Arrière-plan de l'invention

La présente invention porte sur la mise à jour d'une mémoire d'un terminal de télécommunications et concerne plus particulièrement des procédés et dispositifs pour la mise à jour d'une mémoire, par exemple une mémoire cache, d'un terminal de télécommunications à partir de données stockées dans un module d'identité de souscripteur à un réseau de téléphonie mobile avec lequel le terminal peut coopérer.

L'invention trouve une application toute particulière mais non limitative pour la mise à jour optimisée d'une mémoire cache d'un terminal de télécommunication, de type sans fil par exemple.

De façon connue, les terminaux de télécommunication sans fil, tels que les téléphones mobiles ou équivalents par exemple, sont conçus pour coopérer avec un module d'identité de souscripteur à un réseau de téléphonie mobile, dit aussi UICC pour « Universal Integrated Circuit Chip ») ou module UIGC, afin de pouvoir communiquer avec un réseau de télécommunications donné. Un module UICC est parfois appelé plus vulgairement carte SIM. Un module d'identité de souscripteur peut être mis en œuvre dans un composant embarqué ou amovible de type élément sécurisé (eSE ou SE)) qui est un chipset distinct du processeur principal du terminal mobile. Le module d'identité de souscripteur répond par exemple aux spécifications ISO 7816 (norme ETSI TS 102 223), voire à la norme Critères Communs (ISO/CEI 15408). Il peut dialoguer avec le terminal mobile dans lequel il est embarqué ou incorporé, au moyen de trames APDU (pour Application Protocol Data Unit).

Le module UICC permet, au téléphone mobile dans lequel il est généralement inséré ou embarqué, d'interagir avec un réseau de télécommunications. Pour ce faire, le module UICC comprend des informations permettant l'accès au réseau, notamment un identifiant unique IMSI (pour « International Mobile Subscriber Identity») associée à une souscription particulière d'un utilisateur avec l'opérateur de téléphonie associé.

Le module UICC comprend aussi généralement des données stockées dans des fichiers élémentaires. Un fichier élémentaire peut contenir par exemple des données de contact d'un carnet d'adresse (numéro de téléphone, nom, adresse etc.), des SMS, ou d'autres informations utiles. Un téléphone mobile utilisant un module UICC, par exemple, peut accéder à de tels fichiers élémentaires lorsqu'il interagit avec l'utilisateur ou avec le réseau de télécommunications.

