Brevet FR2880753A1 — publié le 20060714

PROCEDE ET MODULE DE TRANSMISSION DE DONNEES MEMORISEES DANS UN TERMINAL La présente invention concerne le domaine de la transmission, par messages, de données mémorisées dans un terminal utilisateur, à destination d'un serveur, relié par un réseau supportant l'envoi de tels messages au terminal utilisateur. Plus particulièrement, la présente invention se rapporte au cas où les messages sont de taille limitée à une taille maximum, par exemple du type des messages SMS ( Short Message System ) utilisés par les terminaux utilisateurs dans les réseaux mobiles GSM ( Global System for Mobile communication ). Il est intéressant de pouvoir rapatrier à destination d'un serveur certaines des données mémorisées par l'utilisateur dans un terminal utilisateur. Par exemple, de telles données peuvent correspondre au contenu du répertoire ou carnet d'adresses stocké sur une carte à puce, telle qu'une carte SIM ( Subscriber Identification Module ), propre à l'abonné et intégré dans son téléphone portable. Les données fournies au serveur font l'objet de sauvegardes. Elles pourront ainsi être restituées ultérieurement à l'utilisateur par exemple en cas de perte ou de vol de son téléphone. La norme 3GPP TS 03.48 version 8-8-0, publiée en décembre 2001, prévoit une commande nommée GET DATA permettant de provoquer la transmission à destination d'un serveur des informations stockées sur une carte SIM. L'application de cette commande au contenu du répertoire implique, pour chacun des contacts mémorisés dans le carnet d'adresses, l'envoi par le serveur au terminal utilisateur d'un SMS contenant la commande GET DATA. Le terminal utilisateur est adapté pour répondre à ce SMS en envoyant à son tour un SMS à destination du serveur, comportant les informations relatives au contact (typiquement une zone relative à un contact, comportant le nom du contact et le numéro de téléphone du contact). Ainsi pour un répertoire d'une carte SIM stockant 150 contacts, le rapatriement nécessite 150 SMS de commande envoyés par le serveur, et 150 SMS de réponse envoyés par le terminal utilisateur. L'opération prend beaucoup de temps et consomme une quantité importante de ressources du réseau. La présente invention vise à diminuer le nombre important de messages nécessaires dans l'art antérieur, pour transmettre à un serveur des 5 données mémorisées dans un terminal utilisateur. A cet effet, suivant un premier aspect, l'invention propose un procédé de transmission de données mémorisées dans un terminal à destination d'un serveur, le terminal comportant des données mémorisées dans des zones d'enregistrement et étant apte à transmettre au serveur des messages de taille maximum fixée, le procédé comprenant les étapes suivantes: - lire les zones et construire une chaîne de données en accolant, selon un ordre fixé préalablement, des groupes de données respectivement associés à certaines au moins des zones, au moins un desdits groupes comportant des données lues dans une zone associée et la taille desdites données; extraire, de la chaîne de données, un premier tronçon et l'inclure dans le message, la taille du premier tronçon étant déterminée de façon à utiliser au maximum la capacité de transmission de données disponible dans le message; et - transmettre au serveur un premier message. Un procédé selon l'invention permet donc de grouper dans un même message un maximum de données, en utilisant la totalité de la capacité de transmission du message. Le nombre de messages nécessaires pour transmettre le contenu de l'ensemble des zones d'un répertoire est donc nettement réduit par rapport à 25 l'art antérieur. Les données relatives à chaque zone pourront ensuite être extraites et attribuées à un groupe de données associé à la zone, à l'aide des informations de taille de groupe présentes dans le message. Suivant un deuxième aspect, l'invention propose un programme d'ordinateur de transmission de données mémorisées, exécutable par une unité de traitement d'un terminal comportant des données mémorisées dans des zones d'enregistrement et étant apte à transmettre, à destination d'un serveur, des messages de taille maximum fixée. Ce programme comprend des instructions pour exécuter les étapes d'un procédé suivant le premier aspect de l'invention. Suivant un troisième aspect, l'invention propose un procédé de traitement, par un serveur, d'un message délivrant des données mémorisées dans certaines au moins des zones d'enregistrement d'un terminal, le procédé de traitement mettant en oeuvre au moins les étapes suivantes: - identifier au moins une valeur de taille indiquée dans le message reçu et extraire du message, en fonction d'au moins ladite valeur de taille, un groupe de données associé à une zone respective et comportant un ensemble de données de taille égale à la valeur de taille identifiée; - identifier ladite zone en fonction d'au moins un ordre de zones fixé préalablement et de la position du groupe de données dans le message; - enregistrer au moins l'ensemble de données en association avec ladite zone identifiée. Suivant un quatrième aspect, l'invention propose un module adapté pour être intégré dans un terminal comportant des données mémorisées dans des zones d'enregistrement et étant apte à transmettre à un serveur des messages de taille maximum fixée, ledit module comportant des moyens pour mettre en oeuvre un procédé de transmission suivant le premier aspect de l'invention. Suivant un cinquième aspect, l'invention propose un terminal comportant des données mémorisées dans des zones d'enregistrement et étant apte à transmettre à un serveur des messages de taille maximum fixée. Le terminal selon l'invention comporte un module suivant le quatrième aspect de l'invention. Suivant un sixième aspect, l'invention propose un module logiciel adapté pour être intégré dans un serveur et pour traiter au moins un message en provenance d'un terminal et délivrant des informations relatives à des données mémorisées dans des zones d'enregistrement du terminal. Ce module comporte des instructions logicielles aptes à commander l'exécution des étapes d'un procédé selon le troisième aspect de l'invention. Suivant un septième aspect, l'invention propose un serveur pour traiter au moins un message en provenance d'un terminal et délivrant des informations relatives à des données mémorisées dans des zones d'enregistrement du terminal, comportant un module suivant le sixième aspect de l'invention. D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels: - la figure 1 représente un réseau mettant en oeuvre un mode de réalisation de l'invention; la figure 2 est un organigramme représentant les différentes étapes d'un procédé de transmission par un terminal dans un mode de réalisation de l'invention; - la figure 3 représente un groupe de données Ci constitué selon l'invention; la figure 4 représente une chaîne de données constituée selon l'invention en fonction des groupes de données déterminés; la figure 5 représente deux SMS constitués dans un mode de mise en oeuvre de l'invention, pour transmettre le contenu de la chaîne de données représentée en figure 4; - la figure 6 est un organigramme représentant différentes étapes d'un procédé de traitement par un serveur dans un mode de réalisation de l'invention. La figure 1 représente un système 1 dans lequel l'invention est mise en oeuvre. Ce système comporte un réseau de télécommunications mobiles 2, par exemple de type GSM, permettant de relier des terminaux utilisateurs et des équipements de l'opérateur du réseau 2. Il est adapté notamment pour acheminer des messages de type SMS émis et/ou reçus par les terminaux utilisateurs et/ou les équipements de l'opérateur et à destination de terminaux utilisateurs et/ou des équipements de l'opérateur. Dans le mode de réalisation considéré, les SMS peuvent contenir au maximum une taille notée Tmax de données. Dans le mode de réalisation considéré, Tmax est égal à 140 octets. Les équipements de l'opérateur du réseau 2 comporte un serveur SI et une base de données DB. Le serveur S1 est adapté pour émettre et recevoir des messages SMS conformément à la norme 3 GPP TS 23-040, version 5-8-1 du 12/10/2004. La base de données DB est destinée à mémoriser une sauvegarde d'éléments stockés dans le répertoire de terminaux utilisateurs du réseau. Le serveur S1 est adapté pour renseigner et/ou mettre à jour cette base DB en fonction de SMS qui lui sont envoyés par les terminaux utilisateurs. Sur la figure 1 est représenté l'un de ces terminaux utilisateurs, référencé 3. Le terminal 3 est adapté pour émettre et recevoir des messages SMS. Le terminal utilisateur 3 fonctionne en association avec une carte SIM 4. La carte SIM 4 mémorise des données propres à l'utilisateur, par exemple un répertoire de contacts 5, contenant des noms et numéros de téléphone de contacts. Dans le mode de réalisation considéré, la carte SIM comporte en outre un module 6 de constitution de SMS de sauvegarde, adapté pour mettre en oeuvre l'invention. Le répertoire 5 du terminal utilisateur contient par exemple 150 zones d'enregistrement de contact, identifiées chacune par un numéro d'ordre de 1 à 150. La zone d'identifiant i est nommée ci-après Zi, pour i = 1 à 150. Une zone d'enregistrement dans le mode de réalisation considéré contient un nom de contact enregistré par l'utilisateur du terminal à partir d'une forme alphanumérique, qui occupe un certain nombre d'octets X, variable en fonction de la longueur du nom. Une zone d'enregistrement Zi est adaptée pour contenir en outre à la suite de ces X octets, 14 octets d'informations diverses, parmi lesquels figurent un champ de 10 octets dédié à l'enregistrement du numéro du contact et un champ de 1 octet dédié à l'identification TON/NPI du type de numéro (TON pour Type of Number ) et du plan de numérotation (NPI pour Numbering Plan Identification ). Dans le mode de réalisation décrit, lorsque le terminal 3 modifie une zone d'enregistrement Zi, il mémorise, dans une zone mémoire spécifique du terminal, une information indiquant que la zone Zi a été modifiée. Cette zone mémoire est réinitialisée après l'envoi au serveur par le terminal des données de sauvegarde du répertoire 5. Ainsi le module 6 sait si les éléments mémorisés dans une zone Zi n'ont pas été modifiés depuis la dernière opération de sauvegarde. L'état de telles zones est nommé ci-après état inchangé . Par ailleurs, le module 6 a également connaissance des zones Zi qui ne sont pas occupées par des données de contacts valides. L'état de telles zones est nommé ci-après état vide . Le module 6, suite à la réception d'un signal commandant l'envoi de SMS de sauvegarde du répertoire, est adapté pour mettre en oeuvre une application A exécutant un certain nombre d'étapes selon l'invention. Le module 6 va constituer une chaîne de données Â à transmettre par tronçons successifs via des SMS, au serveur S1. Cette chaîne de données comporte au moins un groupe de données Ci déterminé par le module 6 pour une zone Zi. Chaque groupe de données Ci débute par un mot de contrôle Ki, de longueur fixe égale à un octet (comprenant donc 8 bits b8-b1 prenant les valeurs 0 ou 1), déterminé par le module 6 en fonction de la zone Zi. Le module 6 va parcourir les zones d'enregistrement Zi, de i = 1 à 150. On notera que si un ordre croissant (de 1 à 150) est ici utilisé, d'autres ordres peuvent néanmoins être utilisés, par exemple décroissant ou autre. Cet ordre est également connu du serveur. Les étapes réalisées par le module 6 pour parcourir les zones et 25 constituer la chaîne de données sont détaillées ci-dessous en référence à l'organigramme représenté en figure 2. La chaîne de données Â est vide au début du processus. Le module 6 réalise une première étape 100 visant à déterminer si la première zone Zi considérée par le module 6, dans le cadre de cette opération d'envoi de données à sauvegarder, est vide ou non. Il va donc commencer par considérer la zone Zi pour i=1. Cas a: Zi est vide. Si Zi est vide, I e module 6 affecte au bit b8 la valeur 0 et au bit b7 la valeur 0. II affecte la valeur 1 à un compteur n,,, destiné à compter le nombre de zones successives dans un état vide (étape 101), à partir de la zone actuellement considérée. Puis il lit les zones qui suivent la zone Zi, en incrémentant le compteur n lorsqu'il lit une nouvelle zone vide, et ce jusqu'à ce qu'il détermine une zone qui n'est pas dans un état vide: Zj, où j = i+nv (étapes 102-104). Le module 6 code alors, à l'aide des bits bl-b6 du mot de contrôle Ki, la valeur indiquée par le compteur n (étape 105). Le mot de contrôle Ki est ainsi déterminé. Le groupe de données Ci est pris égal à Ki (étape 106), quand la zone Zi est vide. Le groupe de données Ci est ajouté au contenu courant de la chaîne de données Â (étape 107). Puis le module 6 reprend le processus à partir de l'étape 100, en l'appliquant à la dernière zone lue Zj'i=.+nv Cas b: la zone Zi n'est pas vide. Si à l'étape 100, le module 6 a déterminé que la zone Zi n'est pas dans un état vide , alors le module 6 détermine si elle est dans un état 20 inchangé ou non (étape 108). Cas b1: si la zone Zi est dans un état inchangé , le module 6 affecte au bit b8 la valeur 0 et au bit b7 la valeur 1. Il affecte la valeur 1 à un compteur n;, destiné à compter le nombre de zones successives dans un état inchangé (étape 109). Puis il lit les zones suivant la zone Zi, en incrémentant le compteur ni lorsqu'il lit une nouvelle zone inchangée, et ce jusqu'à ce qu'il détermine une zone qui n'est pas dans un état inchangé : Zk, où k = n; +1 (étapes 110-112). Le module 6 code alors, à l'aide des bits bl-b6 du mot de contrôle Ki, la valeur indiquée par le compteur n; (étape 113). Le mot de contrôle Ki est ainsi déterminé. Le groupe de données Ci est pris égal à Ki (étape 114), car la zone Zi est inchangée. Le groupe de données Ci est ajouté au contenu courant de la chaîne de données Â (étape 115). Puis le module 6 reprend le processus à partir de l'étape 100, en l'appliquant à la dernière zone lue ZkIk= n; +i. Cas b2: si la zone Zi n'est pas déterminé dans un état inchangé à l'étape 108, le module 6 affecte au bit b8 la valeur 1 (étape 116). Puis le module 6 lit l'identification TON/NPI dans la zone Zi. Il détermine un code en fonction des valeurs prises par cette identification, selon la correspondance suivante: les valeurs, en notation hexadécimale, de TON/NPI égales à OxA1 (numéro national), 0x91 (numéro international), 0x81 (numéro inconnu) correspondent respectivement aux codes 000, 001, 010, conformément à une table de correspondance prédéfinie stockée dans le terminal utilisateur 3. Les valeurs autres que les valeurs hexadécimales précédentes correspondent au code 111. Le module 6 affecte aux bits b5 à b7 du mot de contrôle Ki constitué pour la zone Zi, la valeur du code ainsi déterminé (étape 117) . Puis il extrait de la zone Zi, le numéro de contact Ni. Il détermine la taille tNi, exprimée en nombre d'octets, de ce numéro Ni. Le module 6 affecte aux bits b1 à b4 du mot de contrôle Ki, des valeurs correspondant à la représentation binaire de cette taille tNi (étape 118). Suivant les modes de réalisation, une représentation binaire standard est utilisée ou une représentation binaire de type BCD ( Binary Coded Decimal), où chaque chiffre d'un nombre est codé séparément en binaire. Par exemple, 27 s'écrit en représentation binaire classique 11011 (1x16 + 1x8 + 0x4 + 1x2 + 1x1) et s'écrit en BCD 100111 (codage de 2(10) suivi du codage de 7 sur 4 bits (0111)). II est avantageux d'utiliser le format BCD quand le numéro de téléphone est mémorisé sous forme BCD dans le répertoire 5. La taille tNi est déterminée par le module 6 en fonction de la représentation binaire initialement retenue. Le mot de contrôle Ki du groupe de données pour la zone Zi est ainsi 30 déterminé. Dans le seul cas où le code NPI/TON est égal à 111, le groupe de données comprend à la suite du mot de contrôle, un mot de longueur 1 octet et fournissant la valeur effective de l'identifiant TON/NPI (étapes 120, 121). Ensuite, indépendamment de la valeur du TON/NPI, le module 6 continue à constituer le groupe de données Ci en faisant suivre l'octet Ki (et le cas échéant l'octet fournissant le TON/NPI) constitué comme indiqué précédemment, de tN; octets O;' à O N' qui représentent le numéro de téléphone Ni (étape 122). Puis le module 6 lit, dans la zone d'enregistrement Zi, le nom du contact Mi. II complète le groupe de données Ci en ajoutant à la suite un octet indiquant la longueur tM;, exprimée en octets, des données Mi correspondant au nom du contact (étape 123). Le module 6 fait ensuite suivre cet octet de tMi octets O r à o M', représentant le nom de contact Mi (étape 124). Le groupe de données Ci pour la zone Zi ainsi constitué est ajouté au contenu courant de la chaîne de données Â (étape 125). Puis le module 6 reprend le processus à partir de l'étape 100, en l'appliquant à la prochaine zone non lue Zi+1. Avantageusement, les données (identification TON/NPI, numéro du contact Ni, nom du contact Mi) lues, puis incluses par le module 6 dans le groupe de données correspondent à des données utiles, c'est-à-dire des données à sauvegarder. En particulier, le module 6 ne prend pas en compte les octets de padding FF , qui sont des données de bourrage destinées à remplir les champs de la zone Zi. Sur la figure 3 est représenté un groupe de données Ci, dans le cas d'une zone qui n'est ni dans un état vide , ni dans un état inchangé (cas b2), et avec un code pour l'identifiant TON/NPI différent de 111. La chaîne Â constitué par le module 6 débute par le groupe de données Cl déterminé par le module 6 pour la zone Z1 et est complétée au fur et à mesure qu'il détermine un nouveau groupe de données, lors de l'analyse successive des zones Z1 à Z150 conformément aux étapes indiquées ci-dessus Sur la figure 4 est représentée la chaîne de données Â constituée par le module 6 pour les zones Z1 à Z150. Cette chaîne comporte 21 groupes de données (le répertoire considéré ne contenant pas de zones consécutives dans un état vide, respectivement inchangé, jusqu'à la zone Z20 et comprenant des zones Z21 à Z150 vides). Entre parenthèse sont indiquées les tailles, en octets, de chacun des groupes de données constitués. Ainsi dans le mode de réalisation décrit ci-dessus, le module 6 ne constitue pas de groupe de données spécifique pour une zone vide ( état vide ) qui suit immédiatement (selon l'ordre croissant des identifiants) une autre zone vide, ni pour une zone inchangée depuis la dernière sauvegarde ( état inchangé ) qui suit immédiatement une autre zone inchangée. Dans d'autres modes de réalisation de l'invention, un groupe de données est constitué pour chaque zone. Le module 6 constitue ensuite un ou plusieurs SMS, afin que les données de la chaîne Â puissent être transmises à destination du serveur S1. Le module 6 renseigne l'espace utilisable d'un ou plusieurs SMS (140 15 octets Chi à Ch140 par SMS) de la façon suivante. Il a été préalablement défini un découpage de la longueur maximum Tmax (140 octets) utilisable dans un SMS, en un en-tête de longueur égale à Tmax -T, suivi d'un corps de message de longueur égale à T. Dans le mode de réalisation considéré, T est égal à 137 octets. Le module 6 découpe la chaîne Â construite comme indiquée précédemment en tronçons contigus de 137 octets. Le dernier tronçon contient l'extrémité de la chaîne Â et correspond aux identifiants de zone les plus grands. II a une taille inférieure à 137 octets quand la taille de la chaîne Â n'est pas un multiple de 137. Le module 6 insère, dans les 137 derniers octets Ch4 à Ch140 disponibles de chaque SMS pris successivement, un tronçon respectif. Le SMS contenant le dernier tronçon sera le dernier SMS constitué dans le cadre de la présente opération de sauvegarde du répertoire 5. Ainsi, itérativement, le module 6 extrait, de la chaîne de données diminuée du dernier tronçon extrait, un nouveau tronçon de taille égale à la taille minimum parmi la taille prédéterminée et la taille de la chaîne de données et incluse le nouveau tronçon dans un nouveau message à transmettre à destination du serveur, et ce tant que la taille de la chaîne de données diminuée du dernier tronçon extrait est strictement supérieure à zéro. Puis pour chaque SMS, le module 6 renseigne un en-tête constitué des 3 premiers octets Chi à Ch3. II indique dans le champ Chi (Champ Application Identifier ), l'identifiant de l'application A. Cet identifiant peut être utilisé par les équipements chargés de recevoir ces SMS, pour déterminer le serveur S1 qui gère cette application. Par défaut cette valeur est 0x00. Le module 6 indique dans les bits b8-b1 du champ Ch 2 (Champ SMS Information Mask ) les informations suivantes. Les bits b8-b5 du champ Ch2 indiquent le numéro de version de l'application A (par défaut 0000). Le bit b4 est mis à 0. Le bit b3 est mis à 0 si le SMS en cours de constitution est celui qui contient le dernier tronçon de la chaîne Â c'est-à-dire si la fin de la chaîne a été insérée dans ce SMS. Au contraire, le bit b3 est mis à 1 si un ou plusieurs SMS sont à suivre. Le bit b3 est en outre mis à 0 si b4 est égal à 1. Le module 6 renseigne ensuite le champ Ch3 ( SMS Data ) de la manière suivante. Si le bit b4 du champ SMS Information Mask est égal à 0, le module 6 renseigne ensuite le champ Ch3 avec le numéro i de la zone Zi pour laquelle à été constitué le groupe de données Ci dont proviennent les données mémorisées dans le champ Ch4 (qui est le premier octet du SMS comportant des données de la chaîne Â ). Si le bit b4 du champ SMS Information Mask est égal à 1, le module 6 renseigne ensuite le champ Ch3 ( SMS Data ) avec le code erreur 0x01 ( RANGE-ERROR). Chaque SMS ainsi constitué est ensuite envoyé à l'adresse du serveur S1, dans l'ordre de constitution. Sur la figure 5 sont représentés les SMS constitués par le module 6 à partir de la chaîne de données Â représentée en figure 4. Ces SMS sont au nombre de 2. Le premier tronçon de 137 octets, comprenant les groupes de données Cl à C10 et les 4 premiers octets du groupe C11, a été intégré dans le premier SMS (SMS1). Le second tronçon de 137 octets, comprenant les 7 derniers octets du groupe de données C11 et les groupes de données C12 à C21, a été intégré dans le second SMS (SMS2). Les trois premiers blocs de chaque SMS SMS1, SMS2 de la figure 4, représentent les trois octets d'en-tête. Dans le dernier de ces trois blocs est indiqué le numéro de la zone pour laquelle a été défini le groupe dont fait partie le premier octet du tronçon intégré dans le SMS. Ce numéro a été représenté sur la figure sous forme décimale pour faciliter la lecture. Le signal envoyé au module 6 du terminal utilisateur 3 et commandant l'envoi de SMS de sauvegarde du répertoire, peut être déclenché selon plusieurs manières en fonction des modes de réalisation. Dans un mode de réalisation, le serveur S1 envoie un SMS de déclenchement. Avantageusement, ce SMS de déclenchement précise un intervalle de zones à sauvegarder [Zmin; Zmax], où Zmin et Zmax sont des identifiants de zone. Le fait de préciser un intervalle permet au terminal de ne pas envoyer les données relatives à l'ensemble du contenu du répertoire, mais uniquement celles concernant une plage souhaitée par l'opérateur, par exemple dans le cas où la précédente sauvegarde a échouée en partie seulement, l'échec de sauvegarde concernant la plage [Zmin; Zmax]. Le SMS de déclenchement comporte par exemple trois octets. Les bits b8-b6 du premier octet indiquent le numéro de version du SMS, les autres bits ne sont pas utilisés. Le deuxième octet fournit la valeur de Zmin. Le troisième octet fournit la valeur de Zmax. Lorsque le module 6 reçoit ce SMS, il effectue des opérations de validation. Par exemple, il vérifie le numéro de version, vérifie que Zmin est supérieur ou égal à 1, que Zmax Zmin, que Zmin nombre maximum de zones dans le répertoire (ici 21) etc. Au cas où une de ces opérations indique une incohérence, le module 6 envoie un SMS d'erreur en réponse au serveur 1, contenant uniquement un en-tête de trois octets. Le module 6 n'entame alors pas les opérations de constitution de groupes de données. Le premier octet de l'en-tête du SMS d'erreur est défini comme précédemment. Les bits b8-b5 du champ Ch2 indiquent le numéro de version de l'application A (par défaut 0000). Le bit b4 du champ Ch2 est mis à 1, indiquant une erreur constatée. Au cas où les opérations de validation menées par le module 6 n'indiquent aucune incohérence, le module 6 vérifie que Zmax est inférieur ou égal au nombre maximum de zones dans le répertoire et sinon remplace Zmax par ce nombre maximum. Puis le module 6 effectue les opérations de constitution de groupes de données, mais en n'effectuant les étapes indiquées précédemment qu'à partir de la zone Zmin, et en arrêtant de construite la chaîne de données dès que la zone Zmax a été traitée. La chaîne de données ainsi constituée ne contiendra donc que des groupes de données déterminés pour des zones dont l'identifiant figure dans cette plage. Dans autre un mode de réalisation, l'utilisateur du terminal utilisateur 3 sélectionne un item de sauvegarde de répertoire dans un menu, ce qui déclenche le signal de commande, à destination du module 6, de constitution de SMS. Le bit b4 du champ SMS Information Mask étant égal à 1, le module 6 renseigne ensuite le champ Ch3 ( SMS Data ) avec le code erreur 0x01 ( RANGE-ERROR). Le fait de vérifier que le contenu d'une zone a changé ou non depuis la dernière sauvegarde permet lorsque ce contenu n'a pas changé, de ne pas transmettre les données contenues dans la zone, ce qui diminue le volume d'informations à transmettre au serveur SI. L'invention peut cependant être mise en oeuvre même quand le module 6 n'est pas adapté pour déterminer si les éléments mémorisés dans la zone Zi sont déjà connus du serveur et s'ils ont été modifiés depuis la dernière opération de sauvegarde. Dans ce cas, si la zone Zi n'est pas vide, le groupe de données constitué pour la zone Zi par le module 6 sera intégré d'office dans la chaîne. Le module 6 détermine en outre le nombre de zones consécutives présentant la même caractéristique (vide ou inchangée) et transmet dans le groupe de données relative à la première de ces zones, ce nombre de zones consécutives. Ce seul groupe de données permet donc de transmettre l'ensemble des informations nécessaires à la sauvegarde actualisée de ces zones consécutives du répertoire 5. Le fait de faire figurer dans chaque groupe de données relatif à une zone Zi, un code de 3 bits indiquant la valeur prise par le champ TON/NPI detaille deux octets dans la zone, permet de diminuer le nombre d'octets à transmettre. Toutefois, dans un autre mode de réalisation, la valeur du TON/NPI de taille 1 octets peut être transmise à la place du code. Dans le cas où la plage de sauvegarde débute toujours à partir de la première zone, il n'est pas nécessaire de faire figurer dans l'en-tête le numéro de la zone, même si cela permet au serveur de rétablir le bon ordre de séquencement des SMS, au cas où l'ordre de réception des SMS par le serveur SI ne correspond pas à l'ordre d'envoi des SMS par le terminal utilisateur. Les différentes étapes mises en oeuvre par le serveur sont représentées sur l'organigramme de la figure 6. Lorsque le serveur SI reçoit un premier SMS envoyé par un terminal utilisateur, il analyse les données figurant dans l'en-tête pour identifier le cas échéant un cas d'erreur, et pour identifier la zone Zj à laquelle se rapporte le premier octet du corps du message de 137 octets suivant l'en-tête (quand aucun identifiant ne figure dans l'en-tête, j par défaut, est pris égal à 1) (étape 200). Le serveur S1 détermine le groupe de données pour la zone Zj de la manière suivante. Ce groupe de données Cj débute par le bit b8 du premier octet Kj du corps de message, qui indique si la zone Zj est une zone dans un état autre qu'un état vide ou un état inchangé . Le module 6 lit le premier bit b8 du corps de message et regarde sa valeur (étape 202). Cas a' : b8 est différent de O. Si b8 n'est pas égal à 0 (la zone n'est pas dans un état vide ou un état inchangé ), il lit les bits b7-b5 du premier octet dans le corps du message et compare leur valeur à la valeur 111 (étape 203). Si b7-b5 est différent de 111 , alors le serveur S1 détermine l'identification du TON/NPI à partir d'une table de correspondance prédéfinie identique à celle stockée dans le terminal utilisateur (étape 204). Lorsque b7-b5 est égal à 111 , le serveur S1 est adapté pour extraire la valeur du TON/NPI de la zone Zj, fournie dans le second octet du corps de message (étape 208). Le TON/NPI qui figure dans la zone Zj du répertoire 5 du terminal 3 est ainsi récupéré par le serveur SI, qui le mémorise dans un champ destiné à mémoriser le numéro TON/NPI au sein d'une zone identifiée Z'j d'un répertoire 5' (étape 205 ou 209). Ce répertoire 5' est stocké dans la base de données DB et est destiné à sauvegarder les valeurs de TON/NPI, de numéro Nj et de nom de contact Mj stockés dans la zone Zj du terminal utilisateur 3 au moment de l'envoi des SMS par le terminal 3. Puis le serveur S1 est adapté pour identifier la valeur délivrée par les bits b1-b4 du premier octet du corps de message (étape 206 ou 207) . Ces bits sont connus du serveur Si comme indiquant la taille tNi de l'ensemble de données figurant dans le corps de message à partir du second octet (ou du troisième si le code TON/NPI = 111) et relatives au numéro de contact stocké dans la zone Zj du terminal utilisateur 3. Le serveur S1 extrait alors les tNi octets figurant dans le corps de message depuis le second octet (ou le troisième si le code TON/NPI = 111) (étape 210) et les mémorise dans un champ de la zone Z'j du répertoire 5' destiné à mémoriser le numéro de contact stocké dans la zone Zj du terminal 3 (étape 211). L'octet suivant ces tNi octets dans le SMS fournit au serveur une valeur égale à tMj (étape 212). Le serveur SI est adapté pour extraire alors les tMJ prochains octets (étape 213), et les mémoriser dans un champ dans la zone Z'j du répertoire 5' qui est destiné à mémoriser le nom de contact Mi (étape 214). Ces toi octets correspondent à la fin du groupe de données Cj. Les données correspondant à la zone Zj du terminal 3 est ainsi mémorisée par le serveur S1. Le serveur SI interprète donc l'octet suivant comme le mot de contrôle Kj+1 du groupe Cj+1, relatif à la zone Zj+1 (étape 215), puis retourne à l'étape 202 pour réaliser l'interprétation de cet octet et des suivants. Cas b' : b8 est égal à 0 (la zone Zj est dans un état vide ou un état inchangé ). Le module 6 lit ensuite la valeur de b7 (étape 216) et lit la valeur délivrée par les bits bl-b6. Ces bits sont connus du serveur S1 comme indiquant le nombre n de zones consécutives à partir de Zj, dans le terminal 3, qui sont dans le même état que la zone Zj. Si b7 est égal à 0, cela signifie que la zone Zj du terminal utilisateur 3 est vide. Le serveur S1 met donc à zéro les champs destinés à sauvegarder le TON/NPI, le numéro de contact et le nom de contact de la zone Zj (étape 217) dans le répertoire 5'. Si b7 est égal à 1, le serveur SI conserve inchangées les données 20 mémorisées dans la zone Z'j et fournissant le TON/NPI, le numéro de contact Ni et le nom de contact Mi (étape 218) Puis le serveur S1 réalise la même opération (effacement/conservation) sur les zones présentes entre Z'j et Z'j+n-1 que celle effectuée sur la zone Z'j. Les données correspondant aux zones Zj à Zj+n-1 du terminal 3 sont ainsi mémorisées par le serveur SI. Selon le mode de réalisation considéré de l'invention, un tel groupe Cj ne comporte qu'un seul octet Kj. L'octet qui suit ce seul octet Kj dans le SMS est donc considéré par le 30 serveur SI comme le premier octet du groupe Cj+n (étape 219). Pour interpréter ce nouvel octet et les suivants, le module 6 réitère les étapes à partir de l'étape 202 appliquée sur ce nouvel octet. Le dernier octet présent dans le corps du SMS reçu par le serveur SI n'est pas toujours le dernier octet du groupe de données auquel appartient cet octet. Dans ce cas, le serveur S1 est adapté pour attendre le SMS suivant en provenance du terminal 3 pour poursuivre l'analyse du groupe de données en cours à partir des données fournies par le corps du SMS suivant, et pour poursuivre ensuite la sauvegarde du répertoire. Il effectue en fait une concaténation des 137 octets de corps de message de SMS successifs, et reconstitue la chaîne Â. Le serveur S1 détermine qu'un SMS reçu était le dernier SMS pour la sauvegarde du répertoire du terminal 3, lorsque le bit b3 du second octet dans l'en-tête de SMS (octet SMS Information Mask ) est à 0, le bit b4 de cet octet étant à 0. L'identifiant de la zone figurant dans l'en-tête du premier SMS permet au serveur de débuter la sauvegarde à la zone mémoire indiquée. Ceci est nécessaire lorsque les données transmises dans un premier SMS en provenance d'un terminal ne concernent pas la première zone du répertoire. Cette disposition permet en outre au serveur S1 de réordonner des SMS arrivant dans un ordre différent de l'ordre selon lesquels ils ont été envoyés par le terminal utilisateur. L'invention peut s'appliquer sur des données mémorisées dans le terminal utilisateur autres que le contenu du répertoire, par exemple des commentaires enregistrés, une liste d'adresses URL favorites etc. Dans le cadre d'un service de restauration, des éléments d'un répertoire mémorisés dans la base BD peuvent ensuite être envoyés par le serveur S1 par l'intermédiaire de SMS, à destination d'un terminal utilisateur dont l'utilisateur a perdu le contenu de son répertoire, suite par exemple à des défaillances de carte SIM, ou à des pertes ou vols de terminaux. Ces éléments peuvent être utilisés à d'autres fins, par exemple ils peuvent être synchronisés avec les contacts d'une autre base gérée par l'opérateur, qui est consultable et modifiable par l'abonné depuis un ordinateur O via Internet, comme représenté sur la figure 1. Dans un mode de réalisation, l'application A mise en oeuvre par le module 6 et comprenant les instructions pour mettre en oeuvre l'ensemble des étapes indiquées ci-dessus est une application de type Java, qui représente environ 2 kilooctets et peut donc relativement aisément être téléchargée par SMS sur les cartes SIM. L'application est par exemple téléchargée par SMS depuis un équipement du réseau 2, par exemple le serveur S2 représenté en figure 1. L'utilisation de l'invention est ainsi rendue possible non seulement sur les parcs de nouveaux terminaux utilisateurs, mais également sur les terminaux utilisateurs déjà déployés. Ceci représente un avantage considérable pour un opérateur souhaitant traiter les répertoires de ses abonnés déjà existants sans renouveler leur carte SIM. Ainsi l'invention permet de réduire considérablement le nombre de SMS nécessaires pour envoyer à un serveur les éléments d'un répertoire de terminal utilisateur à sauvegarder. II atteint ce but avec la constitution d'une chaîne de données en mettant bout à bout les groupes de données déterminés pour certaines des zones du répertoire du terminal, et en découpant cette chaîne en tronçon de taille maximum, indépendamment de l'endroit où a lieu la séparation. On diminue ainsi le nombre de SMS nécessaires. Les groupes de données sont constitués de sorte à ne contenir que des informations utiles (les octets de bourrage sont éliminés) et lorsque des zones sont inchangées, on ne transmet pas les données mémorisées dans ces zones. REVENDICATIONS 1. Procédé de transmission de données mémorisées dans un terminal (3) à destination d'un serveur (Si), le terminal comportant des données mémorisées dans des zones d'enregistrement (Zi) et étant apte à transmettre au serveur des messages de taille maximum fixée (Tmax), le procédé comprenant les étapes suivantes: lire les zones et construire une chaîne de données (Â) en accolant, selon un ordre fixé préalablement, des groupes de données respectivement associés à certaines au moins des zones, au moins un desdits groupes comportant des données (Mi, Ni) lues dans une zone associée et la taille (tM;;tN;) desdites données; extraire, de la chaîne de données, un premier tronçon et l'inclure dans le message, la taille du premier tronçon étant déterminée de façon à utiliser au maximum la capacité de transmission de données disponible dans le message; et transmettre au serveur un premier message (SMS1). 2. Procédé selon la revendication 1, selon lequel on réitère les étapes suivantes tant que la taille de la chaîne de données (Â) diminuée du dernier tronçon extrait est strictement supérieure à zéro: extraire, de la chaîne de données diminuée du dernier tronçon extrait, un nouveau tronçon, la taille du nouveau tronçon étant déterminée de façon à utiliser au maximum la capacité de transmission de données disponible dans le message; - transmettre au serveur un nouveau message (SMS2), incluant le nouveau tronçon. 3. Procédé selon la revendication 2, selon lequel lorsque des zones contiguës, selon l'ordre fixé préalablement, sont vides, on détermine un groupe de données (Ci) associé à la première desdites zones contiguës, indiquant le nombre de zones contiguës vides. 4. Procédé selon la revendication 2 ou 3, selon lequel lorsque des zones contiguës, selon l'ordre fixé préalablement, n'ont pas été modifiées depuis la dernière transmission réussie au serveur de données relatives à ces zones contiguës, on détermine un groupe de données (Ci) associé à la première desdites zones contiguës, indiquant le nombre de zones contiguës non modifiées. 5. Procédé selon l'une quelconque des revendications précédentes, selon lequel le message comporte une première partie et une seconde partie, la seconde partie étant destinée à inclure le tronçon, et on indique dans la première partie, un identifiant de la zone associée au groupe dont la première donnée de la seconde partie du message fait partie. 6. Procédé selon la revendication 5, selon lequel on indique en outre dans la 20 première partie que le message est le dernier, lorsque la taille de la chaîne de données diminuée du dernier tronçon extrait est égale à zéro. 7. Procédé selon l'une quelconque des revendications précédentes, selon lequel on supprime des données de bourrage comportées dans des données lues dans une zone avant d'inclure lesdites données lues dans le groupe de données associé à la zone. 8. Procédé selon l'une quelconque des revendications précédentes, selon lequel on a préalablement déterminé une correspondance entre au moins 30 une valeur affectable à un champ particulier d'une zone (Zi) et un code, de taille inférieure à celle de ladite valeur, et le groupe de données associé à une zone comportant ladite valeur dans le champ particulier, comporte ledit code. 9. Programme d'ordinateur de transmission de données mémorisées, exécutable par une unité de traitement d'un terminal comportant des données mémorisées dans des zones d'enregistrement (Zi) et étant apte à transmettre, à destination d'un serveur, des messages de taille maximum fixée (Tmax), ledit programme comprenant des instructions pour exécuter les étapes d'un procédé selon l'une quelconque des revendications 1 à 8. 10.Procédé de traitement, par un serveur (Si), d'un message (SMSI, SMS2) délivrant des données mémorisées dans certaines au moins des zones d'enregistrement (Zi) d'un terminal (3), ledit procédé de traitement mettant en oeuvre au moins les étapes suivantes: - identifier au moins une valeur de taille (tM;;tN;) indiquée dans le message reçu et extraire du message, en fonction d'au moins ladite valeur de taille, un groupe de données (Ci) associé à une zone respective et comportant un ensemble de données (Mi;Ni) de taille égale à la valeur de taille identifiée; identifier ladite zone en fonction d'au moins un ordre de zones fixé préalablement et de la position du groupe de données dans le message; enregistrer au moins l'ensemble de données en association avec ladite zone identifiée. 11. Module (6) adapté pour être intégré dans un terminal (3) comportant des données mémorisées dans des zones d'enregistrement (Zi) et étant apte à transmettre à un serveur (Si) des messages de taille maximum fixée (Tmax), ledit module comportant des moyens pour mettre en oeuvre un procédé de transmission selon l'une des revendications 1 à 8. 12. Terminal (3) comportant des données mémorisées dans des zones d'enregistrement (Zi) et étant apte à transmettre à un serveur (SI) des messages de taille maximum fixée (Tmax), ledit terminal comportant un module (6) selon la revendication 11. 13. Module logiciel (5') adapté pour être intégré dans un serveur (SI) et pour traiter au moins un message (SMS1;SMS2) en provenance d'un terminal (3) et délivrant des informations relatives à des données mémorisées dans des zones d'enregistrement (Zi) du terminal, ledit module comportant des instructions logicielles aptes à commander l'exécution des étapes d'un procédé selon la revendication 10. 14. Serveur (SI) pour traiter au moins un message (SMS1;SMS2) en provenance d'un terminal (3) et délivrant des informations relatives à des données mémorisées dans des zones d'enregistrement (Zi) du terminal, comportant un module (5') selon la revendication 13.