FR3011366A1

FR3011366A1 - Methode de traitement de donnees transactionnelles, terminal, serveur et programmes d’ordinateur correspondants.

Info

Publication number: FR3011366A1
Application number: FR1359350A
Authority: FR
Inventors: Vincent Ducrohet
Original assignee: Compagnie Industrielle et Financiere dIngenierie Ingenico SA
Current assignee: Banks and Acquirers International Holding SAS
Priority date: 2013-09-27
Filing date: 2013-09-27
Publication date: 2015-04-03
Anticipated expiration: 2033-09-27
Also published as: EP3050034A1; US20160239816A1; CA2921110C; CA2921110A1; BR112016006647A2; WO2015044393A1; FR3011366B1; US10504078B2

Abstract

L'invention se rapporte à une méthode de traitement de données transactionnelles, par l'intermédiaire d'un terminal de paiement. Selon l'invention, une telle méthode de traitement comprend : une étape de capture (10), à partir d'un support préexistant (FR), d'au moins une donnée représentative d'une facture à régler (DRAGR), dite donnée consolidée ; - une étape de formatage (20) de la donnée consolidée, par une application d'encaissement dudit terminal de paiement, délivrant une facture numérique (FactN) ; - une étape d'affichage (30), par ladite application d'encaissement, de ladite facture numérique (FactN) ; - au moins une étape de transmission (40), à une application de paiement dudit terminal de paiement (AppP), d'au moins une donnée représentative d'une somme à payer (S) en fonction d'au moins un élément (E) de ladite facture numérique, dite donnée transactionnelle.

Description

