FR3025915A1 - Procedes et dispositifs de gestion de transactions composites - Google Patents

Procedes et dispositifs de gestion de transactions composites Download PDF

Info

Publication number
FR3025915A1
FR3025915A1 FR1458676A FR1458676A FR3025915A1 FR 3025915 A1 FR3025915 A1 FR 3025915A1 FR 1458676 A FR1458676 A FR 1458676A FR 1458676 A FR1458676 A FR 1458676A FR 3025915 A1 FR3025915 A1 FR 3025915A1
Authority
FR
France
Prior art keywords
transaction
ancillary
donation
initiating
parameter
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1458676A
Other languages
English (en)
Other versions
FR3025915B1 (fr
Inventor
Alancon Ghislain D
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Heoh
Original Assignee
Heoh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to FR1458676A priority Critical patent/FR3025915B1/fr
Application filed by Heoh filed Critical Heoh
Priority to EP15771997.2A priority patent/EP3195224A1/fr
Priority to CN201580056121.0A priority patent/CN107209887A/zh
Priority to BR112017004962-7A priority patent/BR112017004962A2/pt
Priority to MX2017003424A priority patent/MX2017003424A/es
Priority to AU2015316635A priority patent/AU2015316635A1/en
Priority to US15/511,037 priority patent/US20180225663A1/en
Priority to PCT/FR2015/052472 priority patent/WO2016042258A1/fr
Priority to US14/992,228 priority patent/US10776782B2/en
Publication of FR3025915A1 publication Critical patent/FR3025915A1/fr
Application granted granted Critical
Publication of FR3025915B1 publication Critical patent/FR3025915B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/209—Specified transaction journal output feature, e.g. printed receipt or voice output
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0279—Fundraising management

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Game Theory and Decision Science (AREA)
  • Marketing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Human Computer Interaction (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention a notamment pour objet la gestion de transactions composites comprenant une transaction principale et au moins une opération annexe dans un ensemble comprenant un dispositif (205) pour initier une transaction, un dispositif (215) pour proposer au moins une opération annexe selon des caractéristiques d'une transaction principale et un dispositif (220) de gestion d'opérations annexes, ledit dispositif pour proposer au moins une opération annexe étant accessible par une pluralité de dispositifs pour initier une transaction distincts et par une pluralité de dispositifs de gestion d'opérations annexes distincts.

Description

1 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 gestion de transactions composites, par exemple de transactions comprenant un paiement et un don à un organisme particulier, effectuées à 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 oeuvre 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 oeuvre 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 oeuvre 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 30 peut être mis en oeuvre 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.
3025915 2 Comme illustré, l'environnement 100 permet à un client 105 disposant d'une carte de paiement d'effectuer des achats auprès d'un commerçant disposant d'une infrastructure informatique 110. Outre cette infrastructure, l'environnement 100 comprend ici un système informatique 115 5 lié à une banque du commerçant, un système informatique (non représenté) lié à une banque du client et un système informatique 120 lié à une banque une organisation 125 de type ONG (sigle d'Organisation Non-Gouvernementale). L'infrastructure informatique 110 du commerçant comprend ici, en particulier, un système informatique comptable 130, un logiciel de caisse 135 10 associé à une caisse opérée par une hôtesse de caisse et un terminal de paiement 140. Le système informatique comptable 130 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 oeuvre le protocole IP (sigle d' Internet Protocol en terminologie anglo-saxonne).
15 Les systèmes informatiques liés aux banques sont reliés entre eux et au système informatique comptable 130 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 20 mis en oeuvre 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), d'un montant noté M, l'hôtesse de caisse lui demande s'il souhaite effectuer un don d'un montant noté D (étape CD). Si le client refuse, le 25 processus de paiement se poursuit de façon classique (non représenté). Au contraire, si le client accepte d'effectuer un don (étape 0), 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 saisi le montant du don à l'aide du logiciel de caisse (étape CY). Cette saisie est typiquement effectuée en ajoutant une référence particulière à la liste des références des produits 3025915 3 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 5 don est ainsi intégré au ticket de caisse dont le montant total indiqué, noté T, comprend le montant des achats réels (A//) et le montant du don (D). En d'autres termes, T= M+ D. Dans une étape suivante (étape ®), le montant total (T) indiqué sur le ticket de caisse, le montant des achats réels (A//) et le montant du don (D) 10 sont transmis par le logiciel de caisse 135 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 (T) au terminal de paiement 140. Alternativement, ce montant 15 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 ( T= Mou T= M 20 + D selon que le client ait effectué un don ou non) pour créditer un compte du commerçant d'un montant correspondant (étape 0). Parallèlement, le système informatique comptable 130 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 25 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).
30 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.
3025915 4 De tels versements sont typiquement effectués sur ordre du commerçant à sa banque, cette dernière exécutant l'ordre de transaction (étapes 0 et 0'). La ou les organisations disposent alors des dons versés pour effectuer leurs missions (étape 0).
5 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 oeuvre, 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 10 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 15 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 20 montant exact du chiffre d'affaire. Par ailleurs, il convient de noter que la mise en oeuvre 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 25 é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ù 30 un refus peut être mal considéré par une hôtesse de caisse ou un client situé à proximité lorsque la question est posée.
3025915 5 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.
5 Enfin, les modifications devant être apportées au logiciel de caisse et dans le système informatique comptable du commerçant sont très couteuses (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 10 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.
15 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 gestion d'une transaction composite comprenant une transaction principale et au moins une opération annexe, ce procédé étant mis en oeuvre dans un ensemble 20 comprenant un dispositif pour initier une transaction, un dispositif pour proposer au moins une opération annexe selon des caractéristiques d'une transaction principale et un dispositif de gestion d'opérations annexes, ledit dispositif pour proposer au moins une opération annexe étant accessible par une pluralité de dispositifs pour initier une transaction distincts et par une pluralité de dispositifs 25 de gestion d'opérations annexes distincts, ce procédé comprenant les étapes suivantes, - réception d'informations relatives à ladite transaction principale, lesdites informations étant reçues dudit dispositif pour initier une transaction par ledit dispositif pour proposer au moins une opération annexe ; 30 - estimation d'au moins un paramètre de ladite au moins une opération annexe, à partir d'au moins une règle prédéterminée, selon au moins une information reçue relative à ladite transaction principale, ladite étape 3025915 6 d'estimation étant mise en oeuvre dans ledit dispositif pour proposer au moins une opération annexe ; - en réponse à une indication d'acceptation de ladite au moins une opération annexe reçue dudit dispositif pour initier une transaction, transmission 5 audit dispositif de gestion d'opérations annexes de données comprenant au moins ledit au moins un paramètre de ladite au moins une opération annexe, ladite transaction principale étant gérée indépendamment desdites étapes de réception, estimation et transmission. Le procédé selon l'invention offre ainsi la possibilité d'effectuer des 10 dons lors d'un paiement sur terminal de paiement sans modification substantielle des logiciels de caisse et des systèmes informatiques comptables équipant des commerçants. Les coûts d'implantation informatique chez des commerçants ne sont donc pas significatifs (un même dispositif pour proposer au moins une opération annexe ou un même système de gestion de demande 15 de dons peut être utilisé par des systèmes de différents commerçants, des systèmes de différentes banques et/ou des systèmes de différents bénéficiaires de dons). La collecte de dons est particulièrement rapide du fait d'un nombre d'opérations pouvant se limiter à une seule saisie de type acceptation. En outre, 20 les hôtesses de caisse ne sont pas sollicitées pour collecter des dons. Le procédé de gestion de dons selon l'invention permet l'installation simplifiée chez un grand nombre de commerçants ainsi que le contrôle et la traçabilité des dons. Selon un mode de réalisation particulier, le procédé comprend en 25 outre une étape de sélection de ladite au moins une règle pour estimer ledit au moins un paramètre de ladite au moins une opération annexe. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de réception d'un identifiant dudit dispositif pour initier une transaction, ladite au moins une règle pour estimer ledit au moins un paramètre 30 de ladite au moins une opération annexe étant sélectionnée selon ledit identifiant dudit dispositif pour initier une transaction.
3025915 7 Selon un mode de réalisation particulier, le procédé comprend en outre une étape initiale de configuration d'au moins une règle pour estimer au moins un paramètre d'au moins une opération annexe. Selon un mode de réalisation particulier, lesdites données 5 transmises audit dispositif de gestion d'opérations annexes en réponse à une indication d'acceptation de ladite au moins une opération annexe comprennent en outre lesdites informations relatives à ladite transaction principale. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de transmission d'une commande d'impression audit dispositif 10 pour initier une transaction, ladite commande d'impression visant l'impression d'un reçu comprenant ledit au moins un paramètre de ladite au moins une opération annexe et ladite au moins une information reçue. Un client peut ainsi garder une preuve d'un don réalisé grâce à l'impression d'un ticket par un terminal de paiement qui comporte une 15 référence. Cette dernière permet l'identification de l'utilisateur sur un système informatique de gestion des dons permettant notamment d'accéder à un ensemble des dons déjà effectués et télécharger des reçus fiscaux. Selon un mode de réalisation particulier, ladite commande d'impression vise en outre l'impression d'une référence à un identifiant d'une 20 entité personnelle sur ledit reçu. Selon un mode de réalisation particulier, lesdites données comprenant au moins ledit au moins un paramètre de ladite au moins une opération annexe comprennent en outre ladite référence. Selon un mode de réalisation particulier, le procédé comprend en 25 outre une étape de mémorisation dudit au moins un paramètre de ladite au moins une opération annexe. Selon un mode de réalisation particulier, le procédé comprend en outre une étape pour générer une transaction basée sur au moins un paramètre préalablement mémorisé d'au moins une opération annexe.
30 Selon un mode de réalisation particulier, le procédé comprend en outre une étape pour générer un récapitulatif d'opérations annexes, ledit 3025915 8 récapitulatif comprenant au moins un paramètre préalablement mémorisé d'au moins une opération annexe. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de cryptage d'au moins une donnée transmise entre ledit 5 dispositif pour initier une transaction et ledit dispositif pour proposer au moins une opération annexe ou entre ledit dispositif pour proposer au moins une opération annexe et ledit dispositif de gestion d'opérations annexes. Selon un mode de réalisation particulier, le protocole de communication entre ledit dispositif pour initier une transaction et ledit dispositif 10 pour proposer au moins une opération annexe ou entre ledit dispositif pour proposer au moins une opération annexe et ledit dispositif de gestion d'opérations annexes est conforme à un standard de type IP. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des 15 étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur ainsi qu'un système comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment. Les avantages procurés par ce programme d'ordinateur et ce système sont similaires à ceux évoqués ci-avant.
20 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 oeuvre un mécanisme de collecte de dons permettant à 25 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 environnement dans lequel peut être mis en oeuvre un mode de réalisation particulier de l'invention ainsi que certaines étapes d'un exemple de procédé selon l'invention ; 30 - la figure 3 représente schématiquement un élément de terminal de paiement comprenant un écran sur lequel plusieurs choix de dons sont proposés à un utilisateur ; 3025915 9 - la figure 4 illustre schématiquement un exemple standard de paiement par carte de paiement dans une infrastructure comprenant une carte de paiement, un terminal de paiement ainsi que des systèmes informatiques bancaires liés au débiteur et au créditeur ; et 5 - la figure 5 illustre un exemple de dispositif de traitement d'informations adapté à mettre en oeuvre, au moins partiellement, un mode de réalisation de l'invention. Selon un mode particulier de mise en oeuvre de l'invention, un mécanisme de gestion de transactions composites mis en oeuvre par 10 ordinateur, par exemple un mécanisme de collecte de dons, fait appel à plusieurs dispositifs dont un ensemble de dispositifs tiers afin d'isoler au moins partiellement des éléments spécifiques de la gestion de transactions composites. Une transaction composite comprend ici une transaction principale et 15 au moins une opération annexe. Cette dernière ou ces dernières 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 20 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 25 essentiellement confiée à deux serveurs distincts, l'un ayant pour objet la gestion de demandes de dons, appelé système informatique de gestion de demandes de dons ou plus généralement dispositif pour proposer au moins une opération annexe, et l'autre la gestion des dons eux-mêmes, appelé système informatique de gestion des dons ou plus généralement dispositif de gestion 30 d'opérations annexes.
3025915 10 La figure 2 illustre schématiquement un environnement dans lequel peut être mis en oeuvre un mode de réalisation particulier de l'invention ainsi que certaines étapes d'un exemple de procédé selon l'invention. L'environnement 200 comprend ici un ensemble incluant un logiciel 5 de caisse 202, un terminal de paiement 205 (plus généralement appelé dispositif pour initier une transaction), un système informatique comptable 210, un système informatique de gestion de demandes de dons 215 et un système informatique de gestion des dons 220. Comme illustré, le logiciel de caisse 202, le terminal de paiement 205 et le système informatique comptable 210 10 appartiennent au commerçant 225. Le logiciel de caisse 202 et le terminal de paiement 205 ainsi que le logiciel de caisse 202 et le système informatique comptable 210 sont reliés par un réseau de communication privé ou public, par exemple un réseau Ethernet ou le réseau Internet.
15 Le terminal de paiement 205 est ici également relié au système informatique de gestion de demandes de dons 215, par exemple un réseau Ethernet ou le réseau Internet, permettant un échange de données en temps réel. Le système informatique de gestion de demandes de dons 215 et le 20 système informatique de gestion des dons 220 sont ici accessibles via un réseau de communication public, par exemple le réseau Internet, pour être accessibles par des systèmes informatiques de différents commerçants et de différents utilisateurs (i.e. clients). Les protocoles de communication entre ces différents dispositifs 25 sont, de préférence, choisis parmi des protocoles standard, par exemple les protocoles IP et X.25. Il est observé que si le système informatique de gestion de demandes de dons 215 et le système informatique de gestion des dons 220 sont typiquement des serveurs distincts, la gestion de demandes de dons et la 30 gestion des dons peuvent être effectuées par deux applications mises en oeuvre sur un même serveur, voire par une même application.
3025915 11 L'environnement 200 comprend en outre un réseau d'intermédiation bancaire 230, par exemple le réseau d'intermédiation bancaire MasterCard, Visa, GIE Carte Bancaire, SWIFT, STET ou Target 2 (MasterCard, Visa, GIE Carte Bancaire, SWIFT, STET et Target 2 sont des marques), ainsi que des 5 systèmes informatiques de gestion de comptes bancaires 235 à 250 associés respectivement à un client, au commerçant ayant le logiciel de caisse 202, le terminal de paiement 205 et le système informatique comptable 210, à un tiers en charge de la gestion de dons et à une organisation bénéficiaire de dons. Selon un mode de réalisation particulier, les données échangées 10 entre le logiciel de caisse 202, le terminal de paiement 205, le système informatique comptable 210, le système informatique de gestion de demandes de dons 215, le système informatique de gestion des dons 220, le réseau d'intermédiation bancaire 230 et les systèmes informatiques de gestion de comptes bancaires et de transactions 235 à 250 sont transmises sous forme de 15 messages cryptés à l'aide d'algorithmes standard, par exemple d'algorithmes basés sur l'utilisation de clés privées et de clés publiques, notamment d'algorithmes de type RSA (Ronald Rivest, Adi Shamir et Leonard Adleman), par paquets. Alternativement, seuls certains échanges sont cryptés selon leur nature et/ou selon les dispositifs sources et/ou destinataires.
20 Comme représentée sur la figure 2, une étape initiale (étape Co) a pour objet de configurer le système informatique de gestion de demandes de dons 215. Une telle configuration comprend notamment la définition d'une ou plusieurs règles associées à un ou plusieurs terminaux de paiement, typiquement tous les terminaux de paiement d'un même commerçant, 25 définissant une modalité de calcul de montant de dons et associant un don à un destinataire, par exemple une organisation de type ONG. Ces règles sont typiquement appliquées selon des paramètres reçus, par exemple selon une valeur reçue (e.g. montant d'une transaction), et/ou un identifiant du dispositif duquel sont reçues ces données (i.e. émetteur du 30 message comprenant ces données). Un exemple de telles règles est illustré en annexe sous forme de table (table 1). Comme illustré, chaque ligne de la table correspond à une règle.
3025915 12 Chaque règle est ici définie par un identifiant (colonne 1), un identifiant d'un terminal de paiement ou d'un groupe de terminaux de paiement (colonne 2), un mode de calcul de dons (colonne 3) et un identifiant d'un bénéficiaire ou d'un groupe de bénéficiaires (colonne 4).
5 Bien entendu, d'autres informations peuvent être utilisées dans la définition des règles. Lorsqu'un groupe de bénéficiaires est désigné, la répartition d'un don entre ces derniers peut être prédéterminée ou laissée à l'appréciation d'un utilisateur (pouvant notamment sélectionner un seul bénéficiaire dans le 10 groupe). Ainsi, par exemple, la règle ayant l'identifiant 2 s'applique au terminal de paiement ou au groupe de terminaux de paiement ayant l'identifiant 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 15 2. Le montant du don est ici déterminé en fonction du montant des achats (0,5%) ou de façon forfaitaire (5E), la plus petite valeur étant retenue. Le paramétrage de ces règles peut se faire par un accès protégé au système informatique de gestion de demandes de dons 215. A titre d'illustration, un commerçant peut accéder, à l'aide d'un identifiant d'un terminal 20 de paiement ou d'un groupe de terminaux de paiement et d'un mot de passe, à l'ensemble des règles associées à cet identifiant, 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 (ou équivalent) connecté au système informatique de gestion de demandes de 25 dons 215 via un réseau de communication tel qu'Internet et via un portail de type web. Lorsqu'un client se présente devant un terminal de paiement pour régler des achats et après que le montant M des achats ait été déterminé, par exemple par une hôtesse de caisse ou de façon automatique, et obtenu par le 30 terminal de paiement (étape 0), de façon manuelle ou automatique, un lien de communication ou une session de communication est établi entre le terminal de paiement 205 et le système informatique de gestion de demandes de dons 215.
3025915 13 Selon un mode de réalisation particulier, le lien de communication est établi automatiquement après saisi, obtention ou validation du montant M des achats. A ces fins, le terminal de paiement comprend une adresse du système informatique de gestion de demandes de dons 215, par exemple un 5 lien URL (sigle d' Uniform Resource Locator en terminologie anglo-saxonne) associé à une commande d'accès appelée dès qu'un montant est saisi, obtenu ou validé. Comme décrit précédemment, le système informatique de gestion de demandes de dons 215 peut être accédé de différents terminaux de paiement 10 gérés par différents commerçant, c'est-à-dire par différents terminaux de paiement n'ayant pas de liens entre eux. Suite à l'établissement du lien de communication entre le terminal de paiement 205 et le système informatique de gestion de demandes de dons 215, le montant M des achats ainsi qu'un identifiant du terminal de paiement et de la 15 transaction sont transmis par le terminal de paiement 205 au système informatique de gestion de demandes de dons 215 (étape 0). Alternativement, le montant M des achats ainsi que l'identifiant du terminal de paiement sont transmis sous forme d'un message à une adresse prédéterminée ou à une adresse déterminée dynamiquement, par exemple à 20 l'aide d'un mécanisme de type DNS (sigle de Domain Name System en terminologie anglo-saxonne). En réponse, le système informatique de gestion de demandes de dons 215 détermine la ou les règles de calcul de dons applicables, notamment en fonction de l'identifiant reçu du terminal de paiement, et calcule une ou 25 plusieurs valeurs de don. Cette ou ces valeurs sont alors transmises au terminal de paiement, chaque valeur étant associée à un bénéficiaire dénoté b (étape 0'). La ou les valeurs de dons ainsi que les bénéficiaires correspondants sont alors de préférence affichés sur un écran du terminal de paiement pour 30 permettre au client de valider une proposition de don, de sélectionner et valider une proposition de don parmi plusieurs, de saisir librement un montant de don ou de payer ses achats sans effectuer de don.
3025915 14 De façon avantageuse, la sélection ou le refus d'un don se fait par une seule pression sur une touche du terminal de paiement (ou d'un dispositif relié à ce dernier). Il est observé ici qu'au moins une partie des actions effectuées par 5 un terminal de paiement peuvent être déportées, par exemple sur un dispositif de type smartphone ou un site web, pour permettre à un utilisateur de visualiser et/ou valider des choix sur son propre dispositif. La figure 3 représente schématiquement un élément de terminal de paiement comprenant un écran sur lequel plusieurs choix de dons sont 10 proposés à un utilisateur. L'élément 300 de terminal de paiement comprend ici un ensemble 305 de touches et un écran 310. Comme représenté, l'écran affiche un message offrant la possibilité à un utilisateur d'effectuer un don de 0,54E à la Croix-Rouge ou aux Restos du Coeurs (la Croix-Rouge et les Restos du Coeurs sont des marques) ou de régler 15 ses achats sans effectuer de don. Comme indiqué avec les références 315, 320 et 325, respectivement, une pression sur la touche 1, référencée 330, a pour effet le versement d'un don de 0,54E à la Croix-Rouge, une pression sur la touche 2, référencée 335, a pour effet de verser un don de 0,54E aux Restos du Coeurs et pression sur la touche A, référencée 340, a pour effet de régler ses 20 achats sans effectuer de don. Après avoir validé ou refusé un don, l'utilisateur valide ses achats (étape 0) pour un montant total T correspondant au montant de ses achats auquel est ajouté le montant du don ( T = M+ D) ou correspondant uniquement au montant des achats ( T = M). Typiquement, lorsque le paiement des achats 25 est effectué à l'aide d'une entité électronique portable telle qu'une carte bancaire, la validation des achats est effectuée par la saisie d'un code confidentiel associé à la carte utilisée ou par tout autre moyen biotechnique (e.g. empreintes digitales). Alternativement, par exemple si le paiement est effectué par virement ou à l'aide d'un porte-monnaie électronique, la code 30 confidentiel peut être un code associé à un identifiant préalablement obtenue de l'utilisateur.
3025915 15 Le prélèvement du montant T sur le compte bancaire de l'utilisateur et le crédit d'un montant équivalent du compte bancaire du commerçant est avantageusement effectué de façon classique comme décrit en référence à la figure 4 (étape ®).
5 Parallèlement au paiement ou, de préférence, suite à la réception d'une autorisation de paiement, le terminal de paiement 205 adresse, le cas échéant, une indication d'acceptation de don au système informatique de gestion de demandes de dons 215, typiquement sous forme d'un message comprenant la ou les valeurs du don et le ou les bénéficiaires sélectionnés 10 (étape 0). En réponse, le système informatique de gestion de demandes de dons 215 retourne, de préférence, une commande d'impression d'un ticket contenant le détail de l'opération, c'est-à-dire le versement total effectué et sa répartition entre le paiement des achats et le don effectué (étape 0'). A la 15 réception de cette commande, le terminal de paiement imprime ce ticket qui est remis à l'utilisateur. Selon un mode de réalisation particulier, la commande d'impression d'un ticket est transmise avec une référence de carte (Rc) associé à la carte de paiement utilisée, cette référence de carte étant de préférence déterminée par 20 le terminal de paiement à partir d'un identifiant ou d'un numéro de carte (par exemple en appliquant une fonction de hachage sur le numéro de carte). Il est observé ici que, selon un mode de réalisation particulier, un identifiant de personne (IDp) est donnée à chaque utilisateur lors de son inscription sur le système informatique de gestion des dons 220 (l'inscription 25 comprenant typiquement la création d'un profil utilisateur). La référence de carte fournie sur le ticket peut être utilisée pour cette inscription qui peut être réalisée, par exemple, via une interface web. Pour éviter toute fraude, la création d'un profil peut être soumise à la fourniture d'informations supplémentaires, par exemple, outre la fourniture de la référence de carte, il 30 peut être demandé à l'utilisateur de donner les six derniers chiffres du numéro de la carte de paiement (à partir desquels pourra être générée une référence de carte qui sera comparée à celle reçue afin de la valider).
3025915 16 Un mot de passe est avantageusement associé à l'identifiant de personne pour sécuriser l'accès à des données relatives à ce donneur. Lorsqu'un donneur s'est inscrit sur le système informatique de gestion des dons 220, un profil est créé. Il comprend notamment la référence 5 de carte, d'autres références de cartes de paiement pouvant être associées à ce profil. Outre l'accès à son profil, l'identifiant de personne permet à un donneur de se connecter au système de gestion des dons 220, par exemple via une page web, et d'obtenir des informations relatives à l'historique des dons 10 effectués, télécharger les reçus fiscaux des montants des dons cumulés sur l'ensemble de ses cartes ou recevoir des informations émanant des associations bénéficiaires de sa générosité. L'identifiant de personnes et le profil associé ne sont connus, de préférence, que du système informatique de gestion des dons 220 (i.e., ils ne 15 sont pas connus du terminal de paiement 205 ni du système informatique de gestion de demandes de dons 215). Pour permettre au système informatique de gestion des dons 220 de gérer des dons, le terminal de paiement adresse, au système informatique de gestion de demandes de dons 215, une référence de la carte de paiement 20 utilisée avec l'indication d'acceptation de don. Avec cette référence de la carte, le système informatique de gestion des dons 220 peut retrouver un identifiant de personne préalablement créé (le système informatique de gestion des dons 220 mémorise les liens entre un identifiant de personne et une ou plusieurs références de carte, par exemple dans une table). Si aucun identifiant de 25 personne n'est trouvé, les données relatives au don sont mémorisées pour être traitées ultérieurement, après la création d'un profil d'utilisateur associé à la référence de carte correspondante. Suite à l'acceptation d'un don, le système informatique de gestion de demandes de dons 215 mémorise le montant des achats M ainsi que le 30 montant du don D effectués dans un journal de dons. Ce dernier comprend, pour chaque transaction effectuée, une référence de transaction, un identifiant d'un terminal de paiement ou d'un groupe de terminaux de paiement, une 3025915 17 référence Rc de carte de paiement, un montant M d'achats, un montant de don(s) effectué(s) et le ou les bénéficiaires associés (étant observé que le montant d'un don peut être réparti entre plusieurs bénéficiaires). Un exemple de journal de dons d'un système informatique de gestion 5 de demandes de dons est illustré en annexe (table 2). A titre d'illustration, la ligne du journal visant la transaction identifiée par la référence 2 correspond à une transaction effectuée à partir d'un terminal de paiement ou d'un groupe de terminaux de paiement identifiés par la référence G53391 pour le donneur ayant utilisé une carte ayant la référence 023, le montant des achats effectués 10 étant de 87,45E et le montant du don de 0,44E se répartissant à parts égales entre les bénéficiaires identifiés par les références 1 et 2. Outre un identifiant de transaction, un identifiant d'un terminal de paiement ou d'un groupe de terminaux de paiement, une référence Rc de carte de paiement, un montant M d'achats, un montant de don(s) effectué(s) et le ou 15 les bénéficiaires associés, le journal de dons peut, de façon optionnelle (non représentée), comprendre le montant T du paiement, représentant du somme montant M d'achats et du montant de don(s) effectué(s) réglés. Le journal de dons est transmis de façon périodique, par exemple toutes les heures ou toutes les nuits, au système informatique de gestion des 20 dons 220 (étape 0) où il est mémorisé. Après transmission au système informatique de gestion des dons, le journal de dons mémorisé dans le système informatique de gestion des dons 220 est réinitialisé (cependant une copie est, de préférence, conservée). Le système informatique de gestion des dons 220 analyse alors le 25 journal de dons pour en extraire les parties concernant un système informatique comptable particulier, par exemple le système informatique comptable 210, c'est-à-dire le système informatique comptable associé à un terminal de paiement ou à un groupe de terminaux de paiement. Les parties extraites concernant un système informatique comptable particulier sont ici transmises à 30 ce dernier pour lui permettre d'effectuer un rapprochement comptable (étape 0).
3025915 18 De façon périodique, par exemple toutes les semaines ou tous les mois, le système informatique de gestion des dons 220 calcule, pour un système informatique comptable particulier, la somme des dons effectués par des clients auprès de terminaux de paiement associés à celui-ci, dénoté ID. Ce 5 calcul est effectué à partir du journal d'achat, en cumulant les dons associés à un même terminal de paiement ou à un même groupe de terminaux de paiement. Une demande de prélèvement ou de règlement de ce montant est alors adressée à ce système informatique comptable pour créditer de ce montant un compte bancaire associé au système informatique de gestion des 10 dons (étape ®). Le prélèvement ou le règlement de cette somme de dons sur un compte bancaire associé à un système informatique comptable et le crédit d'un montant équivalent du compte bancaire associé au système informatique de gestion des dons est avantageusement effectué de façon classique de façon 15 similaire à un processus de paiement d'un fournisseur. Dans une étape suivante, le système informatique de gestion des dons 220 calcule, pour chaque bénéficiaire, la somme des dons à lui reverser. A nouveau, ce calcul est effectué à partir du journal de dons, en cumulant les dons associés à un même bénéficiaire.
20 Le journal de dons mémorisé dans le système informatique de gestion des dons 220 est de préférence mis à jour suite au transfert de dons. Cependant, un historique est conservé pour permettre la traçabilité des dons et l'établissement, le cas échéant, de relevés fiscaux. Ainsi, par exemple, le système informatique de gestion des dons 220 25 calcule, pour un utilisateur particulier, pour certains ou pour tous les utilisateurs, la somme des dons versés durant une période donnée, typiquement une année fiscale. A nouveau, ce calcul est effectué à partir du journal de dons, en cumulant les dons associés à un même utilisateur. La gestion de transactions composites et, en particulier, de dons 30 adossés à des achats, nécessite la création de systèmes informatiques tiers auxquels peuvent faire appel des commerçants et des clients ainsi que le 3025915 19 développement d'interfaces particulières permettant l'accès à ces systèmes informatiques. Ainsi, par exemple, la mise en oeuvre de la solution décrite en référence à la figure 2 nécessite la création d'un système informatique de 5 gestion de demandes de dons et d'un système informatique de gestion de dons ainsi que la création d'interfaces. Parmi ces dernières et pour permettre la mise en oeuvre de la solution décrite en référence à la figure 2, les interfaces suivantes sont créées : - interface d'échange sécurisé de données, en temps réel, entre un 10 logiciel d'un terminal de paiement et un logiciel du système informatique de gestion de demandes de dons ; - interface d'échange sécurisé de données entre un logiciel du système informatique de gestion de demandes de dons et un logiciel du système informatique de gestion de dons, 15 - interface de paramétrage du système informatique de gestion de demandes de dons (typiquement à l'aide d'un système informatique d'un commerçant pour configurer des règles de demandes de dons via une page web) ; - interface d'interrogation du système informatique de gestion de 20 dons (typiquement à l'aide d'un système informatique d'un utilisateur pour paramétrer son identité, inscrire ses cartes, modifier son profil et/ou accéder à des relevés de dons via une page web) ; et - une interface d'échange standard entre le système de gestion des dons et le système informatique comptable du commerçant.
25 Selon un mode de réalisation particulier, les interfaces d'échange de données sont basées sur des protocoles de communication usuels et utilisent des algorithmes de cryptage standard. Ainsi, à titre d'illustration, lorsque les systèmes informatiques sont reliés les uns aux autres via un réseau de type Internet, ces échanges peuvent utiliser le protocole IP combiné avec un 30 cryptage de données par clés privées et clés publiques de type RSA. La figure 4 illustre schématiquement un exemple standard de paiement par carte de paiement dans une infrastructure comprenant une carte 3025915 20 de paiement, un terminal de paiement ainsi que des systèmes informatiques bancaires liés au débiteur et au créditeur. Un tel schéma de paiement est aussi connu sous le nom de modèle de paiement par carte bancaire en quatre coins. Ce schéma de paiement ou un schéma similaire peut notamment 5 être utilisé pour des transferts d'argent entre un compte d'un porteur de carte et un compte d'un commerçant comme visé en référence à la figure 2. Ce schéma de paiement peut être utilisé, tout comme les schémas classiques utilisés pour les chèques, virements et prélèvements, pour des transferts d'argent entre les comptes d'un commerçant (référencé 240 sur la 10 figure 2), d'un gestionnaire de dons (référencé 245 sur la figure 2) et d'une association bénéficiaire (référencée 250 sur la figure 2). Comme illustré, un client pourvu d'une carte de paiement 400, par exemple une carte de type Visa (Visa est une marque), règle ici un achat auprès d'un commerçant disposant d'un terminal de paiement 405. La carte de 15 paiement est associée à un compte bancaire 410 (compte client) géré par un système informatique 415 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 405 est associé à un compte bancaire 420 (compte commerçant) géré par un système informatique 425 d'une banque.
20 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 (étape (D). 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), 25 le terminal de paiement effectue typiquement une demande d'autorisation qui est transmise au système informatique 415 de la banque du porteur de carte via le système informatique 425 de la banque du commerçant et un réseau d'intermédiation bancaire 435 (étape CO et 0). Le message est avantageusement crypté et comprend les 30 identifiants du client et du commerçant ainsi que le montant devant être transféré.
3025915 21 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 415 de la banque du client au système informatique 425 de la 5 banque du commerçant (étape ®). 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 (étape 0), c'est-à-dire ici au 10 système informatique 415, via le réseau d'intermédiation bancaire 435. 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ées (comme précisé précédemment, le réseau d'intermédiation bancaire 435 peut être, par exemple, 15 le réseau d'intermédiation bancaire MasterCard, Visa, GIE Carte Bancaire, SWIFT, STET ou Target 2). Le compte 420 du commerçant est alors crédité de la somme transférée (étape 0) tandis que le compte 410 du client est débité de la même somme (étape CD), typiquement de façon différée.
20 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. La figure 5 illustre un exemple de dispositif pouvant être utilisé pour mettre en oeuvre, au moins partiellement, un mode de réalisation, notamment 25 des étapes décrites en référence aux figures 2 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, 30 sigle de Central Processing Unit en terminologie anglo-saxonne) ; 3025915 22 - 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 5 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 10 - 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 ; 15 - 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 20 - 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 25 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 30 programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 520 ou en mémoire morte 506.
3025915 23 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 5 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 10 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 15 mémoriser les variables et paramètres nécessaires à la mise en oeuvre 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 20 formes de réalisation décrites, d'autres variantes et combinaisons de caractéristiques sont possibles. 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 25 variantes et modes de réalisation peuvent être déduits et mis en oeuvre 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 30 seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en oeuvre l'invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans 3025915 24 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.
3025915 25 ANNEXE ID règle ID TPE REGLE ID bénéficiaires 0 543291 Arrondi supérieur 1 1 1294G3 Forfait 1E par transaction 1 (0,40E), 3 (0,60E) 2 G53391 Minimum entre 0,5% de la 1 (50%), 2 (50%) transaction et 5E ... ... ... n 491503 Arrondi supérieur 1 5 Table 1 ID trans. ID TPE Rc M D, b 0 543291 407 425,66E 1 :0,34E 1 543291 212 35,14E 1 : 0,86E 2 G53391 023 87,45E 1 : 0,22E, 2 : 0,22E ... ... ... ... ... P 1294G3 865 118,00E 1 : 0,40E, 3 : 0,60E 10 Table 2

Claims (15)

  1. REVENDICATIONS1. Procédé de gestion d'une transaction composite comprenant une transaction principale et au moins une opération annexe, ce procédé étant caractérisé en ce qu'il est mis en oeuvre dans un ensemble comprenant un dispositif (205) pour initier une transaction, un dispositif (215) pour proposer au moins une opération annexe selon des caractéristiques d'une transaction principale et un dispositif (220) de gestion d'opérations annexes, ledit dispositif pour proposer au moins une opération annexe étant accessible par une pluralité de dispositifs pour initier une transaction distincts et par une pluralité de dispositifs de gestion d'opérations annexes distincts, et en ce qu'il comprend les étapes suivantes, - réception d'informations relatives à ladite transaction principale, lesdites informations étant reçues dudit dispositif pour initier une transaction par ledit dispositif pour proposer au moins une opération annexe ; - estimation d'au moins un paramètre de ladite au moins une opération annexe, à partir d'au moins une règle prédéterminée, selon au moins une information reçue relative à ladite transaction principale, ladite étape d'estimation étant mise en oeuvre dans ledit dispositif pour proposer au moins une opération annexe ; - en réponse à une indication d'acceptation de ladite au moins une opération annexe reçue dudit dispositif pour initier une transaction, transmission audit dispositif de gestion d'opérations annexes de données comprenant au moins ledit au moins un paramètre de ladite au moins une opération annexe, ladite transaction principale étant gérée indépendamment desdites étapes de réception, estimation et transmission.
  2. 2. Procédé selon la revendication 1 comprenant en outre une étape de sélection de ladite au moins une règle pour estimer ledit au moins un paramètre de ladite au moins une opération annexe.
  3. 3. Procédé selon la revendication 2 comprenant en outre une étape de réception d'un identifiant dudit dispositif pour initier une transaction, ladite au 3025915 27 moins une règle pour estimer ledit au moins un paramètre de ladite au moins une opération annexe étant sélectionnée selon ledit identifiant dudit dispositif pour initier une transaction.
  4. 4. Procédé selon l'une quelconque des revendications 1 à 3 5 comprenant en outre une étape initiale de configuration d'au moins une règle pour estimer au moins un paramètre d'au moins une opération annexe.
  5. 5. Procédé selon l'une quelconque des revendications 1 à 4 selon lequel lesdites données transmises audit dispositif de gestion d'opérations annexes en réponse à une indication d'acceptation de ladite au moins une 10 opération annexe comprennent en outre lesdites informations relatives à ladite transaction principale.
  6. 6. Procédé selon l'une quelconque des revendications 1 à 5 comprenant en outre une étape de transmission d'une commande d'impression audit dispositif pour initier une transaction, ladite commande d'impression visant 15 l'impression d'un reçu comprenant ledit au moins un paramètre de ladite au moins une opération annexe et ladite au moins une information reçue.
  7. 7. Procédé selon la revendication 6 dans lequel ladite commande d'impression vise en outre l'impression d'une référence à un identifiant d'une entité personnelle sur ledit reçu. 20
  8. 8. Procédé selon la revendication 7 selon lequel lesdites données comprenant au moins ledit au moins un paramètre de ladite au moins une opération annexe comprennent en outre ladite référence.
  9. 9. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de mémorisation dudit au moins un paramètre 25 de ladite au moins une opération annexe.
  10. 10. Procédé selon la revendication 9 comprenant en outre une étape pour générer une transaction basée sur au moins un paramètre préalablement mémorisé d'au moins une opération annexe.
  11. 11. Procédé selon la revendication 9 comprenant en outre une étape 30 pour générer un récapitulatif d'opérations annexes, ledit récapitulatif comprenant au moins un paramètre préalablement mémorisé d'au moins une opération annexe. 3025915 28
  12. 12. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de cryptage d'au moins une donnée transmise entre ledit dispositif pour initier une transaction et ledit dispositif pour proposer au moins une opération annexe ou entre ledit dispositif pour proposer au moins 5 une opération annexe et ledit dispositif de gestion d'opérations annexes.
  13. 13. Procédé selon l'une quelconque des revendications précédentes selon lequel le protocole de communication entre ledit dispositif pour initier une transaction et ledit dispositif pour proposer au moins une opération annexe ou entre ledit dispositif pour proposer au moins une opération annexe et ledit 10 dispositif de gestion d'opérations annexes est conforme à un standard de type IP.
  14. 14. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un 15 ordinateur.
  15. 15. Système comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 13. 20
FR1458676A 2014-09-15 2014-09-15 Procedes et dispositifs de gestion de transactions composites Active FR3025915B1 (fr)

Priority Applications (9)

Application Number Priority Date Filing Date Title
FR1458676A FR3025915B1 (fr) 2014-09-15 2014-09-15 Procedes et dispositifs de gestion de transactions composites
CN201580056121.0A CN107209887A (zh) 2014-09-15 2015-09-15 复合交易管理设备及方法
BR112017004962-7A BR112017004962A2 (pt) 2014-09-15 2015-09-15 processos e dispositivos de gestão de transações compósitas
MX2017003424A MX2017003424A (es) 2014-09-15 2015-09-15 Metodos y dispositivos para gestionar transacciones compuestas.
EP15771997.2A EP3195224A1 (fr) 2014-09-15 2015-09-15 Procédés et dispositifs de gestion de transactions composites
AU2015316635A AU2015316635A1 (en) 2014-09-15 2015-09-15 Methods and devices for managing composite transactions
US15/511,037 US20180225663A1 (en) 2014-09-15 2015-09-15 Methods and devices for managing composite transactions
PCT/FR2015/052472 WO2016042258A1 (fr) 2014-09-15 2015-09-15 Procédés et dispositifs de gestion de transactions composites
US14/992,228 US10776782B2 (en) 2014-09-15 2016-01-11 System and method for making and tracking charitable contributions

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1458676 2014-09-15
FR1458676A FR3025915B1 (fr) 2014-09-15 2014-09-15 Procedes et dispositifs de gestion de transactions composites

Publications (2)

Publication Number Publication Date
FR3025915A1 true FR3025915A1 (fr) 2016-03-18
FR3025915B1 FR3025915B1 (fr) 2018-04-20

Family

ID=51842610

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1458676A Active FR3025915B1 (fr) 2014-09-15 2014-09-15 Procedes et dispositifs de gestion de transactions composites

Country Status (8)

Country Link
US (2) US20180225663A1 (fr)
EP (1) EP3195224A1 (fr)
CN (1) CN107209887A (fr)
AU (1) AU2015316635A1 (fr)
BR (1) BR112017004962A2 (fr)
FR (1) FR3025915B1 (fr)
MX (1) MX2017003424A (fr)
WO (1) WO2016042258A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108985741B (zh) * 2018-07-19 2021-06-01 南京市公安局建邺分局 一种警务平台资金流水自动查询追踪方法
JP2020034864A (ja) * 2018-08-31 2020-03-05 京セラドキュメントソリューションズ株式会社 画像形成装置
US11721156B2 (en) * 2020-06-12 2023-08-08 Juan Carlos Vera System and method of setting and charging a fixed donation amount
US20220301039A1 (en) * 2021-03-16 2022-09-22 ELP Global LLC Location-based system for charitable donation

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1136931A1 (fr) * 2000-03-20 2001-09-26 Roundit Inc. Système d'incitation au patronage, et méthode de commerce au détail basée sur internet
WO2003052709A1 (fr) * 2001-12-14 2003-06-26 Pohl Angus Procede informatique automatise de collecte de petite monnaie
US20050051617A1 (en) * 2003-09-05 2005-03-10 Gorelick Steven M. Methods and systems for automatically determining and collecting a monetary contribution from an instrument
US6876971B1 (en) * 2000-07-05 2005-04-05 Every Penny Counts, Inc. Funds distribution system connected with point of sale transaction
US20120084162A1 (en) * 2010-10-05 2012-04-05 Merrill Brooks Smith Systems and methods for conducting a composite bill payment transaction

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6088682A (en) * 1993-02-18 2000-07-11 Every Penny Counts, Inc. Funds distribution system connected with point of sale transactions
US6112191A (en) * 1993-02-18 2000-08-29 Every Penny Counts, Inc. Method and system to create and distribute excess funds from consumer spending transactions
US5466919A (en) * 1993-04-02 1995-11-14 Hovakimian; Henry Credit/charge card system enabling purchasers to contribute to selected charities
US7542919B1 (en) * 1997-03-21 2009-06-02 Walker Digital, Llc Method and apparatus for selecting a supplemental product to offer for sale during a transaction
US20040034563A1 (en) * 1998-11-18 2004-02-19 Brissette Edward C. System and method for making charitable donations
MXPA01013136A (es) * 1999-06-23 2004-06-03 Postrel Richard Sistema para permuta electronica para negociar y recuperar puntos acumulados en programas de recompensa por uso frecuente.
US8160922B2 (en) * 1999-06-23 2012-04-17 Signature Systems, LLC. Method and system for making donations to charitable entities
US6307812B1 (en) * 2000-03-27 2001-10-23 Michael S. Gzybowski Security system using modular timers
US20020120539A1 (en) * 2000-11-20 2002-08-29 Price Cynthia L. Method and system for distributing charitable donations at a point of sale to qualified donees
US20020116214A1 (en) * 2001-02-16 2002-08-22 Horn James Van Automated fundraising accounting system
US20020196204A1 (en) * 2001-06-26 2002-12-26 Matthew Senn Steven Michael Retail customer and product purchase divider with interactive retail transaction functions
US20030065572A1 (en) * 2001-09-28 2003-04-03 Mcnee Carolyn Charity donation method
US20060122856A1 (en) * 2002-06-06 2006-06-08 Benevolink Corporation System and method for enabling consumers to add personal charitable contributions and transfer the right to designate a beneficiary to other consumers
US20040182922A1 (en) * 2003-03-21 2004-09-23 Frank Talarico Systems and methods for a loadable stored-value card with a contribution to a specified beneficiary
US20050125342A1 (en) * 2003-10-01 2005-06-09 Steven Schiff System and method for interactive electronic fund raising and electronic transaction processing
AU2007202567B2 (en) * 2004-07-23 2011-12-15 Jord Williams Poster Charitable giving
US20050251485A1 (en) * 2005-04-18 2005-11-10 Quigley Daniel H Systems for soliciting donations
US8214287B1 (en) * 2007-12-12 2012-07-03 Ernest Garfield System for collecting and distributing charitable contributions
US20090171835A1 (en) * 2007-12-26 2009-07-02 Mastercard International, Inc. Multiple Payment Transaction Systems
US8336762B1 (en) * 2008-11-17 2012-12-25 Greenwise Bankcard LLC Payment transaction processing
US9076167B2 (en) * 2013-06-27 2015-07-07 Sparo Corporation Method and system for automated online merchant charity donations

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1136931A1 (fr) * 2000-03-20 2001-09-26 Roundit Inc. Système d'incitation au patronage, et méthode de commerce au détail basée sur internet
US6876971B1 (en) * 2000-07-05 2005-04-05 Every Penny Counts, Inc. Funds distribution system connected with point of sale transaction
WO2003052709A1 (fr) * 2001-12-14 2003-06-26 Pohl Angus Procede informatique automatise de collecte de petite monnaie
US20050051617A1 (en) * 2003-09-05 2005-03-10 Gorelick Steven M. Methods and systems for automatically determining and collecting a monetary contribution from an instrument
US20120084162A1 (en) * 2010-10-05 2012-04-05 Merrill Brooks Smith Systems and methods for conducting a composite bill payment transaction

Also Published As

Publication number Publication date
AU2015316635A1 (en) 2017-05-04
WO2016042258A1 (fr) 2016-03-24
US20180225663A1 (en) 2018-08-09
BR112017004962A2 (pt) 2018-04-10
EP3195224A1 (fr) 2017-07-26
US10776782B2 (en) 2020-09-15
FR3025915B1 (fr) 2018-04-20
US20160125482A1 (en) 2016-05-05
CN107209887A (zh) 2017-09-26
MX2017003424A (es) 2018-08-01

Similar Documents

Publication Publication Date Title
US10810557B2 (en) Financial services ecosystem
Bollen The Legal Status of Online Currencies–Are Bitcoins the Future?
US20170323298A1 (en) System and method for securely transferring funds between persons
US20160284022A1 (en) System and method for automated digital currency savings platform
KR20230088745A (ko) 디지털 자산 교환을 위한 시스템, 디지털 지갑, 및 디지털 자산들을 교환하기 위한 아키텍처
WO2018154082A1 (fr) Système et procédé de traitement d'une transaction bancaire
WO2016042258A1 (fr) Procédés et dispositifs de gestion de transactions composites
EP3243175A1 (fr) Procédés et dispositifs de commande d'opérations annexes liées a l'exécution de transactions principales
EP3485451B1 (fr) Procédé de traitement d'au moins une donnée de moyen de paiement, terminal de paiement et programme d'ordinateur correspondant
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
EP2724305A1 (fr) Procede de transaction dematerialisee
WO2015044393A1 (fr) Méthode de traitement de données transactionnelles, terminal, serveur et programmes d'ordinateur correspondants
Dannen et al. Use Cases: Proof of work, decentralization, Merkle and Patricia trees, asymmetric cryptography, smart contracts… What can you make with such ingredients?
EP3300012A1 (fr) Procede et systeme pour gerer des autorisations d'achat
FR2912579A1 (fr) Procede de transfert securise via un reseau de communication d'un flux monetaire, systeme de transfert et produit programme correspondants
WO2002025512A2 (fr) Procede, dispositif et systeme de controle et de commande d'operations par un utilisateur

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20160318

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

PLFP Fee payment

Year of fee payment: 9

PLFP Fee payment

Year of fee payment: 10