FR3076036A1 - Procede, dispositif et programme de gestion de preuves d'achat - Google Patents

Procede, dispositif et programme de gestion de preuves d'achat Download PDF

Info

Publication number
FR3076036A1
FR3076036A1 FR1763004A FR1763004A FR3076036A1 FR 3076036 A1 FR3076036 A1 FR 3076036A1 FR 1763004 A FR1763004 A FR 1763004A FR 1763004 A FR1763004 A FR 1763004A FR 3076036 A1 FR3076036 A1 FR 3076036A1
Authority
FR
France
Prior art keywords
purchase
proof
characteristic
user
terminal
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.)
Ceased
Application number
FR1763004A
Other languages
English (en)
Inventor
Emmanuel Le Huerou
Francois Toutain
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.)
Orange SA
Original Assignee
Orange SA
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
Application filed by Orange SA filed Critical Orange SA
Priority to FR1763004A priority Critical patent/FR3076036A1/fr
Priority to EP18836485.5A priority patent/EP3729353A1/fr
Priority to US16/956,120 priority patent/US20210073752A1/en
Priority to PCT/FR2018/053331 priority patent/WO2019122653A1/fr
Publication of FR3076036A1 publication Critical patent/FR3076036A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/04—Payment circuits
    • G06Q20/045—Payment circuits using payment protocols involving tickets
    • G06Q20/0457—Payment circuits using payment protocols involving tickets the tickets being sent electronically
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/903—Querying
    • G06F16/9035—Filtering based on additional data, e.g. user or group profiles
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/04—Payment circuits
    • G06Q20/047—Payment circuits using payment protocols involving electronic receipts
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Databases & Information Systems (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • Computational Linguistics (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un procédé de gestion de preuves d'achats comprenant des étapes de collecte d'au moins une preuve d'achat, d'extraction d'au moins une caractéristique de l'achat à partir de la au moins une preuve d'achat collectée, d'identification d'une opération bancaire sur un compte bancaire de l'utilisateur par mise en correspondance de la au moins une caractéristique de la preuve d'achat extraite avec une caractéristique d'une opération sur un compte bancaire de l'utilisateur, et lorsqu'une opération est identifiée, de mémorisation dans une base de données de la preuve d'achat en association avec l'opération.

Description

Procédé, dispositif et programme de gestion de preuves d'achat.
Domaine technique L'invention appartient au domaine des télécommunications et concerne en particulier un système de gestion des preuves d'achat.
Art antérieur
Chaque dépense chez un marchand est accompagnée d'une preuve d'achat, comme par exemple un ticket de caisse, une facture, une garantie ou toute autre forme de reçu.
En 2015, 70% des Français préfèrent régler leurs achats par carte bancaire plutôt qu'en espèce ou par chèque. Ainsi, chaque achat donne lieu à l'émission d'une facturette de carte bancaire et d'un ticket de caisse.
De tels justificatifs s'accumulent rapidement dans le portefeuille des utilisateurs, au point que la recherche d'un justificatif particulier est fastidieuse lorsque l'utilisateur souhaite par exemple retourner un article et qu'une preuve d'achat est nécessaire. En effet, le ticket de caisse nécessaire peut se trouver parmi d'autres tickets semblables dans un portefeuille, un sac à main ou encore être resté au fond d'un cabas, ou avoir simplement été jeté. Ainsi, la gestion de telles preuves d'achat n'est pas commode.
Différentes solutions s'appuyant sur des technologies de communication numérique ont été proposées. Par exemple, de plus en plus de commerces proposent à leurs clients des tickets de caisse dématérialisés accessibles sur un compte client ou envoyés par email après le passage en caisse. De tels systèmes sont souvent liés à une carte de fidélité permettant d'identifier rapidement le client afin de lui transmettre la preuve d'achat. Toutefois, de telles pratiques ne sont pas généralisées et elles impliquent pour l'utilisateur la création d'une carte de fidélité que l'utilisateur peut ne pas souhaiter. Les preuves d'achat fournies au client par les différents commerces qu'il fréquente sont alors hétérogènes : une partie des tickets consiste en des tickets papier, alors qu'une autre partie des preuves d'achat est disponible en ligne, sur un site Internet appartenant à l'enseigne ou sur sa messagerie électronique. Ainsi, lorsqu'un utilisateur recherche un ticket particulier, il doit se rappeler la nature de la preuve d'achat qui lui a été fournie afin de rechercher soit dans les tickets papiers disponibles, soit sur un site Internet particulier, soit sur sa messagerie électronique. Une telle recherche représente souvent une perte de temps pour l'utilisateur. La gestion des preuves d'achat n'est donc toujours pas optimale.
Les systèmes actuels de gestion des preuves d'achats présentent également des inconvénients lorsqu'il s'agit de comptabiliser des dépenses réalisées et/ou les trier par catégorie. En effet, il est long et fastidieux pour un utilisateur de regrouper les dépenses par objet à partir de tickets de caisse.
Il existe donc un besoin pour un procédé de gestion de preuves d'achat qui ne présente pas les inconvénients de l'art antérieur. Résumé de l'invention A cet effet, il est proposé un procédé de gestion de preuves d'achats comprenant des étapes de : Collecte d'au moins une preuve d'achat,
Extraction d'au moins une caractéristique de l'achat à partir de la au moins une preuve d'achat collectée,
Identification d'une opération bancaire sur un compte bancaire de l'utilisateur par mise en correspondance de la au moins une caractéristique de la preuve d'achat extraite avec une caractéristique d'une opération bancaire sur un compte bancaire de l'utilisateur,
Lorsqu'une opération est identifiée, mémorisation dans une base de données de la preuve d'achat en association avec l'opération.
Le procédé permet ainsi de collecter des preuves d'achats effectués par un utilisateur, telles que des reçus ou des tickets de caisse et de les mettre en correspondance avec des opérations bancaires enregistrées sur le compte bancaire de utilisateur avant de les transmettre au terminal de l'utilisateur. Le procédé facilite ainsi la gestion des preuves d'achat en permettant notamment de les associer avec l'opération bancaire correspondante avant de les transmettre vers un terminal de l'utilisateur.
De cette façon, le procédé permet d'effectuer des regroupements de preuves d'achat selon un critère extrait d'une preuve d'achat. Par exemple, des preuves d'achats effectués chez un même commerçant peuvent être regroupées selon le nom du commerce tel qu'il apparaît sur la preuve d'achat. Il est avantageux d'effectuer des regroupements de preuves d'achat basés sur une caractéristique comprise dans une preuve d'achat plutôt que des regroupements basés sur des caractéristiques d'opérations bancaires. En effet, les preuves d'achats offrent souvent plus d'informations concernant la transaction que l'opération enregistrée sur un compte bancaire.
Les preuves d'achat sont par exemple collectées à partir d'une ou plusieurs bases de données dans laquelle sont stockées sous forme électronique des preuves d'achat transmises par un système d'encaissement ou un terminal de l'utilisateur tel qu'un smartphone.
Au sens de l'invention, on entend par une preuve d'achat tout document relatif à une transaction, comme par exemple un ticket de caisse, un bon de garantie, un coupon de réduction ou tout autre reçu.
Selon une réalisation particulière, le procédé de gestion comprend en outre une étape de transmission vers une entité de stockage, d'une caractéristique de la transaction et d'une représentation de la preuve d'achat associée. L'entité de stockage est par exemple un terminal de l'utilisateur. De cette façon, lorsque le procédé est mis en œuvre par un serveur, une représentation de la preuve d'achat est transmise vers un terminal de l'utilisateur. Lorsque le procédé est mis en œuvre par un terminal, comme par exemple un smartphone de l'utilisateur, la preuve d'achat est transmise vers un serveur permettant son stockage en association avec l'opération bancaire correspondante.
Selon un mode de réalisation particulier, le procédé est tel que l'étape de transmission comprend la transmission d'un message selon un protocole de messagerie instantanée.
De cette façon, une version électronique d'un reçu est reçue par un utilisateur sur son terminal immédiatement après un paiement effectué chez un marchand. L'utilisation d'un système de messagerie instantanée pour transmettre les preuves d'achats améliore l'interactivité, la preuve d'achat pouvant être reçue par un terminal de l'utilisateur immédiatement après un achat.
Selon une réalisation particulière, le message instantané transmis vers l'entité de stockage comprend un critère de regroupement déterminé selon la au moins une caractéristique extraite de la preuve d'achat.
Une telle disposition permet un regroupement pertinent des preuves d'achat sur l'entité de stockage. Ainsi, lorsque l'entité de stockage est un terminal de l'utilisateur, ce dernier peut accéder à des preuves d'achats regroupées par exemple selon la dénomination commerciale du commerce dans lequel a été effectué l'achat, telle qu'elle figure sur la preuve d'achat. Le regroupement peut également être réalisé selon d'autres critères extraits de la preuve d'achat, comme par exemple la dénomination d'un produit acheté, une date, un identifiant d'une entreprise ou tout autre critère souhaitable.
Selon une réalisation particulière, au moins une partie de l'adresse d'émission du message est sélectionnée selon le critère de regroupement déterminé selon la au moins une caractéristique extraite de la preuve d'achat. La plupart des applications de messagerie permettent de trier les messages reçus selon l'adresse de l'expéditeur de façon à les présenter sous la forme d'une conversation. En transmettant un message dont l'adresse de l'expéditeur est renseignée selon une caractéristique d'une preuve d'achat, le procédé permet un regroupement automatique par l'application de messagerie des reçus correspondant à des achats effectués par exemple chez un même marchand. La gestion des preuves d'achat est ainsi facilitée et les terminaux équipés d'un logiciel de messagerie instantanée ne nécessitent pas d'adaptation particulière pour regrouper les preuves d'achat.
Le regroupement des preuves d'achats selon un critère particulier permet d'appliquer des traitements ultérieurs spécifiques, comme le calcul d'une somme des dépenses chez un commerçant particulier par exemple.
Selon un mode particulier de réalisation, le procédé est tel qu'au moins une caractéristique extraite est la date et le montant de la transaction, l'étape de mise en correspondance se basant sur ladite date et ledit montant.
Les preuves d'achat collectées sont analysées de façon à en extraire au moins une caractéristique, comme par exemple le montant de la transaction, sa date, son bénéficiaire ou encore la dénomination du marchand. Il est ainsi possible de mettre en correspondance une preuve d'achat avec une opération bancaire sur le compte de l'utilisateur à partir du montant de la transaction et de sa date par exemple.
Selon un mode de réalisation particulier, le procédé est tel que l'étape de collecte comprend l'obtention d'un reçu électronique transmis par un dispositif d'encaissement et/ou par un terminal associé à l'utilisateur.
Les preuves d'achats peuvent être transmises par le terminal de l'utilisateur, par exemple par l'intermédiaire d'un message instantané comprenant une photographie de la preuve d'achat prise par l'utilisateur. Les preuves d'achat peuvent également être transmises par un dispositif d'encaissement du marchand sous la forme d'un reçu électronique de paiement, par exemple par courrier électronique ou tout autre moyen de transmission ad'hoc.
De façon correspondante au procédé de gestion, l'invention concerne également un procédé d'archivage d'au moins une preuve d'achat sur un terminal de communication tel qu'il comprend une étape de réception d'au moins un message comprenant une caractéristique d'une opération bancaire et une représentation d'une preuve d'achat associée, une étape d'obtention d'un critère de regroupement déterminé selon une caractéristique extraite de la preuve d'achat, et une étape de mémorisation de la preuve d'achat reçue selon le critère de regroupement de la preuve d'achat obtenue.
Les preuves d'achats sont ainsi mémorisées sur le terminal de l'utilisateur en relation avec l'opération bancaire correspondante. Le terminal obtient un critère de regroupement permettant de regrouper des preuves d'achat correspondant à un tel critère. Le critère peut être obtenu à partir du message, par exemple il peut être compris dans l'adresse de l'émetteur du message. L'adresse d'émission d'un tel message est configurée selon un critère extrait de la preuve d'achat considérée. De cette manière, les preuves d'achat reçues par le terminal sont automatiquement regroupées sous la forme d'une conversation de messagerie instantanée sous une forme particulièrement intuitive pour l'utilisateur. Le critère peut également être obtenu par une analyse de la preuve d'achat par le terminal, par exemple par une reconnaissance optique de caractère ou une analyse lexicographique de la preuve d'achat afin d'en extraire une caractéristique.
Selon un autre aspect, l'invention concerne un dispositif de gestion de preuves d'achats remarquable en ce qu'il comprend:
Un module de collecte adapté pour collecter au moins une preuve d'achat,
Un module d'analyse adapté pour extraire au moins une caractéristique de l'achat à partir de la au moins une preuve d'achat collectée,
Un module d'identification adapté pour identifier une opération bancaire sur un compte bancaire de l'utilisateur par mise en correspondance de la au moins une caractéristique de la preuve d'achat extraite avec une caractéristique d'une opération sur un compte bancaire de l'utilisateur,
Une base de données, adaptée pour mémoriser la preuve d'achat en association avec l'opération lorsqu'une opération est identifiée.
Selon une réalisation particulière, le dispositif de gestion comprend en outre un module de communication adapté pour transmettre une caractéristique de la transaction et une représentation de la preuve d'achat associée vers un terminal de l'utilisateur.
Selon un mode particulier de réalisation du dispositif de gestion, le module de collecte est un dispositif d'acquisition d'image associé au dispositif et/ou un module de communication adapté pour recevoir une preuve d'achat transmise au travers d'un réseau de communication. L'invention concerne aussi un dispositif d'archivage d'au moins une preuve d'achat sur un terminal de communication tel qu'il comprend un module de communication adapté pour recevoir au moins message comprenant une caractéristique d'une opération bancaire réalisée sur un compte bancaire de l'utilisateur et une représentation d'une preuve d'achat associée, un module d'obtention d'un critère de regroupement déterminé selon une caractéristique extraite de la preuve d'achat, et un module de stockage de ladite preuve d'achat dans une mémoire du terminal selon le critère de regroupement. L'invention concerne aussi un terminal comprenant un dispositif d'archivage tel que décrit précédemment.
Selon une réalisation particulière, l'invention concerne un serveur comprenant un dispositif de gestion ou un terminal comprenant un dispositif de gestion tel que décrit ci-dessus.
Dans un mode particulier de réalisation, les différentes étapes du procédé selon l'invention sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise également un programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de gestion et/ou les étapes du procédé d'archivage, lorsque ledit programme est exécuté par un processeur.
Un tel 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.
Enfin, l'invention concerne un support d'informations lisible par un processeur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de gestion et/ou les instructions pour l'exécution du procédé d'archivage.
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 dise) 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.
Les différents modes ou caractéristiques de réalisation précités peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux étapes des procédés de gestion et d'archivage tels que définis ci-dessus.
Les serveurs, terminaux, dispositifs, programmes et supports d'informations présentent au moins des avantages analogues à ceux conférés par le procédé auquel ils correspondent.
Brève description 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 particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
La figure 1 illustre une architecture adaptée pour mettre en oeuvre le procédé de gestion conformément à un mode de réalisation particulier,
La figure 2 représente les différentes étapes du procédé de gestion selon un mode particulier de réalisation,
La figure 3 illustre l'architecture d'un dispositif d'obtention selon un mode de réalisation particulier.
Description détaillée
La figure 1 représente une architecture adaptée pour mettre en oeuvre le procédé de gestion selon un mode particulier de réalisation.
La figure 1 montre un terminal de communication mobile 100 adapté pour se connecter à un réseau de communication 101. Le terminal 100 est par exemple un terminal mobile de type smartphone adapté pour se connecter au réseau de communication 101 par l'intermédiaire d'un réseau d'accès cellulaire ou Wi-Fi non représenté. Le réseau 101 est par exemple un réseau de communication IMS (IP Multimedia Subsystem) comprenant un serveur d'application 102 adapté pour échanger des messages avec le terminal 100 selon un protocole de messagerie instantané conforme au standard RCS (Rich Communication Service).
La figure 1 montre également une base de données 103 comprenant des enregistrements relatifs à des opérations bancaires réalisées sur un compte bancaire de l'utilisateur du terminal 100. De tels enregistrements correspondent par exemple à des paiements effectués par l'utilisateur du terminal 100 via une carte de crédit, un moyen de paiement sans contact ou encore un virement. La base de données 103 peut faire partie d'un système d'information bancaire d'une banque dans laquelle l'utilisateur dispose d'un compte. Ainsi, lorsque l'utilisateur effectue un paiement chez un marchand en utilisant par exemple sa carte bancaire, un enregistrement est ajouté à la base de données 103.
La figure 1 montre aussi une base de données 104 dans laquelle sont stockés des preuves d'achats correspondant à des achats effectués par l'utilisateur du terminal 100. Par exemple, lorsque l'utilisateur du terminal 100 effectue un achat chez un marchand, le marchand délivre une preuve d'achat. Il s'agit par exemple d'un ticket de caisse, d'une facture, d'un bon de garantie ou d'un reçu quelconque. Une telle preuve d'achat comprend de manière classique la date de l'achat, le montant payé, et l'objet de l'achat. Les preuves d'achats mémorisées dans la base de données 104 sont par exemple des preuves d'achat obtenues via le terminal 100 ou transmises par un système d'encaissement d'un marchand. Elles peuvent être stockées sous toute forme souhaitable, comme par exemple sous la forme d'une image capturée à partir d'un appareil photo ou d'un document texte. Les preuves d'achats sont stockées dans la base de données 104 en association avec un identifiant de l'utilisateur ayant effectué le paiement. En l'espèce, les preuves d'achat mémorisées dans la base de données 104 sont associées à l'utilisateur du terminal 100, par exemple en utilisant comme identifiant le numéro de téléphone du terminal 100. Ainsi, il est possible pour le serveur 102, par exemple au moyen d'une requête SQL (Structured Query Language) adaptée, d'obtenir des preuves d'achat associées à l'utilisateur du terminal 100.
Le serveur 102 peut également obtenir auprès de la base de données 103 des informations relatives à des opérations bancaires réalisées par l'utilisateur du terminal 100. Pour cela, les opérations bancaires de la base de données 103 sont mémorisées en association avec le numéro de téléphone du terminal 100. Ainsi, à partir du numéro de téléphone du terminal 100, le serveur 102 peut obtenir à la fois des preuves d'achats et des opérations bancaires associées à l'utilisateur.
Selon l'invention, lorsque le serveur 102 détecte l'ajout d'une nouvelle preuve d'achat dans la base de données 104, il recherche une opération correspondante dans la base de données d'opérations bancaires 103. Pour cela, le serveur 102 effectue une analyse de la preuve d'achat afin d'en extraire des données. Une telle analyse comprend par exemple une reconnaissance optique de caractères lorsque la preuve d'achat est sous la forme d'une image. Lorsque la preuve d'achat est dans un format adapté pour être analysée, par exemple dans un format texte, il est procédé à l'extraction des caractéristiques de la preuve d'achat. L'extraction des caractéristiques comprend par exemple la recherche de la date de l'achat et de son montant. L'étape d'extraction peut également permettre au serveur 102 d'obtenir l'objet de l'achat, c'est-à-dire par exemple la désignation, la quantité et le prix unitaire des marchandises achetées.
Les opérations bancaires comptabilisées sur un compte bancaire comprennent généralement au moins une date et un montant. Ainsi, à partir de la date et du montant d'un achat obtenu à partir d'une preuve d'achat mémorisée dans la base de données 104, le serveur 102 recherche dans la base de données 103 une transaction correspondante, c'est-à-dire possédant la même date et le même montant. Lorsqu'une transaction correspondante est identifiée, le serveur mémorise la correspondance de façon à pouvoir fournir à l'utilisateur la preuve d'achat associée à l'opération bancaire. Ainsi, l'utilisateur dispose des preuves d'achats associées aux opérations bancaires enregistrées sur son compte, ce qui facilite leur gestion par l'utilisateur.
Selon un mode particulier de réalisation, le serveur 102 transmet au terminal une représentation de la preuve d'achat en association avec une caractéristique de l'opération bancaire associée. Par exemple, après qu'une opération bancaire de l'utilisateur ait été identifiée par mise en correspondance de la au moins une caractéristique de la preuve d'achat extraite avec une caractéristique de l'opération sur un compte bancaire de l'utilisateur, le serveur 102 envoie un message instantané au terminal 100. Le message envoyé comprend par exemple, la date de l'opération, son montant et une représentation numérique du ticket de caisse correspondant.
Selon un mode de réalisation particulier, le message par lequel le serveur 102 transmet au terminal la preuve d'achat et une caractéristique de la transaction est configuré de manière à ce qu'il soit regroupé, lors de son affichage par le terminal, avec d'autres messages partageant une caractéristique commune. Par exemple, le message est configuré de manière à ce qu'il soit regroupé avec d'autres messages reçus relatifs à une transaction effectuée chez un même commerçant. Le regroupement correspondant par exemple à une vue sous forme d'une conversation avec le commerçant. Pour cela, le serveur 102 configure un identifiant d'expéditeur particulier dans le message instantané. Par exemple, lorsque le message transmis par le serveur 102 est un message SIP, l'entête « from » du message est configurée avec une URI (Universal Ressource Identifier) et/ou un « Display Name » correspondant à la caractéristique selon laquelle est regroupé le message, par exemple un identifiant du commerçant chez qui un achat a été effectué. De cette manière, les preuves d'achats correspondant à des achats effectués dans un même établissement commercial sont regroupées sur le terminal au sein d'une même conversation de messagerie instantanée.
Selon une réalisation particulière, le procédé de gestion peut être mis en œuvre par le terminal 102.
Les étapes du procédé de gestion vont maintenant être décrites en détail, dans un mode de réalisation particulier, en référence à la figure 2.
Lors d'une première étape 200, il est procédé à la collecte d'au moins une preuve d'achat. Pour cela, selon un premier mode de réalisation, le serveur 102 obtient au moins une preuve d'achat auprès d'une base de données telle que la base de données 104 représentée sur la figure 1. Cette base de données peut correspondre à un compte email de l'utilisateur vers lequel sont envoyées des preuves d'achat par un système d'encaissement d'un établissement commercial. Par exemple, l'utilisateur peut avoir une carte de fidélité chez un commerçant grâce à laquelle les preuves d'achats sont envoyées par le commerçant vers une adresse email renseignée par l'utilisateur lors de la création de sa carte. La collecte des preuves d'achat peut alors se faire par un accès au compte mail correspondant afin d'y rechercher des messages comprenant des preuves d'achat. Pour cela, le serveur 102 accède à un compte de messagerie électronique grâce à des données d'authentification fournies au préalable par l'utilisateur. L'identification de messages comprenant des preuves d'achat se fait par exemple en analysant le contenu des messages selon des techniques d'extraction connues afin d'y détecter des mots clefs caractéristique d'une transaction tels que « facture », « commande », etc... Pour identifier plus précisément des messages susceptibles de comprendre des preuves d'achats, le serveur 102 peut accéder à une base de données comprenant des opérations bancaires de l'utilisateur, comme par exemple la base de données 103. A partir de la base de données 103, le serveur détermine des dates auxquelles ont eu lieu des transactions et le montant de telles transactions et recherche parmi les messages reçus sur le compte email de l'utilisateur des messages comprenant une telle date et un tel montant. Lorsque des messages correspondant sont identifiés, les preuves d'achat qu'ils contiennent sont collectées.
Selon un mode de réalisation particulier, les preuves d'achat sont collectées auprès du terminal 100. Lorsque le serveur détermine qu'une nouvelle opération bancaire a lieu sur un compte bancaire de l'utilisateur, il transmet un message au terminal dans le but d'obtenir la preuve d'achat correspondante. Pour cela, le serveur 102 émet par exemple un message instantané conforme à un protocole de messagerie instantané comprenant un message invitant l'utilisateur à photographier et transmettre le ticket de caisse correspondant à la transaction détectée. Selon une réalisation particulière, le paiement est réalisé sans contact grâce à un module NFC (Near Field Communication) du terminal et le terminal obtient automatiquement une preuve de l'achat qu'il transmet à destination du serveur 102 au moyen d'un message adapté.
Selon un mode particulier de réalisation, le serveur 102 collecte des preuves d'achat par l'intermédiaire d'un serveur de médiation d'un système d'information bancaire chargé de collecter des preuves d'achat auprès de différentes sources. A l'étape 201, le serveur 102 analyse les preuves d'achat collectées pour en extraire des informations caractéristiques. En particulier le serveur 102 procède à l'extraction de la date figurant sur la preuve d'achat et de son montant. Une telle extraction est réalisée selon des techniques connues adaptées au format de la preuve d'achat. Par exemple, lorsque la preuve d'achat est une image numérisée, l'extraction comprend par exemple une analyse par reconnaissance optique de caractères puis d'une recherche d'une date, d'une heure et d'un montant à partir d'expressions régulières configurées de manière à permettre la reconnaissance de chaînes de caractères correspondant à la date, l'heure et/ou le montant figurant sur la preuve d'achat. Lorsque la preuve d'achat est un fichier structuré, comme par exemple un fichier au format XML, des techniques d'analyse connues adaptées au format de fichier structuré sont mises en oeuvre dans le même but. Par exemple, le serveur peut mettre en oeuvre un analyseur XML DOM (Document Objet Model).
Lors d'une étape 202, le serveur identifie une opération bancaire sur un compte bancaire de l'utilisateur par mise en correspondance de la au moins une caractéristique de la preuve d'achat extraite avec une caractéristique d'une opération sur un compte bancaire de l'utilisateur. Pour cela, à partir des données extraites d'une preuve d'achat, comme par exemple le montant, la date et l'heure d'un achat, le serveur 102 recherche dans une base de données d'opérations bancaires telle que la base de données 103, une opération correspondante, c'est-à-dire une opération dont la date, l'heure et le montant correspondent à la date, l'heure et le montant extrait de la preuve d'achat. D'autres caractéristiques peuvent être utilisées pour faire la correspondance entre une preuve d'achat et une opération bancaire. Par exemple, le type de moyen de paiement utilisé, la dénomination commerciale ou l'identité bancaire du commerçant peuvent être utilisés pour mettre en correspondance une preuve d'achat avec une opération bancaire lorsqu'ils apparaissent sur la preuve d'achat. Selon une réalisation particulière, le serveur peut extraire une date d'expiration associée à la preuve d'achat. Par exemple, lorsque la preuve d'achat est un coupon de réduction ou un avoir, elle peut comporter une date limite d'utilisation. Le serveur 102 peut alors programmer la transmission d'un message de rappel au terminal de l'utilisateur lorsque la date limite d'utilisation déterminée à partir de l'analyse de la preuve d'achat devient proche, par exemple une semaine avant son expiration. La gestion des bons de réductions ou des avoirs est ainsi facilitée.
Lorsqu'une opération est identifiée lors de l'étape de mise en correspondance 202, le serveur 102 mémorise la preuve d'achat en association avec l'opération bancaire correspondante dans une base de données lors d'une étape 203. De cette façon, un utilisateur peut obtenir à tout moment des preuves d'achats associées à ses opérations bancaires.
Selon un mode de réalisation particulier, le procédé comporte une étape 204 au cours de laquelle il est procédé à la transmission par le serveur, d'une caractéristique d'une opération bancaire et d'une représentation de la preuve d'achat associée. Ainsi, lorsqu'un utilisateur effectue un achat dans un commerce en utilisant un moyen de paiement électronique tel qu'une carte bancaire ou un téléphone mobile équipé d'un système de paiement sans contact, il peut recevoir immédiatement, en provenance du serveur 102, un message instantané comprenant un récapitulatif de son achat, c'est-à-dire les données de la transaction bancaires en association avec les données contenues dans la preuve d'achat. La gestion des preuves d'achat, et en particulier leur recherche et la comptabilité associée est ainsi facilitée.
Selon une réalisation particulière, les étapes de collecte 200, d'extraction 201, d'identification d'une opération bancaire 202 et de mémorisation 203 d'une preuve d'achat en association avec une opération bancaire sont réalisées par un terminal, comme par exemple par le terminal 100 de la figure 1. Dans un tel cas de figure, le terminal obtient par exemple des opérations bancaires à partir d'un serveur bancaire. Les preuves d'achats sont quant à elles collectées par le terminal, par exemple à partir d'une image capturée par un appareil photo du terminal, ou bien à partir d'un serveur. Le terminal comprend alors une base de données dans laquelle sont mémorisées les preuves d'achats en association avec des opérations bancaires. Une telle base de données peut être par exemple une base de données destinée à mémoriser des messages instantanés reçus par une application de messagerie instantanée, ou tout autre base de données sur le terminal ou accessible depuis le terminal.
Selon un mode particulier de réalisation, le serveur 102 comprend un agent conversationnel de type « chatbot » adapté pour échanger des messages en langage naturel avec le terminal 100 conformément à un protocole de messagerie instantanée. L'agent conversationnel notamment transmet à l'étape 204, le message comportant une caractéristique de la transaction et une représentation de la preuve d'achat associée. Un tel agent conversationnel est en outre adapté pour recevoir des messages en provenance du terminal 100, telles que des messages comportant des commandes de regroupement des preuves d'achat selon un critère particulier. De tels messages comprennent des commandes formulées en langage naturel par l'utilisateur et interprétés par l'agent conversationnel du serveur 102. Par exemple, l'utilisateur peut formuler une commande pour obtenir des statistiques sur les achats qu'il a effectués chez le marchand correspondant, une commande pour effacer les informations d'achat devenues obsolètes, une commande pour obtenir des détails sur le service après-vente correspondant à un achat particulier, etc.
Selon un autre aspect, et de façon correspondante au procédé de gestion, l'invention concerne un procédé d'archivage de preuves d'achat dans un terminal de communication tel que le terminal 102. Les étapes du procédé d'archivage sont décrites en référence à la figure 4 et comprennent une étape 400 de réception d'au moins un message comprenant au moins une caractéristique d'une opération bancaire et une représentation d'une preuve d'achat associée, une étape 401 d'obtention d'un lcritère de regroupement issu d'une caractéristique extraite de la preuve d'achat et une étape 402 de mémorisation de ladite représentation de la preuve d'achat en association avec la au moins une caractéristique de l'opération bancaire. L'identifiant de regroupement est déterminé selon une caractéristique extraite de la preuve d'achat de façon à proposer à l'utilisateur un regroupement des preuves d'achat qui soit pertinent. Il peut être obtenu par une analyse de la preuve d'achat reçue comme décrit précédemment, ou à partir du message reçu. En particulier, l'identifiant de regroupement peut être, selon une réalisation particulière, le champ d'adresse de l'émetteur renseigné dans le message. Une telle adresse est alors sélectionnée selon une caractéristique extraite de la preuve d'achat de manière à ce que par exemple, des preuves d'achats relatives à un même commerçant soient automatiquement regroupées. La plupart des logiciels et applications de messagerie instantanée regroupent automatiquement les messages selon l'adresse de l'expéditeur. Une telle disposition permet un regroupement automatique des preuves d'achat au sein d'une conversation de messagerie instantanée. L'utilisateur retrouve ainsi plus facilement les preuves d'achats et le terminal ne nécessite pas d'être spécifiquement adapté.
Selon un mode particulier de réalisation du procédé d'archivage, le procédé comprend en outre une étape d'obtention d'une seconde caractéristique extraite à partir d'au moins une preuve d'achat et une étape de transmission vers un dispositif de gestion de preuves d'achat selon l'invention d'un message comprenant une commande de regroupement selon ladite seconde caractéristique extraite. Le terminal peut obtenir la seconde caractéristique extraite à partir d'un message envoyé par un dispositif de gestion de preuves d'achat comprenant au moins une seconde caractéristique susceptible d'être utilisée pour regrouper des preuves d'achat. Par exemple, il peut s'agir d'une date ou de l'identifiant d'un produit figurant sur la preuve d'achat, ou d'une localisation géographique du commerce dans lequel a été réalisé l'achat.
Selon une réalisation particulière, le procédé d'archivage comprend en outre des étapes d'obtention d'une caractéristique extraite à partir d'une preuve d'achat, de recherche de caractéristiques correspondantes parmi un ensemble de preuves d'achats mémorisées sur le terminal, de sélection des preuves d'achat dont les caractéristiques correspondent, et d'affichage desdites preuves d'achat dont les caractéristiques correspondent regroupées selon la caractéristique extraite. Une telle disposition permet l'application de traitements sur un ensemble de preuves d'achat possédant une caractéristique commune. Cela permet par exemple de calculer une somme de dépenses réalisées pour un produit particulier, chez un commerçant particulier ou à une date particulière.
Selon un mode particulier de réalisation du procédé d'archivage, le procédé peut comprendre une étape de transmission d'une commande vers un dispositif de gestion de preuves d'achat, la commande comprenant par exemple une instruction adaptée pour provoquer la suppression d'une preuve d'achat du dispositif de stockage dans lequel elle est mémorisée.
Selon un mode de réalisation particulier, le regroupement de preuves d'achats selon un second critère extrait d'une preuve d'achat est réalisé par le terminal sur lequel le procédé d'archivage est mis en oeuvre.
La figure 3 représente l'architecture d'un dispositif 300 adapté pour mettre en oeuvre le procédé de gestion selon l'invention.
Le dispositif comprend un espace de stockage 301, par exemple une mémoire MEM, une unité de traitement 302 équipée par exemple d'un processeur PROC. L'unité de traitement peut être pilotée par un programme 303, par exemple un programme d'ordinateur PGR, mettant en oeuvre le procédé de gestion tel que décrit dans l'invention en référence à la figure 2, et notamment les étapes de collecte d'au moins une preuve d'achat, d'extraction d'au moins une caractéristique de l'achat à partir de la au moins une preuve d'achat collectée, d'identification d'une opération bancaire sur un compte bancaire de l'utilisateur par mise en correspondance de la au moins une caractéristique de la au moins une preuve d'achat extraite avec une caractéristique d'une opération sur un compte bancaire de l'utilisateur, et, lorsqu'une opération est identifiée, de mémorisation dans une base de données de la preuve d'achat en association avec l'opération. Selon un mode de réalisation particulier, le programme d'ordinateur met en œuvre une étape de transmission vers un terminal de l'utilisateur, d'une caractéristique de la transaction et d'une représentation de la preuve d'achat associée. À l'initialisation, les instructions du programme d'ordinateur 303 sont par exemple chargées dans une mémoire RAM (Random Access Memory en anglais) avant d'être exécutées par le processeur de l'unité de traitement 302. Le processeur de l'unité de traitement 302 met en œuvre les étapes du procédé de gestion selon les instructions du programme d'ordinateur 303.
Pour cela, outre la mémoire 301 et le processeur 302, le dispositif comprend un module (304, 309) de collecte adapté pour collecter au moins une preuve d'achat. Le module de collecte est par exemple une interface de communication 309 adaptée pour recevoir une preuve d'achat transmise par un terminal ou un serveur de médiation au travers d'un réseau de communication. Il peut s'agit d'une interface réseau Ethernet ou d'une interface réseau sans fil de type WiFi, 2G, 3G ou 4G. Selon une réalisation particulière, le module de collecte peut être un module d'accès à une base de données contenant des preuves d'achat à partir d'une requête SQL adaptée. Selon une réalisation particulière, le module de collecte est un dispositif d'acquisition vidéo, tel qu'une caméra adaptée pour capturer des images, et en particulier pour numériser des preuves d'achat papier.
Le dispositif 300 comporte en outre un module 305 d'analyse adapté pour extraire au moins une caractéristique d'un achat à partir de la au moins une preuve d'achat collectée par le module de collecte. Le module d'analyse 305 peut être mis en œuvre par l'unité de traitement 302 exécutant des instructions de programme d'ordinateur configurées pour réaliser une reconnaissance optique de caractères et/ou des instructions configurées pour rechercher des mots clefs particuliers, des dates ou des montants à partir d'expressions régulières adaptées.
Le dispositif 300 comprend également un module d'identification 306 adapté pour identifier une opération bancaire sur un compte bancaire de l'utilisateur par mise en correspondance de la au moins une caractéristique de la preuve d'achat extraite par le module d'analyse 305 avec une caractéristique d'une opération sur un compte bancaire de l'utilisateur. Le module 306 peut être mis en œuvre par un programme d'ordinateur comportant des instructions configurées pour comparer au moins une caractéristique d'une preuve d'achat extraites par le module d'analyse avec au moins une caractéristique d'une opération bancaire.
Une base de données (308), adaptée pour mémoriser la preuve d'achat en association avec une opération identifiée lorsqu'une opération est identifiée. La base de données est par exemple une base de données relationnelle adaptée pour être interrogée au moyen de requêtes SQL.
Selon un mode de réalisation particulier, l'interface de communication 309 est adaptée pour transmettre une caractéristique de la transaction et une représentation de la preuve d'achat associée vers un terminal de l'utilisateur.
Selon un mode de réalisation particulier, le dispositif 300 est intégré dans un serveur de messagerie instantanée ou un serveur d'application d'un réseau de communication IMS.
Selon une réalisation particulière, le dispositif 300 est intégré dans un terminal de communication.
La figure 5 représente l'architecture d'un dispositif 500 adapté pour mettre en oeuvre le procédé d'archivage selon l'invention.
Le dispositif comprend un espace de stockage 501, par exemple une mémoire MEM, une unité de traitement 502 équipée par exemple d'un processeur PROC. L'unité de traitement peut être pilotée par un programme 503, par exemple un programme d'ordinateur PGR, mettant en oeuvre le procédé d'archivage tel que décrit dans l'invention en référence à la figure 4, et notamment les étapes réception d'au moins un message comprenant une caractéristique d'une opération bancaire et une représentation d'une preuve d'achat associée, d'obtention d'un critère de regroupement déterminé selon une caractéristique extraite de la preuve d'achat, et de mémorisation selon le critère de regroupement de la preuve d'achat obtenue. À l'initialisation, les instructions du programme d'ordinateur 503 sont par exemple chargées dans une mémoire RAM (Random Access Memory en anglais) avant d'être exécutées par le processeur de l'unité de traitement 502. Le processeur de l'unité de traitement 502 met en oeuvre les étapes du procédé de gestion selon les instructions du programme d'ordinateur 503.
Pour cela, le dispositif comprend un module de communication 507 adapté pour recevoir au moins un message comprenant une caractéristique d'une opération bancaire et une représentation d'une preuve d'achat associée, le message comprenant un critère de regroupement déterminé selon une caractéristique extraite de la preuve d'achat. Un tel module de communication est par exemple une interface réseau WiFi, ou une interface réseau cellulaire du type 2G, 3G ou 4G, ou encore une interface de communication NFC (Near field Communication) ou Bluetooth. Selon une réalisation particulière, le module de communication est adapté pour échanger des messages avec un serveur selon un protocole de messagerie instantanée, tel que par exemple un protocole conforme au standard RCS.
Le dispositif 500 comprend également une base de données 508 adaptée pour mémoriser des preuves d'achat associées à au moins une caractéristique d'une opération bancaire sur un compte bancaire de l'utilisateur du dispositif et au moins une caractéristique extraite de ladite preuve d'achat. Le module de base de données 508 est par exemple une base de données d'une application de messagerie instantanée adaptée pour mémoriser des messages comprenant une représentation d'une preuve d'achat et une caractéristique d'une opération bancaire associée, la mémorisation étant effectuée selon un critère de regroupement extrait à partir de la preuve d'achat.
Dans un mode de réalisation particulier, le dispositif 500 comprend en outre un module de regroupement 505, adapté pour regrouper des preuves d'achats selon au moins un critère extrait à partir d'une preuve d'achat. Un tel module peut être mis en œuvre par un processeur tel que le processeur PROC de l'unité de traitement 502 et par des instructions de programme d'ordinateur exécutées par l'unité de traitement 502 et configurées pour obtenir une caractéristique extraite à partir d'une preuve d'achat, rechercher des caractéristiques correspondantes parmi un ensemble de preuves d'achats, et sélectionner des preuves d'achat dont les caractéristiques correspondent.
Selon un mode particulier de réalisation, le dispositif d'archivage comprend un module (504) d'obtention d'un critère de regroupement déterminé selon une caractéristique extraite de la preuve d'achat. Selon un mode particulier de réalisation, un tel module est mis en œuvre par des instructions de programme d'ordinateur configurées pour analyse un message en provenance d'un serveur, le message comprenant un critère de regroupement déterminé selon une caractéristique extraite de la preuve d'achat déterminé par le serveur. Les instructions peuvent être mémorisées dans la mémoire 501 du dispositif et exécutées par le processeur PROC de l'unité de traitement. Selon un mode de réalisation particulier, les instructions sont configurées pour réaliser une analyse de la preuve d'achat comprise dans le message et en extraire un critère de regroupement.
Selon un mode particulier de réalisation, le dispositif 500 est intégré dans un terminal de communication tel qu'un smartphone, un objet connecté, une tablette ou un ordinateur personnel.

Claims (13)

  1. REVENDICATIONS
    1. Procédé de gestion de preuves d'achats caractérisé en ce qu'il comprend les étapes suivantes ; Collecte (200) d'au moins une preuve d'achat Extraction (201) d'au moins une caractéristique de l'achat par analyse de !a au moins une preuve d'achat collectée identification (202) d'une opération bancaire sur un compte bancaire de l'utilisateur par recherche dans une base de données d'une caractéristique d'une opération bancaire sur un compte bancaire de l'utilisateur correspondant à la au moins une caractéristique de ia au moins une preuve d'achat extraite, Lorsqu'une opération est identifiée, mémorisation (203) dans une base de données de la preuve d'achat en association avec l'opération. ?... Procédé selon la revendication 1 tel qu'il comprend en outre une étape de transmission vers un terminal de l'utilisateur, d'une caractéristique de Sa transaction et d'une représentation de la preuve d'achat associée.
  2. 3. Procédé selon la revendication 2 dans lequel l'étape de transmission comprend ia transmission d'un message selon un protocole de messagerie instantanée.
  3. 4. Procédé selon l'une quelconque des revendications 2 à 3 dans lequel le message transmis vers le terminal comprend un critère de regroupement déterminé selon la au moins une caractéristique extraite de la preuve d'achat.
  4. 5. Procédé selon l'une quelconque des revendications précédentes dans lequel la au moins une caractéristique extraite est la date et le montant de la transaction, l'étape de mise en correspondance se basant sur ladite date et ledit montant.
  5. 6. Procédé selon l'une quelconque des revendications précédentes dans lequel la au moins une preuve d'achat est obtenue à partir d'un terminal de l'utilisateur et/ou à partir d'un dispositif d'encaissement.
  6. 7. Procédé d'archivage d'au moins une preuve d'achat sur un terminai de communication caractérisé en ce qu'il comprend une étape de réception (400) d'au moins un message comprenant une caractéristique d'une opération bancaire et une représentation d'une preuve d'achat associée, une étape d'obtention (401) d'un critère de regroupement déterminé selon une caractéristique extraite de la preuve d'achat et une étape de mémorisation (402) selon le critère de regroupement de ia preuve d'achat obtenue,
  7. 8. Dispositif de gestion de preuves d'achats caractérisé en ce qu'il comprend les modules suivant : Un module (304, 309) de collecte adapté pour collecter au moins une preuve d'achat, Un module (305) d'analyse adapté pour extraire au moins une caractéristique de l'achat par analyse de la au moins une preuve d'achat collectée, Un module (306) d'identification adapté pour identifier une opération bancaire sur un compte bancaire de l'utilisateur par recherche dans une base de données d'une caractéristique d'une opération bancaire sur un compte bancaire de l'utilisateur correspondant à la au moins une caractéristique de la preuve d'achat extraite, Une base de données (308), adaptée pour mémoriser la preuve d'achat en association avec i'opération lorsqu'une opération est identifiée.
  8. 9. Dispositif selon la revendication 8 dans lequel le module de collecte est un dispositif d'acquisition d'image associé au dispositif et/ou un module de communication adapté pour recevoir une preuve d'achat transmise au travers d'un réseau de communication.
  9. 10. Dispositif selon i'une quelconque des revendications 8 à 9 tel qu'il comprend en outre un module de communication adapté pour transmettre une caractéristique de la transaction et une représentation de la preuve d'achat associée vers un terminal de l'utilisateur.
  10. 11. Dispositif d'archivage d'au moins une preuve d'achat sur un terminai de communication caractérisé en ce qu'il comprend un module (507) de communication adapté pour recevoir au moins un message comprenant une caractéristique d'une opération bancaire réalisée sur un compte bancaire de l'utilisateur et une représentation d’une preuve d'achat associée, un module (506) d'obtention d'un critère de regroupement déterminé selon une caractéristique extraite de la preuve d'achat, et un module (508) de stockage de ladite preuve d'achat dans une mémoire du terminal selon le critère de regroupement.
  11. 12. Serveur de gestion de preuves d'achats caractérisé en ce qu'il comprend un dispositif selon i'une quelconque des revendications 8 à 10.
  12. 13. Terminal de gestion de preuves d'achats caractérisé en ce qu'il comprend un dispositif seion l’une quelconque des revendications 8 à 9 et/ou un dispositif selon la revendication 11.
  13. 14. Support d'information lisible par un processeur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de gestion selon l'une quelconque des revendications 1 à 6 et/ou des instructions pour l'exécution des étapes du procédé d'archivage selon la revendication 7.
FR1763004A 2017-12-22 2017-12-22 Procede, dispositif et programme de gestion de preuves d'achat Ceased FR3076036A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR1763004A FR3076036A1 (fr) 2017-12-22 2017-12-22 Procede, dispositif et programme de gestion de preuves d'achat
EP18836485.5A EP3729353A1 (fr) 2017-12-22 2018-12-17 Procédé, dispositif et programme de gestion de preuves d'achat
US16/956,120 US20210073752A1 (en) 2017-12-22 2018-12-17 Method, device and program for managing proofs of purchase
PCT/FR2018/053331 WO2019122653A1 (fr) 2017-12-22 2018-12-17 Procédé, dispositif et programme de gestion de preuves d'achat

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1763004A FR3076036A1 (fr) 2017-12-22 2017-12-22 Procede, dispositif et programme de gestion de preuves d'achat
FR1763004 2017-12-22

Publications (1)

Publication Number Publication Date
FR3076036A1 true FR3076036A1 (fr) 2019-06-28

Family

ID=65036829

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1763004A Ceased FR3076036A1 (fr) 2017-12-22 2017-12-22 Procede, dispositif et programme de gestion de preuves d'achat

Country Status (4)

Country Link
US (1) US20210073752A1 (fr)
EP (1) EP3729353A1 (fr)
FR (1) FR3076036A1 (fr)
WO (1) WO2019122653A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3101177A1 (fr) * 2019-09-20 2021-03-26 Orange Procédé de transmission d’une information complémentaire relative à une transaction financière.
JP7434011B2 (ja) * 2020-03-24 2024-02-20 東芝テック株式会社 取引証明システム、管理装置及び情報処理プログラム
US11457011B2 (en) 2020-06-29 2022-09-27 Capital One Services, Llc Using receipts for multifactor authentication
US20220284441A1 (en) * 2021-03-02 2022-09-08 Capital One Services, Llc Detection of Warranty Expiration and Forwarding Notification

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CH708156A2 (fr) * 2013-06-12 2014-12-15 Richard Gaillard Centrale de regroupement et de gestion de garanties contractuelles et d'autres services commerciaux.
US20150012397A1 (en) * 2013-07-03 2015-01-08 Toshiba Tec Kabushiki Kaisha Information processing apparatus and program
EP3142054A1 (fr) * 2015-09-11 2017-03-15 Ingenico Group Procédé de transmission de données, dispositifs et programmes d'ordinateur correspondants

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012030678A2 (fr) * 2010-08-30 2012-03-08 Tunipop, Inc. Techniques pour faciliter des transactions de commerce électronique en ligne relatives à la vente de produits et de marchandises
US11037171B2 (en) * 2011-04-06 2021-06-15 Quotient Technology Inc. Method for verifying the validity and delivering a proof of purchase from a mobile device and associated computer program
US10200320B2 (en) * 2015-12-21 2019-02-05 Dropbox, Inc. Import content items from email

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CH708156A2 (fr) * 2013-06-12 2014-12-15 Richard Gaillard Centrale de regroupement et de gestion de garanties contractuelles et d'autres services commerciaux.
US20150012397A1 (en) * 2013-07-03 2015-01-08 Toshiba Tec Kabushiki Kaisha Information processing apparatus and program
EP3142054A1 (fr) * 2015-09-11 2017-03-15 Ingenico Group Procédé de transmission de données, dispositifs et programmes d'ordinateur correspondants

Also Published As

Publication number Publication date
WO2019122653A1 (fr) 2019-06-27
US20210073752A1 (en) 2021-03-11
EP3729353A1 (fr) 2020-10-28

Similar Documents

Publication Publication Date Title
FR2817061A1 (fr) Procede et systeme de reception, stockage et traitement de coupons electroniques avec un telephone mobile ou un assistant numerique
US20110166911A1 (en) Leveraging Customer Information to Create and Utilize Financial Networks
JP2017500621A (ja) 個人ビッグデータの収集、管理及び授権システム、及び方法
EP3729353A1 (fr) Procédé, dispositif et programme de gestion de preuves d'achat
BE1013925A3 (fr) Methode et systeme pour utiliser un dispositif portatif pour recevoir des promotions et des informations sur des produits.
EP1916623A1 (fr) Procédé de fourniture de données de transactions, terminal, procédé de transaction, procédé d'enrichissement de relevés bancaires, serveur, signaux et produits programme d'ordinateur correspondants.
FR3052283A1 (fr) Procede de fourniture de donnees relatives a une transaction de paiement, dispositif et programme correspondant
WO2016185110A1 (fr) Dispositif, système et procédé de dématérialisation de facturettes
CN107798534A (zh) 一种信息记录方法及装置、终端和可读存储介质
JP6879529B1 (ja) 商品・役務注文システム、商品・役務注文方法及びそのプログラム
CN112511574B (zh) 电子名片处理方法、设备、系统及存储介质
CA2999731A1 (fr) Procede de traitement de donnees par un terminal de paiement, terminal de paiement et programme correspondant
WO2017032056A1 (fr) Procédé et appareil de détermination d'encaissement en fonction d'un point de vente
US12555093B2 (en) Determining merchant enforced transaction rules
FR2968882A1 (fr) Procede et dispositif de production de facturettes dematerialisees
FR3101177A1 (fr) Procédé de transmission d’une information complémentaire relative à une transaction financière.
US20120116899A1 (en) Management of prospective customer data over a communications network
FR2982389A1 (fr) Procede et systeme d'archivage de donnees contenues dans un document a imprimer
EP4099249A1 (fr) Procédé et dispositif de transmission d'un identifiant d'un utilisateur lors d'un paiement électronique réalisépar l utilisateur
CN113626580A (zh) 一种产品排序方法及装置
JP7373820B1 (ja) プログラム、コンピュータ、情報処理システムおよび情報処理方法
WO2020079379A1 (fr) Procédé de transmission et conservation de documents virtuels par rétrofitage d'un terminal d'édition préprogrammé et boitier pour le mettre en oeuvre
WO2019122556A1 (fr) Procédé d'obtention d'une information complémentaire associée à une caractéristique d'une transaction bancaire
FR3074000A1 (fr) Procede et systeme pour afficher des trames d'un ticket de caisse enregistreuse sur les images d'une camera de videosurveillance
WO2025132468A1 (fr) Procédé de dématérialisation d'un ticket de transaction suite à la mise en œuvre d'une transaction entre un marchand et 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: 20190927

RX Complete rejection

Effective date: 20210127