Méthode de traitement de données transactionnelles, terminal, serveur et programmes d'ordinateur correspondants. 1. Domaine de l'invention L'invention se rapporte au domaine des dispositifs de paiement. Plus particulièrement, l'invention se rapporte à un dispositif de paiement qui dispose de capacités d'encaissement. 2. Art Antérieur Des terminaux de paiement sont désormais majoritairement utilisés dans les commerces pour effectuer les règlements des achats. Les commerçants plébiscitent ces terminaux de paiement car ils offrent un degré de sécurisation de transaction supérieur à d'autres moyens de paiement (tels que les chèques) et qu'ils permettent d'éviter les inconvénients liés à la possession de trop grande quantité d'argent liquide. Ainsi, le terminal de paiement est devenu l'accessoire privilégié du commerçant. En revanche, dans certaines situations, le terminal de paiement n'est pas encore tout à fait adapté au besoin du commerçant dû à un manque de fonctionnalité métiers. Par exemple, afin de faciliter les opérations d'encaissement, des commerçants réclament une solution d'encaissement intégrée avec le terminal de paiement. Par solution d'encaissement, on comprend d'une part une intégration et une communication entre le terminal de paiement et une caisse enregistreuse intelligente et d'autre part un respect de normes en vigueur relatives au paiement (de telles normes sont généralement bâties pour un pays donné). Ainsi, une intégration terminal de paiement/caisse enregistreuse dépend du système d'encaissement (par exemple la caisse enregistreuse), du terminal de paiement et n'est généralement valable que dans un pays. Ainsi, si l'on souhaite interfacer un type de terminal de paiement avec un type de système d'encaissement, il est nécessaire de le faire pays par pays ou région par région, ce qui pose des problèmes de coût. De plus, interfacer un système d'encaissement et un terminal de paiement requiert des compétences de développement logiciel, tant au niveau du système d'encaissement qu'au niveau du terminal de paiement. En conséquence, ceci nécessite une gestion de configuration complexe, car il est nécessaire de maintenir de nombreuses versions différentes de logiciel. Ceci est donc également long et coûteux. Il existe donc un besoin de fournir une solution aux problèmes de coûts et de faisabilité d'intégration afin de fournir au terminal de paiement des fonctionnalités d'encaissement pour faciliter le quotidien des commerçants. 3. Résumé de l'invention La technique proposée ne présente pas ces inconvénients de l'art antérieur. Plus particulièrement, la technique proposée se rapporte à une méthode de traitement de données transactionnelles, par l'intermédiaire d'un terminal de 10 paiement. La méthode proposée se différencie par le fait qu'elle comprend : une étape de capture, à partir d'un support préexistant, d'au moins une donnée représentative d'une facture à régler, dite donnée consolidée ; une étape de formatage de la donnée consolidée, par une application 15 d'encaissement dudit terminal de paiement, délivrant une facture numérique ; une étape d'affichage, par ladite application d'encaissement, de ladite facture numérique ; au moins une étape de transmission, à une application de paiement dudit terminal de paiement, d'au moins une donnée représentative d'une somme à 20 payer en fonction d'au moins un élément de ladite facture numérique, dite donnée transactionnelle. Ainsi, la technique proposée permet d'obtenir des données relatives à la facture sans avoir besoin de modifier le fonctionnement du système d'encaissement (qui peut être une caisse enregistreuse). En effet, en effectuant une capture à partir 25 d'un support existant (comme un ticket de caisse ou une facture imprimée, mais également un écran du système d'encaissement), il n'est pas nécessaire de prévoir un développement spécifique du côté du système d'encaissement. Selon un mode de réalisation particulier, ladite étape de capture de ladite donnée consolidée comprend : 30 au moins une étape d'obtention d'un code en deux dimensions préalablement imprimé sur une facture ; une étape de décodage dudit code en deux dimensions délivrant ladite donnée consolidée ; Ainsi, la seule obtention d'un code en deux dimensions, puis le décodage de la donnée permet de transmettre les données nécessaires à l'application d'encaissement du terminal. Selon un mode de réalisation particulier, ladite étape de capture de ladite donnée consolidée comprend en outre, postérieurement à ladite étape de décodage dudit code en deux dimensions, une étape de décompression des données dudit code à deux dimensions.

Ainsi, comme les données sont compressées sur le code en deux dimensions, il est possible de transmettre, sur le code, plus de données que celles qu'il est normalement possible de transmettre par l'intermédiaire de ce type de code. Selon une caractéristique particulière, ladite étape de capture de ladite donnée consolidée comprend en outre, postérieurement à ladite étape de décodage dudit code en deux dimensions, une étape de déchiffrement des données dudit code à deux dimensions. Ainsi, les données consolidées ne sont pas déchiffrables par n'importe quelle application de capture de code à barre. Il n'est pas non plus possible, pour un client indélicat, de frauder en modifiant le contenu du code à barre.

Selon un mode de réalisation particulier, ladite méthode comprend en outre, postérieurement à la transmission, à ladite application de paiement dudit terminal de paiement, de ladite au moins une donnée représentative d'une somme à payer : une étape de prise de contrôle dudit terminal de paiement par ladite application de paiement ; une étape de mise en oeuvre d'une transaction de paiement par ladite application de paiement ; une étape de fourniture, à ladite application d'encaissement, d'un résultat de ladite transaction de paiement ; une étape d'intégration, par ladite application d'encaissement, dudit résultat de ladite transaction de paiement.

Ainsi, il n'y a pas de trou de sécurité dans le traitement de ces données transactionnelles. Dans un autre mode de réalisation, la technique proposée peut également prendre la forme d'un terminal de paiement comprenant des moyens de traitement de données transactionnelles. Ces moyens de traitement de données transactionnelles comprennent : des moyens de capture d'au moins une donnée représentative d'une facture à régler, dite donnée consolidée ; des moyens de formatage de la donnée consolidée, par une application d'encaissement dudit terminal de paiement, délivrant une facture numérique ; des moyens d'affichage, par ladite application d'encaissement, de ladite facture numérique ; des moyens de transmission, à une application de paiement dudit terminal de paiement, d'au moins une donnée représentative d'une somme à payer en fonction d'au moins un élément de ladite facture numérique, dite donnée transactionnelle. Selon une implémentation préférée, les différentes étapes des procédés selon l'invention sont mises en oeuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un module relais selon l'invention et étant conçu pour commander l'exécution des différentes étapes des procédés. En conséquence, l'invention vise aussi un programme, susceptible d'être exécuté par un ordinateur ou par un processeur de données, ce programme comportant des instructions pour commander l'exécution des étapes d'un procédé tel que mentionné ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.

L'invention vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Selon un mode de réalisation, l'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'a un composant matériel ou à un ensemble de composants matériels et logiciels.

Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. Chaque composante du système précédemment décrit met bien entendu en oeuvre ses propres modules logiciels. Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en oeuvre de l'invention. 4. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un synoptique de la technique proposée ; la figure 2 décrit plus précisément les étapes d'obtention de la donnée consolidée ; la figure 3 décrit un dispositif pour la mise en oeuvre de la technique proposée. 5. Description 5.1. Rappel du principe général de l'invention Comme l'objectif est de fournir, au terminal de paiement, des fonctions d'encaissement (de caisse enregistreuse), le principe de l'invention consiste à développer une unique application d'encaissement. Cette unique application métier dédiée à l'encaissement comprend des fonctions simple des systèmes d'encaissement : possibilité de diviser ou de répartir le paiement d'une facture (lorsque la facture est partagée entre plusieurs clients par exemple), possibilité de supprimer des articles ou d'appliquer des réductions sur la note, etc. Cette application d'encaissement est dite générique puisqu'elle ne comprend d'une part pas de fonctions d'encaissement complexes (qui sont liées à des règlementations locales, régionales ou nationales) et qu'elle est disponible pour tous les terminaux d'un type donné. Dans un mode de mise en oeuvre particulier, le constructeur de terminaux de paiement peut sélectionner les types ou les gammes de terminaux de paiement sur lesquels l'application générique est installée. Pour les constructeurs de terminaux de paiement qui intègrent des processeurs qui ne varient pas ou peu, l'application peut facilement être déployée sur de nombreuses gammes ou de nombreux types de terminaux de paiement. L'application d'encaissement peut être mise en oeuvre sous la forme d'un module, logiciel ou matériel, qui est en charge des fonctions d'encaissement au sein du terminal de paiement. Le principe général de l'invention consiste également à mettre en oeuvre un interfaçage générique entre le terminal de paiement et le système d'encaissement, pour éviter de développer des interfaces particulières, qui sont souvent complexes et couteuses. En effet, pour permettre de résoudre les problèmes susmentionnés, il est également nécessaire de prévoir une possibilité de transmission de données entre le système d'encaissement et le terminal de paiement. Traditionnellement, une telle transmission de données peut être mise en oeuvre par un interfaçage physique basé soit sur une transmission filaire soit sur une transmission sans fil. Le terminal de paiement reçoit des données (principalement une donnée relative au montant de la transaction) et affiche cette donnée afin de permettre au client (celui qui règle le montant de la transaction) de payer (c'est-à-dire généralement de saisir un code personnel d'identification, code PIN). La technique proposée ne change pas fondamentalement cette manière de fonctionner. La technique proposée, cependant, modifie d'une part la manière dont les données sont transmises et d'autre part, le destinataire des données transmises. Pour ce qui est de la manière dont les données sont transmises, on utilise une technique qui ne nécessite pas de changements tant au niveau du terminal de paiement que du système d'encaissement. Pour ce faire, on met à profit la capacité du système d'encaissement à imprimer un ticket de caisse.

En effet, les systèmes d'encaissement sont paramétrables. Ils peuvent être paramétrés à la fois en termes d'affichage électronique (par exemple pour l'apparence des icônes ou des logos qui sont affichés sur les différents écrans du système). Ils peuvent également être paramétrés en termes d'affichage physiques : les logos et les données qui sont imprimées sur les tickets de caisse sont paramétrables. Le système offre plusieurs possibilités de paramétrage pour les tickets de caisse. La technique proposée se base sur ces possibilités pour imprimer, en sus des données traditionnelles (magasin, date, heure, logos, identification de produits, quantités, prix par article, prix total, montants des taxes), une donnée consolidée et convertie en un symbole visuel. Cette donnée consolidée comprend, sous une forme condensée et standardisée, l'intégralité des données utiles du ticket de caisse (date/heure/identification des produits, quantité par produit, prix par produit, montant total, montants des taxes). Cette donnée consolidée est imprimée sur le ticket de caisse et est lisible par le terminal de paiement. Ainsi, la transmission des données utiles, pour les fonctions d'encaissement du terminal de paiement, ne nécessite pas de développer une application complexe sur le terminal de paiement et sur le système d'encaissement. Un paramétrage adapté du système d'encaissement peut être suffisant. Dans certaines situations dans lesquelles une telle impression n'est pas possible, il n'est nécessaire que de développer une application spécifique pour le système d'encaissement et non pas pour le terminal, ce qui est nettement moins coûteux.

Pour ce qui est du destinataire des données transmises par le système d'encaissement : les données sont toujours destinées au terminal de paiement, mais les données ne sont plus transmises, comme traditionnellement, à une application de paiement (i.e. une application sécurisée chargée de valider le paiement), mais à l'application d'encaissement (générique) du terminal de paiement qui est en charge du traitement de données transactionnelles. C'est l'application d'encaissement qui communique ensuite avec l'application de paiement pour effectuer la ou les transactions (par exemple plusieurs transactions distinctes lorsque le montant de la facture doit être divisé entre plusieurs payeurs). Plus précisément décrit en relation avec la figure 1, la technique proposée comprend, du point de vue du terminal de paiement : une étape de capture, à partir d'un support préexistant, 10 d'au moins une donnée représentative DRAGR d'une facture à régler FR, dite donnée consolidée ; une étape de formatage 20 de la donnée consolidée, par une application d'encaissement dudit terminal de paiement, délivrant une facture numérique (FactN) ; une étape d'affichage 30, par ladite application d'encaissement, de ladite facture numérique (FactN) ; au moins une étape de transmission 40, à une application de paiement AppP dudit terminal de paiement, d'au moins une donnée représentative d'une somme à payer S en fonction d'au moins un élément E de ladite facture numérique. Dans un mode de réalisation particulier de l'invention, l'étape de capture comprend une étape d'obtention d'une image représentative de la facture à régler, par le biais par exemple d'un capteur numérique installé sur ledit terminal. Dans ce cas, l'image est la donnée consolidée. Le formatage de la donnée consolidée comprend alors une étape de reconnaissance optique de caractères délivrant les données de la facture. Dans d'autres modes de réalisation, le support préexistant ne se présente pas sous la forme d'une facture, mais par exemple d'un écran, tel que l'écran de la caisse enregistreuse, sur laquelle la donnée consolidée est affichée. Dans un autre mode de réalisation, la donnée consolidée se présente sous la forme d'un signal audio, émis par le système d'encaissement. Par la suite, on présente un mode de réalisation de l'invention. Ce mode de réalisation se base sur une matérialisation particulière de la donnée consolidée. Il va de soi que toute autre matérialisation textuelle ou graphique de la donnée consolidée peut être préférée à la présente technique sans qu'elle puisse être considérée comme n'étant pas comprise dans le champ de la présente technique. 5.2. Description d'un mode de réalisation Dans ce mode de réalisation, on décrit une mise en oeuvre de la technique décrite à l'aide de code en deux dimensions. Dans ce mode de réalisation, un QR code de version 4 ou 10 est utilisé pour enregistrer la donnée consolidée (la donnée contenant les données utiles du ticket de caisse). D'autres type de QR code peuvent également être utilisés. Il s'agit ici d'une simple présentation. L'avantage de ce type de QR code est qu'il peut stoker de 67 (version 4) à 395 (version 10) caractères alphanumériques (un équivalent en bit peut également être calculé).

En fonction des modes de réalisation, un code version 40 peut également être utilisé. L'objectif, dans ce mode de réalisation, n'est pas de stocker, dans le code à deux dimensions, un lien (une adresse) vers lequel l'application d'encaissement du terminal de paiement va être redirigée pour obtenir les données utiles. L'objectif est bien de stocker dans le code les données utiles. Bien entendu, la capacité de stockage d'un tel code étant limitée, tout comme est limitée la capacité du système d'encaissement à générer de tels codes, un problème supplémentaire doit être résolu : comment faire lorsque la quantité de données excède celle du code. Pour ce faire, dans ce mode de réalisation de l'invention, deux solutions complémentaires sont employées : la première consiste à compresser les données qui doivent être insérées dans le code ; cette compression, dans ce mode de réalisation particulier est réalisée soit avec un codage Baudot, soit avec un codage Huffman adaptatif. L'avantage de l'utilisation du codage Baudot est que les données utiles sont toujours réparties selon la même séquence comprenant l'article (comprenant des lettres), une quantité éventuelle et un prix (comprenant des chiffres). Or le codage Baudot qui comprend un codage de caractères sur 5 bits est intéressant dans cette situation car la succession des données utiles est prévisible. Ainsi, on augment grandement la capacité de stockage du code. La deuxième solution consiste à imprimer autant de code que nécessaire. Par exemple, si la capacité du premier code est dépassée, un deuxième code est imprimé afin de fournir les données manquantes. L'impression de code continue tant que des données doivent être ajoutées. Quoi qu'il en soit, dans ce mode de réalisation, au moins un code comprenant les données utiles est imprimé sur le ticket de caisse. Les traitements réalisés par le système d'encaissement s'arrêtent à ce point. Du point de vue du terminal de paiement, comme exposé en figure 2, la technique proposée comprend : une étape d'initialisation (00) d'une application d'encaissement ; une étape d'obtention (10) de la donnée consolidée : dans ce mode de réalisation, l'obtention de cette donnée consolidée est mise en oeuvre par les étapes suivantes : scan (11) du ticket de caisse par le terminal de paiement (l'utilisation de la fonction de scan est autorisée pour l'application d'encaissement) à l'aide d'un lecteur de code à barre ; décodage (12) du code obtenu, comprenant optionnellement une étape de décompression de données si cela est nécessaire ; enregistrement (13) de la donnée consolidée au sein dudit terminal ; une étape de formatage (20) de la donnée consolidée par ladite application d'encaissement, délivrant un ticket de caisse numérique ; une étape d'affichage (30), sur l'écran dudit terminal de paiement, du ticket de caisse numérique. Ainsi, le ticket de caisse est importé au sein du terminal de paiement. Les fonctionnalités d'encaissement de l'application générique peuvent ainsi être mise en oeuvre. Ces fonctionnalités peuvent par exemple être des fonctionnalités de division, de répartition, de réduction de montant, de fidélisation (crédit de carte de fidélité), etc. Dans ce mode de réalisation, ces fonctionnalités sont simples et n'interfèrent pas avec les fonctions complexes du système d'encaissement (comme par exemple le calcul de montant de TVA, de journalisation de transactions, etc.). La mise en oeuvre du paiement est commandée à partir de l'application d'encaissement du terminal de paiement. Pour ce faire, lorsqu'un paiement doit être réalisé, l'application d'encaissement transmet, à l'application de paiement, les données nécessaires au paiement (c'est-à-dire, au minimum, le montant), et l'application de paiement se charge d'effectuer les opérations nécessaires au paiement (vérification du PIN, obtention d'autorisation bancaire, etc.) en allant jusqu'à l'impression d'une note de frais par repas. Si le consommateur décide de payer en liquide ou via tout autre moyen de paiement (titres restaurants par exemple), l'application offre la possibilité de le noter afin de calculer le restant total à payer. Dans un mode de réalisation complémentaire, lorsque les fonctions offertes par l'application d'encaissement sont plus complexes, la technique proposée comprend en outre, du point de vue du terminal de paiement, une étape complémentaire d'impression, à l'aide d'une imprimante du terminal de paiement, d'une donnée récapitulative, également agrégée, sous la forme d'une code en deux dimensions (QR Code), sur un ticket de paiement. Le ticket de paiement est le duplicata du ticket qui est conservé par le commerçant. Le code qui y est imprimé de manière complémentaire peut être lu par le système d'encaissement, par exemple à l'aide d'une douchette, afin de prendre en compte l'opération d'encaissement complexe réalisée depuis le terminal de paiement. Cette étape d'impression du code en deux dimensions est précédée d'une étape de calcul des données nécessaires. Dans un mode de réalisation complémentaire, en plus d'être compressées, les données du code en deux dimensions sont également chiffrées. Plus particulièrement, les données sont chiffrées à l'aide d'une clé publique disponible par l'intermédiaire du système d'encaissement. Le système d'encaissement chiffre les données une fois qu'elles ont été compressées (si une compression est mise en oeuvre). 5.3. Système d'encaissement Comme exposé préalablement, la technique proposée se base sur la capacité du système d'encaissement à restituer (ou à imprimer) une donnée consolidée qui comprend l'intégralité des données utiles au module d'encaissement du terminal de paiement. Ces données utiles comprennent au moins l'identification des articles. De manière complémentaire, ces données utiles comprennent également le nombre d'articles, le montant de ces articles et des montants de taxes éventuels, voire des codes de taxes. Le système d'encaissement, en fonction des modes, peut prendre la forme d'une caisse enregistreuse dite « intelligente », qui peut être paramétrée pour effectuer des impressions de factures conformes d'une part à des réglementations locales ou régionales et d'autres part conformes à des exigences de présentation du commerçant. Le système d'encaissement peut également prendre la forme d'un système informatique, plus ou moins décentralisé, dans lequel des caisses enregistreuses, esclaves, sont connectées à un serveur d'encaissement par l'intermédiaire d'un réseau de communication. Ce cas peut par exemple s'appliquer à des réseaux de distribution (franchisés) ou à des magasins ou des commerces de grande taille dans lesquelles les caisses enregistreuses sont reliées en réseau. Dans ce cas, le paramétrage peut être réalisé pour l'ensemble des caisses enregistreuses, au niveau du serveur d'encaissement. Le système est donc paramétré pour restituer la donnée consolidée (ou une forme codée et/ou chiffrée de la donnée consolidée) sur la facture, lors de l'impression de celle-ci ou sur tout autre support adapté : par exemple un code à barre peut être imprimé à la demande du commerçant lorsque le client indique vouloir régler sa facture. Dans ce cas, la donnée consolidée est imprimée à part de la facture elle-même. Bien entendu, en fonction des commerces et des modes de réalisation, la facture peut également être un ticket de caisse, une carte ou tout autre support adapté. 5.4. Description d'un cas d'usage On présente ci-après un cas d'usage de la technique proposée dans un restaurant ou un bar permettant de réaliser des séparations d'additions basées sur le nombre de personnes et leurs consommations. Sur ce marché, la gestion de l'addition est relativement complexe car elle nécessite de manipuler plusieurs types de moyens de paiement (monnaie, billets, carte bleue, titre restaurants, avoirs...) et ce dans un contexte d'environnements particulier (debout, à la table des consommateurs) et enfin dans un contexte de temps serré puisqu'il s'agit souvent d'environnement comprenant des pics d'affluence.

Lorsqu'une table demande la séparation de l'addition, la situation se complexifie, surtout quand les consommateurs souhaitent payer uniquement ce qu'ils ont consommé (vs division par le nombre de consommateurs). Les impacts étudiés sont de plusieurs ordres : temps de calcul long, nécessitant au serveur de rester un long moment à la table pour effectuer l'encaissement ; temps d'attente des autres tables pour commander ou payer ; erreur de calcul donnant, en fin de service, une erreur de caisse qu'il faut gérer via de nombreux recomptage. Au contraire grâce à la méthode de traitement de données transactionnelles de la présente technique, l'encaissement est réalisé directement à table : Une fois l'addition demandée par le consommateur, le serveur tape le numéro de la table au niveau du système d'encaissement. Le système d'encaissement imprime le ticket avec le détail de l'addition et le total ; Sur ce même ticket, un code QR est imprimé. Dans le cas où les informations à ajouter sont trop nombreuses, il est possible d'imprimer plusieurs codes QR (représentant l'addition totale) ; Le code QR imprimé contient les informations de l'addition sous la forme « Nom du plat » « Quantité » « Prix » « TVA », chaque donnée étant séparée par un symbole de séparation ; Une fois l'addition déposée sur la table et la demande de séparation faite par le consommateur, le serveur arrive à la table pour procéder au paiement avec son terminal de paiement électronique ; En utilisant le lecteur de code barre de son terminal de paiement électronique, le serveur scanne le ou les code(s) QR. Le terminal recréé alors l'ensemble de l'addition avec les données comprises dans le code QR ; Une interface permet alors de faire la séparation de l'addition : le serveur demande à la personne P1 ce qu'il/elle a mangé et en cochant ses consommations. Une fois que la sélection est faite, alors il est possible de sélectionner le bouton « Sous-total et Paiement » pour procéder au paiement 20 (quel que soit le type de paiement) ; 7. Ensuite, le serveur peut demander à la personne P2 ce qu'elle est a consommé et ensuite de suite. Le total « Restant à Payer » est automatiquement mis à jour à la fin de chaque sous-total payé ; 8. À la fin du paiement, le sous-total donc doit être à zéro pour valider que tous 25 les consommateurs d'une table ont bien payé l'ensemble de leurs consommations. Il est possible d'imprimer une note de frais à la fin de chaque sous total payé/paiement à la demande du consommateur. Ainsi, le terminal de paiement équipé d'une application générique 30 d'encaissement, au sens de la présente technique, associé à une obtention simplifiée des données utiles relatives à l'achat permettent au commerçant de disposer d'une 1. 2. 3. 4. 5. 6. terminal de paiement utile dans le cas de traitement d'encaissement localisés à des endroits différents de celui où se trouve le système d'encaissement principal du commerce. 5.5. Autres caractéristiques et avantages On présente, en relation avec la figure 3, une architecture simplifiée d'un terminal de paiement apte à mettre en oeuvre la technique décrite. Un tel terminal comprend une mémoire 41, une unité de traitement 42 équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur 43, mettant en oeuvre au moins une partie du procédé tel que décrit. Dans au moins un mode de réalisation, la technique décrite est mise en oeuvre sous la forme d'une application logicielle. Dans un autre mode de réalisation, la technique décrite est mise en oeuvre sous une forme purement matérielle, à l'aide de processeurs et d'interface spécialement créés à cet effet, par exemple dans un terminal de paiement sécurisé. Un tel terminal comprend : des moyens de capture d'au moins une donnée représentative d'une facture à régler, dite donnée consolidée ; des moyens de formatage de la donnée consolidée, par une application d'encaissement dudit terminal de paiement, délivrant une facture numérique ; des moyens d'affichage, par ladite application d'encaissement, de ladite facture numérique ; des moyens de transmission, à une application de paiement dudit terminal de paiement, d'au moins une donnée représentative d'une somme à payer en fonction d'au moins un élément de ladite facture numérique, dite donnée transactionnelle. Ces moyens sont pilotés par le microprocesseur, à l'aide du programme chargés dans la mémoire du terminal. En fonction des modes de réalisation, le terminal comprend également d'autres moyens, comme des modulés de transmission/réception de données, permettant de réaliser des échanges avec un système d'encaissement, comme des moyens d'impression de codes à deux dimensions comprenant des données de compte rendu de transactions effectuées par l'intermédiaire dudit terminal. Le terminal peut également comprendre des modules de traitement cryptographique pour le chiffrement et le déchiffrement des données.

De tels modules et composants constituent les moyens mis en oeuvre pour effectuer les opérations nécessaires en lien avec la présente technique. De tels moyens peuvent se présenter sous une forme matérielle, par exemple des processeurs ou microprocesseurs de type FPGA, ou encore sous une forme logicielle ou sous une combinaison de ces formes. 17

Claims

REVENDICATIONS1. Méthode de traitement de données transactionnelles, par l'intermédiaire d'un terminal de paiement, caractérisé en ce que ladite méthode de traitement comprend : une étape de capture (10), à partir d'un support préexistant (FR), d'au moins une donnée représentative d'une facture à régler (DRAGR), dite donnée consolidée ; - une étape de formatage (20) de la donnée consolidée, par une application d'encaissement dudit terminal de paiement, délivrant une facture numérique (FactN) ; - une étape d'affichage (30), par ladite application d'encaissement, de ladite facture numérique (FactN) ; au moins une étape de transmission (40), à une application de paiement dudit terminal de paiement (AppP), d'au moins une donnée représentative d'une somme à payer (S) en fonction d'au moins un élément (E) de ladite facture numérique, dite donnée transactionnelle.
2. Méthode de traitement selon la revendication 1, caractérisé en ce que ladite étape de capture de ladite donnée consolidée comprend : - au moins une étape d'obtention d'un code en deux dimensions préalablement imprimé sur une facture ; - une étape de décodage dudit code en deux dimensions délivrant ladite donnée consolidée ;
3. Méthode de traitement selon la revendication 2, caractérisé en ce que ladite étape de capture de ladite donnée consolidée comprend en outre, postérieurement à ladite étape de décodage dudit code en deux dimensions, une étape de décompression des données dudit code à deux dimensions. 18 3011366
4. Méthode de traitement selon la revendication 2, caractérisé en ce que ladite étape de capture de ladite donnée consolidée comprend en outre, postérieurement à ladite étape de décodage dudit code en deux dimensions, une étape de déchiffrement des données dudit code à deux dimensions. 5
5. Méthode de traitement selon la revendication 1, caractérisé en ce qu'il comprend en outre, postérieurement à la transmission, à ladite application de paiement dudit terminal de paiement, de ladite au moins une donnée représentative d'une somme à payer : 10 - une étape de prise de contrôle dudit terminal de paiement par ladite application de paiement ; - une étape de mise en oeuvre d'une transaction de paiement par ladite application de paiement ; - une étape de fourniture, à ladite application d'encaissement, d'un résultat de 15 ladite transaction de paiement ; - une étape d'intégration, par ladite application d'encaissement, dudit résultat de ladite transaction de paiement.
6. Terminal de paiement comprenant des moyens de traitement de données 20 transactionnelles comprenant : - des moyens de capture (10), à partir d'un support préexistant (FR), d'au moins une donnée représentative d'une facture à régler (DRAGR), dite donnée consolidée ; - des moyens de formatage (20) de la donnée consolidée, par une application 25 d'encaissement dudit terminal de paiement, délivrant une facture numérique (FactN) ; - des moyens d'affichage (30), par ladite application d'encaissement, de ladite facture numérique (FactN) ; - des moyens de transmission (40), à une application de paiement dudit terminal 30 de paiement (AppP), d'au moins une donnée représentative d'une somme à 19 3011366 payer (S) en fonction d'au moins un élément (E) de ladite facture numérique, dite donnée transactionnelle.
7. Produit programme d'ordinateur t'éléchargeable depuis un réseau de 5 communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution de la méthode selon l'une des revendications 1 à 5, lorsqu'elle est exécuté sur un ordinateur. 10