Brevet FR3120969A1 — publié le 20220923

Procédé de génération d’un marqueur de la capacité d’achat d’un bien par une personne au moyen d’un système de gestion d’informations comportant d’une part au moins un serveur applicatif (2) de gestion de données d’utilisateurs munis de moyens de stockage de données comportant au moins une base de données (5), d’une unité de traitement et de moyens de communication de données en entrée et en sortie du serveur au moyen d’un réseau global de type internet, et d’autre part des terminaux distants (1, 3, 4) munis d’une application logicielle, et détenus par trois types d’utilisateurs, à savoir l’acheteur potentiel du bien, le vendeur du bien et un courtier. Figure pour l’abrégé : Fig1 Procédé de génération d’un marqueur de capacité d’achat d’un bien La présente invention concerne le problème de l’achat de biens, et plus particulièrement mais non exclusivement de l’achat de biens immobiliers. Elle a trait à un procédé de génération d’un marqueur authentificateur de la capacité d’achat d’un bien par une personne, basé sur un système de gestion d’informations reposant sur tous les moyens techniques actuels d’accès et de centralisation d’informations. L’invention permettra aux différentes parties impliquées dans le négoce de tels biens de gagner un temps important pour faire avancer les dossiers sur lesquels un intérêt est manifesté par un client pour un bien vendu par un vendeur, par exemple un agent immobilier. Dans ce domaine, certaines opérations administratives notamment auprès des banques peuvent impliquer des délais de traitement longs, qui sont à leur tour susceptibles de ralentir de manière considérable la réalisation des ventes. Il s’agit par exemple des démarches qui doivent être réalisées en amont dans le but de garantir que le client final est bien en mesure, sur un plan financier, d’acheter le bien convoité. En l’absence d’informations correspondantes, le temps par exemple passé par l’agent et par le client pour la constitution de dossiers, ou éventuellement en visites de biens en vente, peut finalement s’avérer avoir été dépensé en pure perte, s’il se trouve que le client ne peut pas s’offrir le bien qu’il désirait. L’idée à la base de l’invention est de rendre accessibles aux deux parties précitées des informations fiables liées à la capacité financière de l’acheteur, tout en préservant un certain degré de confidentialité, le niveau d’informations fournis devant simplement permettre d’avancer ou non dès le début de la relation. En somme, l’invention rend possible le déblocage, très tôt dans ladite relation, d’un processus de vente potentielle, quel que soit son devenir final. Cela implique l’inclusion dans la boucle d’un courtier qui a la capacité et la légitimité de notamment gérer des informations auxquelles un agent immobilier n’a pas accès. Les données financières qui restent confidentielles pour les agents/vendeurs ne le sont en effet pas pour des courtiers habilités ORIAS (Organisme pour le Registre unique des Intermédiaires en Assurance, Banque et Finance), qui ont de plus la compétence et les données nécessaires à effectuer des simulations fiables. En amont du processus de recherche d’un bien immobilier, le courtier peut en effet calculer la capacité d’emprunt de l’acheteur, qui peut ensuite servir à attester de manière plus officielle de sa possibilité d’achat d’un bien. C’est la consultation de cette information par l’agent immobilier qui conditionne l’ouverture d’un dossier sur un bien immobilier intéressant le client, parce qu’elle garantit en quelque sorte l’adéquation entre ledit bien et les capacités financières de l’acheteur. On évite ainsi de bloquer par exemple un appartement ou une maison jusqu’à ce que l’information financière soit disponible, ce qui peut prendre un certain temps pendant lequel les démarches et relations entre l’agent/vendeur et l’acheteur sont clairement obérées. Il s’agit donc d’un filtrage en amont, qui est dans l’intérêt de tous puisqu’il limite en pratique toute possibilité de tractations prématurées, qui ne peuvent de toute évidence jamais déboucher sur un processus concret de vente. Comme évoqué auparavant, il permet finalement à chacun des protagonistes d’une telle transaction de gagner un temps considérable. Il entame enfin de la meilleure manière la relation entre l’agent et l’acheteur potentiel, tout motif de méfiance lié à une incertitude financière étant d’emblée écarté. Le procédé de l’invention permet de fait de fluidifier dès le début les opérations liées à l’achat d’un bien en générant de manière concrète une information clé pour l’agent immobilier ou pour le vendeur, de manière garantie et en préservant la confidentialité lorsqu’elle est requise ou nécessaire. Techniquement, l’invention met en œuvre un système d’informations et de traitement automatisé qui permet la mise à disposition d’une information sur la véracité de la capacité d’acquisition de l’acheteur potentiel, obtenue via un opérateur crédible, à destination de l’agent et selon un protocole qui assure l’authenticité de ces données sans en divulguer la teneur précise. Plus précisément, l’invention concerne un procédé de génération d’un marqueur de capacité d’achat d’un bien par une personne au moyen d’un système de gestion d’informations comportant d’une part au moins un serveur applicatif de gestion de données d’utilisateurs munis de moyens de stockage de données comportant au moins une base de données, d’une unité de traitement et de moyens de communication de données en entrée et en sortie du serveur au moyen d’un réseau global de type internet, et d’autre part des terminaux distants munis d’une application logicielle, et détenus par trois types d’utilisateurs, à savoir un acheteur potentiel du bien, un vendeur du bien et un courtier, qui est tel qu’il comporte les étapes suivantes : Connexion du terminal de l’utilisateur courtier à un serveur applicatif du système via ladite application logicielle ; Transmission de données d’entrée d’identification d’un utilisateur acheteur et d’informations financières comprenant sa capacité d’emprunt ; Génération par l’unité de traitement du serveur d’un code graphique en deux dimensions, du type QR-code, codant un identifiant unique lié audit utilisateur acheteur ; Connexion du terminal de l’utilisateur acheteur audit serveur via son application logicielle dédiée et obtention dudit code graphique ; Affichage ou impression dudit code graphique ; Lecture et chargement du code graphique via des moyens de lecture de l’application logicielle du vendeur ; Connexion du terminal du vendeur au serveur via son application logicielle dédiée, envoi du code graphique et de données notamment financières concernant un bien ; Décodage du code graphique par l’unité de traitement du serveur, Comparaison par l’unité de traitement entre les informations de capacité financière disponibles issues du décodage et le prix d’un bien inclus dans les données concernant le bien ; Envoi par le serveur à l’application logicielle du vendeur du résultat de la comparaison. L’invention réalise des échanges triangulaires avec le système de gestion informatisé, au cours desquels des informations sont communiquées pour permettre l’élaboration d’un outil indicateur de la capacité de l’acheteur sous une forme qui n’altère pas la nature confidentielle des informations. Sur un plan matériel, le ou les serveurs applicatifs et la base de données d’informations qu’il gère(nt) sont la clé de voûte du procédé, qui peut ensuite être mis en œuvre par ses utilisateurs via différents moyens d’accès à distance (voir ci-après) et au travers d’interfaces dont les modalités d’utilisation changent selon la fonction de l’utilisateur dans la transaction à démarrer. Le procédé de l’invention vise à centraliser et organiser des informations, puis à les échanger de manière intelligible et classées suivant plusieurs critères potentiels pour délivrer le « passeport » ou le marqueur garant de l’authenticité d’informations qui permettent le bon déclenchement de la transaction à réaliser. En fait, selon l’invention, la comparaison effectuée par l’unité de traitement du serveur applicatif entre d’une part les informations de capacité financière disponibles - issues du décodage du code graphique - et d’autre part le prix d’un bien inclus dans les données transmises concernant ce bien se fait sur la base de chiffres concrets, mais le résultat de la comparaison tel que renvoyé consiste de préférence, pour le vendeur ou son agent, en une information binaire positive ou négative. L’information qui est contenue dans le code graphique est un code unique de type GUID (identificateur global unique) identifiant le client potentiel uniquement lisible par l’application chargée par le vendeur puis transmise au serveur applicatif via son application logicielle. Après traitement par le serveur l’information revient sous une forme très simplifiée, ne conservant de préférence que la réponse à la question : est-il possible d’avancer dans ce dossier/ce process ou non. Les terminaux distants sont de préférence des terminaux mobiles de type smartphones ou tablette. Dans ce cas, le code graphique en deux dimensions peut par exemple être affiché sur des moyens d‘affichage du terminal de l’utilisateur acheteur, après la génération qui en est faite par l’unité de traitement du serveur alimentée par les informations du courtier. Cette solution n’est pas la seule qu’on peut mettre en œuvre, une version imprimée du code peut aussi être utilisée. C’est le cas par exemple dans l’hypothèse où l’acheteur n’est équipé, comme terminal distant, que d’un ordinateur fixe. Dans ce cas, une impression du code graphique est fonctionnellement strictement équivalente, l’acheteur n’ayant plus qu’à se rendre chez un agent /vendeur avec le code graphique imprimé. La suite du processus suit cependant exactement la même logique, à savoir une lecture dudit code graphique, visualisé sur un terminal mobile du client ou imprimé, par des moyens de scannage du terminal mobile du vendeur intégré dans l’application, qui flashe en d’autres termes le pictogramme 2D. Le code graphique en deux dimensions est chargé sur ledit terminal du vendeur avant connexion au serveur pour traitement ultérieur, puis renvoi de la ou des données donnant le cas échéant feu vert au vendeur pour poursuivre la relation d’affaire en vue de la vente du bien. L’invention va à présent également être décrite en référence à des figures ci-après qui en précisent certains aspects, sans pour autant être limitatives de l’invention : montre l’architecture globale du système électronique de gestion et d’échanges d’informations au moyen duquel le procédé de l’invention est mis en œuvre ; donne un exemple de l’architecture des applications logicielles équipant les terminaux distants de smartphones ou tablettes. En référence à la , le courtier renseigne via son terminal distant 1 le serveur applicatif 2, dans lequel il dispose d’un espace dédié : il communique la capacité d’emprunt du client qu’il a calculée au préalable, ainsi que des informations relatives audit client. Un corpus de données que l’on désigne par « passeport » est généré, intégrant un codage graphique en deux dimensions sous forme d’un QR Code. Au cours de ces échanges de données, le courtier peut modifier et appliquer des paramètres propres à sa gestion de l’application. Dans cet espace courtier, trois fonctionnalités majeures sont en réalité réalisées : 1. la création du passeport financier d’un client, qui est un marqueur authentificateur de sa capacité d’investissement, 2. la visualisation des historiques des flashes par agent et enfin 3. la visualisation des historiques des flashes par clients (voir ci-après de manière plus détaillée). Pour ce qui concerne la première, comme déjà mentionné, cette fonctionnalité permet d’établir une certification du montant d’emprunt du client. C’est au courtier, avec ses compétences et habilitations, d’établir et de renseigner les informations dont la capacité d’emprunt du client, ce qui déclenche la génération du QR Code constituant le passeport. Il est à noter qu’en dehors de l’utilisation de l’application, la donnée stockée au sein du code est inexploitable. Les relations entre clients et agents, au sens de l’invention, sont ensuite basés sur un scannage du QR Code par l’agent qui réalise un flash de ce code authentificateur et fait traiter les données qu’il contient en communiquant avec le serveur applicatif. Une trace des échanges est gardée dans la base de données, et le courtier peut ensuite visualiser un historique par agent. Cette possibilité est importante pour le courtier car elle lui permet d’analyser le nombre de flashes par agent, et ainsi d’effectuer un suivi des abonnements au service proposé sur la base du procédé de l’invention. L’espace courtier permet aussi la visualisation de l’historique client, dont les communications et échanges avec le serveur applicatif sont également mémorisées. Le suivi des flashes par client, qui concernent cette fois des biens qui l’intéressent, donne une vision significative et globale de l’état du marché. Les informations peuvent être organisées et classées dans la base de données, à des fins de visualisation, par exemple selon l’éligibilité, la date et l’agent ou le client concerné pour chaque flash de QR Code. De fait, le serveur applicatif 2 est connecté à une base de données 5 qu’il renseigne et duquel il extrait des données à la demande. Les informations stockées dans la base de données 5 sont diverses, elles peuvent être relatives à l’identification des personnes, des biens, ou concerner comme mentionné des évènements historiques classés, qui peuvent être comme on l’a vu les scans/flashes opérés sur le QR Code par des agents partenaires ou les biens sélectionnés par ses clients. Un espace propre au client est par ailleurs créé sur le serveur applicatif. A la fin du processus de renseignement réalisé par le courtier à l’aide de l’application, les identifiants du client/acheteur sont automatiquement créés et son compte peut ensuite être initialisé avec son propre mot de passe depuis l’application du client dans la forme utilisée, par exemple l’application mobile qu’il aura téléchargée. Celle-ci est disponible autant pour les systèmes Android que pour les systèmes iOS. A titre essentiel, le client potentiel pourra y retrouver son passeport à tout moment par une connexion via l’application qui équipe son terminal 3, par exemple un smartphone ou une tablette. Le client désirant acquérir un bien aura par conséquent en toutes circonstances la possibilité d’afficher « son » QR Code sur son appareil mobile. Il ne devra en pratique qu’ouvrir l’application en présence de l’agent qui n’aura plus qu’à flasher le QR Code. Le serveur applicatif 2 gère aussi un espace pour les agents immobiliers. Le passeport ou code graphique de l’emprunteur/client généré dans le serveur 2 est donc flashé/scanné par l’application implantée sur les terminaux mobiles de type smartphone et tablette tactiles. Cette application dédiée agent/acheteur communique avec le serveur applicatif 2 qui lui envoie quasi instantanément, à partir du passeport/code graphique, la réponse demandée. Diverses autres informations nécessaires au fonctionnement/paramétrage de l’application peuvent également être obtenues du serveur applicatif 2 en lien avec la base de données 5. Le serveur applicatif 2 comporte également un service web organisant les relations avec les trois types d’utilisateurs, et la base de données 5. C’est le cœur du système. Ladite base de données 5 communique exclusivement avec le serveur 2 lorsqu’une demande émane d’une application en possession d’un des utilisateurs répertoriés ci-dessus. Il s’agit d’une base utilisant un langage de requête structuré de type SQL , qui présente l’avantage d’une grande facilité de maintenance et offre une bonne rapidité d’accès aux données stockées. Il n’y a aucune interaction directe entre la base de données 5 et les applications, les échanges étant effectués via le service web du serveur applicatif 2. Les appels au service et les réponses renvoyées sont normés en JSON qui est décodé et converti en données lisibles pour l’utilisateur. Le JSON est un format de données permettant d’organiser l’information et les données dans un objet structuré qui est optimisé pour l’échange de données. Les applications qui équipent les terminaux des utilisateurs sont organisées selon l’architecture apparaissant en , qui fonctionne comme évoqué selon les deux standards de système d’exploitation iOS et Androïd. Dans ces deux environnements, l’interface web de l’application (« Vue Web ») permet l’envoi et la réception de données via un connecteur qui met en forme les données, dans les deux sens, en fonction de la nature des strates logicielles à connecter. Une interface de programmation « API Matériel » fournit les outils et les services à l’appui de cette connexion, pour les deux systèmes d’exploitation iOS et Androïd. Il est à noter que les exemples de fonctionnalités donnés ci-dessus ne sont pas exhaustifs de l’invention, qui peut également être élargie à des transactions concernant d'autres biens que les biens immobiliers. Procédé de génération d’un marqueur de la capacité d’achat d’un bien par une personne au moyen d’un système de gestion d’informations comportant d’une part au moins un serveur applicatif (2) de gestion de données d’utilisateurs munis de moyens de stockage de données comportant au moins une base de données (5), d’une unité de traitement et de moyens de communication de données en entrée et en sortie du serveur au moyen d’un réseau global de type internet, et d’autre part des terminaux distants (1, 3, 4) munis d’une application logicielle, et détenus par trois types d’utilisateurs, à savoir un acheteur potentiel du bien, un vendeur du bien et un courtier, caractérisé en ce qu’il comporte les étapes suivantes : Connexion du terminal (1) de l’utilisateur courtier à un serveur applicatif (2) du système via ladite application logicielle ; Transmission de données d’entrée d’identification d’un utilisateur acheteur et d’informations financières comprenant sa capacité d’emprunt ; Génération par l’unité de traitement du serveur d’un code graphique en deux dimensions, du type QR-code, codant un identifiant unique lié audit utilisateur acheteur ; Connexion du terminal de l’utilisateur acheteur (3) audit serveur (2) via son application logicielle dédiée et obtention dudit code graphique ; Affichage ou impression dudit code graphique ; Lecture du code graphique via des moyens de lecture de l’application logicielle du vendeur ; Connexion du terminal (4) du vendeur au serveur (2) via son application logicielle dédiée, envoi du code graphique et de données concernant un bien ; Décodage du code graphique par l’unité de traitement du serveur (2), Comparaison par l’unité de traitement entre les informations de capacité financière disponibles issues du décodage et le prix d’un bien inclus dans les données concernant un bien ; Envoi par le serveur (2) à l’application logicielle du vendeur du résultat de la comparaison. Procédé de génération d’un identificateur de capacité d’achat d’un bien selon la revendication précédente, caractérisé en ce que le résultat de la comparaison consiste en une information binaire positive ou négative. Procédé de génération d’un identificateur de capacité d’achat d’un bien selon l’une des revendications précédentes, caractérisé en ce que les terminaux distants (1, 3, 4) sont des terminaux mobiles de type smartphones ou tablettes. Procédé de génération d’un identificateur de capacité d’achat d’un bien selon l’une des revendications précédentes, caractérisé en ce que le code graphique en deux dimensions est affiché sur des moyens d‘affichage du terminal (3) de l’utilisateur acheteur, après génération par l’unité de traitement du serveur (2). Procédé de génération d’un identificateur de capacité d’achat d’un bien selon l’une des revendications précédentes, caractérisé en ce que le code graphique en deux dimensions est lu par des moyens de scannage du terminal (4) du vendeur et chargé sur ledit terminal (4).