FR 2806813 A1 20010928 FR 0003482 A 20000317 La présente invention a pour objet un système de gestion de mémoire pour cartes à puce permettant à un utilisateur d'avoir accès à certaines prestations dans le cadre notamment d'une gestion informatisée des services de la ville. Les systèmes de gestion actuels pour des applications du type contrôle d'accès à un service ou à un lieu sont généralement constitués de terminaux reliés à un ordinateur de type PC coopérant avec des cartes à puce personnalisées. Dans ces cartes à puce la mémoire présente la forme d'une matrice de blocs comprenant d'une part un bloc constructeur contenant le numéro de série de la carte accessible uniquement en lecture et d'autre part, dans chaque rangée de blocs ou secteur, un bloc d'accès offrant la possibilité de mémoriser des clés de sécurité, ainsi que la gestion des droits d'accès, lecture, écriture, sur les autres blocs, généralement au nombre de trois, de ce même secteur. Les gestions d'accès des blocs d'un secteur sont fixées indépendamment les unes des autres. Un bloc mémoire peut se configurer soit comme une mémoire classique dont les données sont accessibles par les fonctions lire et écrire, soit comme la mémoire d'un porte monnaie électronique où la fonction lire informe l'utilisateur sur le contenu du porte monnaie et les fonctions écrire, ajouter, et soustraire autorisent la mise à jour de la valeur du porte-monnaie. Ces cartes sont programmées et initialisées par le concepteur au moyen d'un ordinateur ou d'un automate et sont lues et mises à jour par les terminaux informatiques. Dans ces cartes, l'espace mémoire est rempli linéairement en attribuant une zone mémoire continue à un type de données ou identifiant tel que par exemple le nom ou le prénom d'une personne associé à des données qui varient en fonction de l'utilisateur de la carte et de son usage. Toutefois ces cartes présentent l'inconvénient, une fois que toutes les zones mémoires ont été chacune préalablement allouées à un identifiant déterminé, de ne plus pouvoir mémoriser d'autres identifiants même certaines zones mémoires ne sont pas totalement remplies en données variables. Ainsi, ces cartes ne peuvent pas être utilisees pour des applications multiples telles que par exemple services de la ville qui nécessitent de pouvoir allouer à la mémoire desdites cartes de nouveaux identifiants. La présente invention a pour but de remédier à cet inconvénient en proposant un système de gestion de mémoire pour cartes à puce permettant d'architecturer mémoire de ladite carte de manière lisible et conviviale d'implémenter plus d'éléments que sur les cartes actuelles sans apporter de lourdeur dans son utilisation. Le système de gestion selon l'invention est type comprenant un ou plusieurs terminaux destinés a coopérer avec des cartes à puce comprenant chacune une mémoire présentant la forme d'une matrice de n secteurs de p blocs mémoires et un contrôleur de gestion des accès auxdits blocs et se caractérise essentiellement en ce que ladite mémoire comprend une table d'allocation contenant les adresses des différentes applications et qui forme le sommet d'une arborescence de répertoires de fichiers, et en ce que: - la table d'allocation est décrite, en fonction du nombre répertoires de base contenu dans cette dernière, un ou plusieurs blocs mémoires chaînés entre eux, un répertoire est décrit, en fonction nombre de fichiers contenus dans ce dernier, sur un plusieurs blocs mémoires chaînés entre eux, - un fichier est décrit, en fonction de longueur des données contenues dans ce dernier, sur un plusieurs blocs mémoires chaînés entre eux. Conformément à l'invention un répertoire peut comprendre en outre des sous répertoires et en fonction du nombre qu'il contient être décrit sur un plusieurs blocs chaînés entre eux. Toutefois conformément à l'invention la mémoire des cartes à puce est gérée par le microprocesseur du terminal qui coopère avec ladite carte Dans un mode de réalisation préférentiel de l'invention la trame de données définissant la table d'allocation comprend essentiellement les adresses d'implantation des applications, le type de support de l'application à savoir un fichier ou répertoire, et son identifiant. Les répertoires sont destinés à l'identification des fichiers qui contiennent les données permettant la gestion des applications correspondantes et des répertoires constituant la sous arborescence qui en découle. Les trames de données fichiers peuvent comporter des séparateurs pour optimiser l'utilisation des blocs. Chaque secteur de la carte sera de préférence attribué à une application donnée. De manière préférentielle la carte à puce renferme un jeu de deux clés d'accès par application, une première clé destinée à permettre l'accès en mode lecture des données non confidentielles, et une deuxième clé produite à partir d'un algorithme de cryptage destinée à permettre l'accès en mode écriture à toute entité générée par le concepteur et en mode lecture à toute entité confidentielle. Les avantages et les caractéristiques de la présente invention ressortiront plus clairement de la description qui suit et qui se rapporte au dessin annexé, lequel en représente plusieurs modes de réalisation non limitatifs. - la figure 1 représente une vue schématique d'une carte à puce sans contact et un terminal. - la figure 2a représente une vue schématique de l'espace mémoire de la carte. - la figure 2b représente l'architecture de la mémoire de la carte selon l'invention. - la figure 2c représente la trame définissant la table d'allocation dans un mode de réalisation préférentiel. - la figure 2d représente deux blocs chaînés décrivant une table d'allocation. Si on se réfère à la figure 1 on peut voir qu'une carte à puce sans contact 1 destinée à coopérer avec un lecteur de cartes à puce sans contact 2 renferme un espace mémoire 10, un contrôleur de gestion 11, un circuit d'émission/réception 11' des informations avec le lecteur 2, lequel lecteur 2 comporte un circuit d'émission/réception 20 des données relié électriquement à un microprocesseur 21 associé à une mémoire 22 et une horloge interne 23. Sur la figure 2a on peut voir la mémoire 10 de la carte 1 se présente sous la forme d' matrice de 16 secteurs 12 de 4 blocs mémoires 13 gérés par le microprocesseur 21 du lecteur 2 par l'intermédiaire du contrôleur de gestion 11 de la carte à puce Le bloc mémoire 14 est un champ identifiant de la carte qui est inséré lors de sa mise sur le marché et qui n'est accessible qu'en mode lecture. Le dernier bloc 15 de ce chaque secteur 12 est un bloc d'accès destiné à la gestion des droits d'accès à savoir lecture ou écriture, sur les autres blocs mémoires 13 du même secteur 12. Si on se réfère à la figure 2b on peut voir que la mémoire 10 de la carte 1 est architecturée sous la forme d'une arborescence 3 de répertoires GD de fichiers RF permettant un accès rapide à des éléments de priorités distinctes tels que le numéro d'identification de la carte ou les fichiers d'identification du porteur de carte. Cette architecture de la mémoire 10 est mémorisée dans la mémoire 22 du lecteur 2. Le sommet de l'arborescence est une table d'allocation, caractérisée par les deux caractères RF, qui renferme la liste des adresses d'accès aux sous-éléments GD ou GF et qui sert d'adressage des diverses applications présentes sur la carte 1. Cette table d'allocation RF doit être alimentée et mise à jour, à chaque évolution de l'environnement d'utilisation du porteur de la carte, un terminal 2. On peut voir sur la figure 2c que la trame de la table 'allocation qui est mémorisée dans l'un quelconque des blocs mémoires 13 de la carte comporte une entête RF suivie, en 130, de la longueur de la trame qui la constitue (en nombre de blocs) et des paramètres résumant l'état de l'arborescence puis, en 131, des adresses d'implantation des applications gérées par la carte puis, en 132, du type de support de l'application (fichier ou répertoire) et, en , son code identifiant respectivement GF ou GD. Ainsi en fonction des besoins du porteur d'une carte et des services offerts par la ville, le système informatique mettra à jour les cartes par l'ajout d'applications selon deux étapes: - recherche et réservation d'une zone memoire appropriée à l'application à implanter, - référencement de cette zone mémoire au niveau de la table d'allocation RF, en précisant le type de structure et son identifiant. L'ajout d'une application aura donc pour répercussion sur la carte 1 de définir l'adresse qui pointe vers la zone mémoire correspondante. En outre afin d'optimiser l'espace mémoire on peut voir sur la figure 2d que la table d'allocation est mémorisée dans les blocs 140 et 150, le bloc 140 contenant la liste des adresses des trois premières applications 141 et en fin de trame la référence 142 au bloc suivant 150 qui contient la liste des adresses des applications suivantes. Ainsi cette faculté d'ajouter autant de blocs 13 que nécessaire en vue d'optimiser l'espace mémoire de la carte 1 est rendu possible par la génération d'un chaînage automatique, au moyen du microprocesseur 21 et d'un programme particulier, entre les blocs 140 150 et d'autres blocs 13 si nécessaire. répertoires GD sont destinés à regrouper les informations propres à une application precise, et contiennent la liste des adresses des fichiers GF constituant application. L'organisation est identique à celle de la table d'allocation RF, hormis l'identifiant entête. même que pour la table d'allocation, si la capacité mémoire du bloc 13 est insuffisante, ce dernier peut être chaîné à un ou plusieurs autres blocs mémoires 13. fichier GF contient les données de gestion d'une application et est contenu dans un ou plusieurs blocs 23 chaînés selon la longueur de la donnée à traiter. application peut être gérée selon deux méthodes. Dans la première méthode l'application peut générer autant de fichiers que de données à sauvegarder, mais si l'acces aux données individuelles est simplifié on perd en optimisation de l'espace mémoire. La deuxième méthode consiste à construire, au niveau de l'application, des trames données comportant des séparateurs permettant d'optimiser l'utilisation des blocs 13. Au niveau de l'architecture de la carte on pourra par exemple avoir un répertoire GD de personnalisation du porteur de carte contenant un fichier GF sur un bloc de mémoire 13 pour la date de naissance de l'utilisateur, un fichier GF sur un autre bloc de mémoire 13 pour le prénom et un fichier GF sur trois blocs 13 chaînés pour d'autre paramètres et un répertoire GD de gestion de l'application des piscines contenant un fichier GF sur un bloc pour le numéro de licence, un fichier GF pour la date de début et de fin de validité, etc... On peut voir également sur la figure 2a plusieurs fichiers EP dans l'arborescence contenant chacun une application de base mise à profit par l'utilisateur par exemple lorsqu'une somme d'argent est chargée dans la mémoire de la puce sous forme d'unités. La consommation de ces unités pourra s'effectuer au sein de fférents organismes privés ou publics, en accord avec mode de paiement. En ce qui concerne la logique des clés d'accès, les répertoires GD sont protégés en écriture, et les données liées au porteur de la carte à puce 1, enregistrées dans un ou plusieurs fichiers, ne peuvent être accédées, du fait de leur confidentialité, qu'à partir d'un code. De manière avantageuse, la carte comportera deux clés d'acces, une première clé ou clé publique initialisée à la valeur défaut du constructeur, destinée à permettre l'accès en lecture aux données non confidentiel , et une deuxième clé ou clé privée produite à partir d' algorithme de cryptage permettant l'accès en écriture à toute entité générée par l'installateur et en lecture à toute entité confidentielle. Le chargement de la carte à puce peut s'effectuer à l'aide d'un PC comportant l'application à charger dans la carte, lequel ordinateur est alors relié à un lecteur de proximité permettant le transfert de l'application dans la carte. L'architecture de la carte sera mise en forme préalablement à l'inscription des données dans les chiers. L'ordinateur comportera une interface permettant de générer rapidement une nouvelle arborescence pour consulter une architecture existante ou encore pour recopier facilement le contenu d'une carte vers une autre. REVENDICATIONS 1) Système de gestion de mémoire pour cartes à puce permettant à un utilisateur d'avoir accès à certaines prestations dans le cadre notamment d'une gestion informatisée des services de la ville du type comprenant un ou plusieurs terminaux destinés coopérer avec des cartes à puce (1) comprenant chacune une mémoire (10) présentant la forme d'une matrice de n secteurs (12) de p blocs mémoires (13) et un contrôleur de gestion (11) des accès auxdits blocs (13) caractérisé en ce que ladite mémoire (10) comprend une table d'allocation (RF) contenant les adresses des différentes applications et qui forme le sommet d'une arborescence de répertoires (GD) et de fichiers (GF), et en ce que: - la table d'allocation (RF) est décrite, en fonction du nombre de répertoires (GD) contenu dans cette dernière, sur un ou plusieurs blocs mémoires chaînés entre eux, - chaque répertoire (GD) est décrit, en fonction du nombre de fichiers (GF) contenus dans ce dernier, sur un ou plusieurs blocs mémoires chaînés entre eux, - chaque fichier (GF) est décrit, en fonction de la longueur des données contenues dans ce dernier, sur un ou plusieurs blocs mémoires chainés entre eux. 2) Système de gestion selon la revendication 1 caractérisé en ce que les cartes à puce coopèrent avec les terminaux à distance. 3) Système de gestion selon la revendication 1 ou la revendication 2 caractérisé en ce que la mémoire (10) des cartes à puce (1) est gérée par le microprocesseur (21) du terminal (2) via le contrôleur de gestion (11). 4) Système de gestion informatisé selon l'une quelconque des revendications précédentes caractérisé en ce que la trame de la table d'allocation (RF) comprend les adresses d'implantation des applications, le type de support de l'application à savoir un fichier ou un répertoire, et son identifiant. 5) Système de gestion selon l'une quelconque revendications précédentes caractérisé en ce que répertoires (GD) sont destinés à l'identification fichiers (GF) qui contiennent les données permettant gestion des applications correspondantes et des répertoires (GD) constituant la sous arborescence qui en découle. 6) Système de gestion selon l'une quelconque des revendications précédentes caractérisé en ce que les trames de données des fichiers (GF) comportent des séparateurs destinés à optimiser l'utilisation des blocs (13). 7) Système de gestion selon l'une quelconque de la carte caractérisé en ce que chaque secteur de la mémoire (10 est attribuée à une application. 8) Système de gestion selon l'une quelconque des revendications précédentes caractérisé en ce que la carte à puce (1) renferme un jeu de deux clés d'accès par application, une première clé destinée à permettre l'accès en mode lecture des données non confidentielles, et une deuxième clé produite à partir d'un algorithme de cryptage destinée à permettre l'accès en mode écriture à toute entité génerée par le concepteur et en mode lecture à toute entité confidentielle. 9) Système de gestion selon l'une quelconque des revendications précédentes caractérisé en ce qu'il comprend une interface permettant de générer rapidement une nouvel arborescence, ou de consulter une architecture existante, encore de recopier facilement le contenu d'une carte (1) vers une autre.