FR2936888A1

FR2936888A1 - User data i.e. banking data, accessing method, involves establishing secured communication connection between user data management server and communication terminal if user is authenticated by server

Info

Publication number: FR2936888A1
Application number: FR0856695A
Authority: FR
Inventors: Sebastien Burlet
Original assignee: LEMON WAY
Current assignee: LEMON WAY
Priority date: 2008-10-02
Filing date: 2008-10-02
Publication date: 2010-04-09
Anticipated expiration: 2028-10-02
Also published as: FR2936888B1

Abstract

The method involves authenticating a user by an intermediate equipment e.g. banking gateway, from set of user authentication data and set of reference data. Another set of user authentication data is received by a user data management server from a communication terminal if the user is authenticated by the equipment. The user is authenticated by the server from the latter set of user authentication data and another set of reference data. A secured communication connection is established between the server and the terminal if the user is authenticated by the server. Independent claims are also included for the following: (1) a computer program product, downloaded from a communication network and stored on a computer readable medium, comprising instructions for executing an user data management server accessing method (2) a computer readable storage medium, totally or partially detachable, storing set of instructions for executing an user data management server accessing method (3) a system for accessing a user data management server from a communication terminal comprising a receiving unit.

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. Method for accessing and managing, from a terminal, bank data managed by a server, computer program product, storage medium, terminal, intermediate equipment and corresponding server. FIELD OF THE INVENTION The field of the invention is that of operations and remote banking transactions. More specifically, the invention relates to a technique for accessing and managing, from a terminal of a communication network, bank data managed by a banking server of an external network.

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). The invention applies in particular, but not exclusively, to the case where the terminal is a mobile terminal (for example of the J2ME compatible telephone type, Apple iPhone (registered trademark), Smartphone, PocketPC with a Microsoft Windows Mobile system (brand filed), Palm (registered trademark), Blackberry RIM (registered trademark), Google Android (trademark), etc.) of a radiocommunication network and where the banking servers are WEB servers of the Internet network. The radiocommunication network uses, for example, the GSM standard (for "Global System for Mobile Communications" in English), or an equivalent or concurrent standard such as DCS 1800 (for "Digital Cellular System at 1800 Mhz", in English), PCS 1900 (for "Personal Communication System at 1900 MHz" in English), DECT (for "Digital European Cordless Telecommunications" in English), GPRS (for "General Packet Radio Service" in English) or UTMS (for "Universal Mobile Telecommunication System" in English). English) or CDMA (for "Code Division Multiple Access").

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). It is clear, however, that the present invention also applies with a fixed terminal of a wired network (for example the switched telephone network) and / or with an external network other than the Internet network. Thus, the present invention can be applied, for example, to a digital television connected to the Internet network via a Freebox residential gateway (registered trademark).

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. In general terms, an external network is understood to mean an independent network of the access network that constitutes the communication network. This external network allows a bank to make banking data available, generally in the form of information bases or files, by means of banking servers (also subsequently called bank servers). In the above-mentioned particular case where the external network is the Internet network, the databases are WEB sites hosted by WEB servers. 2. Technological background Today, banking data management in a situation of mobility represents a strong demand from users. Numerous techniques for accessing and remotely managing bank data managed by a banking server are already known. In general, we seek in particular to reconcile at least some of the following objectives: - universality of access and management, any type of 2G / 3G radiocommunication terminal to be able to communicate with a bank server, so as to control the latter to carry out banking operations such as, for example: the consultation of the balance of the accounts (current account, young booklet, PEL, ...), the internal transfer, the external transfer from bank to bank, the purchase / sale of shares, payment of person to person by the use of a mobile account, etc. ; - simplicity of access and management, the user having to be able to perform these operations with a reduced number of operations, and each of these operations must be as easy as possible; - security of operations and in particular control of the identity of the user (to fight against fraud); - management of mobile terminal theft and fraud in general; simplicity and low cost of implementation. The disadvantages of the prior art are discussed below through the particular case where bank data managed by a remote WEB server (ie a bank server) is accessed by means of a micro-browser WAP 30 embedded in a mobile terminal. Typically, a WAP micro-browser, following interaction with a user, will send an encoded WAP request to a WAP gateway (WAP Gateway) which decodes it (by performing a protocol conversion between WAP (Wireless) Transaction Protocol) and the WEB (HTTP for HyperText Transfer Protocol and direct it to the correct WEB server.) In response, the WEB server sends the pages to the WAP gateway that converts between the WEB and the WAP and encodes the data. contained in these pages (in order to reduce their size) before sending them to the mobile terminal The WAP micro-browser of the mobile terminal decodes these pages, interprets them and displays them.

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. Although WAP technology has been an important advance in the remote management mechanism of bank data, this known technology nevertheless has a number of disadvantages. Indeed, the ergonomics of this known technique is limited by the fact that the user must first launch the WAP micro-browser embedded on the mobile terminal, then enter manually by means of an alphanumeric keyboard, usually small size, a URL (for Uniform Resource Locator, for example of the type: http://wap.creditmutuel.fr). In certain situations, and particularly when the user is traveling on a public transport (subway, bus, ...), entering such a URL can be difficult and time consuming. Another disadvantage of this known technique lies in the fact that it requires the creation of pages developed in WML (Wireless Markup Language), the only language used by micro-browsers WAP embedded on mobile phones. The WML language defines a number of basic instructions supported by all micro-browsers, but other functions depend on the type of micro-browser used. In other words, when creating a WAP site, developers must not only translate pages developed in HTML into WML, but must do so by taking into account the different types of existing micro-browsers. Creating a WAP site is therefore complex. To reduce this complexity, developers sometimes choose to develop WML pages only for certain types of micro-browsers. Thus, other WAP micro-browsers are unable to decode these pages, to interpret and display them, or do not take advantage of the optimal technical characteristics of recent mobile terminals.

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. Moreover, the inventors have found that in the event of a network loss, that is to say when the mobile terminal is no longer connected to the banking server via the radio communication network (this may for example occur when the user pass under a tunnel), the time to restore the connection to the banking server is relatively long. It should be noted that during this period of network loss, the user can not consult his banking data, and must sometimes restart the connection procedure from the beginning of the procedure, which is expensive and difficult in a mobile situation, with a small keyboard. 3. Objectives of the invention The invention, in at least one embodiment, is intended in particular to overcome these various disadvantages of the state of the art. More precisely, one of the objectives of the present invention, in at least one embodiment, is to provide a technique for accessing and managing bank data, from any mobile terminal, which is simple to implement and effective , especially in terms of speed of access to the bank server and fluidity of the man-machine interface. A complementary objective of the invention, in at least one of its embodiments, is to provide such a technique that eliminates the manual entry of URLs via the human / machine interface of the mobile terminal, allowing access the most direct and easy to use at his bank.

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. The invention also aims, in at least one embodiment, to provide such a technique that allows better security of access to banking data of a bank server, to fight against fraud and theft. Another object of the invention, in at least one of its embodiments, is to provide such a technique which is inexpensive and compatible with all existing banking servers.

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. At least one embodiment of the invention also aims to provide such a technique that allows a user to view all or part of his banking data, when his mobile terminal is disconnected from the communication network.

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. At least one embodiment of the invention also aims to provide such a technique that allows a user to view all or part of his bank data from his ADSL television, or from a mini Widget application (for example, an application for the Microsoft Windows Vista (registered trademark) office or for an Apple (registered trademark) Mac Dashboard) or Online Widget (for example a mini application for iGoogle (registered trademark) or Facebook (registered trademark)). 4. DESCRIPTION OF THE INVENTION In a particular embodiment of the invention, there is provided a method for accessing and managing, from a terminal of a communication network, bank data managed by a server. banking operations of an external network. According to the invention, the method comprises: a configuration phase comprising the following steps: recording by said terminal of reference access data provided by a user; o first negotiation between said terminal and said server; in the case of a first successful negotiation, reception by said terminal of bank data associated with said user, called user data, from said server; recording by said terminal of said user data, a usage phase comprising the following steps: reception by said terminal of current access data provided by the user; first authentication of the user by said terminal, from said current access data and said reference access data; o in case of first negative authentication, deleting said user data recorded by said terminal. Thus, the invention is based on a completely new and inventive approach to banking data management. Indeed, the invention proposes to store on the terminal all or part of the bank data associated with the user. Thus, in use and contrary to the techniques of the prior art (in particular WAP technology), the invention enables the user, in the event of a network loss (that is to say when the terminal is no longer connected to the communication network), to continue to consult his banking data (for example the balance of his bank accounts) and / or the last banking operations he has carried out.

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. In a particular embodiment, the bank data is stored on the terminal in an encrypted and / or compressed form. Furthermore, during the configuration phase, the user enters access data such as, for example, a four-digit PIN code via a man / machine interface (for example the terminal keyboard or a virtual keyboard). This PIN code is then stored on the terminal. According to the invention, during the use phase access to the bank data stored on the terminal is conditioned by the authentication of the user by the terminal. In other words, to access the bank data stored on the terminal the user must provide the terminal with the correct PIN code. In the case where the user is not successfully authenticated by the terminal (that is to say when the user has not entered the correct access data), the latter deletes all bank data. Thus, the invention makes it possible to maximize the confidentiality of banking data stored on the terminal, especially in the event of the theft of the terminal. According to an advantageous aspect of the invention, said phase of use comprises, in case of first positive authentication, a step of rendering by said terminal of said registered user data, as well as personalization data: logotype of the bank or the cash register Regional, personalized greetings, information about promotional products. Advantageously, said use phase further comprises, in case of first positive authentication, a second negotiation step between said terminal and said server. According to the invention, in the case of a successful second negotiation, the method comprises the following steps: the terminal sends to an intermediate device, via the communication network and according to a first communication protocol, at least one request for launching a banking operation on the server; the intermediate equipment translates said at least one request from the terminal into at least one request and transmits said at least one request to the server via the external network and according to a second communication protocol; the server receives and executes the said at least one request. Thus, all the intelligence and management logic are moved to the intermediate equipment (gateway), which makes the invention usable for any type of communication terminal and bank server, the latter not requiring therefore no complex and expensive adaptation to be compatible with the method according to the invention, which is particularly interesting.

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. According to a first advantageous embodiment of the invention, the first communication protocol belongs to the group comprising: an HTTPS protocol; - an HTTP protocol. Thus, by implementing an HTTPS (Hypertext Transfer Protocol over Secure Socket Layer) protocol, the security of the data exchanged between the terminal and the intermediate equipment is further improved. According to a second advantageous embodiment of the invention, the first communication protocol is an SMPP protocol. In this case, the method comprises the following steps: the terminal sends to a conversion gateway, via the communication network, said at least one launch request; the conversion gateway translates said at least one request from the terminal into at least one transformed launch request, in a form understandable by the intermediate equipment, and transmits said at least one transformed launch request to the intermediate equipment, via the communication network and according to an HTTPS protocol.

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. Thus, the invention enables a terminal implementing the SMPP (Short Message Peer-to-Peer Protocol) protocol to remotely and effectively manage bank data stored on a banking server, from SMS (Short). Message Service in English). To do this, the invention provides for the implementation of a conversion gateway between the terminal and the intermediate equipment. This conversion gateway makes it possible to convert between the SMS and the WEB. Preferably, said second communication protocol belongs to the group comprising: a SOAP protocol over an HTTPS protocol; an HTTPS protocol. Thus, by implementing a SOAP protocol over an HTTPS protocol, the security of the transit of bank data between the bank server and the intermediate equipment is further improved.

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. Advantageously, in the case where the execution of said at least one request results in the transmission of user data from the server to the intermediate equipment, the method further comprises the following steps: the intermediate equipment translates the user data transmitted by the server into transformed user data, in a form comprehensible by said terminal; the intermediate equipment transmits the transformed user data to said terminal; said terminal stores the transformed user data. In a particular embodiment, the intermediate equipment encrypts and compresses the bank data before transmitting them to the terminal. According to an advantageous aspect of the invention, the method further comprises the following steps: the intermediate equipment receives additional data from at least one additional data management equipment via the external network; the intermediate equipment enriches the user data transformed with said additional data, so as to transmit to said terminal enriched data. The additional data management equipment according to the invention is for example an advertisement server, a financial data server, an image server, an external system for managing bank transactions or payment of bills, etc. that is, a data server other than a bank data server. Thus, the invention proposes to transmit to the terminal advertising data, stock market data, etc., at the same time as the bank data, or to pay bills, or to send money in liquid form to the customer. by passing through the banking system ensuring traceability, or crediting a mobile account of a third person such as a supplier identified beforehand or to identify himself to receive his payment within a limited time; this identification can be performed for example on an internet system of a financial institution, or through a website. Advantageously, said terminal belongs to the group comprising: mobile terminals; - fixed terminals.

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. The invention therefore proposes a multi-channel solution, in that it enables any type of terminal to access and manage via any type of communication channel bank data managed by a banking server. Advantageously, said configuration phase further comprises a step of registration by the intermediate equipment of a question defined by the user and a response to said question provided by the user, called true answer. According to an advantageous aspect of the invention, each of said first and second negotiation steps comprises the following steps: reception by the intermediate equipment of a first set of current authentication data from said terminal; second authentication of the user by the intermediate equipment, from said first set of current authentication data; in the case of a second positive authentication, the server receives a second set of current authentication data from the intermediate equipment; the third authentication of the user by the server, from said second set of current authentication data; - In case of third positive authentication, establishment of a secure communication between said terminal and said server. The first and second reference authentication data sets are defined by the bank organization to which the bank server belongs, or may be generated by the gateway. Generally, the banking organization sends the user one or more mails including these reference authentication data sets. As will be seen in the remainder of the description, in a particular embodiment, the intermediate equipment implements a two-factor authentication mechanism, which makes it possible to improve the security of access to the banking server ( and therefore to the user's bank data). Preferably, each of the first and second sets of current authentication data comprises at least one item of information belonging to the group comprising: an identifier associated with the user; bank specific, or common to several financial institutions (eg OpenID) - a password; can be derived from a single table data cross-reference for each bank customer (simple naval battle-style table generated by the gateway) - a bank account number; a unique identifier number of each deployed application (TAG) providing an integrity check by crossing identification variables and a study of the behavior changes of the connection habits of the customers - an identifier associated with said 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. The invention covers a first case in which the identifier associated with the terminal is the IMEI (International Mobil Equipment Identity) identifier of the terminal. The invention covers a second case in which the identifier associated with the terminal is the identity number IMSI (for International Mobile Subscriber Identity in English) stored on the SIM card (for Subscriber Identity Module in English, identity module of subscriber in French) of the terminal. The invention covers a third case in which the identifier associated with the terminal is the telephone number of the 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. Advantageously, said second negotiation step used for example for transactions further comprises the following steps, in case of negative second authentication: the intermediate equipment sending said terminal said registered question; the intermediate equipment receives a current response from said terminal, said current response being provided by the user; the intermediate equipment compares said current response with said recorded true response; in the case of a positive comparison, the intermediate equipment sends said server said second set of current authentication data.

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. The invention therefore proposes to combine a two-factor authentication mechanism and an authentication mechanism with a secret question. In a particular embodiment, it is possible to consider limiting or prohibiting any banking operation (for example the purchase / sale of shares or the external transfer) when the user is not successfully authenticated by the authentication mechanism with secret question. According to an advantageous aspect of the invention, the exchanges between said terminal and the intermediate equipment are implemented by a software application, included in said terminal, and a vacuum cleaner of HTML pages (PARSER in English), included in the equipment. intermediate.

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. In another embodiment, the invention relates to a computer program product downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor, said computer program product comprising instructions program code for the implementation of the aforementioned method, when said program is executed on a computer.

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. In another embodiment, the invention relates to a storage medium, possibly completely or partially removable, readable by a computer, storing a set of instructions executable by said computer to implement the above method. In another embodiment, the invention relates to a communication terminal of the type that can be connected to a communication network. According to the invention, the terminal comprises: banking data storage means transmitted by a banking server of an external network; means for authenticating a user of the terminal, said first authentication means generating a control signal in the event of negative authentication; means for deleting the bank data stored in the storage means, said deletion means being activated by said control signal. In another embodiment, the invention relates to an intermediate device of the type that can communicate with a terminal, via a communication network, and with a banking server, via an external network. According to the invention, the intermediate equipment comprises: means for receiving at least one request for launching a banking operation on the server transmitted by the mobile terminal, via the communication network and according to a first protocol of communication; first means for translating said at least one request from the terminal into at least one request understandable by the server; first transmission means of said at least one request to the server, via the external network and according to a second communication protocol.

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. According to an advantageous aspect of the invention, the intermediate equipment comprises at least one of the following means: means for receiving bank data transmitted by the server, via the external network and according to the second communication protocol; second means for translating said bank data of the server into transformed bank data, in a form understandable by the terminal; second means for transmitting bank data transformed to the terminal, via the communication network and according to the first communication protocol; an HTML page vacuum compatible with the sites and secure infrastructures of the banks, particularly with regard to concatenations of invisible web pages. In another embodiment, the invention relates to a banking server of the type that can be connected. to an external network. According to the invention, the server comprises means for receiving and executing at least one request transmitted according to a second communication protocol by an intermediate device, via the external network, said request corresponding to the translation of a request for data transmission. a terminal received by the intermediate equipment, 20 via a communication network and according to a first communication protocol. 5. List of Figures Other features and advantages of embodiments of the invention will appear on reading the following description, given by way of indicative and nonlimiting example (not all embodiments of the invention). are not limited to the features and advantages of the embodiments described hereinafter), and the accompanying drawings, in which: FIG. 1 shows an example of a banking data access and management system according to a preferred embodiment of FIG. the invention; FIGS. 2a and 2b show flowcharts illustrating a particular embodiment of the method according to the invention, in the case where the terminal implements an HTTPS protocol; FIG. 3 shows the simplified structure of a particular embodiment of a banking server according to the invention; FIG. 4 shows the simplified structure of a particular embodiment of an intermediate device according to the invention; and FIG. 5 shows the simplified structure of a particular embodiment of a terminal according to the invention. 6. Detailed description It is recalled that the present invention proposes to define a technique of access to banking data in a mobility situation. As will be noted in all the figures of this document the elements and identical steps are designated by the same reference numeral.

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. For the sake of clarity, in all the figures of this document the means are referenced by numerical references (of the type 1, 2, 3, ...) and the process steps are referenced by alphanumeric references (of the type E1, E2 , E3, ...). The general principle of the invention rests on the implementation of two modes of access: a first access mode, called connected mode, in which a user can access a banking server and manage operations in real time; banking (bank transfer, account summary, details of transactions, purchase / resale of shares, etc.) from its communication terminal. This connected mode is implemented by the terminal when the latter is connected to a communication network (for example the GPRS network). The method according to the invention in particular involves an intermediate device (also called bank gateway later) accessible from the terminal via an external network (for example the Internet). According to such a method, all the intelligence of access and management of bank data (stored at the bank server level) is provided by the bank gateway. The banking server has only a role of slave vis-à-vis the bank gateway that plays the role of the master by transmitting to the bank server queries to execute. The mobile terminal is never directly in relation (that is to say, it does not communicate directly) with the bank server, but always through the bank gateway; a second mode of access, said unconnected mode, in which the user can view (offline) his bank data and / or the latest banking he has done. This non-connected mode is implemented by the terminal, for example, in the event of network loss. The unconnected mode of the invention relies on the storage of the user's bank data on the terminal in the form of encrypted and compressed files.

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. An example of a system according to the invention is now presented with reference to FIG. In this simplified example, the system comprises: a communication network 1 to which is connected a terminal 2 of a user. For the sake of simplification of the description, it will be limited, throughout the rest of this document, to describe the particular case where the terminal 2 is a mobile terminal (for example a smartphone) comprising a radiocommunication module conferring the ability to connect to the Internet via the GPRS network. The skilled person will easily extend this teaching to a mobile terminal of any other nature (for example a PocketPC, a PDA, an iPhone (registered trademark) of the company Apple, a Blackberry (registered trademark) of the company RIM,. ..) and equipped with any other type of radio communication module using the DATA or SMS channel (for example in accordance with the Edge, UMTS, ...), or a fixed terminal (for example a digital television connected to the Internet network via a residential gateway); the Internet network 3 (forming an external network) to which a bank gateway 4 and a bank server 5 are connected. According to the invention, in the case where a secure WEB service is implemented on the bank server side 5, the data exchanges between the bank bank gateway 4 and the bank server 5 are done according to a SOAP protocol on an HTTPS protocol or following the HTTPS protocol (only). The data exchanged are in XML (eXtensible Markup Language) format. According to the invention, in the case where no secure WEB service is implemented on the bank server side 5, the bank gateway 4 implements a HTML pages (HTML Parsing). Suction techniques of HTML pages are well known to those skilled in the art. They will not be described in more detail in the present description. In the remainder of this document, one places oneself in the case where the exchanges of data between the bank gateway 4 and the bank server 5 are done according to the SOAP protocol on the HTTPS protocol. FIGS. 2a and 2b show a first exemplary embodiment in which a user remotely accesses bank data managed by a banking server from a mobile terminal implementing an HTTPS protocol. As illustrated by FIG. 2a, a configuration phase El is implemented when the user first launches the on-board software application containing the program code instructions for implementing the method according to the invention. The configuration phase E1 comprises a first step E10 during which the user enters via the terminal's human / machine interface (hereinafter referred to as HMI) reference access data, in response to a request from the terminal . For example, it is assumed that at this step E10 the user enters a code of 4 digits. During a step E20, the terminal stores the 4-digit code in an encrypted form, the result of a serialization of several encoding algorithms. During a step E30, the user enters via the terminal's HMI. a question and the answer to the said question, in response to a request from the terminal. During a step E40, the terminal transmits, using the HTTPS protocol, the question and the answer to the question to the bank gateway. The bank gateway receives and records the question and the answer to the question. In a particular embodiment, the question and the response are encrypted and compressed by the terminal before sending. The following substeps relate to a first negotiation step E50 between the terminal and the bank server. This first negotiation step makes it possible to establish a secure communication between the terminal and the banking server. During a substep E501, the user enters via the HMI of the terminal a username and a password, in response to a request from the terminal. During a substep E502, the terminal transmits, using the HTTPS protocol, a first set of data (called the first set of current authentication data) to the bank gateway. According to a particular embodiment of the invention, the first set of current authentication data comprises the user name and the password (entered in the substep E501), as well as an identifier associated with the terminal. As an example, it is considered for the following that the identifier included in the first set of current authentication data is the IMSI identity number stored on the SIM card of the terminal. According to an advantageous aspect of the invention, the first set of current authentication data is encrypted and compressed by the terminal before sending. The encoding techniques used are Triple DES, bit offsets, ZIP compression at base 64 and encryption, or MD5. The techniques of One Time Password are also used, as well as the known techniques of challenge-response algorithm, according to the literature in this area. During a substep E503, the bank gateway implements a first authentication mechanism for authenticating the user and the terminal. More specifically, the bank gateway maintains a table of first reference authentication data sets each comprising: an IMSI identity number, a username and a password. At this substep E503, the bank gateway checks in its table whether the first set of current authentication data corresponds to one of the first reference authentication data sets. If the first set of current authentication data is known to the bank gateway (i.e., in the case of positive authentication), then one goes on to a substep E504, otherwise (ie say in case of negative authentication) we go to a substep E510. It is noted that a negative authentication may, for example, take place if the user enters an incorrect password or, for example, if the terminal transmits an incorrect IMSI identity number (such a situation may occur if the user uses the SIM card of another person). In the substep E504, the user enters via the terminal's HMI a bank account number and a personal code (for example composed of 6 digits), in response to a request from the terminal. During a substep E505, the terminal transmits, using the HTTPS protocol, a second set of data (called the second set of current authentication data) to the bank gateway. The second common authentication data set includes the bank account number and personal code (entered in substep E504). The bank gateway then transmits, using the SOAP protocol over the HTTPS protocol, the second set of current authentication data to the bank server. During a substep E506, the bank server implements a second authentication mechanism for authenticating the user. More specifically, the banking server maintains a table of second reference authentication data sets each comprising: a bank account number and a personal code. At this substep E506, the bank server checks in its table whether the second current authentication data set corresponds to one of the second reference authentication data sets. If the second set of current authentication data is known to the banking server (that is, in the case of positive authentication) (in other words, if the user is authenticated as a customer of the bank to which the bank server belongs), then we go to a substep E507, otherwise (that is to say, in case of negative authentication) we go to a substep E513. In an alternative embodiment, it is possible to consider incrementing a counter each time the user is not authenticated by the bank server, so that: - if the counter has not reached a number N predetermined (with N> _1), then we return to the substep E504; - If the counter has reached the predetermined number N, then we go to the substep E513. In the substep E507, secure communication is established between the terminal and the bank server. In this same sub-step E507, the bank server transmits, using the SOAP protocol over the HTTPS protocol, the bank data of the user (current account statements, securities portfolios, etc.) to the bank gateway. The bank gateway translates the bank data transmitted by the bank server into transformed bank data, presenting itself in a form comprehensible to the terminal. In the exemplary embodiment illustrated, the bank gateway encrypts and compresses the bank data before sending to the 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. The flows between the intermediate system and the bank servers are typically https encrypted streams using a virtual private channel. During a substep E508, the bank gateway transmits, using the HTTPS protocol, the encrypted and compressed banking data to the terminal. In a substep E509, the terminal receives and stores the encrypted and compressed banking data, then decompresses and decrypts them so as to restore them (on its display screen) in a form readable by the user. In the substep E510 (in case of negative authentication of the user by the bank gateway), the bank gateway transmits, using the HTTPS protocol, the question recorded in step E40 to the terminal. During a substep E511, the user enters via the HMI of the terminal a response to the question (called current response). The terminal then transmits, using the HTTPS protocol, the current response to the bank gateway. During a substep E512, the bank gateway compares the current response and the response recorded in step E40. If the current response is the same as the recorded response, then proceed to substep E504, otherwise proceed to substep E513. During the substep E513, the terminal displays on its screen an error message. As will be noted, certain steps in FIG. 2b are identical (same alphanumeric references) to certain steps previously described in FIG. 2a. These common steps (E501 to E505 and E510 to E513) are not described again below. As illustrated by FIG. 2b, a use phase E2 is implemented: when the user restarts the software application embedded on the terminal. In this first case, the use phase E2 begins at step E60 described below; or when the user uses his terminal to carry out banking operations immediately after the configuration phase El (described in FIG. 2a). In this second case, the use phase E2 starts at the step E100 described below. In step E60, the user enters via the HMI of the terminal a current 4-digit code (also called current access data), in response to a request from the 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. During a step E70, the terminal compares the current code entered in step E60 and the code recorded in step E20. If the current code is identical to the registered code, then we go to a step E80, otherwise we go to a step E90. In a particular embodiment, the terminal can display on its screen the bank data recorded in step E509, in sign of positive authentication of the user by the terminal. In step E90, the terminal deletes all bank data recorded in step E509. In a particular embodiment, after deleting the bank data, no message is displayed on the screen of the terminal. In an alternative embodiment, it is also possible to envisage that after deletion of the banking data the terminal generates false banking data. Thus, in case of the theft of the terminal, the thief accesses false banking data of a demo account. In step E80 (also hereinafter referred to as the second negotiation step), the substeps E501 are implemented. to E505 and E510 to E513 previously described with reference to Figure 2a. For the sake of simplification of the description, only the steps that do not appear in FIG. 2a are described below. During a substep E806, the bank server checks whether the second current authentication data set (entered by the user in the substep E504) corresponds to one of the second authentication data sets of reference (included in the table stored by the banking server). If the second set of current authentication data is known to the bank server, then we go to step E10, otherwise we go to substep E513. For the sake of simplification of the description, it will be limited in the following description to describe the particular case where the user makes a transfer from account to account. The skilled person will easily extend this teaching to any other type of banking transaction. During the step E100, the user selects in the menu of the application (displayed on the terminal screen) the icon corresponding to the bank transfer operation. The user enters via the terminal's HMI bank transfer data such as, for example, a recipient account number and a sum of money to be transferred from the user's account (entered in substep E504). to the receiving account (IBAN), as well as a wording and a date of execution. During a step E110, the terminal transmits, using the HTTPS protocol, a request to launch a bank transfer transaction to the bank gateway. Note that the launch request conveys the bank transfer data in encrypted and compressed form. During a step E120, the bank gateway translates the terminal request into a bank transfer execution request, in a form understandable by the bank server. The bank gateway then transmits, using the SOAP protocol over the HTTPS protocol, the execution request to the bank server compatible with a service-oriented architecture (SOA). During a step E130, the bank server executes the request. In this step E130, the bank server transfers the amount of money defined by the user in step E100 from his bank account to the destination account specified by the user in step E100. After execution of the request, the bank server sends the terminal a confirmation of transfer via the bank gateway, possibly doubling the sending of a confirmation SMS. Upon receipt of the confirmation message, the terminal records the bank transfer data (recipient account number, amount of money transferred, date of transfer, ...) in the form of an encrypted and compressed file, or encrypted data stored in a file. partitioned memory space. It is recalled that the recording on the terminal of banking data and banking operations in the form of encrypted and compressed files is an important aspect of the implementation of the invention. Indeed, in use when the terminal loses the connection to the communication network (for example in the case where the user traveling in a train passes under a tunnel), the user can continue to consult his bank data (c). 'ie those registered on the terminal), and if necessary, start preparing its next banking transactions, or to point his writings to make a bank reconciliation with his tickets and stubs of checks. These will be sent to the bank server as soon as the connection to the communication network is reestablished, subject to a time limit for restoration of the connection configurable by the intermediate system.

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 As illustrated in FIG. 1, in the case where the terminal 2 implements a SMPP protocol conferring on it the capacity to transmit SMS messages, the system according to the invention implements a conversion gateway 6 between the terminal 2 and the terminal. bank gateway 4. The conversion gateway 6 performs the conversion between the SMS and the WEB. In other words, the conversion gateway 6 translates the different data transmitted from the terminal (for example the first and second sets of current authentication data, the transfer requests, etc.) into transformed data, which are presented under a form understandable by the bank gateway 4. The conversion gateway 6 transmits, using the HTTPS protocol, the data transformed to the bank gateway 4. In other words, the customers of a bank not having a fixed price data, but only a voice and SMS package, can still be users of the system. In a particular embodiment, the bank gateway 4 may also be connected to one or more additional data management equipment (not shown) such as, for example, advertising data servers, financial data servers, etc. The bank gateway can therefore enrich the data returned to the terminal with advertising data, financial data, etc. Thus, according to an advantageous aspect of the invention, the user can receive in real time the stock market prices on his mobile terminal and simply and effectively place buy / sell orders from his terminal, or send money to a loved one, by storing only the recipient's mobile phone number. FIG. 3 shows the simplified structure of a bank server 5 according to the invention, which comprises a memory 52, and a processing unit 51 equipped with a microprocessor ptP, which is controlled by a computer program (or application) 53 implementing certain steps of the method according to the invention (described in Figures 2a and 2b). The processing unit 51 receives as input a request 54 relating to a request to launch a banking operation on the bank server 5. The microprocessor ptP processes this request, according to the instructions of the program 53 so that depending on the nature of the request the bank server transmits (using, for example, the SOAP protocol over the HTTPS protocol) to a bank gateway 4 bank data 55 of a user or a bank transaction execution confirmation message 56. FIG. 4 shows the simplified structure of a bank gateway 4 (also hereinafter referred to as intermediate equipment) according to the invention, which comprises a memory 42, and a processing unit 41 equipped with a microprocessor ptP, which is controlled by a computer program (or application) 43 implementing certain steps of the method according to the invention (described in Figures 2a and 2b). The processing unit 41 receives as input a request for launch 44 of a banking operation on the bank server 5 described in FIG. 3. The microprocessor ptP processes this request, according to the instructions of the program 43, to generate an executable request 54 5. Finally, FIG. 5 shows the simplified structure of a communication terminal 2 according to the invention, which comprises a memory 22 comprising encrypted and compressed bank data, and a processing unit 21 equipped with a ptP microprocessor, which is controlled by a computer program (or application) 23 implementing certain steps of the method according to the invention (described in Figures 2a and 2b). The processing unit 21 receives as input routine access data 24 provided by a user. The microprocessor ptP processes these current access data, according to the instructions of the program 23. More specifically, the microprocessor ptP compares the current access data and reference access data (for example stored in the memory 22 or in a memory card). other memory of the terminal), so that depending on the result of the comparison the terminal deletes or restores on its display screen the bank data 25 stored in the memory 22.25

