FR3138541A1 - Procédé de création d’un avatar d’un utilisateur - Google Patents

Procédé de création d’un avatar d’un utilisateur Download PDF

Info

Publication number
FR3138541A1
FR3138541A1 FR2207675A FR2207675A FR3138541A1 FR 3138541 A1 FR3138541 A1 FR 3138541A1 FR 2207675 A FR2207675 A FR 2207675A FR 2207675 A FR2207675 A FR 2207675A FR 3138541 A1 FR3138541 A1 FR 3138541A1
Authority
FR
France
Prior art keywords
avatar
server
user
data
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.)
Pending
Application number
FR2207675A
Other languages
English (en)
Inventor
Serge LARA
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.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to FR2207675A priority Critical patent/FR3138541A1/fr
Publication of FR3138541A1 publication Critical patent/FR3138541A1/fr
Pending legal-status Critical Current

Links

Classifications

    • 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
    • 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
    • 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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Medical Informatics (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Procédé de création d’un avatar d’un utilisateur d’un terminal (1) connecté à un serveur de traitement (2) au moyen d’une connexion Internet, le serveur de traitement (2) étant connecté à un serveur boîte noire (4) par l’intermédiaire d’une connexion sécurisée, le procédé comprenant des étapes de :a) réception, par un serveur de traitement (2), de données utilisateur associées à un utilisateur d’un terminal (1) ;b) traitement à la volée par le serveur de traitement (2) des données utilisateur reçues et transmission par le serveur de traitement (2) des données utilisateur ainsi traitées au serveur boîte noire (4) ;c) chiffrement par le serveur boîte noire (4) des données utilisateur traitées de manière à obtenir des données utilisateur chiffrées et génération par le serveur boîte noire (4) d’un premier identifiant unique d’avatar associé aux données utilisateur chiffrées ;g) génération par le serveur de traitement (2) d’un avatar de l’utilisateur comprenant des données d’avatar associées au premier identifiant unique d’avatar. Figure pour l’abrégé : Fig. 3

Description

Procédé de création d’un avatar d’un utilisateur DOMAINE DE L’INVENTION
La présente invention concerne le domaine de la protection des données personnelles notamment la sécurisation de ces données. Et l’invention concerne plus précisément la création d’un avatar d’un utilisateur ainsi que la sécurisation d’une transaction financière au moyen d’un tel avatar.
 ETAT DE LA TECHNIQUE
La protection des données personnelles utilisées en ligne est aujourd’hui devenue un enjeu crucial. En effet, en ligne, un utilisateur transmet des données personnelles à des tiers sans forcément avoir le contrôle sur leur utilisation par ces tiers. En outre, les particuliers, les entreprises, les associations ou les collectivités sont tous exposés quotidiennement à des cyberattaques pouvant conduire au vol de ces données personnelles. Parmi les types de cyberattaques, on retrouve par exemple l’hameçonnage, le piratage de compte ou de compte bancaire ou encore le vol d’identité. Face à la recrudescence des cyberattaques et face à leur complexification, il est de plus en plus nécessaire de développer des solutions pour se protéger des cyberattaques. Une solution consiste à anonymiser et sécuriser un individu dans sa vie numérique. Il existe quelques solutions permettant d’anonymiser et de sécuriser un individu dans sa vie numérique : l’anonymisation et la pseudo-anonymisation, les VPN pour une navigation anonyme, les moteurs de recherches qui ne stockent pas les données, les boites mail anonymisées, les filtres spams, etc. Cependant, l’anonymisation empêche d’identifier un individu anonymisé qui commet une infraction et les vpn, les moteurs de recherche et boites mail anonymisés ne permettent pas l’avatarisation et la navigation avatarisée. En effet, lorsqu’un individu est anonymisé, il ne présente pas d’identité numérique et il ne peut donc pas effectuer tout type d’action numérique nécessitant la saisie de données personnelles. La protection des données personnelles d’un individu par l’avatarisation repose sur la non détention des informations personnelles, tout en lui permettant d’avoir une existence numérique complète. Ainsi, aucune solution existante de sécurisation des données personnelles ne permet à un individu de disposer d’une existence numérique complète, par exemple pour permettre un achat sur une plateforme de e-commerce, qui soit sécurisée mais qui permettent également d’identifier un individu commettant une infraction.
Un but de l’invention est de fournir une identité numérique sécurisée, plus précisément une identité numérique avatarisée.
Un autre but de l’invention est de fournir une identité numérique sécurisée qui ne soit pas complètement anonyme.
Selon un premier aspect, il est proposé un procédé de création d’un avatar d’un utilisateur d’un terminal connecté à un serveur de traitement au moyen d’une connexion Internet, le serveur de traitement étant connecté à un serveur boîte noire par l’intermédiaire d’une connexion sécurisée, le procédé comprenant des étapes de :
a) réception, par un serveur de traitement, de données utilisateur associées à un utilisateur d’un terminal ;
b) traitement à la volée par le serveur de traitement des données utilisateur reçues et transmission par le serveur de traitement des données utilisateur ainsi traitées au serveur boîte noire ;
c) chiffrement par le serveur boîte noire des données utilisateur traitées de manière à obtenir des données utilisateur chiffrées et génération par le serveur boîte noire d’un premier identifiant unique d’avatar associé aux données utilisateur chiffrées ;
g) génération par le serveur de traitement d’un avatar de l’utilisateur comprenant des données d’avatar associées au premier identifiant unique d’avatar.
Selon des caractéristiques avantageuses et non limitatives, prises seules ou dans une quelconque combinaison :
  • le procédé comprend les étapes de :
    d) envoi par le serveur boîte noire du premier identifiant unique d’avatar au serveur de traitement ;
    e) envoi par le serveur de traitement au terminal d’une autorisation de création de l’avatar de l’utilisateur ;
  • le serveur de traitement comprend des premiers moyens de stockage de données et le serveur boîte noire comprend des deuxièmes moyens de stockage de données, le procédé comprenant les étapes de :
    f) réception par le serveur de traitement de données d’authentification associées au premier identifiant unique d’avatar envoyées par le terminal ;
    et dans lequel, à l’étape g), la création de l’avatar est mise en œuvre à partir des données d’authentification et un deuxième identifiant unique d’avatar associé à l’avatar est généré par le serveur de traitement et dans lequel l’étape g) comprend l’enregistrement par le serveur de traitement dans les premiers moyens de stockage de données des données d’avatar, des données d’authentification et du deuxième identifiant unique d’avatar ;
  • les données d’authentification comprennent un identifiant d’utilisateur et un mot de passe ;
  • le procédé comprend l’étape de :
    h) envoi par le serveur de traitement du deuxième identifiant d’avatar au serveur boîte noire et enregistrement par le serveur boîte noire dans les deuxièmes moyens de stockage de données du deuxième identifiant d’avatar associé au premier identifiant unique d’avatar ;
  • le serveur boîte noire comprend des deuxièmes moyens de stockage de données et dans lequel l’étape c) comprend l’enregistrement par le serveur boîte noire dans les deuxièmes moyens de stockage de données du premier identifiant unique d’avatar et des données utilisateur chiffrées ;
  • les données d’utilisateur et les données d’avatar comprennent au moins un nom, une adresse mail et un numéro de téléphone ;
  • les données d’utilisateur et les données d’avatar comprennent un numéro de carte bancaire.
