FR2823330A1

FR2823330A1 - Procede et systeme de gestion de donnees destinees a etre stockees dans une memoire, par exemple du code d'une application charge dans une carte a puce programmable

Info

Publication number: FR2823330A1
Application number: FR0104889A
Authority: FR
Inventors: Jean Jacques Vandewalle; Laurent Lagosanto; Francois Millet
Original assignee: Gemplus Card International SA; Gemplus SA
Current assignee: Gemplus SA
Priority date: 2001-04-10
Filing date: 2001-04-10
Publication date: 2002-10-11
Anticipated expiration: 2021-04-10
Also published as: EP1388134A1; CN1514987A; FR2823330B1; US20040144838A1; US7025261B2; CN1273943C; WO2002084610A1

Abstract

L'invention prévoit la gestion de données destinées à être stockées dans une mémoire (6), celle-ci étant destinées à différentes gestions dont au moins un premier et un second mode de gestion. Dans ce cadre l'invention prévoit de : - fournir une identification, lors d'une phase d'élaboration des données, permettant d'identifier respectivement les données destinées à être gérées suivant les différents modes, et- gérer le stockage et / ou l'exploitation des données sur la base de ladite identification fournie (E6, P1).La mémoire peut être située dans une carte à puce programmable. Les données peuvent alors comprendre du code relatif à une application dont une partie (code administratif) est destinée à personnaliser l'application lors d'une phase initiale, l'identification se rapportant aux données relatives à cette partie de code.

Description

PROCEDE ET SYSTEME DE GESTION DE DONNEES DESTINEES A ETRE STOCKEES DANS UNE MEMOIR, PAR EXEMPLE DU CODE D'UNE APPLICATION CHARGE DANS UNE
CARTE A PUCE PROGRAMMABLE
L'invention concerne la gestion de données à charger en mémoire pour une optimisation des possibilités de stockage. Les données en question peuvent être notamment du code constitutif d'un programme du type"application", destiné à être chargé dans une mémoire d'un dispositif communicant, tel qu'une carte à puce programmable ou analogue.

Avec l'avènement des cartes à puce programmables, il est possible d'y charger des applications de services, c'est-à-dire des programmes logiciels exécutables, provenant de sources diverses.

A cette fin, une carte ouverte comporte des espaces mémoire ré-inscriptibles pour emmagasiner de manière évolutive une ou plusieurs applications de services selon son utilisation, à l'instar d'un disque dur d'un ordinateur personnel, ainsi qu'un processeur apte à exécuter de telles applications.

Ces applications de services, aussi connues par le terme anglo-saxon de"card applets", sont généralement conçues par les fournisseurs de services autorisés par l'émetteur de cartes à puce, par exemple des organismes bancaires, de santé, des distributeurs et autres prestataires de services.

Elles se présentent sous forme de programmes complexes, généralement conçus au moyen de langages évolués tels que Java, C++, Microsoft Windows Basic, de façon à être transférés en bloc dans la mémoire de la carte, soit lors de sa fabrication (chargement en pré-émission), soit ultérieurement au cours de son utilisation (chargement en post-émission).

Du fait que les applications de services proviennent d'une source extérieure au fabricant de la carte qui doit l'intégrer, ce dernier n'a pas une connaissance détaillée de leur code et ne peut donc établir une gestion adaptée pour son stockage.

En particulier, le fabricant ne peut pas prévoir une gestion différente des parties du code d'une application selon qu'elles relèvent de la personnalisation, dont l'utilité n'est que provisoire, ou des autres parties qui peuvent servir à tout moment.

On rappelle que la personnalisation d'une application est une suite d'opérations effectuées à un stade initial qui permet de l'individualiser par rapport au titulaire de la carte. Le code de personnalisation contient différentes commandes, dites"administratives", par exemple pour charger des registres avec des codes d'identification, d'autorisation, et autres données personnelles, et pour configurer l'application en fonction de choix ou de limites établies selon le titulaire, etc.

Lors de la phase de personnalisation, l'application est activée, éventuellement en coopération avec un programme interne de gestion de la carte, pour exécuter l'ensemble des commandes administratives nécessaires à la personnalisation.

Une fois cette personnalisation correctement réalisée, les commandes administratives n'ont plus aucune utilité, mais demeurent en mémoire avec le reste de l'application, faute de pouvoir les gérer à part. Or, ces commandes administratives peuvent représenter quelques dizaines de pour cent de la place totale occupée en mémoire par l'application concernée, ce qui limite d'autant la capacité de la carte à puce à accepter de nouvelles applications.

Au vu de ce qui précède, l'invention a pour objet de prévoir une identification des parties d'un ensemble de données à stocker en mémoire qui peuvent donc être gérées séparément afin de pouvoir optimiser la capacité de stockage. Ainsi, dans le cas de l'exemple précité, où les données concernent l'ensemble du code formant une application à personnaliser, les parties correspondantes aux commandes administratives de personnalisation seront identifiées (i. e. indiquées) comme telles dans le code, selon une convention établie, de manière qu'elles puissent être reconnues et gérées séparément au sein de la carte, notamment pour libérer l'espace qu'elles occupent en mémoire une fois la personnalisation réalisée.

