FR3065308A1 - Systeme et procede de paiement electronique optimise - Google Patents

Abstract

L'invention concerne un système de paiement électronique comprenant - une pluralité de dispositifs d'utilisateur (2, 4), - une pluralité de dispositifs de partenaires (3, 5), - au moins un dispositif de gestion de données (6) connecté aux dispositifs d'utilisateur (2, 4) et aux dispositifs de de partenaires (3, 5) sorte à pouvoir mettre en œuvre des paiements électroniques d'utilisateurs vers des partenaires, dans lequel ledit dispositif de gestion de données (6) est configuré pour requérir des informations de paiement et des autorisations de paiements d'utilisateurs, Caractérisé en ce que ledit un dispositif de gestion de données (6) comprend au moins un module d'optimisation (6h) configuré pour anticiper une pluralité de paiements de sorte que ledit dispositif de gestion de données (6) requiert une information de paiement et une autorisation de paiement pour ladite pluralité de paiements. L'invention porte en outre sur un procédé et un programme associé.

Description

Système et procédé de paiement électroniqueoptimisé

La présente invention concerne un système de paiement électronique utilisant des moyens informatiques. L'invention concerne en outre un procédé et un produit-programme associé.

L'invention trouve une application particulière, non limitative, dans les paiements électroniques associés à l'utilisation de bons d'achats électroniques,

Le paiement est de préférence un paiement en application (« in-app ») permettant en particulier d'utiliser le paiement électronique proposé par le système. Le paiement peut aussi être un autre type de paiement, auquel cas les informations correspondantes sont entrées dans l'application, en lieu et place du paiement électronique.

Pans le domaine des paiements électroniques, des systèmes connus proposent un dispositif central stockant des données et associé à des dispositifs périphériques permettant de recevoir ou d'envoyer des paiementsélectroniques. D'autres systèmes proposent une plateforme centrale d'échanges de données, en particulier de paiements, entre un dispositif de partenaire et un dispositif d'utilisateur. One récompense peut être attribuée à l'utilisateur, notamment un boa d'achat électronique.

Malheureusement, ces systèmes ne sont pas satisfaisants car les paiements électroniques se font généralement par 1'intermédiaire d'un dispositif de prestataire de service de paiement ce qui génère une transmission de données à chaque paiement électronique. Le volume d© transmis représente un nombre d'autant plus significatif qu'il y a de paiements électroniques.

L'invention vise à proposer un système de gestion dans lequel les transferts de données par 1 ' intermédiaire du prestataire de service de paiementsont significativement diminuées pour un même nombre de paiements électroniques.

Pour ce faire» l'invention concerne un système de gestion de données comprenant

- une pluralité de dispositifs d'utilisateur,

- une pluralité de dispositifs de partenaires,

- au moins un dispositif de gestion de données connecté aux dispositifs d'utilisateur et aux dispositifs de de partenaires sorte à pouvoir mettre en œuvre des paiements électroniques d'utilisateurs vers des partenaires, dans lequel ledit dispositif de gestion de données est configuré pour requérir des informations de paiement et des autorisations de paiements d'utilisateurs, caractérisé en ce que ledit un dispositif de gestion de données comprend au moins un module d'optimisation configuré pour anticiper une pluralité de paiements de sorte que ledit dispositif de gestion de données requiert une information de paiement et une autorisation de paiement pour ladite pluralité de paiements.

Avantageusement, le module d'optimisâtion permet d'avoir moins de transferts de données vers le dispositif de prestataire de service de paiement en anticipant les futurs paiements électroniques.

Selon d'autres aspects pris isolément ou combinés selon toutes les combinaisons techniquement réalisables ï - 1 Optimisation est faite en fonction de paramètres déterminés (2), au dispositif de sur l'utilisateur, aux et/ou à la position liés au dispositif d'utilisateur partenaire (3), aux informations informations sur le partenaire géographique desdits dispositifs (2,3) > et/ou les paramètres sont déterminés en fonction de données d'utilisation du système et/ou de moyennes ; et/ou - les paramètres ccnprranent au moins un des éléments suivants : panier moyen t nombre moyen de paiements sur les derniers jours» par exemple les six derniers jours» heure et jourdu paiement, l'étendue de la récarapease en particulier le % de bon d'achat, chez le partenaire i événements extérieur ;

l'âge, le sexe de l'utilisateur, la catégorie socio professionnelle de l'utilisateur, le pourcentage de batterie du dispositif d'utilisateur, la marque du dispositif d'utilisateur ; l'actualité externeou les évènements proches du partenaire ; la ville dans laquelle il utilise l'application habituellement ; la ville dans laquelle l'utilisateur habite, la ville du partenaire.

L'invention porte en outre sur un procédé de gestion de données en particulier au moyen d'un système selon l'invention, le procédé comprenant les étapes suivantes :

- transmettre des données, en particulier de paiement électronique, d'utilisateurs vers des partenaires,

- requérir une information de paiement et une autorisation de paiement pour une pluralité de paiements.

Selon une variante, le procédé de paiement comprend en outre une étape d'optimiser le paiement électronique en anticipant ladite pluralité de paiements électroniques en fonction de paramètres déterminés liés au dispositif d'utilisateur, au dispositif de partenaire, aux informations sur 1'utilisateur, aux informations sur le partenaire et/ou à la position géographique desdits dispositifs.

Un autre objet de 1'invention concerne un produit-programme informatique chargeable dans au moins une unité de commande et comprenant des parties de code logiciel pour exécuter les étapes du procédé selon l'invention lorsqu'il est mis en œuvre par ladite unité de commande.

L'invention sera davantage détaillée par la description de modes de réalisation non limitatifs, et sur la collection des figures annexées, dans lesquelles :

- la figure 1 est une vue schématique du système selon une variante préférée de l'invention ;

- la figure 2 est une vue schématique d'un dispositif de gestion de données du système de la figure 1 ;

- la figure 3 est un schéma illustrant d'un système de paiement préféré: pouvant être utilisé avec le système de gestion de la figure 1 t et

- la figure 4 est une vue schématique illustrant avec plus de détails le système de gestion de la figure 1,

Réutilisation de la récompense ha présente invention concerne un système de gestion de données 1 utilisant des moyens informatiques.