Selon un deuxième aspect, il est proposé un procédé de sécurisation d’une transaction financière mise en œuvre sur une plateforme de transaction sur un premier terminal d’un utilisateur, l’utilisateur disposant d’un compte bancaire et d’un avatar créé selon le procédé de création d’un avatar présenté précédemment, un module de transaction sécurisée étant installé sur le premier terminal, le premier terminal étant connecté à un serveur de transmission, le serveur de transmission étant connecté à un serveur bancaire, le procédé comprenant les étapes de :
b) envoi par le module de transaction sécurisée au serveur de transmission d’une requête de génération d’un numéro de carte bancaire d’avatar pour mettre en œuvre la transaction financière ;
c) envoi par le serveur de transmission au serveur bancaire d’un jeton d’authentification, le jeton d’authentification étant associé à un avatar de l’utilisateur du terminal ;
d) authentification de l’utilisateur par le serveur bancaire à partir du jeton d’authentification et envoi d’une requête de validation d’identité par le serveur bancaire à une plateforme bancaire ;
e) si l’identité de l’utilisateur est validée, génération d’une carte bancaire d’avatar et d’un numéro de carte bancaire d’avatar par le serveur bancaire, la carte bancaire d’avatar étant liée au compte bancaire de l’utilisateur ;
i) mise en œuvre de la transaction financière à partir du numéro de carte bancaire d’avatar.
Selon des caractéristiques avantageuses et non limitatives, prises seules ou dans une quelconque combinaison :
  • le procédé comprend les étapes de :
    f) envoi par le serveur bancaire au serveur de transmission du numéro de carte bancaire d’avatar ;
    g) envoi par le serveur de transmission au module de transaction sécurisée du numéro de carte bancaire d’avatar ;
    h) envoi par le module de transaction sécurisée à la plateforme de transaction du numéro de carte bancaire d’avatar ;
  • la plateforme bancaire est accessible sur le premier terminal ou sur un deuxième terminal ;
  • le serveur bancaire comprend des troisièmes moyens de stockage de données, le serveur de transmission comprend des quatrièmes moyens de stockage de données et dans lequel le procédé comprend préalablement les étapes de :
    a1) génération du jeton d’authentification par le serveur de transmission, enregistrement par le serveur de transmission sur les quatrièmes moyens de stockage de données du jeton d’authentification associé à l’avatar de l’utilisateur et envoi du jeton d’authentification par le serveur de transmission au serveur bancaire ;
    a2) authentification de l’utilisateur sur la plateforme bancaire;
    a4) enregistrement par le serveur bancaire sur les troisièmes moyens de stockage de données du jeton d’authentification associé à des données bancaires de l’utilisateur ;
    a5) envoi par le serveur bancaire d’une requête de confirmation de rattachement du compte bancaire à l’avatar ;
  • le procédé comprend l’étape de :
    a3) envoi d’une requête de validation d’identité par le serveur bancaire à la plateforme bancaire,
    et dans lequel les étapes a4) et a5) sont mises en œuvre seulement si l’identité de l’utilisateur est validée.
Selon un troisième aspect, il est proposé un système de création d’un avatar d’un utilisateur comprenant un serveur de traitement et un serveur boîte noire, le serveur de traitement comprenant des premiers moyens de stockage de données et le serveur boîte noire comprenant des deuxièmes moyens de stockage de données, le serveur de traitement et le serveur boîte noire étant configurés pour être connectés et pour mettre en œuvre des étapes du procédé de création d’un avatar présenté précédemment, le serveur de traitement étant configuré pour être connectés à au moins un terminal.
Selon des caractéristiques avantageuses et non limitatives, prises seules ou dans une quelconque combinaison :
  • le serveur de traitement et le serveur boîte noire sont connectés physiquement, de préférence par un câble ;
  • le serveur de traitement est configuré pour échanger des données avec le terminal en respectant un protocole HTTPS.
Selon un quatrième aspect, il est proposé un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé de création d’un avatar présenté précédemment, lorsque ledit programme est exécuté par un ordinateur.
Selon un cinquième aspect, il est proposé un moyen de stockage lisible par un équipement informatique sur lequel un produit programme d’ordinateur comprend des instructions de code pour l’exécution d’un procédé de création d’un avatar présenté précédemment.
 DESCRIPTION DES FIGURES
D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux figures annexées dont :
- La est un schéma d’une architecture générale pour la mise en œuvre d’un procédé de création d’avatar ;
- La est un schéma d’une architecture générale pour la mise en œuvre d’un procédé de sécurisation d’une transaction financière ;
- La illustre les étapes d’un procédé de création d’avatar ;
- La illustre les étapes d’un procédé de rattachement d’une carte bancaire à un avatar dans le cadre d’un procédé de sécurisation d’une transaction financière ;
- La illustre des étapes d’un procédé de sécurisation d’une transaction financière.
 DESCRIPTION DETAILLEE DE L’INVENTION Architecture
