FR2936888A1 - Procede d'acces et de gestion, a partir d'un terminal, de donnees bancaires gerees par un serveur, produit programme d'ordinateur, moyen de stockage, terminal, equipement intermediaire et serveur correspondants - Google Patents

Abstract

L'invention concerne un procédé d'accès et de gestion, à partir d'un terminal d'un réseau de communication, de données bancaires gérées par un serveur d'opérations bancaires d'un réseau externe. Selon l'invention, le procédé comprend : - une phase de configuration comprenant une étape d'enregistrement par le terminal de données bancaires associées à un utilisateur ; - une phase d'utilisation (E2) comprenant les étapes suivantes : o réception (E60), par le terminal, de données d'accès courantes fournies par l'utilisateur ; o authentification (E70) de l'utilisateur par le terminal, à partir des données d'accès courantes et de données d'accès de référence ; o en cas d'authentification négative, suppression (E90) des données bancaires enregistrées sur le terminal.

Description

Procédé d'accès et de gestion, à partir d'un terminal, de données bancaires gérées par un serveur, produit programme d'ordinateur, moyen de stockage, terminal, équipement intermédiaire et serveur correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui des opérations et des transactions bancaires à distance. Plus précisément, l'invention concerne une technique d'accès et de gestion, à partir d'un terminal d'un réseau de communication, de données bancaires gérées par un serveur d'opérations bancaires d'un réseau externe.

L'invention s'applique notamment, mais non exclusivement, au cas où le terminal est un terminal mobile (par exemple du type téléphone compatible J2ME, iPhone d'Apple (marque déposée), Smartphone, PocketPC avec un système Microsoft Windows Mobile (marque déposée), Palm (marque déposée), Blackberry RIM (marque déposée), Google Android (marque déposée), etc.) d'un réseau de radiocommunication et où les serveurs d'opérations bancaires sont des serveurs WEB du réseau Internet. Le réseau de radiocommunication utilise par exemple la norme GSM (pour "Global System for Mobile communications" en anglais), ou une norme équivalente ou concurrente telle que DCS 1800 (pour "Digital Cellular System à 1800 Mhz", en anglais), PCS 1900 (pour "Personal Communication System à 1900 MHz" en anglais), DECT (pour "Digital European Cordless Telecommunications" en anglais), GPRS (pour "General Packet Radio Service" en anglais) ou UTMS (pour "Universal Mobile Telecommunication System" en anglais) ou CDMA (pour " Code Division Multiple Access " en anglais).

Il est clair cependant que la présente invention s'applique également avec un terminal fixe d'un réseau filaire (par exemple le réseau téléphonique commuté) et/ou avec un réseau externe autre que le réseau Internet. Ainsi, la présente invention peut s'appliquer, par exemple, à un téléviseur numérique connecté au réseau Internet via une passerelle résidentielle de type Freebox (marque déposée).

D'une façon générale, on entend par réseau externe un réseau indépendant du réseau d'accès que constitue le réseau de communication. Ce réseau externe permet à une banque de mettre à disposition des données bancaires, généralement sous la forme de bases d'informations ou de fichiers, au moyen de serveurs d'opérations bancaires (aussi appelés par la suite serveurs bancaires). Dans le cas particulier précité où le réseau externe est le réseau Internet, les bases d'informations sont des sites WEB hébergés par des serveurs WEB. 2. Arrière-plan technologique Aujourd'hui, la gestion de données bancaires en situation de mobilité représente une demande forte des usagers. On connaît déjà de très nombreuses techniques d'accès et de gestion à distance de données bancaires gérées par un serveur bancaire. D'une façon générale, on cherche notamment à concilier au moins certains des objectifs suivants : - universalité de l'accès et de la gestion, tout type de terminal de radiocommunication 2G/3G devant pouvoir communiquer avec un serveur bancaire, de façon à contrôler ce dernier pour qu'il exécute des opérations bancaires telles que, par exemple : la consultation du solde des comptes (compte courant, livret jeune, PEL,...), le virement interne, le virement externe de banque à banque, l'achat/vente d'actions, le paiement de personne à la personne par l'utilisation d'un compte mobile, etc. ; - simplicité de l'accès et de la gestion, l'utilisateur devant pouvoir effectuer ces opérations avec un nombre réduit d'opérations, et chacune de ces opérations devant être le plus facile possible ; - sécurité des opérations et notamment contrôle de l'identité de l'utilisateur (pour lutter contre les fraudes) ; - gestion du vol de terminal mobile et de la fraude en général ; - simplicité et faible coût de la mise en oeuvre. On discute ci-après les inconvénients de l'art antérieur à travers le cas particulier où l'on accède à des données bancaires gérées par un serveur WEB distant (c'est-à-dire un serveur bancaire), au moyen d'un micro-navigateur WAP 30 embarqué dans un terminal mobile. Typiquement, un micro-navigateur WAP, suite à une interaction avec un utilisateur, va envoyer une requête WAP encodée à une passerelle WAP ( WAP Gateway ) qui se charge de la décoder (en effectuant une conversion de protocoles entre le WAP (WTP pour Wireless Transaction Protocol ) et le WEB (HTTP pour HyperText Transfer Protocol et de l'aiguiller vers le bon serveur WEB. En réponse, le serveur WEB envoie les pages à la passerelle WAP qui effectue la conversion entre le WEB et le WAP et encode les données contenues dans ces pages (afin de réduire leur taille) avant de les envoyer au terminal mobile. Le micro-navigateur WAP du terminal mobile décode ces pages, les interprète et les affiche.

Bien que la technologie WAP ait représenté un progrès important dans le mécanisme de gestion à distance de données bancaires, cette technologie connue présente néanmoins un certain nombre d'inconvénients. En effet, l'ergonomie de cette technique connue est limitée par le fait que l'utilisateur doit tout d'abord lancer le micro-navigateur WAP embarqué sur le terminal mobile, puis entrer manuellement au moyen d'un clavier alphanumérique, généralement de petite taille, une adresse URL (pour Uniform Resource Locator en anglais, localisateur uniforme de ressource en français) par exemple du type : http://wap.creditmutuel.fr. Dans certaines situations, et en particulier lorsque l'utilisateur circule à bord d'un transport en commun (métro, autobus,...), la saisie d'une telle adresse URL peut s'avérer difficile et longue. Un autre inconvénient de cette technique connue réside dans le fait qu'elle nécessite la création de pages développées en WML ( Wireless Markup Language en anglais), seul langage utilisé par les micro-navigateurs WAP embarqués sur les téléphones mobiles. Le langage WML définit un certain nombre d'instructions basiques supportées par tous les micro-navigateurs, mais d'autres fonctions dépendent du type de micro-navigateur utilisé. En d'autres termes, lors de la création d'un site WAP, les développeurs doivent non seulement retranscrire en WML les pages développées en HTML, mais en plus ils doivent le faire en tenant compte des différents types de micro-navigateurs existants. La création d'un site WAP est donc complexe. Pour réduire cette complexité, les développeurs choisissent parfois de développer des pages en WML uniquement pour certains types de micro-navigateurs. Ainsi, les autres micro-navigateurs WAP sont dans l'incapacité de décoder ces pages, de les interpréter et de les afficher, ou bien ne profitent pas des caractéristiques techniques optimales des terminaux mobiles récents.