L'invention trouve une application particulière, non limitative, dans les paiements, notamment les paiements électroniques, et l'utilisation de bons d'achats électroniques.

Le paiement est de préférence un paiement es application (« in-app ») permettant en particulier d'utiliser le paiement électronique proposé par le système. Le paiement peut aussi être un autre type de paiement, auquel cas les informations correspondantes sont entrées dans l'application, en lieu et place du paiement électronique, D'autres modes de paiement sont par exemple par carte de paiement, espèces, chèques, titre de paiement, titre restaurant, télépaiement, virement bancaire, transfert d'argent, ou tout autre type de paiement.

L'invention trouve une application particulière, non. limitative, dans les paiements et 1'utilisation de bons d'achats électroniques.

L'invention pourrait dans une certaine mesure être également appliquée à une gestion de données non monétaires, tels que des éléments électroniques échangés ou attribués, pour une obtention d'une récompense électronique, sans qu'il n'y ait nécessairement d® contrepartie en termes de produite ou de services.

La récompense obtenue est concrète et son amplitude peut être vérifiée, et elle peut être utilisée, par des moyens informatiques, te système 1 comprend une pluralité de dispositifs d'utilisateur 2 (2a, 2b,..., 2z), 4 (4a, 4b,..., 4z), et une pluralité de dispositifs de partenaires 3 (3a, 3b,,..» 3z), 5 (5a, 5b,..., 5z) . Ces dispositifs 2 à 5 comprennent es particulier des dispositifs mobiles 2, 3 tels que des téléphones, tablettes, ou autre dispositif dit connecté tels que des montres connectées. On peut aussi, envisager que ces dispositifs 2, 3, comprennent des ordinateurs 3a'.

Les dispositifs d'utilisateurs 2 et les dispositifs de partenaires 3 sont du typé connectables à un réseau de données mobiles et/ou à 1'internet. En outre, ces dispositifs 2, 3 sont de préférence configurés pour qu'y soit chargeable une application mobile permettant des transferts de données.

Ainsi, dans une interprétation préférée de l'invention, les dispositifs d'utilisateurs 2 et les dispositifs de partenaires 3 sont entendus d'une part comme la partie matérielle des dispositifs mobiles mettant en œuvre une application de transferts de données. Avantageusement, cela permet d'utiliser un dispositif mobile du commerce dans le système selon l'invention, pour ne pas avoir à réaliser un dispositif mobile entier dédié uniquement audit système.

Pans une application, particulière du système selon l'invention, les dispositifs d'utilisateurs 2» 4 peuvent servir à envoyer des données de paiement aux dispositifs de partenaires 3, 4, par le biais d'une application mobile dédiée 6 a» sans avoir besoin de disposer d'un autre moyen de paiement. On parlera dans ce cas de paiement en application (« in-app »)»

Le système de gestion selon l'invention comprend en outre au moins un dispositif de gestion de données 6 connecté aux dispositifs d'utilisateur 2, 4 et aux dispositifs de partenaires 3» 5 sorte à pouvoir mettre en œuvre des échanges de données avec ceux-ci. En particulier, le dispositif de gestion de données 6 conprend un serveur par lequel transite les données.

Plus particulièrement, le système de gestion 1 comprend une application mobile 6a chargée dans les dispositifs d'utilisateur 2 et les dispositifs de partenaires 3, et le dispositif de gestion de données 6 comprenant un serveur est associé à ladite application 6a,

Dans l'application particulière du système, les données de paiement passent par le dispositif de gestion de données S avant d'arriver au dispositif de partenaire 3. ün dispositif de prestataire de paiement 7 associé à un compte bancaire 8 de l'utilisateur peut être en outre prévu* par exemple comme expliqué ci-dessous en référence à la figure 3.

En outre, les données à échanger sont stockées et associées à des cosptes électroniques d'utilisateurs 4 et de partenaires 5. L'application 6a permet es particulier de visualiser notamment la quantité de données et l'état de ces comptes. Ainsi, dans une interprétation préférée de l'invention, les dispositifs d'utilisateurs 2, 4 et les dispositifs de partenaires 3, 5 sont entendus d'autre part comme au moins la partie matérielle A, 5 des comptes d'utilisateurs et de partenaires associées aux données stockées.

Dans 1'application particulière du système, les données du compte d'utilisateur 4 peuvent comprendre au moins une identification de compte bancaire et/ou de carte bancaire ou un autre moyen de paiement. De préférence, le conpte d’utilisateur 4 est associé à une interface permettant au moins d'envoyer des paiements. Les données du compte de partenaire 5 peuvent comprendre au moins une identification de coopte bancaire. De préférence, le conpte de partenaire 5 est associé à une interface permettant de recevoir et d'accepter ou refuser des paiements,

