Brevet FR3028977A1 — publié le 20160527

« Procédé pour prévenir l'usurpation d'identité au cours d'une transaction et système s'y rapportant » Introduction L'invention se rapporte à un procédé pour prévenir l'usurpation d'identité. Il est également proposé un système mettant en oeuvre ce procédé. Art antérieur L'invention appartient au domaine des procédés de vérification de la validité d'un document mis en oeuvre au cours d'une transaction locale ou distante. En 2012, 8 % des français d'un échantillon de 1 050 personnes ont déclaré avoir été victimes de la criminalité identitaire sur les dix dernières années, ce qui confirme l'importance de cette forme de criminalité. On rencontre cette situation notamment lors de l'ouverture d'une ligne téléphonique ou d'un compte en banque. Dans le domaine précité, la validité d'un document est vérifiée par authentification du document, c'est à dire en vérifiant que le document est un authentique, c'est à dire que le document n'est pas un document contrefait. La solution proposée par la société Icar permet une identification automatique d'un client par une lecture et une authentification de son document d'identité. Lors d'un enregistrement du client d'un organisme dans des bases de données, le document du client est numérisé et les informations qu'il contient sont extraites, classées et enregistrées dans des bases de données et des applications de l'organisme client de la société. Cette solution détecte un grand nombre de documents d'identité falsifiés. Cette solution ne traite pas le risque lié à la présentation d'un document authentique, non falsifié, mais n'appartenant pas à la personne qui le présente. Ce risque peut être généré par la perte d'un document d'identité par une personne physique. Bien que la personne physique ait pu déclaré, par exemple, à la police cette perte, le document d'identité peut être retrouvé par une personne malintentionnée qui peut alors indument en tirer avantage, par exemple dans un hôtel. 3028977 - 2 - Un but de l'invention est de proposer un procédé et un système se rapportant au procédé permettant de vérifier l'identité de l'utilisateur en plus de l'authenticité du document présenté par ce dernier. Un autre but de l'invention est de proposer un procédé et un système se 5 rapportant au procédé permettant à un utilisateur d'alerter en temps réel des membres d'une communauté autorisée à connaître le statut d'un document qui lui est personnel. Exposé de l'invention Selon un premier aspect de l'invention, on atteint au moins un des buts 10 précités avec un procédé mettant en oeuvre une première base de données sur un serveur interrogeable par un premier serveur d'application, la base de données comprenant au moins un document associé à l'identité d'un premier utilisateur, dit utilisateur protégé, le document étant en outre associé à un statut relatif au document, le statut étant enregistré dans la 15 base de données, le utilisateur protégé étant associé à des données d'utilisateur protégé, les données d'utilisateur protégé étant enregistrées dans la base de données. Selon l'invention, le procédé comprend en outre : - une détermination par un utilisateur partenaire ou une serveur 20 d'application de l'identité de l'utilisateur protégé et de données d'utilisateurs associées à cet utilisateur à partir d'une présentation d'un document par un deuxième utilisateur, dit utilisateur postulant, cette détermination comprenant : o une interrogation de la base de données depuis l'ordinateur 25 (PC1, PC2, PC3) à partir du document pour déterminer si le document est enregistré dans la base de données ; o si le document est enregistré dans la base de données, une interrogation de la base de données pour déterminer le statut du document ; sinon la détermination de l'identité est arrêtée 30 sur échec ; o si le statut du document n'est pas valide, la détermination de l'identité est arrêtée sur échec ; o si le statut du document est valide, une interrogation de la base de données pour déterminer l'identité de l'utilisateur protégé 3028977 - 3 - associé au document et des données d'utilisateur protégé associées à l'utilisateur protégé ; - une étape de comparaison de données renseignées par l'utilisateur postulant et de données générées à partir des données d'utilisateur 5 protégé pour déterminer que l'identité de l'utilisateur protégé est la même que l'identité de l'utilisateur postulant. Ainsi, le procédé selon l'invention permet de proposer un procédé permettant à une communauté d'utilisateurs partenaires de connaître en temps réel le statut d'un document qui est personnel à l'utilisateur protégé. 10 De préférence, le document présenté par l'utilisateur postulant est lu par l'utilisateur partenaire au moyen d'une technologie de reconnaissance de caractère. Selon une particularité, l'inscription dans la base de données d'un utilisateur à protéger est réalisée à partir de la présentation d'un document 15 préalablement authentifié. Ainsi, le procédé selon l'invention permet de proposer un procédé permettant de vérifier l'identité de l'utilisateur en plus de l'authenticité du document présenté par ce dernier. Selon un mode de réalisation, le procédé comprend en outre une étape 20 de réception par l'utilisateur partenaire des données renseignées par l'utilisateur postulant, l'étape de comparaison comprenant une comparaison d'une partie des données renseignées par l'utilisateur postulant et d'une partie des données générées. Ce mode de réalisation est privilégié lorsque l'utilisateur postulant et l'utilisateur partenaire peuvent communiquer 25 directement. En ce cas, l'utilisateur partenaire peut directement interroger l'utilisateur postulant pour comparer des renseignements fournis par ce dernier aux données d'utilisateur protégé associées au document présenté. Selon une mode de réalisation, le procédé comprend en outre une étape d'émission de données, dites données de contrôle, de préférence un code de 30 vérification aléatoire, à destination de l'utilisateur protégé et l'étape de comparaison comprend une comparaison des données de contrôle et des données renseignées par l'utilisateur postulant. Ce mode de réalisation est privilégié lorsque l'utilisateur postulant et l'utilisateur partenaire ne peuvent communiquer directement mais sont distants. En ce cas, et par exemple, un SMS comprenant un code peut être envoyé à destination de l'utilisateur 3028977 - 4 - protégé, qui si il est aussi l'utilisateur postulant peut alors renseigner des données comprenant le code. Avantageusement, le procédé selon l'invention comprend une étape de modification du statut d'un document associé à un utilisateur protégé par 5 l'utilisateur protégé à partir d'un terminal connecté de manière sécurisé à un serveur d'application connecté à la base de données. Ainsi, le procédé selon l'invention permet à un utilisateur protégé d'alerter en temps réel les membres d'une communauté autorisée à connaître le statut d'un document qui lui est personnel. On évite ainsi un 10 temps d'attente lié à une demande de modification du statut par ordinateur de la communauté. Avantageusement, le procédé selon l'invention comprend une étape d'authentification d'un utilisateur protégé auprès du serveur d'application et cette étape est suffisante pour autoriser l'utilisateur protégé à modifier 15 directement le statut d'un document associé à l'utilisateur protégé. Ainsi, le procédé selon l'invention permet à un utilisateur protégé d'alerter en temps réel les membres d'une communauté autorisée à connaître le statut d'un document qui lui est personnel. On évite ainsi un temps d'attente lié à une demande de modification par un utilisateur 20 membre de la communauté. Selon une particularité de l'invention, l'authentification est mise en oeuvre à partir d'une carte à puce ou d'un paramètre biométrique. Ce type d'authentification permet de garantir un niveau de sécurité important qui est garant de l'authenticité des données de la base de données. 25 Avantageusement, l'étape de modification du statut d'un document est mise en oeuvre après une perte ou un vol du document. Selon une particularité, l'utilisateur protégé et/ou les données d'utilisateur protégé et/ou au moins un document associé à l'utilisateur protégé sont enregistrées dans la base de données après une perte ou un 30 vol du document. De préférence, cet enregistrement après la perte ou le vol du document est mise en oeuvre par un utilisateur partenaire. Ainsi, il est possible de protéger un utilisateur qui n'a pas encore été enregistré dans la base de données au moment de la perte ou du vol. 3028977 - 5 - Il est également possible de protéger un utilisateur déjà enregistré dans la base de données au moment de la perte ou du vol mais qui n'y avait pas enregistré le document préalablement à sa perte ou son vol. Il est également possible de protéger un utilisateur non encore enregistré 5 dans la base de données au moment de la perte ou du vol mais qui avait enregistré le document préalablement à sa perte ou son vol dans un autre système d'information, tel que celui que peut mettre en oeuvre un utilisateur partenaire. 10 Selon un deuxième aspect de l'invention, il est proposé un système comprenant : - un premier serveur d'application connecté à une première base de données et à une deuxième base de données, le premier serveur d'application étant configuré pour interroger et modifier les première 15 et deuxième bases de données, la deuxième base de données étant configurée pour comprendre au moins un document associé à l'identité d'un premier utilisateur, dit utilisateur protégé, le document étant en outre associé à un statut relatif audit document, l'utilisateur protégé étant associé à des données d'utilisateur protégé, 20 - un deuxième serveur d'application connecté à la deuxième base de donnée , le deuxième serveur d'application étant configuré pour interroger la deuxième base de données. Selon l'invention, le système est configuré pour mettre en oeuvre un procédé selon l'invention. 25 La deuxième base de données du système selon l'invention est la base de données mise en oeuvre dans le procédé selon l'invention. De préférence, le deuxième serveur ne peut pas se connecter à la première base de données. Selon une particularité de l'invention, le deuxième serveur d'application 30 est configuré pour modifier la deuxième base de données à partir d'une réception d'une requête provenant de l'extérieur du système selon l'invention. Description des figures D'autres particularités et avantages de l'invention apparaîtront à la 35 lecture de la description détaillée de mises en oeuvre et de modes de 3028977 -6 réalisation nullement limitatifs, au regard de figures annexées sur lesquelles : - la FIGURE 1 est une vue schématique de l'architecture technique d'un système 1 selon l'invention ; 5 - la FIGURE 2 est une vue schématique de plusieurs procédures que le système 1 peut mettre en oeuvre. Description de l'invention Ces modes de réalisation n'étant nullement limitatifs, on pourra notamment réaliser des variantes de l'invention ne comprenant qu'une 10 sélection de caractéristiques décrites par la suite, telles que décrites ou généralisées, isolées des autres caractéristiques décrites, si cette sélection de caractéristiques est suffisante pour conférer un avantage technique ou pour différencier l'invention par rapport à l'état de la technique. L'invention met en oeuvre une détermination par un utilisateur partenaire 15 de données d'utilisateurs associées à un utilisateur protégé à partir d'une présentation d'un document par un utilisateur postulant, cette détermination comprenant une interrogation d'une base de données pour déterminer si le document y est enregistré et si son statut est valide, le cas échéant pour accéder aux données d'utilisateur protégé associées à 20 l'utilisateur protégé. Cette interrogation est suivie d'une étape de comparaison de données renseignées par l'utilisateur postulant et des données d'utilisateur protégé pour vérifier que l'identité de l'utilisateur protégé est la même que l'identité de l'utilisateur postulant. 25 Il est maintenant décrit en référence à la FIGURE 1 l'architecture technique du système 1 qui comprend quatre serveurs Si, S2, S3 et S4. Le serveur S1 est un premier serveur d'application dédié à une première catégorie d'utilisateurs et est relié d'une part à un firewall FW1 et d'autre part aux serveurs S3 et S4. Un utilisateur de la première catégorie 30 d'utilisateurs est désigné sous le terme d'utilisateur partenaire dans la suite de cette description. La connexion entre le firewall FW1 et le serveur S1 est chiffrée au moyen d'un chiffrement Cl de type SSL/TLS. 3028977 - 7 - Le serveur S2 est un deuxième serveur d'application dédié à une deuxième catégorie d'utilisateurs et est d'une part relié à un firewall FW2, distinct du firewall FW1, et d'autre part au serveur S4. Le serveur S2 comprend un serveur de gestion de SMS. Il comprend 5 également un serveur HTTP tel qu'un serveur Apache. Un utilisateur de la deuxième catégorie d'utilisateurs est désigné sous le terme d'utilisateur protégé ou à protéger dans la suite de cette description. La connexion entre le firewall FW2 et le serveur S2 est chiffrée au moyen d'un chiffrement C2 de type SSL/TLS. 10 Bien entendu, dans une variante particulière, les fonctions des deux firewalls FW1 et FW2 pourraient être réalisée par un même firewall. Le serveur S3 est un serveur qui enregistre des informations relatives aux utilisateurs partenaires ainsi qu'une première base de données des utilisateurs partenaires. Le serveur S3 peut être interrogé par le serveur 15 d'application Si. Le serveur S3 ne peut pas être interrogé par le serveur d'application S2. Le serveur S4 est un serveur de base de données qui enregistre des informations relatives aux utilisateurs protégés ainsi qu'une deuxième base de données des utilisateurs protégés. Le serveur S4 peut être interrogé par 20 les serveurs d'applications S1 et S2. Bien entendu, dans une variante particulière, les fonctions des deux serveurs S3 et S4 pourraient être réalisées par un même serveur. Le firewall FW1 est relié à trois terminaux PC1, PC2, PC3 d'utilisateurs partenaires. Chaque terminal PC1, PC2, PC3 est connecté au serveur S1 par 25 une connexion sécurisée de type VPN, respectivement notée VPN1, VPN2, VPN3. Le firewall FW1 est reliés à trois terminaux T1, T2, T3 d'utilisateurs protégés. Chaque terminal T1, T2, T3 est connecté au serveur S2 via une liaison de type Internet, respectivement notée fi, 12, 13. Les terminaux T1, 30 T2 et T3 sont respectivement un ordinateur portable, un smartphone et un ordinateur usuel. Après avoir suivi une procédure d'inscription Pl, un utilisateur protégé peut : - s'authentifier auprès du système ; 35 - gérer des documents personnels ; 3028977 - 8 - - alerter en cas de vol ou de perte d'un document ; - mettre à jour ses informations. Après avoir suivi une procédure d'inscription, un utilisateur partenaire peut : 5 - s'authentifier auprès du système ; - inscrire un utilisateur à protéger auprès du système ; - vérifier une information ou un document présenté par un utilisateur postulant ; - alerter en cas de tentative d'usurpation ; 10 - gérer des utilisateurs partenaires, dits internes, habilités à utiliser le système ; - mettre à jour les informations de son compte. Il est maintenant décrit en référence aux FIGURES 1 et 2 plusieurs procédures mises en oeuvre par le système 1. 15 Il est maintenant décrit une procédure d'inscription P1 d'un utilisateur à protéger auprès du système 1, depuis un terminal T1, T2 ou T3. Le serveur S2 génère un formulaire d'inscription à destination du terminal T1, T2 ou T3. Ce formulaire est envoyé à au moins un de ces terminal via 20 au moins une des liaisons I1, 12, 13. Le formulaire comprend : - un libellé relatif à des erreurs, invisible à cette étape de l'inscription, qui est par la suite visible pour informer l'utilisateur d'erreurs apparaissant dans le formulaire d'inscription, - un libellé relatif à un identifiant et une zone de saisie correspondante, 25 - deux libellés relatifs à des mots de passe et deux zones de saisie pour saisir un mot de passe et une confirmation du mot de passe, - un libellé relatif à une question secrète et une zone de saisie correspondante, - une image sécurisée affichant aléatoirement des caractères et une 30 zone de saisie correspondante, - un libellé relatif à une adresse électronique et une zone de saisie correspondante, - une case à cocher avec un lien vers des conditions d'utilisation du service, 3028977 - 9 - - un bouton relatif à une annulation pour annuler tous les traitements liés au formulaire et recommencer éventuellement la saisie, - un bouton relatif à une validation pour valider le traitement de l'information. Son état par défaut est inactif. 5 Un utilisateur à protéger devra prendre connaissance des conditions légales d'utilisation et cocher la case relative pour accepter ces conditions Le programme vérifie que toutes les zones de saisie sont convenablement renseignées. Lorsque le formulaire soumis par le terminal T1, T2 ou T3, présente des 10 erreurs de saisie, le système 1 indique à l'utilisateur à protéger une manière de corriger ses erreurs dans le formulaire par le biais de libellés informatifs. Dans le cas contraire, le bouton validation devient actif. Après que l'utilisateur à protéger à actionné le bouton de validation, le serveur S2 effectue alors traitements suivants : 15 - toutes les informations collectées par le formulaire d'inscription sont enregistrées dans une mémoire temporaire du serveur S2 pour effectuer des traitements; - un script de connexion sécurisé est utilisé pour se connecter à la base de données du serveur S4. 20 En cas d'échec du script de connexion, l'utilisateur à protéger est informé de l'impossibilité de poursuivre. Cette information est réalisée par la génération et l'envoi par le serveur S2 d'une page web à destination du terminal T1, T2 ou T3. En cas de succès du script de connexion, le serveur S2 interroge le 25 serveur S4 via une requête de consultation d'une table des identifiants pour vérifier que l'utilisateur à protéger n'existe pas dans le serveur S4. Si l'utilisateur à protéger existe déjà dans le serveur S4, l'utilisateur à protéger est informé de l'impossibilité de poursuivre. Cette information est réalisée par la génération et l'envoi d'un message depuis le serveur S4 vers 30 le serveur S2. A réception de ce message le serveur S2 génère et envoi une page web à destination du terminal T1, T2 ou T3. Si l'utilisateur à protéger n'existe par dans le serveur S4, un fichier comprenant les données de l'utilisateur à protéger est créé par le serveur S2 et est envoyé et enregistré par le serveur S4. Les données relatives à 35 l'utilisateur sont insérées dans le serveur S4 et liées à un identifiant unique 3028977 - 10 - relatif à l'utilisateur à protéger. Le mot de passe de l'utilisateur est chiffré dans le serveur S4. D'autres données peuvent également être chiffrées. Les données relatives à l'utilisateur, son identifiant et son mot de passe sont enregistrés dans la base de données du serveur S4. 5 Le système 1 collecte en outre des informations personnelles et des informations de paiement du client telle que sa civilité, son nom, son prénom, sa date de naissance, et lieu de naissance. Une photo ainsi qu'une adresse (numéro voie, voie, code postal, ville, pays) et un téléphone sont également enregistrés par le serveur S4. 10 Après vérification des informations saisies, le serveur S2 génère un récapitulatif des données saisies et demande une confirmation à l'utilisateur à protéger ou une modification des données saisies. Si l'utilisateur à protéger souhaite modifier les informations saisies, il est redirigé vers une page d'enregistrement des informations personnelles. 15 Il est maintenant décrit une procédure d'authentification d'un utilisateur protégé par le système 1 depuis un terminal T1, T2 ou T3. Un formulaire d'authentification contient : - un libellé relatif à un identifiant et une zone de saisie 20 correspondante ; - un libellé relatif à un mot de passe et une zone de saisie correspondante ; - une image sécurisée qui affiche aléatoirement des caractères et une zone de saisie correspondante ; 25 - un bouton relatif à une validation pour valider le traitement de l'information dont l'état par défaut est inactif. Lorsque le formulaire par le terminal T1, T2 ou T3 présente des erreurs de saisie, le système 1 indique à l'utilisateur protégé une manière de corriger ses erreurs dans le formulaire par le biais des libellés informatifs. 30 Dans le cas contraire, le bouton validation devient actif. Après que l'utilisateur protégé a actionné le bouton de validation, le serveur S2 effectue alors traitements suivants : - toutes les informations collectées par le formulaire d'inscription sont enregistrées dans une mémoire temporaire du serveur S2 pour 35 effectuer des traitements; 3028977 - un script de connexion sécurisé est utilisé pour se connecter à la base de données du serveur S4. En cas d'échec du script de connexion, l'utilisateur protégé est informé de l'impossibilité de poursuivre. Cette information est réalisée par la génération 5 et l'envoi par le serveur S2 d'une page web à destination de du terminal T1, T2 ou T3. En cas de succès du script de connexion, le serveur S2 interroge le serveur S4 via une requête de consultation d'une table des identifiants pour vérifier que l'utilisateur protégé existe dans le système et que le mot de 10 passe renseigné est correct. En cas d'échec d'authentification du fait de la saisie d'un de mot de passe erroné, l'utilisateur à protéger mettant en oeuvre le formulaire d'authentification est informé de l'échec. Il lui est possible alors de recommencer le processus d'authentification ou bien de réinitialiser son mot 15 de passe. Dans le cas où, trois fois de suite, l'utilisateur protégé ne saisit pas un mot de passe valide, il est contraint par le système de saisir son email et suivre une procédure de réinitialisation du mot de passe. Il peut volontairement réinitialiser son mot de passe sans user des trois tentatives d'identification. 20 Il est maintenant décrit une procédure d'ajout de documents personnels P2 par un utilisateur protégé depuis un terminal T1, T2 ou T3. Lorsqu'un utilisateur protégé souhaite référencer un document auprès du serveur S4, il peut choisir de le faire au moyen d'un formulaire classique de 25 collecte d'informations relatives au document ou au moyen d'une technologie de collecte d'informations propre à l'invention facilitant la saisie des informations relatives au document par un outil de reconnaissance optique des caractères. Le formulaire classique ou le moyen propre à l'invention sont générés par le serveur S2 et transmis au terminal T1, T2 ou 30 T3 de l'utilisateur protégé via un lien I1, 12 ou 13. Selon le moyen propre à l'invention, l'utilisateur protégé sélectionne le pays de provenance du document et le type de document, puis il valide sa sélection en cliquant sur un bouton de validation. Il peut alors choisir de prendre une photo dudit document ou choisir une photo existante du 3028977 - 12 - document sur son ordinateur, son portable ou sa tablette. Il valide ensuite sa sélection en cliquant sur un bouton de validation. De manière optionnelle, l'utilisateur protégé prend une photo de face de lui même, le système comparant alors les photos de face, celle du 5 document et celle de l'utilisateur protégé déjà enregistrée dans le serveur S4. Le système génère un récapitulatif des informations et en demande une validation à l'utilisateur à protéger. Une fois le processus achevé, le système enregistre les informations 10 suivantes dans le serveur S4 : le type de document, le pays émetteur, le numéro de référence du document, la date d'émission, la date de fin de validité, l'émetteur du document et le titulaire du document. Le titulaire du document est comparé au nom de l'utilisateur protégé enregistré dans la base de données du système S4. 15 Le système vérifie ensuite l'authenticité du document à partir d'informations qu'il contient relatives à des documents émis par plus de 90 pays. Si le document que l'utilisateur protégé souhaite référencer dans le système ne présente aucune anomalie, une confirmation de référencement 20 du document est générée. La base de données du serveur S4 est modifiée pour y ajouter le document référencé en y associant le code interne de l'utilisateur protégé. Le document est référencé avec un statut valide. En cas d'anomalies liées au document que l'utilisateur souhaite référencer dans le système, le système génère un rapport d'erreurs 25 mentionnant la cause de l'erreur. Le document présenté est recensé dans une table dédiée de la base de donnée. Cette table est dédiée à l'enregistrement de documents problématiques. Lorsqu'un utilisateur protégé souhaite référencer un moyen de paiement tel qu'un RIB ou un IBAN au sein du système 1, il peut choisir de le faire au 30 moyen d'un formulaire comprenant : - un libellé relatif au moyen de paiement et une zone de saisie de moyen de paiement ; - un bouton relatif à l'action d'ajouter le moyen de paiement. Un logiciel tiers est utilisé pour la vérification du moyen de paiement, par 35 exemple un IBAN. Une fois l'IBAN vérifié avec succès, le système 1 se 3028977 - 13 - connecte a la base de données au moyen du script de connexion afin d'ajouter le nouvel IBAN dans la table des IBAN en lui associant le code interne de l'utilisateur protégé. 5 Il est maintenant décrit une procédure P3 mise en oeuvre par un utilisateur protégé pour alerter le système selon l'invention, c'est à dire pour déclarer perdu ou volé un document préalablement référencé. Les utilisateurs protégés ayant référencé au moins un document, peuvent effectuer une déclaration de perte ou de vol concernant le ou les dits 10 documents. Après authentification de l'utilisateur protégé selon la procédure précédemment décrite, le serveur S2 génère une page comprenant un listage du ou des documents préalablement référencé(s) par l'utilisateur protégé. Cet affichage permet de sélectionner rapidement un document 15 préalablement référencé dont l'utilisateur protégé souhaite déclarer la perte ou le vol. L'utilisateur protégé doit indiquer s'il s'agit d'une perte ou d'un vol du document sélectionné, indiquer une date de la perte ou du vol, l'heure, le lieu (ville et pays), et saisir optionnellement un commentaire. 20 La page comprend en outre un bouton intitulé « joindre » qui permet de joindre une déclaration officielle de perte ou vol de documents. Le client a alors la possibilité d'annuler, de modifier ou de confirmer la procédure de déclaration de perte ou de vol du document sélectionné. En cas d'annulation, le système n'enregistre aucune information 25 concernant la déclaration. En cas de modification, la page comprenant un listage du ou des documents préalablement référencé(s) telle que décrite ci-dessus générée par le serveur S2 peut être modifiée. En cas de validation de la procédure par l'utilisateur protégé, le 30 système 1 met à jour le statut du ou des documents concernés en fonction du choix de l'utilisateur protégé. Un document protégé peut donc être associé à trois statut : valide, perdu ou volé. Le système crée un enregistrement pour chaque déclaration de perte ou de vol dans une table de la base de données en rajoutant la date et l'heure 35 de la déclaration. 3028977 - 14 - L'utilisateur protégé est informé par le système du succès de la procédure. Il reçoit un email de confirmation dans sa boite électronique. Il est maintenant décrit une procédure P3' mise en oeuvre par un 5 utilisateur protégé pour alerter le système selon l'invention dans le cas d'un document non préalablement référencé, c'est à dire pour déclarer perdu ou volé un document non préalablement référencé. Les utilisateurs protégés n'ayant enregistré aucun document doivent produire une déclaration de perte provenant des autorités habilitées à 10 produire cette déclaration. Dans ce cas, au moins deux implémentations sont possibles : . une première implémentation consiste à mettre en oeuvre une procédure d'ajout du document personnel puis une procédure d'alerte de perte ou de vol dudit document ; 15 . une seconde implémentation consiste à mettre en oeuvre une procédure d'ajout du document personnel et à déclarer au cours de cet ajout que le statut du document est respectivement perdu/volé. Il est maintenant décrit une procédure P4 mise en oeuvre par un 20 utilisateur protégé pour mettre à jour ses informations. Après authentification de l'utilisateur protégé selon la procédure précédemment décrite, le serveur S2 génère une page comprenant un listage du ou des documents préalablement référencé(s) par l'utilisateur protégé ainsi que des données d'utilisateur protégé. 25 Cet affichage permet à l'utilisateur protégé de modifier les données d'utilisateur protégé qui sont enregistrées dans le serveur S4. Il est maintenant décrit une procédure d'inscription P5 d'un utilisateur partenaire dans le système 1. 30 L'inscription d'un utilisateur partenaire dans le système 1 est réalisée à partir d'un formulaire généré par le système 1 et mis en oeuvre par un administrateur du système 1. 3028977 - 15 - Il est maintenant décrit une procédure d'authentification d'un utilisateur partenaire par le système 1 depuis un terminal PC1, PC2 ou PC3. Un formulaire d'authentification d'un utilisateur partenaire comprend : - un libellé relatif à un identifiant et une zone de saisie 5 correspondante ; - un libellé relatif à un mot de passe et une zone de saisie correspondante ; - une image sécurisée qui affiche aléatoirement des caractères et une zone de saisie correspondante ; 10 - un bouton relatif à une validation pour valider le traitement de l'information dont l'état par défaut est inactif. Lorsque le formulaire présente des erreurs de saisie, le système 1 indique à l'utilisateur protégé une manière de corriger ses erreurs dans le formulaire par le biais des libellés informatifs. 15 Dans le cas contraire, le bouton validation devient actif. Après que l'utilisateur partenaire a actionné le bouton de validation, le serveur S1 effectue alors traitements suivants : - toutes les informations collectées par le formulaire d'inscription sont enregistrées dans une mémoire temporaire du serveur S1 pour 20 effectuer des traitements; - un script de connexion sécurisé est utilisé pour se connecter à la base de données du serveur S3. En cas d'échec du script de connexion l'utilisateur partenaire est informé de l'impossibilité de poursuivre. Cette information est réalisée par la 25 génération et l'envoi par le serveur S1 d'une page web à destination de l'utilisateur partenaire. En cas de succès du script de connexion, le système interroge le serveur S3 via une requête de consultation de la table des identifiants pour vérifier que l'utilisateur partenaire existe dans le système et que le mot de passe 30 renseigné est correct. En cas d'échec d'authentification du fait de la saisie d'un de mot de passe erroné, l'utilisateur partenaire mettant en oeuvre le formulaire d'authentification est informé de l'échec. Il lui est possible alors de recommencer le processus d'authentification ou bien de réinitialiser son mot 35 de passe. Dans le cas ou l'utilisateur partenaire ne saisit pas de mot de 3028977 - 16 - passe valide trois fois de suite, il est contraint par le système à saisir son email et à suivre une procédure de réinitialisation du mot de passe. Il peut volontairement réinitialiser son mot de passe sans user des trois tentatives d'identification. 5 Il est maintenant décrit une procédure mise en oeuvre par un utilisateur partenaire pour inscrire un utilisateur à protéger auprès du système. Après authentification de l'utilisateur partenaire selon la procédure précédemment décrite, le serveur S1 génère un formulaire d'inscription 10 permettant d'inscrire un utilisateur à protéger auprès du système. Ce formulaire est semblable à celui déjà décrit, mise en oeuvre par l'utilisateur à protéger pour s'inscrire auprès du système. Il est maintenant décrit une procédure P6 mise en oeuvre par un 15 utilisateur partenaire pour vérifier une information ou un document présenté par un utilisateur postulant, lors d'une transaction locale ou distante. Lorsqu'un utilisateur postulant présente une information ou un document, l'utilisateur partenaire peut remplir un formulaire dans lequel il indique le 20 numéro du document ou encore utiliser une technologie de reconnaissance optique de caractère. Une fois le numéro du document connu du système, le serveur S2 interroge le serveur S4 pour rechercher le numéro du document. Si ledit document existe dans le serveur S4, l'utilisateur partenaire reçoit 25 une photo de l'utilisateur protégé associé au document. Cette photo a été enregistrée dans la base de donnée S4 au moment de l'inscription de l'utilisateur protégé. L'utilisateur partenaire reçoit également le statut associé audit document dans le serveur S4. 30 Si le statut du document associé n'est pas valide, par exemple si le statut du document associé est volé ou perdu, le système génère immédiatement un rapport de danger concernant le document avec l'alerte concernant ledit document volé ou perdu. Si le serveur S4 ne reconnaît pas le document présenté, la transaction 35 est interrompue. 3028977 - 17 - Si la transaction est distante, le système génère automatiquement un code unique, envoyé à l'utilisateur protégé via SMS. Cet envoi constitue une procédure de demande d'autorisation P7 par l'utilisateur partenaire. L'utilisateur postulant doit saisir le code dans un formulaire spécifique 5 généré par le système. La saisie de ce code par l'utilisateur postulant constitue une procédure de confirmation P8 de l'utilisateur protégé. En cas d'échec, l'utilisateur postulant est invité deux fois à saisir le code. Après trois échecs, la transaction est interrompue. Si le statut du document associé est valide mais que les informations 10 renseignées par l'utilisateur postulant au cours de la transaction ne correspondent pas avec des données d'utilisateur protégé associées audit utilisateur protégé, le programme signale les erreurs concernant l'identité d'un client existant. La transaction est alors interrompue. 15 Après authentification de l'utilisateur partenaire selon la procédure précédemment décrite, l'utilisateur partenaire peut alerter de la perte ou du vol d'un document d'un utilisateur protégé selon la procédure P8. Si le document était référencé par l'utilisateur protégé préalablement à sa perte ou son vol, le formulaire décrit dans la procédure P3 est mis en 20 oeuvre pour modifier le statut du document. Si le document n'était pas référencé par l'utilisateur protégé préalablement à sa perte ou son vol, la procédure P3' est mise en oeuvre pour référence le document en base de données et modifier le statut du document. 25 Bien entendu le système selon l'invention comprend en outre : - des procédures permettant à un utilisateur partenaire de gérer des utilisateurs partenaires, dits internes, habilités à utiliser le système ; - des procédures permettant à un utilisateur de mettre à jour les 30 informations de son compte enregistrées dans le système. Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention. De plus, les différentes 35 caractéristiques, formes, variantes et modes de réalisation de l'invention REVENDICATIONS1. Procédé mettant en oeuvre une première base de données sur un serveur (S4) interrogeable par un premier serveur d'application (S1), la base de données comprenant au moins un document associé à l'identité d'un premier utilisateur, dit utilisateur protégé, ledit document étant en outre associé à un statut relatif audit document, ledit statut étant enregistré dans ladite base de données, ledit utilisateur protégé étant associé à des données d'utilisateur protégé, lesdites données d'utilisateur protégé étant enregistrées dans ladite base de données, le procédé comprenant en outre : - une détermination par un utilisateur partenaire ou une serveur d'application de l'identité de l'utilisateur protégé et de données d'utilisateurs associées à cet utilisateur à partir d'une présentation d'un document par un deuxième utilisateur, dit utilisateur postulant, cette détermination comprenant : o une interrogation de la base de données depuis l'ordinateur (PC1, PC2, PC3) à partir dudit document pour déterminer si le document est enregistré dans ladite base de données ; o si le document est enregistré dans la base de données, une interrogation de la base de données pour déterminer le statut dudit document ; sinon la détermination de l'identité est arrêtée sur échec ; o si le statut du document n'est pas valide, la détermination de l'identité est arrêtée sur échec ; o si le statut du document est valide, une interrogation de la base de données pour déterminer l'identité de l'utilisateur protégé associé au document et des données d'utilisateur protégé associées audit utilisateur protégé ; - une étape de comparaison de données renseignées par l'utilisateur postulant et de données générées à partir des données d'utilisateur protégé pour déterminer que l'identité de l'utilisateur protégé est la même que l'identité de l'utilisateur postulant. 3028977 - 20 - 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre une étape de réception par l'utilisateur partenaire des données renseignées par l'utilisateur postulant, l'étape de comparaison comprenant une comparaison d'une partie des données renseignées 5 par l'utilisateur postulant et d'une partie des données générées. 3. Procédé selon la revendication 1, caractérisé en ce que qu'il comprend en outre une étape d'émission de données, dites données de contrôle, de préférence un code de vérification aléatoire, à 10 destination de l'utilisateur protégé et en ce que l'étape de comparaison comprend une comparaison desdites données de contrôle et des données renseignées par l'utilisateur postulant. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé 15 en ce qu'il comprend une étape de modification du statut d'un document associé à un utilisateur protégé par ledit utilisateur protégé à partir d'un terminal (T1, T2, T3) connecté de manière sécurisé à un serveur d'application (S2) connecté à la base de données. 20 5. Procédé selon la revendication 4, caractérisé en ce qu'il comprend une étape d'authentification d'un utilisateur protégé muni d'un terminal (T1, T2, T3) auprès du serveur d'application (S2) et en ce que cette étape est suffisante pour autoriser ledit utilisateur protégé à modifier directement le statut d'un document associé audit 25 utilisateur protégé. 6. Procédé selon la revendication 4 ou 5, caractérisé en ce que l'authentification est mise en oeuvre à partir d'une carte à puce ou d'un paramètre biométrique. 30 7. Procédé selon l'une quelconque des revendications 4 à 6, caractérisé en ce que l'étape de modification du statut d'un document est mise en oeuvre après une perte ou un vol dudit document. 3028977 - 21 - 8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que l'utilisateur protégé et/ou les données d'utilisateur pr6tégé et/ou au moins un document associé à l'utilisateur protégé sont enregistrées dans la base de données après une perte ou un vol dudit 5 document. 9. Procédé selon la revendication 8, caractérisé en ce qu'en cas d'échec de l'authentification du document présenté, le document présenté est recensé dans une table dédiée de la base de données. 10 10.Système comprenant : - un premier serveur d'application (S1) connecté à une première base de donnée (S3) et à une deuxième base de données (S4), ledit premier serveur d'application (S1) étant configuré pour 15 interroger et modifier les première et deuxième bases de données, la deuxième base de données étant configurée pour comprendre au moins un document associé à l'identité d'un premier utilisateur, dit utilisateur protégé, ledit document étant en outre associé à un statut relatif audit document, ledit utilisateur protégé étant 20 associé à des données d'utilisateur protégé, - un deuxième serveur d'application (S2) connecté à la deuxième base de données (S4), ledit deuxième serveur d'application étant configuré pour interroger la deuxième base de données, ledit système étant configuré pour mettre en oeuvre un procédé selon 25 l'une quelconque des revendications précédentes. 11.Système selon la revendication 10, caractérisé en ce que le deuxième serveur d'application est configuré pour modifier la deuxième base de données à partir d'une réception d'une requête provenant de 30 l'extérieur du système.