Par ailleurs, les inventeurs ont constaté qu'en cas de perte réseau, c'est-à-dire lorsque le terminal mobile n'est plus connecté au serveur bancaire via le réseau de radiocommunication (ceci peut par exemple se produire lorsque l'utilisateur passe sous un tunnel), le délai de rétablissement de la connexion au serveur bancaire est relativement long. On note que pendant cette période de perte réseau, l'utilisateur ne peut pas consulter ses données bancaires, et doit parfois recommencer la procédure de connexion à partir du début de la procédure, ce qui est coûteux et pénible en situation mobile, avec un petit clavier. 3. Objectifs de l'invention L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, l'un des objectifs de la présente invention, dans au moins un mode de réalisation, est de fournir une technique d'accès et de gestion de données bancaires, depuis tout terminal mobile, qui soit simple à mettre en oeuvre et efficace, notamment en termes de rapidité d'accès au serveur banque et de fluidité de l'interface homme machine. Un objectif complémentaire de l'invention, dans au moins un de ses modes de réalisation, est de fournir une telle technique qui supprime les opérations de saisie manuelle d'adresses URL via l'interface homme/machine du terminal mobile, en permettant un accès le plus direct et simple d'emploi à sa banque.

L'invention a également pour objectif, dans au moins un mode de réalisation, de proposer une telle technique qui permette une meilleure sécurisation de l'accès aux données bancaires d'un serveur bancaire, de lutter contre la fraude et le vol. Un autre objectif de l'invention, dans au moins un de ses modes de 30 réalisation, est de fournir une telle technique qui soit peu coûteuse et compatible avec tous les serveurs bancaires existants.

Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique qui permette à un utilisateur de consulter tout ou partie de ses données bancaires, lorsque son terminal mobile est déconnecté du réseau de communication.

Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique qui permette à un utilisateur de consulter tout ou partie de ses données bancaires à partir de son poste de télévision ADSL, ou bien à partir d'une mini application de type Widget (par exemple une application pour le bureau de Microsoft Windows Vista (marque déposée) ou pour un Dashboard Mac de la société Apple (marque déposée)) ou Online Widget (par exemple une mini application pour iGoogle (marque déposée) ou Facebook (marque déposée)). 4. Exposé de l'invention Dans un mode de réalisation particulier de l'invention, il est proposé un procédé d'accès et de gestion, à partir d'un terminal d'un réseau de communication, de données bancaires gérées par un serveur d'opérations bancaires d'un réseau externe. Selon l'invention, le procédé comprend : - une phase de configuration comprenant les étapes suivantes : o enregistrement par ledit terminal de données d'accès de référence fournies par un utilisateur ; o première négociation entre ledit terminal et ledit serveur ; o en cas de première négociation réussie, réception par ledit terminal de données bancaires associées audit utilisateur, dites données utilisateur, en provenance dudit serveur ; o enregistrement par ledit terminal desdites données utilisateur, - une phase d'utilisation comprenant les étapes suivantes : o réception par ledit terminal de données d'accès courantes fournies par l'utilisateur ; o première authentification de l'utilisateur par ledit terminal, à partir desdites données d'accès courantes et desdites données d'accès de référence ; o en cas de première authentification négative, suppression desdites données utilisateur enregistrées par ledit terminal. Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la gestion de données bancaires. En effet, l'invention propose de stocker sur le terminal tout ou partie des données bancaires associées à l'utilisateur. Ainsi, en cours d'utilisation et contrairement aux techniques de l'art antérieur (notamment la technologie WAP), l'invention permet à l'utilisateur, en cas de perte réseau (c'est-à-dire lorsque le terminal n'est plus connecté au réseau de communication), de continuer à consulter ses données bancaires (par exemple le solde de ses comptes bancaires) et/ou les dernières opérations bancaires qu'il a effectuées.

Dans un mode de réalisation particulier, les données bancaires sont stockées sur le terminal sous une forme cryptée et/ou compressée. Par ailleurs, lors de la phase de configuration l'utilisateur saisit via une interface homme/machine (par exemple le clavier du terminal ou un clavier virtuel) des données d'accès telles que, par exemple, un code PIN de quatre chiffres. Ce code PIN est ensuite stocké sur le terminal. Selon l'invention, lors de la phase d'utilisation l'accès aux données bancaires stockées sur le terminal est conditionné par l'authentification de l'utilisateur par le terminal. En d'autres termes, pour accéder aux données bancaires stockées sur le terminal l'utilisateur doit fournir au terminal le bon code PIN. Dans le cas où l'utilisateur n'est pas authentifié avec succès par le terminal (c'est-à-dire lorsque l'utilisateur n'a pas saisi les bonnes données d'accès), ce dernier supprime toutes les données bancaires. Ainsi, l'invention permet de maximiser la confidentialité des données bancaires stockées sur le terminal, notamment en cas de vol du terminal. Selon un aspect avantageux de l'invention, ladite phase d'utilisation comprend, en cas de première authentification positive, une étape de restitution par ledit terminal desdites données utilisateur enregistrées, ainsi que des données de personnalisation : logotype de la banque ou de la caisse régionale, textes d'accueil personnalisés, informations concernant des produits promotionnels. Avantageusement, ladite phase d'utilisation comprend en outre, en cas de première authentification positive, une deuxième étape de négociation entre ledit terminal et ledit serveur. Selon l'invention, en cas de deuxième négociation réussie, le procédé comprend les étapes suivantes : - le terminal envoie à un équipement intermédiaire, via le réseau de communication et selon un premier protocole de communication, au moins une demande de lancement d'une opération bancaire sur le serveur ; - l'équipement intermédiaire traduit ladite au moins une demande du terminal en au moins une requête et transmet ladite au moins une requête au serveur, via le réseau externe et selon un deuxième protocole de communication ; - le serveur reçoit et exécute ladite au moins une requête. Ainsi, toute l'intelligence et la logique de gestion sont déplacées au niveau de l'équipement intermédiaire (passerelle), ce qui rend l'invention exploitable pour n'importe quel type de terminal de communication et de serveur bancaire, ces derniers ne nécessitant donc aucune adaptation complexe et coûteuse pour être compatibles avec le procédé selon l'invention, ce qui est particulièrement intéressant.