Le système de gestion 1 selon l'invention comprend en outre au moins une source de données de complémentarité 9 associée à au moins une collection de données 10, 11 et/ou aux dispositifs d'utilisateur (31 et/ou aux dispositifs de partenaires (5).

En particulier, le système de gestion selon l'invention comprend au moins une collection de données 10, 11, de préférence plusieurs collections de données 10, 11. Au moins une desdites collections données 11 est associée à nxus source de données de complémentarité. Par « collection de données » peut être entendu une base de données, un compte monétaire ou un dispositif informatique comprenant une mémoire dans laquelle peuvent être stockées des données de complémentarité. Les données de complémentarité sont des données qui peuvent s'ajouter aux données venant de l'utilisateur pour les compléter de sorte à atteindre un but déterminé en termes de quantité de données.

Dans l'application préférée, la collection de données 10, 11 est, en particulier, une cagnotte électronique dans laquelle sont accumulés les données de complémentarités qui sont en particulier une récompense électronique, plus particulièrement des bons d'achats électroniques. ï»a source 9 est en particulier la partie matérielle et informatique d'un compte bancaire associé de préférence à un module du dispositif de gestion de données 6 pour approvisionner les comptes associés auxdits dispositifs 4, 5 ou collection de données 10 11 en particulier d'une manière détaillée ci-dessous.

De préférence, la source 9 est configurée pour compenser des défauts de données de ladite collection de données, en particulier de chaque collection de données de partenaire 11. Dans une variante, on peut prévoir que le compte de partenaire 5 comprend un compte monétaire et la source 9 y est connectée, par exemple pour réaliser un virement ou un transfert d'argent.

Ainsi, le système de gestion comprend un système de compensation de chaque cagnotte électronique 11. ï»e système de compensation comprend au moins un dispositif de basque 9 associé à ladite cagnotte électronique 11. Le dispositif de banque 9 est connecté au dispositif de gestion de sorte que le dispositif de gestion 6 peut donner instruction de compensation au dispositif de banque 9.

De préférence, chaque dispositif d'utilisateur 2, 4 et de partenaire 3, 5 est associé à une collection de données de complémentarité correspondante 10 et 11 (lia, 11b,...). Cet agencement permet de séparer les données à échanger, en particulier les données de paiement, des données de complémentarité générées par le système 1, en particulier des données de bons d'achats électroniques. Une collection de données de complémentarité commune 11 peut être envisagée mais des collections de données spécifiques permettent de séparer des données de chaque utilisateur ou partenaire.

Dans l'application particulière, les comptes d'utilisateur 4 et de partenaires 5 sont associés à des conptes bancaires respectifs, et les cagnottes électroniques 10, 11 comprennent uniquement des bons d'achats générés.

Dans le système selon l'invention, chaque dispositif d'utilisateur 2, 4 est configuré pour transmettre une première quantité de données M à un premier dispositif de partenaire 3, 5 et le système génère en réponse des premières données de complémentarité correspondantes H-X. les données de complémentarité sont de préférence stockées dans une ou ladite collection de données, plus particulièrement dans chacune desdites collections de données 10, 11. Le partenaire reçoit ainsi une quantité de données M-X et on considère qu'il a généré X données de complémentarité utilisables par l'utilisateur au prochain transfert de données avec un autre partenaire.

Ainsi, le système est en particulier configuré poux que lorsque ledit dispositif d'utilisateur transmet une deuxièmequantité N-X de données à un deuxième dispositif de partenaire 3, 5, ladite quantité de données H-X est complétée soit par lesdites premières données de complémentarité correspondantes X si disponibles et sélectionnées par l'utilisateur, soit par des premières données de complémentarité correspondantes X générée ou comblées par la source 9. Avantageusement, 1'utilisateur a besoin de moins de données pour atteindre un but N chez le deuxième partenaire et obtenir d'autres données de complémentarité, en électronique.

particulier une autre récompense

Plus particulièrement, tous les transferts de données génèrent des données de complémentarités correspondantes«

Avantageusement, la configurât ion du système 1 et en particulier le dispositif de gestion de données 6 implémentent «ne obtention d'une récompense électronique permettant de stimuler les échanges pour améliorer l'attrait du système.

En outre, dans une application particulière du système, il permet de mettre en œuvre des moyens de paiement électroniques permettant de transmettre de manière sécurisée des données de paiement de sorte à mettre en œuvre un paiement, ainsi qu'une utilisation de bons d'achats électroniques pour une utilisation concrète mais dématérialisée au moyen d'une application mobile 6a dédiée.

Dans l'application particulière du système, l'envoi de données de paiement par l'intermédiaire du dispositif d'utilisateur 2 vers le dispositif de partenaire 3 déclenche la génération d'un bon d'achat électronique correspondant en particulier à une part du paiement, par exemple 10%. La part est de préférence paramétrable au moyen du dispositif de partenaire. En particulier, le dispositif de gestion 6 génère le bon d'achat électronique et le stocke dans ladite au moins une cagnotte électronique, de préférence dans la cagnotte d'utilisateur 10 et dans la cagnotte de partenaire 11. Lors d'un paiement cher un autre partenaire, le bon. d'achat peut être utilisé de sorte qu'un paiement moindre sera nécessaire.

La source 9 permet d'utiliser rapidement des récompenses électroniques sans attendre que les utilisateurs aient accumulées suffisamment de données de complémentarité. L'engouement résultant de cette utilisation améliore grandement les prauïets échanges de données.

Dans une variante particulière, les quantités de données et les quantités de données complémentaires sont de même nature. En particulier, les boas d'achats et les paiements sont de l'argent pouvant donc se compenser.

ίο

Afin de réguler le système et éviter des pertes trop importantes de données issues de la source 9, certaines configurations peuvent être prévues. Pour ce faire, selon une variante, le dispositif de gestion de données 6 conprend un module d'obligation 6b configuré pour imposer l'utilisation d'au moins une partie des données de complémentarité disponibles.

Dans l'application particulière de l'invention, le module d'obligation 6b impose à l'utilisateur l'utilisation d'au moins une partie dés bons d'achats électroniques disponibles.

En outre, selon une variante, le dispositif de gestion de données peut comprendre un module d'interdiction 6c configuré pour bloquer 1'utilisation de plus de données de complémentarité que le dispositif de partenaire 3,5 n'en a émis, en particulier en dehors des cas de données issues de la source 9.

Dans l'application particulière de l'invention, le module d'interdiction 6c bloque 1'utilisation de plus de bons d'achats que le partenaire considéré n'en a émis.

En outre, le dispositif de gestion peut comprendre un module de dévaluation et/ou réévaluation des bons d'achats. Ce module peut par exemple appliquer un coefficient pour augmenter ou diminuer la valeur des bons d'achats gagnés, te coefficient peut être déterminé par unplusieurs des critères suivants s l'affluence dans le commerce du partenaire, le moyen de paiement utilisé, le secteur d'activité du partenaire, paiement en-ligne ou sur place, le pays d'utilisation et la devise utilisée.

Par exemple des bons d'achats électroniques gagnés dans un restaurant à forte marge faisant un taux élevé sont dévalués de 0,8 chez un marchand de vêtement de marque renommée. De même, on peut envisager que des bons d'achats électroniques gagnés dans un pays donné soient dévalués on réévalués dans ua autre pays. En outre, pour compenser des fluctuations de taux de change, une dévaluation peut être appliquée aux bons d'achats gagnés dans use monnaie autre que celle dans laquelle ils sont utilisés.

Le dispositif de gestion 6 ccmprend des éléments matériels tels qu'un module de connexion 6d tel qu'un BUS de connexion, un module de contrôle 6e tel qu'une CPU et un «octal© mémoire 6f, ainsi que d'autres modules de serveur 6g-6h.

L'invention concerne en outre un procédé de gestion de données particulièrement adapté au système décrit ci-dessus.

Le procédé comprend au moins les étapes pour ;

transmettre une première quantité de données, en particulier un paiement, à un commerce, en particulier à un premier dispositif de partenaire 3,5,

- générer des données de complémentarité, en particulier des bons d'achats,

- compléter la quantité de données transmise, en particulier le paiement, soit par des données de complémentarité, en particulier des bons d'achats électroniques, générées par le Système suite à des précédentes transmissions, soit par des données de complémentarité, en particulier des bons d'achats générés ou comblées par la source 9.

En particulier, le procédé de gestion de données comprend les étapes suivantes :

- fournir une pluralité de dispositifs d'utilisateur 2, 4,

- fournir une pluralité de dispositif de partenaires 3, 5,

- fournir au moins un dispositif de gestion de données 6 connecté aux dispositifs d'utilisateur 2, 4 et aux dispositifs de partenaires 3, 5 sorte a pouvoir mettre en œuvre des échanges de données avec ceux-ci,

- fournir au moins une collection de données (10, 11) dont au moins une (11) est associée à une source de données de complémentarité 9,

- transmettre au moyen d'un dispositif d'utilisateur 2, 4, une première quantité de données à un premier dispositif de partenaire 3, S,

- générer des premières données de complémentarité,

- compléter la quantité de données transmise soit par des données de complémentarité générées par le système suite à des précédentes transmissions, soit par des données de complémentarité générés ou comblées par la source 9.

En particulier, le procédé cœçread use étape pour compenser chaque cagnotte électronique 11,

L'invention concerne en outre un produit-programme pour la mise en œuvre du procédé décrit ci-dessus.

En particulier, l'invention concerne un produit-programme informatique chargeable dans une unité de commande et contprenant des parties de code logiciel pour exécuter les étapes d'un procédé décrit ci-dessus lorsqu'il est mis en œuvre par ladite unité de commande.

Un principe général de gestion des flux de données de paiement dans une application particulière du système selon l'invention va maintenant être décrite en référence à la figure 3.

En étape (a), l'utilisateur envoie, au moyen du dispositif d'utilisateur 2,4, des données de paiement, en particulier un paiement, au dispositif de gestion 6, à savoir un serveur.

Le paiement et l'autorisation de paiement associé peuvent être réalisés de manière connue. De préférence, ils se font suivant les étapes suivantes :

En étape (b), le serveur envoie une demande de paiement à un prestataire de service de paiement, en particulier à un dispositif de prestataire de service paiement 7.

En étape Ce), le prestataire, en particulier son dispositif 7, envoie la demande d'autorisation à la banque 8 de 1·utilisateur, entendre en particulier au système informatique associé au compte bancaire de l'utilisateur S.