Claims

REVENDICATIONS1. Method for accessing a management server (5) of user data from a communication terminal (2) belonging to a user, characterized in that it comprises the following steps: reception (E502) by a device intermediate, a first set of authentication data specific to said user, from said terminal; authenticating (E503) said user by said intermediate equipment from said first set of received authentication data and a first set of reference data; if said user has been authenticated by said intermediate equipment, receiving (E505), by said server, a second set of authentication data specific to said user, from said terminal; authenticating (E506) said user by said server from said second set of received authentication data and a second set of reference data; if said user has been authenticated by said server, establishing, by said intermediate equipment, a secure communication link between said terminal and said server.

2. Method according to claim 1, characterized in that, if said user has not been authenticated by said intermediate equipment, said intermediate equipment performs the following steps: transmission (E510) of at least one predefined question by the user to said terminal; receiving (E511) at least one response to said at least one question from said terminal; establishment of said secure communication link, according to said at least one received response.

3. Method according to any one of claims 1 and 2, characterized in that said terminal performs the following steps: obtaining (E508) user specific data to said user, via said secure communication link; recording (E509) said user data obtained in storage means included in said terminal.

4. Method according to claim 3, characterized in that the step of obtaining said user data comprises: a step of transmitting (E110) a request for obtaining said user data by said terminal to said intermediate equipment, via said secure communication link and according to a first predetermined communication protocol; the following steps, performed by said intermediate equipment: translation of said obtaining request into a request in a form understandable by said server; transmitting (E120) said request to said server via said secure communication link and according to a second predetermined communication protocol; after execution (E130) of said request by said server, receiving said user data via said secure communication link and according to said second protocol; translating said received user data in a form understandable by said terminal; transmission of said user data translated to said terminal, via said secure communication link and according to said first protocol.

