WO2005059847A1 - Microcircuit multi-account card for restricting an account operation and corresponding communication method - Google Patents

Microcircuit multi-account card for restricting an account operation and corresponding communication method Download PDF

Info

Publication number
WO2005059847A1
WO2005059847A1 PCT/FR2004/003254 FR2004003254W WO2005059847A1 WO 2005059847 A1 WO2005059847 A1 WO 2005059847A1 FR 2004003254 W FR2004003254 W FR 2004003254W WO 2005059847 A1 WO2005059847 A1 WO 2005059847A1
Authority
WO
WIPO (PCT)
Prior art keywords
card
applet
execution
application
account
Prior art date
Application number
PCT/FR2004/003254
Other languages
French (fr)
Inventor
Stéphane JAYET
Original Assignee
Oberthur Card Systems Sa
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Oberthur Card Systems Sa filed Critical Oberthur Card Systems Sa
Publication of WO2005059847A1 publication Critical patent/WO2005059847A1/en

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
    • 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
    • G06Q20/35765—Access rights to memory zones

Abstract

The inventive microcircuit card (10) comprises a plurality of accounts, a unit for swinging from one account to another, a unit for performing an application to an account and a memory unit (15) for memorising information related to the right for application to one or several accounts. Said microcircuit card (10) also comprises a unit (16, 26; 19, 24) for prohibiting, according to information on the right for application, to apply to one or several specific accounts which are selected from the plurality thereof in such a way that the application to the other accounts remains authorised.

Description