Selon un premier aspect, l'invention concerne un procédé de gestion de données destinées à être stockées dans une mémoire, les données étant destinées à être gérées suivant au moins deux modes, caractérisé en ce qu'il comprend les étapes de : - fournir une identification, lors d'une phase d'élaboration des données, permettant d'identifier respectivement les données destinées à être gérées suivant les différents modes, et - gérer le stockage et/ou l'exploitation des données sur la base de l'identification fournie.

Dans le cadre de ce procédé, les données destinées à un premier mode de gestion peuvent être des données dont l'utilité n'est que provisoire relativement aux données destinées aux autres modes de gestion.

Dans ce cas, l'invention aura plus particulièrement pour objet un procédé de gestion de données destinées à être stockées dans une mémoire, caractérisé en ce qu'il comprend les étapes de :

- fournir une identification, lors d'une phase d'élaboration des données, de celles des données dont l'utilité n'est que provisoire relativement aux autres données, et - gérer le stockage des données sur la base de l'identification fournie.

Avantageusement, l'identification est intégrée aux données.

Dans une application envisagée, les données comprennent du code relatif à un programme exécutable dont une partie, identifiée comme étant destinée à un premier mode de gestion, se rapporte au code destiné à n'être utilisé que lors d'une phase initiale du programme.

La mémoire peut être située dans un dispositif communicant, tel qu'une carte à puce, les données comprenant du code relatif à une application dont une partie, identifiée comme destinée à un premier mode de gestion, se rapporte au code de personnalisation de l'application lors d'une phase initiale.

Avantageusement, l'étape de gérer le stockage de données comprend les sous-étapes de : - établir les adresses en mémoire des données identifiées, - détecter la fin de l'utilité des données identifiées, et - autoriser ensuite la réutilisation d'une partie au moins desdites adresses pour le stockage ultérieur d'autres données à ces adresses.

Cette étape peut comprendre en outre une étape d'effacement des données identifiées après l'étape de détection de fin d'utilité.

Dans ce cas, on peut prévoir l'aiguillage des données identifiées vers une zone de la mémoire

spécifique destinée à une opération d'effacement ou de réécriture après leur période d'utilité.

On peut envisager, lorsque les données sont relatives à un programme écrit en langage de haut niveau, de fournir l'identification au niveau de ce langage.

A titre d'exemple, lorsque le langage comporte des modules, l'identification peut être fournie par une technique de nommage, où l'on attribue au ou à chaque module du programme associé aux données à identifier, un nom identifiable selon une convention établie.

Lorsque le langage est typé, l'identification peut être fournie par une technique de typage, où l'on confère, à un ou chaque type dudit programme associé aux données à identifier, un lien de sous typage à un type spécifié identifiable selon une convention établie.

Dans le cas d'un langage typé du genre orienté objet, le typage s'opère en conférant à l'une ou chaque classe du programme associée aux données à identifier, un lien d'héritage à une classe spécifiée, identifiable selon la convention établie.

On peut aussi envisager de prévoir l'identification au niveau de la présentation des données lors du stockage.

Par exemple, si les données sont élaborées sous forme de fichiers ou analogue, l'identification peut être fournie en désignant le ou les fichier (s) associé (s) aux données à identifier, selon une convention établie.

Si les données sont élaborées sous forme de code d'instructions, l'identification peut être fournie par étiquetage des instructions relatives aux données à identifier, selon une convention établie,

l'étiquetage étant apposé à chaque instruction concernée ou bornant des groupes d'instructions concernées.

Avantageusement, le procédé peut prévoir en outre une étape de contrôle de la bonne identification des données d'utilité provisoire relativement aux autres données qui elles sont appelées à persister en mémoire, la vérification consistant à s'assurer que les données identifiées comme n'étant que d'utilité provisoire ne sont pas appelées par lesdites autres données.

Dans le cas où les données identifiées correspondent à du code d'une partie d'un programme destinée à n'être utilisée que lors d'une phase initiale du programme, et les autres données correspondent à du code du reste dudit programme, l'analyse peut consister à vérifier qu'aucune instruction du code du reste du programme ne fait appel à des instructions du code utilisées que lors d'une phase initiale du programme.

Avec la vérification, on peut prévoir aussi une étape de maintien en mémoire des données identifiées comme n'étant d'utilité qu'à titre provisoire, au même titre que les autres données stockées, si l'étape de vérification fait apparaître une erreur d'identification.

L'invention peut s'appliquer à d'autres types de gestion que celles relatives à des données d'utilité provisoire par rapport à d'autres. En effet, la gestion permise par l'identification peut servir aussi notamment pour : - déterminer l'emplacement des données dans la mémoire, cet emplacement étant fonction de l'identification ;