Es étape (d), la banque de 1'utilisateur 8 notifie au dispositif de prestataire 7 un accord ou un refus de débiter le compte de l'utilisateur.

En étape (e), le dispositif de prestataire 7 notifie le serveur 6 de l'acceptat ion ou du refus par la banque 8 de débiter le compte bancaire de 1'utilisateur.

En étape (fl), le serveur 6 notifie au dispositif d'utilisateur 2,4 l'acceptation ou le refus de sa banque de débiter le coœpte bancaire associé.

En étape (£2), le serveur 6 notifie au dispositif de partenaire 3,5 l'acceptation ou le refus par la banque 8 de débiter le compte bancaire de 1'utilisateur.

En étape (gl) en cas d'acceptation, le dispositif de partenaire 3,5 envoie au serveur 6 une validation de paiement.

En étape (g,1,1), le serveur 6 envoie au dispositif d'utilisateur 2,4 la validation du paiement par le dispositif de partenaire.

En étape (g2) en cas de refus, le dispositif de partenaire 3,5 envoie une annulâtion. de paiement au serveur 6.

En étape (g2.1), le serveur 6 notifie au dispositif d'utilisateur 2,4 l'annulation du paiement par le dispositif de partenaire 3,5.

En étape (0.2,2), le serveur 6 notifie au dispositif de prestataire 7 l'annulation cta paiement par le dispositif de partenaire 3,5.

En étape (g,2.3), le dispositif de prestataire 7 notifie à la banque de l'utilisateur 8 l'annulation du paiement, qui crédite le compte bancaire de l'utilisateur du montant débité précédemment suite à l'étape (d),

La gestion des données peut aussi se faire sans dispositif de prestataire de paiement 7.

La gestion des données de paiement dans l'application particulière du système selon l'invention va maintenant être décrite en référence à la figure 4»

En étape a.0.1, 1'utilisateur choisit au moyen du dispositif d'utilisateur 2, le commerce, en particulier le dispositif de partenaire 3, dans lequel il veut payer ainsi que le montant à payer et envoie 1'information à l'application 6a.

Selon une variante, ua module informatique de géolocalisation est prévu dans 1'application 6a et facilite la sélection du dispositif de partenaire 3 en fonction d'une localisation proche du dispositif d'utilisateur 2.

En étape a.0.2, l'application 6a demande au serveur 6 le 10 montant de cagnotte électronique X que 1'utilisateur doit utiliser.

Si des boas d'achats sont disponibles, le dispositif serveur oblige de préférence d'utiliser au moins une partie des boas d'achats pour éviter les stockages de montants de bons d'achats afin de réguler le système 1.

En étape a,0.3, le serveur 6 notifieà l'utilisateur, en particulier .au dispositif d'utilisateur 2, le montant de cagnotte minimum a utiliser.

En étape a.l, 1'utilisateur envoie au serveur 6, en 20 particulier au moyen du dispositif d'utilisateur 2,4, le montant à payer au commerce, en particulier les données de paiement à transmettre au dispositif de partenaire 3,5, ainsi que le montant X de cagnotte •utilisé.

En étape a. 2, le serveur 6 envoie au commerce, en 25 particulier au dispositif de partenaire 3,5, le montant payé par l'utilisateur ainsi que le montant X de cagnotte utilisé.

En étape a.3.1, le serveur 6 débite dans la cagnotte utilisateur 10 le montant X utilisé par l'utilisateur.

