FR2774785A1 - Procede de gestion d'application et appareil de traitement d'information utilisant le procede - Google Patents
Procede de gestion d'application et appareil de traitement d'information utilisant le procede Download PDFInfo
- Publication number
- FR2774785A1 FR2774785A1 FR9900092A FR9900092A FR2774785A1 FR 2774785 A1 FR2774785 A1 FR 2774785A1 FR 9900092 A FR9900092 A FR 9900092A FR 9900092 A FR9900092 A FR 9900092A FR 2774785 A1 FR2774785 A1 FR 2774785A1
- Authority
- FR
- France
- Prior art keywords
- application
- applications
- card
- stored
- directory
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/357—Cards having a plurality of specified features
- G06Q20/3576—Multiple memory zones on card
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Software Systems (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Stored Programmes (AREA)
Abstract
Des applications et des données utilisées par les applications sont stockées dans une série de zones de stockage. Une gestion des applications et des données utilisées par les applications est réalisée de telle sorte 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.
Description
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.
Claims (4)
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.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10011689A JPH11212774A (ja) | 1998-01-23 | 1998-01-23 | アプリケーション管理方法、及び、それを用いた情報処理装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2774785A1 true FR2774785A1 (fr) | 1999-08-13 |
| FR2774785B1 FR2774785B1 (fr) | 2005-04-15 |
Family
ID=11785005
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR9810570A Expired - Fee Related FR2774189B1 (fr) | 1998-01-23 | 1998-08-20 | Procede de gestion d'application et appareil de traitement d'information utilisant le procede |
| FR9900092A Expired - Fee Related FR2774785B1 (fr) | 1998-01-23 | 1999-01-07 | Procede de gestion d'application et appareil de traitement d'information utilisant le procede |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR9810570A Expired - Fee Related FR2774189B1 (fr) | 1998-01-23 | 1998-08-20 | Procede de gestion d'application et appareil de traitement d'information utilisant le procede |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7308433B1 (fr) |
| JP (1) | JPH11212774A (fr) |
| FR (2) | FR2774189B1 (fr) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2897705A1 (fr) * | 2006-02-22 | 2007-08-24 | Proton World Internatinal Nv | Mise a jour d'une carte a puce |
| US7447864B2 (en) * | 2006-03-16 | 2008-11-04 | Fujitsu Limited | Memory area allocation control device for allocating target information to free area of memory area, storage medium storing its program and its method |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1113387A3 (fr) * | 1999-12-31 | 2001-11-21 | SCHLUMBERGER Systèmes | Carte à puce comportant une mémoire non volatile avec un mappage nouveau |
| JP4601144B2 (ja) * | 2000-09-25 | 2010-12-22 | 哲男 阿部 | プログラム開発システム、記録媒体および方法 |
| FR2816090B1 (fr) * | 2000-10-26 | 2003-01-10 | Schlumberger Systems & Service | Dispositif de partage de fichiers dans un dispositif a circuit integre |
| EP1518169A2 (fr) * | 2002-02-18 | 2005-03-30 | Axalto SA | Organisation des donnees dans une carte a puce |
| JP2004029945A (ja) * | 2002-06-21 | 2004-01-29 | Dainippon Printing Co Ltd | Ｉｃカード及びｉｃカードプログラム |
| JP4185715B2 (ja) * | 2002-06-28 | 2008-11-26 | 大日本印刷株式会社 | Ｉｃカード及びｉｃカードプログラム |
| WO2004081859A1 (fr) | 2003-03-12 | 2004-09-23 | Telia Ab (Publ) | Dispositif et procede pour le traitement des services |
| US20090112766A1 (en) * | 2007-10-25 | 2009-04-30 | Ayman Hammad | Device including multiple payment applications |
| WO2011081950A1 (fr) * | 2009-12-14 | 2011-07-07 | Massachussets Institute Of Technology | Procédés, systèmes et supports utilisant des techniques de classement dans un apprentissage machine |
| JP5558394B2 (ja) | 2011-03-18 | 2014-07-23 | 株式会社東芝 | 通信媒体、ｉｃカード、コマンド実行方法 |
| AU2015201772B2 (en) * | 2011-09-16 | 2015-07-30 | Google Llc | Secure application directory |
| AU2014202122B2 (en) * | 2011-09-16 | 2015-01-15 | Google Llc | Secure application directory |
| US8313036B1 (en) * | 2011-09-16 | 2012-11-20 | Google Inc. | Secure application directory |
| CN103761126B (zh) * | 2014-01-07 | 2017-03-15 | 中国神华能源股份有限公司 | 应用程序的升级方法和装置 |
| JP2017045103A (ja) * | 2015-08-24 | 2017-03-02 | 大日本印刷株式会社 | 電子情報記憶媒体、情報処理方法、及び情報処理プログラム |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0292248A2 (fr) * | 1987-05-19 | 1988-11-23 | THE GENERAL ELECTRIC COMPANY, p.l.c. | Système de traitement de données |
| JPS6429051A (en) | 1987-07-24 | 1989-01-31 | Nippon Telegraph & Telephone | Ic card telephone system |
| JPS6431285A (en) | 1987-07-28 | 1989-02-01 | Toshiba Corp | Portable electronic equipment |
| FR2626696A1 (fr) * | 1988-02-03 | 1989-08-04 | Toshiba Kk | Systeme d'enregistrement en memoire pour dispositif electronique portatif du type carte |
| FR2635886A1 (fr) * | 1988-08-26 | 1990-03-02 | Toshiba Kk | Procede et dispositif pour traiter des donnees dans la memoire d'une carte a puce |
| JPH04255089A (ja) | 1991-02-06 | 1992-09-10 | Fujitsu Ltd | ビジュアルｉｃカード |
| EP0565389A1 (fr) * | 1992-02-24 | 1993-10-13 | Gemplus Card International | Procédé de personnalisation d'une carte à puce |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2514954B2 (ja) | 1987-03-13 | 1996-07-10 | 三菱電機株式会社 | Ｉｃカ−ド |
| JP3032207B2 (ja) | 1987-04-24 | 2000-04-10 | 株式会社日立製作所 | マイクロ・コンピュータ |
| JPH065272Y2 (ja) | 1987-08-18 | 1994-02-09 | スズキ株式会社 | フロントグリルの取付構造 |
| JPS6431285U (fr) | 1987-08-19 | 1989-02-27 | ||
| US5276903A (en) * | 1988-08-12 | 1994-01-04 | Hatachi Maxell, Ltd. | Method for rewriting partial program data in an IC card and apparatus therefor |
| JPH02287739A (ja) | 1989-04-28 | 1990-11-27 | Moji Zukei Center:Kk | メモリアクセス方法 |
| JPH03232029A (ja) * | 1989-12-08 | 1991-10-16 | Fuji Photo Film Co Ltd | メモリカードの記憶管理方式 |
| JPH0511987A (ja) | 1991-07-04 | 1993-01-22 | Nec Corp | アプリケーシヨンプログラム起動方式 |
| FR2683357A1 (fr) | 1991-10-30 | 1993-05-07 | Philips Composants | Microcircuit pour carte a puce a memoire programmable protegee. |
| US5423034A (en) * | 1992-06-10 | 1995-06-06 | Cohen-Levy; Leon | Network file management with user determined hierarchical file structures and means for intercepting application program open and save commands for inputting and displaying user inputted descriptions of the location and content of files |
| FR2693008B1 (fr) | 1992-06-30 | 1994-08-26 | Gemplus Card Int | Procédé de reconnaissance des fichiers dans une mémoire, notamment une mémoire pour carte à circuit intégré. |
| EP0583006B2 (fr) | 1992-08-13 | 2006-11-29 | Matsushita Electric Industrial Co., Ltd. | Carte IC avec structure de fichier hiérarchique |
| US5590306A (en) * | 1992-09-08 | 1996-12-31 | Fuji Photo Film Co., Ltd. | Memory card management system for writing data with usage and recording codes made significant |
| JPH06175905A (ja) * | 1992-12-03 | 1994-06-24 | Fujitsu Ltd | 暗号化ファイル共有方法 |
| JPH06348556A (ja) | 1993-06-12 | 1994-12-22 | Nec Corp | 記憶域管理システム |
| JP3729421B2 (ja) * | 1994-03-18 | 2005-12-21 | 富士通株式会社 | 不正使用防止方法及び不正使用防止システム |
| JP4095680B2 (ja) * | 1994-08-01 | 2008-06-04 | 富士通株式会社 | カード型記憶装置用セキュリティ管理方法およびカード型記憶装置 |
| JP3691871B2 (ja) * | 1995-03-20 | 2005-09-07 | 富士通株式会社 | カード型記憶媒体 |
| US5778392A (en) * | 1996-04-01 | 1998-07-07 | Symantec Corporation | Opportunistic tile-pulling, vacancy-filling method and apparatus for file-structure reorganization |
| JP2912236B2 (ja) | 1996-06-19 | 1999-06-28 | 日本電気ソフトウェア株式会社 | メモリのプログラム実行領域とファイル領域の確保方式 |
| JPH1011689A (ja) | 1996-06-21 | 1998-01-16 | Anritsu Corp | 自動検針用無線システム |
| US6148377A (en) * | 1996-11-22 | 2000-11-14 | Mangosoft Corporation | Shared memory computer networks |
| US6449607B1 (en) * | 1998-09-11 | 2002-09-10 | Hitachi, Ltd. | Disk storage with modifiable data management function |
-
1998
- 1998-01-23 JP JP10011689A patent/JPH11212774A/ja active Pending
- 1998-07-27 US US09/122,740 patent/US7308433B1/en not_active Expired - Fee Related
- 1998-08-20 FR FR9810570A patent/FR2774189B1/fr not_active Expired - Fee Related
-
1999
- 1999-01-07 FR FR9900092A patent/FR2774785B1/fr not_active Expired - Fee Related
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0292248A2 (fr) * | 1987-05-19 | 1988-11-23 | THE GENERAL ELECTRIC COMPANY, p.l.c. | Système de traitement de données |
| JPS6429051A (en) | 1987-07-24 | 1989-01-31 | Nippon Telegraph & Telephone | Ic card telephone system |
| JPS6431285A (en) | 1987-07-28 | 1989-02-01 | Toshiba Corp | Portable electronic equipment |
| FR2626696A1 (fr) * | 1988-02-03 | 1989-08-04 | Toshiba Kk | Systeme d'enregistrement en memoire pour dispositif electronique portatif du type carte |
| FR2635886A1 (fr) * | 1988-08-26 | 1990-03-02 | Toshiba Kk | Procede et dispositif pour traiter des donnees dans la memoire d'une carte a puce |
| JPH04255089A (ja) | 1991-02-06 | 1992-09-10 | Fujitsu Ltd | ビジュアルｉｃカード |
| EP0565389A1 (fr) * | 1992-02-24 | 1993-10-13 | Gemplus Card International | Procédé de personnalisation d'une carte à puce |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2897705A1 (fr) * | 2006-02-22 | 2007-08-24 | Proton World Internatinal Nv | Mise a jour d'une carte a puce |
| US7447864B2 (en) * | 2006-03-16 | 2008-11-04 | Fujitsu Limited | Memory area allocation control device for allocating target information to free area of memory area, storage medium storing its program and its method |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2774785B1 (fr) | 2005-04-15 |
| FR2774189A1 (fr) | 1999-07-30 |
| US7308433B1 (en) | 2007-12-11 |
| FR2774189B1 (fr) | 2005-04-15 |
| JPH11212774A (ja) | 1999-08-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2774785A1 (fr) | Procede de gestion d'application et appareil de traitement d'information utilisant le procede | |
| EP0207115B1 (fr) | Procede pour personnaliser des supports portatifs tels que des cartes | |
| CA2052656C (fr) | Carte a microprocesseur concue pour recevoir des programmes multiples en memoire programmable | |
| EP0552078B1 (fr) | Carte enfichable pour microordinateur formant lecteur de carte à contacts affleurants | |
| FR2612316A1 (fr) | Carte a circuits integres ayant une capacite de verification d'erreur interne | |
| FR2635891A1 (fr) | Dispositif electronique portatif comportant des donnees-cle limitant l'acces a la memoire | |
| EP2239712A1 (fr) | Procédé pour personnaliser un dispositif électronique, procédé de traitement de données et dispositif associés | |
| EP2786317A1 (fr) | Ecriture de données dans une mémoire non volatile de carte à puce | |
| WO1994018628A1 (fr) | Procede de communication avec un support portatif | |
| FR2663143A1 (fr) | Dispositif electronique portable. | |
| FR2918483A1 (fr) | Dispositif electronique portable et procede de gestion de fichier destine a etre utilise dans un dispositif electronique portable | |
| EP1388134A1 (fr) | Procede et systeme de gestion de donnes destinees a etre stockees dans une carte a puce programmable | |
| EP1585071B1 (fr) | Partage de fichiers non divisibles | |
| FR2667192A1 (fr) | Procede de comptage en memoire eeprom et son utilisation pour la realisation d'un compteur securise. | |
| WO2014063940A1 (fr) | Procede de gestion d'identifiants dans une carte a circuit integre et carte a circuit integre correspondante | |
| FR2806813A1 (fr) | Systeme de gestion de memoire pour cartes a puce permettant a un utilisateur d'avoir acces a certaines prestations dans le cadre notamment d'une gestion informatisee des services de la ville | |
| EP1125259B1 (fr) | Dispositif et procede pour la securisation d'un circuit integre | |
| FR2747813A1 (fr) | Systeme securise de controle d'acces permettant l'invalidation automatique de cles electroniques volees ou perdues et/ou le transfert d'habilitation a produire des cles | |
| FR2813468A1 (fr) | Securite d'acces par code secret a un moyen de traitement de donnees | |
| FR2809847A1 (fr) | Procede de personnalisation electrique de carte a puce | |
| EP1467283B1 (fr) | Système de sauvegarde centralisée d'informations. | |
| FR2923630A1 (fr) | Dispositif electronique portable et procede de controle d'un dispositif electronique portable | |
| FR2693008A1 (fr) | Procédé de reconnaissance des fichiers dans une mémoire, notamment une mémoire pour carte à circuit intégré. | |
| CA1262962A (fr) | Procede pour personnaliser des supports portatifs tels que des cartes | |
| EP0997854B1 (fr) | Dispositif pour la gestion d'accès dans une carte à circuit intégré |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20130430 |