- la gestion concernant l'acheminement desdites données au sein du dispositif, cet acheminement étant fonction de ladite identification. A titre d'exemple pris dans le cadre d'un dispositif multiprocesseur tel qu'une carte à puce disposant de tels moyens, l'acheminement peut s'effectuer vers l'un parmi plusieurs processeurs, sélectionné en fonction de ladite identification ; - la gestion concernant le cryptage de données, le cryptage ou non cryptage desdites données étant fonction de ladite identification ; - la gestion concernant le contrôle d'intégrité des données, lesdites données étant soumises à contrôle d'intégrité en fonction de ladite identification ; - etc.

Selon un deuxième aspect, l'invention concerne un système de gestion de données destinées à être stockées dans une mémoire, les données étant destinées à être gérées suivant au moins deux modes, caractérisé en ce qu'il comprend : - des moyens d'identification pour fournir une identification, lors d'une phase d'élaboration des données, permettant d'identifier respectivement les données destinées à être gérées suivant les différents modes, et des moyens de gestion de stockage et/ou d'exploitation des données fonctionnant sur la base de ladite identification fournie.

Les aspects optionnels de l'invention présentés plus haut dans le cadre du procédé peuvent s'appliquer mutatis mutandis à ce système.

Selon un troisième aspect, l'invention concerne une carte à puce programmable, comprenant une

première mémoire programmable destinée au stockage de code constitutif d'une application, et une deuxième mémoire contenant des instructions permettant de reconnaître une identification, selon une convention établie, du code administratif d'une application chargée, ce code étant destiné à personnaliser l'application lors d'une phase initiale.

Dans un mode de réalisation envisagé, la deuxième mémoire comporte en outre des instructions d'autorisation d'effacement du code administratif de la première mémoire actifs après la fin de la personnalisation de l'application.

L'invention et les avantages qui en découlent apparaîtront plus clairement à la lecture de la description suivante des modes de réalisation préférés, donnés purement à titre d'exemple nonlimitatif, avec référence aux dessins en annexe dont la figure 1 est un schéma synoptique

simplifié des principaux éléments d'une carte à puce , la figure 2 est un organigramme d'un protocole d'identification des parties du code administratif d'une application destinée à la carte à puce de la figure 1, conformément à l'invention, la figure 3 est un organigramme d'une procédure de chargement d'application en carte et de gestion de mémoire programmable utilisée dans le protocole de la figure 2, et la figure 4 est un organigramme d'une variante de celui de la figure 3, qui incorpore des mesures de vérification de l'identification des données.

Les éléments fonctionnels de base d'une carte à puce programmable 1 sont représentés de manière

synoptique dans le schéma bloc de la figure 1. Au coeur se situe un microprocesseur (CPU) 2 qui assure toutes les fonctions de gestion interne de la carte, ainsi que l'exécution des applications qui y sont programmées. Le microprocesseur est relié, par un système de bus internes 4, à trois types de mémoire : - une mémoire programmable du type à lecture uniquement (ROM) mais effaçable et programmable électriquement (EEPROM) 6. Cette mémoire est destinée à être chargée avec une ou plusieurs applications de service (s) pouvant être exécutée (s) par le microprocesseur 2 ; - une mémoire du type ROM masque 8, contenant l'ensemble du code et des valeurs d'un logiciel de gestion interne de la carte. Ces données sont inscrites lors de la fabrication de la puce, au niveau des masques de dépôt des couches. Le contenu de la mémoire ROM masque 8 étant très fortement lié aux moyens matériels de la carte à puce, le code est normalement établi par le fabricant de la carte ; et - une mémoire du type à accès aléatoire (RAM) 10 destinée au stockage de données provisoires, telles que des contenus de registres, blocs de code à charger dans le microprocesseur, etc.

Le bus interne 4 est par ailleurs relié à une interface de communication 12 qui constitue un port d'entrée et de sortie de données vis-à-vis du monde extérieur, et qui assure l'alimentation électrique de la carte 1. Cette interface peut être sous forme de plots de connexion destinés à s'engager avec des contacts respectifs d'un lecteur, et/ou d'une antenne dans le cas d'une carte dite sans contact.

L'interface de communication 12 sert entre autres pour l'échange bidirectionnel de données avec une

borne prévue pour le chargement d'une application dans le mémoire EEPROM 6.

Appliquée à ce contexte de cartes à puce programmables ouvertes, l'invention prévoit une convention entre d'une part le concepteur de l'application de service et d'autre part le fabricant de cartes, visant à identifier de manière stricte le code de personnalisation i. e. "administratif" (celui utilisé uniquement pour la personnalisation) par rapport au reste du code, i. e. le code"fonctionnel" utilisé par l'application cliente. Cette identification est inscrite dans l'application de service par le concepteur et est reconnue au niveau du logiciel de gestion stocké dans la mémoire masque 8.

La gestion de la mémoire EEPROM 6 pourra alors être établie en fonction de cette reconnaissance, notamment en prévoyant un effacement, ou un compactage des données se trouvant aux adresses affectées au stockage du code administratif une fois la personnalisation achevée.