CARTE A MICROCIRCUIT MULTI-COMPTE PERMETTANT LA RESTRICTION D'UNE FONCTIONNALITE A UN COMPTE ET PROCEDE DE COMMUNICATION CORRESPONDANT La présente invention se rapporte à une carte à microcircuit comportant plusieurs comptes - appelée dans toute la suite carte à microcircuit multi-compte - permettant de limiter l'exécution d'une fonctionnalité à un compte particulier de la carte à microcircuit, en interdisant l'exécution de cette fonctionnalité sur d'autres comptes de la carte à microcircuit. L'invention se rapporte aussi à un procédé de communication entre une telle carte à microcircuit et une ou plusieurs entités extérieures. Entre autres exemples de cartes à microcircuit entrant dans le champ d'application de l'invention, on trouve les cartes SIM (module d'identification de l'abonné, en anglais "Subscriber Identity Module") d'abonnement à un opérateur de réseau de télécommunications, les cartes bancaires, les cartes de contrôle d'accès, les cartes d'identité ou passeports ou autres documents officiels, les cartes mémoire, etc. Un "compte" de la carte à microcircuit est compris ici comme l'ensemble des fonctionnalités et des données de la carte à microcircuit qui se rapportent à un utilisateur. Un compte peut correspondre par exemple à un abonnement GSM The present invention relates to a microcircuit card comprising several accounts - hereafter called a multi-account microcircuit card - making it possible to limit the execution of a functionality to a particular account of the microcircuit card, by prohibiting the execution of this functionality on other accounts of the microcircuit card. The invention also relates to a method of communication between such a microcircuit card and one or more external entities. Among other examples of microcircuit cards falling within the scope of the invention, there are SIM cards (subscriber identification module, in English "Subscriber Identity Module") for subscription to a network operator telecommunications, bank cards, access control cards, identity cards or passports or other official documents, memory cards, etc. An "account" of the microcircuit card is understood here as all the functionalities and data of the microcircuit card which relate to a user. An account can correspond for example to a GSM subscription
(norme de télécommunications mobiles, en anglais "Global System for Mobile communications") ou à un compte bancaire, ces exemples n'étant bien entendu pas limitatifs. Une carte à microcircuit multi-compte peut par exemple comporter un premier compte utilisé pour un ensemble d'applications bancaires (telles que la consultation et la gestion de comptes bancaires ou de portefeuilles d'actions, le paiement d'achats, le retrait de sommes d'argent, etc.) et un deuxième compte utilisé pour un ensemble d'applications de transport (telles que l'accès à des portillons d'un réseau de transport en commun, le contrôle du nombre de personnes habilitées à franchir ces portillons, etc.). Actuellement, on connaît des cartes à microcircuit multi-compte (comportant au moins deux comptes) uniquement dans le domaine des cartes d'abonnement à un opérateur de télécommunications mobiles. Ainsi, par exemple, les abonnements "PRO/PERSO", c'est-à-dire correspondant à la fois à un compte professionnel et à un compte personnel, permettent, via un menu (offert par le "SIM toolkit" dans le cas du GSM) d'un terminal de téléphonie mobile ou tout autre type de terminal mobile (par exemple un assistant numérique personnel ou PDA - en anglais "Personal Digital(mobile telecommunications standard, in English "Global System for Mobile communications") or to a bank account, these examples are of course not limiting. A multi-account microcircuit card can, for example, include a first account used for a set of banking applications (such as consulting and managing bank accounts or stock portfolios, payment for purchases, withdrawal of sums money, etc.) and a second account used for a set of transport applications (such as access to gates of a public transport network, control of the number of people authorized to pass through these gates, etc.). Currently, multi-account microcircuit cards (comprising at least two accounts) are known only in the field of subscription cards to a mobile telecommunications operator. Thus, for example, the "PRO / PERSO" subscriptions, that is to say corresponding to both a professional account and a personal account, allow, via a menu (offered by the "SIM toolkit" in the case GSM) of a mobile telephone terminal or any other type of mobile terminal (for example a personal digital assistant or PDA - in English "Personal Digital
Assistant'), de basculer du compte professionnel vers le compte personnel de l'utilisateur (par exemple pour la réalisation d'un appel téléphonique personnel) et vice versa. Dans ce cas, une carte SIM attribuée à un abonné PRO/PERSO comporte deux nombres IMSI (identifiants internationaux d'abonné mobile, en anglais "International Mobile Subscriber Identity") respectivement attachés à chacun des deux comptes. La carte SIM permet en outre une facturation séparée pour chacun des comptes. Un autre exemple connu de carte multi-compte faisant son apparition est une carte comportant un compte SIM et un compte USIM (module universel d'identification de l'abonné, en anglais "Universal Subscriber Identity Module"). La demanderesse à cherché une solution permettant d'interdire l'exécution d'une fonctionnalité sur un des comptes d'une carte à microcircuit multi-compte, tout en la laissant libre d'utilisation sur d'autres comptes de la même carte à microcircuit. Il est en effet utile de pouvoir différencier ainsi les divers comptes d'une même carte : on pourra ainsi permettre, par exemple, à l'utilisateur d'une carteAssistant '), to switch from the professional account to the personal account of the user (for example for making a personal phone call) and vice versa. In this case, a SIM card assigned to a PRO / PERSO subscriber has two IMSI numbers (international mobile subscriber identifiers, in English "International Mobile Subscriber Identity") respectively attached to each of the two accounts. The SIM card also allows separate billing for each account. Another known example of a multi-account card appearing is a card comprising a SIM account and a USIM account (universal subscriber identification module, in English "Universal Subscriber Identity Module"). The plaintiff sought a solution making it possible to prohibit the execution of a functionality on one of the accounts of a multi-account microcircuit card, while leaving it free to use on other accounts of the same microcircuit card. . It is indeed useful to be able to differentiate the various accounts of the same card in this way: this will allow, for example, the user of a card
PRO/PERSO d'accéder à des applications de jeux en ligne payantes lorsqu'il utilise son compte personnel et ne pas permettre cet accès lorsqu'il utilise son compte professionnel. Par ailleurs, dans le souci de rechercher une solution satisfaisante, la demanderesse a souhaité tenir compte de l'importance croissante de l'interopérabilité des systèmes d'exploitation dans le domaine des cartes à microcircuit. L'interopérabilité des systèmes d'exploitation s'est considérablement développée avec l'apparition de plateformes JavaCard. Ainsi, le système d'exploitation d'une carte peut disposer d'une machine virtuelle JavaCard qui permet d'intégrer des composants logiciels, sous forme d'appliquettes, développées de façon indépendante, par exemple par un client du fabricant de cartes. Comme le sait l'homme du métier, une appliquette ou "applet" est une application dans le contexte JavaCard. Dans tout la suite de la description, on utilise pour simplifier le terme "applet", acronyme de l'anglais "APPlication Light wEighV, au sens de "appliquette". En termes de programmation, un applet est un objet, au sens de la programmation orientée objet. Un applet est identifié par un identifiant d'application AID (en anglaisPRO / PERSON to access paid online gaming applications when using their personal account and not allow this access when using their professional account. Furthermore, in order to seek a satisfactory solution, the applicant wished to take into account the growing importance of the interoperability of operating systems in the field of microcircuit cards. The interoperability of operating systems has developed considerably with the appearance of JavaCard platforms. Thus, the operating system of a card can have a JavaCard virtual machine which makes it possible to integrate software components, in the form of applets, developed independently, for example by a customer of the card manufacturer. As a person skilled in the art knows, an applet or "applet" is an application in the JavaCard context. In the remainder of the description, the term "applet", acronym from the English "APPlication Light wEighV, in the sense of" applet "is used to simplify. In terms of programming, an applet is an object, within the meaning of the object oriented programming. An applet is identified by an AID application identifier
"Application Identifier"). Un applet comporte notamment une série de méthodes, qui sont des programmes, dont certains peuvent être invoqués, c'est-à-dire dont l'exécution peut être lancée, par un terminal, par envoi de messages appropriés"Application Identifier"). An applet notably comprises a series of methods, which are programs, some of which can be invoked, that is to say the execution of which can be launched, by a terminal, by sending appropriate messages.
(du type d'une commande APDU) à une carte à microcircuit. Parmi ces "méthodes", on trouve le "constructeur" de l'applet, qui permet d'instancier (en anglais "to instantiate") l'applet. Le constructeur porte le nom de l'applet et est invoqué par la méthode "new", bien connue de l'homme du métier.(of the type of an APDU command) to a microcircuit card. Among these "methods", we find the "constructor" of the applet, which allows to instantiate (in English "to instantiate") the applet. The constructor bears the name of the applet and is invoked by the "new" method, well known to those skilled in the art.
Cette méthode est lancée à chaque installation de l'applet. De tels applets peuvent être chargés dans la carte à microcircuit, soit directement dans le code ROM (mémoire morte, en anglais "Read Only Memory") du système d'exploitation, soit dans l'EEPROM (mémoire morte programmable et effaçable électriquement, en anglais "Electrically ErasableThis method is launched each time the applet is installed. Such applets can be loaded into the microcircuit card, either directly in the ROM code (read only memory) of the operating system, or in the EEPROM (electrically erasable programmable read only memory). English "Electrically Erasable
Programmable Read Only Memory") lors des phases finales de la fabrication de la carte, par exemple en cours de pré-personnalisation ou de personnalisation, ou encore après livraison de la carte (c'est-à-dire en "post-issuance"), par exemple en mettant en oeuvre un mécanisme dit OTA (utilisant la voie hertzienne, en anglais "Over The Ait"), qui consiste à charger l'applet par envoi à la carte d'un message du type message court (SMS, en anglais "Short Message Service") généralement crypté et soumis à authentification, pour des raisons de sécurité. Un besoin est donc apparu de prévoir un mécanisme qui permette, dans un tel contexte, d'interdire le fonctionnement d'un applet sur au moins un compte d'une carte multi-compte. A la connaissance de la demanderesse, un tel mécanisme n'existe pas à l'heure actuelle. La présente invention a pour but de remédier à cet inconvénient. Dans ce but, l'invention propose une carte à microcircuit comportant une pluralité de comptes, une unité pour basculer d'un compte à un autre, une unité pour exécuter une application impliquant une intervention sur un compte et une unité de mémorisation, caractérisée en ce que : - l'unité de mémorisation est adaptée à mémoriser des informations de droits d'exécution de l'application précitée sur un ou plusieurs comptes, la carte à microcircuit comporte en outre une unité pour interdire, en fonction des informations de droits d'exécution, l'exécution de l'application précitée sur un ou plusieurs comptes spécifiques choisis parmi la pluralité de comptes, l'exécution de l'application sur les autres comptes restant autorisée. Ainsi, l'invention permet de restreindre l'utilisation d'une fonctionnalité, réalisée par une application, à un ou plusieurs comptes choisis parmi l'ensemble des comptes de la carte, sans empêcher que cette fonctionnalité soit offerte à l'utilisateur des autres comptes. Cela permet corrélativement de développer une application indépendamment de ses futurs droits d'exécution, lesquels ne seront pris en compte qu'au moment du chargement de l'application dans la carte. De même, l'unité d'interdiction peut être mise en œuvre quel que soit le mode de déclenchement de l'exécution de l'application. L'invention apporte en cela une avancée significative, sachant qu'actuellement, il existe un très grand nombre de modes de déclenchement possibles d'une application - par exemple, pour une carte d'abonnement à un opérateur de télécommunications mobiles comportant une plateforme JavaCard, on connaît près de 80 façons de déclencher une appliquette contenue dans la carte. Si on se bornait à adapter le menu correspondant à chaque compte, l'appliquette pourrait être lancée par un autre moyen, tel que la réception d'un message court (SMS) par le téléphone mobile. Avantageusement, la carte à microcircuit comporte en outre une unité pour recevoir de l'extérieur, de façon sécurisée, les informations de droits d'exécution mentionnées ci-dessus. Ainsi, l'émetteur de la carte peut donner accès en toute sécurité à des fonctionnalités différentes compte par compte. Avantageusement, l'unité de mémorisation est adaptée à mémoriser une table de correspondance entre une pluralité d'applications, susceptibles d'être exécutées sur un compte de la pluralité de comptes, et des comptes de la pluralité de comptes, sur lesquels l'exécution d'une application est autorisée ou interdite. L'unité d'interdiction coopère avec cette table de correspondance, pour vérifier, à réception d'une commande impliquant le lancement de l'exécution d'une application, que l'exécution de cette application sur le compte en cours d'utilisation est autorisée. Cette caractéristique est particulièrement simple à mettre en œuvre. Dans un mode particulier de réalisation, l'application est une appliquette. Le contexte JavaCard est un domaine d'application privilégié, mais non exclusif, de l'invention. Dans ce contexte, l'application considérée est un applet Java. Dans ce cas, l'expression "exécution de l'applet" désigne, par abus de langage, l'exécution d'une ou plusieurs méthodes de cet applet. Avantageusement, l'unité de mémorisation contient un ou plusieurs composants du "CAP file" ou fichier d'exécution de l'appliquette et ces composants contiennent les informations de droits d'exécution. Cette caractéristique est simple à mettre en œuvre et est en outre compatible avec la forme normalisée du "CAP file". Dans un exemple particulier d'application de l'invention, la carte à microcircuit considérée consiste en une carte d'abonnement à un opérateur de télécommunications mobiles. Il s'agit de l'application immédiate de l'invention, puisqu'il existe des cartes multi-compte dans ce domaine. Dans cet exemple, l'unité d'interdiction comporte avantageusement des menus d'affichage sur l'écran d'un téléphone mobile coopérant avec la carte qui diffèrent selon les comptes. Comme indiqué plus haut, cette caractéristique, combinée avec les autres caractéristiques de la carte à microcircuit conforme à l'invention, et en particulier son unité d'interdiction, permet d'interdire l'exécution d'une application indépendamment du mode de déclenchement de l'application. II est ainsi fort aisé d'autoriser ou non l'utilisateur à faire exécuter une application donnée sur le compte qu'il est en train d'utiliser, en lui donnant ou non le choix, selon le menu disponible, de lancer cette application par sélection d'un élément du menu. Dans le même but que celui indiqué plus haut, l'invention propose également un procédé de communication entre une carte à microcircuit telle que décrite succinctement ci-dessus et au moins une entité extérieure, remarquable en ce qu'il comporte une étape de configuration de la carte, consistant, pour l'entité extérieure, à transmettre de façon sécurisée à la carte les informations de droits d'exécution de l'application. Les avantages du procédé de communication sont similaires à ceux de la carte à microcircuit et ne sont donc pas répétés ici. Dans un mode particulier de réalisation, l'étape de configuration est intégrée à une étape d'installation définie par la norme d'infrastructure de cartes à microcircuit Global Platform, par ajout d'un champ optionnel dans la commande d'installation. Cette caractéristique est simple à mettre en œuvre et est de plus compatible avec les normes actuelles, qu'il est très aisé d'adapter. Dans un mode de réalisation où l'application est une appliquette, l'étape de configuration peut consister à transmettre à la carte un ou plusieurs composants du "CAP file" ou fichier d'exécution de l'appliquette ; ces composants contiennent dans ce cas les informations de droits d'exécution. Dans un mode particulier de réalisation, l'appliquette comporte des instructions pour enregistrer dans la carte des droits d'exécution contenus dans les informations de droits d'exécution. Ces instructions sont avantageusement contenues dans le constructeur de l'appliquette. Lorsque la carte à microcircuit comporte en mémoire, comme décrit brièvement plus haut, une table de correspondance entre des applications et des comptes, l'étape d'installation du procédé de communication conforme à l'invention peut comporter en outre une étape de création ou de mise à jour de cette table de correspondance. Dans un mode particulier de réalisation, le procédé de communication comporte en outre une étape de chargement de l'application dans la carte. Il est particulièrement commode de définir les droits d'exécution lors du chargement d'une application, au début de la vie d'une carte (en phase de personnalisation ou de pré-personnalisation) ou au cours de la vie de la carte (c'est-à-dire après livraison de celle-ci, i.e. en "post-issuance"). Dans le même but que celui indiqué plus haut, l'invention propose en outre une appliquette adaptée à s'exécuter sur un compte d'une carte à microcircuit telle que succinctement décrite ci-dessus, cette appliquette étant remarquable en ce qu'elle comporte des instructions pour enregistrer dans la carte des droits d'exécution contenus dans les informations de droits d'exécution. Ces instructions sont avantageusement contenues dans le constructeur de l'appliquette. Toujours dans le même but, l'invention propose aussi un fichier d'exécution d'une appliquette ou "CAP file", cette appliquette étant adaptée à s'exécuter sur un ou plusieurs comptes d'une carte à microcircuit telle que succinctement décrite ci-dessus, ce fichier étant remarquable en ce qu'il comporte un ou plusieurs composants contenant les informations de droits d'exécution de l'appliquette. Les avantages de l'appliquette et du "CAP file" sont similaires à ceux de la carte à microcircuit et du procédé de communication conformes à l'invention et ne sont donc pas rappelés ici. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit de modes particuliers de réalisation, donnés à titre d'exemples non limitatifs. La description est faite en référence aux dessins qui l'accompagnent, dans lesquels : la figure 1 représente de façon schématique une carte à microcircuit conforme à l'invention, dans un premier mode particulier de réalisation ; - les figures 2A et 2B représentent des exemples de réalisation d'une table de correspondance entre applications et comptes, conformément à la présente invention ; la figure 3 représente schématiquement un "CAP file" ou fichier d'exécution d'une appliquette avec des composants conformes à la présente invention, dans un mode particulier de réalisation ; la figure 4 illustre schématiquement une étape de configuration d'une carte à microcircuit et une étape de chargement d'une application dans la carte, ces étapes faisant partie d'un procédé de communication conforme à l'invention entre la carte et une entité extérieure ; et la figure 5 illustre schématiquement une commande d'installation conforme à l'invention, adaptée à partir de la norme GlobalPIatform, norme d'infrastructure de cartes à microcircuit. Dans un premier mode particulier de réalisation de l'invention, illustré sur la figure 1, une carte à microcircuit 10 conforme à la présente invention comporte une unité centrale de traitement CU 12, auxquelles sont associées de façon classique une mémoire RAM 13, une mémoire EEPROM 15, une mémoire ROM 17 et un port d'entrées/sorties 18. La mémoire EEPROM 15 est adaptée à mémoriser, sous diverses formes dont deux en particulier sont décrites plus en détail ci-après, des informations qui représentent des droits d'exécution d'une ou plusieurs applications sur un ou plusieurs des comptes de la carte, c'est-à-dire des informations qui indiquent si l'exécution d'une application sur un compte donné de la carte est autorisée ou non. La carte à microcircuit 10 conforme à l'invention comporte en outre une unité d'interdiction, adaptée à interdire, en fonction des informations précitées de droits d'exécution, l'exécution de l'application sur un ou plusieurs comptes spécifiques choisis parmi l'ensemble des comptes de la carte, l'exécution de cette application restant autorisée sur les autres comptes. Comme on le verra par la suite, cette unité d'interdiction peut être constituée, soit par un ensemble composé d'un répartiteur 26 et d'une table de correspondance 16, soit par un ensemble composé d'une machine virtuelle 19 et d'un "CAP file" 24. Dans le mode de réalisation de la figure 1 , l'unité d'interdiction 12, 14 de la carte à microcircuit 10 comporte une table de correspondance T (désignée par le chiffre de référence 16 sur le dessin) entre les applets et les comptes autorisés ou interdits. La table de correspondance 16 peut être réalisée de diverses façons. On donne ci-dessous à titre nullement limitatif, en liaison avec les figures 2A et 2B, des exemples d'implantation de cette table. Enfin, la carte à microcircuit 10 conforme à la présente invention est adaptée à communiquer avec une entité extérieure 22, par l'intermédiaire d'un réseau 20. Comme le montre la figure 2A, on peut définir pour chaque compte une liste d'applets autorisés à s'exécuter sur ce compte. Ces informations de droits d'exécution sont par exemple mémorisées dans la table 16 sous forme d'un fichier, par exemple un fichier linéaire (c'est-à-dire où un accès direct aux enregistrements est possible, par opposition à un fichier transparent, accessible bit à bit) EFAPPLET_X, où X désigne le compte concerné. La figure 2A montre que la table 16 mémorise, pour chaque champ du fichier : - la taille du champ (en nombre d'octets, représentée arbitrairement dans la colonne de gauche sur le dessin), - le contenu du champ (représenté arbitrairement dans la colonne du milieu) et - la longueur du champ (en bits, représentée arbitrairement dans la colonne de droite). Dans la variante illustrée sur la figure 2B, on définit, pour chaque applet, la liste des comptes sur lesquels l'exécution de cet applet est autorisée. La table de correspondance 16 mémorise ces informations des droits d'exécution par exemple sous la forme d'un fichier linéaire EFAPPLET définissant dans chaque enregistrement l'identifiant de l'applet ainsi que la liste des abonnements autorisés à y accéder. De même que dans l'exemple de la figure 2A, la table 16 mémorise, pour chaque champ du fichier, sa taille (en octets), son contenu et sa longueur (en bits). Les fichiers EFAPPLET_X et EFAPPLET peuvent tout aussi bien définir, soit les applets autorisés pour chaque compte et les comptes autorisés pour chaque applet, respectivement, soit les applets et les comptes interdits, respectivement. Dans les exemples des figures 2A et 2B, les fichiers linéaires variables (EFAPPLET_X et EFAPPLET) sont mémorisés dans la carte en mémoire non volatile, par exemple dans l'EEPROM ou dans une mémoire Flash. Leur mise à jour peut être effectuée à divers stades, tels que lors du chargement de l'applet dans la carte ou encore lors de la création d'un compte dans la carte, que ce soit au moment de la phase de pré-personnalisation de la carte, au moment de la personnalisation de la carte, ou après livraison de celle-ci (c'est-à-dire en "post- issuance"). Ces réalisations impliquent une adaptation du système d'exploitation de la carte. La table de correspondance coopère en effet avec le répartiteur D (désigné par le chiffre de référence 26 sur la figure 1) de la carte à microcircuit. Pour mémoire, le répartiteur (en anglais "dispatcher") est défini par la norme GSM 11.14 et ses évolutions. C'est le programme du système d'exploitation réalisant l'interprétation des commandes et le lancement de l'exécution des programmes résultant de cette interprétation. En particulier, les programmes dont l'exécution est lancée peuvent être des applets. Le répartiteur 26 selon l'invention est adapté à vérifier, avant de lancer l'exécution d'un applet, lorsqu'il reçoit une commande qu'il interprète comme nécessitant le lancement de l'exécution d'un applet, que l'exécution de cet applet est bien autorisée sur le compte en cours d'utilisation. Pour cela, le répartiteur 26 lit le fichier EFAPPLET_X OU EFAPPLET- Dans un deuxième mode particulier de réalisation de l'invention, on peut choisir de permettre le blocage de l'exécution d'un applet en ajoutant à cet effet un ou plusieurs composants dans le fichier d'exécution de l'applet, appelé aussi le "CAP file". Les informations de droits d'exécution sont alors contenues dans ce ou ces composants du "CAP file". Le "CAP file" est mémorisé en EEPROM dans la carte à microcircuit (il est désigné par le chiffre de référence 24 sur la figure 1). Dans ce cas, la carte comporte une machine virtuelle JavaCard adaptée à interpréter ce ou ces composants du "CAP file" ; dans un tel cas, la machine virtuelle et le "CAP file" constituent l'unité d'interdiction 19, 24. Ils possèdent des indications sur les droits d'exécution de l'applet vis-à-vis du compte en cours d'utilisation. En fonction de ces indications, la machine virtuelle pourra autoriser ou interdire l'exécution de l'applet sur ce compte. Pour mémoire, un applet est mémorisé dans une carte à microcircuit, par exemple en mémoire EEPROM ou ROM, sous la forme d'un fichier appelé "CAP file". Ce fichier d'exécution de l'applet est issu de la compilation des fichiers JavaCard. Pour exécuter l'applet, la carte comporte une machine virtuelle qui lit le "CAP file". Comme le montre la figure 3, le "CAP file" 30 est composé d'un certain nombre d'enregistrements R1 , R2, ... , Rn ou composants, appelés aussi TLV, où T désigne le type d'enregistrement ou identifiant (en anglais "Tag"), L désigne la longueur de l'enregistrement (en anglais "Length") et V désigne le contenu ou valeur de l'enregistrement (en anglais "Value"). La présence de l'identifiant permet de distinguer les différents types de composants : importation des applications, identification de l'application, code proprement dit, etc. Un de ces composants est le code de l'applet ou "byte code". Le "CAP file" contient ainsi l'ensemble de l'applet ainsi que les paramètres nécessaires pour son installation et son fonctionnement. La figure 3 montre également la définition typique d'un composant du "CAP file" : co ponent { ul tag u2 size u3 info[] } A la lecture du "CAP file", la machine virtuelle, lorsqu'elle rencontre un composant dont l'identifiant a une valeur prédéterminée, va lire l'attribut "info" pour déterminer sur quel compte l'applet peut s'exécuter. L'attribut "info" peut par exemple comporter la liste des droits d'exécution de l'applet. La spécification JavaCard autorise l'ajout de composants dans le "CAP file", moyennant une taille de 128 à 255 bits pour l'identifiant. Dans un exemple particulier de réalisation où la carte à microcircuit 10 est une carte SIM d'abonnement à un opérateur de réseau de télécommunications, si la carte comporte un nombre de comptes N1 , l'unité d'interdiction 12, 14 est par exemple constituée par N2 menus différents s'affichant sur l'écran du téléphone mobile de l'utilisateur. D'une part, chacun des N2 menus est associé à un ou plusieurs des N1 comptes et d'autre part, à chacun des N1 comptes sont associés un ou plusieurs des N2 menus. Lors de l'utilisation d'un compte donné, seul les menus associés sont accessibles à l'utilisateur. Dans un téléphone mobile comportant une carte à microcircuit incluant une plateforme JavaCard, la sélection d'un élément dans un menu sur l'écran du téléphone peut entraîner l'exécution d'un applet correspondant à cet élément dans la carte SIM. Dans l'état de la technique, la carte à microcircuit se borne à mémoriser l'ensemble des menus affichés, tandis que conformément à la présente invention, la carte à microcircuit mémorise des menus différents selon les comptes utilisés et sélectionne pour affichage ceux qui sont associés au compte en cours d'utilisation. Par conséquent, lorsque l'utilisateur utilise un compte donné, il ne voit pas apparaître dans les menus associés les choix correspondant aux applets ne pouvant être exécutés sur ce compte. La figure 4 illustre schématiquement une étape de configuration d'une carte à microcircuit, cette étape faisant partie d'un procédé de communication conforme à l'invention entre la carte 10 et une entité extérieure 22, qui peut par exemple être un opérateur de télécommunications. Lors de cette étape de configuration (plus particulièrement matérialisée sur le dessin par la flèche "droits"), l'entité extérieure 22 transmet de façon sécurisée à la carte les informations de droits d'exécution de l'application. L'unité d'entrée/sortie 18 de la carte 10 (voir figure 1), combinée à des moyens de réception d'un terminal de téléphonie mobile ou tout autre type de terminal (non représenté sur les dessins), permet à cette dernière de recevoir les informations de droits d'exécution de l'extérieur. Ces informations de droits d'exécution peuvent comporter des identifiants de comptes de la carte sur lesquels l'exécution d'une application est autorisée ou interdite. L'identifiant d'un compte peut être communiqué de façon directe à la carte. Dans l'exemple mentionné plus haut d'un compte PRO/PERSO d'un opérateur de télécommunications mobiles, cet identifiant peut être l'IMSI de l'un des deux abonnements (personnel ou professionnel). L'identifiant d'un compte peut aussi être communiqué de façon indirecte. Par exemple, l'entité extérieure 22 peut communiquer à la carte 10 un identifiant précisant que c'est sur le compte professionnel que l'exécution de l'application est interdite, sans connaître l'IMSI, en utilisant simplement l'identifiant du compte professionnel. La carte est alors capable de retrouver l'IMSI concerné. En variante, la carte peut communiquer avec non pas une, mais plusieurs entités extérieures, qui transmettront alors chacune de façon sécurisée les informations de droits d'exécution d'une ou plusieurs applications vis-à-vis des comptes de la carte. Dans un mode particulier de réalisation, l'étape de configuration de la carte décrite ci-dessus est intégrée à l'étape d'installation telle que définie dans la norme GlobalPIatform. Pour cela, un champ supplémentaire optionnel est ajouté dans la commande d'installation. Lorsque l'application est un applet, lors de l'étape de configuration, l'entité extérieure 22 transmet à la carte 10 un ou plusieurs composants du "CAP file", qui contiennent les informations de droits d'exécution de l'applet sur les comptes de la carte. De préférence, l'applet comporte dans son constructeur des instructions pour enregistrer dans la carte ses propres droits d'exécution. La table de correspondance est créée, si elle n'existe pas encore, ou mise à jour, si elle a déjà été créée, au cours de l'étape d'installation. Dans le mode particulier de réalisation de la figure 4, le procédé de communication selon l'invention comporte, outre l'étape de configuration de la carte, une étape de chargement de l'application dans la carte (plus particulièrement illustrée par la flèche "chargement'). Il peut être utile de modifier les droits d'exécution d'un applet indépendamment du chargement de cet applet. Un opérateur d'un réseau de télécommunications mobiles peut autoriser l'exécution d'un applet sur un compte sur lequel elle était précédemment interdite, par exemple à la suite de la mise en place d'un nouveau service sur ce compte. Pour cela, l'opérateur peut par exemple mettre à jour à distance le fichier EFAPPLET_X OU EFAPPLET décrit plus haut, par l'envoi d'un SMS sécurisé (c'est-à- dire typiquement crypté et authentifié, par des méthodes connues de l'homme du métier) à la carte, comme illustré sur la figure 4. Ce SMS comporte notamment la clé d'accès au fichier EFAPPLET_X OU EFAPPLET et déclenche l'exécution d'une commande de mise à jour (par exemple : "Update Record") dans la carte. Comme le montre la figure 5, lorsque l'étape de configuration de la carte est intégrée à l'étape d'installation définie par la norme GlobalPIatform et que la commande d'installation (INSTALL(INSTALL)) telle que définie par cette norme contient un champ supplémentaire optionnel, le contenu et la longueur de ce champ se présentent sous la forme illustrée en grisé sur le dessin. Ainsi, dans l'exemple de réalisation illustré ici, le champ optionnel "Liste abonnés" (accompagné d'un paramètre "O" désignant ce caractère optionnel, figurant arbitrairement dans la colonne de gauche sur le dessin) comprend la liste des identifiants des comptes de la carte sur lesquels l'exécution de l'applet est autorisée ou interdite. Cette commande d'installation est reçue par exemple sous la forme d'une commande APDU. Le champ optionnel "Liste abonnés" est interprété par le gestionnaire d'application (constitué par du code stocké en ROM, faisant partie du système d'exploitation de la carte), qui met alors à jour toutes les informations nécessaires dans la carte, notamment la table de correspondance 16. Tous les champs autres que les champs optionnels illustrés sur la figure 5 sont connus de l'homme du métier et définis dans la norme GlobalPIatform. En variante, on peut inclure dans l'applet un programme d'enregistrement des droits d'exécution de l'applet sur la carte. De préférence, ce programme est dans le constructeur de l'applet, et par conséquent, dans le code de l'applet. Cette variante présente l'avantage que le programme du constructeur est systématiquement lancé à chaque installation de l'applet. La mise à jour de l'enregistrement des droits d'exécution est ainsi garantie, par exemple, sous la forme d'une mise à jour de la table de correspondance 16 dans sa variante illustrée sur la figure 5. Dans une autre variante, dans laquelle on choisit d'ajouter un composant dans le "CAP file", on peut utiliser des logiciels connus, tels que l'outil Converter de Sun Microsystems, pour réaliser la conversion d'un fichier objet, généralement appelé "fichier .class", en un fichier "CAP", généralement appeléProgrammable Read Only Memory ") during the final stages of card manufacturing, for example during pre-personalization or personalization, or even after delivery of the card (ie" post-issuance " ), for example by implementing a so-called OTA mechanism (using the radio channel, in English "Over The Ait"), which consists of loading the applet by sending a short message type message (SMS, in English "Short Message Service") generally encrypted and subject to authentication, for security reasons. A need has therefore appeared to provide a mechanism which makes it possible, in such a context, to prohibit the operation of an applet on at least a multi-account card account. To the knowledge of the applicant, such a mechanism does not currently exist. The object of the present invention is to remedy this drawback. To this end, the invention provides a microcircuit card comprising a plurality of accounts, a unit for switching from one account to another, a unit for executing an application involving intervention on an account and a storage unit, characterized in that: - the storage unit is adapted to store information on the execution rights of the aforementioned application on one or more accounts, the microcircuit card further comprises a unit for prohibiting, as a function of the rights information d execution, the execution of the aforementioned application on one or more specific accounts chosen from the plurality of accounts, the execution of the application on the other accounts remaining authorized. Thus, the invention makes it possible to restrict the use of a functionality, carried out by an application, to one or more accounts chosen from all of the accounts on the card, without preventing this functionality from being offered to the user of others. accounts. This correlatively makes it possible to develop an application independently of its future execution rights, which will only be taken into account when the application is loaded into the card. Similarly, the prohibition unit can be implemented regardless of the mode of triggering of the execution of the application. The invention brings in this a significant advance, knowing that currently, there are a very large number of possible modes of triggering an application - for example, for a subscription card to a mobile telecommunications operator comprising a JavaCard platform. , we know about 80 ways to trigger an applet contained in the card. If we limited ourselves to adapting the menu corresponding to each account, the app could be launched by another means, such as the reception of a short message (SMS) by the mobile phone. Advantageously, the microcircuit card further comprises a unit for receiving from the outside, in a secure manner, the performance rights information mentioned above. Thus, the card issuer can give secure access to different functionalities account by account. Advantageously, the storage unit is adapted to store a correspondence table between a plurality of applications, capable of being executed on an account of the plurality of accounts, and accounts of the plurality of accounts, on which the execution of an application is allowed or prohibited. The prohibition unit cooperates with this correspondence table, to verify, upon receipt of an order involving the launching of the execution of an application, that the execution of this application on the account in use is authorized. This feature is particularly simple to implement. In a particular embodiment, the application is an applet. The JavaCard context is a preferred, but not exclusive, field of application of the invention. In this context, the application considered is a Java applet. In this case, the expression "execution of the applet" designates, by abuse of language, the execution of one or more methods of this applet. Advantageously, the storage unit contains one or more components of the "CAP file" or execution file of the applet and these components contain the information on execution rights. This feature is simple to implement and is also compatible with the standardized form of the "CAP file". In a particular example of application of the invention, the microcircuit card considered consists of a subscription card to a mobile telecommunications operator. This is the immediate application of the invention, since there are multi-account cards in this area. In this example, the prohibition unit advantageously comprises display menus on the screen of a mobile telephone cooperating with the card which differ according to the accounts. As indicated above, this characteristic, combined with the other characteristics of the microcircuit card according to the invention, and in particular its prohibition unit, makes it possible to prohibit the execution of an application regardless of the triggering mode of the application. It is thus very easy to authorize or not the user to execute a given application on the account he is using, by giving him or not the choice, depending on the available menu, of launching this application by selection of a menu item. For the same purpose as that indicated above, the invention also provides a method of communication between a microcircuit card as briefly described above and at least one external entity, remarkable in that it comprises a configuration step of the card, consisting, for the external entity, in transmitting securely to the card the information of execution rights of the application. The advantages of the communication method are similar to those of the microcircuit card and are therefore not repeated here. In a particular embodiment, the configuration step is integrated into an installation step defined by the standard for microcircuit card infrastructure Global Platform, by adding an optional field in the installation command. This feature is simple to implement and is moreover compatible with current standards, which it is very easy to adapt. In an embodiment where the application is an applet, the configuration step can consist in transmitting to the card one or more components of the "CAP file" or execution file of the applet; these components in this case contain the performance rights information. In a particular embodiment, the applet includes instructions for recording performance rights contained in the performance rights information in the card. These instructions are advantageously contained in the manufacturer of the applet. When the microcircuit card has in memory, as described briefly above, a correspondence table between applications and accounts, the step of installing the communication method according to the invention may also include a step of creating or to update this correspondence table. In a particular embodiment, the communication method further comprises a step of loading the application into the card. It is particularly convenient to define the execution rights when loading an application, at the beginning of the life of a card (during the personalization or pre-personalization) or during the life of the card (ie after delivery thereof, ie in "post-issuance"). For the same purpose as that indicated above, the invention further provides an applet adapted to run on an account of a microcircuit card as succinctly described above, this applet being remarkable in that it comprises instructions for recording performance rights contained in the performance rights information in the card. These instructions are advantageously contained in the manufacturer of the applet. Still for the same purpose, the invention also proposes an execution file for an applet or "CAP file", this applet being adapted to run on one or more accounts of a microcircuit card as succinctly described below. above, this file being remarkable in that it comprises one or more components containing the information of rights of execution of the applet. The advantages of the appliquette and the "CAP file" are similar to those of the microcircuit card and of the communication method according to the invention and are therefore not repeated here. Other aspects and advantages of the invention will appear on reading the detailed description which follows of particular embodiments, given by way of nonlimiting examples. The description is made with reference to the accompanying drawings, in which: FIG. 1 schematically represents a microcircuit card according to the invention, in a first particular embodiment; - Figures 2A and 2B show exemplary embodiments of a correspondence table between applications and accounts, in accordance with the present invention; FIG. 3 schematically represents a "CAP file" or execution file of an applet with components in accordance with the present invention, in a particular embodiment; FIG. 4 schematically illustrates a step of configuring a microcircuit card and a step of loading an application into the card, these steps being part of a communication method according to the invention between the card and an external entity; and FIG. 5 diagrammatically illustrates an installation command in accordance with the invention, adapted from the GlobalPIatform standard, infrastructure standard for microcircuit cards. In a first particular embodiment of the invention, illustrated in FIG. 1, a microcircuit card 10 in accordance with the present invention comprises a central processing unit CU 12, with which are conventionally associated a RAM memory 13, a memory EEPROM 15, a ROM memory 17 and an input / output port 18. The EEPROM memory 15 is suitable for storing, in various forms, two of which in particular are described in more detail below, information which represents rights of execution of one or more applications on one or more of the card accounts, that is to say information which indicates whether the execution of an application on a given account of the card is authorized or not. The microcircuit card 10 according to the invention further comprises a prohibition unit, adapted to prohibit, as a function of the aforementioned information of execution rights, the execution of the application on one or more specific accounts chosen from among 'all card accounts, the execution of this application remaining authorized on other accounts. As will be seen below, this prohibition unit can be constituted either by an assembly composed of a distributor 26 and a correspondence table 16, or by an assembly composed of a virtual machine 19 and of a "CAP file" 24. In the embodiment of FIG. 1, the prohibition unit 12, 14 of the microcircuit card 10 comprises a correspondence table T (designated by the reference number 16 in the drawing) between applets and authorized or prohibited accounts. The correspondence table 16 can be produced in various ways. Examples of the layout of this table are given below in no way limiting, in connection with FIGS. 2A and 2B. Finally, the microcircuit card 10 according to the present invention is adapted to communicate with an external entity 22, via a network 20. As shown in FIG. 2A, a list of applets can be defined for each account allowed to run on this account. This execution rights information is for example stored in table 16 in the form of a file, for example a linear file (that is to say where direct access to the records is possible, as opposed to a transparent file , accessible bit by bit) EF A PPLET_X, where X is the account concerned. FIG. 2A shows that table 16 stores, for each field of the file: - the size of the field (in number of bytes, represented arbitrarily in the left column in the drawing), - the content of the field (represented arbitrarily in the middle column) and - the length of the field (in bits, represented arbitrarily in the right column). In the variant illustrated in FIG. 2B, the list of accounts on which the execution of this applet is authorized is defined for each applet. The correspondence table 16 stores this information on execution rights for example in the form of a linear file EFAPPLET defining in each record the identifier of the applet as well as the list of subscriptions authorized to access it. As in the example of FIG. 2A, the table 16 stores, for each field of the file, its size (in bytes), its content and its length (in bits). The EFAPPLET_X and EFAPPLET files can just as easily define either the applets authorized for each account and the accounts authorized for each applet, respectively, or the applets and accounts prohibited, respectively. In the examples of FIGS. 2A and 2B, the variable linear files (EF A PPLET_X and EFAPPLET) are stored in the card in non-volatile memory, for example in the EEPROM or in a Flash memory. They can be updated at various stages, such as when the applet is loaded into the card or when an account is created in the card, either during the pre-personalization phase of the card, at the time of personalization of the card, or after delivery thereof (that is to say in "post-issuance"). These achievements imply an adaptation of the card's operating system. The correspondence table in fact cooperates with the distributor D (designated by the reference numeral 26 in FIG. 1) of the microcircuit card. For the record, the dispatcher is defined by the GSM 11.14 standard and its evolutions. It is the operating system program interpreting commands and launching the execution of programs resulting from this interpretation. In particular, the programs whose execution is launched can be applets. The dispatcher 26 according to the invention is adapted to verify, before launching the execution of an applet, when it receives a command which it interprets as requiring the launching of the execution of an applet, that the execution of this applet is allowed on the account in use. For this, the dispatcher 26 reads the file EFAPPLET_X OR EFAPPLET- In a second particular embodiment of the invention, one can choose to allow the blocking of the execution of an applet by adding for this purpose one or more components in the applet execution file, also called the "CAP file". The performance rights information is then contained in this or these components of the "CAP file". The "CAP file" is stored in EEPROM in the microcircuit card (it is designated by the reference number 24 in FIG. 1). In this case, the card includes a JavaCard virtual machine adapted to interpret this or these components of the "CAP file"; in such a case, the virtual machine and the "CAP file" constitute the prohibition unit 19, 24. They have information on the execution rights of the applet vis-à-vis the account being use. Based on these indications, the virtual machine can authorize or prohibit the execution of the applet on this account. For the record, an applet is stored in a microcircuit card, for example in EEPROM or ROM memory, in the form of a file called "CAP file". This applet execution file comes from the compilation of JavaCard files. To run the applet, the card includes a virtual machine which reads the "CAP file". As shown in FIG. 3, the "CAP file" 30 is composed of a certain number of records R1, R2, ..., Rn or components, also called TLV, where T designates the type of record or identifier ( in English "Tag"), L indicates the length of the record (in English "Length") and V indicates the content or value of the record (in English "Value"). The presence of the identifier makes it possible to distinguish the different types of components: import of applications, identification of the application, code itself, etc. One of these components is the applet code or "byte code". The "CAP file" thus contains the entire applet as well as the parameters necessary for its installation and operation. Figure 3 also shows the typical definition of a component of the "CAP file": co ponent {ul tag u2 size u3 info []} When reading the "CAP file", the virtual machine, when it encounters a component whose the identifier has a predetermined value, will read the "info" attribute to determine on which account the applet can run. The "info" attribute can for example include the list of execution rights of the applet. The JavaCard specification allows the addition of components in the "CAP file", with a size of 128 to 255 bits for the identifier. In a particular embodiment where the microcircuit card 10 is a SIM card for subscription to a telecommunications network operator, if the card has a number of accounts N1, the prohibition unit 12, 14 is for example constituted by N2 different menus displayed on the screen of the user's mobile phone. On the one hand, each of the N2 menus is associated with one or more of the N1 accounts and on the other hand, with each of the N1 accounts are associated one or more of the N2 menus. When using a given account, only the associated menus are accessible to the user. In a mobile telephone comprising a microcircuit card including a JavaCard platform, the selection of an item in a menu on the screen of the phone may cause an applet corresponding to this item to be executed in the SIM card. In the state of the art, the microcircuit card is limited to memorizing all of the menus displayed, while in accordance with the present invention, the microcircuit card memorizes different menus according to the accounts used and selects for display those which are associated with the account in use. Consequently, when the user uses a given account, he does not see appear in the associated menus the choices corresponding to the applets which cannot be executed on this account. FIG. 4 schematically illustrates a step of configuring a microcircuit card, this step being part of a communication method according to the invention between the card 10 and an external entity 22, which can for example be a telecommunications operator . During this configuration step (more particularly materialized in the drawing by the arrow "rights"), the external entity 22 transmits securely to the card the information of execution rights of the application. The input / output unit 18 of the card 10 (see FIG. 1), combined with means for receiving a mobile telephone terminal or any other type of terminal (not shown in the drawings), allows the latter to receive performance rights information from the outside. This execution rights information may include identifiers of card accounts on which the execution of an application is authorized or prohibited. The account identifier can be communicated directly to the card. In the example mentioned above of a PRO / PERSO account of a mobile telecommunications operator, this identifier can be the IMSI of one of the two subscriptions (personal or professional). The identifier of an account can also be communicated indirectly. For example, the external entity 22 can communicate to the card 10 an identifier specifying that it is on the professional account that the execution of the application is prohibited, without knowing the IMSI, by simply using the account identifier professional. The card is then able to find the IMSI concerned. As a variant, the card can communicate with not one, but several external entities, which will then each transmit securely the information on the execution rights of one or more applications vis-à-vis the card accounts. In a particular embodiment, the step of configuring the card described above is integrated into the installation step as defined in the GlobalPIatform standard. For this, an optional additional field is added in the installation command. When the application is an applet, during the configuration step, the external entity 22 transmits to the card 10 one or more components of the "CAP file", which contain the execution rights information of the applet on card accounts. Preferably, the applet includes in its constructor instructions for recording in the card its own performance rights. The correspondence table is created, if it does not already exist, or updated, if it has already been created, during the installation step. In the particular embodiment of FIG. 4, the communication method according to the invention comprises, in addition to the step of configuring the card, a step of loading the application into the card (more particularly illustrated by the arrow " It may be useful to modify the execution rights of an applet independently of the loading of this applet. An operator of a mobile telecommunications network can authorize the execution of an applet on an account on which it was previously prohibited, for example following the establishment of a new service on this account. For this, the operator can for example update remotely the EF file A PPLET_X OR EFAPPLET described above, by l sending a secure SMS (that is to say typically encrypted and authenticated, by methods known to those skilled in the art) to the card, as illustrated in FIG. 4. This SMS notably includes the key access to file EF A PP LET_X OR EFAPPLET and triggers the execution of an update command (for example: "Update Record") in the card. As shown in Figure 5, when the card configuration step is integrated with the installation step defined by the GlobalPIatform standard and the installation command (INSTALL (INSTALL)) as defined by this standard contains an optional additional field, the content and length of this field appear in the form shown in gray in the drawing. Thus, in the exemplary embodiment illustrated here, the optional field "Subscriber list" (accompanied by a parameter "O" designating this optional character, arbitrarily appearing in the left column on the drawing) includes the list of account identifiers of the map on which the execution of the applet is authorized or prohibited. This installation command is received for example in the form of an APDU command. The optional field "Subscriber list" is interpreted by the application manager (consisting of code stored in ROM, part of the operating system of the card), which then updates all the information required in the card, in particular the correspondence table 16. All the fields other than the optional fields illustrated in FIG. 5 are known to those skilled in the art and defined in the GlobalPIatform standard. As a variant, it is possible to include in the applet a program for recording the execution rights of the applet on the card. Preferably, this program is in the applet constructor, and therefore in the applet code. This variant has the advantage that the manufacturer's program is systematically launched each time the applet is installed. The updating of the recording of performance rights is thus guaranteed, for example, in the form of an update of the correspondence table 16 in its variant illustrated in FIG. 5. In another variant, in which one chooses to add a component in the "CAP file", one can use known software, such as the Converter tool from Sun Microsystems, to carry out the conversion of an object file, generally called ".class file", into a CAP file, usually called
"fichier .cap", après compilation du code JavaCard. Conformément à la présente invention, on peut modifier cet outil de façon qu'il ajoute automatiquement dans le "CAP file" le composant requis décrit plus haut. A l'exception de la solution consistant à inclure dans l'applet un programme d'enregistrement des droits d'exécution de l'applet sur la carte, l'ensemble des modes particuliers de réalisation précédemment décrits présente un avantages en commun, à savoir, le fait que l'applet peut être développé indépendamment des droits d'exécution. Ces derniers dont pris en compte uniquement au moment du chargement de l'applet dans la carte. ".cap file", after compilation of the JavaCard code. In accordance with the present invention, this tool can be modified so that it automatically adds to the "CAP file" the required component described above. With the exception of the solution consisting in including in the applet a program for recording the execution rights of the applet on the card, all of the particular embodiments described above have a common advantage, namely , the fact that the applet can be developed regardless of performance rights. These are only taken into account when the applet is loaded into the map.

Claims

REVENDICATIONS
1. Carte à microcircuit (10) comportant une pluralité de comptes, des moyens pour basculer d'un compte à un autre, des moyens pour exécuter une application impliquant une intervention sur un compte et des moyens (15) de mémorisation, caractérisée en ce que : les moyens (15) de mémorisation sont adaptés à mémoriser des informations de droits d'exécution de ladite application sur un ou plusieurs comptes, - la carte à microcircuit (10) comporte en outre des moyens (16, 26 ;1. A microcircuit card (10) comprising a plurality of accounts, means for switching from one account to another, means for executing an application involving intervention on an account and means (15) for storage, characterized in that that: the storage means (15) are adapted to store information on the rights to execute said application on one or more accounts, - the microcircuit card (10) further comprises means (16, 26;
19, 24) pour interdire, en fonction desdites informations de droits d'exécution, l'exécution de ladite application sur un ou plusieurs comptes spécifiques choisis parmi ladite pluralité de comptes, l'exécution de l'application sur les autres comptes restant autorisée. 2. Carte à microcircuit (10) selon la revendication 1 , caractérisée en ce qu'elle comporte en outre des moyens (18) pour recevoir de l'extérieur, de façon sécurisée, lesdites informations de droits d'exécution. 3. Carte à microcircuit (10) selon la revendication 1 ou 2, caractérisée en ce que : - lesdits moyens (15) de mémorisation sont adaptés à mémoriser une table de correspondance (16) entre une pluralité d'applications, susceptibles d'être exécutées sur un compte de la pluralité de comptes, et des comptes de ladite pluralité de comptes, sur lesquels l'exécution d'une application est autorisée ou interdite ; lesdits moyens (16, 26 ; 19, 24) d'interdiction coopérant avec ladite table de correspondance (16), pour vérifier, à réception d'une commande impliquant le lancement de l'exécution d'une application, que l'exécution de cette application sur le compte en cours d'utilisation est autorisée. 4. Carte à microcircuit (10) selon la revendication 1 , 2 ou 3, caractérisée en ce que ladite application est une appliquette. 5. Carte à microcircuit (10) selon la revendication précédente, caractérisée en ce que les moyens de mémorisation contiennent un ou plusieurs composants du "CAP file" (30) ou fichier d'exécution de l'appliquette et en ce que lesdits composants contiennent lesdites informations de droits d'exécution. 6. Carte à microcircuit (10) selon l'une quelconque des revendications précédentes, caractérisée en ce qu'elle consiste en une carte d'abonnement à un opérateur de télécommunications mobiles. 7. Carte à microcircuit (10) selon la revendication précédente, caractérisée en ce que les moyens (16, 26 ; 19, 24) d'interdiction comportent des menus d'affichage sur l'écran d'un téléphone mobile coopérant avec la carte qui diffèrent selon les comptes. 8. Procédé de communication entre une carte à microcircuit (10) selon l'une quelconque des revendications précédentes et au moins une entité extérieure (22), caractérisé en ce qu'il comporte une étape de configuration de la carte (10), consistant, pour l'entité extérieure (22), à transmettre de façon sécurisée à la carte lesdites informations de droits d'exécution de ladite application. 9. Procédé selon la revendication précédente, caractérisé en ce que l'étape de configuration est intégrée à une étape d'installation définie par la norme d'infrastructure de cartes à microcircuit GlobalPIatform, par ajout d'un champ optionnel dans la commande d'installation. 10. Procédé selon la revendication 8 ou 9, dans lequel l'application est une appliquette, caractérisé en ce que ladite étape de configuration consiste à transmettre à la carte (10) un ou plusieurs composants du "CAP file" (30) ou fichier d'exécution de l'appliquette et en ce que lesdits composants contiennent lesdites informations de droits d'exécution. 11. Procédé selon la revendication précédente, caractérisé en ce que l'appliquette comporte des instructions pour enregistrer dans la carte (10) des droits d'exécution contenus dans lesdites informations. 12. Procédé selon la revendication précédente, caractérisé en ce que lesdites instructions sont contenues dans le constructeur de l'appliquette. 13. Procédé selon la revendication 9, pour communiquer avec une carte à microcircuit (10) selon la revendication 3, caractérisé en ce que ladite étape d'installation comporte en outre une étape de création ou de mise à jour de ladite table de correspondance (16). 19, 24) to prohibit, according to said information of execution rights, the execution of said application on one or more specific accounts chosen from said plurality of accounts, the execution of the application on other accounts remaining authorized. 2. A microcircuit card (10) according to claim 1, characterized in that it further comprises means (18) for receiving from the outside, in a secure manner, said performance rights information. 3. microcircuit card (10) according to claim 1 or 2, characterized in that: - said storage means (15) are adapted to store a correspondence table (16) between a plurality of applications, capable of being executed on an account of the plurality of accounts, and accounts of said plurality of accounts, on which the execution of an application is authorized or prohibited; said prohibition means (16, 26; 19, 24) cooperating with said correspondence table (16), to verify, upon receipt of an order involving the launching of the execution of an application, that the execution of this application on the account in use is authorized. 4. Microcircuit card (10) according to claim 1, 2 or 3, characterized in that said application is an applet. 5. Microcircuit card (10) according to the preceding claim, characterized in that the storage means contain one or more components of the "CAP file" (30) or execution file of the applet and in that said components contain said information of execution rights. 6. Microcircuit card (10) according to any one of the preceding claims, characterized in that it consists of a subscription card to a mobile telecommunications operator. 7. microcircuit card (10) according to the preceding claim, characterized in that the prohibition means (16, 26; 19, 24) comprise display menus on the screen of a mobile telephone cooperating with the card which differ by account. 8. A method of communication between a microcircuit card (10) according to any one of the preceding claims and at least one external entity (22), characterized in that it comprises a step of configuring the card (10), consisting , for the external entity (22), to transmit securely to the card said information of execution rights of said application. 9. Method according to the preceding claim, characterized in that the configuration step is integrated into an installation step defined by the standard of microcircuit card infrastructure GlobalPIatform, by adding an optional field in the command of installation. 10. The method of claim 8 or 9, wherein the application is an applet, characterized in that said configuration step consists in transmitting to the card (10) one or more components of the "CAP file" (30) or file of execution of the applet and in that said components contain said information of execution rights. 11. Method according to the preceding claim, characterized in that the applet includes instructions for recording in the card (10) performance rights contained in said information. 12. Method according to the preceding claim, characterized in that said instructions are contained in the constructor of the applet. 13. The method of claim 9, for communicating with a microcircuit card (10) according to claim 3, characterized in that said installation step further comprises a step of creating or updating said correspondence table ( 16).
14. Procédé selon Tune quelconque des revendications 8 à 13, caractérisé en ce qu'il comporte en outre une étape de chargement de ladite application dans la carte (10). 15. Appliquette adaptée à s'exécuter sur un compte d'une carte à microcircuit (10) selon l'une quelconque des revendications 1 à 7, caractérisée en ce qu'elle comporte des instructions pour enregistrer dans la carte des droits d'exécution contenus dans les informations de droits d'exécution. 16. Appliquette selon la revendication précédente, caractérisée en ce que lesdites instructions sont contenues dans le constructeur de l'appliquette. 17. Fichier d'exécution d'une appliquette ou "CAP file" (30), ladite appliquette étant adaptée à s'exécuter sur un ou plusieurs comptes d'une carte à microcircuit (10) selon l'une quelconque des revendications 1 à 7, ledit fichier étant caractérisé en ce qu'il comporte un ou plusieurs composants contenant lesdites informations de droits d'exécution de ladite appliquette. 14. Method according to any one of claims 8 to 13, characterized in that it further comprises a step of loading said application into the card (10). 15. Appliquette adapted to run on an account of a microcircuit card (10) according to any one of claims 1 to 7, characterized in that it includes instructions for recording in the card performance rights contained in the performance rights information. 16. Appliquette according to the preceding claim, characterized in that said instructions are contained in the manufacturer of the applet. 17. Execution file of an applet or "CAP file" (30), said applet being adapted to run on one or more accounts of a microcircuit card (10) according to any one of claims 1 to 7, said file being characterized in that it comprises one or more components containing said information on the performance rights of said applet.
PCT/FR2004/003254 2003-12-17 2004-12-16 Microcircuit multi-account card for restricting an account operation and corresponding communication method WO2005059847A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0314805 2003-12-17
FR0314805A FR2864294B1 (en) 2003-12-17 2003-12-17 MULTI-COUNTER MICROCIRCUIT BOARD FOR RESTRICTING FUNCTIONALITY TO ACCOUNT AND CORRESPONDING COMMUNICATION METHOD

Publications (1)

Publication Number Publication Date
WO2005059847A1 true WO2005059847A1 (en) 2005-06-30

Family

ID=34630248

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2004/003254 WO2005059847A1 (en) 2003-12-17 2004-12-16 Microcircuit multi-account card for restricting an account operation and corresponding communication method

Country Status (2)

Country Link
FR (1) FR2864294B1 (en)
WO (1) WO2005059847A1 (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998009257A1 (en) * 1996-08-30 1998-03-05 Gemplus S.C.A. A system and method for loading applications onto a smart card
WO2000067212A1 (en) * 1999-04-29 2000-11-09 Schlumberger Systemes Method for controlling commands in several application files and chip card for carrying out said method
US6216014B1 (en) * 1996-05-17 2001-04-10 Gemplus Communication system for managing safely and independently a plurality of applications by each user card and corresponding user card and management method
WO2001084512A1 (en) * 2000-04-28 2001-11-08 Gemplus Multiple application smart card
WO2002076126A2 (en) * 2001-03-16 2002-09-26 Schlumberger Systèmes Subscriber identity module for managing a plurality of commands of at least one applet

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6216014B1 (en) * 1996-05-17 2001-04-10 Gemplus Communication system for managing safely and independently a plurality of applications by each user card and corresponding user card and management method
WO1998009257A1 (en) * 1996-08-30 1998-03-05 Gemplus S.C.A. A system and method for loading applications onto a smart card
WO2000067212A1 (en) * 1999-04-29 2000-11-09 Schlumberger Systemes Method for controlling commands in several application files and chip card for carrying out said method
WO2001084512A1 (en) * 2000-04-28 2001-11-08 Gemplus Multiple application smart card
WO2002076126A2 (en) * 2001-03-16 2002-09-26 Schlumberger Systèmes Subscriber identity module for managing a plurality of commands of at least one applet

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"globalplatform Card Specification Version 2.1.1", March 2003, GOLBALPLATFORM INC., XP002290114 *

Also Published As

Publication number Publication date
FR2864294A1 (en) 2005-06-24
FR2864294B1 (en) 2006-03-24

Similar Documents

Publication Publication Date Title
EP0906603B1 (en) Communication system for managing safely and independently a plurality of applications by each user card and corresponding user card and management method
EP2008483B1 (en) Method of securing access to a proximity communication module in a mobile terminal
CA2309293A1 (en) Method, card and terminals for carrying out transactions in a telecommunication network
FR2821231A1 (en) METHOD FOR ADMINISTERING A SUBSCRIBER CARD FOR MOBILE TELEPHONY EQUIPMENT OF THE TYPE WITH AUXILIARY READER AND ON-BOARD SYSTEM FOR IMPLEMENTING THE PROCESS
WO2010115840A1 (en) Method for personalizing an electronic device, associated data processing method and device
EP1395962A1 (en) Application deployment form a smart card
WO2002005511A1 (en) Security module
WO2002042912A1 (en) Executing an application in a portable electronic object with low storage capacity
EP1388134A1 (en) Method and system for managing data designed to be stored in a programmable smart card
EP2912640B1 (en) Method for managing identifiers in a smart card and smart card
WO2007071832A1 (en) Use of proprietary information transmitted by a radio communication network to a mobile termianl under the control of a smart card
WO2005059847A1 (en) Microcircuit multi-account card for restricting an account operation and corresponding communication method
EP1142193A1 (en) Method for secure data loading between two security modules
WO2007080328A2 (en) Method for generating a profile for the personalisation of an electronic entity and associated system
EP1538857B1 (en) Method for backing up mobile telephone data
EP1578064B1 (en) Method to access a service via a terminal connected to a communication network
EP1413158B1 (en) Method of accessing a specific service offered by a virtual operator and the chip card for a corresponding device
EP0974131B1 (en) Dynamic data interpretation method for a chip card
EP3648491B1 (en) Multi-configuration secure element and associated method
EP2284751B1 (en) Method for traceability and accountability of dynamic exchange in an internet environment
WO2002008897A1 (en) Protocol for message exchange between applications implanted on an onboard system, and corresponding onboard system
EP0944880A1 (en) Security module comprising means generating links between main files and auxiliary files
EP1208519B1 (en) System and method for loading commands into an integrated circuit card
EP1547005B2 (en) Microcircuit card whereof the performances can be modified after customization
WO2003073273A1 (en) Decentralised and customised service management method and device

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase