La présente invention concerne la gestion de transactions financières effectuées par des débiteurs auprès de créditeurs via des comptes bancaires de ces derniers. Plus précisément, l'invention concerne des procédés et des dispositifs de commande d'opérations annexes liées à l'exécution de transactions principales, par exemple de gestion de dons suite à des paiements par cartes bancaires, effectués à l'aide de dispositifs reliés par un réseau de communication.

Alors que traditionnellement les dons étaient effectués de façon autonome, par exemple en adressant un chèque ou un virement à un organisme d'intérêt général ou en donnant de la monnaie à un représentant d'une association, il existe aujourd'hui des applications mises en œuvre sur ordinateur (c'est-à-dire, en pratique, sur ordinateurs, assistants personnels, smartphones ou similaires).

Une caractéristique essentielle des mécanismes de collecte de dons mis en œuvre par ordinateur concerne la qualité des interfaces permettant d'effectuer des dons afin qu'un utilisateur ne soit pas enclin à écarter une offre de dons pour des raisons de complexité, de temps excessif, d'incertitude quant au montant, au bénéficiaire ou à la fiabilité de la procédure, etc..

Alors que ces mécanismes obéissent généralement à des règles monétaires simples en proposant, par exemple, d'arrondir une somme à payer pour un achat à l'entier supérieur ou de verser une somme prédéterminée pour chaque achat, la mise en œuvre est généralement complexe pour répondre aux besoins de simplicité de l'utilisateur et de sécurité concernant les transactions. En outre, il existe une demande importante de traçabilité des dons, notamment à des fins fiscales.

La figure 1 illustre schématiquement un environnement dans lequel peut être mis en œuvre un mécanisme de collecte de dons permettant à un client d'effectuer un micro-don lors d'un achat, par exemple un don de la différence entre le prix à payer et ce prix arrondi à l'entier supérieur.

Comme illustré, l'environnement 1 00 permet à un client 1 05 disposant d'une carte de paiement d'effectuer des achats auprès d'un commerçant disposant d'une infrastructure informatique 1 1 0. Outre cette infrastructure, l'environnement 1 00 comprend ici un système informatique 1 15 lié à une banque du commerçant, un système informatique (non représenté) lié à une banque du client et un système informatique 1 20 lié à une banque d'une organisation 1 25 de type ONG (sigle d'Organisation Non-Gouvernementale).

L'infrastructure informatique 1 10 du commerçant comprend ici, en particulier, un système informatique comptable 1 30, un logiciel de caisse 1 35 associé à une caisse opérée par une hôtesse de caisse et un terminal de paiement 140. Le système informatique comptable 1 30 et le logiciel de caisse 135 sont connectés l'un à l'autre par un réseau de communication, par exemple un réseau de type Ethernet mettant en œuvre le protocole I P (sigle d ^! Internet Protocol en terminologie anglo-saxonne).

Les systèmes informatiques liés aux banques sont reliés entre eux et au système informatique comptable 1 30 ainsi qu'au terminal de paiement 140 par un réseau de communication de type Internet, les échanges de données étant sécurisés, par exemple par cryptage.

Le mécanisme de collecte de dons est généralement essentiellement mis en œuvre dans le système informatique comptable 130 du commerçant ainsi que dans son logiciel de caisse.

Lorsqu'un client passe en caisse pour effectuer le règlement de ses achats (étape ©), d'un montant noté M, l'hôtesse de caisse lui demande s'il souhaite effectuer un don d'un montant noté D (étape ©). Si le client refuse, le processus de paiement se poursuit de façon classique (non représenté).