Le concept général d'une telle exploitation de l'identification du code administratif est illustré par les organigrammes des figures 2 et 3.

A un stade initial, le concepteur C de l'application de service et le fabricant F de cartes à puce programmables s'entendent sur une convention d'identification du code administratif (étape E2).

Cette convention assure l'interopérabilité entre la carte et l'application de service.

Sur la base de cette convention, le concepteur fournit une identification du code administratif dans son application (par marquage, nommage, étiquetage, etc. ) (étape E4). Les informations constitutives de

cette identification sont intégrées avec l'ensemble des données qui constituent le code de l'application.

De son côté, le fabricant inscrit dans la mémoire ROM masque 8 les commandes nécessaires à la reconnaissance du code ainsi identifié et à la gestion en mémoire EEPROM 6 de ce code, conformément à une procédure Pl de chargement en carte et de gestion mémoire décrite plus bas ci-après (étape E6).

Le concepteur, ici assimilé au propriétaire exploitant de l'application, diffuse l'application en vue de son intégration dans la carte à puce (étape E8). A cette fin, il la transmet au fabricant pour chargement sur des cartes vierges depuis une borne en usine (chargement en pré-émission) et, le cas échéant, sur des bornes"usager"B2 pour chargement par les détenteurs des cartes à puce (chargement en post-émission). A titre d'exemple, un détenteur peut charger, par le biais d'une borne B2, une application pour un nouveau service commercial qu'il souhaite utiliser.

Le chargement de l'application, que ce soit par une borne BI en usine ou par une borne"usager"B2, se réalise avec l'exécution en tâche de fond de la

procédure PI, qui sera décrite plus particulièrement par référence à la figure 3. De manière générale, la borne B1 ou B2 comporte un programme qui gère le chargement d'une application en ayant identifié d'un côté le code de personnalisation et de l'autre le code applicatif (fonctionnel). Ce programme va charger depuis la borne BI ou B2 tout le code de l'application et, en cas de demande de personnalisation immédiate, engager la phase de personnalisation avec transmission des ordres nécessaires.

La procédure débute par la détection d'un chargement dans la mémoire EEPROM 6 d'une application dans la carte à puce 1 (étape E10). Lorsqu'un chargement d'application est détecté, on analyse le flux de données qui constituent le code pour y identifier les données relatives au code administratif (étape E12). Cette identification est réalisée au moyen des commandes de reconnaissance établies lors de l'étape E6, sur la base de la convention d'identification.

On établit alors les adresses en EEPROM 6 auxquelles sont affectées les données du code administratif (étape E14). Cette étape peut être réalisée de deux manières : - passive, c'est-à-dire en répertoriant dans un registre (en EEPROM 6 ou RAM 10) les séries d'adresses occupées par les données du code administratif, sans intervenir sur le choix de ces adresses, ou - dynamique, en dirigeant les données du code administratif sur des zones d'adresses en EEPROM 6 déterminées, à l'écart des autres données formant le reste du code.

Ce processus d'établissement continue jusqu'à la détection de la fin du chargement de l'application (étape E16).

On obtient ainsi une carte chargée de son application, avec identification en interne des adresses en EEPROM 6 occupées par le code administratif. La procédure passe alors en phase d'attente d'une demande de personnalisation, c'est-àdire de l'exécution du code administratif, vis-à-vis de l'application chargée. La personnalisation peut intervenir à tout moment après le chargement de l'application. Typiquement, elle s'opère par

insertion de la carte dans une borne prévue à cet effet (par exemple un terminal bancaire) à une occasion choisie arbitrairement par le détenteur de la carte.

A chaque fois que la carte 1 est mise en communication avec une borne, la procédure Pl intervient de nouveau pour déterminer si une demande de personnalisation a été formulée (étape E18). Si tel est le cas, le programme de personnalisation chargé en mémoire EEPROM 6 est exécuté de manière classique (étape E20). La personnalisation implique typiquement un dialogue entre la carte et la borne, cette dernière permettant au prestataire de services d'inscrire des données personnelles (codes d'identification, mot de passe, options choisies, etc. ) via des commandes administratives. La personnalisation va alors configurer l'application au sein de la carte en tenant compte de ces données personnelles (par exemple pour vérifier le code personnel à chaque utilisation, gérer des échanges selon des options choisies, etc. ). On note que la personnalisation s'opère au stade initial de l'application, une fois pour toute ; la configuration de l'application sur la base des données personnelles est ensuite gelée. Ainsi, le code administratif n'a plus d'utilité une fois que la personnalisation est terminée.

A la fin de la personnalisation (étape E12), détectée par exemple en restant en attente d'une commande ou d'un code spécifique à la terminaison, la procédure autorise la réutilisation des adresses du code administratif localisées à l'étape E14 (étape E24). Cette autorisation permet plusieurs possibilités de gestion de l'espace mémoire EEPROM 6 :