Selon un premier mode de réalisation avantageux de l'invention, le premier protocole de communication appartient au groupe comprenant : - un protocole HTTPS ; - un protocole HTTP. Ainsi, en mettant en oeuvre un protocole HTTPS ( Hypertext Transfer Protocol over Secure Socket Layer en anglais) on améliore davantage la sécurité des données échangées entre le terminal et l'équipement intermédiaire. Selon un second mode de réalisation avantageux de l'invention, le premier protocole de communication est un protocole SMPP. Dans ce cas, le procédé comprend les étapes suivantes : - le terminal envoie à une passerelle de conversion, via le réseau de communication, ladite au moins une demande de lancement ; - la passerelle de conversion traduit ladite au moins une demande du terminal en au moins une demande de lancement transformée, se présentant sous une forme compréhensible par l'équipement intermédiaire, et transmet ladite au moins une demande de lancement transformée à l'équipement intermédiaire, via le réseau de communication et selon un protocole HTTPS.

Ainsi, l'invention permet à un terminal mettant en oeuvre le protocole SMPP ( Short Message Peer-to-Peer Protocol en anglais) de gérer à distance et de manière efficace des données bancaires stockées sur un serveur bancaire, à partir de SMS ( Short Message Service en anglais). Pour ce faire, l'invention prévoit la mise en oeuvre d'une passerelle de conversion entre le terminal et l'équipement intermédiaire. Cette passerelle de conversion permet de réaliser la conversion entre le SMS et le WEB. Préférentiellement, ledit deuxième protocole de communication appartient au groupe comprenant : - un protocole SOAP sur un protocole HTTPS ; - un protocole HTTPS. Ainsi, en mettant en oeuvre un protocole SOAP sur un protocole HTTPS on améliore davantage la sécurité du transit des données bancaires entre le serveur bancaire et l'équipement intermédiaire.

Avantageusement, dans le cas où l'exécution de ladite au moins une requête se traduit par la transmission de données utilisateur depuis le serveur vers l'équipement intermédiaire, le procédé comprend en outre les étapes suivantes : - l'équipement intermédiaire traduit les données utilisateur transmises par le serveur en des données utilisateur transformées, se présentant sous une forme compréhensible par ledit terminal ; - l'équipement intermédiaire transmet les données utilisateur transformées audit terminal ; - ledit terminal enregistre les données utilisateur transformées. Dans un mode de réalisation particulier, l'équipement intermédiaire crypte et compresse les données bancaires avant de les transmettre vers le terminal. Selon un aspect avantageux de l'invention, le procédé comprend en outre les étapes suivantes : - l'équipement intermédiaire reçoit des données supplémentaires en provenance d'au moins un équipement de gestion de données 30 supplémentaires, via le réseau externe ; - l'équipement intermédiaire enrichit les données utilisateur transformées avec lesdites données supplémentaires, de façon à transmettre audit terminal des données enrichies. L'équipement de gestion de données supplémentaires selon l'invention est par exemple un serveur de publicités, un serveur de données financières, un serveur d'images, un système externe de gestion de transactions bancaires ou de paiement de factures etc., c'est-à-dire un serveur de données autre qu'un serveur de données bancaires. Ainsi, l'invention propose de transmettre vers le terminal des données publicitaires, des données boursières, etc., en même temps que les données bancaires, ou bien de payer des factures, ou d'envoyer de l'argent sous forme liquide à l'étranger en passant par le système bancaire assurant une traçabilité, ou de créditer un compte mobile d'une personne tierce comme d'un fournisseur identifié au préalable ou devant s'identifier pour recevoir son paiement sous un temps limité ; cette identification pouvant être effectuée par exemple sur un système internet d'une institution financière, ou bien par l'intermédiaire d'un site internet. De façon avantageuse, ledit terminal appartient au groupe comprenant : - des terminaux mobiles ; - des terminaux fixes.

L'invention propose donc une solution multi-canal, en ce sens qu'elle permet à tout type de terminal d'accéder et de gérer via tout type de canal de communication des données bancaires gérées par un serveur bancaire. Avantageusement, ladite phase de configuration comprend en outre une étape d'enregistrement par l'équipement intermédiaire d'une question définie par l'utilisateur et d'une réponse à ladite question fournie par l'utilisateur, dite réponse vrai. Selon un aspect avantageux de l'invention, chacune desdites première et deuxième étapes de négociation comprend les étapes suivantes : - réception par l'équipement intermédiaire d'un premier jeu de données d'authentification courant en provenance dudit terminal ; - deuxième authentification de l'utilisateur par l'équipement intermédiaire, à partir dudit premier jeu de données d'authentification courant ; - en cas de deuxième authentification positive, réception par le serveur d'un deuxième jeu de données d'authentification courant en provenance de l'équipement intermédiaire ; - troisième authentification de l'utilisateur par le serveur, à partir dudit deuxième jeu de données d'authentification courant ; - en cas de troisième authentification positive, établissement d'une communication sécurisée entre ledit terminal et ledit serveur. Les premier et deuxième jeux de données d'authentification de références sont définis par l'organisme bancaire auquel appartient le serveur bancaire, ou peuvent être générés par la passerelle. Généralement, l'organisme bancaire envoie à l'utilisateur un ou plusieurs courriers comprenant ces jeux de données d'authentification de références. Comme on le verra dans la suite de la description, dans un mode de réalisation particulier, l'équipement intermédiaire met en oeuvre un mécanisme d'authentification à deux facteurs, ce qui permet d'améliorer la sécurisation de l'accès au serveur bancaire (et donc aux données bancaires de l'utilisateur). De façon préférentielle, chacun des premier et deuxième jeux de données d'authentification courant comprend au moins une information appartenant au groupe comprenant : - un identifiant associé à l'utilisateur ; propre à une banque, ou commun à plusieurs institutions financières (par exemple OpenID) - un mot de passe ; pouvant être issu d'un croisement de données sous forme de tableau unique pour chaque client de la banque (tableau simple à utiliser de type bataille navale, généré par la passerelle) - un numéro de compte bancaire ; - un numéro unique d'identifiant de chaque application déployée (TAG en anglais) assurant un contrôle de l'intégrité par un croisement de variables d'identification et une étude des changements de comportement des habitudes de connexion des clients - un identifiant associé audit terminal.

