FR3094539A1 - Procédé de commande anonymisé d’un produit ou d’un service à l’aide d’un terminal de communication - Google Patents
Procédé de commande anonymisé d’un produit ou d’un service à l’aide d’un terminal de communication Download PDFInfo
- Publication number
- FR3094539A1 FR3094539A1 FR1903440A FR1903440A FR3094539A1 FR 3094539 A1 FR3094539 A1 FR 3094539A1 FR 1903440 A FR1903440 A FR 1903440A FR 1903440 A FR1903440 A FR 1903440A FR 3094539 A1 FR3094539 A1 FR 3094539A1
- Authority
- FR
- France
- Prior art keywords
- communication
- terminal
- product
- service
- request
- 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.)
- Pending
Links
- 230000006854 communication Effects 0.000 title claims abstract description 113
- 238000004891 communication Methods 0.000 title claims abstract description 110
- 238000000034 method Methods 0.000 title claims abstract description 41
- 230000008569 process Effects 0.000 title description 13
- 230000000873 masking effect Effects 0.000 claims abstract description 5
- 238000004590 computer program Methods 0.000 claims description 9
- 230000004044 response Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 2
- 238000001914 filtration Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000002123 temporal effect Effects 0.000 description 2
- 230000001755 vocal effect Effects 0.000 description 2
- 230000007175 bidirectional communication Effects 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0613—Third-party assisted
- G06Q30/0615—Anonymizing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0241—Advertisements
- G06Q30/0251—Targeted advertisements
- G06Q30/0267—Wireless devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
- G06F21/6254—Protecting personal data, e.g. for financial or medical purposes by anonymising data, e.g. decorrelating personal data from the owner's identification
-
- 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
- G06Q10/00—Administration; Management
- G06Q10/02—Reservations, e.g. for tickets, services or events
-
- 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
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/40—Business processes related to the transportation industry
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
- H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Finance (AREA)
- Development Economics (AREA)
- Accounting & Taxation (AREA)
- Marketing (AREA)
- Economics (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- General Health & Medical Sciences (AREA)
- Tourism & Hospitality (AREA)
- Health & Medical Sciences (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Entrepreneurship & Innovation (AREA)
- Bioethics (AREA)
- Human Resources & Organizations (AREA)
- Game Theory and Decision Science (AREA)
- Computing Systems (AREA)
- Signal Processing (AREA)
- Medical Informatics (AREA)
- Databases & Information Systems (AREA)
- Software Systems (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Primary Health Care (AREA)
- Information Transfer Between Computers (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Procédé de c ommande anonymisé d’un produit ou d’un service à l’aide d’un terminal de communication L’invention concerne un procédé de commande d’un produit ou d’un service au moyen d’un terminal de communication, comprenant ce qui suit, au niveau du terminal : - envoyer (S2, S10) à un serveur une requête de commande du produit ou du service, contenant des informations relatives au produit ou au service, - établir (S9) en arrière-plan une communication vers N terminaux de fournisseur(N≥1) identifiés par le serveur comme étant aptes à fournir le produit ou le service, en fonction de tout ou partie des informations de la requête, ladite communication étant établie en masquant l’identifiant de communication du terminal et des N terminaux, - au cours de la communication, recevoir (S14) une offre du produit ou du service en provenance d’au moins un terminal de fournisseur parmi au moins K, tel que 1≤K≤ N, l’offre ayant été sélectionnée durant la communication comme optimisant un compromis entre tout ou partie des informations de la requête et une donnée de localisation du terminal et/ou une donnée temporelle associée à la requête, - commander (S15) la restitution de l’offre, l’identifiant de communication dudit au moins un terminal de fournisseur ainsi que l’identification du fournisseur étant masqués. Figure pour l’abrégé : Figure 3
Description
Domaine de l'invention
La présente invention se rapporte de manière générale au domaine des communications sécurisées, en particulier dans le cadre de la commande d’un produit ou d’un service à l’aide d’un terminal de communication (téléphone mobile, tablette, ordinateur, etc.).
Art antérieur
Actuellement, pour commander un produit ou un service à l’aide d’un terminal de communication, l’utilisateur saisit des informations relatives au produit ou au service dans un moteur de recherche. De telles informations décrivent le produit ou le service que l’utilisateur souhaite commander et comprennent éventuellement le montant auquel l’utilisateur souhaite acquérir le produit ou le service. Une recherche est alors lancée sur la base des informations saisies et, en retour, le terminal de l’utilisateur affiche une liste de fournisseurs susceptibles d’offrir à l’utilisateur le produit ou le service correspondant aux informations saisies.
L’inconvénient de ce type de procédé de commande réside dans le fait que l’utilisateur doit ensuite naviguer dans la liste des fournisseurs reçue, prendre contact avec chacun d’entre eux afin de savoir si les fournisseurs sont réellement en mesure de répondre à la commande. Un tel procédé de commande est fastidieux et chronophage pour l’utilisateur. Il est aussi peu fiable compte tenu du fait que la recherche est elle-même généralement très approximative.
Un autre inconvénient de ce type de procédé est que des données personnelles relatives aux fournisseurs sont divulguées dans la liste de fournisseurs reçue. Les fournisseurs ne sont donc pas à l’abri d’être contactés par un utilisateur mal intentionné, dans le cas par exemple où le montant du produit ou du service requis est élevé. Le fait aussi que l’utilisateur contacte un fournisseur de la liste a l’inconvénient de divulguer à ce dernier des données personnelles de l’utilisateur (ex : nom ou numéro de téléphone de l’utilisateur qui s’affiche sur le terminal de communication du fournisseur), alors que la commande du produit ou du service n’a même pas encore été finalisée.
Afin de simplifier ce type de procédé de commande et d’obtenir une liste de fournisseurs plus ciblée par rapport aux critères de recherche saisis par l’utilisateur, certains sites de vente en ligne proposent maintenant à l’utilisateur de filtrer les résultats d’une recherche de produit ou de service que l’utilisateur souhaite commander, en se basant sur la localisation d’un terminal de communication de l’utilisateur. Un tel filtrage permet certes de réduire la liste des fournisseurs potentiels du produit ou du service. Toutefois, l’utilisateur est toujours obligé de contacter un à un les fournisseurs de la liste et la divulgation des données personnelles de l’utilisateur, comme celles des fournisseurs, n’est toujours pas préservée.
Objet et résumé de l'invention
Un des buts de l'invention est de remédier à des inconvénients de l'état de la technique précité.
A cet effet, un objet de la présente invention concerne un procédé de commande d’un produit ou d’un service au moyen d’un terminal de communication associé à un identifiant de communication.
Un tel procédé est remarquable en ce qu’il comprend ce qui suit, au niveau du terminal :
- envoyer à un serveur une requête de commande du produit ou du service, ladite requête contenant des informations relatives au produit ou au service,
- établir en arrière-plan une communication vers N terminaux associés respectivement à N identifiants de communication (N≥1), les N terminaux étant des terminaux de fournisseurs identifiés par le serveur comme étant aptes à fournir le produit ou le service, en fonction de tout ou partie des informations contenues dans la requête, ladite communication étant établie en masquant l’identifiant de communication du terminal et les N identifiants de communication,
- au cours de la communication, recevoir une offre du produit ou du service en provenance d’au moins un terminal de fournisseur parmi au moins K, tel que 1≤K≤ N, l’offre ayant été générée durant la communication et sélectionnée comme optimisant un compromis entre, d’une part, tout ou partie des informations contenues dans la requête et, d’autre part, une donnée de localisation du terminal de communication et/ou une donnée temporelle associée à la requête,
- commander la restitution de l’offre, l’identifiant de communication dudit au moins un terminal de fournisseur ainsi que l’identification du fournisseur dudit au moins un terminal de fournisseur étant masqués lors de la restitution.
Un tel procédé de commande de produit ou de service est particulièrement simple et rapide à mettre en œuvre pour l’utilisateur, puisque celui-ci se contente juste d’envoyer une requête à un serveur à l’aide de son terminal pour spécifier les informations relatives au produit ou au service qu’il souhaite commander.
De manière avantageuse, l’utilisateur n’a en outre pas besoin de contacter un par un les N fournisseurs du produit ou du service qu’il souhaite obtenir, de tels contacts étant exécutés en arrière-plan ou en tâche de fond à l’initiative du terminal de l’utilisateur. Il en résulte que le procédé de commande de produit ou de service est plus facile à utiliser et est exécuté beaucoup plus rapidement que dans l’art antérieur.
Un autre avantage d’un tel procédé est qu’il préserve la confidentialité des données personnelles aussi bien du côté du terminal ayant requis l’offre de produit ou de service, que du côté des N terminaux de fournisseurs de produit ou de service qui ont été identifiés.
Selon un mode de réalisation particulier, le procédé comprend ce qui suit, en cas d’acceptation de l’offre :
- envoyer des données d’identification de l’utilisateur du terminal audit au moins un terminal de fournisseur,
- recevoir des données d’identification de l’utilisateur dudit au moins un terminal de fournisseur.
Grâce à un tel mode de réalisation, l’anonymat de l’utilisateur du terminal de communication et l’anonymat du fournisseur du produit ou du service dont l’offre a été acceptée sont levés seulement une fois que l’offre a été acceptée par l’utilisateur du terminal.
Selon un autre mode de réalisation particulier, le procédé comprend ce qui suit, en cas de refus de l’offre :
- poursuivre la communication, au cours de laquelle les actions de recevoir une offre et de commander la restitution de l’offre reçue sont itérées, tant qu’une offre n’est pas acceptée.
Un tel mode de réalisation permet de proposer à l’utilisateur du terminal et même si ce dernier a décliné l’offre optimale, une ou plusieurs autre(s) offres de produit ou de
service qui correspondent à ses critères de recherche, sans que l’utilisateur n’ait besoin de contacter de sa propre initiative les différents fournisseurs de produit ou de service. En outre, les identités des fournisseurs n’étant pas connues de l’utilisateur, un tel mode de réalisation permet de protéger les fournisseurs, en particulier dans le cas où les informations contenues dans la requête sont sensibles, telles que par exemple un montant élevé du produit ou du service requis, un objet rare, etc….
Selon un autre mode de réalisation particulier, au cours de la communication, le terminal reçoit, en provenance de respectivement N-K terminaux de fournisseur de produit ou de service identifiés par le serveur, N-K refus de fournir le produit ou le service correspondant à la requête.
Un tel mode de réalisation permet avantageusement pour l’utilisateur du terminal qui a envoyé la requête de commande du produit ou du service, de ne recevoir que les offres des K fournisseurs restants, intéressés par le produit ou le service commandé. Il en ressort une diminution des échanges qui seront susceptibles d’avoir lieu au cours de la communication entre le terminal de l’utilisateur et les K terminaux de fournisseur restants, ce qui entraîne une limitation de l’encombrement du réseau de communication entre le terminal de l’utilisateur et les terminaux de fournisseur. Compte tenu du fait que la communication est établie en arrière-plan et que l’identité des fournisseurs et de leurs terminaux de communication correspondants n’est pas connue de l’utilisateur, il n’est avantageusement pas possible pour l’utilisateur d’identifier les N-K fournisseurs ayant refusé de fournir le produit ou le service correspondant à la requête.
Selon un autre mode de réalisation particulier, l’offre de produit ou de service reçue au cours de la communication est générée en tenant compte d’au moins une variable d’ajustement de :
- tout ou partie des informations contenues dans la requête, et/ou
- une donnée de localisation du terminal de communication, et/ou
- une donnée temporelle associée à la requête.
L’avantage d’un tel mode de réalisation est que l’utilisateur du terminal reçoit au moins une offre de produit ou de service, même si cette dernière ne correspond pas exactement aux informations relatives au produit ou service mentionnées dans la requête et/ou à la localisation du terminal et/ou à la date/instant à laquelle a été envoyée la requête et/ou à des informations temporelles indiquées dans la requête.
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, au procédé de commande de produit ou de service défini ci-dessus.
L'invention concerne également un terminal de communication de communication pour commander un produit ou un service, ledit terminal de communication étant associé à un identifiant de communication.
Un tel terminal est remarquable en ce qu’il comprend un processeur qui est configuré pour mettre en œuvre ce qui suit :
- envoyer à un serveur une requête de commande du produit ou du service, ladite requête contenant des informations relatives au produit ou au service,
- établir en arrière-plan une communication vers N terminaux associés respectivement à N identifiants de communication (N≥1), les N terminaux étant des terminaux de fournisseurs identifiés par le serveur comme étant aptes à fournir le produit ou le service, en fonction de tout ou partie des informations contenues dans la requête, ladite communication étant établie en masquant l’identifiant de communication du terminal et les N identifiants de communication,
- au cours de la communication, recevoir une offre du produit ou du service en provenance d’au moins un terminal de fournisseur parmi au moins K, tel que 1≤K≤ N, l’offre ayant été générée durant la communication et sélectionnée comme optimisant un compromis entre, d’une part, tout ou partie des informations contenues dans la requête et, d’autre part, une donnée de localisation du terminal de communication et/ou une donnée temporelle associée à la requête,
- commander la restitution de l’offre sur une interface de restitution, l’identifiant de communication dudit au moins un terminal de fournisseur ainsi que l’identification du fournisseur dudit au moins un terminal de fournisseur étant masqués lors de la restitution.
Un tel terminal de communication est notamment apte à mettre en œuvre le procédé de commande de produit ou de service précité.
L'invention concerne encore un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de commande de produit ou de service selon l'invention, selon l’un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur.
De telles instructions peuvent être stockées durablement dans un support mémoire non transitoire du terminal de communication.
Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
L’invention vise également un support d’enregistrement ou support d’informations lisible par un ordinateur, et comportant des instructions d’un programme d’ordinateur tel que mentionné ci-dessus.
Le support d'enregistrement 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 clé USB ou un disque dur.
D'autre part, le support d'enregistrement 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'enregistrement 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é de commande de produit ou de service précité.
D'autres caractéristiques et avantages apparaîtront à la lecture de modes de réalisation particuliers de l'invention, donnés à titre d’exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
Description
détaillé d’un mode de réalisation
de l’invention
Environnement architectural
La figure 1 représente un environnement dans lequel est mis en œuvre le procédé de commande de produit ou de service selon l’invention.
Sur la figure 1 sont représentés :
- un terminal de communication TERu d’un utilisateur UT souhaitant commander un produit ou un service,
- N terminaux de communication TERf1, TERf2,…, TERfNappartenant respectivement à N fournisseurs f1, f2,…, fNde produit ou de service,
- un serveur SER de mise en relation du terminal TERu avec chacun des terminaux de communication TERf1, TERf2,…, TERfNde fournisseurs.
Le terminal TERu, les terminaux TERf1, TERf2,…, TERfNet le serveur SER communiquent entre eux via un réseau de communication RC. Il peut s’agir par exemple d’un réseau de type IP (abréviation anglaise de « Internet Protocol »), d’un réseau de type x-DSL, fibre ou encore 3G, 4G, 5G, etc.
A titre d’exemples non exhaustifs, le terminal TERu et les terminaux TERf1, TERf2,…, TERfNsont :
- un téléphone portable, et/ou
- un smartphone (« téléphone intelligent »), et/ou
- une tablette, et/ou
- un ordinateur portable, et/ou
- un ordinateur personnel de type PC, et/ou
- etc….
Le terminal TERu est classiquement associé à un identifiant de communication ICu, tel que par exemple le numéro de téléphone mobile, le numéro de ligne fixe, l’adresse IP ou bien l’adresse email permanente de l’utilisateur UT, un tel identifiant lui ayant été attribué par un ou plusieurs opérateurs de télécommunications au(x)quel(s) l’utilisateur UT est abonné ou bien encore par un ou plusieurs fournisseurs de service de télécommunications auprès duquel/desquels l’utilisateur UT a créé un compte.
Pour un terminal de fournisseur TERfi(1≤i≤N) considéré parmi N, le terminal TERfiest classiquement associé à un identifiant de communication ICfi, tel que par exemple le numéro de téléphone mobile, le numéro de ligne fixe, l’adresse IP ou bien l’adresse email permanente du fournisseur fi, un tel identifiant lui ayant été attribué par un ou plusieurs opérateurs de télécommunications au(x)quel(s) le fournisseur fiest abonné ou bien encore par un ou plusieurs fournisseurs de service de télécommunications auprès duquel/desquels le fournisseur fia créé un compte.
Le terminal TERu comprend une application logicielle (ou programme applicatif) APu qui est dédiée à la mise en œuvre du procédé de commande de produit ou de service conformément à la présente invention. L’application APu est téléchargée dans le terminal TERu, en amont de l’exécution du procédé de commande de produit ou de service.
Les terminaux de fournisseur TERf1, TERf2,…, TERfNcomprennent également chacun une application logicielle (ou programme applicatif) correspondante APf1, APf2,…, APfNqui est apte à dialoguer avec l’application APulors de la mise en œuvre du procédé de commande de produit ou de service conformément à la présente invention. Les applications APf1, APf2,…, APfNsont respectivement téléchargées dans les terminaux de fournisseurs TERf1, TERf2,…, TERfN, en amont de l’exécution du procédé de commande de produit ou de service.
Le serveur SER stocke dans une mémoire ou une base de données :
- un identifiant de communication virtuel IVu attribué à l’utilisateur UT, un tel identifiant étant associé à l’identifiant de communication ICu du terminal TERu,
- des identifiants de communication virtuels IVf1, IVf2,…, IVfNrelatifs respectivement aux fournisseurs f1, f2,…, fN, de tels identifiants étant associés respectivement aux identifiants de communication ICf1, ICf2,…, ICfN.
Un identifiant de communication virtuel est par exemple une suite de caractères numériques ou alphanumériques générée par exemple de manière aléatoire. L’identifiant virtuel de l’utilisateur UT (respectivement d’un fournisseur ficonsidéré parmi N) est destiné à circuler dans le réseau de communication RC à la place de l’identifiant de communication ICu (respectivement de l’identifiant de communication ICfi) de façon à préserver l’anonymat de l’utilisateur UT (respectivement du fournisseur fide produit ou de service).
Description d’un mode de réalisation du
terminal de communication TERu
La figure 2 présente la structure simplifiée du terminal de communication TERu adapté pour mettre en œuvre le procédé de commande de produit ou de service qui va être décrit ci-dessous.
De façon connue en soi, le terminal de communication TERu comprend :
- une interface de connexion IC qui est adaptée pour communiquer, via le réseau de communication RC, selon par exemple le protocole http (abréviation anglaise de « HyperText Transfer Protocol »), avec le serveur SER de la figure 1,
- un écran de visualisation EC,
- un haut-parleur HP,
- un microphone MIC.
Selon l’invention, le terminal TERu stocke dans une mémoire MEM1 l’application APu dédiée à l’exécution du procédé de commande de produit ou de service selon l’invention.
Selon un mode particulier de réalisation de l'invention, les actions exécutées par le procédé de commande de produit ou de service sont mises en œuvre par des instructions d’un programme d'ordinateur PG. Pour cela, le terminal TERu a l'architecture classique d'un ordinateur et comprend notamment une mémoire MEM2, une unité de traitement UTR, équipée par exemple d'un processeur PROC, et pilotée par le programme d'ordinateur PG stocké en mémoire MEM2. Le programme d'ordinateur PG comprend des instructions pour mettre en œuvre les actions du procédé de commande de produit ou de service qui va être décrit ci-dessous, lorsque le programme est exécuté par le processeur PROC, selon l'un quelconque des modes particuliers de réalisation de l'invention.
A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire RAM (non représentée) avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UTR met notamment en œuvre les actions du procédé de commande de produit ou de service, selon les instructions du programme d'ordinateur PG.
Description d’un mode de réalisation du procédé
de commande de produit ou de service
En référence à la figure 3, on décrit maintenant le déroulement d’un procédé de commande de produit ou de service selon un mode de réalisation de l’invention.
Selon un premier exemple de réalisation, l’utilisateur UT souhaite, dans le cadre d’un service de porte-monnaie électronique, effectuer un retrait d’espèces à l’aide de son terminal TERu, dans un commerce partenaire.
Selon un deuxième exemple de réalisation, l’utilisateur souhaite acheter une voiture de marque X, de modèle Y et de couleur Z.
En S1, l’utilisateur UT ouvre l’application APu et saisit, via une interface utilisateur générée par l’application APu, des informations relatives au produit ou au service que l’utilisateur souhaite commander. Une telle interface utilisateur peut être vocale et restituée via le haut-parleur HP de la figure 2 ou bien encore textuelle et restituée sur l’écran EC de la figure 2.
Dans le cas du premier exemple de réalisation, les informations relatives au produit ou au service comprennent le montant que l’utilisateur UT souhaite retirer, soit t euros.
Dans le cas du deuxième exemple de réalisation, les informations relatives au produit ou au service comprennent le type de produit : « voiture », le prix, la marque X, le modèle Y, la couleur Z de la voiture souhaitée. Bien entendu, de telles informations pourraient être limitées au mot « voiture » ou à une combinaison du mot « voiture » avec l’une et/ou l’autre des rubriques « prix », marque X, modèle Y, couleur Z.
Les informations relatives au produit ou au service peuvent également comprendre :
- une donnée de localisation du terminal TERu, telles que par exemple les coordonnées GPS (abréviation anglaise de «Global Positioning System») du terminal TERu ; et/ou
- une ou plusieurs données temporelles associées à la requête, telles que:
- une ou plusieurs données temporelles relatives à la saisie, par exemple la date de la saisie, l’instant de la saisie en heure, minute(s), seconde(s),
- une ou plusieurs données temporelles relatives à l’envoi de la requête, telles que par exemple des données d’horodatage,
- une ou plusieurs données temporelles relatives à la fourniture du produit ou du service souhaité, telles que par exemple un jour de la semaine ou du mois en cours, une plage horaire dans la journée, 9h30-12h30, par exemple.
De manière optionnelle, les informations relatives au produit ou au service requis comprennent en outre une ou plusieurs variables d’ajustement :
- de tout ou partie des informations contenues dans la requête, et/ou
- d’une donnée de localisation du terminal de communication, et/ou
- d’au moins une des données temporelles associées à la requête précitées.
Si par exemple, une information contenue dans la requête est un prix du produit ou du service, une variable d’ajustement consiste par exemple en une plage de tolérance sur ce prix, par exemple plus ou moins 5%, 10%, etc…
Si par exemple, une information contenue dans la requête est une donnée de localisation, telle qu’une distance de j kilomètres autour du terminal de communication, une variable d’ajustement consiste par exemple en une plage de tolérance sur cette distance, par exemple j plus ou moins 500 m, 1 km, etc…
Si par exemple, une information contenue dans la requête est au moins une donnée temporelle, une variable d’ajustement consiste par exemple en une variation d’une plage horaire mentionnée initialement dans la requête ou encore une durée de validité de la commande du produit ou du service souhaité, par exemple 1 jour, 2 jours, 1 semaine, etc…
En S2, une requête de commande de produit ou de service contenant les informations saisies est envoyée, via le réseau RC de la figure 1, au serveur SER, au moyen de l’application APu. Un tel envoi peut être mis en œuvre au moyen d’une touche générée par l’interface utilisateur de l’application APu et restituée sur l’écran EC ou au moyen d’une commande vocale générée par l’interface utilisateur de l’application APu et restituée par le haut-parleur HP. La requête envoyée est conforme par exemple au protocole http ou https.
En S3, le serveur SER reçoit la requête. Il identifie alors les N fournisseurs f1, f2,…, fNcomme étant aptes à fournir le produit ou le service demandé. Une telle identification est mise en œuvre à l’aide d’un mécanisme d’analyse de données qui utilise tout ou partie des informations relatives au produit ou au service contenues dans la requête envoyée en S2 et qui calcule une probabilité selon laquelle les N fournisseurs f1, f2,…, fNsont aptes à fournir le produit ou le service requis. La probabilité est éventuellement calculée sur la base d’un historique local accessible par le serveur SER.
Dans le cas du premier exemple de réalisation, le serveur SER estime ainsi à partir des transactions déjà effectuées par les fournisseurs f1, f2,…, fN et stockées dans un historique local, qu’ils sont capables de fournir le montant de t euros demandé par l’utilisateur UT.
Dans le cas du deuxième exemple de réalisation, le serveur SER est en mesure d’évaluer à partir de l’historique local, que telle voiture requise par l’utilisateur UT est en stock chez l’ensemble des fournisseurs f1, f2,…, fN.
Une telle identification permet d’obtenir de façon complètement transparente pour l’utilisateur UT, et de manière dynamique et ciblée, une liste de fournisseurs pour lesquels il existe une forte probabilité qu’ils puissent répondre favorablement à la requête de commande de produit ou de service envoyée en S2.
En S4, le serveur SER envoie à l’application APu une réponse à la requête reçue. Une telle réponse contient les identifiant virtuels IVf1, IVf2,…, IVfNrelatifs respectivement aux fournisseurs f1, f2,…, fN.
De manière optionnelle, les identifiants virtuels IVf1, IVf2,…, IVfNenvoyés en S4 sont associés respectivement aux probabilités calculées par le serveur SER, selon lesquelles les N fournisseurs f1, f2,…, fNsont aptes à fournir le produit ou le service requis.
En S5, l’application APu reçoit la réponse.
En S6, une requête en demande de communication avec les terminaux de fournisseur TERf1, TERf2,…, TERfNest alors envoyée en arrière-plan par l’application APu au serveur SER, ladite requête contenant l’identifiant virtuel IVu du terminal TERu et les identifiant virtuels IVf1, IVf2,…, IVfNrelatifs respectivement aux fournisseurs f1, f2,…, fN.
En S7, le serveur SER reçoit la requête et crée alors un canal d’échange anonymisé pour la mise en relation en mode pair à pair de l’application APu du terminal TERu avec chacune des applications APf1, APf2,…, APfN des terminaux de fournisseur TERf1, TERf2,…, TERfN.
En S8, le serveur SER envoie une demande de mise en relation à chacune des applications APu et APf1, APf2,…, APfN.
En S9, la communication entre l’application APu et chacune des applications APf1, APf2,…, APfNest alors établie, après validation auprès du serveur SER, par les applications APu et APf1, APf2,…, APfN, de la demande de mise en relation. La communication est établie par exemple au moyen d’un protocole de communication bidirectionnel synchrone ou asynchrone, tel que par exemple du type WebSocket, http, etc.
De façon particulièrement avantageuse, la communication est mise en œuvre en arrière-plan, donc de façon transparente pour l’utilisateur UT. Par ailleurs, les identifiants de communication publics précités ICu et ICf1, ICf2,…, ICfNsont masqués durant la communication puisqu’ils sont remplacés par respectivement les identifiants virtuels précités IVu, IVf1, IVf2,…, IVfN.
En S10, l’application APu envoie en arrière-plan, à chacune des applications APf1, APf2,…, APfN, la requête précédemment envoyée en S2. Ladite requête peut contenir, en plus des informations déjà mentionnées en relation avec l’opération S2 ci-dessus, une ou plusieurs variables d’ajustement :
- de tout ou partie des informations contenues dans la requête, et/ou
- d’une donnée de localisation du terminal de communication, et/ou
- d’une donnée temporelle associée à la requête, telle que par exemple la date de la saisie, l’instant de la saisie en heure, minute(s), seconde(s), un jour de la semaine ou du mois en cours, une plage horaire dans la journée, 9h30-12h30, par exemple.
Dans le cas du premier exemple de réalisation précité, la variable d’ajustement peut par exemple consister en une tolérance de plus ou moins 5% du montant de t euros demandé.
Dans le cas du deuxième exemple de réalisation précité, la variable d’ajustement peut par exemple consister en une tolérance sur la couleur Z initialement saisie.
Chacun des terminaux de fournisseurs TERf1, TERf2,…, TERfNestime alors en local s’il est en mesure, à l’instant où il reçoit la requête envoyée en S10, si les fournisseurs f1, f2,…, fNidentifiés sont aptes à répondre favorablement à la requête, en fonction de tout ou partie des informations contenues dans cette requête, des variables d’ajustement contenues dans cette requête et/ou éventuellement de variables d’ajustement échangées lors de ladite communication entre l’application APu et chacune des applications APf1, APf2,…, APfNet/ou des éventuelles variables d’ajustement déjà acceptées par les fournisseurs de service. Une telle estimation est établie par calcul de probabilités considérant en entrée les informations contenues dans cette requête et les variables d’ajustement précitées.
Selon le premier exemple de réalisation précité, l’estimation est basée par exemple :
- uniquement sur le montant de t euros mentionné dans la requête envoyée en S10,
- sur le montant de t euros et sur une donnée de localisation du terminal TERu, telle que par exemple un rayon de j kilomètres autour du terminal TERu ;
- sur le montant de t euros, et/ou sur une donnée de localisation du terminal TERu, telle que par exemple un rayon de j kilomètres autour du terminal TERu et/ou une variable d’ajustement de plus ou moins 5% du montant de t euros.
Selon le deuxième exemple de réalisation précité, l’estimation est basée par exemple :
- uniquement sur le type de produit : « voiture », le prix, la marque X, le modèle Y, la couleur Z de la voiture souhaitée ;
- sur le type de produit : « voiture », le prix, la marque X, le modèle Y, la couleur Z de la voiture souhaitée et/ou sur une donnée de localisation du terminal TERu, telle que par exemple un rayon de j kilomètres autour du terminal TERu et/ou une variable d’ajustement sur, par exemple, la couleur Z. Si la couleur Z est par exemple bleue, l’estimation est calculée en prenant en compte une autre couleur, par exemple la couleur grise et/ou la couleur noire.
A l’issue de cette estimation, N-K fournisseurs, tel que K≤N, peuvent abandonner la communication parce que soit ils ne disposent pas du produit souhaité, soit ils ne peuvent pas rendre le service souhaité, dans les conditions acceptées par ces fournisseurs au regard des conditions souhaitées par l’utilisateur UT. A cet effet, l’application APu reçoit (non représenté sur la figure 3) N-K messages de refus de fournir le produit ou le service souhaité en provenance des N-K applications correspondantes des N-K terminaux de fournisseur K+1,…, N.
En S11, K applications APf1, APf2,…, APfKenvoient chacune une réponse à l’application APu, chaque réponse contenant les conditions de l’offre que peut proposer le fournisseur correspondant f1, f2,…, fKet qui sont basées sur le calcul de l’estimation ci-dessus.
En S12, l’application APu reçoit en arrière-plan chacune des K réponses contenant respectivement K offres du produit ou du service requis.
En S13, est alors mise en œuvre en arrière-plan une phase de négociation entre l’application APu et chacune des K applications APf1, APf2,…, APfK, de manière à sélectionner au moins une offre de produit ou de service optimale. Cette offre est sélectionnée comme optimisant un compromis entre, d’une part, tout ou partie des informations contenues dans la requête envoyée en S10 et, d’autre part, au moins une donnée de localisation du terminal de communication TERu, telle que décrite plus haut, et/ou au moins une donnée temporelle associée à la requête envoyée en S10, dont des exemples ont déjà été décrits plus haut, et/ou encore au moins une variable d’ajustement telle que décrite plus haut. Au cours de la négociation, pour chaque offre envoyée à l’application APu par une application APficonsidérée parmi K, l’application APu répond à l’offre en renvoyant à l’application APficonsidérée, soit un message de refus, soit un message d’acceptation. Cet échange est itéré pour 1≤i≤K. L’offre optimale est par exemple celle envoyée par l’application APfidu terminal de fournisseur TERfi.
Toutes les offres auxquelles a répondu favorablement l’application APu peuvent être classées dans l’ordre allant de l’offre optimale à l’offre la moins optimale.
En S14, l’application APu reçoit en arrière-plan l’offre de produit ou de service optimale.
En S15, il est procédé à la commande de la restitution de l’offre optimale sur, par exemple, une interface de restitution du terminal TERu, telle que par exemple l’écran EC ou le haut-parleur HP de la figure 2. Selon un exemple de réalisation, une icône représentant de façon anonyme le fournisseur fiest affichée sur une carte de l’endroit où est situé le fournisseur fi, ce qui permet à l’utilisateur UT de situer grossièrement la localisation du fournisseur fi. De manière particulièrement avantageuse, aucune information personnelle sur le fournisseur fi, qu’il s’agisse de son nom, de son adresse, de l’identifiant de communication ICfidu terminal de fournisseur TERfi, etc…n’est affichée sur l’écran EC. Selon un autre exemple, une phrase du type : « le fournisseur fiest à 5km de chez vous au nord-ouest » est énoncée via le haut-parleur HP. Une telle phrase ne divulgue aucune information personnelle sur le fournisseur fi, qu’il s’agisse de son nom, de son adresse, de l’identifiant de communication ICfidu terminal de fournisseur TERfi, etc..
En S16, si l’utilisateur UT valide l’offre (« O » sur la figure 3), par exemple en appuyant sur une touche dédiée de l’écran EC ou en disant « OK » via le microphone MIC de la figure 2, un contrat de l’offre du produit ou service souhaité est généré par l’application APu selon des paramètres préprogrammés, un tel contrat étant considéré comme signé par l’utilisateur UT, mais ne comprenant à ce stade aucune données personnelles relatives à l’utilisateur UT.
En S17, le contrat signé par l’utilisateur UT est envoyé en arrière-plan par l’application APu à l’application APfi.
Le terminal TERfireçoit le contrat, et s’il est validé par le fournisseur fiselon les mêmes principes que ceux mis en œuvre pour l’utilisateur UT, la génération d’une signature de contrat par le fournisseur fiest déclenchée via l’application APfi. A ce stade, le contrat ne comprend pas non plus de données personnelles relatives au fournisseur fi.
En S18, le contrat signé par le fournisseur fiest envoyé en arrière-plan par l’application APfià l’application APu.
En S19, le terminal TERu reçoit le contrat signé par le fournisseur fi.
En S20, des données personnelles relatives à l’utilisateur UT sont envoyées en arrière-plan au terminal TERfiselon une configuration prédéfinie. A l’issue de cet envoi, et selon cette configuration prédéfinie, les données personnelles de l’utilisateur UT sont restituées en S21 sur le terminal TERfi, de manière textuelle ou vocale. Il peut s’agir par exemple du nom et de l’adresse de messagerie électronique de l’utilisateur UT. En S20, le terminal TERu reçoit également en arrière-plan, en provenance du terminal TERfi, et selon une configuration prédéfinie, des données personnelles relatives au fournisseur fi. Selon cette configuration prédéfinie, il peut s’agir par exemple du nom, d’une adresse de messagerie électronique du fournisseur fi, ainsi que l’adresse de visite de ce dernier. Selon cette configuration prédéfinie, les données personnelles du fournisseur fiqui ont été reçues sont restituées en S21 sur le terminal TERu, de manière textuelle, par exemple sur l’écran EC du terminal TERu, ou bien de manière vocale, au moyen du haut-parleur HP du terminal TERu.
Si en S16, l’utilisateur UT ne valide pas l’offre (« N » sur la figure 3), par exemple en appuyant sur une touche dédiée de l’écran EC ou en disant « NON OK » via le microphone MIC, le procédé de commande retourne à l’opération S13 en vue de sélectionner l’une des offres restantes parmi K-1. La sélection est mise en œuvre par itération dans l’ordre selon lequel les offres ont été triées, une itération étant effectuée tant qu’une nouvelle offre optimale n’est pas sélectionnée. Si aucune des offres n’est acceptée par l’utilisateur UT, selon un exemple de réalisation, la mise en relation établie en S13 prend fin. Le procédé de commande revient alors à l’opération de saisie S1, où l’utilisateur UT est invité à saisir des informations complémentaires de celles saisies initialement en S1. Puis les opérations S2 et suivantes sont réitérées. Selon un autre exemple de réalisation, la mise en relation établie en S13 demeure, et le procédé de commande repasse en S10 où sont appliquées des variables d’ajustement préconfigurées sur :
- tout ou partie des informations contenues dans la requête, et/ou
- une donnée de localisation du terminal de communication, et/ou
- une donnée temporelle associée à la requête.
Il va de soi que les modes de réalisation qui ont été décrits ci-dessus ont été donnés à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l’homme de l’art, sans pour autant sortir du cadre de l’invention. D’autres applications de l’invention sont également possibles, telles que par exemple un système d’enchères électroniques ou encore un système de paiement via une application mobile téléchargée sur un terminal de télécommunications.
Claims (8)
- Procédé de communication sécurisée adapté pour commander un produit ou un service au moyen d’un terminal de communication (TERu) associé à un identifiant de communication (ICu), comprenant ce qui suit, au niveau du terminal :
- envoyer (S2, S10) à un serveur (SER), via un réseau de communication (RC), une requête de commande du produit ou du service, ladite requête contenant des informations relatives au produit ou au service,
- établir (S9) en arrière-plan une communication vers N terminaux associés respectivement à N identifiants de communication (N≥1) (ICf1, ICf2,…, ICfN), les N terminaux étant des terminaux de fournisseurs identifiés par le serveur comme étant aptes à fournir le produit ou le service, en fonction de tout ou partie des informations contenues dans la requête, ladite communication étant établie en masquant l’identifiant de communication du terminal et les N identifiants de communication,
- au cours de la communication, recevoir (S14) une offre du produit ou du service en provenance d’au moins un terminal de fournisseur parmi au moins K, tel que 1≤K≤ N, l’offre ayant été générée durant la communication et sélectionnée comme optimisant un compromis entre, d’une part, tout ou partie des informations contenues dans la requête et, d’autre part, une donnée de localisation du terminal de communication et/ou une donnée temporelle associée à la requête,
- commander (S15) la restitution de l’offre sur une interface du terminal, l’identifiant de communication dudit au moins un terminal de fournisseur ainsi que l’identification du fournisseur dudit au moins un terminal de fournisseur étant masqués lors de la restitution. - Procédé de commande selon la revendication 1, dans lequel en cas d’acceptation de l’offre :
- envoyer (S20) des données d’identification de l’utilisateur du terminal audit au moins un terminal de fournisseur,
- recevoir (S20) des données d’identification de l’utilisateur dudit au moins un terminal de fournisseur. - Procédé de commande selon la revendication 1, dans lequel en cas de refus de l’offre, poursuivre la communication (S10 ; S13), au cours de laquelle les actions de recevoir une offre et de commander la restitution de l’offre reçue sont itérées, tant qu’une offre n’est pas acceptée.
- Procédé de commande selon l’une quelconque des revendications 1 à 3, dans lequel, au cours de la communication, le terminal reçoit, en provenance de respectivement N-K terminaux de fournisseur de produit ou de service identifiés par le serveur, N-K refus de fournir le produit ou le service correspondant à la requête.
- Procédé de commande selon l’une quelconque des revendications 1 à 4, dans lequel l’offre de produit ou de service reçue au cours de la communication est générée en tenant compte d’au moins une variable d’ajustement de :
- tout ou partie des informations contenues dans la requête, et/ou
- une donnée de localisation du terminal de communication, et/ou
- une donnée temporelle associée à la requête. - Terminal de communication sécurisée (TERu) adapté pour commander un produit ou un service, ledit terminal de communication étant associé à un identifiant de communication (ICu) et comprenant un processeur (PROC) qui est configuré pour mettre en œuvre ce qui suit :
- envoyer à un serveur, via un réseau de communication (RC), une requête de commande du produit ou du service, ladite requête contenant des informations relatives au produit ou au service,
- établir en arrière-plan une communication vers N terminaux associés respectivement à N identifiants de communication (N≥1), les N terminaux étant des terminaux de fournisseurs identifiés par le serveur comme étant aptes à fournir le produit ou le service, en fonction de tout ou partie des informations contenues dans la requête, ladite communication étant établie en masquant l’identifiant de communication du terminal et les N identifiants de communication,
- au cours de la communication, recevoir une offre du produit ou du service en provenance d’au moins un terminal de fournisseur parmi au moins K, tel que 1≤K≤ N, l’offre ayant été générée durant la communication et sélectionnée comme optimisant un compromis entre, d’une part, tout ou partie des informations contenues dans la requête et, d’autre part, une donnée de localisation du terminal de communication et/ou une donnée temporelle associée à la requête,
- commander la restitution de l’offre sur une interface du terminal, l’identifiant de communication dudit au moins un terminal de fournisseur ainsi que l’identification du fournisseur dudit au moins un terminal de fournisseur étant masqués lors de la restitution. - Programme d'ordinateur comportant des instructions de code de programme pour la mise en œuvre du procédé de commande selon l’une quelconque des revendications 1 à 5, lorsqu'il est exécuté sur un ordinateur.
- Support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur selon la revendication 7.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1903440A FR3094539A1 (fr) | 2019-04-01 | 2019-04-01 | Procédé de commande anonymisé d’un produit ou d’un service à l’aide d’un terminal de communication |
| US17/600,533 US20220180403A1 (en) | 2019-04-01 | 2020-03-20 | Secure communication method suitable for ordering a product or a service using a communication terminal |
| EP20732257.9A EP3948752A1 (fr) | 2019-04-01 | 2020-03-20 | Procédé de communication sécurisée adapté pour commander un produit ou un service à l'aide d'un terminal de communication |
| PCT/FR2020/050610 WO2020201663A1 (fr) | 2019-04-01 | 2020-03-20 | Procédé de communication sécurisée adapté pour commander un produit ou un service à l'aide d'un terminal de communication |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1903440A FR3094539A1 (fr) | 2019-04-01 | 2019-04-01 | Procédé de commande anonymisé d’un produit ou d’un service à l’aide d’un terminal de communication |
| FR1903440 | 2019-04-01 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3094539A1 true FR3094539A1 (fr) | 2020-10-02 |
Family
ID=68072538
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1903440A Pending FR3094539A1 (fr) | 2019-04-01 | 2019-04-01 | Procédé de commande anonymisé d’un produit ou d’un service à l’aide d’un terminal de communication |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20220180403A1 (fr) |
| EP (1) | EP3948752A1 (fr) |
| FR (1) | FR3094539A1 (fr) |
| WO (1) | WO2020201663A1 (fr) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1345396A1 (fr) * | 2001-08-14 | 2003-09-17 | Siemens Aktiengesellschaft | Rendre disponible d'un chiffre pour une annonce |
| FR2945364A1 (fr) * | 2009-05-06 | 2010-11-12 | Goodkap | Procede de mise en relation a l'usage de voyageurs, module et systeme associes |
| EP2500852A1 (fr) * | 2011-03-14 | 2012-09-19 | France Telecom | Traitement de données pour la gestion d'offres et de demandes de trajets de covoiturage |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB0001882D0 (en) * | 2000-01-28 | 2000-03-22 | Beca Limited | Raw cotton trading web |
| AUPR969501A0 (en) * | 2001-12-20 | 2002-01-24 | Global Trade Finance Network Pte Ltd | Forfaiting transactions |
| US7545784B2 (en) * | 2004-02-11 | 2009-06-09 | Yahoo! Inc. | System and method for wireless communication between previously known and unknown users |
| US20070203821A1 (en) * | 2006-02-24 | 2007-08-30 | Dufour Remi | Computer system, method and software capable of listing identified goods in transit or storage and managing buyer and seller communications regarding such goods |
| US20070226152A1 (en) * | 2006-03-21 | 2007-09-27 | Austin Jones | System and method for anonymous transactions and conveyances |
| AU2007307648A1 (en) * | 2006-10-12 | 2008-04-17 | Shapiro, Peter A | Method and system for making anonymous on-line purchases |
| US7797202B1 (en) * | 2007-02-20 | 2010-09-14 | Asian Atlantic Industries, Inc. | Method of masking the identities of both a bidder and seller in an auction |
| WO2009136262A1 (fr) * | 2008-05-06 | 2009-11-12 | Rejean Desrosiers | Système de portail inversé et procédé |
| US8438072B2 (en) * | 2009-02-20 | 2013-05-07 | Consumercartel, Llc | Online exchange system and method with reverse auction |
| US20110302096A1 (en) * | 2010-06-02 | 2011-12-08 | Apple Inc. | Authentication service for sales of goods and services |
| US20120005102A1 (en) * | 2010-07-02 | 2012-01-05 | Mcclung Robert Thomas | Method and System for Anonymous Communication Between A Consumer and Provider |
| US10074146B2 (en) * | 2010-08-26 | 2018-09-11 | Adam Selsby | Buyer driven market system and method |
| US20140108067A1 (en) * | 2012-10-11 | 2014-04-17 | Getgoing, Inc. | Using qualification events to provide price differentiation for travel products |
| US10713698B2 (en) * | 2014-01-27 | 2020-07-14 | Ushur, Inc. | Instant generation and usage of HTTP URL based unique identity for engaging in multi-modal real-time interactions in online marketplaces, social networks and other relevant places |
| US20170109814A1 (en) * | 2015-10-19 | 2017-04-20 | Wesley John Boudville | Linket to control mobile deep links |
-
2019
- 2019-04-01 FR FR1903440A patent/FR3094539A1/fr active Pending
-
2020
- 2020-03-20 WO PCT/FR2020/050610 patent/WO2020201663A1/fr unknown
- 2020-03-20 EP EP20732257.9A patent/EP3948752A1/fr active Pending
- 2020-03-20 US US17/600,533 patent/US20220180403A1/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1345396A1 (fr) * | 2001-08-14 | 2003-09-17 | Siemens Aktiengesellschaft | Rendre disponible d'un chiffre pour une annonce |
| FR2945364A1 (fr) * | 2009-05-06 | 2010-11-12 | Goodkap | Procede de mise en relation a l'usage de voyageurs, module et systeme associes |
| EP2500852A1 (fr) * | 2011-03-14 | 2012-09-19 | France Telecom | Traitement de données pour la gestion d'offres et de demandes de trajets de covoiturage |
Non-Patent Citations (2)
| Title |
|---|
| HUSSAIN M ET AL: "The case for service provider anonymity", SIGNAL PROCESSING AND INFORMATION TECHNOLOGY (ISSPIT), 2010 IEEE INTERNATIONAL SYMPOSIUM ON, IEEE, 15 December 2010 (2010-12-15), pages 114 - 119, XP031912810, ISBN: 978-1-4244-9992-2, DOI: 10.1109/ISSPIT.2010.5711743 * |
| NI JIANBING ET AL: "AMA: Anonymous mutual authentication with traceability in carpooling systems", 2016 IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS (ICC), IEEE, 22 May 2016 (2016-05-22), pages 1 - 6, XP032922371, DOI: 10.1109/ICC.2016.7511196 * |
Also Published As
| Publication number | Publication date |
|---|---|
| EP3948752A1 (fr) | 2022-02-09 |
| WO2020201663A1 (fr) | 2020-10-08 |
| US20220180403A1 (en) | 2022-06-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3243176B1 (fr) | Procédé de traitement d'une transaction à partir d'un terminal de communication | |
| FR2837953A1 (fr) | Systeme d'echange de donnees | |
| EP1269360A1 (fr) | Procede permettant a un adjudicateur de faire parvenir un appel d'offre a un ou plusieurs prestataires selectionnes | |
| FR3062499A1 (fr) | Procede de reduction de la taille d'une base de donnees repartie de type chaine de blocs, dispositif et programme correspondant | |
| FR3094539A1 (fr) | Procédé de commande anonymisé d’un produit ou d’un service à l’aide d’un terminal de communication | |
| EP3811312A1 (fr) | Procédé et dispositif de répartition par un agent conversationnel d'une dépense engagée par un utilisateur au sein d'un groupe d'utilisateurs | |
| FR2863811A1 (fr) | Systeme de communication entre un terminal mobile et un serveur de communication et les procedes de communications associes. | |
| EP3928501A1 (fr) | Procédé de gestion d'accès d'un utilisateur à un service vocal, dispositif, système et programmes correspondants | |
| EP3035723B1 (fr) | Procédé de transmission de données en relation avec une communication | |
| FR3101497A1 (fr) | Terminal, dispositif de personnalisation de requêtes de services et procédés permettant un service personnalisé. | |
| FR3023640A1 (fr) | Procede de gestion d'une transaction, serveur, produit programme d'ordinateur et medium de stockage correspondants. | |
| WO2018172669A1 (fr) | Procédé et dispositif de gestion du stockage de documents numériques | |
| FR3057085A1 (fr) | Controle de delegation de droits | |
| EP4099249A1 (fr) | Procédé et dispositif de transmission d'un identifiant d'un utilisateur lors d'un paiement électronique réalisépar l utilisateur | |
| FR3105477A3 (fr) | Système de distribution de contenu avec gestion de profil utilisateur | |
| FR3003966A1 (fr) | Procede d'adaptation dynamique d'un environnement logiciel execute a partir d'un terminal de communication d'un utilisateur, au cours d'une communication entre l'utilisateur et au moins un interlocuteur. | |
| EP4154137A1 (fr) | Procede et systeme d'authentification d'un utilisateur aupres d'un serveur d'authentification | |
| EP4032057A1 (fr) | Procede de transmission d'une information complementaire relative a une transaction financiere | |
| EP4320534A1 (fr) | Méthode de contrôle d'accès à un bien ou service distribué par un réseau de communication de données | |
| EP3502991A1 (fr) | Procede et dispositif de validation d'une transaction de paiement | |
| CH719332A2 (fr) | Procédé, système et terminal de collecte de marques d'intérêts pour déclencher des processus automatisés. | |
| EP3757865A1 (fr) | Procédé de traitement d'un message et dispositif correspondant | |
| EP2600592B1 (fr) | Procédés et dispositifs de communication permettant un échange asynchrone et privé | |
| FR3128840A1 (fr) | Supervision du fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes | |
| FR3143249A1 (fr) | Procédé et dispositif d’obtention d’au moins une donnée associée à un contenu audiovisuel en cours de consultation par un utilisateur |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20201002 |
|
| RX | Complete rejection |
Effective date: 20210412 |