En étape a.3.2, le serveur 6 débite dans la cagnotte du 30 commerce 11 le montant X utilisé par 1'utilisateur.

En étape a.4.1(a), le commerce, en particulier le dispositif de partenaire, notifie la validation du paiement au serveur 9, qui le transmets en suite au dispositif d'utilisateur (a.4.1(b),.

En étape a,4.1.1» le serveur vérifie le solde de la cagnotte du commerce 11.

En étape a.4.1,11, le solde de la cagnotte du commerce 11 est renvoyé au serveur 6,

En étape a.4.1.12, si le solde de la cagnotte commerce 11 est négatif, le serveur envoie le montant à combler à la source 9, à savoir la banque associée au serveur 6, entendre en particulier au système informatique associé à ladite banque.

En étape a,4.1.13, la banque envoie le montant à combler dans la cagnotte du commerce 11 pour la solder.

Ainsi, selon une variante, le dispositif de gestion, comprend un module de vérification de solde de cagnotte de commerce 11, et un module d'instructions de virement d'un montant correspondant à un solde négatif. Avantageusement ces deux modules permettent aux commerces de recevoir des bons d'achat électroniques même en l'absence de bons d'achats émis.

En étape a.4.12, le serveur 6 crédite le montant Y dans la cagnotte utilisateur 10 généré suite à son paiement dans le commerce.

En étape a.4.13, le serveur crédit® le montant Y dans la cagnotte du commerce 11 généré suite au paiement de 1'utilisateur.

En étape a.1.2, en cas de refus, le commerce notifie le serveur 6 de 1’annulation du paiement, au moyen du dispositif de partenaire 3, 5.

En étape a.4.21, le serveur 6 notifie à 1'utilisateur, par le biais du dispositif d'utilisateur 2, 4, l'annulation du paiement par le commerce.

En étape a.4.22, le serveur 6 crédite dans la cagnotte de l'utilisateur 10 le montant X de cagnotte utilisé.

En étape a.4.23, le serveur 6 crédite dans la cagnotte du commerce 11 le montant X de cagnotte utilisé par l'utilisateur,

Ainsi, dans une variante préférée, l'invention concerne notamment un programme de fidélité pour les commerçant s et les utilisateurs mis ©n œuvre de manière électronique procurant un avantage aux utilisateurs. Ainsi, à chaque paiement chez leur commerçant, les utilisateurs reçoivent automatiquement un bon. d'achat, exprimé en euros et crédité dans une cagnotte. Cette variante préférée réside dans la gestion de ces bons d'achats.

En effet, les utilisateurs peuvent utiliser leurs bons d'achats chez tous les- commerçants, c'est-à-dire qu'ils peuvent l'utiliser au sein du commerce qui l'a généré ou au sein d'un autre coomerce, le tout de préférence sans conditions. Les utilisateurs peuvent donc utiliser leur cagnotte dans les commerces du monde entier, que ce soit dans le magasin physique ou sur le site web du ccasanerçant.

Cette liberté laissée aux utilisateurs est couplée au fait que les commerçants ne peuvent pas recevoir plus de bons d'achats qu'ils n'en ont émis, sauf cas d'utilisation de la banque (9).

L'invention concerne en particulier un moteur capable de gérer les flux afin que les utilisateurs puissent utiliser leurs bons d'achats quand ils le souhaitent tout en permettant aux commerces de ne pas recevoir plus de bons d'achats qu'ils n'en ont émis, sauf cas d'utilisation de la banque.

Optimisation de la réccanpense

Un aspect particulier de l'invention vise à mieux adapter les récompenses aux utilisateurs au moment de l'échange de données.

Selon cet aspect, ledit dispositif de gestion de données 6 comprend au moins un module de gestion 6g configure pour Optimiser l'étendue de la réccmqpense électronique de manière spécifique en fonction de paramètres déterminés liés au dispositif d'utilisateur (2, 4), au dispositif de partenaire (3,

5), aux informations sur 1'utilisateur, aux informations sur le partenaire et/ou à la position géographique desdits dispositifs (2, 3).

Le module de gestion 6g comprend par exemple us algorithme utilisant lesdits paramètres pour déterminer avec précision, la récompense optimale pour un utilisateur donné, La détermination peut se faire de manière absolue, suivant des règles prédéterminées, ou en utilisant des moyennes. La détermination absolue vise à anticiper de manière précise la situation d'échange actuelle à partir de données de précédentes utilisations du système 1.

Dans l'application particulière, les bons- d'achats électroniques optimisés permettent de cibler un utilisateur et stimuler l'échange, en particulier le paiement pouvant être electroniqu.e.

Selon une variante, le module de gestion 6g est configuré pour optimiser l'étendue de la récompense électronique autour d'un seuil prédéterminé, de préférence au-dessus d'un seuil minimal.

Par exenple le seuil minimal est fixé à 10%.

Le partenaire a la possibilité de modifier l'étendue de la récompense. Le dispositif de gestion est configuré pour proposer une étendue adaptée à la situation actuelle,

L'étendue déteraiaee peut en outre être signalée à

1'utilisateur. Par exemple, en fonction de la géolocalisation de l'utilisateur, l'étendue suggérée aux partenaires proches peut être affichée sur le dispositif d'utilisateur 2. Un partenaire peut ainsi être recommandé à un utilisateur avec une étendue associée, à savoir en particulier un pourcentage de bon d'achat associé.

La détermination peut être faite autour d'un seuil déterminé défini dans un cas particulier corn» une récompense maximale acceptable, par exemple suivant des études de marché ou des données accumulées par le dispositif de gestion 6. Le seuil prédéterminé est de préférence spécifique à une activité et/ou peut être indexé sur les marges moyennes dans une activité, par exemple 10% de la marge allouée au maximum aux bons d'achats mobiles. Dans une activité donnée à très forte marge, par exeuple en pizzeria, il peut être de 40%, et dans une autre activité, il peut être de 20%.

Selon une variante, les paramètres sont des indicateurs de situation défavorable à l'utilisateur et la récompense est diminuée. Ces indicateurs montrent çpie l'utilisateur sera enclin à effectuer l'échange de données sans être incité par une offre particulière de récompense. Dans ce cas, le module de gestion 6g détermine une étendue plus proche du seuil minimum, ici 10%. Par exemple, le module de gestion 6g détermine une récompense entre 10% et le seuil prédéterminé, par exemple à mi-chemin entre ces valeurs.

