Brevet FR2774785A1 — publié le 19990813

ARRIERE-PLAN DE L'INVENTION La présente invention concerne un procédé de gestion d'application ainsi qu'un appareil de traitement d'information qui utilise le procédé et en particulier, un procédé de gestion d'application et un appareil de traitement d'information qui utilise le procédé, utilisés lorsqu'une pluralité d'applications sont stockées. Récemment, des supports d'information d'enregistrement du type carte comportant des puces de circuit intégré (IC) incorporées, c'est-à-dire des cartes IC, telles que des cartes de monnaie électronique, des cartes de crédit, des cartes pour des organismes se gérant par eux mêmes, etc... ont été utilisés. Une telle carte IC présente une capacité de stockage importante et des demandes pour qu'une seule carte puisse être utilisée pour une pluralité de types de tâches vont croissants. Par exemple, dans le cas o une carte IC est utilisée en tant que carte de crédit et o une carte IC est utilisée en tant que carte pour un organisme se gérant par lui-même, il est commode pour l'utilisateur qu'une unique carte IC soit utilisée en commun en tant que carte de crédit et en tant que carte pour l'organisme se gérant par lui-même en lieu et place des deux cartes IC qui sont en sa possession pour des utilisations respectives. Par conséquent, une carte IC dans laquelle une pluralité d'applications sont utilisées est nécessaire. DESCRIPTION DE L'ART ANTERIEUR Dans l'art antérieur, un paramètre de fonctionnement est stocké dans une carte IC et un fonctionnement d'un calculateur hôte est modifié en tant que résultat du fait que le paramètre de fonctionnement est appliqué sur le calculateur hôte, lequel paramètre est stocké dans la carte IC lorsque la carte IC est insérée dans un dispositif de lecture/écriture de carte IC. Un tel procédé est décrit dans la demande de brevet publié du Japon N 01-029051. En outre, en tant que procédé dans lequel une unique carte IC est utilisée pour une pluralité d'applications, un procédé permettant d'utiliser de manière efficace un programme tandis qu'un programme déjà existant est utilisé lorsqu'un programme est additionné est décrit dans la demande de brevet publié du Japon N 01-031285. En outre, un procédé dans lequel des touches de fonctionnement sont prévues sur une carte IC et l'une d'une pluralité d'applications est sélectionnée en tant que résultat du fait que l'une respective des touches de fonctionnement est activée est décrit dans la demande de brevet publié du Japon N 04-255089. Cependant, dans la demande de brevet publié du Japon N 01- 031285, un procédé d'exécution du programme stocké n'est pas décrit. En outre, selon le procédé décrit dans la demande de brevet publié du Japon N 04-255089, l'activation d'une touche nécessaire pour sélectionner l'une de la pluralité d'applications est peu commode. RESUME DE L'INVENTION La présente invention a été élaborée en considération des points mentionnés ci-avant et un objet de la présente invention consiste à proposer un procédé de gestion d'application et un appareil de traitement d'information qui utilise le procédé, par l'intermédiaire desquels une application souhaitée d'une pluralité d'applications peut être aisément accédée. Un procédé de gestion d'application, conformément à la présente invention, pour un cas dans lequel une pluralité d'applications sont stockées, comprend les étapes de: formation d'une structure de répertoires correspondant à ladite pluralité d'applications; octroi d'éléments d'information d'identification respectivement à des répertoires prédéterminés de ladite structure de répertoires, lesdits éléments d'information d'identification étant respectivement utilisés pour identifier ladite pluralité d'applications, ladite pluralité d'applications correspondant respectivement auxdits répertoires prédéterminés; et réalisation d'une gestion de telle sorte qu'une application de ladite pluralité d'applications correspondant à un répertoire desdits répertoires prédéterminés soit sélectionnée conformément à un élément desdits éléments d'information d'identification octroyé audit répertoire desdits répertoires prédéterminés, lorsque ledit répertoire desdits répertoires prédéterminés est sélectionné. Selon le procédé décrit ci-avant, lorsqu'un répertoire est sélectionné, l'application correspondante peut être reconnue immédiatement en utilisant l'élément d'information d'identification octroyé au répertoire sélectionné. Les éléments d'information d'identification peuvent respectivement comprendre des adresses de la pluralité d'applications; et une adresse des adresses est reconnue et ainsi, l'application de la pluralité d'applications correspondant à l'adresse des adresses est accédée. Selon ce procédé, il est possible d'exécuter une application souhaitée immédiatement en reconnaissant l'adresse de l'application octroyée au répertoire sélectionné. Le procédé de gestion d'application peut comprendre les étapes de: préparation d'une table de gestion d'application qui stocke lesdits éléments d'information d'identification et lesdites adresses de début de ladite pluralité d'applications qui correspondent respectivement auxdits éléments d'information d'identification; et report à ladite table de gestion d'application lorsqu'un répertoire desdits répertoires prédéterminés est sélectionné de manière à reconnaître une adresse de début d'une application de ladite pluralité d'applications, ladite adresse de début correspondant à un élément de ladite information d'identification octroyé audit répertoire desdits répertoires prédéterminés, et de manière à accéder à ladite application de ladite pluralité d'applications. Selon ce procédé, la table de gestion d'application qui stocke les éléments d'information d'identification et des adresses de début de la pluralité d'applications qui correspondent aux éléments d'information d'identification est constituée. Par conséquent, en modifiant seulement la relation entre les éléments d'information d'identification et les adresses de début des applications dans la table de gestion d'application, il est possible de réaliser diverses fonctions en utilisant la zone de stockage qui n'est pas importante. Le procédé de gestion d'application peut comprendre les étapes de: stockage d'une information de dimension au niveau d'une adresse de début de chaque application de ladite pluralité d'applications, ladite information de dimension indiquant une dimension de ladite application de ladite pluralité d'applications; répétition de la détection de la dimension d'une application de ladite pluralité d'applications à partir de l'information de dimension stockée au niveau de l'adresse de début de ladite application de ladite pluralité d'applications et recherche d'une adresse de début d'une application suivante de ladite pluralité d'applications conformément à ladite dimension de l'application précédente de ladite pluralité d'applications de manière à obtenir l'adresse de début d'une application souhaitée de ladite pluralité d'applications. Selon ce procédé, il est possible d'obtenir l'adresse de début d'une application souhaitée en utilisant l'ordre selon lequel les applications sont stockées. Ainsi, il n'est pas nécessaire de préparer la table de gestion d'application et par conséquent, il est possible d'utiliser efficacement la capacité de stockage. Un élément des éléments d'information d'identification peut être octroyé au répertoire le plus élevé de la structure de répertoires. Selon ce procédé, il est possible qu'une unique application soit aisément amenée à correspondre à une pluralité de répertoires subordonnés en octroyant l'élément d'information d'identification permettant d'identifier l'application au répertoire le plus élevé des répertoires qui sont utilisés par l'application. Un élément des éléments d'information d'identification peut être octroyé à chaque répertoire de la structure de répertoires. Ainsi, il est possible d'exécuter immédiatement une application en tant que résultat du fait que l'application qui est reconnue à partir de l'élément d'information d'identification octroyé à l'un quelconque des répertoires correspond à l'application. Lorsqu'une application de la pluralité d'applications doit être supprimée de manière substantielle, un élément des éléments d'information d'identification pour l'application de la pluralité d'applications est amené à être inopérant. Ainsi, il est aisé de supprimer de façon substantielle une application de la pluralité d'applications du fait qu'il est possible de supprimer de façon substantielle cette application seulement en faisant en sorte que l'élément d'information d'identification de cette application soit inopérant sans supprimer réellement cette application. Lorsqu'une application de la pluralité d'applications est mise à jour, une application obtenue à partir de la mise à jour de l'application de la pluralité d'applications peut être additionnée à la pluralité d'applications; et un élément des éléments d'information d'identification permettant d'identifier l'application de la pluralité d'applications peut être modifié selon un élément d'information d'identification permettant d'identifier l'application obtenue à partir de la mise à jour de l'application de la pluralité d'applications. Ainsi, il est possible de mettre à jour l'application sans supprimer réellement l'application antérieure. Un procédé de gestion d'application selon un autre aspect de la présente invention comprend les étapes de stockage d'applications et de données utilisées par lesdites applications dans une série de zones de stockage; et gestion des applications et des données utilisées par lesdites applications stockées dans ladite série de zones de stockage, dans lequel ladite série de zones de stockage est divisée selon une zone de programmes qui stocke lesdites applications et selon une zone de données qui stocke lesdites données utilisées par lesdites applications. Selon ce procédé, en tant que résultat du fait que la série de zones de stockage est divisée selon une zone de programmes qui stocke les applications et selon une zone de données qui stocke les données utilisées par les applications, les données destinées à être utilisées par les applications sont empêchées d'être détruites lorsque les applications sont mises àjour ou augmentées, et les applications sont empêchées d'être détruites lorsque les données utilisées par les applications sont mises à jour ou augmentées. Une frontière entre la zone de programmes et la zone de données peut être modifiée. Ainsi, en modifiant arbitrairement la frontière entre la zone de données et la zone de programmes, des capacités de stockage appropriées de la zone de données et de la zone de programmes peuvent être assurées en fonction de la quantité des applications et de la quantité des données à utiliser par les applications. Par conséquent, il est possible d'utiliser efficacement la zone de stockage. Lorsque des applications sont stockées dans la zone de programmes, les applications peuvent être stockées depuis une extrémité de la zone de programmes opposée à la frontière. Ainsi, il est possible de modifier la frontière sans déplacer les applications dans la zone de programmes. Un appareil de traitement d'information selon un autre aspect de la présente invention qui stocke une pluralité d'applications comprend une structure de répertoires correspondant à la pluralité d'applications, dans lequel des éléments d'information d'identification sont respectivement octroyés à des répertoires prédéterminés de ladite structure de répertoires, lesdits éléments d'information d'identification étant utilisés respectivement pour identifier ladite pluralité d'applications, ladite pluralité d'applications correspondant auxdits répertoires prédéterminés de ladite structure de répertoires. Selon l'agencement décrit ci-avant, il est possible de démarrer rapidement l'exécution d'une application en tant que résultat du fait que l'application est immédiatement reconnue à partir de l'élément d'information d'identification octroyé à un répertoire correspondant à l'application, lorsque le répertoire est sélectionné. Les éléments d'information d'identification peuvent respectivement comprendre des adresses de la pluralité d'applications. Ainsi, il est possible d'exécuter rapidement une application en tant que résultat du fait que l'application est accédée immédiatement en utilisant l'adresse octroyée au répertoire. L'appareil de traitement d'information peut comprendre une table de gestion d'application qui stocke les éléments d'information d'identification et des adresses de début de la pluralité d'applications qui correspondent respectivement aux éléments d'information d'identification. Ainsi, seulement en modifiant la relation entre les éléments d'information d'identification et les adresses de début des applications dans la table de gestion d'application, il est possible de réaliser diverses fonctions en utilisant la zone de stockage qui n'est pas très importante. Un élément des éléments d'information d'identification peut être octroyé au répertoire le plus élevé de la structure de répertoires. Selon cet agencement, il est possible qu'une unique application soit aisément amenée à correspondre à une pluralité de répertoires subordonnés en octroyant l'élément d'information d'identification, pour identifier l'application, au répertoire le plus élevé des répertoires qui sont utilisés par l'application. Un élément des éléments d'information d'identification peut être octroyé à chaque répertoire de la structure de répertoires. Ainsi, il est possible d'exécuter immédiatement une application en tant que résultat du fait que l'application est reconnue à partir de l'élément d'information d'identification qui est octroyé à l'un quelconque des répertoires correspondant à l'application. Un appareil de traitement d'information selon un autre aspect de la présente invention stocke des applications et des données utilisées par les applications dans une série de zones de stockage, dans lequel la série de zones de stockage est divisée selon deux zones prédéterminées, l'une desdites deux zones prédéterminées stockant les applications et l'autre desdites deux zones prédéterminées stockant les données utilisées par lesdites applications. Selon cet agencement, en tant que résultat du fait que la série de zones de stockage est divisée selon une zone de programmes qui stocke les applications et selon une zone de données qui stocke les données utilisées par les applications, les données à utiliser par les applications sont empêchées d'être détruites lorsque les applications sont mises à jour ou augmentées et les applications sont empêchées d'être détruites lorsque les données utilisées par les applications sont mises a jour ou augmentées. D'autres objets et d'autres caractéristiques supplémentaires de la présente invention apparaîtront de façon plus évidente au vu de la description détaillée qui suit que l'on lira en conjonction avec les dessins annexes. BREVE DESCRIPTION DES DESSINS La figure 1 représente un agencement système d'un premier mode de réalisation de la présente invention la figure 2 représente un agencement général d'une carte IC selon le premier mode de réalisation de la présente invention la figure 3 représente un schéma fonctionnel de la carte IC selon le premier mode de réalisation de la présente invention la figure 4 représente un agencement de fichiers d'une mémoire morte effaçable et programmable électriquement (EEPROM) selon le premier mode de réalisation de la présente invention la figure 5 représente une séparation d'une zone de stockage de l'EEPROM selon le premier mode de réalisation de la présente invention la figure 6 représente un procédé permettant de stocker des données et des application dans 'EEPROM selon le premier mode de réalisation de la présente invention; la figure 7 représente une structure de fichiers selon le premier mode de réalisation de la présente invention; la figure 8 représente un organigramme de traitement permettant d'accéder à une application dans la carte IC selon le premier mode de réalisation de la présente invention; la figure 9 représente une structure de fichiers selon un mode de réalisation constitué en tant que variante du premier mode de réalisation de la présente invention; la figure 10 représente une structure de fichiers selon un autre mode de réalisation constitué en tant que variante du premier mode de réalisation de la présente invention; la figure 1l1 représente un agencement de fichiers d'une EEPROM selon un second mode de réalisation de la présente invention; la figure 12 représente un agencement de données d'une table de gestion d'application selon le second mode de réalisation de la présente invention; la figure 13 représente une structure de fichiers selon le second mode de réalisation de la présente invention; la figure 14 représente un organigramme de traitement permettant d'accéder à une application dans une carte IC selon le second mode de réalisation de la présente invention; les figures 15, 16 et 17 représentent des opérations permettant de mettre à jour des applications selon le second mode de réalisation; et la figure 18 représente des opérations permettant d'accéder à une application selon le troisième mode de réalisation. DESCRIPTION DETAILLEE DES MODES DE REALISATION La figure 1 représente un agencement système d'un premier mode de réalisation de la présente invention. Selon ce mode de réalisation, une pluralité d'applications sont stockées dans une unique carte IC dans un système qui utilise la carte IC et ainsi, la carte IC est utilisée pour une pluralité de services. Le système 1 selon ce mode de réalisation inclut un dispositif de lecture/écriture de carte IC 3 qui joue le rôle d'interface avec la carte IC 2, et un calculateur hôte 4 connecté au dispositif de lecture/écriture de carte IC 3 et qui réalise un traitement d'information conformément aux applications stockées dans la carte IC 2. En tant que carte IC 2, par exemple, une carte IC du type contact ou une carte IC du type sans contact est utilisée. Un cas dans lequel la carte IC du type contact est utilisée en tant que carte IC 2 sera maintenant décrit. Dans le cas o la carte IC du type contact est utilisée, une connexion électrique est réalisée en tant que résultat du fait que les contacts de la carte IC viennent en contact avec des bornes de connexion. Lorsque la carte IC 2 est insérée dans une partie d'insertion prédéterminée 5 du dispositif de lecture/écriture de carte IC 3, les contacts 6 qui sont exposés sur une surface de la carte IC 2 viennent en contact avec les bornes de connexion 7 prévues dans la partie d'insertion 5 du dispositif de lecture/écriture de carte IC 3. En tant que résultat du fait que les contacts 6 de la carte IC 2 viennent en contact avec les bornes de connexion 7 prévues dans la partie d'insertion 5 du dispositif de lecture/écriture de carte IC 3, la carte IC 2 est connectée de façon substantielle avec le calculateur hôte 4. Dans la carte IC 2, une application nécessaire est sélectionnée parmi la pluralité d'applications stockées dans une mémoire interne de la carte IC conformément à une commande de sélection de fichier appliquée depuis le calculateur hôte 4, et l'application sélectionnée est exécutée automatiquement. La figure 2 représente un agencement général de la carte IC selon le premier mode de réalisation de la présente invention. Par exemple, la carte IC 2 comprend la carte IC du type contact comme représenté sur la figure 2. Un circuit LSI (grande échelle l1 d'intégration) 60 est noyé dans un corps de carte 80 réalisé en résine et les contacts 6 du circuit LSI 60 sont exposes sur la surface du corps de carte 80, lesquels contacts 6 du circuit LSI 60 viennent en contact avec les bornes de connexion 7 du dispositif de lecture/écriture de carte IC 3. La figure 3 représente un schéma fonctionnel de la carte IC 2 selon le premier mode de réalisation de la présente invention. Les contacts 6 sont connectés au circuit LSI 60 et ainsi, une connexion externe du circuit LSI 60 est réalisée. Le circuit LSI 60 inclut un circuit d'interface 8 qui joue le rôle d'interface avec le dispositif de lecture/écriture de carte IC 3 qui est connecté au circuit LSI 60 par l'intermédiaire des contacts 6, une CPU ou unité centrale de traitement 9 qui réalise un traitement de données, un système d'exploitation ou OS de base nécessaire pour faire fonctionner la carte IC 2, une ROM ou mémoire morte 10 qui stocke des valeurs établies etc.... une RAM ou mémoire vive 11 qui joue le rôle de zone de travail lorsque la CPU 9 réalise un traitement de données et une mémoire morte programmable et effaçable électriquement (EEPROM) 12 qui stocke la pluralité d'applications qui peuvent être exécutées dans la carte IC 2. La figure 4 représente un agencement de fichiers de î'EEPROM 12 selon le premier mode de réalisation de la présente invention. De façon générale, I'EEPROM 12 inclut une zone de gestion 13 qui stocke une information de gestion permettant de gérer des données et les applications stockées dans d'autres zones de stockage de i'EEPROM 12, une zone de données 14 qui stocke des données telles qu'une structure de fichiers dont les fichiers sont utilisés par les applications et une zone de programmes 15 qui stocke les applications. L'adresse de début, dans la zone de programmes 15, de chaque application stockée dans la zone de programmes 15 se voit octroyer le répertoire le plus élevé des répertoires de la structure de fichiers stockée dans la zone de données 14, les fichiers des répertoires mentionnés ci-avant étant utilisés par les applications mentionnées ci-avant. La zone de programmes 15 est complètement séparée de la zone de données 14 et la frontière de ces deux zones peut être modifiée. La figure 5 représente la séparation des zones dans l'EEPROM 12 selon le premier mode de réalisation de la présente invention. Par report à la figure 5, la frontière "c" entre la zone de données 14 et la zone de programmes 15 est gérée en tant que dernière adresse de la zone de données 14 "adrDD" ou en tant que première adresse de la zone de programmes 15 "adrDA" dans la zone de gestion 13. Lorsque des fichiers stockés dans la zone de données 14 sont mis à jour, une commande est réalisée de telle sorte que les données stockées dans la zone de données 14 n'excèdent pas la frontière "c", c'est-à-dire la dernière adresse "adrDD" de la zone de données 14 ou la première adresse "adrDA" de la zone de programmes 15 en tant que résultat de la mise à jour des fichiers, l'information de frontière "c" étant gérée dans la zone de gestion 13. De façon similaire, lorsque les applications sont mises à jour, une commande est réalisée de telle sorte que les applications stockées dans la zone de programmes 15 n'excèdent pas la frontière "c", c'est-à-dire la dernière adresse "adrDD" de la zone de données 14 ou la première adresse "adrDA" de la zone de programmes 15 en tant que résultat de la mise à jour des applications, l'information de frontière "c" étant gérée dans la zone de gestion 13. En tant que résultat du fait que le fait que les données sont stockées dans la zone de données 14 et que les applications sont stockées dans la zone de programmes 15 est géré en utilisant la frontière "c", les données stockées dans la zone de données 14 sont empêchées d'être détruites par les applications lorsque la mise à jour des applications ou similaire est réalisée et de façon similaire, les applications stockées dans la zone de programmes 15 sont empêchées d'être détruites par les fichiers lorsque la mise à jour des fichiers ou similaire est réalisée. En outre, du fait que l'information de frontière "c" est gérée en utilisant l'adresse établie dans la zone de gestion 13, la position de la frontière "c" peut être aisément modifiée en tant que résultat du fait que l'adresse gérée dans la zone de gestion 13 est modifiée. Ainsi, par exemple, dans le cas o une capacité de stockage de la zone de programmes 15 est insuffisante tandis que la zone de données 14 dispose d'une capacité de stockage libre, la capacité de stockage nécessaire peut être constituée pour la zone de programmes en tant que résultat du fait que simplement l'adresse qui détermine la frontière "c", gérée dans la zone de gestion 13, est modifiée pour être passée sur le côté de la zone de données 14. De façon similaire, dans le cas o une capacité de stockage de la zone de données 14 est insuffisante tandis que la zone de programmes 15 dispose d'une capacité de stockage libre, la capacité de stockage nécessaire peut être assurée pour la zone de données 14 en tant que résultat du fait que seulement l'adresse, qui détermine la frontière "c", gérée dans la zone de gestion 13, est modifiée pour être passée sur le côté de la zone de programmes 15. En outre, selon le premier mode de réalisation, comme représenté sur la figure 6, les données "data 1", "data 2",..., "data m" sont stockées dans la zone de données 14 depuis l'adresse plus faible de l'EEPROM 12 selon l'ordre des adresses tandis que les applications APL1, APL2,..., APLn sont stockées dans la zone de programmes 15 depuis l'adresse plus élevée de 1'EEPROM 12 selon l'ordre inverse à l'ordre des adresses. Par conséquent, les dernières données "data m" de la zone de données 14 sont stockées avant la frontière "c" tandis que la dernière application APLn qui est stockée dans la zone de programmes 15 est stockée après la frontière "c". En tant que résultat, la frontière "c" entre la zone de données 14 et la zone d'applications 15 peut être modifiée sans déplacer les données stockées dans la zone de données 14 ou les applications stockées dans la zone de programmes 15. Plus spécifiquement, lorsque les applications sont stockées dans la zone de programmes 15, en premier lieu, l'application APL1 est stockée depuis l'adresse la plus élevée selon l'ordre inverse à l'ordre des adresses. Puis l'application APL2 est stockée depuis l'adresse immédiatement inférieure à l'adresse au niveau de laquelle le dernier élément de l'application APL1 a été stocké selon l'ordre inverse à l'ordre des adresses. Puis de façon similaire, chaque application suivante est stockée depuis l'adresse plus élevée selon l'ordre inverse à l'ordre des adresses. La figure 7 représente la structure de fichiers stockée dans la zone de données 14 selon le premier mode de réalisation de la présente invention. La structure de fichiers selon le premier mode de réalisation de la présente invention inclut un répertoire maître DLL0 et des parties de fichiers F1 à Fn subordonnées au répertoire maître DLL0. Les parties de fichiers F1 à Fn incluent respectivement des fichiers F1 à Fn qui sont respectivement utilisés par les applications APL1 à APLn et desrépertoires les plus élevés d11i à dlln ainsi que des répertories subordonnés dl 1 11 à dl ln 1. Les adresses de début adrl à adrn des applications APL1 à APLn, lesquelles adresses adrl à adrn sont respectivement des adresses de début dans la zone de programmes 15 à partir desquelles les applications APL1 à APL2 sont stockées, sont respectivement octroyées aux répertoires les plus élevés d 11 à dl in des parties de fichiers F1 à Fn. Les parties de fichiers F1 à Fn incluent des fichiers F1 à Fn utilisés respectivement par les applications APL1 à APLn, comme mentionné ci-avant. La figure 8 représente un organigramme de traitement permettant d'accéder à une application des applications stockées dans la zone de programmes 15 dans la carte IC selon le premier mode de réalisation de la présente invention. Lorsqu'une commande est appliquée depuis le calculateur hôte 4 sur la carte IC 2 par l'intermédiaire du dispositif de lecture/écriture de carte IC 3 (au niveau d'une étape S1-1), la commande reçue est analysée dans la carte IC 2 (au niveau d'une étape S 1-2). Puis il est déterminé si oui ou non la commande reçue est la commande de sélection de fichier (au niveau d'une étape S1-3). Lorsqu'il est déterminé au niveau de l'étape S1-3 que la commande reçue est la commande de sélection de fichier, un fichier spécifié par cette commande de sélection de fichier est sélectionné (au niveau d'une étape S 1-4). Lorsque le fichier est sélectionné au niveau de l'étape S1-4, le répertoire le plus élevé de la partie de fichiers qui inclut le fichier sélectionné est reconnu (au niveau d'une étape S1-5). Puis l'adresse de début de l'application octroyée au répertoire le plus élevé de la partie de fichiers est reconnue, la partie de fichiers correspondant à cette application, c'est-à-dire les fichiers inclus dans la partie de fichiers qui est utilisée par l'application est reconnue (au niveau d'une étape S1-6). Lorsque l'adresse de début de l'application est reconnue au niveau de l'étape S1-6, l'application stockée au niveau de l'adresse de début reconnue est accédée et une commande de l'application est lue à partir de cette adresse de début et l'exécution de l'application est démarrée (au niveau d'une étape S1-7). A cet instant, bien que seulement l'adresse de début de l'application ait été octroyée au répertoire le plus élevé de la partie de fichiers respective, du fait que la dimension de l'application est écrite au niveau de cette adresse de début, la dernière adresse de l'application peut être reconnue. Comme mentionné ci-avant, l'application est stockée depuis une adresse plus élevée selon l'ordre inverse à l'ordre des adresses. Par conséquent, lorsque l'application est exécutée, la valeur de comptage d'un compteur de programme est décrémentée successivement depuis l'adresse de début. Par conséquent, comme mentionné ci-avant, l'information concernant la dimension de l'application est écrite au niveau de l'adresse de début de l'application. Ainsi, c'est seulement en tant que résultat du fait que l'adresse de début de l'application est établie dans le répertoire le plus élevé de la partie de fichiers du fichier sélectionné que l'application souhaitée peut être exécutée. Lorsqu'il est déterminé au niveau de l'étape S1-3 que la commande revue est une autre commande, la carte IC 2 réalise le traitement conformément à cette commande (au niveau d'une étape S 1-8). Par conséquent, selon le premier mode de réalisation de la présente invention, en tant que résultat du fait que seulement un fichier est spécifié au moyen de la commande de sélection de fichier appliquée depuis le calculateur hôte 4, l'application correspondant au fichier spécifié est automatiquement exécutée. Selon le premier mode de réalisation de la présente invention, l'adresse de début de chaque application est octroyée au répertoire le plus élevé d'une partie de fichiers respective. Cependant, il est également possible que l'adresse de début de chaque application soit octroyée à un répertoire subordonné ou à des répertoires subordonnés d'une partie de fichiers respective. La figure 9 représente une structure de fichiers selon un mode de réalisation constitué en tant que variante du premier mode de réalisation de la présente invention. Les mêmes index de référence et les mêmes caractères de référence sont octroyés à des parties/composants qui sont les mêmes que ceux représentés sur la figure 7 et leurs descriptions seront omises. Selon ce mode de réalisation constitué en tant que variante, de façon similaire aux répertoires les plus élevés dll à dlln des parties de fichiers respectives F1 à Fn, les adresses de début, dans la zone de programmes 15, des applications correspondantes sont octroyées aux répertoires d 1111 à d 11 n 1 respectivement subordonnés aux répertoires les plus élevés dl 11 à d 1 ln. Selon ce mode de réalisation constitué en tant que variante, l'adresse de début de chaque application peut être obtenue à partir de n'importe lequel des répertoires d'une partie de fichiers respective. En tant que résultat, il est non nécessaire de sélectionner le répertoire le plus élevé parmi les répertoires de la partie de fichiers. En tant que résultat, l'exécution de l'application peut être realisée rapidement en tant que résultat du fait que l'application est accédée immédiatement. Dans les structures de fichiers représentées sur les figures 7 et 9, les adresses de début des applications sont octroyées respectivement aux répertoires des parties de fichiers F1 à Fn. Cependant, il est également possible que l'adresse de début d'une application APLO soit octroyée au répertoire maitre DLL0. La figure 10 représente la structure de fichiers selon un autre mode de réalisation constitué en tant que variante du premier mode de réalisation de la présente invention. Les mêmes index de référence et les mêmes symboles de référence sont octroyés à des parties/composants qui sont les mêmes que ceux représentés sur la figure 9 et leurs descriptions seront omises. Selon cet autre mode de réalisation constitué en tant que variante, de façon similaire aux répertories les plus élevés dl1 à dlln des parties de fichiers respectives F1 à Fn, les adresses de début, dans la zone de programmes 15, des applications correspondantes sont octroyées aux répertoires d111i à dlIln qui sont subordonnés respectivement aux répertoires les plus élevés dlll à dlln. En outre, l'adresse de début adrO de la zone de programme 15 à partir de laquelle l'application correspondante APLO est stockée est octroyée au répertorie maitre DLLO. Selon cet autre mode de réalisation constitué en tant que variante, l'adresse de chaque application peut être obtenue à partir de n'importe lequel des répertoires d'une partie de fichiers respective. En tant que résultat, il n'est pas nécessaire de sélectionner le répertoire le plus élevé à partir des répertoires de la partie de fichiers. En tant que résultat, l'exécution de l'application peut être réalisée rapidement du fait que la reconnaissance de l'adresse de début de l'application est qu'un accès à celle-ci sont réalisés immédiatement. En outre, en tant que résultat du fait que l'adresse de début adrO de la zone de programmes 15 à partir de laquelle l'application APLO est stockée est octroyée au répertoire maître DLLO, il est possible que l'adresse de début adrO de l'application APLO qui peut utiliser des fichiers d'une pluralité de parties de fichiers dans la structure de fichiers puisse être incluse dans la zone de programmes 15. Dans le cas de cet autre mode de réalisation constitué en tant que variante, lorsque la commande de sélection de fichier appliquée depuis le calculateur hôte 4 spécifie des fichiers d'une pluralité de parties de fichiers (certains de F1, F2,..., Fn), ces fichiers de la pluralité de parties de fichiers sont sélectionnés au niveau de l'étape S1-4. Puis, dans ce cas, le répertoire maître DLLO est reconnu au niveau de l'étape S1-5, l'adresse de début adrO de l'application APLO est reconnue au niveau de l'étape S1-6. Puis une commande de cette application APLO écrite au niveau de l'adresse de début adrO est lue et l'application APLO est exécutée (au niveau de l'étape S 1-7). Dans le cas de cet autre mode de réalisation constitué en tant que variante, lorsque la commande de sélection de fichier appliquée depuis le calculateur hôte 4 spécifie un fichier ou des fichiers d'une unique partie de fichiers Fm (m=1, 2, 3,..., ou n), le fichier ou les fichiers de l'unique partie de fichiers Fm est/sont sélectionné(s) au niveau de l'étape S1-4. Alors, dans ce cas, le répertoire le plus élevé dllm ou le répertoire dllml ou le répertoire similaire subordonné au répertoire le plus élevé est reconnu au niveau de l'étape S1-5, l'adresse de début adrm de l'application APLm est reconnue au niveau de l'étape S1-6. Alors une commande de cette application APLm écrite au niveau de l'adresse de début adrm est lue et l'application APLm est exécutée (au niveau de l'étape S1-7). Dans les modes de réalisation décrits ci-avant, les adresses de début des applications sont respectivement directement octroyées aux répertoires des parties de fichiers. Cependant, il est également possible que des numéros d'identification des applications soient respectivement octroyés aux répertoires, qu'une table de gestion d'application qui stocke les numéros d'identification et les adresses de début des applications présentant les numéros d'identification soit prévue et qu'il soit fait référence à la table de gestion d'application de telle sorte que les adresses de début des applications puissent être respectivement obtenues à partir des numéros d'identification des applications, lesquels numéros d'identification ont été respectivement octroyés aux répertoires. Un mode de réalisation dans le cas o la table de gestion d'application est constituée sera maintenant décrit. L'agencement système du mode de réalisation (second mode de réalisation) est similaire à celui du premier mode de réalisation décrit ci-avant et par conséquent, les descriptions afférentes seront omises. La figure 11 représente un agencement de fichiers d'une EEPROM 20 selon le second mode de réalisation de la présente invention. Les mêmes index de référence ou les mêmes symboles de référence sont octroyés aux parties qui sont les mêmes que celles représentées sur la figure 4 et les descriptions afférentes seront omises. Selon le second mode de réalisation, la table de gestion d'application 21 est prévue dans la zone de gestion 13 de 1'EEPROM et les numéros d'identification des applications sont respectivement octroyés aux répertoires de la structure de fichiers 22 stockée dans la zone de données 14. La figure 12 représente un agencement de données de la table de gestion d'application 21 selon le second mode de réalisation de la présente invention. Comme représenté sur la figure 12, la table de gestion d'application 21 inclut les numéros d'identification #0, #1, #2,....,#n octroyés respectivement aux applications APL0, APL1, APL2,..., APLn stockées dans la zone de programmes 15 de 'EEPROM 20 et les adresses de début adrO, adrl, adr2,..., adrn dans la zone de programmes 15 des applications APL1, APL2,..., APLn présentant respectivement les numéros d'identification #0, #1, #2,..., #n. Les numéros d'identification mentionnés ci-avant #0, #1, #2, #n sont respectivement octroyés aux répertoires qui correspondent respectivement aux applications APL0, APL1, APL2,.... APLn. La figure 13 représente une structure de fichiers selon le second mode de réalisation de la présente invention. Les mêmes index de référence et les mêmes symboles de référence sont octroyés aux parties/composants qui sont les mêmes que ceux représentés sur la figure 10 et les descriptions afférentes seront omises. La structure de fichiers selon le second mode de réalisation inclut le répertoire maître DLL0, les répertoires dlll à dlln subordonnés au répertoire maître DLLO, les répertoires dllll à dl lnl subordonnés respectivement aux répertoires d111 à dl in et les fichiers F1 à Fn comme représenté sur la figure 13. Les numéros d'identification #0, #1, #2,..., #n sont octroyés à ces répertoires en correspondance respectivement avec les applications APL0, APL1, APL2,..., APLn. Les numéros d'identification #0, #1, #2,..., #n sont respectivement utilisés pour identifier les applications APL0, APL1, APL2,..., APLn. La figure 14 représente un organigramme de traitement permettant d'accéder à une application dans la carte IC selon le second mode de réalisation de la présente invention. Lorsqu'une commande est appliquée depuis le calculateur hôte 4 sur la carte IC 2 par l'intermédiaire du dispositif de lecture/écriture de carte IC 3 (au niveau d'une étape S2-1), la commande reçue est analysée (au niveau d'une étape S2-2). Puis il est déterminé si oui ou non la commande reçue est la commande de sélection de fichier (au niveau d'une étape S2-3). Lorsqu'il est déterminé au niveau de l'étape S2-3 que la commande reçue est la commande de sélection de fichier, un fichier spécifié par cette commande de sélection de fichier est sélectionné (au niveau d'une étape S2-4). Lorsque le fichier est sélectionné au niveau de l'étape S2-4, un répertoire de la partie de fichiers du fichier sélectionné est reconnu (au niveau d'une étape S2-5). Puis le numéro d'identification de l'application (l'un de #1, #2,..., #n) octroyé au répertoire reconnu de la partie de fichiers est reconnu, laquelle partie correspond à cette application (au niveau de l'étape S2-6). Lorsque le numéro d'identification de l'application est reconnu au niveau de l'étape S2-6, il est fait référence à la table de gestion d'application 21 établie dans la zone de gestion 13 de l'EEPROM 20 (au niveau d'une étape S2-7). Ainsi, l'adresse de début (l'une des adresses adrl, adr2,..., adrn) dans la zone de programmes 15 de l'application (l'une des applications APL1, APL2,..., APLn) correspondant au numéro d'identification (l'un de #1, #2,..., #n) est obtenue (au niveau d'une étape S2-8). L'adresse de début (l'une de adrl, adr2,..., adrn) de l'application (l'une des applications APL1, APL2,..., APLn) est accédée, une commande de cette application est lue depuis l'adresse de début accédée et l'exécution de cette application est démarrée (au niveau d'une étape S2-9). Lorsqu'il est déterminé au niveau de l'étape S2-3 que la commande reçue est une autre commande, le traitement conformément à cette commande est réalisé (au niveau d'une étape S2-10). Lorsque la commande de sélection de fichier appliquée depuis le calculateur hôte 4 spécifie des fichiers d'une pluralité de parties de fichiers (comme pris parmi F1, F2,..., Fn), ces fichiers de la pluralité de parties de fichiers sont sélectionnés au niveau de l'étape S2-4. Ensuite, dans ce cas, le répertoire maître DLLO est reconnu et le numéro d'identification #O octroyé au répertoire maître DLL0 est reconnu au niveau de l'étape S2-6. Alors il est fait référence à la table de gestion d'application 21 (au niveau de l'étape S2-7) et l'adresse de début adrO de l'application APLO est obtenue au niveau de l'étape S2- 8. Puis une commande de cette application APLO écrite au niveau de l'adresse de début adrO est lue et l'application APLO est exécutée (au niveau de l'étape S2-9). Lorsque la commande de sélection de fichier appliquée depuis le calculateur hôte 4 spécifie des fichiers d'une unique partie de fichiers Fm (m=l, 2, 3,..., ou n), ces fichiers de l'unique partie de fichiers sont sélectionnés au niveau de l'étape S2-4. Puis dans ce cas, le répertoire le plus élevé dllm, ou le répertoire dllml ou le répertoire similaire subordonné au répertoire le plus élevé est reconnu et le numéro d'identification #m octroyé au répertoire le plus élevé dl lm ou au répertoire dllml ou au répertoire similaire subordonné au répertoire le plus élevé est reconnu au niveau de l'étape S2-6. Puis il est fait référence à la table de gestion d'application 21 (au niveau de l'étape S2-7) et l'adresse de début adrm de l'application APLm est obtenue au niveau de l'étape S2-8. Puis une commande de cette application APLm écrite à l'adresse de début adrm est lue et l'application APLm est exécutée (au niveau de l'étape S2-9). Par conséquent, selon le second mode de réalisation de la présente invention, en tant que résultat du fait que seulement un fichier (ou des fichiers) est spécifié par la commande de sélection de fichier appliquée depuis le calculateur hôte 4, l'application correspondant au(x) fichier(s) spécifié(s) est automatiquement exécutée. Selon le second mode de réalisation, lorsqu'une application est mise à jour, une application existante est laissée telle quelle et une application mise à jour est stockée additionnellement dans la zone de programmes 15. Puis l'adresse de l'application correspondant au numéro d'identification de l'application à mettre a jour est modifiée selon l'adresse de début d'une application obtenue en tant que résultat du fait que l'application à mettre à jour est mise à jour. Les figures 15, 16 et 17 représentent des fonctionnements selon le second mode de réalisation de la présente invention pour mettre à jour une application stockée dans la zone de programmes 15. La figure 15 représente des états de la zone de programmes 15 et de la table de gestion d'application 21 avant qu'une application ne soit mise à jour. La figure 16 représente des états de la zone de programmes 15 et de la table de gestion d'application 21 après que l'application est mise à jour. La figure 17 représente des états de la zone de programmes 15 et de la table de gestion d'application 21 après que la première application est supprimée. Comme représenté sur la figure 15, dans le cas o l'application APL1 est stockée dans la zone de programmes 15, le numéro d'identification #1 permettant d'identifier l'application APL1 et l'adresse de début adrl de l'application APL1 sont stockés dans la table de gestion d'application 21. Lorsque l'application APL1 est mise à jour, comme représenté sur la figure 16, l'application APL1 est laissée telle quelle et une application APLi' obtenue à partir de l'application APL1 qui est mise à jour est stockée additionnellement dans la zone de programmes 15. Puis l'adresse de début adrl de la première application APL1 correspondant au numéro d'identification #1 est modifiée selon l'adresse de début adrl' de l'application nouvellement stockée APLi', comme représenté sur la figure 16. Par conséquent, l'application APL 1 correspondant à l'identification #1 est modifiée selon l'application APLi' tandis que la première application APL1 est laissée dans la zone de programmes 15 telle quelle. En outre, afin d'utiliser efficacement la capacité de stockage de la zone de programmes 15, comme représenté sur la figure 17, la première application APL1 peut être supprimée de la zone de programmes 15. Dans ce cas, la première application APL1 est supprimée, l'application nouvellement stockée APLi' est déplacée jusqu'à la position au niveau de laquelle la première application APL1 a été stockée et l'adresse de début pour le numéro d'identification # 1 est retournée à la première adresse de début adrl. Par conséquent, l'application APL1 est mise à jour selon l'application APL 1'. Selon le second mode de réalisation, il est possible de supprimer de manière substantielle une application de la zone de programmes 15 seulement en faisant en sorte que le numéro d'identification de l'application soit supprimé de façon substantielle pour devenir inopérant dans le cas o les applications sont gérées en utilisant les numéros d'identification. Par conséquent, lorsque les applications sont gérées en utilisant les numéros d'identification, il est possible de simplifier de manière substantielle le processus de suppression d'une application de la zone de programmes 15 seulement en modifiant l'adresse de début de l'application à supprimer selon un numéro ou symbole inopérant (par exemple un numéro qui n'est pas inclus dans les adresses de l'EEPROM). Ainsi, il est possible de supprimer de manière substantielle une application non nécessaire de la zone de programmes 15 sans supprimer réellement cette application. Dans le premier mode de réalisation décrit ci-avant, une application est accédée au moyen de l'utilisation de son adresse de début. Dans le second mode réalisation décrit ci-avant, une application est accédée en utilisant son adresse de début qui est obtenue par l'intermédiaire de la table de gestion d'application 21 à partir du numéro d'identification de l'application à exécuter. Un agencement dans lequel, sans utiliser la table de gestion 21, une application est accédée directement en utilisant son numéro * d'identification peut être considéré. La figure 18 représente des opérations permettant d'exécuter une application selon un troisième mode de réalisation de la présente invention. Selon le troisième mode de réalisation, sans utiliser la table de gestion 21, une application est accédée directement en utilisant son numéro d'identification. Le troisième mode de réalisation inclut la structure de fichiers qui est la même que celle du second mode de réalisation représenté sur la figure 13. Le troisième mode de réalisation n'inclut pas la table de gestion d'application 21. Selon le troisième mode de réalisation, lorsque l'un des numéros d'identification #0 à #n est obtenu à partir d'un répertoire des répertoires représentés sur la figure 13, par exemple lorsqu'un numéro d'identification #m est obtenu, l'adresse de début adrO de la première application stockée est recherchée. Puis l'information de dimension SO qui indique la dimension de l'application APLO et qui est stockée au niveau de l'adresse de début adrO de l'application APLO est obtenue. Puis, en tant que valeur initiale, le numéro d'identification #0 est obtenu. Puis l'adresse de début adrl de l'application APL1 qui est stockée à la suite de l'application APLO est recherchée en tant que résultat de la soustraction de la dimension indiquée par l'information de dimension SO de l'adresse de début adrO de l'application APLO. Ensuite, l'information de dimension S1 qui indique la dimension de l'application APL1 et qui est stockée à l'adresse de début adrl de l'application APL1 est obtenue. Puis le numéro d'identification #1 est obtenu en tant que résultat du fait que "1" est additionné au numéro d'identification préalablement obtenu #0. Les opérations mentionnées ci-avant sont répétées jusqu'à ce que le numéro d'identification #m soit obtenu. L'information de fin est stockée à la dernière adresse de la dernière application APLn de telle sorte que l'adresse de début d'une nouvelle application peut être aisément établie lorsque la nouvelle application est stockée dans la zone de programmes 15. Dans le troisième mode de réalisation décrit ci-avant, du fait que la table de gestion d'application 21 n'est pas nécessaire, il est possible d'utiliser efficacement la capacité de stockage de l'EEPROM. Dans chacun des premier, deuxième et troisième modes de réalisation, les applications sont stockées depuis une adresse plus haute vers une adresse plus basse, comme décrit ci-dessus. Cependant, la relation entre la zone de gestion 13, la zone de données 14 et la zone de programmes 15 et la relation entre les adresses sont relatives. Par conséquent, il n'est pas nécessaire d'être limité à la forme mentionnée ci-avant. En outre, le cas o la carte IC du type contact est utilisée a été décrit dans la description des modes de réalisation. Cependant, chacun de ces modes de réalisation peut être appliqué au cas o une carte IC du type sans contact est utilisée à la place de la carte IC du type contact. En outre, la présente invention n'est pas limitée aux modes de réalisation décrits ci-dessus et des variantes et modifications peuvent être proposées sans sortir du cadre de la présente invention. Le contenu de la demande de brevet du Japon N 10-011689 déposée le 23 janvier 1998 est à prendre en considération pour une meilleure compréhension de l'invention. REVENDICATIONS 1. Procédé de gestion d'application, caractérisé en ce qu'il comprend les étapes de; stockage d'applications et de données utilisées par lesdites applications dans une série de zones de stockage; et gestion des applications et des données utilisées par lesdites applications stockées dans ladite série de zones de stockage, dans lequel ladite série de zones de stockage est divisée selon une zone de programmes qui stocke lesdites applications et selon une zone de données qui stocke lesdites données utilisées par lesdites applications. 2. Procédé de gestion d'application selon la revendication 1, caractérisé en ce qu'une frontière entre ladite zone de programmes et ladite zone de données peut être modifiée. 3. Procédé de gestion d'application selon la revendication 2, caractérisé en ce que, lorsque lesdites applications sont stockées dans ladite zone de programmes, lesdites applications sont stockées depuis une extrémité de ladite zone de programmes opposée à ladite frontière. 4. Appareil de traitement d'information qui stocke des applications (APL1 a APLn) et des données utilisées par lesdites applications dans une série de zones de stockage, caractérisé en ce que ladite série de zones de stockage est divisée selon deux zones prédéterminées, I'une desdites deux zones prédéterminées stockant les applications et l'autre desdites deux zones prédéterminées stockant les données utilisées par lesdites applications.