L'invention couvre un premier cas dans lequel l'identifiant associé au terminal est l'identifiant IMEI (pour International Mobil Equipment Identity ) du terminal. L'invention couvre un deuxième cas dans lequel l'identifiant associé au terminal est le numéro d'identité IMSI (pour International Mobile Subscriber Identity en anglais) stocké sur la carte SIM (pour Subscriber Identity Module en anglais, module d'identité d'abonné en français) du terminal. L'invention couvre un troisième cas dans lequel l'identifiant associé au terminal est le numéro de téléphone du terminal.

Avantageusement, ladite deuxième étape de négociation utilisée par exemple pour les transactions comprend en outre les étapes suivantes, en cas de deuxième authentification négative : - l'équipement intermédiaire envoi audit terminal ladite question enregistrée ; - l'équipement intermédiaire reçoit une réponse courante en provenance dudit terminal, ladite réponse courante étant fournie par l'utilisateur ; - l'équipement intermédiaire compare ladite réponse courante et ladite réponse vraie enregistrée ; - en cas de comparaison positive, l'équipement intermédiaire envoie audit serveur ledit deuxième jeu de données d'authentification courant.

L'invention propose donc de combiner un mécanisme d'authentification à deux facteurs et un mécanisme d'authentification avec question secrète. Dans un mode de réalisation particulier, il est possible d'envisager de limiter ou d'interdire toute opération bancaire (par exemple l'achat/vente d'actions ou le virement externe) lorsque l'utilisateur n'est pas authentifié avec succès par le mécanisme d'authentification avec question secrète. Selon un aspect avantageux de l'invention, les échanges entre ledit terminal et l'équipement intermédiaire sont mis en oeuvre par une application logicielle, compris dans ledit terminal, et un aspirateur de pages HTML (PARSER en anglais), compris dans l'équipement intermédiaire.

Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, ledit produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre du procédé précité, lorsque ledit programme est exécuté sur un ordinateur.

Dans un autre mode de réalisation, l'invention concerne un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé précité. Dans un autre mode de réalisation, l'invention concerne un terminal de 10 communication du type pouvant être connecté à un réseau de communication. Selon l'invention, le terminal comprend : - des moyens de stockage de données bancaires transmises par un serveur d'opérations bancaires d'un réseau externe ; - des moyens d'authentification d'un utilisateur du terminal, lesdits premiers 15 moyens d'authentification générant un signal de commande en cas d'authentification négative ; - des moyens de suppression des données bancaires stockées dans les moyens de stockage, lesdits moyens de suppression étant activés par ledit signal de commande. 20 Dans un autre mode de réalisation, l'invention concerne un équipement intermédiaire du type pouvant communiquer avec un terminal, via un réseau de communication, et avec un serveur d'opérations bancaires, via un réseau externe. Selon l'invention, l'équipement intermédiaire comprend : - des moyens de réception d'au moins une demande de lancement d'une 25 opération bancaire sur le serveur transmise par le terminal mobile, via le réseau de communication et selon un premier protocole de communication ; - des premiers moyens de traduction de ladite au moins une demande du terminal en au moins une requête compréhensible par le serveur ; - des premiers moyens de transmission de ladite au moins une requête au 30 serveur, via le réseau externe et selon un deuxième protocole de communication.

Selon un aspect avantageux de l'invention, l'équipement intermédiaire comprend au moins l'un des moyens suivants : - des moyens de réception de données bancaires transmises par le serveur, via le réseau externe et selon le deuxième protocole de communication ; - des seconds moyens de traduction desdites données bancaires du serveur en des données bancaires transformées, se présentant sous une forme compréhensible par le terminal ; - des seconds moyens de transmission des données bancaires transformées au terminal, via le réseau de communication et selon le premier protocole 10 de communication ; - un aspirateur de pages HTML compatible avec les sites et infrastructures sécurisées des banques, notamment en ce qui concerne les enchaînements de pages internet invisibles Dans un autre mode de réalisation, l'invention concerne un serveur 15 d'opérations bancaires du type pouvant être connecté à un réseau externe. Selon l'invention, le serveur comprend des moyens de réception et d'exécution d'au moins une requête transmise selon un deuxième protocole de communication par un équipement intermédiaire, via le réseau externe, ladite requête correspondant à la traduction d'une demande d'un terminal reçue par l'équipement intermédiaire, 20 via un réseau de communication et selon un premier protocole de communication. 5. Liste des figures D'autres caractéristiques et avantages de modes de réalisation de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention 25 ne sont pas limités aux caractéristiques et avantages des modes de réalisation décrits ci-après), et des dessins annexés, dans lesquels : - la figure 1 présente un exemple de système d'accès et de gestion de données bancaires selon un mode de réalisation préférentiel de l'invention ; - les figures 2a et 2b présentent des organigrammes illustrant un mode de réalisation particulier du procédé selon l'invention, dans le cas où le terminal met en oeuvre un protocole HTTPS ; - la figure 3 présente la structure simplifiée d'un mode de réalisation particulier d'un serveur d'opérations bancaires selon l'invention ; - la figure 4 présente la structure simplifiée d'un mode de réalisation particulier d'un équipement intermédiaire selon l'invention ; et - la figure 5 présente la structure simplifiée d'un mode de réalisation particulier d'un terminal selon l'invention. 6. Description détaillée On rappelle que la présente invention propose de définir une technique d'accès à des données bancaires en situation de mobilité. Comme on le notera sur toutes les figures du présent document les éléments et étapes identiques sont désignés par une même référence numérique.