Des indicateurs a long terme peuvent être des moyennes ou autres calculs issus d'une base de données d'anciennes utilisations du système.

Les indicateurs en temps réels sont similaires et sont déterminés en continu par le dispositif de gestion 6, et peuvent être actualisés.

Ces indicateurs sont par exemple une heure de paiement tardive, par exemple après 2.2 heures, un pourcentage de batterie du dispositif d'utilisateur 2 inférieur a un seuil de batterie, par exemple 10%, les conditions météorologiques défavorables au moment de l'échange, par exemple un temps brumeux ou un temps pluvieux.

Alternativement, les indicateurs peuvent être à contrario défavorables au partenaire, lorsque la. situation est à l'opposé de l'une de celle ci-dessus. En particulier, la récompense peut être au seuil prédéterminé par exemple 40 ou 20% ou encore un autre pourcentage.

De manière générale, le dispositif de gestion 6 adapte l'étendue de la réccm^ense grâce à une analyse des données disponibles notamment pour des situations similaires à la situation en cause dans le passé. Des corrections peuvent être prévues entre des domaines voisins, par exemple en ajoutant un point à l'étendue déterminée dans le domaine voisin.

Selon une variante, les paramètres comprennent un type d'échange, en particulier de paiement par exemple sur place, à emporter, en livraison, ou à distance. Lorsque le paiement est fait pour un échange sur place, en particulier une consommation sur place, le dispositif de gestion 6 peut limiter l'étendue de la récompense par exemple au seuil minimal. Lorsque le paiement est fait pour un autre échange, l'étendue de- la récctnpense est augmentée, en particulier pour une consommation, commandée avec livraison, l'étendue augmente par exemple de deux points. Pour une consommation à distance, l'étendue augmente de préférence davantage que pour une commande en livraison. Par exemple de 5 points de plus que le seuil minimal.

Selon une variante, les paramètres comprennent un montant d'une cagnotte électronique de partenaire ou d'une cagnotte électronique d'ut ilï sateux.

En particulier, si la cagnotte est de plus de 30€ l'étendue augmente de deux points sinon elle diminue par exemple de deux points.

Selon une variante, les paramètres comprennent une fréquence d'utilisation de la cagnotte

En particulier, si l'utilisation est rare, par exemple deux fois par mois, l'étendue augmente par exemple de deux points sinon elle diminue de deux points.

Selon une variante, les paramètres comprennent la fréquentation chez le partenaire au moment de l'échange

La fréquentation peut être déterminée par le nombre de dispositif d'utilisateurs 2géolocalisés a» même endroit que le dispositif de partenaire 3.

En particulier,, si la fréquentation est importante, par exemple trois fois par semaines, l'étendue augmente par exemple de deux points sinon elle diminue de deux points.

Selon une variante, les paramètres comprennent ; des récompenses accordées par un ou plusieurs autres partenaires ou tiers proches géographiquement,

En particulier, le dispositif de gestion 6 propose une étendue similaire à celle des partenaires proches.

Selon une variante, les paramètres comprennent la fréquence de fréquentation de l'utilisateur au sein d'un établissement donné.

La fréquentation peut être déterminée es fonction de la géolocalisation de 1'utilisateur au même endroit que le dispositif de partenaire 3.

En particulier, si la fréquentation est importante» par exençle trois fois par semaines, l'étendue augmente par exenple de deux points sinon elle diminue de deux points.

Selon une variante, les paramètres comprennent la récurrence des paiements de l'utilisateur dans le réseau global du système.

Selon une variante, les paramètres comprennent la marque du dispositif d'utilisateur 2. En particulier, si la marque est considérée comme étant d'une gamme supérieure à la moyenne» l'étendue augmente de 2 points sinon elle diminue par exemple de deux points.

Selon, une variante» les paramètres conprennent l'âge et/ou le sexe de l'utilisateur. En particulier, si l'utilisateur est un homme, on augmente, par exemple de deux- points sinon oa baisse de deux points. En particulier» si l'utilisateur est âgé de plus de 20 ans» on baisse l'étendue par exemple de deux points sinon on 1'augmente de deux points.

Selon une variante» les paramètres eaŒprennent la catégorie Socio-Professionnelle de l'utilisateur, En particulier, si l'utilisateur est d'une catégorie considérée comme aisée, on augmente 1'étendue par exemple de deux points sinon on la baisse de deux points.

Selon une variante, les paramètres comprennent la ville dans laquelle il utilise l'application habituellement ; ou la ville dans laquelle l'utilisateur habite ; ou la ville du partenaire. La ville peut être déterminée par géolocalisation du dispositif de partenaire 3 ou du dispositif d'utilisateur 2.

Par exemple, ces paramètres peuvent être indexés sur un critère objectif qualifiant la ville comme un classement de villes touristiques, ou le PIB de la ville.

En particulier, si la ville est une ville favorable aux échanges, on augmente l'étendue par exemple de 2 points sinon on la baisse de deux points.

Selon une variante, les paramètres comprennent les habitudes du réseau social de l'utilisateur, en particulier les amis de 1'utilisateur et de préférence leurs amis.

Les habitudes du réseau social peuvent être déterminées par une analyse des données relatives à un réseau social en ligne par l'internet.

En particulier, si le réseau social montre un enclin au produit acheté, on augmente l'étendue par exemple de 2 points sinon on la baisse de deux points.

Selon une variante, les paramètres comprennent l'actualité externeou les évènements proches du partenaire. L'actualité est déterminée par une analyse de données d'actualité en ligne par internet.

Par exemple si un évènement majeur a lieu le Jour ou près du jour de l'échange, on augmente l'étendue par exemple de 2 points sinon on la baisse de deux points.

Les points évoqués ci-dessus sont des augmentations ou des diminutions de pourcentage de bons d'achat. Le nombre de points dépend des données sur les précédents échanges, et/ou sur des données d'études de marché et/ou des moyennes de données sur des j situations similaires. i

L'invention porte en outre sur un procédé de gestion de j données en particulier au moyen d'un système tel que décrit j précédemment » j t

Le procédé comprend une étape de transmettre des données, en j particulier de paiements d'utilisateurs vers des partenaires. i