Selon un premier aspect, en référence à la , il est proposé un procédé de création d’un avatar d’un utilisateur d’un terminal 1 connecté à un serveur de traitement 2.
Le terminal 1 est typiquement un appareil électronique et peut être n’importe quel équipement lui-même adapté pour se connecter au serveur de traitement 2, le plus souvent un smartphone, mais possiblement une tablette tactile, un ordinateur portable ou fixe, une console de jeux, etc. Le terminal 1 est de préférence équipé d’un navigateur, d’une application mobile ou d’une interface de programmation d'application (API).
Le terminal 1 est connecté au serveur de traitement 2 au moyen d’une connexion Internet. Cette connexion peut être mise en œuvre par une liaison sans fil de type Wi-Fi, un câble, ou via un réseau de communication mobile (3G, 4G, 5G, etc.).
Le serveur de traitement 2 est typiquement configuré pour mettre en œuvre des traitements et comprend à ce titre un calculateur. De préférence, le serveur de traitement 2 et le terminal 1 sont configurés pour échanger des données de manière sécurisées via la connexion Internet. Avantageusement, le serveur de traitement 2 et le terminal 1 sont configurés pour échanger des données en respectant un protocole HTTPS (HyperText Transfer Protocol Secure pour protocole de transfert hypertexte sécurisé).
Le serveur de traitement 2 est connecté à un serveur boîte noire 4. Le serveur boîte noire 4 est typiquement configuré pour mettre en œuvre des traitements et comprend à ce titre un calculateur. Le serveur de traitement 2 est connecté au serveur boîte noire 4 par l’intermédiaire d’une connexion sécurisée. Préférentiellement, la connexion sécurisée est une connexion physique au moyen d’un câble reliant le serveur de traitement 2 au serveur boite noire 4.
Avantageusement, le serveur de traitement 2 comprend des premiers moyens de stockage de données 21 et le serveur boîte noire 4 comprend des deuxièmes moyens de stockage de données 41. Les moyens de stockage 21, 41 sont typiquement des bases de données.
Selon un deuxième aspect, en référence à la , il est proposé un procédé de sécurisation d’une transaction financière mise en œuvre sur une plateforme de transaction sur un premier terminal 11 d’un utilisateur, l’utilisateur disposant d’un avatar.
L’utilisateur peut également disposer d’un deuxième terminal 12.
Le premier terminal 11 et le deuxième terminal 12 sont typiquement des appareils électroniques et peuvent être par exemple un smartphone, une tablette tactile, un ordinateur portable, une console de jeux, etc. Selon un certain mode de réalisation, le premier terminal 11 et le deuxième terminal 12 sont un même terminal.
Le premier terminal 11 permet à l’utilisateur d’accéder à une plateforme de transaction. Par «plateforme de transaction», on entend toute plateforme numérique qui peut impliquer une transaction financière. La plateforme de transaction peut par exemple être un site de commerce en ligne.
Un module de transaction sécurisée 13 est installé sur le premier terminal 11. Le module de transaction sécurisée 13 est avantageusement un plugin, c’est-à-dire un logiciel conçu pour être greffé à un autre logiciel à travers une interface prévue à cet effet. Le module de transaction sécurisée 13 est par exemple conçu pour être greffé à un navigateur de recherche et est avantageusement adapté pour mettre en œuvre une transaction financière sécurisée lorsque l’utilisateur accède à une plateforme de transaction via le navigateur.
Le premier terminal 11 est connecté à un serveur de transmission 14 au moyen d’une connexion Internet. Cette connexion peut être mise en œuvre par une connexion sans fil de type Wi-Fi ou via un réseau de communication mobile (3G, 4G, 5G, etc.).
Le serveur de transmission 14 est typiquement configuré pour mettre en œuvre des traitements et comprend à ce titre un calculateur. De préférence, le serveur de transmission 14 et le premier terminal 11 sont configurés pour échanger des données de manière sécurisées via la connexion Internet. Avantageusement, le serveur de transmission 14 et le premier terminal 11 sont configurés pour échanger des données en respectant le protocole HTTPS.
Le serveur de transmission 14 est connecté à un serveur bancaire 16. Le serveur bancaire 16 est typiquement configuré pour mettre en œuvre des traitements et comprend à ce titre un calculateur. Le serveur de transmission 14 appartenant avantageusement à une banque (qui permet de fournir des services bancaires à des utilisateurs). Avantageusement, le serveur de transmission 14 et le serveur bancaire 16 sont connectés de manière sécurisée.
Avantageusement, le serveur bancaire 16 comprend des troisièmes moyens de stockage de données 161, le serveur de transmission 14 comprend des quatrièmes moyens de stockage de données 141. Les moyens de stockage 141, 161 sont typiquement des bases de données.
Le premier terminal 11 ou le deuxième terminal 12 permettent d’accéder à une plateforme bancaire. Par «plateforme bancaire», on entend toute plateforme permettant à un utilisateur disposant d’un compte bancaire dans une certaine banque d’accéder à l’état de son compte bancaire et de mettre en œuvre diverses opérations comme un virement depuis le compte bancaire ou une validation d’un paiement sollicité depuis le compte bancaire. La plateforme bancaire est typiquement un site ou une application mobile mise en place par une banque pour ses clients. De préférence, l’utilisateur dispose d’une carte bancaire associée à son compte bancaire, la carte bancaire étant associée à au moins un numéro de carte bancaire. Avantageusement, le premier terminal 11 et/ou le deuxième terminal 12 sont adaptés pour communiquer avec le serveur bancaire 16.
Procédés
Comme expliqué précédemment, il est proposé selon un premier aspect un procédé de création d’un avatar. Un avatar est une identité numérique définie par un ensemble de données personnelles avatarisées. Plus précisément, de manière connue, un utilisateur accédant à des services en ligne sur le réseau Internet est identifié sur ce réseau par des données utilisateur qui sont des données personnelles. De telles données personnelles comprennent notamment son nom, son adresse e-mail ou encore son numéro de carte bancaire le cas échéant. Un avatar de l’utilisateur peut également être identifié par ces mêmes types données personnelles mais ces données seront différentes des données personnelles de l’utilisateur. Les données personnelles de l’avatar sont des données personnelles expressément générées pour l’avatar. Ce sont, en quelle que sorte, de « fausses » données personnelles qui ne permettent pas de retrouver les vraies données personnelles de l’utilisateur. Ainsi, l’utilisateur peut naviguer sur Internet et effectuer des opérations sur Internet grâce à son identité avatarisée sans pour autant avoir à communiquer sa véritable identité et ainsi sans risquer de la mettre en danger. Grâce à cette identité avatarisée et donc grâce à son avatar, l’utilisateur peut par exemple effectuer des achats en lignes ou recevoir et envoyer des mails sur une boîte mail avatarisée tout en assurant la protection de ses données personnelles. Le seul risque qu’encoure l’utilisateur est le vol de son identité avatarisée ce qui ne représente en fait aucun danger pour lui puisque cette identité avatarisée n’est pas définie par de véritables données personnelles de l’utilisateur.
En référence à la , le procédé de création d’un avatar comprend une étape a) de réception, par le serveur de traitement 2, de données utilisateur. De préférence, pour créer son avatar, il est mis à la disposition de l’utilisateur une interface dédiée à laquelle il a par exemple accès via son terminal 1. Avantageusement, cette interface comprend des champs dans lequel l’utilisateur peut saisir ses données utilisateur. Les données utilisateur comprennent de préférence et de manière non limitative un nom (comme un nom de famille et/ou un prénom par exemple), une adresse mail et un numéro de téléphone. Encore de préférence, pour un usage plus étendu de l’avatar, les données utilisateur comprennent des informations bancaires comme un numéro de carte bancaire. Ainsi, avantageusement, les données utilisateur sont saisies via le terminal 1 par l’utilisateur et envoyée au serveur de traitement 2.
De préférence, les données utilisateur sont envoyées par le terminal 1 au serveur de traitement 2 via un tunnel sécurisé. Par exemple, les données peuvent être envoyées en respectant un protocole Secure Shell (SSH) ou via un réseau virtuel privé (RVP), en anglais Virtual Private Network (VPN).
Le procédé de création comprend ensuite une étape b) de traitement à la volée par le serveur de traitement 2 des données utilisateur reçues et de transmission par le serveur de traitement 2 des données utilisateur ainsi traitées au serveur boîte noire 4.
Le traitement à la volée est une technique en informatique qui consiste à chiffrer des données sans les stocker. Le traitement à la volée consiste à envoyer des données en sortie d’un équipement (i.e. ici le serveur de traitement 2) qui les reçoit dès le début de leur réception en entrée, ou sans attendre de les avoir totalement reçues. Le traitement à la volée est particulièrement adapté pour éviter le vol de données. En effet, les données sont traitées par le serveur de traitement 2 puis transmises au serveur boîte noire 4 sans être stockées par le serveur de traitement 2 de sorte qu’il est très compliqué, voire impossible, d’intercepter les données utilisateur dans le serveur de traitement 2 qui est accessible notamment via une connexion Internet et qui est donc par définition accessible.
Le traitement mis en œuvre par le serveur de traitement 2 est de préférence un chiffrement des données utilisateur pour sécuriser ces données.
Une fois traitées, les données utilisateur traitées sont transmises par le serveur de traitement 2 au serveur boîte noire 4. De préférence, les données utilisateur traitées sont envoyées au serveur boîte noire 4 via une connexion physique (comme un câble). Le serveur boite noire 4 n’est pas accessible via le réseau Internet.
Toujours en référence à la , le procédé de création comprend ensuite une étape c) de chiffrement par le serveur boîte noire 4 des données utilisateur traitées de manière à obtenir des données utilisateur chiffrées. En d’autres termes, le serveur boîte noire 4 chiffre davantage les données utilisateur. Avantageusement, le chiffrement mis en œuvre par le serveur boîte noire 4 permet d’obtenir une chaîne chiffrée et un dictionnaire uniques. Le dictionnaire permet de déchiffrer la chaîne chiffrée. De préférence, la chaîne chiffrée correspond à l’adresse mail et le numéro de téléphone de l’utilisateur chiffrés (chiffrés par le serveur de traitement 2 lors de l’étape de traitement à la volée puis par le serveur boîte noire 4 pour obtention de la chaîne chiffrée). Préférentiellement, le chiffrement mis en œuvre par le serveur boîte noire 4 est également de type à la volée.
Avantageusement, le chiffrement comprend en outre une étape de salissage des données utilisateur. Par «salissage», on entend un brouillage non prédictible des données utilisateur, de préférence plus particulièrement de la chaîne chiffrée. Par exemple, si la chaîne chiffrée est une séquence aléatoire de 0 et de 1, le salissage peut correspondre à l’insertion aléatoire de 0 et de 1 au sein de la chaîne chiffrée. Des algorithmes de désalissage sont prévus pour permettre de «désalir» les données salies, c’est-à-dire retrouver les données dans leur état non sali.
L’étape c) du procédé comprend en outre la génération par le serveur boîte noire 4 d’un premier identifiant unique d’avatar associé aux données utilisateur chiffrées. Avantageusement, le premier identifiant unique d’avatar et les données utilisateur chiffrées sont enregistrées dans les deuxièmes moyens de stockage de données 41 du serveur boîte noire 4.
De préférence, le procédé comprend une étape d) d’envoi par le serveur boîte noire 4 du premier identifiant unique d’avatar au serveur de traitement 2. Cet envoi est avantageusement mis en œuvre par l’intermédiaire de la connexion sécurisée (de préférence physique). De préférence également, le procédé comprend une étape e) d’envoi par le serveur de traitement 2 au terminal 1 d’une confirmation qu’il (i.e. le serveur de traitement) a bien en sa possession le premier identifiant unique d’avatar ce qui correspond à une autorisation de création d’avatar. Ceci signifie que l’utilisateur est autorisé à créer son avatar. De préférence, le premier identifiant unique d’avatar est conservé de manière temporaire dans le serveur de traitement 2 au moins le temps que l’utilisateur définisse ses d’authentification (voir étape suivante f). De préférence, le premier identifiant unique d’avatar n’est pas stocké durablement par le serveur de traitement 2.
Avantageusement, le procédé comprend une étape f) de réception par le serveur de traitement 2 des données d’authentification. Ces données d’authentification sont associées au premier identifiant unique d’avatar. Plus précisément, dans un premier temps, l’utilisateur saisit sur son terminal 1 des données d’authentification. Il est de préférence mis à la disposition de l’utilisateur une deuxième interface dédiée à laquelle il a par exemple accès via son terminal 1. Avantageusement, cette interface comprend des champs dans lequel l’utilisateur peut saisir les données d’authentification. Ces données d’authentification comprennent avantageusement un identifiant d’utilisateur (i.e. un login) et un mot de passe déterminés par l’utilisateur. Ces données d’authentification lui permettront ensuite, lorsqu’il nécessitera son avatar, d’utiliser son avatar. Ainsi, l’avatarisation présente l’avantage d’être réversible car, à partir des données d’authentification, l’utilisateur peut accéder à son avatar quand il le souhaite. Une fois les données d’authentification renseignées, les données d’authentification sont envoyées par le terminal 1 au serveur de traitement 2.
Le procédé comprend ensuite une étape g) de génération par le serveur de traitement 2 d’un avatar de l’utilisateur comprenant des données d’avatar associées au premier identifiant unique d’avatar. En d’autres termes, des données d’avatar sont générées par le serveur de traitement 2. Ces données d’avatar définissent l’identité de l’avatar de l’utilisateur. Ces données d’avatar sont associées au premier identifiant unique d’avatar et ce premier identifiant unique d’avatar identifie l’avatar. Les données d’avatar peuvent comprendre un nom d’avatar, une adresse mail d’avatar, un numéro de téléphone d’avatar ou même des informations bancaires d’avatar comme un numéro de carte bancaire d’avatar. En outre, l’étape g) comprend de préférence la génération d’un deuxième identifiant unique d’avatar par le serveur de traitement 2 qui est directement associé aux données d’avatar et qui est donc associé au premier identifiant unique d’avatar.
Ainsi, par «ces données d’avatar sont associées au premier identifiant unique d’avatar», on entend de préférence que les données d’avatar sont associées dans les premiers moyens de stockage de données 21 (i.e. les moyens de stockage de données du serveur de traitement 2) au deuxième identifiant unique d’avatar, le deuxième identifiant unique d’avatar étant lui-même de préférence associé au premier identifiant unique d’avatar dans les deuxièmes moyens de stockage de données 41 (i.e. les moyens de stockage de données du serveur boîte noire 4). En conséquence, les données d’avatar sont avantageusement associées au premier identifiant unique d’avatar via le deuxième identifiant unique d’avatar.
En effet, avantageusement, l’étape g) du procédé comprend l’enregistrement par le serveur de traitement 2 dans les premiers moyens de stockage de données 21 des données d’avatar, des données d’authentification et du deuxième identifiant unique d’avatar. De préférence, les données d’authentification enregistrées sont préalablement chiffrées par le serveur de traitement 2. En outre, le procédé comprend préférentiellement une étape h) d’envoi par le serveur de traitement 2 du deuxième identifiant d’avatar au serveur boîte noire 4 et d’enregistrement par le serveur boîte noire 4 dans les deuxièmes moyens de stockage de données 41 du deuxième identifiant d’avatar associé au premier identifiant unique d’avatar.
A l’issue du procédé de création d’avatar, les données d’avatar sont générées et stockées dans les premiers moyens de stockage de données 21. L’utilisateur dispose de ses données d’authentification pour utiliser son avatar à sa guise.
Selon un deuxième aspect, il est proposé un procédé de sécurisation d’une transaction financière mise en œuvre sur une plateforme de transaction sur un premier terminal 11 d’un utilisateur disposant d’un avatar. Par «transaction financière», on entend tout type de transaction financière comme un paiement émis et/ou reçu par l’utilisateur. Comme expliqué précédemment, la plateforme de transaction est par exemple un site de commerce en ligne. Il est admis que l’utilisateur s’est déjà créé un avatar, de préférence selon le procédé de création d’avatar décrit précédemment.
On rappelle également qu’un module de transaction sécurisée 13 est installé sur le premier terminal 11, que le premier terminal 11 est connecté à un serveur de transmission 14 et que le serveur de transmission 14 est connecté à un serveur bancaire 16.
De préférence, pour mettre en œuvre la sécurisation d’une transaction, l’utilisateur rattache une carte bancaire à son avatar. Pour cela, l’utilisateur sollicite via le premier terminal 11 le rattachement de son avatar à un compte bancaire. Plus précisément, l’utilisateur est authentifié avec ses données d’authentification d’avatar sur une plateforme d’avatar dédiée via laquelle il peut configurer son avatar et, en particulier, solliciter le rattachement de son avatar à un compte bancaire. De préférence, l’utilisateur sélectionne la banque hébergeant le compte bancaire auquel il souhaite rattacher son avatar. Le premier terminal 11 étant connecté au serveur de transmission 14, une requête de rattachement est envoyée par le premier terminal 11 au serveur de transmission 14 dans une étape a0) illustrée en .
Puis, en référence à la , suite à la réception de la requête de rattachement, dans une étape a1), un jeton d’authentification est généré et enregistré par le serveur de transmission 14 et envoyé par le serveur de transmission 14 au serveur bancaire 16. Le serveur bancaire 16 conserve le jeton d’authentification au moins pendant les étapes du procédé de rattachement d’une carte bancaire à l’avatar. Le jeton d’authentification est une donnée associée à l’avatar de l’utilisateur du premier terminal 11 et qui permet au serveur bancaire 16 d’authentifier l’avatar auquel il est souhaité qu’un compte bancaire soit rattaché. Le jeton d’authentification peut être typiquement une longue chaîne de caractères aléatoires unique. De préférence, le jeton d’authentification associé à l’avatar de l’utilisateur est stocké dans les quatrièmes moyens de stockage de données 141 du le serveur de transmission 14.
Préférentiellement, lorsque le jeton d’authentification est généré, l’utilisateur est redirigé sur une interface d’authentification de sa plateforme bancaire (la plateforme bancaire étant typiquement le site internet de la banque ou une application, par exemple mobile, de la banque) et le jeton d’authentification est à cette occasion transmis au serveur bancaire 16. Par exemple, si l’utilisateur accède à la plateforme d’avatar via un navigateur, lorsqu’il sollicite le rattachement, il est redirigé sur le site de sa banque et l’adresse web à laquelle il est redirigé comprend le jeton d’authentification de sorte que le serveur bancaire 16 reçoit le jeton d’authentification. De préférence, le jeton d’authentification communiqué au serveur bancaire 16 est chiffré, par exemple via un certificat électronique de la banque (de préférence un certificat Secure Sockets Layer (SSL)).
De préférence, le procédé de sécurisation comprend en outre une étape a2) d’authentification de l’utilisateur sur la plateforme bancaire de sa banque. Plus précisément, sur le premier terminal 11, l’utilisateur est redirigé sur une interface d’authentification de sa plateforme bancaire. Cette authentification correspond classiquement à une authentification de l’utilisateur sur la plateforme bancaire mis à sa disposition par sa banque pour accéder à ses données bancaires et pour mettre en œuvre diverses opérations bancaires.
Une fois l’authentification réalisée, le procédé de sécurisation comprend de préférence une étape a3) d’envoi d’une requête de validation d’identité par le serveur bancaire 16 à la plateforme bancaire. Typiquement, une interface de validation de la plateforme bancaire est affichée par le premier terminal 11 et requiert par exemple la saisie d’un code, d’une empreinte digitale ou encore d’une capture du visage de l’utilisateur pour permettre la validation de l’identité de l’utilisateur. En fait, cette étape vise à confirmer que l’utilisateur qui souhaite rattacher un compte bancaire à son avatar est bien la personne propriétaire de la carte bancaire.
Une fois l’identité validée, et de préférence seulement si elle est validée, le procédé comprend une étape a4) du procédé comprend de préférence l’enregistrement par le serveur bancaire 16 sur les troisièmes moyens de stockage de données 161 (i.e. les moyens de stockage de données du serveur bancaire) du jeton d’authentification associé à des données bancaires de l’utilisateur. En fait, ici, le jeton d’authentification est stocké et rattaché au compte de l’utilisateur dans les troisièmes moyens de stockage de données 161.
En outre également, une fois l’identité validée, et de préférence seulement si elle est validée, l’étape a5) est mise en œuvre consistant à envoyer par le serveur bancaire 16 une requête de confirmation au serveur de transmission 14 qu’un compte bancaire a bien été rattaché à l’avatar. La requête de confirmation comprend au moins une information selon laquelle un compte bancaire a bien été rattaché à l’avatar. La requête de confirmation comprend en outre le jeton d’authentification ce qui permet au serveur de transmission 14 d’identifier l’avatar correspondant au jeton d’authentification et ainsi d’enregistrer la confirmation de rattachement pour le bon avatar. En conséquence, à l’issue de l’étape a5), il est admis qu’un compte bancaire est rattaché à l’avatar. La sollicitation d’une carte bancaire pourra ainsi être réalisée à partir du jeton d’authentification. De préférence, la requête de confirmation est chiffrée, par exemple via un certificat SSL.
Lorsqu’un compte bancaire est rattaché à l’avatar de l’utilisateur, l’utilisateur peut effectuer des transactions financières sans avoir à communiquer sa véritable identité et donc de manière sécurisée. Ainsi, en référence à la , lorsque l’utilisateur souhaite effectuer une transaction financière sécurisée, une étape b) est mise en œuvre d’envoi par le module de transaction sécurisée 13 au serveur de transmission 14 d’une requête de génération d’un numéro de carte bancaire d’avatar pour mettre en œuvre la transaction financière. En effet, comme expliqué précédemment, l’avatar est défini par une identité avatarisée qui comprend avantageusement un numéro de carte bancaire d’avatar. Ce numéro de carte bancaire d’avatar n’est pas le vrai numéro de carte bancaire de l’utilisateur. C’est un numéro de carte bancaire qui est spécifiquement généré par le serveur bancaire 16 pour l’utilisateur lorsque celui-ci veut effectuer une transaction financière sécurisée. Ainsi, le procédé de sécurisation repose sur la création d’un numéro de carte bancaire d’avatar.
De préférence, la requête de génération d’un numéro de carte bancaire d’avatar comprend au moins le montant de la transaction financière sollicitée. Préférentiellement, la requête de génération est chiffrée, par exemple via un certificat SSL.
Suite à la réception de la requête de génération du numéro de carte bancaire d’avatar, dans une étape c), le serveur de transmission 14 envoie au serveur bancaire 16 le jeton d’authentification associé à l’avatar de l’utilisateur et préalablement stocké dans les quatrièmes moyens de stockage de données 141 (i.e. les moyens de stockage de données du serveur de transmission 14).
Le procédé de sécurisation comprend ensuite une étape d) dans laquelle le serveur bancaire 16 authentifie l’utilisateur à partir du jeton d’authentification puis envoie une requête de validation d’identité à la plateforme bancaire. La requête de validation d’identité est similaire à celle effectuée en étape a3). Ici, la validation d’identité vise à sécuriser d’autant plus la transaction financière et à s’assurer que la personne qui sollicite la transaction financière via l’avatar est bien la personne propriétaire du compte bancaire auquel est rattaché le jeton d’authentification. La validation d’identité est effectuée via une interface de validation d’identité de la plateforme bancaire sur le premier terminal 11 ou sur un deuxième terminal 12 de l’utilisateur.
Puis, dans une étape e), si l’identité de l’utilisateur est validée, le serveur bancaire 16 génère une carte bancaire d’avatar et donc un numéro de carte bancaire d’avatar. La carte bancaire d’avatar, et donc le numéro de carte bancaire d’avatar, sont liés au compte bancaire de l’utilisateur. En fait, le numéro de carte bancaire d’avatar ne permet pas de retrouver le vrai numéro de carte bancaire de l’utilisateur. En revanche, ce numéro de carte bancaire d’avatar permet à l’utilisateur d’effectuer la transaction financière de sorte que, si c’est par exemple un paiement, c’est bien sur son compte bancaire que de l’argent sera retiré. Le numéro de carte bancaire d’avatar est donc associé au compte bancaire de l’utilisateur. Préférentiellement, la carte bancaire d’avatar permet exclusivement la transaction concernée c’est-à-dire que la carte bancaire d’avatar est prévue pour être utilisée pour un montant unique et un destinataire unique. Ainsi, seule la transaction qu’a initié l’utilisateur peut être mise en œuvre à partir de la carte bancaire d’avatar. En fait, la carte bancaire d’avatar est de préférence à usage unique. En outre, de préférence, le numéro de carte bancaire est valable pour une durée déterminée.
Le procédé de sécurisation comprend ensuite une étape f) d’envoi du numéro de carte bancaire d’avatar par le serveur bancaire 16 au serveur de transmission 14. Avantageusement, cet envoi est effectué avec un appel API (application programming interface ou « interface de programmation d'application ») sécurisé. Cet envoi est de préférence sécurisé car, de préférence, le serveur bancaire 16 est connecté de manière sécurisée au serveur de transmission 14. De préférence, l’envoi est sécurisé par exemple via un certificat SSL. Le serveur bancaire 16 envoie également le jeton d’authentification pour que le serveur de transmission 14 puisse identifier l’avatar concerné.
Puis, dans une étape g), le serveur de transmission 14 envoie au module de transaction sécurisée 13 le numéro de carte bancaire avatar. Avantageusement, cet envoi est effectué avec un appel API sécurisé. Cet envoi est de préférence sécurisé car, de préférence, le serveur de transmission 14 est connecté de manière sécurisée au module de transaction sécurisée 13. Le module de transaction sécurisée 13 envoie ensuite, dans une étape h), à la plateforme de transaction le numéro de carte bancaire d’avatar. De préférence, l’interface de la plateforme de transaction affichée par le premier terminal 11 à l’utilisateur est une interface de paiement comprenant des champs pour renseigner des informations bancaires dont un numéro de carte bancaire. Idéalement, suite à la réception du numéro de carte bancaire d’avatar par la plateforme de transaction, le champ pour le numéro de carte bancaire est automatiquement rempli avec le numéro de carte bancaire d’avatar.
Pour finir, le procédé de sécurisation comprend une étape i) de mise en œuvre de la transaction financière à partir du numéro de carte bancaire d’avatar. En d’autres termes, l’utilisateur valide la mise en œuvre de la transaction financière et la transaction est réalisée.
La transaction financière est ainsi très sécurisée puisque le numéro de carte bancaire d’avatar n’est pas stocké dans des moyens de stockage de données (donc il est quasiment impossible pour un hacker de voler ce numéro), ne peut être utilisé que pour une transaction particulière (de préférence au moins pour un montant et un destinataire particulier) et n’est généré que si l’individu propriétaire du compte bancaire a validé son identité.
De manière alternative, les étapes du procédé de sécurisation de transaction financière ci-dessus décrit peuvent être mises en œuvre de manière similaire pour sécuriser tout type de transactions numériques.
En effet, de manière avantageuse, l’avatar peut être utilisé pour sécuriser toute transaction qu’elle soit, par exemple, financière ou de donnée, avec un tiers de confiance (dans le mode de réalisation décrit précédemment, le tiers de confiance est la banque). On précise qu’un tiers de confiance est toute entité qui met en œuvre des opérations d’authentification pour effectuer des opérations sécurisées. Dans ce cas, l’utilisateur rattache son avatar à son compte pour le tiers de confiance et peut ensuite mettre en œuvre des transaction sécurisées avec ce tiers.
Par exemple, l’avatar peut permettre de sécuriser une procédure de vote dématérialisée organisé par un tiers de confiance. Il est admis que l’utilisateur dispose au préalable d’un avatar et d’un compte pour ce tiers de confiance (par exemple un compte sur un site gouvernemental sur lequel le vote dématérialisé peut être effectué). L’utilisateur peut alors rattacher à son avatar son compte. Puis, l’utilisateur pourra voter sur ce tiers de confiance en utilisant son avatar.
Produit programme et moyens de stockage
Selon un quatrième aspect, il est proposé un produit programme d’ordinateur comprenant des instructions de code pour l’exécution du procédé de création d’un avatar, lorsque ledit programme est exécuté par un calculateur.
Selon un cinquième aspect, il est proposé un moyen de stockage lisible par un équipement informatique sur lequel un produit programme d’ordinateur comprend des instructions de code pour l’exécution du procédé de création d’un avatar.