Par souci de clarté, dans toutes les figures du présent document les moyens sont référencés par des références numériques (du type 1, 2, 3,...) et les étapes de procédé sont référencées par des références alphanumériques (du type El, E2, E3,...). Le principe général de l'invention repose sur la mise en oeuvre de deux 20 modes d'accès : - un premier mode d'accès, dit mode connecté, dans lequel un utilisateur peut accéder à un serveur bancaire et gérer en temps réel des opérations bancaires (virement, synthèse de compte, détail des écritures, achat/revente d'actions, etc.) depuis son terminal de communication. Ce mode connecté est mis en oeuvre par le terminal lorsque ce dernier est connecté à un réseau de communication (par exemple le réseau GPRS). Le procédé selon l'invention fait notamment intervenir un équipement intermédiaire (aussi appelé par la suite passerelle bancaire) accessible depuis le terminal via un réseau externe (par exemple le réseau Internet). Selon un tel procédé, toute l'intelligence d'accès et de gestion des données bancaires 25 30 (stockées au niveau du serveur bancaire) est assurée par la passerelle bancaire. Le serveur bancaire n'a qu'un rôle d'esclave vis-à-vis de la passerelle bancaire qui joue le rôle du maître en transmettant vers le serveur bancaire des requêtes à exécuter. Le terminal mobile quant à lui n'est jamais directement en relation (c'est-à-dire qu'il ne communique pas directement) avec le serveur bancaire, mais toujours par l'entremise de la passerelle bancaire ; un second mode d'accès, dit mode non connecté, dans lequel l'utilisateur peut consulter (hors connexion) ses données bancaires et/ou les dernières opérations bancaires qu'il a effectuées. Ce mode non connecté est mis en oeuvre par le terminal, par exemple, en cas de perte réseau. Le mode non connecté de l'invention repose sur le stockage des données bancaires de l'utilisateur sur le terminal sous forme de fichiers cryptés et compressés.