l'inscription de nouvelles données aux adresses précédemment occupées par le code administratif, par exemple lors d'un chargement d'une autre application. Dans ce cas, le code administratif pourra rester présent jusqu'à ce que ces adresses en mémoire EEPROM 6 soient réquisitionnées pour d'autres données, - l'effacement physique des données du code administratif, immédiatement après l'autorisation, par une routine exécutée par le programme de chargement de la borne ou par le programme de gestion interne, ou encore le compactage des données du code administratif, rendant disponible une partie des adresses précédemment occupées.

Cette étape E24 peut être mise en oeuvre par le programme de gestion interne de la carte 1 selon des techniques classiques d'identification des adresses libres en mémoire EEPROM 6.

Quelle que soit la possibilité choisie, la gestion permet de récupérer la place en mémoire EEPROM 6 occupée inutilement par le code de personnalisation après son exécution.

L'identification du code de personnalisation peut se réaliser de très nombreuses façons différentes, dont quelques exemples seront donnés ciaprès.

Les exemples sont décomposés en deux familles : une qui dépend du langage de programmation utilisé pour développer l'application, et une qui dépend de la façon dont est stocké le code de l'application (dans des fichiers).

1. Identification du code de personnalisation par le langage de programmation.

De nos jours, la programmation des cartes à puce se fait par des langages relativement évolués. Il ne s'agit plus de manipuler des grandes suites d'instructions avec découpage de très bas niveau (proche de la machine), mais d'utiliser une plus grande abstraction dans lequel on regroupe des instructions en procédures écrites en Pascal, Ada, C, etc. Dans des langages plus évolués encore, on passe à des niveaux où on regroupe des ensembles de fonctions que l'on dénomme des modules. Avec des langages de niveau encore plus haut (Java, C++, etc.), on regroupe à la fois les procédures et les données qui concernent un même élément dans ce que l'on désigne un module ou une classe.

Ces langages évolués fournissent des abstractions de haut niveau qui peuvent être exploitées pour identifier le code administratif de manière appropriée, conformément à l'invention.

Une première approche consiste à déclarer que tout ce qui relève du code administratif est mis dans un module déterminé. A cette fin, on peut procéder selon deux façons : par"nommage"ou par"typage".

Le nommage consiste à nommer ce (s) module (s) par une expression permettant à un tiers de le (s) reconnaître comme contenant le code de personnalisation, par exemple en attribuant au module le préfixe"perso", ou tout autre préfixe établi selon une convention de nommage entre le fabricant de cartes et le concepteur d'applications clientes à l'étape E2 précitée. Bien entendu, les autres modules contenant le reste du code ne doivent pas utiliser ce préfixe. De la sorte, le logiciel de gestion stocké dans la mémoire ROM masque 8 de la

carte peut, en lisant les noms de modules, savoir où se trouvent les parties de code destinées à la personnalisation et agir en conséquence, par exemple en les mettant à des adresses de cellules qui seront soumises à une phase d'effacement après la personnalisation (cf. figure 3, étapes E12, E14).

L'approche basée sur le typage s'adresse aux langages orientés objet. Ces langages font appel à des"classes", assimilables à des modules, chacune définissant un"type"de données et de traitements associés. Ces types sont organisés selon une hiérarchie de types, allant du plus général au plus spécifique, i. e. on trouve généralement un type de base à partir duquel sont rattachés les classes et leurs instances selon des liens de dépendance établis, dits"d'héritage", une classe"héritant"de toutes les classes desquels elle dépend dans la hiérarchie. On peut ainsi spécifier que les classes de personnalisation"héritent"d'une classe spécifique dédiée à la personnalisation, désigné selon la convention fixée à l'étape E2, par exemple "perso". Le code des autres classes n'hérite pas de cette classe"perso". La classe"perso"peut être vide, s'agissant alors d'une coquille servant uniquement à créer les liens d'héritage. Lors de la programmation, on s'assure que les codes liés à la personnalisation sont regroupés dans des classes qui héritent de cette classe"perso".

Au niveau de la carte à puce, le logiciel de gestion en ROM masque 8 réalise une analyse de types lors de la réception du code (cf figure 3, étape E12), dans le but de déterminer les types des modules contenus dans le programme. Le type du module spécifie ses liens hiérarchiques ascendants. On peut ainsi déterminer par le type d'un module si ce

dernier hérite, à un niveau hiérarchique quelconque, du module"perso". Si tel est le cas, on considère que le module en question comporte du code de personnalisation, à gérer en tant que tel à l'étape
E14.

2. Identification du code de personnalisation par le stockage du code de l'application.

Les deux approches venant d'être décrites interviennent au moment où le concepteur développeur crée son application.

Deux autres techniques peuvent être envisagées, qui interviennent non pas lors de la conception de l'application, mais au moment de la transmission de l'application au fabricant :
1. le concepteur transmet les codes liés à la personnalisation dans un fichier séparé du ou des fichiers contenant le reste du code. Le fichier séparé, identifiable comme tel lors du chargement de l'application (figure 3, étape E12), peut alors être localisé en mémoire (étape E14).