Claims (18)

  1. Procédé de création d’un avatar d’un utilisateur d’un terminal (1) connecté à un serveur de traitement (2) au moyen d’une connexion Internet, le serveur de traitement (2) étant connecté à un serveur boîte noire (4) par l’intermédiaire d’une connexion sécurisée, le procédé comprenant des étapes de :
    a) réception, par un serveur de traitement (2), de données utilisateur associées à un utilisateur d’un terminal (1) ;
    b) traitement à la volée par le serveur de traitement (2) des données utilisateur reçues et transmission par le serveur de traitement (2) des données utilisateur ainsi traitées au serveur boîte noire (4) ;
    c) chiffrement par le serveur boîte noire (4) des données utilisateur traitées de manière à obtenir des données utilisateur chiffrées et génération par le serveur boîte noire (4) d’un premier identifiant unique d’avatar associé aux données utilisateur chiffrées ;
    g) génération par le serveur de traitement (2) d’un avatar de l’utilisateur comprenant des données d’avatar associées au premier identifiant unique d’avatar.
  2. Procédé selon la revendication 1, comprenant les étapes de :
    d) envoi par le serveur boîte noire (4) du premier identifiant unique d’avatar au serveur de traitement (2) ;
    e) envoi par le serveur de traitement (2) au terminal (1) d’une autorisation de création de l’avatar de l’utilisateur.
  3. Procédé selon l’une des revendications 1 et 2, dans lequel le serveur de traitement (2) comprend des premiers moyens de stockage de données (21) et le serveur boîte noire (4) comprend des deuxièmes moyens de stockage de données (41), le procédé comprenant les étapes de :
    f) réception par le serveur de traitement (2) de données d’authentification associées au premier identifiant unique d’avatar envoyées par le terminal (1) ;
    et dans lequel, à l’étape g), la création de l’avatar est mise en œuvre à partir des données d’authentification et un deuxième identifiant unique d’avatar associé à l’avatar est généré par le serveur de traitement (2) et dans lequel l’étape g) comprend l’enregistrement par le serveur de traitement (2) dans les premiers moyens de stockage de données (21) des données d’avatar, des données d’authentification et du deuxième identifiant unique d’avatar.
  4. Procédé selon la revendication 3, dans lequel les données d’authentification comprennent un identifiant d’utilisateur et un mot de passe.
  5. Procédé selon l’une des revendications 3 et 4, comprenant l’étape de :
    h) envoi par le serveur de traitement (2) du deuxième identifiant d’avatar au serveur boîte noire (4) et enregistrement par le serveur boîte noire (4) dans les deuxièmes moyens de stockage de données (41) du deuxième identifiant d’avatar associé au premier identifiant unique d’avatar.
  6. Procédé selon l’une des revendications 1 à 5, dans lequel le serveur boîte noire (4) comprend des deuxièmes moyens de stockage de données (41) et dans lequel l’étape c) comprend l’enregistrement par le serveur boîte noire (4) dans les deuxièmes moyens de stockage de données (41) du premier identifiant unique d’avatar et des données utilisateur chiffrées.
  7. Procédé selon l’une des revendications 1 à 6, dans lequel les données d’utilisateur et les données d’avatar comprennent au moins un nom, une adresse mail et un numéro de téléphone.
  8. Procédé selon l’une des revendications 1 à 7, dans lequel les données d’utilisateur et les données d’avatar comprennent un numéro de carte bancaire.
  9. Procédé de sécurisation d’une transaction financière mise en œuvre sur une plateforme de transaction sur un premier terminal (11) d’un utilisateur, l’utilisateur disposant d’un compte bancaire et d’un avatar créé selon le procédé de l’une des revendications 1 à 8, un module de transaction sécurisée (13) étant installé sur le premier terminal (11), le premier terminal (11) étant connecté à un serveur de transmission (14), le serveur de transmission (14) étant connecté à un serveur bancaire (16), le procédé comprenant les étapes de :
    b) envoi par le module de transaction sécurisée (13) au serveur de transmission (14) d’une requête de génération d’un numéro de carte bancaire d’avatar pour mettre en œuvre la transaction financière ;
    c) envoi par le serveur de transmission (14) au serveur bancaire (16) d’un jeton d’authentification, le jeton d’authentification étant associé à un avatar de l’utilisateur du terminal (1) ;
    d) authentification de l’utilisateur par le serveur bancaire (16) à partir du jeton d’authentification et envoi d’une requête de validation d’identité par le serveur bancaire (16) à une plateforme bancaire ;
    e) si l’identité de l’utilisateur est validée, génération d’une carte bancaire d’avatar et d’un numéro de carte bancaire d’avatar par le serveur bancaire (16), la carte bancaire d’avatar étant liée au compte bancaire de l’utilisateur ;
    i) mise en œuvre de la transaction financière à partir du numéro de carte bancaire d’avatar.
  10. Procédé selon la revendication 9, comprenant les étapes de :
    f) envoi par le serveur bancaire (16) au serveur de transmission (14) du numéro de carte bancaire d’avatar ;
    g) envoi par le serveur de transmission (14) au module de transaction sécurisée (13) du numéro de carte bancaire d’avatar ;
    h) envoi par le module de transaction sécurisée (13) à la plateforme de transaction du numéro de carte bancaire d’avatar.
  11. Procédé selon l’une des revendications 9 et 10, dans lequel la plateforme bancaire est accessible sur le premier terminal (11) ou sur un deuxième terminal (12).
  12. Procédé selon l’une des revendications 9 à 11, dans lequel le serveur bancaire (16) comprend des troisièmes moyens de stockage de données, le serveur de transmission (14) comprend des quatrièmes moyens de stockage de données et dans lequel le procédé comprend préalablement les étapes de :
    a1) génération du jeton d’authentification par le serveur de transmission (14), enregistrement par le serveur de transmission (14) sur les quatrièmes moyens de stockage de données du jeton d’authentification associé à l’avatar de l’utilisateur et envoi du jeton d’authentification par le serveur de transmission (14) au serveur bancaire (16) ;
    a2) authentification de l’utilisateur sur la plateforme bancaire;
    a4) enregistrement par le serveur bancaire (16) sur les troisièmes moyens de stockage de données du jeton d’authentification associé à des données bancaires de l’utilisateur ;
    a5) envoi par le serveur bancaire (16) d’une requête de confirmation de rattachement du compte bancaire à l’avatar.
  13. Procédé selon la revendication 12, comprenant l’étape de :
    a3) envoi d’une requête de validation d’identité par le serveur bancaire (16) à la plateforme bancaire,
    et dans lequel les étapes a4) et a5) sont mises en œuvre seulement si l’identité de l’utilisateur est validée.
  14. Système de création d’un avatar d’un utilisateur comprenant un serveur de traitement (2) et un serveur boîte noire (4), le serveur de traitement (2) comprenant des premiers moyens de stockage de données (21) et le serveur boîte noire (4) comprenant des deuxièmes moyens de stockage de données (41), le serveur de traitement (2) et le serveur boîte noire (4) étant configurés pour être connectés et pour mettre en œuvre des étapes du procédé de création d’un avatar selon l’une des revendications 1 à 8, le serveur de traitement (2) étant configuré pour être connectés à au moins un terminal (1).
  15. Système selon la revendication 14, dans lequel le serveur de traitement (2) et le serveur boîte noire (4) sont connectés physiquement, de préférence par un câble.
  16. Système selon l’une des revendications 14 et 15, dans lequel le serveur de traitement (2) est configuré pour échanger des données avec le terminal (1) en respectant un protocole HTTPS.
  17. Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé de création d’un avatar selon l’une des revendications 1 à 8, lorsque ledit programme est exécuté par un ordinateur.
  18. Moyen de stockage lisible par un équipement informatique sur lequel un produit programme d’ordinateur comprend des instructions de code pour l’exécution d’un procédé de création d’un avatar selon l’une des revendications 1 à 8.
