FR 2826747 A1 20030103 FR 0108718 A 20010702 PROCEDE ET DISPOSITIF DE TRAITEMENT DE DONNEES POUR LA PERSONNALISATION D'UNE APPLICATION SUR UN DISPOSITIF COMMUNICANT PORTATIF, PAR EXEMPLE UNE CARTE A PUCE L'invention concerne un procédé et un dispositif de personnalisation ou d'initialisation pour dispositifs communicants portatifs tels que les cartes à puce. Avec l'avènement des cartes à puce programmables ouvertes ou fermées, il est possible de faire exécuter par celles-ci des applications de service, c'est-à-dire des programmes logiciels exécutables, provenant de sources diverses. A cette fin, une carte programmable comporte des espaces mémoire réinscriptibles pour emmagasiner une ou plusieurs applications selon son utilisation, ainsi qu'un processeur apte à exécuter de telles applications. Ces applications de service, aussi connues par le terme anglo-saxon de"applets", se présentent sous forme de programmes complexes, généralement conçus au moyen de langages évolués tels que Java Card, C++, Visual Basic, etc. Chaque application de service comporte une partie"applicative"qui assure l'exécution du programme en mode normal, et une partie"administrative"qui ne sert qu'à un stade initial pour personnaliser l'application au titulaire de la carte. Les données stockées qui constituent les moyens logiciels de cette partie administrative sont désignées"code administratif", ou"code de personnalisation". Ce code peut occuper jusqu'à plusieurs dizaines de pour-cent de l'ensemble du code formant l'application. Dans le contexte de l'invention, le terme"personnalisation"comprend également tout autre processus analogue à exécuter dans une application, tel qu'une initialisation de paramètres. Le code de personnalisation sert notamment au chargement dans la carte de données propres à l'utilisateur, de manière qu'elles puissent être lues et exploitées au besoin lors de l'exécution normale de l'application. De manière classique, le code de personnalisation embarqué dans une carte à puce ou autre dispositif communicant portatif doit assurer les fonctions suivantes : - le dialogue selon un protocole établi avec un programme de personnalisation à l'extérieur de la carte-on distingue alors le code de personnalisation sur carte, contenu dans l'espace mémoire ré-inscriptible, et le code de personnalisation hors carte, contenu par exemple dans un terminal distant ou un serveur ; la reconnaissance des instructions d'identification et de chargement de champs de données destinées à contenir des valeurs spécifiques à la personnalisation ; et - le chargement de ces valeurs de personnalisation dans des registres correspondants de l'espace mémoire de la carte. La figure 1 illustre de manière simplifiée quelques étapes dans le processus classique de chargement de données de personnalisation depuis l'extérieur vers des champs respectifs de stockage d'une carte programmable, lors d'une personnalisation d'une application de cette carte. Dans l'exemple, la carte est reliée par une borne à un serveur ou terminal distant qui renseigne les champs par un code de personnalisation hors carte. Pour chaque champ à renseigner dans la carte, le code de personnalisation hors carte comporte une première instruction, destinée au programme de personnalisation sur carte, qui indique le champ spécifique désigné. Le code de personnalisation sur carte doit reconnaître chacune de ces instructions pour sélectionner le champ désigné et agir en conséquence. Cette reconnaissance nécessite une instruction de décodage spécifique à chaque champ, qui doit être stockée avec le code de personnalisation sur carte. Ensuite, le code de personnalisation hors carte transmet les données personnelles à inscrire dans le champ précédemment désigné. A la réception de ces données, le code de personnalisation sur carte exécute les instructions nécessaires pour les charger dans un registre désigné selon l'instruction précédente. Une fois le premier champ ainsi chargé, le processus se répète de manière identique pour chacun des autres champs. Ainsi, dans l'exemple de la figure 1, n éléments d'information personnelle sont chargés dans des champs respectifs de la carte, chacun étant précédé d'une instruction spécifique qui doit être identifiée par le code de personnalisation sur carte. A titre d'exemple, le processus de personnalisation d'une application destinée à une carte de suivi de prestations médicales peut renseigner les champs suivants : champ 1 = nom, champ 2 = prénom, champ 3 = numéro de sécurité sociale, champ 4 = taille, champ 5 = poids, etc. De manière similaire, le processus de personnalisation d'une autre application, par exemple destinée à une carte bancaire, renseignera les champs suivants : champ 1 = numéro d'identification personnel (PIN), champ 2 = nombre maximal de tentatives de saisie de code, champ 3 = limite de débit hebdomadaire autorisé, champ 4 = code banque, champ 5 = code agence, etc. Les instructions relatives à chaque champ doivent non seulement identifier celui-ci, mais également indiquer la forme des données contenues (nombre et type de caractères, formatage, etc.). Ces éléments d'information étant propres à chaque application, il s'ensuit que chaque application stockée dans une carte doit avoir son code de personnalisation spécifique. La place occupée par ce code de personnalisation sur carte augmente avec le nombre d'applications chargées, et peut occuper au total plusieurs dizaines de pour-cent de l'espace mémoire de la carte dédié aux applications. En résumé, ce procédé classique souffre des inconvénients suivants : il s'accommode difficilement des personnalisations à distance, car le procédé requiert généralement un échange d'un nombre important de commandes, ce qui peut être très difficile à assurer sur un réseau lent ; et - les commandes de personnalisation doivent être codées dans toutes les applications de la carte, ce qui occupe un espace mémoire important dans la carte. Au vu de ce qui précède, l'invention propose une nouvelle approche du problème de personnalisation d'une application, notamment lorsque celle-ci est contenue dans un dispositif communicant portatif tel qu'une carte à puce. Plus particulièrement, l'invention prévoit, selon un premier aspect, un procédé de préparation de données de personnalisation ou d'initialisation pour transmission à un dispositif communicant portatif, par exemple une carte à puce, les données comprenant plusieurs éléments d'information, chacun attribué à un champ exploité par le dispositif, caractérisé en ce que la préparation consiste à créer une concaténation des éléments d'information par des blocs de données respectifs contigus et ordonnancés selon une convention reconnue par le dispositif communicant, sans désignation explicite de champ. De préférence, les blocs de données sont formatés selon plusieurs types préétablis, le nombre d'octets utilisés pour inscrire un élément d'information dans le bloc qui lui est attribué étant fonction du type de ce bloc. On peut envisager plusieurs types précités, dont au moins un type fixe composé d'un nombre fixe d'octets et un format variable composé d'un nombre variable d'octets, ce nombre étant spécifié dans le bloc. Les données peuvent être transmises sous forme cryptée. Selon un deuxième aspect, l'invention concerne un procédé de personnalisation ou d'initialisation d'une application dans un dispositif communicant portatif, par exemple une carte à puce, la personnalisation/initialisation comprenant la réception de données provenant d'une source extérieure pour extraire de ces données des éléments d'information à inscrire dans des champs respectifs, caractérisé en ce qu'il consiste à accepter en entrée lesdites données sous forme d'une concaténation dans lequel lesdits éléments d'information sont définis par des blocs respectifs contigus, ordonnancés selon une convention reconnue par ladite source extérieure et ledit dispositif communicant, sans désignation explicite de champ, chaque élément d'information reçu de ladite concaténation étant identifié en fonction du type et de la position de son bloc de données dans ladite concaténation. Avantageusement, chaque élément d'information est extrait par référence au type de bloc de données dans lequel il est contenu, le type de chaque bloc pour chaque champ étant établi par la convention. De préférence, chaque élément d'information extrait de la concaténation est transféré dans une portion de stockage de champ correspondant du dispositif portatif communicant. Dans les modes de réalisation envisagés, le procédé comprend le renseignement de chaque champ avec la valeur correspondante dans une adresse correspondante du dispositif portatif communicant, par les étapes de : - mémorisation, à un stade initial, de ladite convention pour savoir l'ordre d'apparition des champs dans ladite concaténation et le type de bloc dans lequel est contenue la valeur correspondante, - stockage de la concaténation, et pour chaque renseignement de champ : - émission d'une commande d'extraction de la valeur par désignation du type du bloc de données dans laquelle elle est contenue, l'extraction étant réalisée à partir du premier octet, ou de l'octet suivant de dernier octet précédemment extrait, de ladite concaténation, et - transfert de ladite valeur extraite vers une portion de mémoire du dispositif portatif attribué au champ correspondant. Selon un troisième aspect, l'invention concerne la mise en oeuvre du procédé selon le deuxième aspect dans une carte à puce. Selon un quatrième aspect, l'invention concerne un dispositif de préparation de données de personnalisation ou d'initialisation pour transmission à un dispositif communicant portatif, par exemple une carte à puce, les données comprenant plusieurs éléments d'information, chacun attribué à un champ exploité par ledit dispositif, caractérisé en ce qu'il comprend des moyens pour créer une concaténation desdits éléments d'information par des blocs respectifs contigus ordonnancés selon une convention reconnue par ledit dispositif communicant, sans désignation explicite de champ. Selon un cinquième aspect, l'invention concerne un dispositif de personnalisation ou d'initialisation d'une application dans un dispositif communicant portatif, par exemple une carte à puce, la personnalisation/initialisation comprenant la réception de données provenant d'une source extérieure pour extraire de ces données des éléments d'information à inscrire dans des champs respectifs, caractérisé en ce qu'il comprend des moyens pour accepter en entrée les données sous forme d'une concaténation dans lequel lesdits éléments d'information sont définis par des blocs de données respectifs contigus, ordonnancés selon une convention reconnue par ladite source extérieure et ledit dispositif communicant, sans désignation explicite de champ, et des moyens pour identifier et extraire chaque élément d'information reçu de ladite concaténation en fonction du type et de la position de son bloc de données correspondant dans ladite concaténation. Selon un sixième aspect, l'invention concerne un dispositif communicant, caractérisé en ce qu'il intègre le dispositif selon le cinquième aspect. Ce dispositif communicant peut être plus spécifiquement une carte à puce. Les caractéristiques optionnelles de l'invention, présentées dans le cadre de procédé selon les trois premiers aspects, s'appliquent mutatis mutandis au dispositif et système selon les quatre derniers aspects. L'invention et les avantages qui en découlent apparaîtront plus clairement à la lecture de la description qui suit des modes de réalisation préférés, donnée purement à titre d'exemples nonlimitatifs par référence aux dessins annexés, dans lesquels : - la figure l, déjà décrite, représente une partie des instructions transmises vers une carte à puce lors d'une personnalisation d'une application, notamment pour renseigner des champs de données personnelles, - la figure 2 est un schéma synoptique simplifié des principaux éléments d'une carte à puce programmable"ouverte", - la figure 3 est un schéma explicatif indiquant comment des données personnelles sur fichier de banque de données apparaissent lorsque présentées sous forme d'une concaténation de caractères, conformément à l'invention, et - la figure 4 est un schéma synoptique des éléments, fonctionnels intervenant pour la concaténation des données personnelles et de leur exploitation à la fois en dehors de la carte et sur la carte. Avant d'aborder les spécificités de la personnalisation conforme à l'invention, l'architecture générale d'une carte à puce programmable ouverte sera décrite par référence à la figure 2. Au coeur de la carte 1 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 interne 4 à trois types de mémoire : - une mémoire programmable du type ROM effaçable électriquement (EEPROM) 6. Cette mémoire est destinée à être chargée avec une ou plusieurs applications de service 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. Le contenu de la mémoire ROM masque 8 est très fortement lié aux moyens matériels de la carte à puce, le code étant normalement établi par le fabricant de la carte ; et - une mémoire du type RAM 10 destinée au stockage de données provisoires, telles que des contenus de registres, des 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 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 14 sert entre autres pour l'échange bidirectionnel de données avec une borne prévue pour le chargement d'une application dans la mémoire EEPROM 6. Le concept général de l'invention sera décrit par référence aux figures 3 et 4. Dans ce qui suit, le dispositif portatif communicant est une carte à puce du type décrit par référence à la figure 2. On comprendra cependant que cette description peut être transposée à tout autre type de dispositif portatif communicant. La figure 3 illustre la préparation des données de personnalisation par un centre extérieur de la carte, par exemple un serveur ou un terminal distant. Les données personnelles à un titulaire de carte y sont établies de diverses manières. Dans l'exemple, ces données ont deux sources possibles : - un poste local de saisie directe sur écran 20, celui-ci pouvant être intégré à un terminal lecteur de carte. Dans ce cas, les données peuvent être inscrites directement par le titulaire en remplissant un questionnaire sur écran ; et un fichier d'informations personnelles spécifique au titulaire, provenant d'une base de données 21. Les données provenant de ces sources sont traitées par un module logiciel de personnalisation 22 pour y être organisées et formatées selon un format préétabli par le protocole de personnalisation fixé avec le programme sur carte faisant l'objet de la personnalisation. Le module de personnalisation 22 produit sous forme électronique un ensemble d'éléments d'informations personnelles VI à Vn qui constituent les données regroupées dans des champs correspondants El à En. Dans la figure, cet ensemble d'éléments d'information est représenté sous forme d'un tableau 24 avec n champs différents, numérotés 1 à n, dont les cinq premiers sont : le nom, le prénom, le numéro de sécurité sociale, la taille et le poids du titulaire de la carte. A chaque champ Ei (i étant un nombre compris entre 1 et n) est associée une valeur Vi, c'est-à- dire la donnée personnelle correspondante (par exemple"Durand"pour le champ"Nom"). Comme le montre le tableau 24, les valeurs Vi peuvent être numériques ou alphabétiques selon l'information à fournir. Une classification, dénommée"type"est appliquée à chaque valeur Vi en fonction de la longueur celle-ci en termes d'octets, conformément à la table suivante : Tableau 1 : correspondance entre type et longueur en octets. Type longueur en octets Tableau d'octets > 4 (non déterministe) Entier 4 (déterministe) Court 2 (déterministe) Octet 1 (déterministe) (Les termes utilisés pour les types sont également connus par les appellations anglo-saxonnes :"Byte-array","Integer","Short"et"Byte", dans l'ordre d'apparition.) Le type tableau d'octets et non déterministe en ce sens que sa longueur n'est pas fixe ; en revanche tous les autres types cités sont déterministes, leur longueur étant figée. Lorsque les valeurs constituent un tableau d'octets, ce qui est notamment le cas pour les trois premiers champs El, E2 et E3, elles sont préfixées par l'indication de leur longueur en octets, cette indication étant codée sur deux octets. Ainsi, pour le champ El, le tableau d'octets commence par"06" pour signaler que la valeur"Durand"qui suit comporte six octets (chaque caractère numérique ou alphabétique occupe un octet). Pour les types Entier et Court, la valeur contenue est complémentée, au besoin, par un ou deux "0"de remplissage en tête pour obtenir le nombre fixe d'octets, respectivement quatre et deux. A titre d'exemple, le champ"taille"étant du type Entier, la valeur de "17811 sera précédée d'un 11011 pour former le bloc de quatre octets"0178". Les valeurs Vn-1 et Vn en fin de tableau 24 sont respectivement du type"octet"et"court". Conformément à l'invention, les valeurs exprimées par les types pour ces n champs sont soumises à une opération de concaténation, de manière à produire une chaîne de caractères, donc d'octets, 26. Pour ce faire, on insère d'abord chaque valeur Vi dans un bloc de données Bi, qui a le format défini par le type utilisé pour exprimer cette valeur Vi. Ainsi, un bloc de données Bi pour le type"tableau d'octets" comporte les deux octets de préfixe précités suivi des octets qui composent la valeur Vi. Les blocs de données Bi pour les types déterministes (entier, court, octet) sont constitués par le ou les octets de la valeur Vi elle-même, éventuellement avec un ou plusieurs 11011 de remplissage. Ensuite, on crée une concaténation de ces blocs de données Bi, sans interposition d'autres données. On remarque notamment l'absence dans la concaténation 26 de désignation explicite de champ Ei, telle que"nom","prénom", etc. Ainsi, comme le montre la concaténation 26, le tableau d'octets "06DURAND", formant le bloc BI pour le champ El est suivi immédiatement par le tableau d'octets"08PHILIPPE", formant le bloc B2, etc. On note que le regroupement de données est des plus compacts, du fait qu'il n'incorpore pas les noms des champs devant chacune des valeurs, au contraire de l'approche classique. La chaîne d'octets de la concaténation 26 est transmise sous forme de flux d'octets à la carte à puce du destinataire, où elle subira une opération inverse, dite de"déconcaténation", permettant d'extraire les données pour les inscrire dans les champs prévus El, E2, E3,..., En de l'application sur carte. La figure 4 illustre les moyens fonctionnels qui permettent de réaliser d'une part la concaténation des données personnelles hors carte et d'autre part l'exploitation de ces données sous forme sérialisée au niveau de la carte 1 pour la personnalisation d'une application. Ces moyens fonctionnels sont réalisés avec des modules logiciels répartis dans les mémoires hors carte et sur carte. Dans cette figure 4, les parties opérationnelles sont indiquées par des rectangles, et les actions ou résultats provenant de ces parties sont indiqués par des pastilles. Au niveau des moyens de personnalisation hors carte, on identifie une unité de personnalisation 40 qui sert notamment à établir des groupements des informations personnelles selon le tableau 24 de la figure 3, pour reprendre cet exemple, et un module de concaténation 42 qui coopère avec cette unité 40 pour / réaliser la concaténation de valeurs 26. Des moyens de transmission 44 sont prévus en aval pour assurer le transport de la concaténation de valeurs 26 vers la carte. En fonctionnement, l'unité de personnalisation hors carte crée, pour chaque champ Ei, un ensemble groupé de trois éléments : le nom du champ, son type, et la valeur qui doit y être inscrite. Pour chaque champ appelé, en commençant par le premier El, l'unité de personnalisation émet vers le module concaténation 42 le type et la valeur 46. A partir de ces éléments d'information, le module de concaténation va créer un bloc d'octets dont le nombre sera établi par le type, selon le tableau 1 supra. Ce bloc sera composé des valeurs elles-mêmes ainsi que les éventuelles données de préfixe indiquant le nombre d'octets dans le cas d'un type tableau d'octets et les"0"de remplissage précités. On note que le bloc peut comporter un nombre arbitraire d'octets, y compris un seul (cas d'un type octet). Le premier bloc de données correspondant au premier champ est alors inséré 48 à une extrémité d'un registre 50, tel qu'une mémoire tampon du type FIFO, qui permet la lecture des octets séquentiellement dans l'ordre d'apparition dans le bloc. Ensuite, le processus est répété de la même manière pour le champ suivant (rebouclage L1). Tout bloc suivant ainsi obtenu est enregistré avec le premier octet situé à la position qui suit immédiatement celle de dernier octet du bloc précédent. Après l'insertion du dernier bloc de données dans le registre 50, celui-ci contient la concaténation 26 (soit les données sérialisées) telle que représentée à la figure 3. Au moment de réaliser la personnalisation au niveau de la carte 1, les données sérialisées du registre 50 sont transférées vers les moyens de transmission 44 pour être ensuite transmises par une liaison 52 vers cette carte. La réalisation des moyens de transmission et de la liaison est classique, s'agissant d'une liaison locale sur câble série ou parallèle, ou sans fil par faisceau infrarouge ou hertzien, ou encore d'une liaison entre terminaux distants hors carte et sur carte par ligne téléphonique sur réseau du type Internet. A la réception de la concaténation de valeurs 26, celles-ci sont stockées dans un registre de la carte (ou éventuellement à proximité de la carte) en respectant l'ordre de succession des octets. L'exploitation de ces données sur carte est assurée par une unité de personnalisation 54 qui coopère avec un module de déconcaténation 56 (aussi désigné par le terme"bibliothèque"). A l'instar de l'unité 40, l'unité de personnalisation sur carte 54 sert à établir un groupement d'éléments pour chaque champ. Dans ce cas, le groupement comprend deux éléments qui sont communs avec ceux de l'unité de personnalisation hors carte 40, à savoir le nom du champ et son type, pour chaque champ El, E2, E3,..., En. On note qu'il existe une concordance exacte entre ces éléments situés hors carte et sur carte. Plus particulièrement, on retrouve au niveau des unités de personnalisation hors carte 40 et sur carte 54 une identité pour ce qui concerne : - les champs El, E2,..., En faisant l'objet de la concaténation, - l'ordre de prise en compte de ces champs pour la concaténation et pour la déconcaténation respectivement hors carte et sur carte, et - pour chaque champ, le type de valeur contenu : tableau d'octets, entier, court ou octet. Toutefois, lorsque le type associé à un champ est un tableau d'octets, l'unité de personnalisation 54 n'a pas besoin de connaître sa longueur, cette information étant précisée dans les données de concaténation 26 reçues. Cette concordance peut être préétablie par une convention ou elle peut être obtenue en écrivant le code pertinent à cet aspect de manière cohérente entre les parties hors carte et sur carte. En plus de ces deux éléments (champ et type), le groupement précité d'éléments de l'unité de personnalisation sur carte comporte, pour chaque champ, une adresse de destination de la valeur associée à ce champ. Cette adresse, qui constitue donc le troisième élément du groupement, peut être la première valeur d'adresse d'une mémoire destinée à stocker la valeur dans la carte. Le processus de personnalisation sur carte consiste alors, en premier lieu, à extraire pour chaque champ la valeur correspondante contenue dans les données de concaténation 26. Pour ce faire, l'unité de personnalisation 54 émet vers le module de déconcaténation 56 une commande 58 d'extraction du type de données correspondant au champ considéré. En réponse, le module de déconcaténation 56 extrait, à partir des données de concaténation 26, les octets du bloc qui constituent la valeur du champ. Ces octets sont identifiés par le module de concaténation simplement par le fait que : - d'une part les blocs d'octets qui constituent les champs successivement traités se suivent dans les données de concaténation 26, ce qui permet de déterminer le point de départ de l'extraction, et - d'autre part que la signalisation du type par la commande 58 permet de déterminer le nombre d'octets à extraire. Ainsi, pour le premier champ El selon l'exemple de la figure 3, la commande d'extraction de type 58 consiste à demander au module de déconcaténation 56 d'extraire le type tableau d'octet. S'agissant de la première commande 58, le module se positionne pour lire la tête des données de concaténation 26 et, conformément au processus pour extraire un tableau d'octet, lit les deux premiers octets, soit"06". Le module est ainsi informé qu'il doit délivrer les six octets suivants des données de concaténation, soit ceux qui encodent la valeur"DURAND". Cette valeur est émise en sortie 60 depuis le module de déconcaténation 56 vers l'unité de personnalisation 54. En réponse, celle-ci crée et émet 62 un ensemble de données composées de cette valeur et de son adresse de destination pour renseigner le champ. Cet ensemble est traité par des moyens internes de gestion pour obtenir la mémorisation de cette valeur à l'emplacement convenu de la carte. On obtient ainsi la mise à jour (ou la création) 64 du champ El, correspondant au nom, avec la valeur"DURAND"à l'emplacement mémoire de la carte prévu pour cette information personnelle. L'unité de personnalisation 54 détermine ensuite s'il y un champ suivant 66. Si tel est le cas, elle effectue un rebouclage L2 pour passer au traitement de ce champ. Pour le champ suivant E2, le module de déconcaténation 56 est également informé qu'il doit extraire un tableau d'octets. Le bloc d'octets concerné est identifié comme celui se situant immédiatement à la suite du dernier octet extrait pour le champ précédent El. La valeur"PHILIPPE"de ce champ de prénom est ainsi extraite par un processus identique et subit les mêmes traitements de sortie de valeur 50 vers l'unité de personnalisation 54, de sortie de celle-ci avec l'adresse du deuxième champ 62, et de mise à jour du champ 64 pour inscrire la valeur dans l'emplacement mémoire de la carte prévu pour le prénom. Le point de départ de chaque opération d'extraction de valeur à partir des données sérialisées 26 peut être fixé par un pointeur d'adresse selon des techniques classiques. Lorsque toutes les valeurs des n champs sont ainsi extraites et mémorisées dans la carte aux adresses convenues, le processus de déconcaténation est terminé. L'un des aspects remarquables de l'invention réside dans le fait que le module de concaténation hors carte 42 et le module de déconcaténation sur carte 58 sont parfaitement génériques en ce sens qu'ils sont indépendants des spécificités de la personnalisation d'une application de service particulière. En effet, ces modules n'ont pas à prendre en compte le sens ou la finalité des valeurs qu'ils gèrent. Leur rôle est simplement de les concaténer (module de concaténation 42) et de les extraire (module de déconcaténation 56) en tant que blocs d'octets dont la taille est fixée par le type attribué., De la sorte, le module de concaténation hors carte 42 peut être installé dans tout terminal ayant pour mission de transmettre des données de personnalisation vers un dispositif. Un terminal ainsi équipé pourra alors bénéficier des avantages de l'envoi des données de personnalisation sous forme sérialisée pour toutes les applications de service gérées. Au niveau de la carte, un seul et même module de déconcaténation 56 peut servir différentes unités de personnalisation 54, notamment dans le cas d'une carte multiservices ouverte ou fermée comportant plusieurs applications dont chacune comporte sa propre unité de personnalisation. Le concept de l'invention ayant été décrit en dehors des considérations spécifiques au formalisme des moyens logiciels, par souci de simplification, ces aspects seront maintenant abordés dans le cadre d'un exemple basé sur langage Java Card, couramment utilisé pour la programmation des applications sur carte à puce. Le langage Java Card est un dérivé du langage Java, qui tient compte des limites en ressources matérielles des cartes, notamment en ce qui concerne leur capacité de mémoire. Il est cependant clair que l'homme du métier pourra aisément transposer et adapter les éléments de cette description à tout autre langage utilisé dans le domaine. Au niveau des moyens logiciels, la mise en oeuvre de la concaténation intervient aux niveaux suivants : - de l'exécution du code de personnalisation sur une machine en dehors de la carte, s'agissant par exemple d'une machine de personnalisation ou d'un serveur à, distance ; - du codage des données de personnalisation qui en résultent dans un flux d'octets (cf. données 26 de la figure 3), en utilisant un format unique et portatif ; de la transmission vers la carte du flux d'octets qui en résulte ; et - du décodage du flux d'octets assuré par la carte en utilisant un processus automatisé, mise en oeuvre par le module de déconcaténation 54. Au niveau hors carte (serveur), les moyens logiciels comprennent une bibliothèque qui permet à un utilisateur de créer et d'initialiser les mêmes objets que ceux utilisés dans l'application carte, par exemple des fichiers, des codes d'identification personnelle, des clés. Ces moyens comprennent en outre un outil logiciel (module de concaténation 42) qui peut saisir ces objets (après initialisation) et les transformer en un flux d'octets 26, lequel est codé d'une manière unique et transportable. Au niveau de la carte 1, les moyens logiciels comprennent un outil générique de lecture (module de déconcaténation 56) dont la fonction est de décoder la partie générique du flux d'octets. Pour chaque type d'objet qui peut être créé, il est prévu une fonction spécifique pour décoder la partie du flux d'octets qui décrit ce type d'objet particulier. La mise en oeuvre des moyens logiciels est fonction du type de machine de personnalisation et du type de carte utilisé. A titre d'exemple, la concaténation (et, inversement, la déconcaténation) peut être basée sur un format de concaténation adapté au langage"Java Card". Lorsque qu'une machine de personnalisation est utilisée dans un environnement sécurisé, le flux d'octets n'a pas forcément à être sécurisé par cryptage, et les données brutes, dont quelques valeurs de vérification (dites"checksums"en terminologie anglo-saxonne) peuvent être transmises sur la ligne entre la machine de personnalisation et la carte. Lorsqu'un serveur à distance est utilisé (par exemple via Internet), la communication doit être de préférence sécurisée, et le flux d'octets sera alors crypté et signé (par exemple en utilisant un protocole du type connu sous le sigle MAC, pour "message authentication coding"). Dans certains cas, il est possible de ne crypter que la partie sensible du flux de données. Avec une carte ouverte dans laquelle des applications peuvent être écrites par des tiers et chargées dans la carte, la bibliothèque principale de la carte, soit le module de déconcaténation, sera incluse dans l'outil logiciel d'exploitation, normalement en mémoire figée ROM, mais les bibliothèques qui décodent les contenus de chaque objet, soit l'unité de personnalisation 54, seront contenues dans l'application qui définit l'objet. Avec une carte fermée, l'intégralité de la bibliothèque carte sera intégrée dans l'outil logiciel d'exploitation et l'ensemble d'objets potentiels sera figé. On considérera maintenant une application en langage"Java Card"qui peut être personnalisée par un serveur distant à travers un réseau. Par souci de simplification, on se concentrera sur le cas particulier d'un objet créé pour le code d'identification personnel (Objet PIN). Dans l'exemple, les données transmises sont : - le, nombre maximum de tentatives d'inscription / de code admises, - la taille maximum du code PIN, - la taille réelle et la valeur du code PIN, - le nombre initial de tentatives possibles. L'idée est alors de définir deux méthodes additionnelles dans l'objet PIN : une pour l'écriture des données PIN et l'autre pour la lecture de ces données PIN. Une méthode d'écriture des données PIN dans un flux sur le serveur peut se présenter comme suit : Public void écrireFlux (ObjectOutput out) throws IOException { out. writeByte (maxTries) ; out. writeByte (maxSize) ; out. writeByte (actualSize) ; out. write (PINValue, (short) 0, actualize) ; out. writeByte (ratif) ; } Cette méthode sera désignée"écrireFluxO". De manière correspondante, une méthode de lecture de données PIN à partir d'un flux (sur la carte) peut se présenter comme suit : Public void lireFlux (Object ! nput in) throws IOException { maxTries = in. readbyteo ; maxSize = in. readByte () ; actualize = in. readByteO ; in. read (PINValue, (short) 0, actualize) ; ratof = in. readByte () ; } Cette méthode sera désignée"lireFluxO". Avec les moyens logiciels"Java Card", le flux d'octets, qui en résulte devra contenir toute l'information décrite par l'utilisateur, ainsi que des informations système destinées à être utilisées par le décodeur générique sur la carte, soit : - L'AID de l'ensemble dans lequel la classe est définie. (Un AID est un code d'identification attribué par un organisme international de normalisation pour répertorier des applications.) et - le jeton, (token en terminologie anglo-saxonne) de la classe au sein de l'ensemble. (Un jeton est une manière de d'identifier une classe par un nombre hexadécimal plutôt que par un nom, afin d'économiser de l'espace mémoire sur carte.) En conséquence, si un code personnel PIN est utilisé dans les conditions suivantes : - définition dans l'ensemble com. gemplus. util (AID = AO 00 00 00 18 34) ; - la classe a le jeton 0x21 dans cet ensemble ; - le code personnel PIN est défini avec trois tentatives au maximum, une taille maximum de six, une valeur PIN de"1234"et un nombre courant de tentatives maximum de trois alors le flux d'octets correspondant sera AO 00 00 00 18 34 Ensemble Aid 21 Classe jeton (token) 03 Maximum de tentatives 06 Taille maximum 04 01 02 03 04 Taille et valeur PIN 03 Taille et valeur PIN Autrement dit, le flux de données de la concaténation se présentera comme : AO 00 00 00 18 34 21 03 06 04 01 02 03 04 03. Ce flux de données peut être produit sur un serveur par la méthode"writeExternalO"définie plus haut, puis crypté, et ensuite envoyé vers la carte, où il sera décodé par la méthode" readExternal () Il définie plus haut. L'idée de base venant d'être décrite consiste à définir un système pour la représentation de données dans une carte et un protocole pour les charger dans la carte. A partir de ce contexte, on peut envisager plusieurs variantes : 1. Au lieu de produire les données à partir d'un simulateur, il est possible d'utiliser une carte "maîtresse"qui est personnalisée selon une méthode classique, et ensuite obtenir les données extérieures à partir de cette carte maîtresse. Les données qui en résultent peuvent alors être transmises vers d'autres cartes. Ainsi, conformément à cette variante, la carte"maîtresse"remplit le rôle des moyens hors carte, et l'ensemble des opérations de personnalisation est réalisé par des cartes. 2. Les données sérialisées 26 peuvent être soumis à cryptage selon un protocole cryptographique déterminé lors de leur transport ou de leur stockage en mémoire. 3. Les données sérialisées 26 peuvent être sauvegardées sur des sites à des fins d'archivage des contenus des informations personnelles d'une carte ou d'effectuer de nouvelles personnalisations. 4. Après avoir produit la sauvegarde (cf. variante 3), il est possible de garder les applications, connues par le terme de"applets", dans la terminologie anglo-saxonne, dans un lieu de stockage sûr, par exemple on réalisant un cryptage selon la variante 2. Les données peuvent aussi être utilisées pour exécuter une application sur un autre dispositif à partir du serveur. 1 5. Un système de sauvegarde défini au paragraphe (2) peut aussi être utilisé en fin de vie de carte en tant qu'outil de diagnostic ou de détection de fraude. 6. Le système de sauvegarde sécurisé défini au paragraphe (2) plus haut peut être utilisé pour échanger des données entre cartes d'une manière sécurisée. On note que dans une mise en oeuvre de l'invention sur la base du langage Java Card, il est possible de s'appuyer en partie sur des techniques de concaténation de données déjà établies pour ce langage. Ces techniques sont connues dans des domaines très différents de ceux de la personnalisation d'applications sur dispositifs portatifs, à savoir les techniques de sauvegarde de données et de partage de tâches entre ordinateurs. L'invention peut servir tant pour la personnalisation sur un site de production en pré- émission que pour une personnalisation à distance, en post-émission. Dans tous les cas, qu'il s'agisse d'une carte ouverte ou fermée, on obtient les effets techniques suivants : une réduction de la taille du code de personnalisation sur la carte. Sur la carte, la quantité de code nécessaire à la personnalisation est très réduite pour plusieurs raisons. D'abord, une grande partie de code est générique et comprise dans le système, seule une implantation. Ensuite, le code qui est spécifique à chaque type d'objet est plutôt petit, et n'a besoin d'être présent qu'à un seul endroit dans la carte ; une facilitation de la personnalisation à distance.'Puisqu'il n'y a qu'un seul flux d'octets à transférer, le niveau d'interactivité durant la personnalisation est réduit, et il devient possible de travailler avec un réseau même de faible qualité. En plus, la quantité globale de données à échanger tend à diminuer. Par ailleurs, il sera apprécié que : - la plupart du code de personnalisation réside à l'extérieur de la carte, cette dernière ne contenant que le code générique nécessaire au décodage du flux ; - le flux unique d'octets peut être rendu plus compact que les scripts classiques de personnalisation, et sa structure est très simple, ce qui facilite grandement le transport du flux vers la carte ; - la machine de personnalisation ou le serveur peut garder une archive détaillée de la personnalisation. Le code de personnalisation peut être fondu dans le code du serveur de manière transparente ; - le flux d'octets est indépendant du type de carte utilisé, ce qui peut augmenter le potentiel de réutilisation des scripts de personnalisation ; - dans le cas d'un serveur"Java"et d'une carte "Java Card", le serveur peut utiliser le logiciel de la carte pour exécuter l'initialisation, ce qui réduit sensiblement le risque potentiel d'erreurs. REVENDICATIONS 1. Procédé de préparation de données de personnalisation ou d'initialisation pour transmission à un dispositif communicant portatif, par exemple une carte à puce (1), les données comprenant plusieurs éléments d'information (Vi), chacun attribué à un champ (Ei) exploité par ledit dispositif, caractérisé en ce que ladite préparation consiste à créer une concaténation (26) desdits éléments d'information (Vi) par des blocs de données respectifs (Bi) contigus et ordonnancés selon une convention reconnue par ledit dispositif communicant, sans désignation explicite de champ. 2. Procédé selon la revendication 1, caractérisé en ce que les blocs de données (Bi) sont formatés selon plusieurs types préétablis, le nombre d'octets utilisés pour inscrire un élément d'information (Vi) dans le bloc qui lui est attribué étant fonction du type de ce bloc (Bi). 3. Procédé selon la revendication 2, caractérisé en ce que les lesdits types comprennent au moins un type fixe composé d'un nombre fixe d'octets et un format variable composé d'un nombre variable d'octets, ce nombre étant spécifié dans le bloc. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que les données sont transmises sous forme cryptée. 5. Procédé de personnalisation ou d'initialisation d'une application dans un dispositif communicant portatif, par exemple une carte à puce (1), ladite personnalisation/initialisation comprenant la réception de données provenant d'une source extérieure (40-50) pour extraire de ces données des éléments d'information (Vi) à inscrire dans des champs respectifs (Ei), caractérisé en ce qu'il consiste à accepter en entrée lesdites données sous forme d'une concaténation (26) dans lequel lesdits éléments d'information (Vi) sont définis par des blocs respectifs (Bi) contigus, ordonnancés selon une convention reconnue par ladite source extérieure (40- 50) et ledit dispositif communicant (1), sans désignation explicite de champ, chaque élément d'information (Vi) reçu de ladite concaténation étant identifié en fonction du type et de la position de son bloc de données dans ladite concaténation. 6. Procédé selon la revendication 5, caractérisé en ce que chaque élément d'information (Vi) est extrait par référence au type de bloc de données (Bi) dans lequel il est contenu, le type de chaque bloc pour chaque champ (Ei) étant établi par ladite convention. 7. Procédé selon la revendication 6, caractérisé en ce que les lesdits types comprennent au moins un type fixe composé d'un nombre fixe d'octets et un format variable composé d'un nombre variable d'octets, ce nombre étant spécifié dans le bloc. / 8. Procédé selon l'une quelconque des revendications 5 à 7, caractérisé en ce que chaque élément d'information (Vi) extrait de ladite concaténation (26) est transféré dans une portion de stockage de champ correspondant (Ei) du dispositif portatif communicant (1). 9. Procédé selon l'une quelconque des revendications 5 à 8, caractérisé en ce qu'il comprend le renseignement de chaque champ (Ei) avec la valeur correspondante (Vi) dans une adresse correspondante du dispositif portatif communicant, par les étapes de : - mémorisation, à un stade initial, de ladite convention pour savoir l'ordre d'apparition des champs dans ladite concaténation (26) et le type de bloc (Vi) dans lequel est contenue la valeur correspondante (Vi), - stockage de ladite concaténation (26), et pour chaque renseignement de champ : - émission d'une commande d'extraction de la valeur (Vi) par désignation du type du bloc de données (Bi) dans laquelle elle est contenue, l'extraction étant réalisée à partir du premier octet, ou de l'octet suivant de dernier octet précédemment extrait, de ladite concaténation (26), et - transfert de ladite valeur extraite vers une portion de mémoire du dispositif portatif (1) attribué au champ correspondant. 10. Mise en oeuvre du procédé selon l'une quelconque des revendications 5 à 9 dans une carte à puce (1). 11. Dispositif de préparation de données de personnalisation ou d'initialisation pour transmission à un dispositif communicant portatif, par exemple une carte à puce (1), les données comprenant plusieurs éléments d'information (Vi), chacun attribué à un champ (Ei) exploité par ledit dispositif, caractérisé en ce qu'il comprend des moyens (48, 50) pour créer une concaténation (26) desdits éléments d'information (Vi) par des blocs respectifs (Bi) contigus ordonnancés selon une convention reconnue par ledit dispositif communicant, sans désignation explicite de champ. 12. Dispositif selon la revendication 11, caractérisé en ce que les blocs de données (Bi) sont formatés selon plusieurs types préétablis, le nombre d'octets utilisés pour inscrire un élément d'information (Vi) dans le bloc qui lui est attribué étant fonction du type de ce bloc (Bi). 13. Dispositif selon la revendication 12, caractérisé en ce que les lesdits types comprennent au moins un type fixe composé d'un nombre fixe d'octets et un format variable composé d'un nombre variable d'octets, ce nombre étant spécifié dans le bloc. 14. Dispositif de personnalisation ou d'initialisation d'une application dans un dispositif communicant portatif, par exemple une carte à puce (1), ladite personnalisation/initialisation comprenant la réception de données provenant d'une source extérieure (40-50) pour extraire de ces données des éléments d'information (Vi) à inscrire dans des champs respectifs (Ei), caractérisé en ce qu'il comprend des moyens (54) pour accepter en entrée lesdites données sous forme d'une concaténation (26) dans lequel lesdits éléments d'information (Vi) sont définis par des blocs de données respectifs (Bi) contigus, ordonnancés selon une convention reconnue par ladite source extérieure (40-50) et ledit dispositif communicant (1), sans désignation explicite de champ, et des moyens (56,58) pour identifier et extraire chaque élément d'information (Vi) reçu de ladite concaténation en fonction du type et de la position de son bloc de données correspondant dans ladite concaténation. 15. Dispositif selon la revendication 14, caractérisé en ce que chaque élément d'information (Vi) est extrait par référence au type de bloc de données (Bi) dans lequel il est contenu, le type de chaque bloc pour chaque champ (Ei) étant établi par ladite convention. 16. Dispositif selon la revendication 15, caractérisé en ce que les lesdits types comprennent au moins un type fixe composé d'un nombre fixe d'octets et un format variable composé d'un nombre variable d'octets, ce nombre étant spécifié dans le bloc de données (Bi). 17. Dispositif selon l'une quelconque des revendications 14 à 16, caractérisé en ce qu'il comprend des moyens de renseignement de chaque champ (Ei) avec la valeur correspondante (Vi) dans une adresse correspondante du dispositif portatif communicant, ces moyens comprenant : 1 - des moyens de mémorisation à un stade initial de ladite convention pour savoir l'ordre d'apparition des champs dans ladite concaténation (26) et le type de bloc (Vi) dans lequel est contenue la valeur correspondante (Vi), - des moyens de stockage de ladite concaténation (26), des moyens d'émission d'une commande d'extraction de la valeur (Vi) par désignation du type du bloc (Bi) dans laquelle elle est contenue, l'extraction étant réalisée à partir du premier octet ou de l'octet suivant de dernier octet précédemment extrait de ladite concaténation (26), et - des moyens transfert de ladite valeur extraite vers une portion de mémoire du dispositif portatif (1) attribué au champ correspondant. 18. Dispositif selon l'une quelconque des revendications 14 à 17, caractérisé en ce qu'il est physiquement intégré dans ledit dispositif portatif communicant (1). 19 Carte à puce (1), caractérisée en ce qu'elle intègre un dispositif selon l'une quelconque des revendications 14 à 17.