LU501747B1 - Dispositif de traitement de données pour terminal de vente - Google Patents
Dispositif de traitement de données pour terminal de vente Download PDFInfo
- Publication number
- LU501747B1 LU501747B1 LU501747A LU501747A LU501747B1 LU 501747 B1 LU501747 B1 LU 501747B1 LU 501747 A LU501747 A LU 501747A LU 501747 A LU501747 A LU 501747A LU 501747 B1 LU501747 B1 LU 501747B1
- Authority
- LU
- Luxembourg
- Prior art keywords
- print data
- data processing
- data
- additional information
- processing device
- Prior art date
Links
- 238000012545 processing Methods 0.000 title claims abstract description 40
- 238000004891 communication Methods 0.000 claims abstract description 13
- 238000000034 method Methods 0.000 claims abstract description 11
- 238000007639 printing Methods 0.000 claims description 24
- 230000008569 process Effects 0.000 claims description 2
- 230000015654 memory Effects 0.000 description 7
- 230000003190 augmentative effect Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 5
- 239000000872 buffer Substances 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 238000004590 computer program Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000002093 peripheral effect Effects 0.000 description 3
- 238000010276 construction Methods 0.000 description 2
- 238000003780 insertion Methods 0.000 description 2
- 230000037431 insertion Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000013528 artificial neural network Methods 0.000 description 1
- 230000003416 augmentation Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000003116 impacting effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000011017 operating method Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000010979 ruby Substances 0.000 description 1
- 229910001750 ruby Inorganic materials 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000029305 taxis Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
- G07G5/00—Receipt-giving machines
-
- 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
- G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
- G07G1/00—Cash registers
- G07G1/12—Cash registers electronically operated
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
- G07G1/00—Cash registers
- G07G1/12—Cash registers electronically operated
- G07G1/14—Systems including one or more distant stations co-operating with a central processing unit
Landscapes
- Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Finance (AREA)
- Cash Registers Or Receiving Machines (AREA)
Abstract
Dispositif de traitement de données (10) d'un terminal de vente, TDV (12), comprenant : au moins un port d'entrée (28) pour recevoir des données d'impression de TDV (12) en provenance d'un TDV (12) ; des moyens de traitement de données configurés pour construire, à partir des données d'impression de TDV (12), des données d'impression modifiées, lesquelles comprennent des informations additionnelles, lesdites informations additionnelles comprenant un numéro identifiant le dispositif de traitement de données et un numéro de série généré par le dispositif de traitement de données ; au moins un port de sortie (30) pour transmettre les données d'impression modifiées vers une imprimante (14) ; et un module de communication (44) configuré pour transmettre les données d'impression modifiées, vers un serveur distant (1). Sont également présenté un système de traitement de données et un procédé de fonctionnement d'un système de vente.
Description
Dispositif de traitement de données pour terminal de vente
L'invention concerne le domaine de la gestion des transactions par un terminal de vente, et en particulier l’intégration de services en ligne à un terminal de vente sans impacter son intégrité.
Etat de la technique
La gestion des tickets et reçus produits par des terminaux de vente (TDV — en anglais
Point of Sale, POS) est devenue de plus en plus difficile pour les clients ainsi que pour le détaillant. Les tickets de caisse contiennent des informations importantes telles que les références des articles achetés, leurs prix et le montant total ; ils peuvent aussi inclure la date et l'adresse de la transaction ou même des promotions. Cependant, le client ne garde son ticket que pour un court instant et ne digére qu’un minimum de toutes les informations. En outre, il est possible qu’il perde le ticket, sous forme de papier imprimé, alors qu’il aurait souhaité le garder.
Le détaillant/commerçant rencontre des problèmes similaires. Les promotions indiquées sur les tickets sont ignorées et la gestion et analyse des tickets est laborieuse.
En outre, les programmes de fidélisation client n’ont guère de succès : les clients sont lassés des cartes de fidélité et ne veulent plus dévoiler leurs informations personnelles.
Ces problèmes peuvent être résolus en intégrant des services en ligne au TDV qui permettrait au client de payer en ligne, sauvegarder ses tickets, et au commerçant d’avoir une meilleure vue sur ses comptes. La multitude d’anciens TDV en circulation rend la modernisation de ceux-ci difficile et coûteuse, puisqu'il faut modifier le logiciel du TDV ou ajouter du matériel informatique onéreux.
L’objet de la présente invention est de proposer un dispositif et un système qui modernise un TDV évitant les désavantages nommés ci-dessus.
Description générale de l’invention
Conformément à l'invention, un dispositif de traitement de données (DTD) d’un terminal de vente (TDV) comprend : au moins un port d’entrée pour recevoir des données d’impression de TDV en provenance d’un TDV ; des moyens de traitement de données configurés pour construire, à partir des données — d’impression de TDV, des données d’impression modifiées, lesquelles comprennent des informations additionnelles, lesdites informations additionnelles comprenant un numéro identifiant le DTD et un numéro de série généré par le DTD ;
au moins un port de sortie pour transmettre les données d’impression modifiées vers une imprimante ; et un module de communication configuré pour transmettre les données d'impression modifiées, vers un serveur distant.
Le dispositif selon l'invention est configuré pour enrichir, ou augmenter, un flux de données d'impression de TDV afin de conférer des fonctionnalités additionnelles. La fonction principale du DTD selon invention est de permettre le paiement à partir d’un terminal mobile d'utilisateur (tel qu’un smartphone). Le DTD va donc construire un flux de données modifiées qui comprend des données additionnelles en vue de réaliser une opération donnée à partir du ticket imprimé, notamment réaliser une opération de paiement.
Le DTD envoie également les données d'impression modifiées vers un serveur distant, pour y conserver, et exploiter, les tickets digitaux, et également pour gérer le paiement en ligne.
La relation (« matching ») entre le ticket imprimé (ticket physique) et le ticket digital sur le serveur se fait au moyen du numéro de DTD et du numéro de série de ticket.
Ainsi, le présent DTD permet d'intercepter le flux physique d'impression pour d’abord injecter un QR code sur le ticket afin d’accéder à une webapplication de paiement, et va en également remonter au serveur distant les données d’impression modifiées, afin — d'extraire le montant a payer du ticket et relier le ticket digital au ticket physique lu par le terminal du client.
De préférence, les informations additionnelles définissent une url.
Selon les variantes, les informations additionnelles comprennent des informations relatives à un paiement en ligne, un sondage, un jeu concours et/ou une promotion.
Avantageusement, les informations additionnelles sont ajoutées aux données d'impression sous la forme d’une représentation d'image encodée avec les informations additionnelles, l’image encodée étant apte à être lue et décodée par un terminal mobile d’un utilisateur. La représentation d’image encodée est par exemple de type QR code.
Selon un autre aspect, on propose un système de traitement de données, comprenant : au moins un dispositif de traitement de données tel que divulgué dans le présent texte, et un serveur distant configuré pour stocké des données d’impression modifiées reçues de l’au moins un dispositif de traitement de données et pour permettre la réalisation d’une opération au moyen d’un terminal mobile d’utilisateur ayant accès à une impression des données d'impression modifiées.
Ainsi le DTD va enrichir le ticket pour lui apporter des informations additionnelles qui vont permettre, à l’aide d’un terminal mobile, de déclencher/réaliser une opération donnée, typiquement un paiement.
Selon un mode de réalisation, le serveur distant est configuré pour déterminer le montant d’une transaction de PDV dans les données d’impression modifiées, et pour initier une opération de paiement, lors d’une demande à partir d’un terminal mobile d'utilisateur, après une authentification des données d'impression sur base du numéro identifiant le dispositif de traitement de données et du numéro de série.
Selon un autre aspect, l'invention concerne un procédé de fonctionnement d’un système de vente selon la revendication 8. Des modes de réalisation sont précisés aux revendications 9 à 12.
Brève description des figures
D’autres particularités et caractéristiques de l'invention ressortiront de la description détaillée d'au moins un mode de réalisation avantageux présenté ci-dessous, à titre — d'illustration, en se référant aux dessins annexés. Ceux-ci montrent : [Fig. 1] : un diagramme de principe d’un mode de réalisation de l'invention, dans lequel un terminal de vente est associé au présent dispositif de traitement de données ; [Fig. 2] : un organigramme d’un mode de réalisation d’un procédé de fonctionnement du présent dispositif de traitement de données ; [Fig. 3] : a) une vue d’un ticket modifié par le dispositif de traitement de données d’un terminal de vente et b) une vue détaillant la construction du ticket modifié ; [Fig. 4] : un diagramme du dispositif de traitement de données de la figure 1 ; [Fig. 5] : un diagramme fonctionnel illustrant les modules du dispositif de traitement de données d’un terminal de vente selon un mode de réalisation ; et [Fig. 6]: un diagramme de principe d’un autre mode de réalisation de l'invention comprenant un terminal de vente associé au présent dispositif de traitement.
Description détaillée de modes de réalisation préférés
Un mode de réalisation du présent dispositif de traitement de données 10 dans son environnement typique d’utilisation sera maintenant décrit en référence aux figures 1 à 5. Le dispositif de traitement de données 10 est conçu pour être associé à un terminal de vente 12 et son imprimante 14 afin de générer des tickets modifiés 16 comprenant des informations additionnelles, en particulier du type un QR code facilitant le paiement par un téléphone mobile d’un client. Un tel ticket est aussi dit « augmenté »
Le TDV 12 (« Point of sale » en anglais) est ici un terminal conventionnel configuré pour générer des données d’impression relatif à une/des transactions traitées par le TDV 12.
Le TDV 12 peut être basé sur n’importe quelle technologie. Un intérêt du DTD 10 est sa capacité à être associé à tout type de TDV 12, car aucune interopérabilité n’est requise.
En effet, le DTD 10 ne communique pas avec le TDV 12, il reçoit simplement un flux de données d’impression provenant de celui-ci.
Le dispositif de traitement de données 10, noté DTD, est une unité informatique configurée pour l'exécution de modules de programmes informatiques, en particulier des modules de traitement de données. Tel qu'il est utilisé dans le présent document, le terme "module" fait référence à la logique du programme informatique et/ou aux données permettant de fournir la fonctionnalité spécifiée. Un module peut être mis en œuvre dans par un matériel informatique, un microprogramme et/ou un logiciel.
Dans la variante de la Fig.4, le DTD 10 est comprend au moins un processeur 20 couplé à un bus 22, auquel sont également couplés une mémoire 24, un dispositif de stockage 26 et un port d’entrée 28 et un port de sortie 30. Le processeur 20 peut être un processeur polyvalent général tel qu'un processeur INTEL x86, ARM, Atmel AVR ou POW
ERPC compatible-CPU. Le dispositif de stockage 24 est, dans un mode de réalisation, un dispositif de mémoire à semi-conducteurs mais peut également être tout autre dispositif capable de stocker des données, tel qu'un disque dur, un disque compact (CD) ou un
DVD inscriptible, ou un dispositif de mémoire à semi-conducteurs. La mémoire peut être, par exemple, un micrologiciel, une mémoire morte (ROM), une mémoire vive non volatile (NVRAM), et/ou une mémoire vive. Le dispositif de stockage et/ou la mémoire peuvent contenir des instructions, des modules et des données utilisées par le processeur. Les types de systèmes informatiques utilisés par le DTD 10 peuvent varier en fonction du mode de réalisation et de la puissance de traitement utilisée par l’unité.
Ainsi, par exemple, le système informatique du DTD peut être un système informatique intégré à base de microcontrôleur, un ordinateur à carte unique ou un ordinateur personnel standard (PC). En particulier, un ordinateur à carte unique de type ARM possédant 4 cœurs 1.5 GHz, 8 Go de RAM et 64 Go de stockage et utilisant une distribution Linux spécifique optimisée nommée Stellar OS.
Le DTD 10 comprend au moins un port d’entrée 28 pour recevoir des données d'impression de TDV en provenance du TDV 12. Le DTD 10 (via son port d’entrée 28) est connecté avec le TDV de manière filaire (ex. port USB, port Ethernet etc.) ou sans fil (par ex. un port sans fil tel que Wifi, USB sans fil, Bluetooth, Ethernet sans fil, GPRS, EDGE,
HSPA, LTE, WiMax) ou une autre technologie de port de communication. Les données d'impression de TDV sont destinées à l'imprimante 14, mais sont interceptées par le DTD 10.
Le DTD 10 comporte des moyens de traitement de données, en particulier, un module d'analyse 40 configuré lire les données d’impression de TDV dans leur format brut et identifier certaines caractéristiques telles que des caractères ou codes. Ces caractères peuvent être spécifiques au langage d'impression ou création de code, et vise à repérer des éléments de code/caractères, ou séquences/combinaisons, pour déterminer la position d'insertion de données additionnelles.
Avantageusement le module d’analyse 40 identifie la fin du ticket dans le flux d'impression représenté par un élément caractéristique (ou séquence) dans les données d'impression, par ex. le caractère V définit la fin de ticket dans le langage SPOS. On souhaite effectivement ajouter des données additionnelles après la fin du corps de ticket, pour ne pas en modifier l’intégrité. La protection de l’intégrité du ticket lors de l'augmentation est impérative, car toute modification du ticket original serait susceptible d’être considérée comme frauduleuse.
Les moyens de traitement de données du DTD 10 comprennent de plus un module d’enrichissement 42 configuré pour construire des données d’impression modifiées a partir des données d’impression. En particulier, le module d’enrichissement injecte dans les données d'impression des informations additionnelles. Les données d'impression originales sont ainsi modifiées ou augmentées par le module d’enrichissement 42 en y ajoutant des informations additionnelles. Les données d'impression modifiées seront envoyées vers l'imprimante 14 et imprimées au lieu des données originales. Le DTD 10 — sélectionne les informations à ajouter selon des instructions fournies par l’utilisateur.
Dans une variante, les instructions du module d’enrichissement 42 se basent sur les informations extraites des données d'impression, par exemple si les données d'impression contiennent un certain article le module d’enrichissement 42 ajoutera certaines informations additionnelles.
En pratique, les informations additionnelles peuvent comprendre des informations relatives à un paiement en ligne, un sondage, un jeu concours, une promotion ou définir une url.
Afin de permettre l’authentification ultérieure des données d’impression correspondant à un ticket émis par le TDV, les informations additionnelles comprennent un numéro identifiant le DTD et un numéro de série généré par le DTD. Ces deux numéros forment un couple unique. Le numéro de série est unique, généré par un compteur de ticket du
DTD, et ne correspond pas forcément au numéro de ticket qui peut être généré par le
TDV lui-même.
Dans une variante, les moyens de traitement de données du DTD 10 comprennent un module de chiffrage 54 configuré pour chiffrer le numéro de série et/ou le numéro identifiant le DTD, et c’est le ou les numéros chiffrés qui font partie des informations additionnelles. II n’est donc pas possible à un tiers de deviner les couples d’authentification associé aux données d'impression modifiées.
Typiquement, les informations additionnelles comprennent encore une adresse internet (url), qui va permettre l’accès à une page internet pour la réalisation d’une opération en ligne sur base d’une impression des données d’impression modifiées (donc du ticket imprimé correspondant aux données d’impression modifiées).
Préférablement, les informations additionnelles sont ajoutées aux données — d'impression sous la forme d’une représentation d'image encodée avec les informations additionnelles, en particulier du type QR code, l'image encodée étant apte à être lue et décodée par un terminal mobile d’un client.
Lorsque le QR code est lu et décodé, le terminal du client est dirigé vers une page d’accueil (sur base de l’url) affichant les informations du ticket. Sur la page d’accueil, le client peut être invité à indiquer ou s'inscrire à des programmes de fidélisation pour profiter de réductions. De plus, la page d'accueil peut se trouver sur l’internet et affichée dans un navigateur ou être affichée dans une application mobile installée sur le smartphone du client. Le commerçant peut afficher ses promotions, jeux concours ou sondages à travers la page d'accueil ou l’application mobile.
Le DTD 10 comprend au moins un port de sortie 30 pour transmettre les données d'impression modifiées vers l'imprimante 14. Selon les variantes, le DTD 10 est connecté à l’imprimante de manière filaire ou sans fil (mêmes possibilités de technologies que pour le port d’entrée28.
L’imprimante produit un ticket modifié 16 qui peut être lu et décodé par un terminal mobile (typiquement un téléphone mobile/smartphone) d’un client. Ceci permettra au commerçant d’intégrer des services en ligne, comme le paiement en ligne, même si le
TDV 12 n’intègre pas une telle fonctionnalité de manière native.
Dans ce contexte, les numéros de série de ticket et/ou le numéro identifiant de DTD, intégrés au ticket, vont permettre de retrouver les informations correspondantes sur le serveur distant, donc de retrouver l’opération correspondante et de la valider. Une fois la version digitale du ticket de caisse retrouvée / identifiée en ligne sur base de ces numéros, on pourra passer à la phase de paiement.
Un exemple de construction de ticket modifié 16 est présenté Fig. 3. Les données d'impression générées par le TDV 12 comprennent des instructions correspondant à la partie de ticket 13 : il s’agit de la partie originale ou existante. La partie créée dans le
DTD 10, dite partie injectée ou enrichie est indiquée 11 et prend ici la forme d’un QR code. La partie injectée 11 est ajoutée à la fin du ticket original 13, formant le ticket augmenté 16 (Fig.3 a) produit par l'imprimante 14. Comme indiqué précédemment, les données correspondant au QR code encodant les numéros de série ticket et de DTD sont par exemple injectées dans les données d’impression originales à la fin de la partie de code correspondant au ticket original et avant l’instruction de coupe.
Comme indiqué en Fig. 1, le DTD 10 comprend avantageusement un module de communication 44 configuré pour transmettre les données d’impression modifiées/augmentées dans leur format brut vers un serveur distant1 à travers une connexion Internet. Le serveur distant 1 est connecté au DTD par tout port approprié, (par ex. USB, Ethernet ou un port sans fil telle que USB sans fil, Bluetooth, Ethernet sans fil).
Dans le serveur distant 1, les données d'impression modifiées sont converties vers un format .txt, celui-ci peut être lu et analysé par des autres programmes informatiques, et un format .html pour afficher le ticket augmenté. Le couple unique lié au ticket et l’url dans le QR code sont utilisés dans le serveur distant 1 pour relier le ticket aux formats xt et .html au QR code du ticket augmenté imprimé. Le format .txt est analysé par un module « Parser » dans le serveur distant 1 qui identifie les différentes informations du ticket, telles que les articles achetés, leur nombre, le total etc. L'analyse syntaxique du ticket ainsi que la version .html du ticket permettent de diriger le terminal mobile du client vers une landing page affichant le ticket et permettant le paiement en ligne, lorsque le QR code est lu et décodé. L'utilisation du couple unique reliant le ticket — augmenté physique au ticket digital permet au DTD 10 une impression continue même si le serveur distant 1 est déconnecté, puisque l’url comprenant le couple unique est encodée dans le QR code indépendamment du serveur distant 1. L’url devient fonctionnelle lorsque le serveur distant 1 se reconnecte et relie le ticket digital à l’url.
Un mode de réalisation d’un procédé de fonctionnement d’un système de vente comprenant le TDV 12, le DTD 10 et l'imprimante 14 est illustré à la Fig. 2. Le procédé comprend principalement les étapes suivantes : — Suite à une vente, le TDV 12 enregistre une transaction et génère un flux de données d'impression comprenant des informations de transaction . Le DTD 10 reçoit ces données d’impression du TDV 12, étape 100 ; — à l’étape suivante 102, le DTD 10 traite les données d’impression. Il analyse/lit le contenu /code/instructions des données d’impression, et génère des données d'impression modifiées, lesquelles comprennent des informations additionnelles (avec l’url, et le couple de numéros ticket / DTD) ; — à l’étape 106, les données d'impression modifiées sont envoyées vers l'imprimante 14 pour impression d’un ticket — les données d’impression modifiées sont également envoyées — étape 104 - vers le serveur distant 1, lequel comprend une base de données de transactions/tickets 60.
Bien que dans la Fig. 2 on a représenté d’abord l’étape 104 puis l'étape 106, elles peuvent être réalisées dans l’ordre inverse ou en parallèle.
Les informations additionnelles sont ajoutées aux données d’impression sous la forme d’une représentation d’image encodée avec les informations additionnelles. Un code à barres à deux dimensions, en particulier du type QR code, peut être choisit comme image codée apte à être lue et déchiffrée par un terminal mobile d’un utilisateur.
Comme indiqué ci-dessus, le TDV 12 est conçu de manière à gérer des transactions (ventes), par exemple : lister les articles achetés, calculer le sous-total, les taxes et le total, ajouter les informations de la transaction, comme le numéro de transaction ou le nom du commerce, et générer et transmettre les données d'impression à l’imprimante.
Le TDV 12 comprend typiquement un composant générant des données d'impression en tant que flux de données d'impression codé à l'aide d'un langage de commande d'impression et transmis par un port de communication. Le flux de données d'impression peut utiliser n'importe quel langage de contrôle d'impression, tel que
Epson ESC/POS, JavaPOS, OPOS, Starline, PostScript, PCL, ou autres. Le port de communication du point de vente peut être, par exemple, un port RS-232, un port USB, un port parallèle, un port Ethernet ou un port sans fil telle que USB sans fil, Bluetooth,
Ethernet sans fil, GPRS, EDGE, HSPA, LTE, WiMax ou une autre technologie de port de communication. Le système informatique, par exemple, peut être un ordinateur personnel exécutant une application de terminal de vente telle que MICROS RES ou un navigateur web tel que MICROSOFT INTERNET EXPLORER qui permet à l'utilisateur final de gérer des transactions de terminal de vente en utilisant une application de terminal de vente basée sur le cloud ou sur le web telle que VIVONET HALO.
Un schéma fonctionnel illustrant les modules du DTD 10 est présenté à la Fig. 5. Les modules décrits ci-dessous font généralement référence à une logique incorporée dans du matériel et/ou des microprogrammes, et/ou à une collection d'instructions logicielles, ayant éventuellement des points d'entrée et de sortie, écrites dans un langage de programmation tel que, par exemple, Java, Ruby, Ruby on Rails, Lua, C, C#, et/ou C++. Ils peuvent être compilés et liés dans un programme exécutable, installés dans une bibliothèque de liens dynamiques, ou peuvent être écrits dans un langage de programmation interprété tel que, par exemple, BASIC, Perl ou Python. On notera que ces modules peuvent être appelés par d'autres et/ou par eux-mêmes, et/ou qu'ils peuvent être invoqués en réponse à des événements détectés ou à des interruptions.
Dans un mode de réalisation, ces modules sont stockés dans le dispositif de stockage 26 et chargés dans la mémoire 24 pour être exécutés par le processeur 20.
Comme illustré sur à la Fig. 5, le DTD 10 comprend un module d’analyse 40 qui lit le flux de données d’impression intercepté au format brut, le plus souvent au format ESC/POS, etidentifie des éléments/codes/instructions caractéristiques (ex. trait de coupe ou la fin du ticket) dans les données d’impression. En identifiant la fin du ticket, il est possible d'augmenter le ticket sans altérer le ticket orignal. De préférence, en analysant les données d'impression, le module d’analyse 40 identifie également l’existence de caractères/instructions/codes susceptible d'indiquer qu’il s’agit de données — d'impression qui ne correspondent pas à une action, opération ou transaction devant donner lieu à une action de la part d’un client. Par exemple, les TDV génèrent typiquement des tickets dits « Z », qui constituent des récapitulatifs de transactions et sont destinés au commerçant, donc ne nécessite pas d’augmentation.
Le DTV 10 comprend un module générateur de code graphique 46 configuré pour — générer un code graphique. Le code graphique peut être un code à barres 1D, un code à barres 2D ou un autre type de code à barres/image adapté à l'intégration d'informations qui peuvent être scannées et interprétées optiquement. Lorsque le module générateur de code graphique 46 est configuré pour générer un code à barres 2D, le code à barres 2D peut être généré en utilisant n'importe quelle symbologie de code 2D telle que le code QR, Datamatrix, le code à barres couleur haute capacité, le
ShotCode, le SPARQCode ou toute autre symbologie de code 2D.
Le module d’enrichissement 42 est configuré pour ajouter les informations supplémentaires/additionnelles aux données d’impression brutes lorsqu'il est appelé pour ce faire par le module d’analyse 40. Dans un mode de réalisation, les données supplémentaires comprennent un ou plusieurs des éléments suivants : (1) une representation codée d'un appel à l'action demandant à un client recevant le reçu d'utiliser son téléphone mobile pour scanner un code-barres 2D imprimé sur le reçu afin de s'inscrire au programme de fidélité du commerçant ou de gagner des récompenses ou des cadeaux de fidélité s'il est déjà inscrit, (2) une représentation codée d'un code- barres 2D, et (3) une représentation codée d'instructions demandant au client recevant le ticket de télécharger un scanner de codes-barres 2D pour son téléphone mobile s'il ne possède pas déjà un scanner de codes-barres 2D. Le module d’enrichissement 42 produit donc des informations enrichies, correspondant typiquement aux informations originales du ticket, auxquelles on a ajouté des informations additionnelles (comprenant notamment une url, le numéro de série de ticket et le numéro du DTD).
Le DTD 10 comprend un module de codage de langage d'impression 48 configuré pour coder les informations additionnelles générées par le module 42 dans un format défini de langage d'imprimante particulier, pour insertion dans les données d’impression interceptées. Les informations a coder peuvent étre des données de texte ou des données d'image. Par exemple, le module de codage de langage d'impression 48 est configure pour coder les informations enrichies dans le format de langage d'imprimante
ESC/POS d'Epson. En outre, le module de codage 48 peut être configuré pour convertir des données d’impression d’un langage d’imprimante vers un autre langage d'imprimante, ce qui facilite l’interopérabilité.
Du fait de la différence de vitesse entre le processeur et le périphérique, les données envoyées vers un périphérique sont le plus souvent stockées dans des mémoires tampon ou buffer 50 en attente de leur envoi effectif vers le périphérique, pour épargnerau DTD 10 l'attente due à la différence de débits. De même, les données reçues de l'extérieur sont souvent rassemblées dans des tampons 50, en attente de leur traitement par le DTD 10 pour des raisons d'efficacité, et aussi pour éviter leur perte.
Le module de communication 44 est configuré pour transférer les données d’impression entrantes vers la mémoire tampon 50, et les données d'impression modifiées vers le serveur distant 1 et vers l'imprimante 14. Le module de communication 44 gère ainsi la communication, resp. le transfert de données/informations, dans le DTD 10 et vers l'extérieur. Dans une variante, il est possible de connecter plusieurs imprimantes au DTD 10 et le module de communication 44 gère l’envoi des données d’impression vers les différentes imprimantes
Le module de configuration de stockage 52 gère la sauvegarde de différentes données utilisées par le DTD 10 et les autres modules, comme des informations utilisées par le module générateur de code graphique 46.
Il apparaitra à l'homme du métier que d'autres modes de réalisation peuvent comporter des modules différents et/ou autres que ceux décrits ici, et que les fonctionnalités peuvent être réparties entre les modules d'une manière différente.
Dans une variante, un module NFC (en anglais « near-field communication ») peut être installé dans le DTD 10. Ce module NFC permettrait l’utilisation d’émetteur-récepteur
NFC pour transmettre des données à un terminal (téléphone mobile) du client, sans impression du ticket physique. Le client reçoit les données du reçu en approchant son terminal mobile compatible avec la technologie NFC à l’émetteur-récepteur NFC. Ces données comprennent typiquement une adresse internet (url) qui arrive sur une page d’accueil (landing page) permettant le téléchargement du ticket et le paiement.
Dans une autre variante, le DTD 10 comprend une unité d’affichage (intégrée au boitier du DTD ou séparée) pour afficher le QR code. L'impression du reçu physique est évitée, puisque le client peut lire et décoder le QR code avec son terminal mobile à partir de
I'écran.
Un autre intérêt de l'invention est de permettre la collecte des informations de transaction dans une base de données 60. Comme indiqué précédemment, les données — d’impression modifiées au format brut, typiquement ESC/POS, sont converties vers un format .txt et un format .html dans le serveur 1. La version .html est utilisé pour afficher le ticket digital sur la page d’accueil, vers laquelle le terminal du client est dirigé lorsque le QR code est lu et déchiffré. La version .txt peut être utilisé par d’autres logiciels informatiques, en particulier des logiciels d’analyse syntaxique.
Les tickets produits par des différents TDV 12 peuvent avoir différentes structures, par exemple le nombre d’article peut être placé avant l’article ou après l’article juste avant le prix et d’autres variations de la structure sont possible. L'utilisation du logiciel dit « Parser » permet l’analyse syntaxique du ticket, permettant d’identifier les différentes informations du ticket, tes que la nature des articles achetés, leur référence, le nombre — d’articles, le total etc, ceux-ci sont utilisé dans la création de la landing page de l’url dans le QR code. De plus, le module « Parser » dans le serveur distant 1 permet la conversion du fichier .txt, dans lequel le ticket peut être structuré de différentes manière, vers un fichier .xml ou préférablement JSON, qui aura une structure unique indépendante de la structure initiale. Le Parser essayera de « comprendre » (ou — interpréter) le ticket en se basant sur les positions de texte, mais le logiciel s'adapte lorsqu’il y a des variations. De cette manière le Parser peut reconnaître un ensemble d'éléments de données comprenant, sans s'y limiter, la date et l'heure imprimées comme partie du ticket, le terminal de vente à partir duquel le ticket a été imprimé, l'entité pour laquelle le ticket a été imprimé, l'identité du membre du personnel responsable de la transaction, le numéro de table ou le numéro d'invité pour lequel le ticket est imprimé, le numéro de série du ticket, l'identifiant de transaction de la transaction pour laquelle le ticket est imprimé, les descriptions d'articles, les quantités d'article, les frais d'article, le sous-total, les lignes de taxes (TVA ou autres) et le montant total. Les éléments reconnus par le Parser sont restructurés et un fichier xml / JSON correspondant est créé. D'autres éléments de données de transaction sont possibles en fonction du type d'environnement de vente au détail/service dans lequel le TDV 12 est déployé. La version .xml ou JSON peut être réutilisé pour établir la base de données 60.
Les différents éléments d’information sont mis en correspondance avec les champs correspondants. Par exemple, le nom du magasin peut être mis en correspondance avec un champ de nom de magasin, le nom d'un article acheté peut être mis en correspondance avec un champ d'article acheté, le prix d'un article peut être mis en correspondance avec un champ de prix d'article, une taxe peut être mise en correspondance avec un champ de taxe, un total peut être mis en correspondance avec un champ de total, etc. Ainsi, informations des tickets peuvent être reçues dans le serveur 1, analysées et stockées, sans que le commerçant, le client ou une autre entité ne scanne optiquement un ticket physique.
D’ailleurs, un spécialiste en données peut utiliser les fichiers .xml ou JSON pour établir la base de données en attribuant de différents labels uniques à des articles, de sorte que les labels sont comptés à travers tous les fichiers xml ou JSON des tickets sur le serveur 1. Comme il y a une multitude de façons d’écrire ces labels, un réseau de neurones peut être entrainé pour détecter de nouvelles formes de labels et les réunir avec les labels du système pour le même article. Dans une variante, le Parser est installé comme module
Parser dans le DTD 10.
Les informations ainsi collectées peuvent ensuite être présentées à un utilisateur (par exemple, le client, le commerçant et/ou une autre partie autorisée) via une interface utilisateur fournie par un terminal informatique. Différents types de données peuvent être affichés à différents types d'utilisateurs. Par exemple, un utilisateur peut être en mesure d'accéder à certaines ou à toutes les données et de les visualiser sous forme de tableau et/ou de graphique via un site Web sur Internet, par l'intermédiaire d'un — navigateur hébergé sur un dispositif informatique de l'utilisateur ou via une application (par exemple, une application pour téléphone) chargée sur un dispositif informatique tel qu'un téléphone. En option, le site web permet à l'utilisateur d'ajouter des métadonnées concernant les données présentées. Par exemple, l'utilisateur peut éventuellement catégoriser et annoter les données du reçu, au niveau du reçu et/ou de la ligne du reçu. Ces métadonnées générées par l'utilisateur sont également stockées dans la base de données 60 en association avec les données du reçu et/ou l'utilisateur afin de pouvoir être rappelées et interrogées ultérieurement.
Dans une variante, le site web ou l'application sont configurés pour permettre à l'utilisateur d'interroger des informations statistiques sur toutes les parties ou des parties sélectionnées des informations collectées à partir des tickets pour un client, un commerçant et/ou un magasin particulier. Par exemple, en option, des outils automatisés de finances personnelles sont fournis par l'intermédiaire de ces informations, qui peuvent inclure des graphiques (courbes, histogrammes, etc.). Par exemple, les graphiques peuvent fournir à un utilisateur, tel qu'un consommateur, des informations sur les achats ventilés dans des catégories telles que l'automobile, la restauration, l'épicerie, les loisirs, les dépenses de logement, etc. En option, le système permet également aux commerçants d'afficher, d'interroger et de générer des rapports qui résument les informations d'achat sur une base magasin par magasin, pour tous les magasins, etc. Le consommateur peut recevoir des informations agrégées sur ses habitudes de dépenses, éventuellement sur une période de temps sélectionnée. De même, un commerçant peut voir qui sont ses meilleurs clients, combien ils dépensent sur une période donnée et à quels types d'articles ils consacrent leur argent.
La Fig.6 illustre un mode de la réalisation dans lequel le DTD 10 est configuré pour recevoir des données relatives à des transactions/achats en ligne. La configuration de base est celle de la Fig. 1, et l’environnement comprend en outre une plateforme de commande/achat en ligne 62 opérée par le serveur distant 1. Les commandes en ligne 62 se font à travers un site web ou application mobile dédiée.
En outre lorsque le client fait un paiement en ligne et désire recevoir un reçu, le serveur distant 1 envoie les données d'impression de ce reçu vers le DTD 10, qui les envoie vers l'imprimante. Le cas échéant, le DTD 10 convertit les données d’impression du format e-pos vers le format ESC/POS avant envoi vers l'imprimante 14. Dans une variante, dans laquelle le DTD 10 est connecté avec plusieurs imprimantes, il est possible de configurer le DTD 10 pour envoyer les commandes en ligne vers une imprimante dédiée et les commandes provenant du TDV vers une autre imprimante. Ceci permet par exemple l'envoi des commandes à livrer d’un restaurant vers une imprimante situé en cuisine au lieu de l'imprimante principale.
Les données d'impression des commandes en ligne ne doivent pas nécessairement être modifiées car le paiement de ces commandes se fait immédiatement à travers le site web ou "application mobile dédiée.
Les données d’impression sont traitées de manière similaire aux autres données dans le serveur 1 et sont envoyées à travers le DTD 10 vers l’imprimante 14.
Claims (12)
1. Dispositif de traitement de données (10) d’un terminal de vente, TDV (12), comprenant : au moins un port d’entrée (28) pour recevoir des données d’impression de TDV (12) en provenance d’un TDV (12) ; des moyens de traitement de données configurés pour construire, à partir des données d’impression de TDV (12), des données d'impression modifiées, lesquelles comprennent des informations additionnelles, lesdites informations additionnelles comprenant un numéro identifiant le dispositif de traitement de données et un numéro de série généré par le dispositif de traitement de données ; au moins un port de sortie (30) pour transmettre les données d'impression modifiées vers une imprimante (14) ; et un module de communication (44) configuré pour transmettre les données d'impression modifiées, vers un serveur distant (1).
2. Dispositif selon l’une quelconque des revendications précédentes, dans lequel les informations additionnelles définissent une url.
3. Dispositif selon la revendication 1 ou 2, dans lequel les informations additionnelles comprennent des informations relatives à un paiement en ligne, un sondage, un jeu concours et/ou une promotion.
4. Dispositif selon la revendication 1, 2 ou 3, dans lequel les informations additionnelles sont ajoutées aux données d'impression sous la forme d’une représentation d'image encodée (11) avec les informations additionnelles, l’image encodée étant apte à être lue et décodée par un terminal mobile d’un utilisateur.
5. Dispositif selon la revendication 4, dans lequel la représentation d’image encodée est de type QR code.
6. Système de traitement de données, comprenant : au moins un dispositif de traitement de données (10) selon l’une quelconque des revendications précédentes, et un serveur distant (1) configuré pour stocké des données d'impression modifiées reçues de l’au moins un dispositif de traitement de données et pour permettre la réalisation d’une opération au moyen d’un terminal mobile d’utilisateur ayant accès à une impression des données d’impression modifiées.
7. Système selon la revendication 6, dans lequel le serveur distant est configuré pour déterminer le montant d’une transaction de PDV dans les données d’impression modifiées, et pour initier une opération de paiement, lors d’une demande à partir d’un terminal mobile d’utilisateur, après une authentification des données d'impression sur base du numéro identifiant le dispositif de traitement de données et du numéro de série.
8. Procédé de fonctionnement d’un système de vente comprenant un terminal de vente, TDV (12), un dispositif de traitement de données, DTD, (10), en particulier selon l’une quelconque des revendications précédentes, un serveur distant (1) et une imprimante (14), dans lequel ; le DTD (10) reçoit du TDV (12) des données d’impression comprenant des informations de transaction ; le DTD (10) traite les données d’impression et génère, à partir des données d'impression, des données d’impression modifiées comprenant des informations additionnelles, les informations additionnelles comprenant un numéro identifiant le dispositif de traitement de données et un numéro de série généré par le dispositif de traitement de données ; les données d’impression modifiées sont envoyées vers l'imprimante (14) pour impression d’un ticket ainsi que vers une base données (60) sur le serveur distant
(1).
9. Procédé selon la revendication 8, dans lequel les informations additionnelles comprennent des informations relatives à un paiement en ligne, un sondage, un jeu concours et/ou une promotion ; et les informations additionnelles sont ajoutées aux données d'impression sous la forme d’une représentation d’image encodée avec les informations additionnelles, l’image encodée étant apte à être lue et décodée par un terminal mobile d’un utilisateur.
10. Procédé selon la revendication 9, dans lequel la représentation d'image encodée est un code à barres à deux dimensions, en particulier un QR code.
11. Procédé selon la revendication 8, 9 ou 10, dans lequel le serveur distant est configuré pour déterminer le montant d’une transaction de PDV dans les données d'impression modifiées, et pour initier une opération de paiement, lors d’une demande à partir d’un terminal mobile d’utilisateur, après une authentification des données d’impression sur base du numéro identifiant le dispositif de traitement de données et du numéro de série.
12. Procédé selon l’une quelconque des revendications 8 à 11, dans lequel le DTD est configuré pour recevoir des données d'impression relatives à des transaction en ligne (62), et les transmettre à la base de données (60).
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| LU501747A LU501747B1 (fr) | 2022-03-29 | 2022-03-29 | Dispositif de traitement de données pour terminal de vente |
| ES202330233U ES1307889U (es) | 2022-03-29 | 2023-02-15 | Dispositivo de tratamiento de datos para un terminal de venta |
| DE202023101103.9U DE202023101103U1 (de) | 2022-03-29 | 2023-03-08 | Datenverarbeitungsanlage für Verkaufsterminals |
| GB2303856.5A GB2618208A (en) | 2022-03-29 | 2023-03-16 | Data processing device for sales terminal |
| NL2034465A NL2034465A (en) | 2022-03-29 | 2023-03-29 | Data processing device for sales terminal |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| LU501747A LU501747B1 (fr) | 2022-03-29 | 2022-03-29 | Dispositif de traitement de données pour terminal de vente |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| LU501747B1 true LU501747B1 (fr) | 2023-09-29 |
Family
ID=81327510
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| LU501747A LU501747B1 (fr) | 2022-03-29 | 2022-03-29 | Dispositif de traitement de données pour terminal de vente |
Country Status (5)
| Country | Link |
|---|---|
| DE (1) | DE202023101103U1 (fr) |
| ES (1) | ES1307889U (fr) |
| GB (1) | GB2618208A (fr) |
| LU (1) | LU501747B1 (fr) |
| NL (1) | NL2034465A (fr) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120316950A1 (en) * | 2011-06-10 | 2012-12-13 | Jeffrey Laporte | System and method for augmentation of retail pos data streams with transaction information |
| US20140122272A1 (en) * | 2008-07-08 | 2014-05-01 | Omnilync, Inc. | Transaction data capture device and system |
| CN105321272B (zh) * | 2015-11-04 | 2018-06-26 | 北京果皮移动科技有限公司 | 一种根据收银机交易数据打印动态二维码的方法及装置 |
| US20180181951A1 (en) * | 2016-12-22 | 2018-06-28 | AppCard, Inc. | Apparatus and methods for processing commercial transaction data |
| US20210049576A1 (en) * | 2018-03-13 | 2021-02-18 | Fobisuite Technologies, Inc. | Point-of-sale system and method |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7581676B2 (en) * | 2005-01-14 | 2009-09-01 | Douglas Brian Skor | Method and apparatus for purchasing and dispensing products |
| US20130112743A1 (en) * | 2011-09-13 | 2013-05-09 | Rob Cavin | Device to analyze point of sale print stream and encode transaction data |
| JP6588197B2 (ja) * | 2014-10-31 | 2019-10-09 | 株式会社ユビレジ | 管理プログラム、管理方法、レシート管理装置、情報処理システム及びサービス提供装置 |
| US11132667B1 (en) * | 2020-12-10 | 2021-09-28 | Copper Inc. | Data processing systems and methods for transmitting and modifying data via a smart data cable |
-
2022
- 2022-03-29 LU LU501747A patent/LU501747B1/fr active IP Right Grant
-
2023
- 2023-02-15 ES ES202330233U patent/ES1307889U/es active Pending
- 2023-03-08 DE DE202023101103.9U patent/DE202023101103U1/de active Active
- 2023-03-16 GB GB2303856.5A patent/GB2618208A/en active Pending
- 2023-03-29 NL NL2034465A patent/NL2034465A/en unknown
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140122272A1 (en) * | 2008-07-08 | 2014-05-01 | Omnilync, Inc. | Transaction data capture device and system |
| US20120316950A1 (en) * | 2011-06-10 | 2012-12-13 | Jeffrey Laporte | System and method for augmentation of retail pos data streams with transaction information |
| CN105321272B (zh) * | 2015-11-04 | 2018-06-26 | 北京果皮移动科技有限公司 | 一种根据收银机交易数据打印动态二维码的方法及装置 |
| US20180181951A1 (en) * | 2016-12-22 | 2018-06-28 | AppCard, Inc. | Apparatus and methods for processing commercial transaction data |
| US20210049576A1 (en) * | 2018-03-13 | 2021-02-18 | Fobisuite Technologies, Inc. | Point-of-sale system and method |
Also Published As
| Publication number | Publication date |
|---|---|
| GB2618208A (en) | 2023-11-01 |
| ES1307889U (es) | 2024-05-24 |
| NL2034465A (en) | 2023-10-12 |
| DE202023101103U1 (de) | 2023-07-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20120316950A1 (en) | System and method for augmentation of retail pos data streams with transaction information | |
| US8788350B2 (en) | Handling payment receipts with a receipt store | |
| US20180121899A1 (en) | Method of enhancing point-of-sale systems | |
| US20200294081A1 (en) | Systems and methods for intelligent coupon distribution, redemption, and tracking | |
| US20120215691A1 (en) | System and method for payment transfer | |
| US20190370847A1 (en) | Method and systems relating to the use of blockchain and self-sovereign identity for gift cards, rewards, and incentives programs | |
| WO2018047982A1 (fr) | Procédé de paiement et système de paiement utilisant des informations de code | |
| US20180005200A1 (en) | Generation and delivery of digital receipts based on user preferences and transaction related data | |
| EP2701099A1 (fr) | Réseau informatique permettant de commander dynamiquement les codes RQ | |
| US20170132656A1 (en) | System and method for decoding scanned abbreviation data | |
| JP2016507819A (ja) | デジタルｑｒレシートを生成および報告するための方法およびデバイス | |
| WO2013062481A1 (fr) | Collecte anonyme, présentation et enchère inverse d'objets de type reçus de paiement | |
| US20180165716A1 (en) | Advertisement exchange network | |
| US20230259936A1 (en) | System and method for using intelligent codes in conjunction with non-fungible tokens | |
| LU501747B1 (fr) | Dispositif de traitement de données pour terminal de vente | |
| US20170243253A1 (en) | Advertisement exchange network | |
| KR102058934B1 (ko) | 전자 영수증들의 저장 및 액세스를 위한 시스템 및 방법 | |
| EP2166501A1 (fr) | Système pour émettre, gérer et accéder à des factures électroniques simplifiées avec taxe à la valeur ajoutée | |
| FR2982389A1 (fr) | Procede et systeme d'archivage de donnees contenues dans un document a imprimer | |
| FR2968882A1 (fr) | Procede et dispositif de production de facturettes dematerialisees | |
| WO2015044393A1 (fr) | Méthode de traitement de données transactionnelles, terminal, serveur et programmes d'ordinateur correspondants | |
| TR202009148A2 (tr) | Bi̇r akilli pos si̇stemi̇ | |
| WO2015087066A1 (fr) | Système et procédé de compensation de bon de réduction | |
| KR20090013447A (ko) | 광고를 이용한 가치발급 방법 및 시스템과 이를 위한기록매체 | |
| FR3004832A1 (fr) | Procede de gestion d’un compte de fidelite d’un client dans un systeme de vente |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FG | Patent granted |
Effective date: 20230929 |