FR2207675A 2022-07-26 2022-07-26 Procédé de création d’un avatar d’un utilisateur Pending FR3138541A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR2207675A FR3138541A1 (fr) 2022-07-26 2022-07-26 Procédé de création d’un avatar d’un utilisateur

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2207675 2022-07-26
FR2207675A FR3138541A1 (fr) 2022-07-26 2022-07-26 Procédé de création d’un avatar d’un utilisateur

Publications (1)

Publication Number Publication Date
FR3138541A1 true FR3138541A1 (fr) 2024-02-02

Family

ID=84053350

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2207675A Pending FR3138541A1 (fr) 2022-07-26 2022-07-26 Procédé de création d’un avatar d’un utilisateur

Country Status (1)

Country Link
FR (1) FR3138541A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1028401A2 (fr) * 1999-02-12 2000-08-16 Citibank, N.A. Méthode et système pour exécuter une transaction avec cartes bancaires
US20130205135A1 (en) * 2012-02-03 2013-08-08 Daniel Joseph Lutz System and method of storing data
US20170364920A1 (en) * 2016-06-16 2017-12-21 Vishal Anand Security approaches for virtual reality transactions
US20210042854A1 (en) * 2019-08-09 2021-02-11 Forward Impact Enterprises, LLC System and method for providing a technology-supported-trusted-performance feedback and experiential learning system
US20210383377A1 (en) * 2018-06-22 2021-12-09 Mshift, Inc. Decentralized identity verification platforms

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1028401A2 (fr) * 1999-02-12 2000-08-16 Citibank, N.A. Méthode et système pour exécuter une transaction avec cartes bancaires
US20130205135A1 (en) * 2012-02-03 2013-08-08 Daniel Joseph Lutz System and method of storing data
US20170364920A1 (en) * 2016-06-16 2017-12-21 Vishal Anand Security approaches for virtual reality transactions
US20210383377A1 (en) * 2018-06-22 2021-12-09 Mshift, Inc. Decentralized identity verification platforms
US20210042854A1 (en) * 2019-08-09 2021-02-11 Forward Impact Enterprises, LLC System and method for providing a technology-supported-trusted-performance feedback and experiential learning system