Au contraire, si le client accepte d'effectuer un don (étape ®), l'hôtesse de caisse appuie sur un bouton spécifique pour calculer une valeur de don basée sur l'arrondi supérieur du montant des achats, passe un code-barres spécifique pour obtenir un résultat similaire ou saisit le montant du don à l'aide du logiciel de caisse (étape ®'). Cette saisie est typiquement effectuée en ajoutant une référence particulière à la liste des références des produits achetés par le client, cette référence particulière désignant un don et permettant, le cas échéant, la saisie d'un montant libre par l'hôtesse de caisse.

Il est observé que plusieurs références particulières peuvent être utilisées pour désigner chacune un organisme à qui le don doit être effectué. Le don est ainsi intégré au ticket de caisse dont le montant total indiqué, noté 7 ^" , comprend le montant des achats réels (M) et le montant du don (D). En d'autres termes, T = M + D.

Dans une étape suivante (étape ©), le montant total ( 7) indiqué sur le ticket de caisse, le montant des achats réels (M) et le montant du don (D) sont transmis par le logiciel de caisse 1 35 au système informatique comptable 130 du commerçant.

Si le paiement des achats est effectué par carte bancaire (et non en espèce ou par chèque), le logiciel de caisse transmet automatiquement le montant à payer ( 7) au terminal de paiement 140. Alternativement, ce montant est saisi par l'hôtesse de caisse sur le terminal de paiement 140. S'il est autorisé, le client valide le paiement à l'aide de son code secret.

Le système informatique de la banque du commerçant télécollecte les encaissements du commerçant, typiquement de façon périodique, et présente en intermédiation bancaire le montant des paiements ( 7 ^~ = M ou 7 ^~ = M + D selon que le client ait effectué un don ou non) pour créditer un compte du commerçant d'un montant correspondant (étape (D).

Parallèlement, le système informatique comptable 1 30 du commerçant met à jour des journaux de compte dans lesquels figurent les montants des achats réels (M) et les montants des dons (D), typiquement par organisation bénéficiaire. La gestion distincte des montants des achats réels {M) et des montants des dons (D) est nécessaire pour des raisons comptables (liées par exemple à la TVA, sigle de Taxe sur la Valeur Ajoutée) et fiscales (notamment pour le calcul du chiffre d'affaire dans lequel le montant des dons ne doit pas rentrer).

Le journal de compte des dons est notamment utilisé par le commerçant pour reverser périodiquement, par exemple tous les mois, le montant total des dons reçus pour le compte d'une ou plusieurs organisations. De tels versements sont typiquement effectués sur ordre du commerçant à sa banque, cette dernière exécutant l'ordre de transaction (étapes © et ©'). La ou les organisations disposent alors des dons versés pour effectuer leurs missions (étape ®).

Il est observé ici que les mécanismes de collecte de dons ou de micro-dons tels que celui décrit en référence à la figure 1 nécessitent, pour leur mise en œuvre, des modifications substantielles des dispositifs utilisés.

Ainsi, en particulier, il est nécessaire de modifier le logiciel de caisse et/ou d'ajouter un logiciel coopérant avec ce dernier, afin de permettre la saisie d'au moins une référence particulière désignant un don et permettant le calcul d'un montant associé ou la saisie d'un montant libre associé, pour qu'un article particulier, non soumis à la TVA, soit ajouté à un ticket de caisse.

Il est également nécessaire de modifier le système informatique comptable du commerçant pour permettre une gestion distincte des montants d'achats réels et des montants de dons, pour permettre le traitement de références de produits assimilés à des dons et non soumis à la TVA (ces montants ne doivent pas entrer dans le calcul du chiffre d'affaire), pour gérer différents journaux de comptes et pour créditer des comptes extérieurs (comptes associés à des organisations de type ONG) ainsi que pour calculer le montant exact du chiffre d'affaire.

Par ailleurs, il convient de noter que la mise en œuvre de ces mécanismes de collecte de dons nécessite une implication du personnel de caisse auprès des clients. Ainsi, par exemple, les hôtesses de caisse doivent faire la « quête » auprès des clients en les priant de réaliser un don puis, le cas échéant, gérer l'initiation du processus de gestion de dons. Ce surplus de travail est généralement considéré comme désagréable par les hôtesses de caisse qui ont la sensation de quémander des dons. En outre, cette façon de procéder peut avoir une influence psychologique désagréable et être considérée comme intrusive par le client qui se sent piégé dans la mesure où un refus peut être mal considéré par une hôtesse de caisse ou un client situé à proximité lorsque la question est posée. Ainsi, les contraintes imposées par ces mécanismes de collecte de dons ont des conséquences importantes.

En outre, il existe des risques de ralentissement important du passage en caisse à cause de la complexité de la procédure.

Enfin, les modifications devant être apportées au logiciel de caisse et dans le système informatique comptable du commerçant sont très coûteuses (typiquement de l'ordre de plusieurs millions d'euros dans le cadre d'une chaîne opérant à l'échelle nationale). Il est observé ici que les modifications sont très difficilement exportables d'un commerçant à un autre, ce qui implique une répétition des opérations de modifications et donc des coûts afférents.

Enfin, le transfert et la gestion des fonds sont de la responsabilité du commerçant, sans réels contrôles possibles. La traçabilité des dons n'est ainsi pas assurée, conduisant à des problèmes tels que des problèmes de défiscalisation.

L'invention permet de résoudre au moins un des problèmes exposés précédemment.

L'invention a ainsi pour objet un procédé de commande d'une opération annexe liée à l'exécution d'une transaction principale, ce procédé étant mis en œuvre dans un système de gestion d'opérations annexes connecté à un dispositif tiers d'un ensemble de paiement bancaire comprenant en outre au moins deux dispositifs clients distincts, l'ensemble de paiement bancaire étant configuré pour effectuer une transaction principale entre les deux dispositifs clients, et comprenant les étapes suivantes,

- réception d'informations relatives à l'exécution de ladite transaction principale entre les deux dispositifs clients, lesdites informations étant reçues dudit dispositif tiers ;

- identification d'au moins une règle d'exécution de l'opération annexe selon au moins une première information desdites informations reçues ; et

- exécution de l'opération annexe selon ladite au moins une règle identifiée et au moins une seconde information desdites informations reçues, distincte de ladite première information. Le procédé selon l'invention offre ainsi la possibilité d'effectuer des dons lors d'un paiement sur terminal de paiement sans modification des logiciels de caisse et des systèmes informatiques comptables équipant les commerçants. Seul l'ajout d'un module de traitement de données issues de la chaîne de paiement est nécessaire, sans modification de cette dernière. Ce module est typiquement ajouté à un équipement de la chaîne de paiement, par exemple un équipement d'une banque émettrice d'une carte de paiement utilisée pour le paiement, sans modification des flux de paiement. Les coûts d'implantation informatique d'une telle solution ainsi que la fiabilité de la solution sont donc avantageux.

La collecte de dons est particulièrement rapide du fait qu'elle est totalement transparente, pour le débiteur et le créditeur, au moment de l'exécution de la transaction principale. Les hôtesses de caisse ne sont pas sollicitées pour collecter des dons.

En outre, l'installation du procédé de gestion de dons selon l'invention est particulièrement simple. De plus, il permet un réel contrôle et une réelle traçabilité des dons.

Selon un mode de réalisation particulier, le procédé comprend en outre une étape de configuration de ladite au moins une règle d'exécution dans ledit système de gestion d'opérations annexes.

Selon un mode de réalisation particulier, le procédé comprend en outre une étape de mémorisation d'au moins une information relative à l'exécution de ladite opération annexe et une étape de création d'un historique d'exécution d'opérations annexes.

Selon un mode de réalisation particulier, ladite étape d'exécution de l'opération annexe comprend une étape de transmission de données à au moins un dispositif distinct dudit dispositif tiers.

Selon un mode de réalisation particulier, lesdites données transmises à au moins un dispositif distinct dudit dispositif tiers comprennent un ordre de débit et un ordre de crédit.

Selon un mode de réalisation particulier, lesdites étapes d'identification d'au moins une règle et d'exécution de l'opération annexe sont exécutées de façon périodique selon des informations préalablement reçues et mémorisées.

L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur. Les avantages procurés par ce programme d'ordinateur sont similaires à ceux évoqués ci-avant.

L'invention a aussi pour objet un dispositif de commande d'opérations annexes liées à l'exécution de transactions principales, ledit dispositif comprenant :

- une base de données ;

- un module d'acquisition et de gestion d'opérations annexes ; et,

- un module de calcul,

le module d'acquisition et de gestion d'opérations annexes et le module de calcul étant configurés pour

o recevoir des données d'un dispositif tiers d'un ensemble de paiement bancaire comprenant en outre au moins deux dispositifs clients distincts, l'ensemble de paiement bancaire étant configuré pour effectuer une transaction principale entre les deux dispositifs clients ; et

o identifier et exécuter au moins partiellement une règle d'exécution d'une opération annexe mémorisée dans la base de données selon des données reçues.

Le dispositif selon l'invention offre ainsi la possibilité d'effectuer des dons lors d'un paiement sur terminal de paiement sans modification des logiciels de caisse et des systèmes informatiques comptables équipant les commerçants. Seul l'ajout d'un module de traitement de données issues de la chaîne de paiement est nécessaire, sans modification de cette dernière. Ce module est typiquement ajouté à un équipement de la chaîne de paiement, par exemple un équipement d'une banque émettrice d'une carte de paiement utilisée pour le paiement, sans modification des flux de paiement. Les coûts d'implantation informatique d'une telle solution ainsi que la fiabilité de la solution sont donc avantageux.

La collecte de dons est particulièrement rapide du fait qu'elle est totalement transparente, pour le débiteur et le créditeur, au moment de l'exécution de la transaction principale. Les hôtesses de caisse ne sont pas sollicitées pour collecter des dons.

En outre, l'installation du dispositif selon l'invention est particulièrement simple. De plus, il permet un réel contrôle et une réelle traçabilité des dons.

Selon un mode de réalisation particulier, le dispositif comprend en outre un module de configuration, le module de configuration permettant la mémorisation dans ladite base de données et le paramétrage de règles d'exécution d'opérations annexes.

Selon un mode de réalisation particulier, le dispositif comprend en outre une interface de communication d'acquisition de données configurée pour recevoir des données dudit dispositif tiers.

Selon un mode de réalisation particulier, ladite interface de communication d'acquisition de données est unidirectionnelle.

Selon un mode de réalisation particulier, le dispositif comprend en outre une interface de communication de configuration configurée pour permettre à un utilisateur de saisir, paramétrer ou modifier une règle d'exécution d'opérations annexes.

Selon un mode de réalisation particulier, ladite interface de communication de configuration offre un accès Internet à un dispositif distant.

Selon un mode de réalisation particulier, le dispositif comprend en outre une interface de communication configurée pour transmettre des données vers ledit ensemble de paiement bancaire lors de l'exécution d'une opération annexe.

D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 illustre schématiquement un environnement dans lequel peut être mis en œuvre un mécanisme de collecte de dons permettant à un client d'effectuer un micro-don lors d'un achat, par exemple un don de la différence entre le prix à payer et ce prix arrondi à l'entier supérieur ;

- la figure 2 illustre schématiquement un premier exemple d'environnement dans lequel peut être mis en œuvre un mode de réalisation particulier de l'invention ;

- la figure 3 illustre schématiquement un système de gestion d'opérations annexes ;

- la figure 4 illustre schématiquement un second exemple d'environnement dans lequel peut être mis en œuvre un mode de réalisation particulier de l'invention ; et

- la figure 5 illustre un exemple de dispositif de traitement d'informations adapté à mettre en œuvre, au moins partiellement, un mode de réalisation de l'invention.

Selon un mode particulier de mise en œuvre de l'invention, un mécanisme de commande d'opérations annexes liées à l'exécution de transactions principales, mis en œuvre par ordinateur, par exemple un mécanisme de collecte de dons, fait appel à un système spécifique relié à un système d'exécution de transactions principales pour recevoir des données de celui-ci, sans interagir avec ce système d'exécution de transactions principales.

Ainsi, le système d'exécution de transactions principales n'est que peu modifié, uniquement pour transmettre des informations relatives à l'exécution de transactions principales.

Une transaction composite comprend ici une transaction principale et au moins une opération annexe dont l'exécution résulte automatiquement de celle de la transaction principale. De telles opérations annexes visent typiquement des montants et des bénéficiaires différents de ceux de la transaction principale. Il est rappelé qu'une transaction est une opération commerciale visant, pour la partie faisant l'objet d'un mode de réalisation particulier de l'invention, un transfert d'une somme monétaire entre un débiteur et un créditeur. A titre d'illustration, une transaction composite peut comprendre le règlement d'un achat (transaction principale) combiné à un don (opération annexe).

Selon un mode de réalisation particulier, la gestion des dons est essentiellement confiée à un système informatique particulier ayant pour objet la gestion de demandes de dons et la gestion des dons eux-mêmes. Ce système informatique de gestion de demandes de dons et de gestion des dons eux-mêmes est appelé système de gestion d'opérations annexes. Il s'agit, par exemple d'un système informatique mis en œuvre par un serveur connecté à un serveur bancaire.

Il est rappelé ici que le modèle connu, en monétique, sous le nom de modèle à quatre coins comprend une carte de paiement d'un porteur, un terminal de paiement d'un commerçant, la banque du commerçant et la banque du porteur, les deux banques étant connectées l'une à l'autre via des réseaux d'autorisations aussi appelés réseau d'intermédiation bancaire.

Selon ce modèle à quatre coins, un client pourvu d'une carte de paiement, par exemple une carte de type Visa (Visa est une marque), peut régler un achat auprès d'un commerçant disposant d'un terminal de paiement. La carte de paiement est associée à un compte bancaire (compte client) géré par un système informatique d'une banque (typiquement la banque ayant émis la carte bancaire ou pour le compte de laquelle la carte bancaire a été émise). De même, le terminal de paiement est associé à un compte bancaire (compte commerçant) géré par un système informatique d'une banque.

Pour effectuer une transaction d'achat, un client présente sa carte de paiement à un terminal de paiement d'un commerçant auquel le montant a été transmis de façon manuelle ou automatique. Après validation de l'achat par le client, par exemple en saisissant un code confidentiel ou code PIN (acronyme de Personal Identification Number en terminologie anglo-saxonne), le terminal de paiement effectue généralement une demande d'autorisation qui est transmise au système informatique de la banque du porteur de carte via le système informatique de la banque du commerçant et un réseau d'intermédiation bancaire. Le message est avantageusement crypté et comprend les identifiants du client et du commerçant ainsi que le montant devant être transféré.

Après authentification et vérification, notamment de l'identité du client et de celle du commerçant ainsi que du solde du compte débiteur, un message d'acceptation de transfert, de préférence crypté, est adressé par le système informatique de la banque du client au système informatique de la banque du commerçant.

Après avoir reçu un message d'acceptation de transfert, un message de crédit est transmis par le système informatique de la banque du commerçant à l'adresse du système informatique de la banque gérant le compte bancaire auquel est associée la carte de paiement utilisée via le réseau d'intermédiation bancaire. Ce message est de préférence crypté.

Il est observé ici que les demandes d'intermédiations bancaires peuvent être accumulées et effectuées de façon différée. Le réseau d'intermédiation bancaire peut être, par exemple, le réseau d'intermédiation bancaire MasterCard, Visa, GI E Carte Bancaire, SWI FT, STET ou Target 2 (MasterCard, Visa, GI E Carte Bancaire, SWI FT, STET et Target 2 sont des marques).

Le compte du commerçant est alors crédité de la somme transférée tandis que le compte du client est débité de la même somme, typiquement de façon différée.

Le cryptage utilisé pour les échanges de données est, par exemple, basé sur un algorithme standard de cryptage utilisant une clé publique et une clé privée, par exemple un cryptage de type RSA (sigle de Ronald Rivest, Adi Shamir et Léonard Adleman).

Selon leur nature et/ou selon les dispositifs sources et/ou destinataires, seuls certains échanges peuvent être cryptés.

Dans un tel modèle standard à quatre coins, une transaction principale ne peut pas commander une ou plusieurs opérations annexes indépendantes, notamment des dons, sans modifications substantielles des systèmes informatiques de la banque du commerçant et de ceux de la banque gérant le compte bancaire auquel est associée la carte de paiement utilisée.

Conformément à un mode de réalisation particulier, un système informatique particulier est associé à un serveur bancaire pour collecter des informations relatives à l'exécution de transactions effectuées par un porteur de carte et commander des opérations annexes, notamment des opérations de dons, sans modifier le traitement des transactions.

La figure 2 illustre schématiquement un premier exemple d'environnement 200 dans lequel peut être mis en œuvre un mode de réalisation particulier de l'invention, basé sur le modèle à quatre coins.

Comme illustré, un porteur d'une carte de paiement 205 peut effectuer un paiement auprès d'un terminal de paiement 210 lui-même relié à un système informatique bancaire 215 de la banque d'un commerçant. Ce système informatique bancaire 215 peut à son tour, via un réseau d'intermédiation bancaire 220, entrer en contact avec un système informatique bancaire 225 de la banque ayant émis la carte de paiement utilisée.

Le système informatique bancaire 225 est connecté, via le réseau d'intermédiation bancaire 220, à un système informatique bancaire 230 d'une banque gérant un compte du porteur de la carte de paiement utilisée, sur lequel doit être prélevé le montant des achats effectués. Il est également connecté à un serveur 235 mettant en œuvre un système de gestion d'opérations annexes.

Comme illustré, le serveur 235 mettant en œuvre un système de gestion d'opérations annexes est lui-même relié, via le réseau d'intermédiation bancaire 220, au système informatique bancaire 230 d'une banque gérant un compte du porteur de la carte de paiement utilisée, sur lequel doit être prélevé le montant des dons effectués et à un système informatique bancaire 240 d'une banque gérant un compte associé à une ou plusieurs opérations annexes devant être effectuées (par exemple un compte d'une ONG à destination de qui sont effectués des dons).

II est observé ici que si le système informatique bancaire de la banque gérant un compte sur lequel doit être prélevé le montant des achats effectués est le même que le système informatique bancaire de la banque gérant un compte sur lequel doit être prélevé le montant des dons effectués, ces systèmes et/ou ces comptes peuvent être différents.

Le système informatique bancaire 225 de la banque ayant émis la carte de paiement utilisée est, de préférence, différent du système informatique bancaire 230 de la banque gérant un compte du porteur de la carte de paiement utilisée, sur lequel doit être prélevé le montant des dons effectués.

Les protocoles de communication entre ces différents systèmes informatiques bancaires sont, de préférence, choisis parmi des protocoles standard, par exemple les protocoles IP (sigle d ^! Internet Protocol en terminologie anglo-saxonne) et X.25.

Le réseau d'intermédiation bancaire 220 est, par exemple le réseau d'intermédiation bancaire MasterCard, Visa, GIE Carte Bancaire, SWIFT, STET ou Target 2.

Le contrôle d'opérations annexes est ici effectué à l'aide d'un identifiant associé à la carte de paiement utilisée et d'un système de gestion d'opérations annexes mis en œuvre dans le système informatique 235 relié au système informatique bancaire 225 de la banque ayant émis la carte de paiement utilisée.

Le lancement et le contrôle d'opérations annexes peut se décomposer en deux phases, une phase de configuration et une phase d'utilisation.

Durant la phase de configuration (notée ® sur la figure 2), le porteur de la carte 205 vient configurer des caractéristiques qui lui sont propres (pouvant être regroupées sous forme d'un profil) dans le système informatique 235 relié au système informatique bancaire 225 de la banque ayant émis la carte de paiement utilisée.

Une telle configuration consiste par exemple à déterminer des règles pour calculer des montants de dons et indiquer les destinataires.

Cette phase de configuration est décrite plus en détails en référence à la figure 3.

La phase d'utilisation vise directement le lancement et le contrôle d'opérations annexes suite à l'exécution d'une transaction principale. Lors de l'exécution d'une transaction principale, par exemple pour effectuer un achat d'un montant M, un client présente sa carte de paiement 205 à un terminal de paiement 210 d'un commerçant auquel le montant M a été transmis de façon manuelle ou automatique. Après validation de l'achat par le client (étape ©), par exemple en saisissant un code confidentiel ou code PIN (acronyme de Personal Identification Number en terminologie anglo-saxonne), le terminal de paiement 210 effectue ici une demande d'autorisation (étape ©) qui est transmise au système informatique bancaire 225 de la banque ayant émis la carte de paiement utilisée (étape ®), avec le montant M, via le système informatique 215 de la banque du commerçant et le réseau d'intermédiation bancaire 220.

Le message est avantageusement crypté et comprend les identifiants du client et du commerçant ainsi que le montant devant être transféré.

Après authentification et vérification, notamment de l'identité du client et de celle du commerçant ainsi que des seuils de montants autorisés par la carte de paiement utilisée, un message d'acceptation de transfert (noté ack), de préférence crypté, est adressé par le système informatique bancaire 225 de la banque ayant émis la carte de paiement utilisée au système informatique 215 de la banque du commerçant puis au terminal de paiement 210 (étapes © et ©).

Après avoir reçu un message d'acceptation de transfert, un message de débit est transmis par le système informatique 215 de la banque du commerçant à l'adresse du système informatique bancaire 225 de la banque ayant émis la carte de paiement utilisée (étape ©) via le réseau d'intermédiation bancaire 220. Ce message est de préférence crypté.

Un message de débit est alors transmis par le système informatique bancaire 225 de la banque ayant émis la carte de paiement utilisée à l'adresse du système informatique bancaire 230 d'une banque gérant un compte du porteur de la carte de paiement utilisée, sur lequel doit être prélevé le montant des achats effectués (étape ®), via le réseau d'intermédiation bancaire 220. A nouveau, ce message est de préférence crypté. Il est observé ici que les demandes d'intermédiations bancaires peuvent être accumulées et effectuées de façon différée. De même, les opérations de crédit et/ou débit peuvent être accumulées et effectuées de façon différée.

Le compte du commerçant est alors crédité de la somme transférée tandis que le compte du client est débité de la même somme, typiquement de façon différée, hors commission (par exemple une commission de commerçant ou une commission de paiement international).

Le cryptage utilisé pour les échanges de données est, par exemple, un cryptage utilisant une clé publique et une clé privée, par exemple un cryptage de type RSA.

Le système informatique bancaire 225 de la banque ayant émis la carte de paiement utilisée tient ici un journal de compte comprenant des informations relatives à chaque transaction principale effectuée, par exemple le montant et un identifiant associé à la carte de paiement utilisée (mais ne permettant pas, de préférence, de reconstituer le numéro de la carte de paiement utilisée (ce numéro de carte permettant d'effectuer des achats)).

Des informations de ce journal de compte sont, pour chaque carte de paiement gérée par le système informatique bancaire correspondant, transmises au système informatique 235 mettant en œuvre un système de gestion d'opérations annexes (étape ®), typiquement un module logiciel. Elles peuvent être transmises pour chaque transaction principale ou par lots, de façon périodique.

Ces informations sont utilisées pour déterminer, à partir de la configuration effectuée par le porteur de la carte considérée, les opérations annexes devant être effectuées, c'est-à-dire, par exemple, calculer un montant de dons et identifier le destinataire des dons.

Le système de gestion d'opérations annexes est décrit plus en détails en référence à la figure 3.

Comme illustré schématiquement sur la figure 2, un versement peut être effectué de façon standard par la transmission d'un message de débit du système informatique 235 mettant en œuvre un système de gestion d'opérations annexes à l'adresse du système informatique bancaire 230 d'une banque gérant un compte du porteur de la carte de paiement utilisée, sur lequel doit être prélevé le montant des achats et/ou des dons effectués, et par la transmission d'un message de crédit du système informatique 235 mettant en œuvre un système de gestion d'opérations annexes à l'adresse du système informatique bancaire 240 d'une banque gérant un compte du ou des destinataires du don (étapes ® et ®'), via le réseau d'intermédiation bancaire 220.

Selon un mode de réalisation particulier, le versement de dons (crédit et débit) est effectué par lot pour un ensemble de dons (i.e. une somme de dons∑D). Le versement de dons accumulés est avantageusement effectué à l'aide d'un compte particulier géré par un tiers, par exemple par l'entité en charge du système de gestion d'opérations annexes, aussi appelé compte pivot.

La figure 3 illustre schématiquement un système de gestion d'opérations annexes pouvant être mis en œuvre, par exemple, dans un système informatique connecté à un système informatique bancaire d'une banque ayant émis une carte de paiement permettant d'exécuter des opérations annexes, par exemple le système informatique 235 de la figure 2.

Comme illustré, le système de gestion d'opérations annexes 300 comprend essentiellement trois modules 305, 31 0 et 31 5 ainsi qu'une base de données 320. Le module 305 est un module de configuration, le module 310 est un module d'acquisition et de gestion des opérations annexes par exemple de gestion de dons, et le module 31 5 est un module de calcul, par exemple de calcul de dons.

Selon un mode de réalisation particulier, les modules 305, 310 et 31 5 sont indépendants les uns des autres.

Comme illustré, le système de gestion d'opérations annexes 300 comprend ici les interfaces de communication 325, 330 et 335.

L'interface de communication 325 permet à un utilisateur d'interagir avec le module de configuration 305. Il s'agit, par exemple, d'une interface de communication locale (pour un accès à partir d'un équipement informatique mettant en œuvre le système de gestion d'opérations annexes 300) ou distante (pour un accès à partir d'un équipement informatique distant via un réseau de communication). L'interface de communication 325 offre, de préférence, des moyens de codage permettant de crypter les données échangées.

Le module de configuration 305 comprend avantageusement une interface utilisateur coopérant avec l'interface de communication 325 pour permettre à un porteur d'une carte gérée par le gestionnaire du système de gestion d'opérations annexes 300 d'entrer et paramétrer des règles relatives à des opérations annexes. Ces règles peuvent être mémorisées sous forme de tables dans la base de données 320.

L'accès au module peut, selon un mode de réalisation particulier, être effectué à partir d'un ordinateur distant, à l'aide d'une connexion telle qu'Internet. Cet accès est, de préférence, protégé par un identifiant et un mot de passe préalablement remis au titulaire de la carte, de façon classique.

La table 1 , présentée en annexe, illustre un exemple de règles relatives à des opérations annexes, ici des dons.

Chaque ligne de la table correspond ici à une règle. Selon l'exemple illustré, chaque règle est définie par un identifiant (colonne 1 ), un identifiant associé à une carte de paiement ou un groupe d'identifiants associés à des cartes de paiement (colonne 2), un mode de calcul de dons (colonne 3) et un identifiant d'un bénéficiaire ou un groupe d'identifiants de bénéficiaires (colonne 4).

Bien entendu, d'autres informations peuvent être utilisées dans la définition des règles. Ainsi, par exemple, l'identifiant associé à une carte de paiement peut être remplacé ou complété par un identifiant de client et/ou un identifiant de contrat.

Comme indiqué précédemment, un identifiant associé à une carte de paiement ne correspond pas, de préférence, au numéro de la carte de paiement. Selon un mode de réalisation particulier, un tel identifiant ne permet pas d'utiliser la carte pour effectuer un paiement.

Lorsqu'un groupe de bénéficiaires est désigné, la répartition d'un don entre ces derniers est, de préférence, prédéterminée. Ainsi, par exemple, la règle ayant l'identifiant 2 s'applique à la carte de paiement ou au groupe de cartes de paiement ayant la référence G53391 , les bénéficiaires étant pour une première moitié d'un don un bénéficiaire ayant l'identifiant 1 et pour la seconde moitié du don un bénéficiaire ayant l'identifiant 2. Le montant du don est ici déterminé en fonction du montant des achats (0,5%) ou de façon forfaitaire (5€), la plus petite valeur étant retenue.

Comme décrit précédemment, le paramétrage de ces règles peut se faire par un accès protégé au système de gestion d'opérations annexes 300. A titre d'illustration, un porteur de carte de paiement peut accéder, à l'aide d'un identifiant qui lui est propre ou d'une référence de sa carte de paiement et d'un mot de passe, à l'ensemble des règles associées à cet identifiant ou à cette référence, c'est-à-dire à un sous-ensemble des règles mémorisées. L'accès aux règles permet d'ajouter, modifier ou supprimer des règles. L'accès peut se faire depuis un ordinateur quelconque, une tablette, un smartphone ou tout autre dispositif similaire connecté au système de gestion d'opérations annexes 300 via un réseau de communication tel qu'Internet et via un portail de type web.

Le module 31 0 d'acquisition et de gestions des opérations annexes, par exemple de gestion de dons, reçoit des données reçues du système informatique bancaire de la banque ayant émis la carte de paiement utilisée (typiquement le système informatique sur lequel est implémenté le système de gestion d'opérations annexes 300) via l'interface de communication 330. Ces données, issues d'un journal de comptes, comprennent typiquement un identifiant associé à la carte de paiement ainsi qu'un ou plusieurs montants. Elles peuvent être reçues par le module 310 de façon périodique, par exemple de façon quotidienne ou hebdomadaire, ou sur requête.

Les données reçues peuvent être mémorisées dans la base de données 320 pour être traitées par le module de calcul 31 5 ou être directement adressées à ce dernier.

L'interface de communication 330 est, par exemple, une interface de communication locale (pour un accès à partir d'un équipement informatique mettant en œuvre le système de gestion d'opérations annexes 300) ou distante (pour un accès à partir d'un équipement informatique disant via un réseau de communication). L'interface de communication 330 offre, de préférence, des moyens de codage permettant de crypter les données échangées. L'interface de communication 330 est avantageusement unidirectionnelle pour permettre la réception de données d'un système informatique bancaire sans autoriser la transmission de données vers ce système, garantissant ainsi, vis-à-vis du module 310 d'acquisition et de gestion d'opérations annexes, l'intégrité des données gérées par le système informatique bancaire auquel il est connecté.

Le module 310 d'acquisition et de gestion des opérations annexes gère les résultats fournis par le module 315 de calcul.

Le module 315 de calcul utilise les règles associées à un identifiant associé à la carte de paiement considérée, typiquement un identifiant reçu par le module d'acquisition et de gestion des opérations annexes, mémorisées ici dans la base de données 320, pour déterminer les opérations annexes à effectuer.

Selon un mode de réalisation particulier, le module 315 effectue une partie des opérations annexes à effectuer, telle que les calculs visés sans les règles, par exemple les calculs de montants de dons.

Les résultats obtenus par le module 315 sont, de préférence, mémorisés dans la base de données 320, par exemple sous forme de journaux de résultats, par exemple de journaux de dons.

Un tel journal comprend, par exemple, pour chaque transaction effectuée, comme illustré dans la table 2 donnée en annexe, une référence de transaction (colonne 1 ), un identifiant de carte de paiement (colonne 2), un montant d'achat (colonne 3), un montant d'un ou plusieurs dons effectués et le ou les bénéficiaires associés (colonne 4), étant observé que le montant d'un don peut être réparti entre plusieurs bénéficiaires.

Un journal des dons peut comprendre d'autres informations telles qu'un identifiant du commerçant associé à la transaction ayant conduit aux dons considérés. En outre, le journal des dons peut comprendre le montant T du paiement, représentant la somme du montant M d'achats et du montant des dons correspondant. A titre d'illustration, la ligne du journal visant la transaction identifiée par la référence 2 correspond à une transaction effectuée par une carte de paiement référencée G53391 , le montant des achats effectués étant de 87,45€ et le montant du don de 0,44€ se répartissant à parts égales entre les bénéficiaires identifiés par les références 1 et 2.

Les journaux de résultats sont accédés de façon périodique, par exemple tous les mois, par le module 31 0 d'acquisition et de gestion des opérations annexes.

Dans le contexte de dons, le module 31 0 détermine, par exemple, le total des dons associés à une carte de paiement afin de débiter un compte du porteur de la carte et créditer le ou les comptes désignés comme destinataires.

Ces opérations de débit et de crédit sont réalisées selon un schéma standard tel que ceux décrits précédemment, à l'aide de l'interface de communication 335. A titre d'illustration, l'interface de communication 335 offre un accès vers et depuis un réseau d'intermédiation bancaire.

Il est observé ici que les opérations de débit et de crédit sont particulièrement simples à mettre en œuvre pour un sous-traitant bancaire. Selon un mode de réalisation particulier, les journaux de résultats sont conservés, avec une indication précisant que les opérations correspondantes de débit et crédit ont été effectuées, pour permettre, par exemple, d'éditer des relevés de dons pouvant être notamment utilisés à des fins fiscales. De tels relevés sont typiquement édités sur requête, par exemple en utilisant le module 305 de configuration qui peut comprendre des outils de consultation.

La figure 4 illustre schématiquement un second exemple d'environnement 400 dans lequel peut être mis en œuvre un mode de réalisation particulier de l'invention, basé sur le modèle connu sous le nom de modèle à trois coins.

Il est rappelé ici que, selon ce modèle de paiement par carte bancaire, un système informatique bancaire unique est impliqué pour le traitement d'une transaction. Il y a une séparation entre la gestion du système des cartes de paiement et les tenues des comptes débités et crédités. Le système informatique bancaire unique passe par des systèmes de compensation et de règlement pour créditer les commerçants et débiter les porteurs.

Comme illustré sur la figure 4, un porteur d'une carte de paiement 405 peut effectuer un paiement auprès d'un terminal de paiement 410 lui-même relié à un système informatique bancaire unique 415. Ce système informatique bancaire unique 415 peut à son tour, via un réseau d'intermédiation bancaire 420, entrer en contact avec un système informatique bancaire 425 de la banque du commerçant et avec un système informatique bancaire 430 de la banque du porteur de la carte utilisée.

Enfin, le système informatique bancaire unique 415 est connecté à un système informatique 435 mettant en œuvre un système de gestion d'opérations annexes.

Comme illustré, le système informatique 435 est lui-même relié, via le réseau d'intermédiation bancaire 420, au système informatique bancaire 430 d'une banque gérant un compte du porteur de la carte de paiement utilisée, sur lequel doit être prélevé le montant des dons effectués, ainsi qu'à un système informatique bancaire 440 d'une banque gérant un compte associé à une ou plusieurs opérations annexes devant être effectuées, par exemple un compte d'une ONG.

Les protocoles de communication entre ces différents systèmes informatiques bancaires sont, de préférence, choisis parmi des protocoles standard, par exemple les protocoles IP et X.25.

Le réseau d'intermédiation bancaire 420 est, par exemple le réseau d'intermédiation bancaire MasterCard, Visa, GIE Carte Bancaire, SWIFT, STET ou Target 2.

Le système informatique bancaire unique 415 est, par exemple, un système informatique de type Amex (Amex est une marque).

Le contrôle d'opérations annexes est ici effectué à l'aide d'un identifiant associé à la carte de paiement utilisée et d'un système de gestion d'opérations annexes mis en œuvre dans un système informatique relié au système informatique bancaire unique. Selon l'exemple illustré sur la figure 4, le système informatique bancaire unique 415 est celui de la banque émettrice de la carte de paiement utilisée.

Comme décrit précédemment en référence à la figure 2, le lancement et le contrôle d'opérations annexes peut se décomposer en deux phases, une phase de configuration et une phase d'utilisation.

La phase de configuration (notée ® sur la figure 4) est similaire à celle décrite précédemment en référence à la figure 3. A nouveau, cette configuration consiste par exemple à déterminer des règles pour calculer des montants de dons et indiquer les destinataires.

La phase d'utilisation vise directement le lancement et le contrôle d'opérations annexes lorsqu'une transaction principale est effectuée.

Lors de l'exécution d'une transaction principale, par exemple pour effectuer un achat d'un montant M, un client présente sa carte de paiement 405 à un terminal de paiement 410 d'un commerçant auquel le montant M a été transmis de façon manuelle ou automatique. Après validation de l'achat par le client (étape ©), par exemple en saisissant un code confidentiel ou code PIN (acronyme de Personal Identification Number en terminologie anglo-saxonne), le terminal de paiement 410 effectue ici une demande d'autorisation au système informatique bancaire unique 415 (étape ©).

Le message est avantageusement crypté et comprend les identifiants du client et du commerçant ainsi que le montant devant être transféré.

Après authentification et vérification, notamment de l'identité du client et de celle du commerçant ainsi que des seuils de montants autorisés par la carte de paiement utilisée, un message d'acceptation de transfert (noté ack), de préférence crypté, est adressé par le système informatique bancaire unique 415 au terminal de paiement (étape ®).

Un message de crédit est alors transmis par le système informatique bancaire unique 415, via le réseau d'intermédiation bancaire 420, au système informatique 425 de la banque du commerçant (étape ©). De même, un message de débit est transmis par le système informatique bancaire unique 415, via le réseau d'intermédiation bancaire 420, au système informatique 430 d'une banque gérant un compte du porteur de la carte de paiement utilisée (étape ©).

Ces messages de débit et de crédit, visant un montant M, sont de préférence cryptés.

Il est observé ici que les demandes de débit et/ou de crédit peuvent être accumulées et effectuées de façon différée.

Le compte du commerçant est alors crédité de la somme transférée tandis que le compte du client est débité de la même somme, typiquement de façon différée, hors commission (par exemple une commission de commerçant ou une commission de paiement international).

Le cryptage utilisé pour les échanges de données est, par exemple, un cryptage utilisant une clé publique et une clé privée, par exemple un cryptage de type RSA.

Le système informatique bancaire unique, lié à la banque ayant émis la carte de paiement utilisée, tient ici un journal de compte comprenant des informations relatives à chaque transaction principale effectuée, par exemple le montant et un identifiant associé à la carte de paiement utilisée (mais ne permettant pas, de préférence, de reconstituer le numéro de la carte de paiement utilisée (ce numéro de carte permettant d'effectuer des achats)).

Des informations de ce journal de compte sont, pour chaque carte de paiement gérée par le système informatique bancaire unique 415, transmises à un système de gestion d'opérations annexes, typiquement un module logiciel, du système informatique 435 (étape ©). Elles peuvent être transmises pour chaque transaction principale ou par lots, de façon périodique.

Elles sont typiquement utilisées pour déterminer, à partir de la configuration effectuée par le porteur de la carte considérée, les opérations annexes devant être effectuées, c'est-à-dire, par exemple, calculer un montant de dons et identifier le destinataire des dons.

Ce système de gestion d'opérations annexes peut être similaire à celui décrit précédemment en référence à la figure 3. Comme illustré schématiquement sur la figure 4, un versement de dons peut être effectué par le système de gestion d'opérations annexes du système informatique 435, de façon standard, par la transmission d'un message de débit à l'adresse du système informatique bancaire 430 de la banque gérant un compte du porteur de la carte de paiement utilisée, sur lequel doit être prélevé le montant des dons effectués, et par la transmission d'un message de crédit à l'adresse du système informatique bancaire 440 d'une banque gérant un compte du destinataire des dons (étapes ® et ®'). Les opérations de débit et de crédit sont ici effectuées via le réseau d'intermédiation bancaire 420.

Lorsqu'il existe plusieurs destinataires pour les dons, plusieurs messages de crédit sont émis.

Selon un mode de réalisation particulier, le versement de dons (crédit et débit) est effectué par lots pour un ensemble de dons (i.e. une somme de dons ∑D). A nouveau, le versement de dons accumulés est avantageusement effectué à l'aide d'un compte pivot.

La figure 5 illustre un exemple de dispositif pouvant être utilisé pour mettre en œuvre, au moins partiellement, un mode de réalisation, notamment des étapes décrites en référence aux figures 2, 3 et 4. Le dispositif 500 est par exemple un serveur, un ordinateur ou un assistant personnel.

Le dispositif 500 comporte de préférence un bus de communication 502 auquel sont reliés :

- une unité centrale de traitement ou microprocesseur 504 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ;

- une mémoire morte 506 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter le système d'exploitation et des programmes tels que "Prog" ;

- une mémoire vive ou mémoire cache 508 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; - un lecteur 510 de support amovible de stockage 512 tel qu'une carte mémoire ou un disque, par exemple un disque DVD ; et

- une carte graphique 514 reliée à un écran 516.

Optionnellement, le dispositif 500 peut également disposer des éléments suivants :

- un disque dur 520 pouvant comporter les programmes "Prog" précités et des données traitées ou à traiter selon l'invention ;

- un clavier 522 et une souris 524 ou tout autre dispositif de pointage comme un crayon optique, un écran tactile ou une télécommande permettant à l'utilisateur d'interagir avec les programmes selon l'invention, en particulier pour initier un transfert d'argent, configurer des règles de demandes de dons, suivre une ou plusieurs listes de dons et obtenir un reçu fiscal ; et

- une interface de communication 526 reliée à un réseau de communication distribué 528, par exemple le réseau Internet, l'interface étant apte à transmettre et à recevoir des données.

Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 500 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 500 directement ou par l'intermédiaire d'un autre élément du dispositif 500.

Le code exécutable de chaque programme permettant à l'appareil programmable de mettre en œuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 520 ou en mémoire morte 506.

Selon une variante, le code exécutable des programmes pourra être reçu par l'intermédiaire du réseau de communication 528, via l'interface 526, pour être stocké de façon identique à celle décrite précédemment.

De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 500 avant d'être exécutés.

L'unité centrale 504 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 520 ou dans la mémoire morte 506 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 520 ou la mémoire morte 506, sont transférés dans la mémoire vive 508 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en œuvre de l'invention.

Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente. La présente invention ne se limite pas aux formes de réalisation décrites, d'autres variantes et combinaisons de caractéristiques sont possibles.

En particulier, il est observé ici que si, dans un souci d'illustration, l'invention a été décrite selon des modes de réalisation particuliers, il existe d'autres variantes.

Ainsi, par exemple, l'invention peut être mise en œuvre dans un contexte de paiement via réseau, notamment de paiements par Internet tels que des paiements de type achats en ligne sécurisés ou de type m-POS (acronyme de mobile Point of Sale en terminologie anglo-saxonne).

De même, toujours à titre d'illustration, l'invention peut être mise en œuvre lors d'opérations de type retrait (un don étant effectué pour chaque retrait, selon certains seuils ou non).

La présente invention a été décrite et illustrée dans la présente description détaillée en référence aux figures jointes. Toutefois, la présente invention ne se limite pas aux formes de réalisation présentées. D'autres variantes et modes de réalisation peuvent être déduits et mis en œuvre par la personne compétente dans le domaine de l'invention à la lecture de la présente description et des figures annexées.

Dans les revendications, le terme « comporter » n'exclut pas d'autres éléments ou d'autres étapes. L'article indéfini « un » n'exclut pas le pluriel. Un seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en œuvre l'invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes n'exclut pas, en effet, la possibilité de les combiner. Les signes de référence ne sauraient être compris comme limitant la portée de l'invention.

ANNEXE

Table 1

Table 2