On présente maintenant, en relation avec la figure 1, un exemple de système selon l'invention. Dans cet exemple simplifié, le système comprend : un réseau de communication 1 auquel est relié un terminal 2 d'un utilisateur. Par souci de simplification de la description, on se limitera, dans toute la suite de ce document, à décrire le cas particulier où le terminal 2 est un terminal mobile (par exemple un smartphone) comprenant un module de radiocommunication lui conférant la capacité de se connecter au réseau Internet via le réseau GPRS. L'Homme du Métier étendra sans difficulté cet enseignement à un terminal mobile de toute autre nature (par exemple un PocketPC, un PDA, un iPhone (marque déposée) de la société Apple, un Blackberry (marque déposée) de la société RIM, ...) et équipé de tout autre type de module de radiocommunication utilisant le canal DATA ou SMS (par exemple conforme à la norme Edge, UMTS,...), ou à un terminal fixe (par exemple un téléviseur numérique connecté au réseau Internet via une passerelle résidentielle) ; le réseau Internet 3 (formant réseau externe) auquel sont reliés une passerelle bancaire 4 et un serveur bancaire 5. Selon l'invention, dans le cas où un service WEB sécurisé est mis en oeuvre côté serveur bancaire 5, les échanges de données entre la passerelle bancaire 4 et le serveur bancaire 5 se font suivant un protocole SOAP sur un protocole HTTPS ou suivant le protocole HTTPS (uniquement). Les données échangées sont au format XML ( eXtensible Markup Language en anglais). Selon l'invention, dans le cas où aucun service WEB sécurisé n'est mis en oeuvre côté serveur bancaire 5, la passerelle bancaire 4 met en oeuvre un aspirateur de pages HTML ( Parsing HTML en anglais). Les techniques d'aspiration de pages HTML sont bien connues de l'Homme du Métier. Elles ne seront pas décrites plus en détail dans la présente description. Dans la suite de ce document, on se place dans le cas où les échanges de 15 données entre la passerelle bancaire 4 et le serveur bancaire 5 se font suivant le protocole SOAP sur le protocole HTTPS. On présente maintenant avec les figures 2a et 2b un premier exemple de mode de réalisation dans lequel un utilisateur accède à distance à des données bancaires gérées par un serveur bancaire depuis un terminal mobile mettant en 20 oeuvre un protocole HTTPS. Comme illustré par la figure 2a, une phase de configuration El est mise en oeuvre lorsque l'utilisateur lance pour la première fois l'application logicielle embarquée sur le terminal mobile et contenant les instructions de code de programme pour la mise en oeuvre du procédé selon l'invention. 25 La phase de configuration El comprend une première étape E10 au cours de laquelle l'utilisateur saisit via l'interface homme/machine du terminal (noté par la suite IHM) des données d'accès de référence, en réponse à une demande du terminal. A titre d'exemple, on suppose qu'à cette étape E10 l'utilisateur saisit un code de 4 chiffres. 30 Lors d'une étape E20, le terminal enregistre le code de 4 chiffres sous une forme cryptée, fruit d'une sérialisation de plusieurs algorithmes d'encodage 10 Lors d'une étape E30, l'utilisateur saisit via l'IHM du terminal une question et la réponse à ladite question, en réponse à une demande du terminal. Lors d'une étape E40, le terminal transmet, en utilisant le protocole HTTPS, la question et la réponse à ladite question vers la passerelle bancaire. La passerelle bancaire reçoit et enregistre la question et la réponse à ladite question. Dans un mode de réalisation particulier, la question et la réponse sont cryptées et compressées par le terminal avant envoi. Les sous-étapes suivantes sont relatives à une première étape de négociation E50 entre le terminal et le serveur bancaire. Cette première étape de négociation permet d'établir une communication sécurisée entre le terminal et le serveur bancaire. Lors d'une sous-étape E501, l'utilisateur saisit via l'IHM du terminal un nom d'utilisateur et un mot de passe, en réponse à une demande du terminal. Lors d'une sous-étape E502, le terminal transmet, en utilisant le protocole HTTPS, un premier jeu de données (dit premier jeu de données d'authentification courant) vers la passerelle bancaire. Selon un mode de réalisation particulier de l'invention, le premier jeu de données d'authentification courant comprend le nom d'utilisateur et le mot de passe (saisis à la sous-étape E501), ainsi qu'un identifiant associé au terminal. A titre d'exemple, on considère pour la suite que l'identifiant compris dans le premier jeu de données d'authentification courant est le numéro d'identité IMSI stocké sur la carte SIM du terminal. Selon un aspect avantageux de l'invention, le premier jeu de données d'authentification courant est crypté et compressé par le terminal avant envoi. Les techniques d'encodage utilisées sont Triple DES, décalages de bits, compression ZIP en base 64 au minimum et cryptage, ou encore MD5. Les techniques de One Time Password sont également utilisées, ainsi que les techniques connues d'algorithme de défi-réponse, conformément à la littérature en ce domaine. Lors d'une sous-étape E503, la passerelle bancaire met en oeuvre un premier mécanisme d'authentification permettant d'authentifier l'utilisateur et le terminal. Plus précisément, la passerelle bancaire maintient une table de premiers jeux de données d'authentification de référence comprenant chacun : un numéro d'identité IMSI, un nom d'utilisateur et un mot de passe. A cette sous-étape E503, la passerelle bancaire vérifie dans sa table si le premier jeu de données d'authentification courant correspond à l'un des premiers jeux de données d'authentification de référence. Si le premier jeu de données d'authentification courant est connu de la passerelle bancaire (c'est-à-dire en cas d'authentification positive), alors on passe à une sous-étape E504, sinon (c'est-à-dire en cas d'authentification négative) on passe à une sous-étape E510. On note qu'une authentification négative peut, par exemple, avoir lieu si l'utilisateur saisit un mot de passe incorrect ou, par exemple, si le terminal transmet un numéro d'identité IMSI incorrect (une telle situation peut se produire si l'utilisateur utilise la carte SIM d'une autre personne). Lors de la sous-étape E504, l'utilisateur saisit via l'IHM du terminal un numéro de compte bancaire et un code personnel (par exemple composé de 6 15 chiffres), en réponse à une demande du terminal. Lors d'une sous-étape E505, le terminal transmet, en utilisant le protocole HTTPS, un deuxième jeu de données (dit deuxième jeu de données d'authentification courant) vers la passerelle bancaire. Le deuxième jeu de données d'authentification courant comprend le numéro de compte bancaire et le 20 code personnel (saisis à la sous-étape E504). La passerelle bancaire transmet ensuite, en utilisant le protocole SOAP sur le protocole HTTPS, le deuxième jeu de données d'authentification courant vers le serveur bancaire. Lors d'une sous-étape E506, le serveur bancaire met en oeuvre un deuxième mécanisme d'authentification permettant d'authentifier l'utilisateur. 25 Plus précisément, le serveur bancaire maintient une table de deuxièmes jeux de données d'authentification de référence comprenant chacun : un numéro de compte bancaire et un code personnel. A cette sous-étape E506, le serveur bancaire vérifie dans sa table si le deuxième jeu de données d'authentification courant correspond à l'un des deuxièmes jeux de données d'authentification de 30 référence. Si le deuxième jeu de données d'authentification courant est connu du serveur bancaire (c'est-à-dire en cas d'authentification positive) (en d'autres termes si l'utilisateur est authentifié comme étant un client de la banque auquel appartient le serveur bancaire), alors on passe à une sous-étape E507, sinon (c'est-à-dire en cas d'authentification négative) on passe à une sous-étape E513. Dans une variante de réalisation, il est possible d'envisager d'incrémenter un compteur à chaque fois que l'utilisateur n'est pas authentifié par le serveur bancaire, de sorte que : - si le compteur n'a pas atteint un nombre N prédéterminé (avec N>_1), alors on retourne à la sous-étape E504 ; - si le compteur a atteint le nombre N prédéterminé, alors on passe à la sous-étape E513. Lors de la sous-étape E507, une communication sécurisée est établie entre le terminal et le serveur bancaire. A cette même sous-étape E507, le serveur bancaire transmet, en utilisant le protocole SOAP sur le protocole HTTPS, les données bancaires de l'utilisateur (états des comptes courants, portefeuilles de titres, etc.) vers la passerelle bancaire. La passerelle bancaire traduit les données bancaires transmise par le serveur bancaire en des données bancaires transformées, se présentant sous une forme compréhensible par le terminal. Dans l'exemple de réalisation illustré, la passerelle bancaire crypte et compresse les données bancaires avant envoi vers le terminal.

Les flux entre le système intermédiaire et les serveurs bancaires sont classiquement des flux cryptés https utilisant un canal privé virtuel. Lors d'une sous-étape E508, la passerelle bancaire transmet, en utilisant le protocole HTTPS, les données bancaires cryptées et compressées vers le terminal. Lors d'une sous-étape E509, le terminal reçoit et enregistre les données bancaires cryptées et compressées, puis les décompresse et les décrypte de manière à les restituer (sur son écran d'affichage) sous une forme lisible par l'utilisateur. Lors de la sous-étape E510 (en cas d'authentification négative de l'utilisateur par la passerelle bancaire), la passerelle bancaire transmet, en utilisant le protocole HTTPS, la question enregistrée à l'étape E40 vers le terminal. Lors d'une sous-étape E511, l'utilisateur saisit via l'IHM du terminal une réponse à la question (dite réponse courante). Le terminal transmet ensuite, en utilisant le protocole HTTPS, la réponse courante vers la passerelle bancaire. Lors d'une sous-étape E512, la passerelle bancaire compare la réponse courante et la réponse enregistrée à l'étape E40. Si la réponse courante est identique à la réponse enregistrée, alors on passe à la sous-étape E504, sinon on passe à la sous-étape E513. Lors de la sous-étape E513, le terminal affiche sur son écran un message d'erreur. Comme on le notera certaines étapes de la figure 2b sont identiques (mêmes références alphanumériques) à certaines étapes décrites précédemment à la figure 2a. Ces étapes communes (E501 à E505 et E510 à E513) ne sont pas décrites de nouveau ci-après. Comme illustré par la figure 2b, une phase d'utilisation E2 est mise en oeuvre : - lorsque l'utilisateur relance l'application logicielle embarquée sur le terminal. Dans ce premier cas, la phase d'utilisation E2 commence à l'étape E60 décrite ci-après ; - ou lorsque l'utilisateur utilise son terminal pour effectuer des opérations bancaires juste après la phase de configuration El (décrite à la figure 2a). Dans ce deuxième cas, la phase d'utilisation E2 commence à l'étape E100 décrite ci-après. Lors de l'étape E60, l'utilisateur saisit via l'IHM du terminal un code courant de 4 chiffres (aussi appelé par la suite données d'accès courantes), en réponse à une demande du terminal.

Lors d'une étape E70, le terminal compare le code courant saisi à l'étape E60 et le code enregistré à l'étape E20. Si le code courant est identique au code enregistré, alors on passe à une étape E80, sinon on passe à une étape E90. Dans un mode de réalisation particulier, le terminal peut afficher sur son écran les données bancaires enregistrées à l'étape E509, en signe d'authentification positive de l'utilisateur par le terminal. Lors de l'étape E90, le terminal supprime toutes les données bancaires enregistrées à l'étape E509. Dans un mode de réalisation particulier, après suppression des données bancaires, aucun message n'est affiché sur l'écran du terminal. Dans une variante de réalisation, il est également possible d'envisager qu'après suppression des données bancaires le terminal génère des fausses données bancaires. Ainsi, en cas de vol du terminal, le voleur accède à des fausses données bancaires d'un compte de démonstration Lors de l'étape E80 (aussi appelée par la suite deuxième étape de négociation), on met en oeuvre les sous-étapes E501 à E505 et E510 à E513 décrites précédemment en référence à la figure 2a. Par souci de simplification de la description, on détaille ci-après uniquement les étapes qui n'apparaissent pas sur la figure 2a. Lors d'une sous-étape E806, le serveur bancaire vérifie si le deuxième jeu de données d'authentification courant (saisi par l'utilisateur à la sous-étape E504) correspond à l'un des deuxièmes jeux de données d'authentification de référence (compris dans la table stockée par le serveur bancaire). Si le deuxième jeu de données d'authentification courant est connu du serveur bancaire, alors on passe à l'étape E10, sinon on passe à la sous-étape E513. Par souci de simplification de la description, on se limitera dans la suite de la description à décrire le cas particulier où l'utilisateur effectue un virement de compte à compte. L'Homme du Métier étendra sans difficulté cet enseignement à tout autre type de transaction bancaire. Lors de l'étape E100, l'utilisateur sélectionne dans le menu de l'application (affiché sur l'écran du terminal) l'icône correspondant à l'opération de virement bancaire. L'utilisateur saisit via l'IHM du terminal des données de virement bancaire telles que, par exemple, un numéro de compte destinataire et une somme d'argent à transférer depuis le compte de l'utilisateur (saisi à la sous-étape E504) vers le compte destinataire (IBAN), ainsi qu'un libellé et une date d'exécution. Lors d'une étape E110, le terminal transmet, en utilisant le protocole HTTPS, une demande de lancement d'une opération de virement bancaire vers la passerelle bancaire. On note que la demande de lancement véhicule les données de virement bancaire sous forme cryptée et compressée. Lors d'une étape E120, la passerelle bancaire traduit la demande du terminal en une requête d'exécution de virement bancaire, se présentant sous une forme compréhensible par le serveur bancaire. La passerelle bancaire transmet ensuite, en utilisant le protocole SOAP sur le protocole HTTPS, la requête d'exécution vers le serveur bancaire compatible avec une architecture orientée service (SOA en anglais) Lors d'une étape E130, le serveur bancaire exécute la requête. A cette étape E130, le serveur bancaire transfère la somme d'argent définie par l'utilisateur à l'étape E100 depuis son compte bancaire vers le compte destinataire spécifié par l'utilisateur à l'étape E100. Après exécution de la requête, le serveur bancaire envoie au terminal un message de confirmation de virement, via la passerelle bancaire, doublé éventuellement de l'envoi d'un SMS de confirmation. Sur réception du message de confirmation, le terminal enregistre les données de virement bancaire (numéro de compte destinataire, somme d'argent transféré, date du virement,...) sous forme de fichier crypté et compressé, ou de donnée cryptée stockée dans un espace mémoire cloisonné. On rappelle que l'enregistrement sur le terminal des données bancaires et des opérations bancaires sous forme de fichiers cryptés et compressés, est un aspect important de la mise en oeuvre de l'invention. En effet, en cours d'utilisation lorsque le terminal perd la connexion au réseau de communication (par exemple dans le cas où l'utilisateur voyageant dans un train passe sous un tunnel), l'utilisateur peut continuer à consulter ses données bancaires (c'est-à-dire celles enregistrées sur le terminal), et le cas échéant, commencer à préparer ses prochaines opérations bancaires, ou bien de pointer ses écritures pour effectuer un rapprochement bancaire avec ses tickets et talons de chèques. Celles-ci seront envoyées vers le serveur bancaire dès que la connexion au réseau de communication sera rétablie, sous condition de limite de temps de rétablissement de la connexion paramétrable par le système intermédiaire.