2. l'étiquetage, où l'on transmet un fichier contenant l'ensemble du code de l'application (code administratif et autres codes). Ce fichier se présente sous la forme d'une suite d'instructions (par exemple de 0 à n). Les instructions dans cette suite relatives à la personnalisation sont alors signalées par un étiquetage (connu également par l'expression anglo-saxonne"tag") selon une convention établie lors de l'étape E2 précitée. A titre d'exemple, une suite d'instructions de personnalisation débutera par une étiquette"début de code personnalisation"et terminera par une étiquette "fin de code de personnalisation".

On peut associer une étiquette devant chaque code de personnalisation. Dans ce cas, il convient

de tenir compte des liens entre les codes lorsque l'on dissocie les instructions.

Il sera maintenant décrit par référence à la figure 4 une variante de la procédure Pl de la figure 3, qui diffère de celle-ci essentiellement par le fait qu'elle intègre une étape de vérification visant à déterminer s'il n'y a pas d'erreur dans l'identification. Les étapes E10-E24 de la figure 4 sont identiques à celles correspondantes de la figure 3 et ne seront pas décrites à nouveau par souci de concision.

Quel que soit le moyen utilisé pour identifier les codes de personnalisation parmi les codes de l'application, il peut se produire que du code fonctionnel soit identifié par erreur comme du code de personnalisation. Ce code serait alors susceptible d'être effacé (étape E24) avec pour conséquence un dysfonctionnement de l'application.

Pour prévenir cette source d'erreur, la variante prévoit en outre une étape de vérification préalable à l'étape d'autorisation d'effacement aux adresses de code de personnalisation. Cette vérification peut intervenir à différents moments de la procédure Pl précitée, ou même à un stade antérieur à son exécution, selon la technique utilisée. Le résultat de la vérification est enregistré de manière accessible durant le chargement du programme ayant fait l'objet de cette vérification. Dans l'exemple, ce résultat est utilisé juste après la fin de personnalisation (étape E22) dans une étape d'aiguillage conditionnel E26 pour déterminer si l'on passe ou pas à l'étape E24 d'autorisation de réutiliser les adresses du code de personnalisation. S'il n'y a pas d'erreur d'identification détectée, la procédure passe par

étape d'autorisation E24 (branche bel), comme dans le cas de la figure 3. S'il y a au moins une erreur d'identification détectée, la procédure contourne l'étape d'autorisation E24. Dans ce cas, les données relatives au code administratif sont maintenues dans la mémoire 6 au même titre que les autres données de l'application.

De manière générale, la vérification consiste à s'assurer que le code fonctionnel ne fait pas appel à du code administratif, par exemple au moyen de l'instruction"go to".

Plusieurs techniques peuvent être envisagées à cet effet. Par exemple, la vérification peut être faite au niveau de la carte 1, après le chargement de l'application. Dans ce cas, la carte est gérée à l'étape E14 pour stocker le code de personnalisation entre deux adresses bornées (AP1-APn), et on vérifie lors de l'exécution du code fonctionnel qu'il n'y a pas de saut à des adresses situées entre API et APn.

La vérification peut aussi s'effectuer à l'extérieur de la carte, en réalisant une analyse de code visant à déterminer si le code fonctionnel fait appel à du code administratif, ce qui indiquerait une erreur de désignation de code administratif.

Par exemple, dans une approche par"typage", on peut vérifier que le code fonctionnel ne fait jamais accès à des objets du type"perso".

Si une telle erreur est détectée suite à la vérification, il sera possible de réagir de manière appropriée, notamment en inhibant l'effacement.

Il est clair que les enseignements de l'invention peuvent revêtir de nombreuses formes équivalentes et s'appliquer à d'autres domaines.

Dans les exemples décrits, l'identification est attachée au code administratif ; toutefois, un effet technique équivalent peut être obtenu en attachant, à l'inverse, une identification au code applicatif.

Dans ce cas, la procédure sera adaptée pour reconnaître le code administratif par l'absence d'identification attachée.

Grâce à l'invention, il est possible de gérer les données stockées dans la mémoire 6 de manière intelligente, en permettant l'élimination de la mémoire des données relatives au code administratif lorsque celles-ci ne sont plus utiles, après la personnalisation. L'espace mémoire ainsi libéré peut donc être ensuite exploité pour le stockage d'autres données, correspondant par exemple à une application additionnelle sur la carte. On obtient donc une optimisation de l'utilisation de l'espace mémoire 6, et un accroissement des possibilités de stockage d'applications ou autres données.

On notera que l'invention n'est nullement limitée aux modes de réalisation venant d'être décrits. En effet, l'invention permet une gestion de nombreux différents paramètres liés à des données, ainsi que mentionné en partie introductive, où l'identification des données peut servir entre autres à : établir un emplacement de stockage en mémoire, établir un acheminement des données correspondantes, par exemple vers un processeur spécifique parmi plusieurs processeurs associés à la mémoire, à déterminer si les données doivent être cryptées ou pas, à déterminer si les données doivent subir un contrôle d'intégrité et/ou les conditions de ce contrôle, etc.

Claims

REVENDICATIONS 1. Procédé de gestion de données destinées à être stockées dans une mémoire (6), lesdites données étant destinées à être gérées suivant deux modes, caractérisé en ce qu'il comprend les étapes de : - fournir une identification, lors d'une phase d'élaboration des données, permettant d'identifier respectivement les données destinées à être gérées suivant les différents modes, et - gérer le stockage et/ou l'exploitation des données sur la base de ladite identification fournie (E6, Pal).

2. Procédé selon la revendication 1, caractérisé en ce que les données destinées au premier mode de gestion sont des données dont l'utilité n'est que provisoire relativement aux données destinées à un second mode de gestion.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que ladite identification est intégrée aux données.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que les données comprennent du code relatif à un programme exécutable dont une partie, identifiée comme étant destinée à un premier mode de gestion, se rapporte au code destiné à n'être utilisé que lors d'une phase initiale du programme.
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que la

<Desc/Clms Page number 22>

mémoire (6) est située dans un dispositif communicant (1), et en ce que les données comprennent du code relatif à une application dont une partie, identifiée comme destinée à un premier mode de gestion, se rapporte au code de personnalisation de l'application lors d'une phase initiale.
6. Procédé selon l'une quelconque des revendications 2 à 5, caractérisé en ce que l'étape de gérer le stockage de données comprend les sous- étapes de : établir les adresses en mémoire des données identifiées (E14),

- détecter la fin de l'utilité des données identifiées (E22), et - autoriser ensuite la réutilisation d'une partie au moins desdites adresses pour le stockage ultérieur d'autres données à ces adresses (E24).
7. Procédé selon la revendication 6, caractérisé en ce que l'étape de gérer le stockage de données comprend en outre une étape d'effacement des données identifiées après l'étape de détection de fin d'utilité.
8. Procédé selon l'une quelconque des revendications 2 à 7, caractérisé en ce que l'étape de gérer le stockage de données comprend l'aiguillage des données identifiées vers une zone de la mémoire spécifique destinée à une opération d'effacement ou de réécriture après leur période d'utilité.
9. Procédé selon l'une quelconque des revendications 2 à 8, caractérisé en ce qu'il

<Desc/Clms Page number 23>

comprend en outre une étape de contrôle de la bonne identification des données d'utilité provisoire relativement aux autres données, ladite vérification consistant à s'assurer que les données identifiées comme n'étant que d'utilité provisoire ne sont appelées par lesdites autres données.
10. Procédé selon la revendication 9, caractérisé en ce qu'il comprend en outre une étape de maintien en mémoire (6) des données identifiées comme n'étant que d'utilité provisoire, au même titre que les autres dites données stockées, si l'étape de vérification fait apparaître une erreur d'identification. il. Procédé selon la revendication 1, caractérisé en ce que la gestion concerne la détermination de l'emplacement desdites données dans la mémoire (6), cet emplacement étant fonction de ladite identification.
12. Procédé selon la revendication 1, caractérisé en ce que la gestion concerne l'acheminement desdites données au sein du dispositif, cet acheminement étant fonction de ladite identification.
13. Procédé selon la revendication 12, caractérisé en ce que l'acheminement est vers l'un parmi plusieurs processeurs, sélectionné en fonction de ladite identification.
14. Procédé selon la revendication 1, caractérisé en ce que la gestion concerne le cryptage

<Desc/Clms Page number 24>

de données, le cryptage ou l'absence de cryptage desdites données étant fonction de ladite identification.
15. Procédé selon la revendication 1, caractérisé en ce que la gestion concerne le contrôle d'intégrité des données, lesdites données étant soumises à contrôle d'intégrité en fonction de ladite identification.
16. Procédé selon l'une quelconque des revendications 1 à 15, caractérisé en ce que les données sont relatives à un programme écrit en langage de haut niveau, et ce que ladite identification est fournie au niveau de ce langage.
17. Procédé selon la revendication 16, caractérisé en ce que ledit langage comporte des modules, et en ce que ladite identification est fournie par une technique de nommage, où l'on attribue, à un ou à chaque module dudit programme associé auxdites données à identifier, un nom identifiable selon une convention établie.
18. Procédé selon la revendication 16, caractérisé en ce que ledit langage est un langage typé, et en ce que ladite identification est fournie par une technique de typage, où l'on confère, à un ou à chaque type dudit programme associé auxdites données à identifier, un lien de sous typage à un type spécifié identifiable selon une convention établie.
19. Procédé selon l'une quelconque des revendications 1 à 18, caractérisé en ce que les

<Desc/Clms Page number 25>

données sont élaborées sous forme de fichiers ou analogue, et en ce que ladite identification est fournie en désignant le ou les fichier (s) associé (s) auxdites données à identifier, selon une convention établie.
20. Procédé selon l'une quelconque des revendications 1 à 18, caractérisé en ce que les données sont élaborées sous forme de code d'instructions, et en ce que ladite identification est fournie par étiquetage des instructions relatives auxdites données à identifier, selon une convention établie, l'étiquetage étant apposé à chaque instruction concernée ou bornant des groupes d'instructions concernées.
21. Procédé selon l'une quelconque des revendications 1 à 20, caractérisé en ce que ladite mémoire (6) est située dans une carte à puce programmable (1).
22. Système de gestion de données destinées à être stockées dans une mémoire (6), lesdites données étant destinées à être gérées suivant au moins deux modes, caractérisé en ce qu'il comprend : - des moyens d'identification pour fournir une identification, lors d'une phase d'élaboration des données, permettant d'identifier respectivement les données destinées à être gérées suivant différents modes, et des moyens de gestion de stockage et/ou d'exploitation des données fonctionnant sur la base

de ladite identification fournie (E6, Pal).

<Desc/Clms Page number 26>
23. Système selon la revendication 22, caractérisé en ce que les données destinées à un premier mode de gestion sont des données dont l'utilité n'est que provisoire relativement aux données destinées à un second mode de gestion.
24. Système selon la revendication 22 ou 23, caractérisé en ce que lesdits moyens d'identification sont prévus pour intégrer ladite identification aux données.
25. Système selon l'une quelconque des revendications 22 à 24, caractérisé en ce que les données comprennent du code relatif à un programme exécutable dont une partie, identifiée comme étant destinée à un premier mode de gestion, se rapporte au code destiné à n'être utilisé que lors d'une phase initiale du programme.
26. Système selon l'une quelconque des revendications 22 à 25, caractérisé en ce que la mémoire (6) est située dans un dispositif communicant (1), et en ce que les données comprennent du code relatif à une application dont une partie, identifiée comme destinée à un premier mode de gestion, se rapporte au code de personnalisation de l'application lors d'une phase initiale.
27. Système selon l'une quelconque des revendications 23 à 26, caractérisé en ce que les moyens de gestion comprennent : - des moyens pour établir les adresses en mémoire des données identifiées (E14),

<Desc/Clms Page number 27>

- des moyens pour détecter la fin de l'utilité des données identifiées (E22), et des moyens pour autoriser ensuite la réutilisation d'une partie au moins desdites adresses pour le stockage ultérieur d'autres données à ces adresses (E24).
28. Système selon la revendication 27, caractérisé en ce que les moyens de gestion comprennent en outre des moyens, actifs après la détection de ladite fin, pour effacer des données identifiées.
29. Système selon l'une quelconque des revendications 22 à 28, caractérisé en ce que les moyens de gestion comprennent des moyens pour aiguiller des données identifiées vers une zone de la mémoire spécifique destinée à une opération d'effacement ou de réécriture après leur période d'utilité.
30. Système selon l'une quelconque des revendications 23 à 29, caractérisé en ce qu'il comprend en outre des moyens de contrôle de la bonne identification des données d'utilité provisoire relativement aux autres données, lesdits moyens de vérification permettant d'établir si les données identifiées comme n'étant que d'utilité provisoire ne sont appelées par lesdites autres données.
31. Système selon la revendication 30, caractérisé en ce qu'il comprend en outre des moyens de maintien en mémoire (6) des données identifiées comme n'étant que d'utilité provisoire, au même titre que les autres dites données stockées, si les moyens

<Desc/Clms Page number 28>

de vérification font apparaître une erreur d'identification.
32. Système selon la revendication 22, caractérisé en ce que les moyens de gestion servent à déterminer l'emplacement desdites données dans la mémoire (6), cet emplacement étant fonction de ladite identification.
33. Système selon la revendication 22, caractérisé en ce que les moyens de gestion servent à établir l'acheminement desdites données au sein du dispositif, cet acheminement étant fonction de ladite identification.
34. Système selon la revendication 32, caractérisé en ce que l'acheminement est vers l'un parmi plusieurs processeurs, sélectionné en fonction de ladite identification.
35. Système selon la revendication 22, caractérisé en ce que les moyens de gestion servent à gérer le cryptage de données, le cryptage ou l'absence de cryptage desdites données étant fonction de ladite identification.
36. Système selon la revendication 22, caractérisé en ce que les moyens de gestion servent à contrôler l'intégrité des données, lesdites données étant soumises à contrôle d'intégrité en fonction de ladite identification.
37. Système selon l'une quelconque des revendications 22 à 36, caractérisé en ce que ladite

<Desc/Clms Page number 29>

mémoire (6) est située dans une carte à puce programmable (1).
38. Carte à puce programmable (1) comprenant une première mémoire programmable (6) destinée au stockage de code constitutif d'une application, et une deuxième mémoire (8) contenant des instructions permettant de reconnaître une identification, selon une convention établie, du code administratif d'une application chargée, ce code étant destiné à personnaliser l'application lors d'une phase initiale.
39. Carte à puce selon la revendication 36, caractérisé en ce que la deuxième mémoire (8) comporte en outre des instructions d'autorisation d'effacement du code administratif de la première mémoire (6) qui sont actives après la fin de la personnalisation de l'application.