En raison du temps relativement long nécessaire au terminal de télécommunications pour accéder aux données contenues dans les fichiers élémentaires du module UICC, et compte tenu de la répétition de ces accès en cours de fonctionnement du terminal, ce dernier (ou plus précisément une interface de communication du terminal telle qu'un modem par exemple) peut être configuré pour mémoriser dans une mémoire cache du terminal des copies des fichiers élémentaires du module UICC afin de réduire les temps d'accès.

Ainsi, lors d'une phase de démarrage du terminal de télécommunications par l'utilisateur, le terminal fait en général une mise à jour complète de sa mémoire cache en stockant tous les fichiers élémentaires qu'il récupère à cet effet depuis le module UICC.

Or, lors de cette mise à jour de la mémoire cache, le terminal doit nécessairement lire et copier dans la mémoire cache tous les fichiers élémentaires du module UICC, quand bien une partie seulement de ces fichiers ont été effectivement modifiés depuis la dernière opération de mise à jour de la mémoire cache.

Autrement dit, la déposante a constaté que le terminal doit obligatoirement lire et copier au démarrage toutes les données des fichiers élémentaires du module UICC y compris les données ne nécessitant pas a priori de mise à jour dans la mémoire cache. En outre, le nombre d'applications et de services mis en uvre sur le module UICC allant croissants, les temps d'accès requis au démarrage pour lire les données des fichiers élémentaires augmentent également au détriment de la rapidité d'exécution et de la qualité de l'expérience générale de l'utilisateur.

Aussi, il existe un besoin pour une solution permettant, lors d'une phase de démarrage du terminal de télécommunications, une mise à jour plus rapide et plus efficace d'une mémoire (une mémoire cache par exemple) du terminal à partir des données contenues dans le module UICC. Objet et résumé de l'invention

A cet effet, la présente invention concerne un procédé de mise à jour du contenu d'une mémoire, par exemple une mémoire cache, d'un terminal de télécommunications apte à coopérer avec un module d'identité de souscripteur pour accéder à un réseau de télécommunications, le procédé étant mis en œuvre par le module d'identité de souscripteur, le procédé comprenant : - détection d'une opération de modification d'au moins un premier fichier élémentaire dans ledit module, et

- génération d'une donnée de mise à jour associée audit au moins un premier fichier élémentaire modifié, et

comprenant lors d'une phase de démarrage du terminal :

- réception d'un message de démarrage en provenance du terminal, puis

- réception d'une requête de sélection, en provenance du terminal, pour permettre au module d'identité de souscripteur d'identifier au moins un deuxième fichier élémentaire à traiter contenu ou qui a été contenu dans le module d'identité de souscripteur,

- sur réception de ladite requête de sélection, envoi de la donnée de mise à jour associée audit au moins un premier fichier élémentaire, et

- réalisation d'une opération de lecture dudit au moins un premier fichier élémentaire ou dudit au moins un deuxième fichier élémentaire à traiter, conformément à une commande de lecture reçue en provenance du terminal en réponse à l'envoi de ladite donnée de mise à jour.

La présente invention présente de nombreux avantages. Le procédé de mise à jour de l'invention permet une mise à jour optimisée de la mémoire (par exemple la mémoire cache) d'un terminal de télécommunications à partir de données contenues dans le module UICC avec lequel le terminal coopère.

Lors du démarrage du terminal, ce dernier est capable de déterminer les fichiers élémentaires qui nécessitent une mise à jour dans la mémoire en question et ne procède alors avantageusement qu'à la lecture de ces seuls fichiers élémentaires dans le module UICC. Comme indiqué précédemment, les opérations de lecture dans le module UICC présent prennent du temps ce qui ralentit donc d'autant la phase de démarrage du terminal. L'invention permet de limiter le nombre d'opérations de lecture à effectuer pour mettre à jour la mémoire, engendrant ainsi un gain de temps au démarrage du terminal, ce qui améliore sensiblement la qualité de l'expérience de l'utilisateur.

Par ailleurs, l'invention présente l'avantage en ce que le terminal est informé au démarrage dès qu'une mise à jour est nécessaire. Le terminal est capable de distinguer le cas où le module UICC considéré ne met pas en œuvre le procédé de l'invention, ou le cas où le module UICC met en œuvre le procédé de l'invention mais aucune mise à jour de la mémoire n'est requise au démarrage du terminal.

D'autre part, il n'est pas nécessaire d'altérer fondamentalement la phase de démarrage du terminal pour mettre en œuvre le terminal. Les modifications requises dans le fonctionnement du terminal peuvent facilement être mises en place pour les terminaux actuels ou futurs.

En outre, l'invention offre si besoin une rétrocompatibilité vis-à-vis des terminaux de télécommunications et les modules UICC qui ne mettent pas en œuvre l'invention. Un terminal de télécommunications conventionnel, par exemple, ne considère pas de données de mise à jour (les objets TLV définis par l'invention par exemple) reçues depuis le module UICC. De même, un module UICC conventionnel ne prend pas en charge la gestion des données de mise à jour s'il ne met pas en œuvre l'invention.

Dans un mode de réalisation particulier, la requête de sélection contient un identifiant de chaque deuxième fichier élémentaire à traiter contenu dans le module d'identité de souscripteur.

Dans un mode de réalisation particulier, ledit au moins un premier fichier élémentaire et ledit au moins un deuxième fichier élémentaire sont identifiés par un même identifiant.

Dans un mode de réalisation particulier, ladite donnée de mise-à-jour générée est un nombre aléatoire ou la valeur d'un compteur, ladite donnée de mise à jour étant modifiée sur détection de chaque opération de modification.

L'utilisation par exemple d'un tel nombre aléatoire est avantageuse en ce qu'elle permet de déterminer simplement si une modification du fichier élémentaire associé a eu lieu, comme décrit plus en détail ultérieurement.

Dans une variante particulière, la donnée de mise à jour est un compteur qui est incrémenté ou décrémenté d'une valeur prédéterminée à chaque détection d'une opération modification.

L'utilisation d'un compteur est avantageuse en ce qu'elle permet de déterminer simplement si une modification du fichier élémentaire associé a eu lieu, comme décrit plus en détail ultérieurement. De plus, cette technique garantit que la donnée de mise à jour DMJ est différente pour chaque modification d'un fichier élémentaire sur une période donnée.

Dans un mode de réalisation particulier, une donnée de statut pouvant prendre une première ou une deuxième valeur est associée à chaque premier fichier élémentaire contenu dans le module d'identité de souscripteur, le procédé comprenant :

sur détection de chaque opération de modification d'un premier fichier élémentaire, affectation de ladite deuxième valeur à la donnée de statut associée audit premier fichier élémentaire,

dans lequel la donnée de mise à jour envoyée par le module d'identité de souscripteur comprend un identifiant de chaque premier fichier élémentaire dont la donnée de statut est à la deuxième valeur. Dans un mode de réalisation particulier, le procédé comprend :

sur détection de chaque opération de modification d'un premier fichier élémentaire, mémorisation d'un identifiant dudit premier fichier élémentaire dans une liste, dans lequel la donnée de mise à jour comprend ladite liste.

Dans un mode particulier de réalisation, les différentes étapes du procédé de mise à jour mis en œuvre par le module d'identité de souscripteur sont déterminées par des instructions de programmes d'ordinateurs.

En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un processeur, ou plus généralement dans un module d'identité de souscripteur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de mise en œuvre d'une mémoire tel que défini ci-dessus.

L'invention vise aussi un support d'enregistrement (ou support d'informations) lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

Corrélativement, l'invention vise un procédé de mise à jour du contenu d'une mémoire, par exemple une mémoire cache, d'un terminal de télécommunications apte à coopérer avec un module d'identité de souscripteur pour accéder à un réseau de télécommunications, le procédé étant mis en œuvre par le terminal de télécommunications, le procédé comprenant lors d'une phase de démarrage du terminal :

- envoi d'un message de démarrage au module d'identité de souscripteur, puis

- envoi d'une requête de sélection, au module d'identité de souscripteur, pour permettre au module d'identité de souscripteur d'identifier au moins un deuxième fichier élémentaire à traiter contenu ou qui a été contenu dans le module d'identité de souscripteur,

- en réponse à ladite requête de sélection, réception d'une donnée de mise à jour associée à au moins un premier fichier élémentaire contenu ou qui a été contenu dans le module d'identité de souscripteur,

- détermination, à partir de ladite donnée de mise à jour reçue, pour chaque deuxième fichier élémentaire à traiter, si ledit deuxième fichier élémentaire a été modifié, et

- dans l'affirmative, une étape de mise à jour dudit au moins un premier fichier élémentaire ou dudit au moins un deuxième fichier élémentaire dans la mémoire du terminal. Les avantages et commentaires indiqués ci-avant en référence au procédé mis en œuvre par le module d'identité de souscripteur s'applique de la même manière au procédé mise en œuvre ici par le terminal et à ses variantes de réalisation.

Dans un mode de réalisation particulier, la requête de sélection contient un identifiant de chaque deuxième fichier élémentaire à traiter contenu dans le module d'identité de souscripteur.

Dans un mode de réalisation particulier, ledit au moins un premier fichier élémentaire et ledit au moins un deuxième fichier élémentaire sont identifiés par un même identifiant.

Dans un mode de réalisation particulier, le procédé comprend :

détermination, d'un identifiant dudit au moins un deuxième fichier élémentaire à traiter ou un identifiant d'un répertoire contenant l'identifiant dudit au moins un deuxième fichier élémentaire, à partir d'une première liste d'au moins un identifiant de fichier élémentaire, ledit répertoire étant contenu dans le module d'identité de souscripteur, et insertion dudit identifiant dans la requête de sélection à envoyer au module d'identité de souscripteur.

Dans un mode de réalisation particulier, le procédé comprend :

enregistrement, préalablement à la phase de démarrage, dans une mémoire non volatile d'une donnée de référence respective en association avec ledit au moins un premier fichier élémentaire à traiter,

dans lequel, lors de ladite détermination, le terminal détermine, à partir d'une comparaison entre ladite donnée de référence associée audit premier fichier élémentaire et ladite donnée de mise à jour correspondante, si ledit fichier élémentaire a été modifié.

Dans un mode de réalisation particulier, le terminal détermine que ledit fichier élémentaire a été modifié lorsque ladite donnée de référence associée audit premier fichier élémentaire et ladite donnée de mise à jour correspondante sont différentes.

Dans un mode de réalisation particulier, la donnée de mise à jour reçue depuis le module d'identité de souscripteur comprend un identifiant de chaque premier fichier élémentaire.

Dans un mode particulier de réalisation, les différentes étapes du procédé mis en œuvre par le terminal sont déterminées par des instructions de programmes d'ordinateurs.

En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un processeur, ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé mis en œuvre par un terminal tel que défini ci-dessus. L'invention vise aussi un support d'enregistrement (ou support d'informations) lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

A noter que les programme mentionnés ci-avant peuvent utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.

De plus, les supports d'enregistrement mentionnés ci-avant peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette {floppy dise) ou un disque dur.

D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

L'invention vis également un procédé de mise à jour du contenu d'une mémoire, par exemple une mémoire cache, d'un terminal de télécommunications apte à coopérer avec un module d'identité de souscripteur pour accéder à un réseau de télécommunications, le procédé étant mis en œuvre :

- par le terminal de télécommunications réalisant un procédé tel que défini ci-avant, et

- le module d'identité de souscripteur réalisant un procédé tel que défini ci-avant. L'invention vise aussi un module d'identité de souscripteur et un terminal aptes à réaliser respectivement les étapes des procédés ci-dessus mis en œuvre par ledit module et ledit terminal.

Plus particulièrement, l'invention vise un module d'identité de souscripteur pour la mise en œuvre d'un procédé de mise à jour du contenu d'une mémoire, par exemple d'une mémoire cache, d'un terminal de télécommunications, ledit module d'identité de souscripteur étant apte à coopérer avec le terminal de télécommunications pour permettre audit terminal d'accéder à un réseau de télécommunications, ledit module d'identité de souscripteur comprenant : - une unité de détection d'une opération de modification d'au moins un premier fichier élémentaire dans ledit module, et

- une unité de génération d'une donnée de mise à jour associée audit au moins premier un fichier élémentaire modifié, et comprenant, lors d'une phase de démarrage du terminal :

- une unité de réception d'un message de démarrage en provenance du terminal,

- une unité de réception d'une requête de sélection, en provenance du terminal, pour permettre au module d'identité de souscripteur d'identifier au moins un deuxième fichier élémentaire à traiter contenu ou qui a été contenu dans le module d'identité de souscripteur,

- une unité d'envoi, sur réception de ladite requête de sélection, de la donnée de mise à jour associée audit au moins un premier fichier élémentaire, et

- une unité de réalisation d'une opération de lecture dudit au moins un premier fichier élémentaire ou dudit au moins un deuxième fichier élémentaire à traiter, conformément à une commande de lecture reçue en provenance du terminal en réponse à l'envoi de ladite donnée de mise à jour.

L'invention vise aussi un terminal de télécommunications pour la mise en œuvre d'un procédé de mise à jour du contenu d'une mémoire, par exemple une mémoire cache, dudit terminal, ledit terminal étant apte à coopérer avec un module d'identité de souscripteur pour accéder à un réseau de télécommunications, le terminal comprenant, lors d'une phase de démarrage du terminal :

- une unité d'envoi d'un message de démarrage au module d'identité de souscripteur,

- une unité d'envoi d'une requête de sélection, au module d'identité de souscripteur, pour permettre au module d'identité de souscripteur d'identifier au moins un deuxième fichier élémentaire à traiter contenu ou qui a été contenu dans le module d'identité de souscripteur,

- unité de réception, en réponse à ladite requête de sélection, d'une donnée de mise à jour associée à au moins un premier fichier élémentaire contenu ou qui a été contenu dans le module d'identité de souscripteur,

- une unité de détermination, à partir de ladite donnée de mise à jour reçue, pour chaque deuxième fichier élémentaire à traiter, si ledit deuxième fichier élémentaire a été modifié, et

- dans l'affirmative, une unité de mise à jour dudit au moins un premier fichier élémentaire ou dudit au moins un deuxième fichier élémentaire dans la mémoire du terminal.

L'invention vise en outre un système de télécommunications comprenant : - un module souscripteur d'identité tel que défini ci-avant, et

- un terminal de télécommunications tel que défini ci-avant, ledit terminal étant apte à coopérer avec le module d'identité de souscripteur pour accéder à un réseau de télécommunications.

Les différents modes de réalisation et variantes définis précédemment en relation avec les procédés de l'invention mis en œuvre par le module d'identité de souscripteur et le terminal s'appliquent respectivement de la même manière au module d'identité de souscripteur et au terminal définis ci-dessus.

L'invention vise également un procédé de mise à jour du contenu d'une mémoire, par exemple une mémoire cache, d'un terminal de télécommunications apte à coopérer avec un module d'identité de souscripteur pour accéder à un réseau de télécommunications, le procédé étant mis en œuvre par le module d'identité de souscripteur, le procédé comprenant :

- détection d'une modification apportée à au moins un fichier élémentaire contenu ou qui a été contenu dans ledit module, et

- génération d'une donnée de mise à jour associée audit au moins un fichier élémentaire modifié, et

comprenant lors d'une phase de démarrage du terminal :

- réception d'un message de démarrage en provenance du terminal, puis

- réception d'une requête de sélection, en provenance du terminal, pour permettre au module d'identité de souscripteur d'identifier au moins un fichier élémentaire à traiter, ce dernier étant contenu dans le module d'identité de souscripteur ou était initialement contenu dans le module d'identité de souscripteur avant ladite modification dudit fichier élémentaire, et

- sur réception de ladite requête de sélection, envoi de la donnée de mise à jour associée à chaque fichier élémentaire à traiter.

Dans un mode particulier, le procédé comprend en outre une opération de lecture d'au moins un fichier élémentaire à traiter, conformément à une commande de lecture reçue en provenance du terminal en réponse à l'envoi de ladite donnée de mise à jour.

L'invention vise en outre un procédé de mise à jour du contenu d'une mémoire, par exemple une mémoire cache, d'un terminal de télécommunications apte à coopérer avec un module d'identité de souscripteur pour accéder à un réseau de télécommunications, le procédé étant mis en œuvre par le terminal de télécommunications, le procédé comprenant lors d'une phase de démarrage du terminal :

- envoi d'un message de démarrage au module d'identité de souscripteur, puis envoi d'une requête de sélection, au module d'identité de souscripteur, pour permettre au module d'identité de souscripteur d'identifier au moins un fichier élémentaire à traiter, ce dernier étant contenu dans ledit module d'identité de souscripteur ou était initialement contenu dans le module d'identité de souscripteur avant ladite modification dudit fichier élémentaire,

en réponse à ladite requête de sélection, réception d'une donnée de mise à jour associée à au moins un premier fichier élémentaire à traiter,

détermination, à partir de ladite donnée de mise à jour reçue, pour chaque deuxième fichier élémentaire à traiter, si ledit fichier élémentaire a été modifié dans le module d'identité de souscripteur, et

dans l'affirmative, une étape de mise à jour dudit fichier élémentaire dans la mémoire du terminal.

Brève description des dessins

D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures:

- la figure 1 représente, de manière schématique, l'architecture matérielle d'un terminal de télécommunications et d'un module d'identité de souscripteur conformes à une mise en œuvre particulière de l'invention ;

- la figure 2 représente, sous forme d'un organigramme, les principales étapes de procédés de mise à jour de mémoire réalisés respectivement par le terminal et par le module d'identité de souscripteur de la figure 1, conformément à un premier mode de réalisation de l'invention ;

- la figure 3 représente schématiquement un exemple de liste d'identifiants de fichiers élémentaires à traiter contenue dans le terminal ;

- la figure 4 représente schématiquement des données de référence mémorisées par le terminal en association avec chaque identifiant de fichier élémentaire, conformément au premier mode de réalisation de l'invention ;

- la figure 5 représente schématiquement des données de mise à jour mémorisées dans le module d'identité de souscripteur en association avec chaque identifiant de fichier élémentaire ;

- la figure 6 représente la structure d'une réponse de données comportant une donnée de mise à jour, envoyée par le module d'identité de souscripteur au terminal conformément à un exemple particulier de réalisation ; la figure 7 représente, sous forme d'un organigramme, les principales étapes de procédés de mise à jour de mémoire réalisés respectivement par le terminal et par le module d'identité de souscripteur de la figure 1 conformément à un deuxième mode de réalisation de l'invention ;

la figure 8 représente schématiquement des données de statut mémorisées par le module d'identité de souscripteur en association avec chaque identifiant de fichier élémentaire, conformément au deuxième mode de réalisation de l'invention ; et

la figure 9 représente, sous forme d'un organigramme, les principales étapes de procédés de mise à jour de mémoire réalisés respectivement par le terminal et par le module d'identité de souscripteur de la figure 1 conformément à un troisième mode de réalisation de l'invention.

Description détaillée de plusieurs modes de réalisation

La présente invention porte sur la mise à jour d'une mémoire d'un terminal de télécommunications et concerne plus particulièrement des procédés et dispositifs pour la mise à jour d'une mémoire, par exemple une mémoire cache, d'un terminal de télécommunications à partir de données stockées dans un module d'identité de souscripteur avec lequel le terminal peut coopérer.

Dans ce document, des exemples de mise en œuvre de l'invention sont décrits en relation avec un téléphone mobile. On comprendra toutefois que l'invention s'applique plus généralement à un quelconque terminal de télécommunications, de préférence sans fil, apte à coopérer avec un module d'identité de souscripteur pour accéder à un réseau de communication. Un tel terminal peut être un téléphone mobile, une tablette, un ordinateur ou équivalent par exemple.

Dans ce document, on nommera un module d'identité de souscripteur par l'expression « module UICC ».

Par ailleurs, les exemples de mise en œuvres ci-dessous concerne la mise à jour d'une mémoire cache. Plus généralement, l'invention s'applique à la mise à jour d'une mémoire quelconque d'un terminal de télécommunications.

La figure 1 représente schématiquement l'architecture matérielle d'un terminal de télécommunications T et d'un module UICC 2 conforme à une mise en œuvre particulière de l'invention. Le module UICC 2 est, dans cet exemple, conforme à la norme ISO 7816.

De plus, le terminal de télécommunications est ici un téléphone mobile apte à coopérer avec le module UICC 2 pour communiquer avec le réseau de télécommunications 4. Le réseau de télécommunications est ici mis à disposition par l'opérateur de téléphonie qui a délivré le module UICC 2. En utilisant le module UICC, le terminal T est par exemple capable de communiquer avec un serveur distant SV via le réseau 4. Le serveur distant SV offre par exemple des services accessibles par le terminal T à l'aide du module UICC 2.

Plus particulièrement, le terminal T comprend un microprocesseur 6, une mémoire morte (de type ROM) 8, une mémoire volatile réinscriptible (de type RAM) 10, une mémoire non volatile réinscriptible (de type EEPROM) 12 et une interface de communication 14 permettant au terminal T de communiquer avec le module UICC 2 et avec le réseau 4.

Dans cet exemple, l'interface de communication 14 est un modem (ou « baseband » en anglais). De plus, le module UICC 2 est ici inséré dans le terminal T lui-même bien que d'autres arrangements soient envisageables. Le système SY comprend ici le terminal T et le module UICC 2. Le module UICC 2 est par exemple inséré ou embarqué dans le terminal T.

L'interface de communication 14 comprend ici un microprocesseur dédié (non représenté) ainsi qu'une mémoire cache 16 et un mémoire non volatile 18. Une liste Ll dont le contenu et l'utilité seront décrits ultérieurement est stockée dans la mémoire 18.

La mémoire non volatile 18 constitue ici un support d'enregistrement conforme à l'invention, lisible par l'interface de communication 14, et sur lequel est enregistré un programme d'ordinateur PG2 conforme à l'invention, comportant des instructions pour l'exécution des étapes, par l'interface de communication 14 et plus généralement par le terminal T, d'un procédé de mise à jour du contenu de la mémoire cache 16 selon l'invention. Les principales étapes de ce procédé sont représentées, dans un premier mode particulier de réalisation de l'invention, sur la figure 2 décrite ultérieurement.

Le module UICC 2 comprend dans cet exemple un microprocesseur 30, une interface de communication 32 apte à communiquer avec l'interface de communication 14, une mémoire volatile réinscriptible (de type RAM) 34, une mémoire non volatile réinscriptible 36 et une mémoire morte (de type ROM) 38.

La mémoire morte 38 constitue ici un support d'enregistrement conforme à l'invention, lisible par le microprocesseur 30, et sur lequel est enregistré un programme d'ordinateur PG1 conforme à l'invention, comportant des instructions pour l'exécution par le module UICC 2 des étapes d'un procédé de mise à jour du contenu de la mémoire cache 16 selon l'invention. Les principales étapes de ce procédé sont représentées, dans un premier mode particulier de réalisation de l'invention, sur la figure 2 décrite ultérieurement. Par ailleurs, le module UICC 2 contient un certain nombre de fichier élémentaires (non représentés) FE1 à FEn (notés collectivement FE) stockés dans une mémoire non volatile (la mémoire EEPROM 12 par exemple) du module UICC 2, n étant un entier naturel non nul. Ces fichiers élémentaires FE peuvent contenir par exemple des données de contact d'un carnet d'adresse (numéro de téléphone, nom, adresse etc.), des SMS, et/ou d'autres informations utiles. Le terminal T peut utiliser ces données lorsqu'il interagit avec l'utilisateur ou avec le réseau de télécommunications 4.

De plus, l'interface de communication 14 et, plus généralement le terminal T, est configuré pour mémoriser dans la mémoire cache 16 les fichiers élémentaires FE contenus dans le module UICC 2.

Lors du démarrage (ou initialisation) du terminal T (sur commande par exemple de l'utilisateur), l'interface de communication 14 est configuré pour mettre à jour le contenu de la mémoire cache 16 à partir des fichiers élémentaires FE contenus dans le module UICC 2. Dans la suite de ce document, on considère de façon plus générale que c'est le terminal 2 qui réalise le procédé de mise à jour de la mémoire cache 16 selon l'invention.

Comme l'a constaté la déposante, le temps d'accès du terminal T lors de la lecture de fichiers élémentaires FE dans le module UICC est relativement long, ce qui détériore la rapidité d'exécution de la séquence de démarrage du terminal T et réduit donc fortement la qualité d'expérience de l'utilisateur.

Aussi, la présente invention propose un procédé de mise à jour optimisé de la mémoire cache 16 du terminal T afin notamment de limiter les opérations de lecture des fichiers élémentaires FE dans le module UICC 2 et ainsi d'accélérer de manière significative la phase de démarrage du terminal T.

Un premier mode de réalisation de l'invention est à présent décrit en référence aux figures 1 à 6. Plus précisément, le module UICC 2 d'une part et le terminal T d'autre part mettent en œuvre des procédés de mise à jour selon l'invention en exécutant respectivement les programmes PG1 et PG2.

Comme représenté en figure 5, dans cet exemple, le module UICC 2 contient en mémoire une donnée de mise à jour DMJ1 à DMJn en association respectivement avec les identifiants ID1 à IDn de chaque fichier élémentaire FE1 à Fen, n étant un entier naturel non nul.

Lors d'une étape B2 illustrée en figure 2, le module UICC 2 détecte qu'une opération de modification d'un ou de plusieurs fichiers élémentaires FE contenus dans ledit module UICC a été réalisée. Autrement dit, le module UICC 2 détecte qu'une modification a été apportée vis-à-vis d'un ou plusieurs fichiers élémentaires FE. Ce processus de détection est par exemple réalisé ponctuellement en réponse à une commande ou sur détection d'un événement, ou en continu entre deux arrêts successifs du terminal T.

Sur chaque détection B2 d'une opération de modification d'un fichier élémentaire FE, le module UICC 2 modifie (B4) la donnée de mise à jour DMJ associée audit fichier élémentaire modifié. Autrement dit, une nouvelle donnée de mise à jour DMJ est générée sur chaque détection B2. Ainsi, la donnée de mise à jour DMJ ainsi généré est différente de la donnée de mise à jour DMJ qui était associée au fichier élémentaire FE correspondant avant l'étape B4 de génération.

A noter qu'une opération de modification au sens de l'invention peut correspondre à la modification de données préexistantes contenues dans un fichier élémentaire, à la suppression de ce fichier élémentaire ou encore à la création d'un nouveau fichier élémentaire. Dans tous les cas, une modification a bien été apportée vis-à-vis du fichier élémentaire concerné.

Dans le cas où la modification considérée comprend la suppression d'un fichier élémentaire FE, l'opération de modification détectée par le module UICC 2 concerne le fichier élémentaire qui était contenu dans le module UICC 2 avant que la modification (i.e. ia suppression) soit réalisée.

On envisage ici le cas où le module UICC 2 détecte (B2) une opération de modification du fichier élémentaire FE2 de sorte que le module UICC 2 modifie la donnée de mise à jour DMJ2 mémorisée en association avec le fichier FE2 (ou plus précisément, avec l'identifiant ID2).

Dans cet exemple, le contenu du fichier élémentaire FE2 a par exemple été modifié lors d'une mise à jour déclenchée par l'utilisateur ou à distance (e.g. modifications de données de contact propres à un profil dans le carnet d'adresse de l'utilisateur).

Selon un premier exemple de réalisation, la valeur de la donnée de mise à jour DMJ est calculée à partir d'une fonction de hachage ayant par exemple comme paramètre le contenu du fichier élémentaire concerné.

Selon un deuxième exemple de réalisation, la donnée de mise à jour DMJ est un nombre aléatoire qui est modifié sur chaque détection B2 d'une opération de modification. De manière préférée, ce nombre aléatoire peut prendre suffisamment de valeurs afin que le risque soit très faible qu'une même valeur soit affectée au nombre aléatoire dans une période de temps réduite.

L'utilisation d'un tel nombre aléatoire est avantageuse en ce qu'elle permet de déterminer simplement si une modification du fichier élémentaire associé a eu lieu, comme décrit plus en détail ultérieurement. Selon un troisième exemple de réalisation, la donnée de mise à jour DMJ est un compteur dont la valeur est modifiée sur chaque détection d'une opération de modification. Dans un exemple particulier, le compteur est incrémenté ou décrémenté d'une valeur prédéterminée à chaque détection B2.

L'utilisation d'un compteur est avantageuse en ce qu'elle permet de déterminer simplement si une modification du fichier élémentaire associé a eu lieu, comme décrit plus en détail ultérieurement. De plus, cette technique garantit que la donnée de mise à jour DMJ est différente pour chaque modification d'un fichier élémentaire sur une période donnée.

On envisage à présent le cas où le terminal T est éteint puis redémarré ultérieurement. Les étapes suivantes du procédé sont donc réalisées lors d'une phase de démarrage (ou d'initialisation) du terminal T qui survient à la mise sous tension A6 du terminal.

Le démarrage A6 du terminal T déclenche ici l'envoi (A8) d'une commande d'initialisation vers le module UICC 2. Cette commande d'initialisation est par exemple une commande ATR (pour « Answer to Reset ») conforme à la norme ISO 7816.

Suite à l'envoi de la commande ATR, le terminal T consulte (A10) la liste Ll stockée dans la mémoire non volatile 18. Le terminal détermine ainsi (A10) l'identifiant ID de chaque fichier élémentaire FE à traiter. La liste Ll contient au moins un identifiant ID d'un fichier élémentaire FE.

Dans l'exemple envisagé ici, la liste Ll contient les identifiants ID2, ID4 et ID5, représentés en figure 3 et correspondant respectivement aux fichiers élémentaires FE2, FE4 et FE5. On considère ici le cas où le terminal T décide de traiter en premier lieu le fichier élémentaire FE2. La suite du procédé peut être répétée pour chaque fichier élémentaire FE identifié dans la liste Ll (à savoir les fichiers élémentaires FE4 et FE5 dans cet exemple).

Dans l'exemple considéré ici, la liste Ll est enregistrée en local dans le terminal T. En variante, la liste Ll est stockée à l'extérieur du terminal T et accessible par ce dernier de façon à réaliser l'étape A10. D'autres mises en œuvre n'impliquant pas l'utilisation d'une telle liste Ll sont également envisageables.

Lors d'une étape A12, le terminal T envoie une requête de sélection (SELECT) au module UICC 2, cette requête contenant ici l'identifiant ID2 du fichier élémentaire FE2. On peut envisager le cas où une telle requête de sélection comprend une pluralité d'identifiants de fichiers élémentaires à traiter.

Dans un exemple particulier, la requête de sélection est une commande APDU dénommée « SELECT FILE », conforme à la norme 7816. La requête SELECT contient ici un paramètre P2=4 qui indique au module UICC 2 qu'il doit renvoyer lors de l'étape B16 à venir notamment la donnée de mise à jour DMJ2.

Après réception (B8) du message de démarrage ATR, le module UICC reçoit (B12) ainsi la requête de sélection SELECT.

Sur réception B12 de la requête SELECT, le module UICC 2 récupère (B14) puis envoie (B16) la donnée de mise à jour DMJ2 stockée dans le module UICC 2 en association avec le fichier élémentaire FE2.

Dans cet exemple, la donnée de mise à jour DMJ2 est envoyée (B16) dans un message REPONSE.

La donnée de mise à jour DMJ2 est par exemple spécifiée dans un ou plusieurs objets

TLV (pour « Tag Length Value ») conformes à la norme ISO 7816-4 ou ETSI TS 102.221. La figure 6 représente une structure du message RESPONSE à titre d'exemple. Dans ce cas, le message REPONSE est un objet TLV 1 dont le tag=62 et la valeur est la donnée FCP définie dans la norme ETSI TS 102.221. Cette valeur contient un deuxième objet TLV 2 dont le tag=82 et la valeur contient des informations propriétaires (tag=A5).

Conformément à l'invention, un troisième objet TLV3 dont le tag =80 est inséré dans les informations propriétaires A5. Cet objet TLV 3 contient en particulier un identifiant unique de mise à jour dont le tag=89. Cet identifiant unique correspond ici à une donnée de mise à jour DMJ au sens de l'invention et prend la forme d'un quatrième objet TLV 4 dont le tag=89 et contenant la valeur de la donnée de mise à jour.

La structure de données de la figure 6 est toutefois proposée à titre purement illustratif, d'autres mises en œuvre de cette donnée de mise à jour étant envisageables dans le cadre de l'invention.

Après réception (A16) de la donnée de mise à jour DMJ2, le terminal détermine (A18), à partir de la donnée de mise à jour DMJ2, si le fichier élémentaire FE2 correspondant a été modifié.

Dans l'exemple considéré ici, on suppose que le terminal T a réalisé, à un instant de référence TR antérieur à l'étape de détection B2 et donc au démarrage A6 du terminal T, une étape d'enregistrement dans sa mémoire non volatile 18 de données de référence DR1 à DRn (nommés collectivement DR) en association avec respectivement les identifiants ID1 à IDn, comme représenté schématiquement en figure 4.

Cet instant de référence TR correspond par exemple au moment où la précédente mise à jour de la mémoire cache 16 a été achevée.

Les données de référence DR sont par exemple égales aux données de mise à jour DMJ qui étaient mémorisés dans le module UICC 2 à l'instant TR. Plus généralement, les données de référence DR indiquent un état de référence des fichiers élémentaires FE stockés dans la mémoire non volatile 18 du terminal T au moment de référence TR.

Dans le cas présent, le terminal T compare à l'étape A18 la donnée de référence DR2 du fichier élémentaire FE2 en cours de traitement avec la donnée de mise à jour correspondante DMJ2 et détermine, à partir de cette comparaison, si le fichier élémentaire FE2 a été modifié.

Plus précisément, dans cet exemple particulier, lorsque le terminal T détecte que la données de référence DR2 et la donnée de mise à jour DMJ2 sont identiques, il en déduit que le fichier élémentaire FE2 n'a pas été modifié (i.e. aucune modification depuis le moment de référence TR mentionné ci-avant). Dans ce cas, le procédé prend fin ou, le cas échéant, le procédé reprend à l'étape A10 pour chaque fichier élémentaire de la liste Ll (i.e. FE4 et FE5 dans cet exemple) qui n'a pas encore été traité.

En revanche, lorsque le terminal T détecte que la donnée de référence DR2 et la donnée de mise à jour DMJ2 ne sont pas identiques, il en déduit que le fichier élémentaire FE2 a été modifié (i.e. il y a eu au moins une modification de FE2 depuis l'instant de référence TR).

Dans une mise en œuvre particulière, le terminal T remplace en outre la donnée de référence DR2 par la donnée de mise à jour DMJ2, une fois l'étape A18 réalisée.

Lorsque le résultat de la comparaison A18 est négatif (modification de FE2 détectée), le terminal T réalise (A20) une étape de mise à jour A26 du fichier élémentaire FE2 dans la mémoire cache 16, à partir du fichier élémentaire FE2 contenu dans le module UICC 2.

Dans cet exemple de réalisation, le terminal T réalise (A20) à cette fin une opération de lecture A20 du fichier FE2 dans le module UICC 2. Au cours de cette étape de lecture, le module UICC 2 autorise (B20) l'accès du terminal T au fichier FE2 contenu dans le module UICC 2. Pour ce faire, le terminal T envoie (A22) ici une commande en lecture CMD contenant l'identifiant ID2 du fichier élémentaire FE2 à lire. Sur réception (B22) de cette commande CMD, le module UICC 2 envoie (B24) au terminal T le fichier FE2 demandé.

Le terminal réalise ensuite l'étape A26 de mise à jour de la mémoire cache 16 à partir du fichier FE2 reçu à l'étape A24.

Dans un exemple particulier, le terminal reprend le procédé à l'étape 10 afin de déterminer les fichiers élémentaires FE qui n'ont pas encore été traités et exécutent ainsi les étapes suivantes (A12 à A26) successivement pour chaque fichier élémentaire indiqué dans la liste Ll.

Dans une variante du premier mode de réalisation décrit ci-dessus en référence à la figure 2, on considère le cas où un fichier élémentaire FE contenu dans le module UICC 2 comprend au moins un identifiant ID d'un autre fichier élémentaire FE dont la mise à jour est nécessaire. On envisage par exemple le cas où le fichier élémentaire FEl dans le module UICC 2 comprend les identifiants ID2 et ID4. Le fichier élémentaire FEl joue alors le rôle d'un répertoire dans lequel sont contenus les identifiants ID2 et ID4.

Dans ce cas, sur réception B12 de la requête SELECT contenant l'identifiant ID2, le module UICC détecte à l'étape B14 que l'identifiant ID2 est contenu dans le fichier élémentaire FEl. Le module UICC envoie (B16) alors au terminal T la donnée de mise à jour DMJl associée au fichier élémentaire FEl. A partir d'une comparaison entre la donnée de mise à jour DMJl et la donnée de référence DR1 associé au fichier FEl, le terminal T détermine (A18) ensuite si au moins un fichier élémentaire dont l'identifiant est contenu dans le fichier élémentaire FEl (à savoir FE2 et FE4 dans cet exemple) a été modifié.

Si tel est le cas, le terminal T procède à la lecture, et si besoin à la mise à jour dans la mémoire cache 16, du fichier FE2. Dans une variante particulière, le terminal T procède en outre à la lecture, et si besoin à la mise à jour dans la mémoire cache 16, du fichier FE4 identifié dans le fichier FEl.

Dans une autre variante, le terminal T sait avant l'envoi A12 que le fichier élémentaire FE2 qu'il souhaite traiter est identifié dans le fichier élémentaire FEl contenu dans le module UICC 2. Dans ce cas, la requête SELECT envoyée par le terminal T à l'étape A12 comprend l'identifiant ID1 et non l'identifiant ID2. A partir de l'identifiant ID1 reçu (B12), le module UICC 2 récupère (B14) la donnée de mise à jour DMJl associé à FEl et envoie (B16) cette donnée de mise à jour au terminal T qui la traite comme décrit dans la précédente variante.

A noter que, dans ce document, sauf indications contraires, les éléments communs à deux modes de réalisation distincts portent les mêmes signes de références et présentent des caractéristiques identiques de sorte qu'ils ne sont pas à nouveau décrits par souci de simplicité.

Un deuxième mode de réalisation de l'invention est à présent décrit en référence principalement aux figures 7 et 8.

Dans ce deuxième mode, des données de statut (ou « tag ») TG1 à TGn (notés collectivement TG) sont mémorisés par le module UICC 2 en association avec les fichiers élémentaires FEl à FEn ou, plus précisément dans cet exemple, en association avec les identifiants respectifs ID1 à IDn, comme représenté schématiquement en figure 8.

Chaque donnée de statut TG peut prendre une première valeur ou une deuxième valeur distincte de la première, à savoir les valeurs '0' et ^Λ respectivement dans le cas présent. Dans cet exemple, les données de statut TG sont par défaut fixées à 0. Toujours dans cet exemple, la gestion des données de statut TG et, plus particulièrement, les étapes B2 à B24 du procédé du point de vue du module UICC 2 sont réalisées par une application ou applet (par exemple un applet JAVACARD) mis en œuvre dans le module UICC 2.

Dans ce deuxième mode de réalisation, le module UICC 2 réalise l'étape B2 comme décrit précédemment. Une modification d'un fichier élémentaire FE est par exemple détectée (B2) lorsqu'un événement prédéfini auquel est abonné le module UICC 2 survient. Cet événement peut être, par exemple, un événement de changement du contenu d'un fichier élémentaire, un événement de suppression ou encore un événement de création d'un fichier élémentaire dans le module UICC 2.

Sur chaque détection d'une opération de modification d'un fichier élémentaire FE dans le module UICC 2, ce dernier affecte (B30) la deuxième valeur (i.e. la valeur 1) à la donnée de statut TG correspondante. Dans cet exemple, on considère le cas où le terminal T détecte (B2) que le fichier élémentaire FE2 a été modifié et affecte (B30) par conséquent la valeur 1 à TG2.

Dans le cas où le couple [ID2, TG2] n'existait pas au moment de la détection B2 d'une modification de FE2, le module UICC 2 créée ce couple et affecte la valeur 1 à TG2.

On suppose ensuite que le terminal T est éteint puis redémarré ultérieurement lors d'une étape A6. Le terminal T et le module UICC 2 réalisent les étapes A8 et B8 comme décrit précédemment en référence au premier mode de réalisation.

Suite à l'étape A8, le terminal T envoie (B31) ici une commande AUDIT, de type APDU dans cet exemple, au module UICC 2. Dans ce mode de réalisation, la commande AUDIT permet au terminal de déterminer en retour tous les fichiers élémentaires qui doivent être mis à jour.

En réponse à la commande AUDIT reçue (B32), le module UICC 2 identifie (B33) tous les fichiers élémentaires FE stockés dans le module UICC 2, dont la donnée de statut TG correspondante est à 1. Le module UICC 2 envoie (34) ensuite au terminal T les identifiants ID de chaque fichier élémentaire dont la donnée de statut TG est à 1.

Les identifiants ID envoyés B34 par le module UICC 2 constituent une donnée de mise à jour au sens de l'invention.

Dans cet exemple, le module UICC 2 détecte B33 que seule la donnée de statut TG2 est à 1 et, par conséquent, envoie (B34) au terminal T l'identifiant ID2 dans un message REPONSE.

Le terminal T réalise alors, à partir des identifiants reçus, une mise à jour A26 du fichier élémentaire FE2 dans la mémoire cache 16. Pour ce faire, les étapes A20, A22, A24 et A26 d'une part, et les étapes B20, B22 et B24 d'autre part, sont réalisées comme précédemment décrites en référence au premier mode de réalisation de l'invention.

Comme indiqué précédemment, la commande AUDIT permet ci-dessus au terminal T de déterminer en retour tous les fichiers élémentaires qui doivent être mis à jour. Aussi, le terminal met à jour (A26) dans la mémoire cache 16 tous les fichiers élémentaires identifiés dans le message REPONSE.

Alternativement, on peut envisager que le terminal T envoie à l'étape B31 une requête de sélection identifiant spécifiquement un ou plusieurs fichiers élémentaires à traiter.

Selon ce mode de réalisation, la donnée de statut étant une donnée binaire, la valeur de la donnée est réinitialisée à la valeur initiale ^Λ 0' après que le procédé de mise-à-jour a été mis en œuvre.

Un troisième mode de réalisation de l'invention est à présent décrit en référence principalement à la figure 9.

Dans ce troisième mode, le module UICC 2 réalise l'étape B2 comme décrite précédemment.

Sur chaque détection B2 d'une opération de modification d'un fichier élémentaire FE stocké dans le module UICC 2, ce dernier mémorise (B40) l'identifiant ID du fichier élémentaire FE concerné dans une liste notée ici L2. Dans cet exemple, la liste L2 est par exemple stockée dans la mémoire non volatile 36. Dans le cas où un identifiant ID est déjà dans la liste L2, il n'est pas nécessaire pour le module UICC 2 d'ajouter à nouveau l'identifiant dans la liste L2 lorsqu'une nouvelle modification du fichier élémentaire FE correspondant est détectée à l'étape B2. La mise à jour de la liste L2 se poursuit par exemple jusqu'à l'arrêt du terminal T et donc du module UICC 2.

De façon analogue au deuxième mode de réalisation, la gestion de la liste L2 et, plus particulièrement, les étapes du procédé du point de vue du module UICC 2 dans ce troisième mode de réalisation sont réalisées par une application ou applet (par exemple un applet JAVACARD) mis en œuvre dans le module UICC 2.

Le terminal T et le module UICC 2 réalisent ici les étapes A6, A8, B8, A10, B31 et B32 comme décrit précédemment en référence aux précédemment modes de réalisation.

En particulier, on suppose que le terminal T est éteint puis redémarré ultérieurement lors de l'étape A6 comme décrit précédemment. Suite à l'étape A10, le terminal T envoie (B31) une commande AUDIT, de type APDU par exemple, au module UICC 2.

En réponse à la commande AUDIT reçue (B32), le module UICC 2 envoie (B42) au terminal T tous les identifiants ID présents dans la liste L2 (dans l'hypothèse où la liste L2 contient au moins un identifiant). On considère ici l'hypothèse où seul l'identifiant ID2 du fichier élémentaire FE2 est présent dans la liste L2 de sorte que le module UICC 2 envoie ID2 au terminal T à l'étape B42. Cet identifiant ID2 constitue dans ce troisième mode de réalisation une donnée de mise à jour DMJ2 au sens de l'invention.

Suite à la réception A42 de l'identifiant ID2, le terminal T réalise la mise à jour A26 du fichier FE2 dans la mémoire cache 16. Pour ce faire, le terminal T et le module UICC procède comme déjà décrit en référence aux précédents modes de réalisation.

En ce qui concerne les deuxième et troisième modes de réalisation décrits précédemment en référence aux figures 7 et 9, il convient de noter que chaque identifiant ID envoyé à l'étape B34 et B42 au terminal T peut correspondre à un élément permettant au terminal d'identifier le fichier élémentaire FE correspondant ou, alternativement, au fichier élémentaire FE lui-même. Dans cette dernière variante, il n'est alors pas nécessaire pour le terminal T de procéder ensuite à l'opération de lecture A20 du fichier élémentaire FE considéré comme précédemment décrit.

Un homme du métier comprendra que les modes de réalisation et variantes décrits ci-avant ne constituent que des exemples non limitatifs de mise en œuvre de l'invention. En particulier, l'homme du métier pourra envisager une quelconque combinaison des variantes et modes de réalisation décrits ci-avant afin de répondre à un besoin bien particulier.

La présente invention présente de nombreux avantages. Le procédé de mise à jour de l'invention permet une mise à jour optimisée de la mémoire (par exemple la mémoire cache) d'un terminal de télécommunications à partir de données contenues dans le module UICC avec lequel le terminal coopère.

Lors du démarrage du terminal, ce dernier est capable de déterminer les fichiers élémentaires qui nécessitent une mise à jour dans la mémoire en question et ne procède alors avantageusement qu'à la lecture de ces seuls fichiers élémentaires dans le module UICC. Comme indiqué précédemment, les opérations de lecture dans le module UICC présent prennent du temps ce qui ralentit donc d'autant la phase de démarrage du terminal. L'invention permet de limiter le nombre d'opérations de lecture à effectuer pour mettre à jour la mémoire, engendrant ainsi un gain de temps au démarrage du terminal, ce qui améliore sensiblement la qualité de l'expérience de l'utilisateur.

Par ailleurs, l'invention présente l'avantage en ce que le terminal est informé au démarrage dès qu'une mise à jour est nécessaire. Le terminal est capable de distinguer le cas où le module UICC considéré ne met pas en œuvre le procédé de l'invention ou le cas où le module UICC met en œuvre le procédé de l'invention mais aucune mise à jour de la mémoire n'est requise au démarrage du terminal. D'autre part, il n'est pas nécessaire d'altérer fondamentalement la phase de démarrage du terminal pour mettre en œuvre le terminal. Les modifications requises dans le fonctionnement du terminal peuvent facilement être mises en place pour les terminaux actuels ou futurs.

En outre, l'invention offre si besoin une rétrocompatibilité vis-à-vis des terminaux de télécommunications et les modules UICC qui ne mettent pas en œuvre l'invention. Un terminal de télécommunications conventionnel, par exemple, ne prend pas en compte les données de mise à jour (les objets TLV par exemple) reçues depuis le module UICC. De même, un module UICC conventionnel ne prend pas en charge la gestion des données de mise à jour s'il ne met pas en œuvre l'invention.