Dans cette étape, des données, en particulier des données de paiement sont transmises. Le paiement est tel que décrit ci- j dessus. j

Le procédé se poursuit par une étape d'optimiser l'étendue j de la récompense électronique, en particulier du boa d'achat j électronique, de manière spécifique en fonction de paramètres j déterminés liés au dispositif d'utilisateur 2, au dispositif de j partenaire 3, aux informations sur 1'utilisateur, aux j informations sur le partenaire et/ou à la position géographique i desdits dispositifs 2, 3. Les paramètres sont en particulier 1 ceux décrits ci-dessus. ï

Le procédé comprend une étape d'émettre ladite récompense j électronique, en particulier de bons d'achats électroniques, des { partenaires vers les utilisateurs. L'émission de bons d'achats j électroniques se fait en particulier comme décrit ci-dessus. j

En particulier, dans le procédé général de gestion décrit j ci-dessus l'optimisation de la récompense est faite au moment de la validation du paiement, par exemple entre les étapes a. 4.1(a) ï et (b). Avantageusement, cet aspect implique un effet de j surprise pour l’utilisateur et le partenaire jusqu'au moment de , l'échange, en particulier du paiement. L'utilisateur est donc j stimulé à utiliser le système car il sait qu'il obtiendra une i récompense et il veut en découvrir l'étendue en réalisant I l'échange en particulier le paiement. j

Les éléments permettant l'optimisation de la récompense j peuvent aussi être mis en œuvre dans un système de gestion sans « réutilisation de récompense tel que décrit ci-dessus. j

L'invention porte également sur un produit-programme informatique chargeable dans au moins une unité de commande et comprenant des parties de code logiciel pour exécuter les étapes du procédé tel que décrit ci-dessus, lorsqu'il est mis en œuvre par ladite unité de commande.

Optimisation des paiements électroniques

Un aspect particulier de vise à diminuer le nonbre de transferts de données vers le dispositif de prestataire de

service de	paiement 7 pour un	même	soiabre	de	paiements
électroniques	. Dans cette optique,	le	système	de	gestion de
données 1	est considéré comme	ra	système	de paiement
électronique.
Pour ce	faire» le dispositif	de	gestion	de	données S

cœprend au moins un module d'optimisation 6h configuré pour anticiper une pluralité de paiements.

La pluralité de paiement ainsi optimisée permet d'effectuer un paiement électronique correspondant et d'utiliser un seul transfert de données vers le dispositif de prestataire de service de paiement 7. Par « pluralité de paiements » est entendu un nombre supérieur à un paiement.

Une fois l'optimisation réalisée, le dispositif de gestion de données 6 requiert une information de paiement et une autorisation, de paiement pour ladite pluralité de paiements. En particulier, l'optimisation est faîte ou corrigée en fonction de paramètres déterminés liés au dispositif d'utilisateur» au dispositif de partenaire» aux informations sur l'utilisateur» aux informations sur le partenaire et/ou à la position géographique desdits dispositifs.

Le module d'optimisation 6h comprend par exemple un. algorithme utilisant lesdits, paramètres pour déterminer avec précision 1'étendue optimale pour un utilisateur donné. La détermination peut se faire de manière absolue, suivant des règles prédéterminées, ou en utilisant des moyennes. La détermination absolue vise à anticiper de manière précise la situation d'échange actuelle à partir de données de précédentes utilisations du système 1.

Alternativement ou en combinaison, l'étendue de l'autorisation peut être déterminée suivant une référence et ajustée par lesdits paramètres de préférence en fonction d'une part de données de précédentes utilisations du système et/ou de moyennes, et d'autre part desdits paramètres. La référence peut être ajustée en fonction du secteur d’activité du partenaire et/ou sa notoriété évaluée de manière objective.

Par exemple, l'étendue est de 25 euros. Ainsi, le dispositif de gestion de données 6 requiert une autorisation correspondante dès le prochain paiement. Avantageusement, lorsque le dispositif d'utilisateur totalise par exeuple cinq fois 5 euros de paiements, le dispositif de gestion 6 a utilisé un seul transfert de données vers le dispositif de prestataire 7 au lieu de cinq dans l'art antérieur.

Plus généralement, selon une variante, l'autorisation peut être une préautorisation, et le dispositif de prestataire de paiement 7 réalise une empreinte sur le compte bancaire de l'utilisateur pendant une période donnée, par exemple de sept jours, puis, de préférence au terme de cette période, le prélèvement du paiement global est réalisé sur le compte.

On peut envisager un dispositif de gestion 6 ayant des modules informatiques d'un dispositif de prestataire de service de paiement 7.

De préférence, si l'autorisation est refusée, une nouvelle autorisation de plus qu'un paiement et moindre que l'autorisation précédente est demandée. Par exeple une autorisation de 20 euros est demandée. De nouveaux essais de ce type peuvent être réitérés.

Selon une variante, les paramètres comprennent le panier moyen, par exemple le panier moyen du dispositif d'utilisateur.

En particulier, si le panier moyen sur une période donnée est par exemple de plus de 14€, le module d'optimisation 6h détermine une étendue correspondante augmentée par exemple de deux euros sinon elle est diminuée de deux euros.

Selon uBé variante, les paramètres coupreanent le nombre moyen de paiements sur les derniers jours par exemple les six derniers jours.

En particulier, si un utilisateur effectue plus de cinq paiements sur les six derniers jours, l’étendue augmente de par exemple de deux euros sinon elle diminue de deux euros.

Selon une variante, les paramètres comprennent l'heure et le jour du paiement.

En particulier, si un utilisateur paye après 23 heures, l'étendue augmente par exençle de deux euros sinon elle diminue de deux euros. Par ailleurs, si un utilisateur paye après le 15 du mois, l'étendue augmente par exemple de deux euros sinon elle diminue de deux euros.

Selon une variante, les paramètres comprennent l'étendue de la récompense en particulier le pourcentage de bon d'achat mobile, chez le partenaire.

En particulier, si un utilisateur le pourcentage de bon, d'achat mobile est supérieur à 15%, l'étendue augmente par exemple de deux euros sinon elle diminue de deux euros.

Selon une variante, les paramètres coeprennent l'âge. En particulier, si un utilisateur a plus de 20 ans, l'étendue augmente par exemple de deux sinon elle diminue de deux euros.

Selon une variante, les paramètres comprennent le sexe de l'utilisateur par exemple dans un domaine d'activité donné. En particulier, si l'utilisateur est un homme, l'étendue augmente par exemple de deux euros sinon elle diminue de deux euros.

Selon une variante, les paramètres comprennent la catégorie socio professionnelle de l'utilisateur. En particulier, si l'utilisateur est d'une catégorie considérée comme aisée, on augmente par exemple de deux euros sinon elle diminue de deux euros.

Selon une variante, les paramètres coaprennent le pourcentage de batterie du dispositif d'utilisateur, la marque du dispositif d'utilisateur. En particulier, si le pourcentage de batterie du dispositif de 1'utilisateur est inférieur à 5%, l'étendue augmente par exemple de deux euros sinon elle diminue de deux euros, ;

Selon une variante, les paramètres cantprennent l'actualité j i

externe ou les évènements proches du partenaire. En particulier, si un événement externe a lieu à proximité du partenaire, j l'étendue augmente par exeaple de deux euros sinon elle diminue { de deux euros. 1

Selon une variante, les paramètres comprennent la ville dans- l laquelle il utilise l'application habituellement t ou la ville j dans laquelle l'utilisateur habite ·, ou la ville du partenaire. i

La ville peut être déterminée par géolocalisation du dispositif j de partenaire 3 ou du dispositif d'utilisateur 2. {

Par exemple, ces paramètres peuvent être indexés sur un , critère objectif qualifiant la ville comme un classement de j villes touristiques, ou le PIB de la ville, j

En particulier, si la ville est une ville favorable aux j échanges, on augmente l'étendue par exemple de 2 euros sinon oa i la baisse de deux euros. j

L'étendue est de préférence optimisée pour correspondre au i mieux à un utilisateur donné es combinant les données sur l'utilisateur et des données sur toutes les précédentes J utilisations du système. J

L'invention concerne en outre un procédé de paiement î électroniqueen particulier au moyen d'un système tel que décrit j ci-dessus. f

Le procédé comprend une étape de transmettre des données, en j particulier de paiement électronique, d'utilisateurs vers des J partenaires. Ce paiement est par exemple un paiement dit « in- j app ».

i

I ï

(

Le procédé comprend en outre une étape d'optimiser le paiement électronique en anticipant une pluralité de paiements électroniques en fonction de paramètres déterminés liés au dispositif d'utilisateur, au dispositif de partenaire, aux informations sur 1'utilisateur, aux informations sur le partenaire et/ou à la position géographique desdits dispositifs. Les paramètres sont en particuliers ceux décrits ci-dessus.

Le procédé comprend en outre une étape de requérir use information de paiement et une autorisation de paiement pour ladite pluralité de paiements. Cette étape est de préférence incluse dans l'étape (b) décrite ci-dessus.

Les éléments permettant l'optimisation du paiement peuvent aussi être mis en œuvre dans un système de paiement autre que celui utilisé dans le système de gestion tel que décrit cidessus»

L'invention porte également sur un produit-programme informatique chargeable dans au moins une unité de commande et comprenant des parties de code logiciel pour exécuter les étapes du procédé tel que décrit ci-dessus, lorsqu'il est mis en œuvre par ladite usité de cconmande.

Claims (7)

1. Système de paiement électroniquecomprenant

- une pluralité de dispositifs d'utilisateur (2, 4),

- use pluralité de dispositifs de partenaires (3, 5),

- au moins un dispositif de gestion de données (6) connecté aux dispositifs d'utilisateur (2, 4) et aux dispositifs de de partenaires (3, 5) sorte à pouvoir mettre en œuvre des paiements électroniques d'utilisateurs vers des partenaires, dans lequel ledit dispositif de gestion de données (6) est configuré pour requérir des informations de paiement et des autorisations de paiements d'utilisateurs.

Caractérisé en ce que ledit un dispositif de gestion de données (6) comprend au moins un module d'optimisation (6h) configuré pour anticiper une pluralité de paiements de sorte que ledit dispositif de gestion de données (6) requiert une information de paiement et une autorisation de paiement pour ladite pluralité de paiements.

2. Système de de paiement électronique selon la revendication précédente, dans lequel l'optimisation est faite en fonction de paramètres déterminés liés au dispositif d'utilisateur (2), au dispositif de partenaire (31, aux informations sur l'utilisateur, aux informâtions sur le partenaire et/ou à la position géographique desdits dispositifs (2,3).

3. Système de de paiement électroniqueselon la revendication précédente, dans lequel les paramètres sont déterminés en fonction de données d'utilisation du système (1) et/ou de moyennes.

4. Système de de paiement électroniqueselon la revendication 2 ou 3, dans lequel les paramètres ccmçrennent au moins un des éléments suivants ; panier moyen ,· nombre moyen de paiements sur les derniers, jours par exemple les six derniers jours, heure et jour du paiement, l'étendue de la récompense en particulier le % de bon d'achat, chez le partenaire ; événements extérieur ; l'âge, le sexe de l'utilisateur, la catégorie socio professionnelle de l'utilisateur, le pourcentage de batterie du dispositif d'utilisateur, la marque du dispositif d'utilisateur ; l'actualité externe ou les évènements proches du partenaire.

5. Procédé de paiement électronique en particulier au moyen d'un système selon l'une des revendications précédentes, le procédé comprenant les étapes suivantes t transmettre des données, en particulier de paiementélectronique, d'utilisateurs vers des partenaires,

- requérir une information de paiement et une autorisation de paiement pour une pluralité de paiements.

6. Procédé de paiement électronique selon la revendication précédente, comprenant en outre une étape d'optimiser le paiement électronique en anticipant ladite pluralité de paiements électroniques en fonction de paramètres déterminés liés- au dispositif d'utilisateur, au dispositif de partenaire, aux informations sur l'utilisateur, aux informations sur le partenaire et/ou à la position géographique desdits dispositifs.

7. Produit de programme informatique chargeable dans au moins une unité de commande et comprenant des parties de code logiciel pour exécuter les étapes du procédé selon la revendication précédente lorsqu'il est mis en œuvre par ladite unité de commande.