Comme illustré sur la figure 1, dans le cas où le terminal 2 met en oeuvre un protocole SMPP lui conférant la capacité de transmettre des messages SMS, le système selon l'invention met en oeuvre une passerelle de conversion 6 entre le terminal 2 et la passerelle bancaire 4. La passerelle de conversion 6 effectue la conversion entre le SMS et le WEB. En d'autres termes, la passerelle de conversion 6 traduit les différentes données émises depuis le terminal (par exemple les premier et deuxième jeux de données d'authentification courant, les demandes de virement, etc.) en des données transformées, se présentant sous une forme compréhensible par la passerelle bancaire 4. La passerelle de conversion 6 transmet, en utilisant le protocole HTTPS, les données transformées vers la passerelle bancaire 4. En d'autres termes, les clients d'une banque ne disposant pas d'un forfait données, mais uniquement d'un forfait voix et SMS, pourront tout de même être des utilisateurs du système. Dans un mode de réalisation particulier, la passerelle bancaire 4 peut également être connectée à un ou plusieurs équipements de gestion de données supplémentaires (non représentés) tels que, par exemple, des serveurs de données publicitaires, des serveurs de données financières, etc. La passerelle bancaire peut donc enrichir les données renvoyées au terminal avec des données publicitaires, des données financières, etc. Ainsi, selon un aspect avantageux de l'invention, l'utilisateur peut recevoir en temps réel les cours de la bourse sur son terminal mobile et passer simplement et efficacement des ordres d'achat/vente d'actions depuis son terminal, ou bien envoyer de l'argent à un proche, en ne mémorisant que le numéro de téléphone portable du destinataire. La figure 3 présente la structure simplifiée d'un serveur bancaire 5 selon l'invention, qui comprend une mémoire 52, et une unité de traitement 51 équipée d'un microprocesseur ptP, qui est piloté par un programme d'ordinateur (ou application) 53 mettant en oeuvre certaines étapes du procédé selon l'invention (décrites aux figures 2a et 2b). L'unité de traitement 51 reçoit en entrée une requête 54 relative à une demande de lancement d'une opération bancaire sur le serveur bancaire 5. Le microprocesseur ptP traite cette requête, selon les instructions du programme 53 de sorte qu'en fonction de la nature de la requête le serveur bancaire transmet (en utilisant par exemple le protocole SOAP sur le protocole HTTPS) vers une passerelle bancaire 4 des données bancaires 55 d'un utilisateur ou un message de confirmation 56 d'exécution d'opération bancaire. La figure 4 présente la structure simplifiée d'une passerelle bancaire 4 (aussi appelée par la suite équipement intermédiaire) selon l'invention, qui comprend une mémoire 42, et une unité de traitement 41 équipée d'un microprocesseur ptP, qui est piloté par un programme d'ordinateur (ou application) 43 mettant en oeuvre certaines étapes du procédé selon l'invention (décrites aux figures 2a et 2b). L'unité de traitement 41 reçoit en entrée une demande de lancement 44 d'une opération bancaire sur le serveur bancaire 5 décrit à la figure 3. Le microprocesseur ptP traite cette demande, selon les instructions du programme 43, pour générer une requête 54 exécutable par le serveur bancaire 5. La figure 5 présente enfin la structure simplifiée d'un terminal de communication 2 selon l'invention, qui comprend une mémoire 22 comprenant des données bancaires 25 cryptées et compressées, et une unité de traitement 21 équipée d'un microprocesseur ptP, qui est piloté par un programme d'ordinateur (ou application) 23 mettant en oeuvre certaines étapes du procédé selon l'invention (décrites aux figures 2a et 2b). L'unité de traitement 21 reçoit en entrée des données d'accès courantes 24 fournies par un utilisateur. Le microprocesseur ptP traite ces données d'accès courantes, selon les instructions du programme 23. Plus précisément, le microprocesseur ptP compare les données d'accès courantes et des données d'accès de référence (par exemple stockées dans la mémoire 22 ou dans une autre mémoire du terminal), de sorte qu'en fonction du résultat de la comparaison le terminal supprime ou restitue sur son écran d'affichage les données bancaires 25 stockées dans la mémoire 22.25

Claims (12)

1. REVENDICATIONS1. Procédé d'accès à un serveur de gestion (5) de données utilisateur à partir d'un terminal de communication (2) appartenant à un utilisateur, caractérisé en ce qu'il comprend les étapes suivantes : réception (E502), par un équipement intermédiaire, d'un premier jeu de données d'authentification propre audit utilisateur, en provenance dudit terminal ; authentification (E503) dudit utilisateur par ledit équipement intermédiaire, à partir dudit premier jeu de données d'authentification reçu et d'un premier jeu de données de référence ; si ledit utilisateur a été authentifié par ledit équipement intermédiaire, réception (E505), par ledit serveur, d'un second jeu de données d'authentification propre audit utilisateur, en provenance dudit terminal ; authentification (E506) dudit utilisateur par ledit serveur, à partir dudit second jeu de données d'authentification reçu et d'un second jeu de données de référence ; si ledit utilisateur a été authentifié par ledit serveur, établissement, par ledit équipement intermédiaire, d'une liaison de communication sécurisée entre ledit terminal et ledit serveur.
2. 2. Procédé selon la revendication 1, caractérisé en ce que, si ledit utilisateur n'a pas été authentifié par ledit équipement intermédiaire, ledit équipement intermédiaire effectue les étapes suivantes : transmission (E510) d'au moins une question prédéfinie par l'utilisateur vers ledit terminal ; réception (E511) d'au moins une réponse à ladite au moins une question en provenance dudit terminal ; établissement de ladite liaison de communication sécurisée, en fonction de ladite au moins une réponse reçue.
3. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ledit terminal effectue les étapes suivantes :obtention (E508) de données utilisateur propres audit utilisateur, via ladite liaison de communication sécurisée ; enregistrement (E509) desdites données utilisateur obtenues dans un moyen de stockage compris dans ledit terminal.
4. 4. Procédé selon la revendication 3, caractérisé en ce que l'étape d'obtention desdites données utilisateur comprend : une étape de transmission (E110) d'une demande d'obtention desdites données utilisateur par ledit terminal vers ledit équipement intermédiaire, via ladite liaison de communication sécurisée et selon un premier protocole de communication prédéterminé ; les étapes suivantes, effectuées par ledit équipement intermédiaire : traduction de ladite demande d'obtention en une requête se présentant sous une forme compréhensible par ledit serveur ; transmission (E120) de ladite requête vers ledit serveur, via ladite liaison de communication sécurisée et selon un second protocole de communication prédéterminé ; après exécution (E130) de ladite requête par ledit serveur , réception desdites données utilisateur via ladite liaison de communication sécurisée et selon ledit second protocole ; traduction desdites données utilisateur reçues sous une forme compréhensible par ledit terminal ; transmission desdites données utilisateur traduites vers ledit terminal, via ladite liaison de communication sécurisée et selon ledit premier protocole.
5. 5. Procédé selon la revendication 4, caractérisé en ce que ledit premier protocole appartient au groupe comprenant : un protocole HTTP ; un protocole I-ITTPS ; et un protocole SMPP.
6. 6. Procédé selon l'une quelconque des revendications 4 et 5, caractérisé en ce que ledit second protocole appartient au groupe comprenant :un protocole SOAP sur un protocole HTTPS ; un protocole HTTPS.
7. 7. Procédé selon l'une quelconque des revendications 3 à 6, caractérisé en ce que ledit terminal effectue les étapes suivantes : demande d'un code d'accès audit utilisateur ; obtention (E70) d'un code d'accès fourni par ledit utilisateur ; suppression (E90) desdites données utilisateur enregistrées, en fonction dudit code d'accès fourni et d'un code d'accès de référence.
8. 8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ledit premier jeu de données d'authentification comprend : - un identifiant associé audit utilisateur ; - un mot de passe ; et - un identifiant associé audit terminal.
9. 9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que ledit second jeu de données d'authentification comprend : - un numéro de compte bancaire ; et un code secret connu dudit utilisateur.
10. 10. Produit programme d'ordinateur, téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé d'accès selon l'une au moins des revendications 1 à 9, lorsque ledit programme est exécuté sur un ordinateur.
11. 11. Médium de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé d'accès selon l'une au moins des revendications 1 à 9.
12. 12. Système d'accès à un serveur de gestion de données utilisateur à partir d'un terminal de communication appartenant à un utilisateur, caractérisé en ce que 30 ledit système comprend un équipement intermédiaire comprenant : des moyens de réception d'un premier jeu de donnéesd'authentification propre audit utilisateur, en provenance dudit terminal ; des moyens d'authentification dudit utilisateur, à partir dudit premier jeu de données d'authentification reçu par lesdits moyens de réception 5 et d'un premier jeu de données de référence, en ce que ledit serveur comprend : des moyens de réception d'un second jeu de données d'authentification propre audit utilisateur, en provenance dudit terminal ; des moyens d'authentification dudit utilisateur, à partir dudit second 10 jeu de données d'authentification reçu par lesdits moyens de réception et d'un second jeu de données de référence, et en ce que ledit équipement intermédiaire comprend en outre des moyens d'établissement d'une liaison de communication sécurisée entre ledit terminal et ledit serveur, lesdits moyens d'établissement de ladite liaison de 15 communication sécurisée étant activés par lesdits moyens d'authentification dudit serveur.