5. Method according to claim 4, characterized in that said first protocol belongs to the group comprising: an HTTP protocol; an I-ITTPS protocol; and an SMPP protocol.

6. Method according to any one of claims 4 and 5, characterized in that said second protocol belongs to the group comprising: a SOAP protocol on an HTTPS protocol; an HTTPS protocol.

7. Method according to any one of claims 3 to 6, characterized in that said terminal performs the following steps: request an access code to said user; obtaining (E70) an access code provided by said user; removing (E90) said stored user data according to said provided access code and a reference access code.

8. Method according to any one of claims 1 to 7, characterized in that said first set of authentication data comprises: an identifier associated with said user; - a password ; and an identifier associated with said terminal.

9. Method according to any one of claims 1 to 8, characterized in that said second set of authentication data comprises: - a bank account number; and a known secret code of said user.

10. Computer program product, downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor, characterized in that it comprises program code instructions for the implementation the access method according to at least one of claims 1 to 9, when said program is run on a computer.

11. Storage medium, possibly completely or partially removable, readable by a computer, storing a set of instructions executable by said computer to implement the access method according to at least one of claims 1 to 9.

12. System for accessing a user data management server from a communication terminal belonging to a user, characterized in that said system comprises an intermediate device comprising: means for receiving a first set of authentication data specific to said user, from said terminal; authentication means of said user, from said first set of authentication data received by said receiving means 5 and a first set of reference data, in that said server comprises: reception means of a second set of authentication data specific to said user, from said terminal; authentication means of said user, from said second set of authentication data received by said receiving means and a second set of reference data, and in that said intermediate equipment further comprises means for establishment of a secure communication link between said terminal and said server, said means for establishing said secure communication link being activated by said authentication means of said server.