FR 2855708 A1 20041203 FR 0306440 A 20030527 La présente invention concerne, de façon générale, le domaine des télécommunications. Plus précisément, l'invention concerne, selon un premier de ses aspects, un système pour utiliser un 5 réseau de téléphonie mobile à l'aide d'une première entité prévue pour stocker des données de valeur correspondant à du temps de communication sur le réseau, la première entité étant associée à un code identifiant un moyen terminal d'utilisateur appartenant au réseau, 10 par l'intermédiaire d'une relation pré-établie entre un opérateur du réseau et l'utilisateur du moyen terminal, ce système comprenant un serveur de gestion hébergeant une première base de données pour enregistrer les données concernant au moins la première entité. Ainsi, le système de l'invention trouve une application bien particulière pour l'utilisation d'un réseau de téléphonie mobile, o la relation préétablie entre l'opérateur et l'utilisateur est matérialisée par la première entité qui peut par exemple être un compte 20 prépayé, destiné à permettre l'utilisation du réseau de téléphonie mobile de l'opérateur de télécommunication auprès duquel l'utilisateur est inscrit. De tels comptes utilisateurs sont maintenant couramment utilisés pour permettre l'accès sans 25 abonnement par l'intermédiaire d'un téléphone mobile à un réseau de téléphonie mobile d'un opérateur. Ces comptes utilisateurs o sont stockées des unités téléphoniques correspondant à du temps de communication sur le réseau, permettent ainsi de passer des appels prépayés et/ou 30 d'accéder à divers services proposés par l'opérateur. Le compte est alors associé au numéro d'une carte SIM (pour Subscriber Identity Module en anglais) du réseau de l'opérateur, insérée dans le téléphone mobile de l'utilisateur. L'utilisateur peut ainsi facilement contrôler le montant de ses communications. Cependant, la contrainte à prendre en compte par rapport à un système avec abonnement, est que 5 l'utilisateur doit recharger son compte lorsque son crédit est épuisé, de façon à obtenir des unités téléphoniques correspondant à du temps de communication, pour pouvoir utiliser le réseau de l'opérateur. Différentes techniques sont aujourd'hui disponibles 10 pour permettre d'utiliser un réseau de téléphonie mobile dans le cadre d'une relation pré-établie entre l'utilisateur final et l'opérateur du réseau et pour recharger un compte prépayé pour téléphone mobile, la plus courante étant la distribution par l'opérateur de 15 cartes à gratter sur lesquelles sont inscrits des codes d'identification, recouverts par une surface opaque destinée à être retirée. L'utilisateur achète alors la carte pour un montant déterminé auprès d'un revendeur commerçant, gratte la surface opaque de façon à dévoiler 20 le code d'identification et téléphone à l'opérateur pour le lui communiquer. L'opérateur vérifie la validité du code et, en cas de réussite de cette opération d'authentification, recharge le compte prépayé du montant associé au code d'identification de la carte. L'inconvénient de cette méthode côté utilisateur est que ce dernier doit acquérir un support physique, à savoir une carte à gratter, et transmettre lui-même le code à l'opérateur pour effectuer le rechargement de son compte. Un autre inconvénient concerne la distribution 30 des cartes à gratter qui s'effectue par l'intermédiaire de points de revente statiques. Cette méthode connue basée sur l'utilisation de cartes à gratter est donc relativement inconfortable et entraîne un manque de flexibilité pour l'utilisateur dans la gestion de son compte prépayé. De plus, côté opérateur, l'utilisation d'une carte à gratter pour l'accès à son réseau implique un certain 5 nombre d'opérations contraignantes, parmi lesquelles la fabrication de la carte avec association d'un code d'identification, la mémorisation du code d'identification dans un serveur informatique d'authentification, la distribution et la vente de la 10 carte, etc. . . Toutes ces opérations entraînent des coûts opérationnels élevés pour l'opérateur. Egalement, l'opérateur n'est pas informé en temps réel de l'achat d'une carte à gratter par un client. L'opérateur ne dispose ainsi d'aucun moyen véritable pour 15 estimer en temps réel le stock de cartes à gratter des différents revendeurs et pour tenir un historique des transactions effectuées entre les clients et les revendeurs de cartes à gratter. Ainsi, cette méthode utilisant des cartes à gratter apparaît très mal adaptée 20 à une gestion efficace par l'opérateur du rechargement des comptes prépayés de ses clients. La présente invention, qui se fonde sur ces différents constats, a pour but de pallier les inconvénients précités liés à l'utilisation des cartes à 25 gratter, aussi bien côté client, utilisateur final du réseau, que côté opérateur. Avec cet objectif en vue, l'invention vise plus particulièrement à mettre en oeuvre un système répondant au besoin, aujourd'hui non satisfait, de plus de 30 souplesse et de simplicité, pour l'utilisation d'un réseau de téléphonie mobile dans le cadre d'une relation pré-établie entre l'utilisateur final et l'opérateur du réseau, qui permette à l'utilisateur d'utiliser le réseau mobile de l'opérateur sans avoir d'abonnement, ni de cartes quelconques pour y accéder. A cette fin, le système de l'invention, par ailleurs conforme à la définition générique qu'en donne le 5 préambule ci-dessus, est essentiellement caractérisé en ce que le serveur héberge une seconde base de données pour enregistrer des données concernant au moins une seconde entité, prévue pour stocker des données de valeur correspondant à du temps de communication sur le réseau, 10 ladite seconde entité étant affectée à un fournisseur de temps de communication, ledit système comprenant une transmission, par l'intermédiaire d'une application sécurisée depuis un appareil de communication du fournisseur vers le serveur, d'une requête de transfert 15 incluant au moins le code associé à la première entité, un identifiant du fournisseur et une donnée de valeur déterminée, l'opération de transfert étant effectuée par le serveur de gestion à la réception de la requête par l'intermédiaire de moyens de gestion de la seconde base 20 de données permettant de diminuer les données de valeur de la seconde entité en fonction de la donnée de valeur déterminée et par l'intermédiaire de moyens de gestion de la première base de données permettant d'augmenter les données de valeur de la première entité en fonction de la 25 donnée de valeur déterminée. Concrètement, l'opérateur doit donc disposer d'un réseau de fournisseurs de temps de communication sur le réseau, qui lui achètent en gros des unités téléphoniques correspondant à du temps de communication pour utiliser 30 le réseau, pour les revendre au détail aux clients finaux sans avoir de support physique à gérer. La seconde entité est alors constituée, par exemple, d'un compte fournisseur auprès de l'opérateur, o sont stockées des unités téléphoniques achetées par le fournisseur à l'opérateur. L'utilisateur final doit au préalable avoir été enregistré dans le réseau de l'opérateur grâce à l'achat 5 d'une carte SIM du réseau de l'opérateur, permettant de l'identifier dans le réseau. Selon une caractéristique de l'invention, le moyen terminal de l'utilisateur est un téléphone mobile et, dans un mode de réalisation avantageux de l'invention, 10 le code associé à la première entité inclus dans la requête de transfert comprend le numéro de mobile de l'utilisateur. Dans un mode de mise en oeuvre du système de l'invention, l'application sécurisée est une application 15 du type infrastructure à clé publique permettant au fournisseur de signer la requête transmise pour s'authentifier auprès du serveur. Dans une variante, l'appareil de communication du fournisseur est un téléphone mobile, l'application 20 sécurisée étant hébergée par une carte SIM insérée dans le téléphone mobile du fournisseur. Avantageusement, l'identifiant du fournisseur inclus dans la requête de transfert comprend le numéro de mobile du fournisseur. De préférence, la requête transmise au serveur est signée par la saisie d'un code confidentiel sur le téléphone mobile du fournisseur. Avantageusement, le code confidentiel utilisé pour la signature est différent du code confidentiel utilisé 30 pour débloquer le téléphone. De préférence, le serveur de gestion, à la réception de la requête signée par le fournisseur, vérifie la signature par l'intermédiaire de moyens d'authentification, de sorte à confirmer ou infirmer la transmission de la requête et, dans le cas o la transmission est confirmée, effectue l'opération de transfert. Selon une variante possible de l'invention, 5 préalablement à la transmission sécurisée de la requête de transfert par l'intermédiaire de l'application sécurisée, le système comprend une transmission, depuis l'appareil de communication du fournisseur vers des moyens de vérification du serveur, des informations 10 constituant la requête de transfert pour une vérification préalable en temps réel de ces informations par le serveur et, après validation des informations constituant la requête de transfert, l'émission par le serveur d'une demande d'authentification à destination du fournisseur, 15 de sorte à initier la transmission sécurisée de la requête de transfert par l'intermédiaire de l'application sécurisée. Dans un mode de réalisation, le fournisseur se connecte au serveur en mode vocal au moyen de son 20 appareil de communication par l'intermédiaire d'un numéro de téléphone de service et transmet les informations constituant la requête de transfert aux moyens de vérification du serveur en tapant sur l'appareil de communication le code associé à la première entité, 25 l'identifiant fournisseur et la donnée de valeur déterminée. Dans un autre mode de réalisation, le fournisseur transmet les informations constituant la requête de transfert aux moyens de vérification du serveur par 30 l'intermédiaire d'un message numérique libellé suivant un format prédétermine. De préférence, la vérification des informations constituant la requête de transfert par les moyens de vérification du serveur consiste à vérifier que le code associé à la première entité transmis correspond à un utilisateur appartenant au réseau selon la relation préétablie. Avantageusement, parallèlement à vérification des 5 informations constituant la requête de transfert, le serveur envoie à destination du fournisseur, un message demandant des informations commerciales se rapportant à l'utilisateur, permettant une mise à jour de la première base de données. Selon ce mode de réalisation, le serveur de gestion comprend des moyens de mise à jour de la première base de données avec des informations commerciales relatives aux utilisateurs. Dans une variante, le système comprend l'émission 15 par le serveur de gestion d'une confirmation du transfert à destination du fournisseur et de l'utilisateur. De préférence, la confirmation est envoyée par l'intermédiaire d'un message numérique libellé suivant un format prédéterminé. Le réseau de téléphonie mobile utilisé pour la mise en oeuvre de l'invention est par exemple constitué par un réseau GSM, le message numérique étant alors de préférence constitué par un message court de service SMS. Comme le sait bien l'homme de métier, l'acronyme GSM 25 dérive de l'expression anglo-saxonne " Global System for Mobile communications " et constitue l'appellation internationale d'un système de téléphonie radio cellulaire numérique répondant à la norme elle-même dite " GSM ". L'acronyme SMS dérive quant à lui de l'expression anglo-saxonne " Short Message Service " et désigne, dans la norme GSM, un service bidirectionnel de messages courts. Néanmoins, la référence faite dans la présente description à un réseau GSM doit être considérée comme incluant la référence à un réseau UMTS, à un réseau GPRS, et à tout réseau téléphonique dans lequel une relation 5 pré-établie entre l'opérateur et un utilisateur final basée sur un compte prépayé peut être mise en oeuvre pour l'utilisation de ce réseau. Le système de l'invention présente de nombreux avantages, qui peuvent être mis en évidence sur une 10 application au rechargement d'un compte prépayé pour téléphone mobile. Notamment, ce système permet à l'opérateur de suivre avec précision l'évolution des comptes utilisateurs et des comptes fournisseurs et ainsi d'améliorer les 15 contrôles. Le système permet également d'assurer le lien avec le serveur de gestion de l'opérateur pour autoriser ou interdire très simplement les accès au réseau de téléphonie mobile. Le système de l'invention facilite également le 20 rechargement de son compte par l'utilisateur, puisqu'il permet de se passer de tout support physique. Ce système permet ainsi de supprimer un certain nombre de tâches matérielles génératrices de coûts pour l'opérateur, qui sont indispensables à la mise en oeuvre des méthodes de 25 rechargement d'un compte prépayé pour mobile actuelles basées sur l'utilisation de cartes à gratter. D'autres caractéristiques et avantages de l'invention ressortiront plus clairement de la description qui est faite ci-après, à titre indicatif et 30 nullement limitatif, en référence aux figures suivantes dans lesquelles: - la figure 1 représente de façon schématique et symbolique les principaux acteurs et les principales opérations mis en oeuvre dans le système de l'invention, présenté dans son application au rechargement d'un compte prépayé pour téléphone mobile, et - la figure 2 représente de façon schématique l'architecture du serveur de gestion mis en oeuvre dans le cadre du système selon la présente invention. Comme annoncé précédemment, l'invention concerne un système permettant à un utilisateur d'utiliser un réseau de téléphonie mobile à l'aide d'une première entité, en l'occurrence un compte prépayé utilisateur K_UTIL. Ce 10 compte utilisateur est prévu pour stocker des données de valeur correspondant à du temps de communication sur le réseau. L'utilisateur dispose d'un moyen terminal pour accéder au réseau, typiquement un téléphone mobile EMT et 15 doit au préalable avoir été enregistré auprès d'un opérateur du réseau grâce à l'achat d'une carte SIM du réseau de l'opérateur, destinée à être insérée dans son téléphone mobile. Le compte prépayé utilisateur K_UTIL est en fait associé à un code IDENT, identifiant le 20 téléphone mobile de l'utilisateur, par l'intermédiaire d'une relation pré-établie PREPM entre un opérateur du réseau de téléphonie mobile et l'utilisateur. Ce code IDENT peut par exemple être constitué par le numéro de la carte SIM du téléphone mobile EMT, ou par le numéro de 25 mobile MSISDN de l'utilisateur (acronyme pour l'expression anglo-saxonne "Mobile Station international ISDN number"), ou par tout autre code préalablement agréé, enregistré et accepté par le réseau. Selon l'invention, l'opérateur doit disposer d'un 30 réseau de fournisseurs de temps de communication sur le réseau, qui lui achètent en gros des unités téléphoniques correspondant à du temps de communication pour utiliser le réseau, pour les revendre au détail aux utilisateurs finaux. Chaque fournisseur FOURN agréé par l'opérateur pour vendre des unités téléphoniques dispose donc d'un compte fournisseur K_FOURN auprès de celui-ci pour stocker des données de valeur correspondant à du temps de communication sur le réseau. Un serveur de gestion SERV appartenant au réseau de téléphonie mobile héberge une première base de données DB_UTIL pour enregistrer les données concernant les différents comptes prépayés utilisateur et une seconde base de données DBFOURN pour enregistrer les données 10 concernant les différents comptes fournisseurs. Dans un mode de réalisation de l'invention pour l'application au rechargement d'un compte prépayé, un utilisateur s'adresse à un fournisseur agréé par l'opérateur du réseau auprès duquel l'utilisateur est 15 inscrit, pour lui acheter des unités téléphoniques correspondant à du temps de communication sur le réseau. Pour ce faire, l'utilisateur, ou toute autre personne, par exemple un ami ou un parent de l'utilisateur, disposant du code IDENT associé au compte 20 prépayé de l'utilisateur, à savoir du numéro MSISDN de mobile de l'utilisateur et souhaitant recharger le compte prépayé de l'utilisateur, prend contact avec un fournisseur et lui demande de recharger le compte prépayé de l'utilisateur pour un montant déterminé D_VAL 25 correspondant à l'achat d'une durée de communication spécifique sur le réseau. Après paiement de l'utilisateur ou de ladite personne par un moyen quelconque, le fournisseur va transmettre au serveur de gestion de l'opérateur les informations nécessaires au rechargement 30 du compte prépayé de l'utilisateur. Le système comprend alors la transmission, par l'intermédiaire d'une application sécurisée dédiée au rechargement SIGN, depuis un appareil de communication TERMFOURN du fournisseur vers le serveur SERV, d'une requête de transfert RQT_TRSF incluant les informations de rechargement, en l'occurrence au moins le code IDENT associé au compte prépayé utilisateur permettant d'identifier le téléphone mobile de l'utilisateur, la 5 donnée de valeur déterminée DVAL, ainsi qu'un identifiant du fournisseur ID_F. L'appareil de communication du fournisseur est constitué par un téléphone mobile et l'application sécurisée dédiée au rechargement d'un compte prépayé 10 utilisateur est hébergée par une carte SIM du réseau de l'opérateur insérée dans le téléphone mobile du fournisseur. Grâce à cette caractéristique, les points de revente d'unités téléphoniques permettant d'utiliser le réseau ne sont plus statiques vis-à-vis de l'utilisateur. 15 L'identifiant du fournisseur est de préférence constitué par le numéro de mobile MSISDN du fournisseur. Le fournisseur rentre tout d'abord dans l'application sécurisée lui permettant de transmettre les informations de rechargement au serveur. Il saisit alors 20 le numéro de mobile MSISDN IDENT de l'utilisateur ainsi que le montant à recharger D_VAL sur le compte utilisateur KUTIL, par l'intermédiaire du clavier de son téléphone mobile. L'application sécurisée SIGN installée sur la carte 25 SIM du fournisseur est une application du type infrastructure à clé publique permettant de signer les transactions effectuées pour l'authentification du fournisseur auprès du serveur de gestion. Ainsi, une clé de signature ou clé privée est installée sur la carte SIM 30 du fournisseur et seul le fournisseur connaît cette clé. A cette clé privée est associée une clé publique que le serveur connaît et qu'il utilise pour vérifier la signature. Le fournisseur, après avoir rentré les informations de rechargement IDENT et D_VAL constituant la requête de transfert, va donc signer cette requête par l'utilisation d'un code confidentiel. Ce code 5 confidentiel est choisi de préférence différent de celui utilisé pour débloquer le téléphone. Un message comportant la requête signée est alors transmis par l'intermédiaire de l'application sécurisée à destination du serveur de gestion SERV.L'identifiant du 10 fournisseur ID_F apparaît alors automatiquement en entête du message, typiquement un message court de service SMS, comportant la requête signée. Le serveur comprend des moyens d'authentification M_AUTH disposant de la clé publique associée à la clé privée utilisée par le 15 fournisseur pour signer la requête, de façon à vérifier la signature. Les moyens d'authentification du serveur permettent donc de confirmer ou d'infirmer la transmission de la requête de transfert et, dans le cas o la transmission est confirmée, le serveur effectue 20 l'opération de transfert et recharge le compte prépayé utilisateur K_UTIL du montant déterminé. Ainsi, le compte fournisseur K_FOURN est débité du montant déterminé et le compte utilisateur K_UTIL est crédité du montant déterminé en s'appuyant sur les bases 25 de données utilisateurs et fournisseurs. Pour ce faire, le serveur comprend des moyens de gestion M_DB d'une part, de la base de données fournisseur DB_FOURN, permettant de diminuer les données de valeur du compte fournisseur K_FOURN en fonction de la donnée de valeur 30 déterminée D_VAL et, d'autre part, de la base de données utilisateurs DBUTIL, permettant d'augmenter les données de valeur du compte utilisateur K_UTIL en fonction de la donnée de valeur déterminée D_VAL. Une confirmation du transfert peut être envoyée par le serveur à destination du fournisseur et de l'utilisateur, leur indiquant les nouveaux soldes de leurs comptes respectifs. Cette confirmation peut être 5 envoyée par l'intermédiaire d'un message court de service SMS. Selon une variante, préalablement à la transmission de la requête de transfert signée par l'intermédiaire de l'application sécurisée, le système comprend une 10 transmission, depuis l'appareil de communication du fournisseur vers le serveur, des informations constituant la requête de transfert pour une vérification préalable en temps réel de ces informations par l'intermédiaire de moyens de vérification du serveur M_VERIF. Pour ce faire, le fournisseur, dans un premier mode de réalisation, se connecte au serveur en mode vocal au moyen de son téléphone mobile, par l'intermédiaire d'un numéro de téléphone de service et transmet les informations constituant la requête de transfert aux 20 moyens de vérification M_VERIF du serveur en tapant sur le clavier de son téléphone mobile le code IDENT associé au compte prépayé utilisateur, son identifiant fournisseur ID_F et la donnée de valeur déterminée D_VAL. Selon un autre mode de réalisation, le fournisseur 25 transmet les informations constituant la requête de transfert aux moyens de vérification du serveur M_VERIF par l'intermédiaire d'un message numérique libellé suivant un format prédéterminé, typiquement un message court de service SMS. Dans ce cas, l'identifiant 30 utilisateur ID_F apparaît automatiquement dans l'en-tête du SMS. Par exemple, la vérification des informations constituant la requête de transfert par les moyens de vérification du serveur peut consister à vérifier que le code IDENT transmis correspond effectivement à un utilisateur appartenant au réseau de téléphonie mobile selon la relation pré-établie, et donc qu'il est bien inscrit auprès de l'opérateur du réseau. Les moyens de 5 vérification peuvent également vérifier que le solde du compte fournisseur K_FOURN est suffisant pour opérer l'opération de transfert de la donnée de valeur déterminée D_VAL vers le compte utilisateur K_UTIL. A ce stade, selon une variante de l'invention, le 10 serveur envoie à destination du fournisseur un message demandant des informations commerciales se rapportant à l'utilisateur, de façon à permettre une mise à jour de la base de données utilisateurs DB_ UTIL à l'aide de ces informations. Cette variante du système selon l'invention 15 est mise en euvre en fonction de critères qui dépendent du trafic et de la qualité du réseau. Dans le cas o ces critères sont remplis, le serveur envoie donc un message à destination du téléphone mobile du fournisseur incluant des demandes diverses à vocation commerciale auxquelles 20 l'utilisateur répond ou non. Ces demandes peuvent par exemple concerner le nom, le prénom, l'âge de l'utilisateur et, plus généralement, toute information susceptible d'intéresser l'opérateur du réseau dans un but commercial. Dans le cas, o l'utilisateur accepte de 25 répondre à de telles demandes, les informations qu'il fournit sont envoyées en retour depuis le téléphone mobile du fournisseur vers le serveur, permettant la mise à jour de la base de données utilisateurs DB_UTIL par l'intermédiaire de moyens de mise à jour M_MAJ du 30 serveur. Pour la mise en oeuvre de cette variante concernant la réception optionnelle de demandes d'informations commerciales se rapportant aux utilisateurs et l'envoi des réponses, des applications spécifiques sont développées sur la carte SIM et le téléphone mobile du fournisseur. Après validation des informations déjà existantes constituant la requête de transfert, et mise à jour 5 éventuelle de la base de données utilisateur DB_UTIL avec les informations commerciales acquises se rapportant à l'utilisateur, le système comprend l'émission vers le téléphone mobile du fournisseur, par l'intermédiaire des moyens d'authentification du serveur, d'une demande 10 d'authentification, de sorte à initier la transmission sécurisée de la requête de transfert par l'intermédiaire de l'application sécurisée. La demande d'authentification comprend les informations de rechargement IDENT et DVAL déjà transmises par le fournisseur pour vérification 15 préalable. Le fournisseur, après avoir vérifié les informations de rechargement constituant la requête de transfert IDENT et D_VAL transmises dans la demande d'authentification, s'authentifie auprès du serveur avec 20 sa signature. Pour ce faire, le fournisseur envoie la requête signée au serveur par l'utilisation de son code confidentiel. Comme expliqué précédemment, le serveur, par l'intermédiaire de ses moyens d'authentification, vérifie 25 la signature de sorte à confirmer ou infirmer la transmission de la requête de transfert et, dans le cas o la transmission est confirmée, le serveur effectue l'opération de transfert par laquelle le compte fournisseur K_FOURN est débité et le compte utilisateur 30 K_UTIL est crédité du montant déterminé D_VAL, en s'appuyant sur les bases de données utilisateurs DB_UTIL et fournisseurs DB_FOURN. Egalement, en option, une confirmation du transfert peut être envoyée par le serveur à destination des téléphones mobiles du fournisseur et de l'utilisateur, leur indiquant les nouveaux soldes de leurs comptes respectifs. Cette confirmation peut être envoyée par l'intermédiaire d'un message court de service SMS. REVENDICATIONS 1. Système pour utiliser un réseau de téléphonie mobile à l'aide d'une première entité (KUTIL) prévue 5 pour stocker des données de valeur correspondant à du temps de communication sur le réseau, ladite première entité étant associée à un code (IDENT) identifiant un moyen terminal d'utilisateur (EMT) appartenant au réseau, par l'intermédiaire d'une relation pré-établie (PREPM) 10 entre un opérateur du réseau et l'utilisateur du moyen terminal, ce système comprenant un serveur de gestion (SERV) hébergeant une première base de données (DB_UTIL) pour enregistrer les données concernant au moins la première entité (K_UTIL), caractérisé en ce que le 15 serveur héberge une seconde base de données (DB_FOURN) pour enregistrer des données concernant au moins une seconde entité (K_FOURN), prévue pour stocker des données de valeur correspondant à du temps de communication sur le réseau, ladite seconde entité (K_FOURN) étant affectée 20 à un fournisseur de temps de communication (FOURN), ledit système comprenant une transmission, par l'intermédiaire d'une application sécurisée (SIGN) depuis un appareil de communication du fournisseur (TERM_FOURN) vers le serveur, d'une requête de transfert (RQT_TRSF) incluant 25 au moins le code (IDENT) associé à la première entité, un identifiant du fournisseur (ID_F) et une donnée de valeur déterminée (DVAL), l'opération de transfert étant effectuée par le serveur de gestion à la réception de la requête par l'intermédiaire de moyens de gestion (MDB) 30 de la seconde base de données (DBFOURN) permettant de diminuer les données de valeur de la seconde entité en fonction de la donnée de valeur déterminée (DVAL) et par l'intermédiaire de moyens de gestion (MDB) de la première base de données (DBUTIL) permettant d'augmenter les données de valeur de la première entité en fonction de la donnée de valeur déterminée (DVAL). 2. Système selon la revendication 1, caractérisé en 5 ce que le moyen terminal de l'utilisateur (EMT) est un téléphone mobile. 3. Système selon la revendication 2, caractérisé en ce que le code (IDENT) associé à la première entité 10 inclus dans la requête de transfert (RQT TRSF) comprend le numéro de mobile de l'utilisateur. 4. Système selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'application sécurisée 15 (SIGN) est une application du type infrastructure à clé publique, permettant au fournisseur de signer la requête transmise pour s'authentifier auprès du serveur (SERV). 5. Système selon l'une quelconque des revendications 20 1 à 4, caractérisé en ce que l'appareil de communication du fournisseur (TERMFOURN) est un téléphone mobile, l'application sécurisée (SIGN) étant hébergée par une carte SIM insérée dans le téléphone mobile du fournisseur. 6. Système selon la revendication 5, caractérisé en ce que l'identifiant du fournisseur (IDF) inclus dans la requête de transfert (RQTTRSF) comprend le numéro de mobile du fournisseur. 7. Système selon la revendication 5 ou 6, caractérisé en ce que la requête (RQT_TRSF) transmise au serveur (SERV) est signée par la saisie d'un code confidentiel sur le téléphone mobile du fournisseur. 8. Système selon la revendication 7, caractérisé en ce que le code confidentiel utilisé pour la signature est différent du code confidentiel utilisé pour débloquer le téléphone. 9. Système selon l'une quelconque des revendications 4 à 8, caractérisé en ce que le serveur de gestion (SERV), à la réception de la requête signée par le 10 fournisseur, vérifie la signature par l'intermédiaire de moyens d'authentification (LMAUTH), de sorte à confirmer ou infirmer la transmission de la requête et, dans le cas o la transmission est confirmée, effectue l'opération de transfert. 10. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que, préalablement à la transmission sécurisée de la requête de transfert par l'intermédiaire de l'application 20 sécurisée (SIGN), le système comprend une transmission, depuis l'appareil de communication du fournisseur vers des moyens de vérification du serveur (M_VERIF), des informations constituant la requête de transfert pour une vérification préalable en temps réel de ces informations 25 par le serveur et, après validation des informations constituant la requête de transfert, l'émission par le serveur d'une demande d'authentification à destination du fournisseur, de sorte à initier la transmission sécurisée de la requête de transfert par l'intermédiaire de 30 l'application sécurisée. 11. Système selon la revendication 10, caractérisé en ce que le fournisseur se connecte au serveur en mode vocal au moyen de son appareil de communication par l'intermédiaire d'un numéro de téléphone de service et transmet les informations constituant la requête de transfert aux moyens de vérification (MVERIF) en tapant sur l'appareil de communication le code (IDENT) associé 5 à la première entité, l'identifiant fournisseur (IDF) et la donnée de valeur déterminée (DVAL). 12. Système selon la revendication 10, caractérisé en ce que le fournisseur transmet les informations 10 constituant la requête de transfert aux moyens de vérification (MVERIF) du serveur par l'intermédiaire d'un message numérique libellé suivant un format prédéterminé. 13. Système selon la revendication 12, caractérisé en ce que le message numérique est constitué par un message court de service SMS. 14. Système selon l'une quelconque des 20 revendications 10 à 13, caractérisé en ce que la vérification des informations constituant la requête de transfert par les moyens de vérification (MVERIF) du serveur consiste à vérifier que le code (IDENT) associé à la première entité transmis correspond à un utilisateur 25 appartenant au réseau selon la relation pré-établie. 15. Système selon l'une quelconque des revendications 10 à 14, caractérisé en ce que, parallèlement à vérification des informations constituant 30 la requête de transfert, le serveur envoie à destination du fournisseur, un message demandant des informations commerciales se rapportant à l'utilisateur, permettant une mise à jour de la première base de données (DB UTIL). 16. Système selon la revendication 15, caractérisé en ce que le serveur de gestion (SERV) comprend des moyens de mise à jour (MMAJ) de la première base de données (DBUTIL) avec des informations commerciales relatives aux utilisateurs. 17. Système selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend l'émission par le serveur de gestion (SERV) 10 d'une confirmation du transfert à destination du fournisseur et de l'utilisateur. 18. Système selon la revendication 17, caractérisé en ce que la confirmation est envoyée par l'intermédiaire 15 d'un message court de service SMS.