Similar Documents

Publication Publication Date Title
US8074257B2 (en) Framework and technology to enable the portability of information cards
EP2619941B1 (fr) Procede, serveur et systeme d'authentification d'une personne
WO2002033933A1 (fr) Procede de controle d'acces a des adresses de sites internet
EP3391614B1 (fr) Procédé de transmission d'une information numérique
FR2823400A1 (fr) Dispositif securise d'echange de donnees
WO2012031755A2 (fr) Procede d'authentification pour l'acces a un site web
EP3163487B1 (fr) Procédé de sécurisation de traitement de données transactionnelles, terminal et programme d'ordinateur correspondant
CA2414469A1 (fr) Procede de controle d`acces a un contenu et systeme pour le controle d`acces a un contenu
EP2813962B1 (fr) Méthode de contrôle d'accès à un type de services spécifique et dispositif d'authentification pour le contrôle de l'accès à un tel type de services.
FR2795264A1 (fr) Systeme et procedes d'acces securise a un serveur informatique utilisant ledit systeme
FR3138541A1 (fr) Procédé de création d’un avatar d’un utilisateur
EP2009571B1 (fr) Système et procédé de sécurisation utilisant un dispositif de sécurité
WO2021116627A1 (fr) Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication
WO2001073706A1 (fr) Systeme de paiement permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi-public
FR3057085A1 (fr) Controle de delegation de droits
EP3570518B1 (fr) Systeme et procede d'authentification utilisant un jeton a usage unique de duree limitee
EP3371760A1 (fr) Procédé de verification d'identité lors d'une virtualisation
FR3114714A1 (fr) Procédé d’accès à un ensemble de données d’un utilisateur.
FR3007929A1 (fr) Procede d'authentification d'un utilisateur d'un terminal mobile
EP1988483A2 (fr) Cadre et technologie pour permettre la portabilité des cartes d'information
WO2023001846A1 (fr) Procédé de transaction entre un organisme et un établissement sur une chaîne de blocs
WO2023274979A1 (fr) Procédé d'authentification de transaction utilisant deux canaux de communication
FR3143143A1 (fr) Procédé de connexion à un compte personnel sur un service en ligne au moyen d’une chaîne de blocs
FR2888437A1 (fr) Procede et systeme de controle d'acces a un service d'un fournisseur d'acces implemente sur un serveur multimedia, module, serveur, terminal et programmes pour ce systeme
EP4320534A1 (fr) Méthode de contrôle d'accès à un bien ou service distribué par un réseau de communication de données

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20240202

PLFP Fee payment

Year of fee payment: 3