FR2881855A1 - Administration d'application de service dans une carte a microcontroleur depuis un terminal - Google Patents

Administration d'application de service dans une carte a microcontroleur depuis un terminal Download PDF

Info

Publication number
FR2881855A1
FR2881855A1 FR0501316A FR0501316A FR2881855A1 FR 2881855 A1 FR2881855 A1 FR 2881855A1 FR 0501316 A FR0501316 A FR 0501316A FR 0501316 A FR0501316 A FR 0501316A FR 2881855 A1 FR2881855 A1 FR 2881855A1
Authority
FR
France
Prior art keywords
data
terminal
recording medium
request
card
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.)
Pending
Application number
FR0501316A
Other languages
English (en)
Inventor
Christophe Foesser
Olivier Potonniee
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Gemplus SA
Original Assignee
Gemplus SCA
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 Gemplus SCA filed Critical Gemplus SCA
Priority to FR0501316A priority Critical patent/FR2881855A1/fr
Priority to PCT/EP2006/050528 priority patent/WO2006084800A1/fr
Publication of FR2881855A1 publication Critical patent/FR2881855A1/fr
Pending legal-status Critical Current

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/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • 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/0806—Details of the card
    • G07F7/0833—Card having specific functional components
    • G07F7/084—Additional components relating to data transfer and storing, e.g. error detection, self-diagnosis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer And Data Communications (AREA)

Abstract

Pour administrer la carte (C) comme serveur depuis un terminal client (T), le terminal reçoit de la carte des premières données relatives à une application de service implémentée dans la carte et demandée par le terminal dans une première requête (RQ). Dans le terminal, des deuxièmes données sont créées en dépendance des premières données et une commande en relation avec les deuxièmes données est validée. La carte exécute, suite à une deuxième requête incluant les deuxièmes données et un identificateur associé à la commande validée, une commande pour modifier des données incluses dans le support d'enregistrement en fonction des deuxièmes données en des données modifiées, comme un formulaire ou un fichier, et crée dynamiquement une deuxième réponse incluant les données modifiées, ou un statut sur la commande exécutée, afin de la transmettre au terminal.

Description

Administration d'application de service dans une
carte à microcontrôleur depuis un terminal La présente invention concerne l'administration d'application de service au moyen d'un terminal, des applications de service étant implémentées dans une carte à microcontrôleur.
Actuellement une carte à microcontrôleur, dite également carte à puce, est administrable au moyen d'un terminal connecté directement à la carte, ou le plus souvent depuis un terminal distant via un réseau de télécommunications. Le protocole de transfert de messages entre le terminal et la carte à microcontrôleur est spécifique à ce type de liaison entre un terminal et une carte à carte à microcontrôleur, et le terminal est pourvu d'un outil de communication spécifique audit protocole. Par exemple, une carte à puce SIM (Subscriber Identity Module) insérée dans un terminal mobile est administrée par un terminal distant faisant office de plateforme OTA (Over The Air) pour gérer selon un protocole de transfert spécifique le contenu de la carte par la transmission de messages courts SMS entre la carte et le terminal distant, le terminal mobile contenant la carte étant transparent aux contenus des messages courts. La transmission de messages courts nécessite des outils informatiques spécifiques implantés dans le terminal distant pour la mise en forme des messages courts et leurs transmission et réception vers et depuis la carte à microcontrôleur.
Cependant tous les terminaux ne sont pas dotés ou ne sont pas capables d'accueillir ces outils 35 informatiques spécifiques. De plus l'usager d'un terminal distant doit être formé à la manipulation de ces outils spécifiques pour administrer une carte à microcontrôleur.
Il existe donc un besoin d'administrer une carte à microcontrôleur par l'intermédiaire de protocoles de transfert et d'outils informatiques compatibles avec tous les terminaux fixes et mobiles classiques pour que tout usager puisse s'adresser à l'aide de l'un de ces terminaux à la carte comme à un serveur ordinaire. Plus particulièrement, l'invention a trait à des applications de service administrées dans la carte depuis un terminal communiquant à l'aide d'outils informatiques reposant sur des protocoles de transfert standard au niveau de la couche applicative de type HTTP (HyperText Transfert Protocol), FTP (File Transfert Protocol) ou Telnet, la carte agissant par rapport au terminal comme un serveur ordinaire.
Par ailleurs on connaît par la demande de brevet français 2805059 intitulée "Procédé de chargement d'une pièce de logiciel dans une carte à puce, notamment du type dit "applet"", un système de communication entre un terminal muni d'un lecteur de carte et une carte à microcontrôleur reposant sur des protocoles de transport de type TCP/IP et de transfert de type HTTP pour des communications de la carte à travers le réseau internet. Selon cette demande de brevet, une pièce de logiciel, telle qu'une applet, est chargée dans une carte à puce connectée à un terminal, le chargement étant mis en oeuvre à l'aide de premier et second programmes de chargement. Le premier programme de chargement peut être stocké dans le terminal, ou dans un serveur :3 communiquant avec le terminal via l'internet. Le second programme de chargement est stocké dans la carte à puce. Deux couches protocolaires de communication spécifiques sont respectivement implémentées dans le terminal connecté à la carte et dans la carte. Ces couches protocolaires comprennent des agents intelligents pour que la carte offre des fonctionnalités de client/serveur web et de passerelle CGI (Common Gateway Interface).
Le procédé de chargement comprend après l'ouverture d'une session entre au moins le terminal et la carte à puce, une transmission d'une requête selon le protocole "HTTP" fournie par le premier programme de chargement à la carte pour adresser une page HTML (HyperText Markup Language) avec une adresse URL (Uniform Resource Locator), une récupération de données de paramétrage fournies par le second programme de chargement et véhiculées par un formulaire "HTML", et une exécution du deuxième programme de chargement en dépendance des données de paramétrage par mise en oeuvre de la fonctionnalité CGI pour charger la pièce de logiciel.
La demande de brevet français précitée 2805059 ne concerne qu'un chargement d'apple: dans la carte basé sur le protocole de transfert HTTP. Elle nécessite des programmes de chargement spécifique et n'est pas orientée vers urne modification de données dans une mémoire de la carte afin de communiquer classiquement avec un terminal d'usager agissant comme un client classique.
L'invention a pour objectif d'administrer une carte à microcontrôleur depuis un terminal d'usager et non uniquement de charger une pièce de logiciel dans la carte. Cette administration est effectuée dynamiquement dans la carte sur la base d'un protocole de transfert standard par exemple de type HTTP, FTP ou Telnet entre le terminal et la carte.
Pour atteindre cet objectif, un procédé pour administrer un support d'enregistrement à microcontrôleur agissant comme un serveur depuis un terminal agissant comme un client, le terminal et le support d'enregistrement reposant sur un protocole de transfert de données, le terminal recevant du support d'enregistrement une première réponse incluant des premières données relatives à une application de service implémentée dans le support d'enregistrement et demandée préalablement par le terminal dans une première requête, le terminal affichant les premières données afin que des deuxièmes données soient créées en dépendance des premières données et une commande en relation avec les deuxièmes données soit validée, est caractérisé en ce que le support d'enregistrement exécute les étapes suivantes: en réponse à une deuxième requête transmise depuis le terminal et incluant les deuxièmes données et un identificateur de commande associé à la commande validée, exécution par le support d'enregistrement d'une commande correspondant à l'identificateur de commande extrait de la deuxième requête pour modifier des données incluses dans le support d'enregistrement en fonction des deuxièmes données en des données modifiées, et création dynamique d'une deuxième réponse incluant les données modifiées, ou un statut sur la commande exécutée, afin de la transmettre au terminal.
L'invention ainsi caractérisée offre les avantages de - configurer des cartes à microcontrôleur, en tant que supports d'enregistrement miniatures à microcontrôleur, à partir d'un terminal distant ou non sans implémenter dans le terminal un logiciel spécifique à l'administration des cartes à puce; - utiliser un moyen de consultation de type navigateur connu à l'interface d'usager dans le terminal pour administrer des cartes afin d'éviter de former l'usager du terminal sur un nouveau logiciel d'administration de carte à puce.
Selon un premier exemple, le protocole de transfert de données est un protocole de transfert d'hypertexte. Dans cet exemple, les données sont textuelles, les deuxièmes données créées sont saisies ou sont sélectionnées parmi les premières données, et la commande en relation avec les deuxièmes données est un champ de commande valide.
Selon un deuxième exemple, le protocole de transfert de données est un protocole de transfert de fichier. Dans cet exemple, les données sont des identificateurs de fichiers ou des fichiers, et les deuxièmes données créées sont au moins un identificateur de fichier sélectionné parmi les identificateurs de fichiers, ou au moins un fichier sélectionné parmi les fichiers, ou au moins un fichier initialement mémorisé dans le terminal Selon une autre caractéristique du procédé de l'invention, le protocole de transfert est identifié à la réception d'une requête dans la carte, en fonction d'un identificateur de protocole de transfert extrait de la requête afin de traiter la requête selon le protocole de transfert identifié. L'invention administre ainsi une carte à puce en utilisant un logiciel de réseau standard disponible sur un grand nombre de terminal, tout en offrant une compatibilité avec des protocoles de transfert standard servant de base pour communiquer au niveau applicatif avec le terminal.
L'usager du terminal, qui peut être à proximité ou distant de la carte, s'adresse à la carte comme s'il s'adressait à un serveur ordinaire, la carte transmettant par exemple des formulaires ou des informations de fichiers pour son administration au terminal sur la base de l'un des protocoles de transfert standard.
Les applications de service d'administration de la carte sont relatives par exemple à la gestion de code secret de sécurité de la carte, des changements d'état de la carte, des modifications comme des adjonctions ou suppressions de données relatives à un service comme la gestion d'un répertoire téléphonique dans une mémoire de la carte, l'activation ou la désactivation d'une application de service dans carte, etc. L'invention a trait également à un système pour administrer un support d'enregistrement à microcontrôleur agissant comme un serveur depuis un terminal agissant comme un client, le terminal et le support d'enregistrement comportant respectivement un moyen de consultation et un moyen de traitement reposant sur un protocole de transfert de données, le moyen de consultation recevant du moyen de traitement une première réponse incluant des premières données relatives à une application de service implémentée dans le support d'enregistrement et demandée préalablement par le terminal dans une première requête, le terminal affichant les premières données afin que des deuxièmes données soient créées en dépendance des premières données et une commande en relation avec les deuxièmes données soit validée. Le système est caractérisé en ce que le moyen de traitement comprend: un moyen d'administration d'application pour exécuter, en réponse à une deuxième requête transmise depuis le terminal et incluant les deuxièmes données et un identificateur de commande associé à la commande validée, une commande correspondant à l'identificateur de commande extrait de la deuxième requête pour modifier des données incluses dans le support d'enregistrement en fonction des deuxièmes données en des données modifiées, et un moyen pour créer dynamiquement une deuxième réponse incluant les données modifiées, ou un statut sur la commande exécutée, afin de la transmettre au terminal.
L'invention est relative encore à un support d'enregistrement à microcontrôleur, tel qu'une carte à microcontrôleur, agissant comme un serveur et communiquant avec un terminal agissant comme un client, comme défini dans le système selon l'invention.
En particulier, le moyen de traitement dans le support d'enregistrement à microcontrôleur peut comprendre un moyen pour identifier le protocole de transfert en fonction d'un identificateur de protocole de transfert extrait d'une requête reçue par le support d'enregistrement afin de sélectionner un moyen dans le support d'enregistrement pour traiter la requête selon le protocole de transfert identifié.
D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations préférées de l'invention, données à titre d'exemples non limitatifs, en référence aux dessins annexés correspondants dans lesquels: - la figure 1 est un bloc-diagramme schématique d'un système d'administration d'application de service de carte à microcontrôleur selon l'invention - la figure 2 est un exemple de formulaire inclus dans une réponse de carte selon l'invention; - les figures 3A et 3B sont des blocs-diagrammes schématiques d'architectures de système d'administration selon des première et deuxième réalisations de l'invention; - la figure 4 est un bloc-diagramme schématique particulièrement de moyens fonctionnels propres à l'invention dans une carte à microcontrôleur; - la figure 5 est un algorithme d'un procédé d'administration de carte avec échange de requêtes et réponses entre un terminal et une carte, selon l'invention; et - la figure 6 est un algorithme détaillant le traitement d'une requête et la construction d'une réponse dans la carte, inclus dans le procédé d'administration de carte.
Le système d'administration d'application de service d'une carte à microcontrôleur repose sur une architecture client/serveur sensiblement de présentation. Dans cette architecture client/serveur représentée à la figure 1, un terminal T d'un usager agit en tant que client et une carte à microcontrôleur C de l'usager agit en tant que serveur. Comme on le verra par la suite au sujet des figures 3A et 3B, des requêtes RQ et réponses RP sont échangées entre le termina=_ et la carte, 2881855 9 soit à travers un réseau de télécommunications, le terminal et la carte étant éloignés selon la première réalisation, soit localement, le terminal et la carte étant à proximité selon la deuxième réalisation.
En référence à la figure 1, le terminal d'usager T comprend un processeur PT, des mémoires MT, un afficheur AF tel qu'un écran connecté ou intégré au terminal et associé notamment à un clavier connecté ou intégré au terminal T, et soit une interface de réseau IRT pour au moins la première réalisation et/ou un lecteur de carte à microcontrôleur LT pour au moins la deuxième réalisation. Les différents éléments du terminal sont reliés entre eux par un bus bidirectionnel BT. Le terminal T comprend sous forme de module logiciel un élément de consultation ECT tel qu'un navigateur supportant un protocole de transfert de données, par exemple un protocole de transfert d'hypertexte HTTP (HyperText Transfer Protocol) ou un protocole de transfert de fichier FTP (File Transfer Protocol), ou tout autre protocole de transfert de données connu, inclus dans les mémoires MT. L'élément de consultation ECT transmet une requête RQ selon une demande saisie par l'usager du terminal vers la carte C et reçoit une réponse R]? de la carte C à afficher sur l'afficheur AF. La requête RQ et la réponse RP sont formatées par l'interface de réseau IRT pour transiter entre le terminal T et la carte C selon un protocole de "transport" de données standard, par exemple de type TCP (Transmission Ccntrol Protocol) combiné au protocole de réseau IP (Internet Protocol).
La carte à microcontrôleur C, dite également carte à puce ou carte à circuit intégré, peut être du type UICC (Universal Integrated Circuit Card). Comme il est connu, la carte à microcontrôleur C comprend principalement un processeur PC et trois mémoires M1 à M3. La carte peut comprendre également un port d'entrée/sortie PES connectable au lecteur avec ou sans contact pour échanger des commandes, ou requêtes, et réponses avec un terminal, comme le terminal T. Les différents éléments de la carte sont reliés entre eux par un bus bidirectionnel BC. La mémoire M1 est du type ROM ou Flash et inclut le système d'exploitation de la carte. La mémoire M2 est une mémoire non volatile par exemple EEPROM ou Flash pour notamment mémoriser des clés, des numéros d'identité et d'autres paramètres du profil de l'usager possédant la carte, comme un code PIN et autres données de sécurité. La mémoire M3 est une mémoire RAM ou SRAM servant plus particulièrement au traitement de données.
La carte C comprend, en outre relativement à l'invention, un élément de traitement logiciel ETR réparti dans les mémoires M1 et M2. L'élément de traitement ETR reçoit une requête RQ, tel qu'un paquet selon le protocole de transport standard utilisé par le terminal T, interprète et traite la requête RQ, forme une réponse RP, tel qu'un paquet selon ledit protocole de transport, et transmet la réponse au terminal T. Les mémoires Ml et M2 comportent également un module logiciel d'administration de la carte regroupant tous les services de configuration et d'administration de la carte, ainsi que des applications de service interactives. Chacune de ces applications de service dans la carte en tant que serveur comporte des fonctions pour traiter des requêtes qui lui sont destinées, notamment pour modifier des données 1 1 incluses dans la carte en fonction de données dans des requêtes, ordonnancer les interactions requête-réponse avec le terminal T et construire dynamiquement des réponses notamment avec des données de carte modifiées, par exemple sous forme de pages d'écran ou de fichiers préparés, afin que l'afficheur AF du terminal T, en tant que client, présente les pages ou les fichiers.
Les requêtes RQ sont des paquets ayant un en- tête compatible avec le protocole de transport utilisé et un champ de données. La première requête RQ transmise par le terminal T initialise la communication entre le terminal et la carte C et comprend notamment un identificateur de service IS associé au service demandé par l'usager du terminal et dispensé par l'exécution d'une application de service implémentée dans la carte. L'identificateur de service peut être par exemple une adresse indiquant l'espace mémoire occupé par les instructions et les données de l'application de service dans la carte. Chaque requête suivante RQ est formée après interprétation et traitement saisies et/ou de données sélectionnées dans une réponse précédemment transmise par la carte et/ou lues en mémoire du terminal et au moins d'une commande validée CC en relation avec ces données à interpréter et traiter. Les requêtes suivantes comprennent également un ou plusieurs en-têtes identifiant un protocole de transfert et es données saisies et/ou sélectionnées et/ou lues et au moins l'identificateur de la commande validée.
Une réponse RP est un paquet ayant un en-tête compatible avec les protocoles de transport et de transfert utilisés et un champ de données relatif à une demande de service de l'usager et pouvant inclure par exemple un formulaire sous forme de page HTML (HyperText Markup Language) ou des informations de fichiers au format FTP.
A titre d'exemple, on se référera dans la suite de la description, sauf mention d'autres exemples, à des données compatibles avec un protocole de transfert d'hypertexte, comme le protocole HTTP (HyperText Transfert Protocol), et donc à des données requises par le termina_ sous forme de page ou formulaire HTML. Le formulaire comporte notamment des données mémorisées dans la carte, ccmme des données de répertoire, et des champs de saisie de données et/ou de bouton de commande relatifs au service demandé. Le formulaire, une fois reçu, est affiché par le terminal sur l'afficheur AF pour être lu par l'usager.
Un exemple de page de formulaire est illustré à la figure 2. Il concerne une application de service de gestion d'un répertoire téléphonique mémorisé dans la carte à microcontrôleur C. Le formulaire comporte des données mémorisées dans la carte C, comme des noms de contacts Dal et des numéros téléphoniques ou adresses associés Da2, et des outils de gestion d'interactivité pour le service tels que la suppression ou l'ajout de données, les outils étant représentés par des champs de sélection/saisie de contacts Dbl, Db2 et/ou de numéros de téléphone Db3, et des boutons de commande par exemple relatifs à une commande de suppression CC1 d'un contact sélectionné Dbl ou à une commande d'ajout CC2 d'un contact Db2 et de son numéro téléphonique Db3, ou à une demande CC3 pour accéder à un autre service ou à la fin d'une session entre le terminal et la carte.
Les figures 3A et 3B illustrent respectivement deux réalisations pour l'échange de requête et réponse entre le terminal T et la carte C. Selon la première réalisation représentée à la figure 3A, le système comprend une carte à microcontrôleur C connectée avec ou sans contact à un un lecteur de carte L relié à un réseau de télécommunications R reposant sur le protocole TCP/IP. Selon un premier exemple, le lecteur L est un lecteur intelligent comprenant au moins un processeur et une mémoire. Selon des deuxièmes exemples, le lecteur L est inclus dans un terminal possédant une interface de réseau et pouvant être un terminal radio mobile, un terminal bancaire accueillant une carte de débit ou de crédit, ou un ordinateur personnel ou une station de travail doté d'un lecteur de carte à puce, ou bien un petit équipement communicant tel qu'un assistant numérique personnel (PDA) pouvant lire une carte à microcontrôleur introduite dans celui-ci. Le terminal T est distant du lecteur L connecté à la carte et est connecté au réseau R. Le terminal distant T comprend l'élément de consultation standard ECT tel qu'un navigateur Web pour transmettre une requête RQ à destination de la carte C à travers le réseau R et le lecteur L. La carte comprend également l'élément de traitement ETR pour interpréter et traiter la requête RQ et pour constituer une réponse RP à cette requête transmise par la carte au terminal distant T à travers le lecteur L et le réseau R. A la réception de chaque requête RQ au niveau du protocole de transport, transmise par le terminal distant T, un module de communication spécifique logiciel COM1 inclus dans la mémoire du lecteur L segmente et encapsule la requête au niveau du 1 4 protocole de transfert dans des commandes CMD de type "ENVELOPPE" transmises à la carte. Les commandes sont relatives à un jeu de commandes et réponses pouvant constituer des unités de données protocolaires APDU (Application Protocol Data Unit) définies selon un protocole de communication directe asynchrone spécifique entre un terminal constitué ou incorporant le lecteur L et la carte à microcontrôleur reliée au lecteur, par exemple selon la norme ISO 7816-3.
Chaque commande CMD-APDU issue de la requête RQ est transmise à un module de communication logiciel spécifique COM2 inclus dans les mémoires M1 et M2 de la carte C. A la réception des commandes CMD-APDU comprenant la requête RQ, le module COM2 de la carte décapsule les commandes CMD-APDU pour recomposer la requête RQ et l'appliquer à l'élément ETR de la carte C pour la traiter. L'élément ETR forme une réponse RP à la requête RQ selon le protocole de transport standard, l'applique au module COM2 qui segmente et encapsule la réponse RP dans des réponses RP-APDU selon le protocole de communication directe entre la carte C et le lecteur L. le module de communication COM1 du lecteur L décapsule les réponses RP-APDU en des segments et concatène les segments en la réponse RP pour la transmettre au terminal distant T à travers le réseau R selon le protocole de transport utilisé par le terminal T et indiqué dans l'en- tête de la réponse RP.
Ainsi l'usager du terminal communique avec la carte de manière transparente à travers le lecteur L, comme s'il communiquait avec un serveur web.
En référence à la figure 3B selon la deuxième réalisation, le terminal T accueille:_ui-même avec ou sans contact la carte à microcontrôleur C. Dans cette deuxième réalisation, le terminal T comprend l'élément de consultation standard ECT et le module de communication spécifique COM1 qui encapsule une requête RQ en des commandes CMD--APDU selon le protocole de communication spécifique pour transmettre ces commandes successivement à la carte C et qui décapsule des réponses RP-APDU selon le protocole de communication spécifique en des segments et concatène les segments en une réponse RP pour l'appliquer à l'élément de consultation ECT.
Lorsque le terminal est un terminal radio mobile, la carte est par exemple une carte SIM (Subscriber Identity Module) pour un réseau de radiocommunication cellulaire du type GSM, ou un module d'identité USIM ou RUIM (Removable User Identity Module) pour un réseau à accès multiple à répartition par codes CDMA (Coded Division Multiple Access) de la troisième génération (3GPP) du type UMTS (Universal Mobile Telecommunications System), ou de la troisième génération (3GPP2) du type CDMA 2000. Selon d'autres exemples, le terminal T est un terminal bancaire accueillant une carte de paiement, ou un ordinateur personnel doté d'un =lecteur de carte à microcontrôleur, ou bien un petit équipement communicant tel qu'un assistant numérique personnel (PDA) pouvant lire la carte à microcontrôleur introduite dans celui-ci.
Selon encore d'autres exemples relatifs aux figures 3A et 3B, les échanges de données entre la carte et le lecteur, ou le terminal, sont basés sur un protocole de communication de type USB (Universal Serial Bus) lorsque la carte est remplacée par un support d'enregistrement à microcontrôleur comme une clé USB, ou de type MMC (Multi Media Card) lorsque la carte est une carte multimédia. La carte peut être encore une "Flash-Memory Card" corrme une "Secure Digital Card", ou bien être remplacée par tout support d'enregistrement miniature portable amovible à microcontrôleur.
L'invention n'est pas limitée aux réalisations décrites ci-dessus et à leurs variantes. La carte à microcontrôleur peut comprendre une interface de transport/réseau physique qui est connectée par contact ou sans contact directement au réseau et associée à l'élément de traitement ET. inclus dans la carte pour échanger directement des requêtes RQ et des réponses RP par exemple selon le protocole de transport/réseau de type TCP/IP avec l'élément de consultation ECT du terminal T, c'est-à-dire seulement à travers un réseau de télécommunications R reposant par exemple sur le protocole TCP/IP, mais sans être connectée à un lecteur quelconque et sans ainsi échanger des requêtes et des réponses, par 2C exemple de type APDU ou des paquets de type USB, avec le terminal selon un protocole de communication spécifique à travers des modules de communication spécifiques COM1 et COM2.
En se référant maintenant à la figure 4, la carte à microcontrôleur C de l'invention connectée au terminal T comporte l'élément de traitement ETR et un module d'administration d'application de service MAd pour administrer une ou plusieurs applications de service. Les modules de communication COM1 et COM2 ne sont pas représentés dans la figure 4 puisqu'ils n'interviennent pas directement dans l'interprétation et le traitement des requêtes RQ et la construction des réponses REP et peuvent être considérés comme transparents pour le transfert des requêtes RQ et des réponses REP entre le terminal T et la carte C. L'élément de traitement ETR qui est un module logiciel réparti dans les mémoires Ml et M2 de la carte C, comprend un module serveur MS, un ou plusieurs modules de protocole de transfert et une ou plusieurs interfaces d'administration. A titre d'exemple, on a supposé que l'élément de traitement ETR comprenait deux modules de protocole MP1, MP2 et trois interfaces d'administration IAdl, IAd2 et IAd3.
Le module serveur MS reçoit les requêtes RQ provenant du terminal T et transmet les réponses RP vers le terminal. Le module MS gère les couches basses sous le protocole de transport standard TCP/IP depuis la couche physique dans la carte à puce. En outre, le module serveur comprend de préférence un moyen logiciel de sécurité pour gérer une couche intermédiaire de sécurité standard de type SSL/TSL (Secure Socket Layer/Transport Security Layer) interfacée au dessus du protocole de transport TCP au niveau applicatif entre le protocole de transfert de données et chaque application proprement dite, et indépendante des applications. Le moyen de sécurité garantit la confidentialité et l'intégrité des données échangées entre la carte et le terminal via le réseau, en négociant initialement des algorithmes de chiffrement symétriques et d'authentification mutuelle entre la carte et le terminal et des clés symétriques basées sur une clé maître choisie par le terminalclient et chiffrée en fonction d'une clé publique transmise par la carte au terminal.
Les modules de protocole de transfert MP1, MP2 gèrent le transfert de message de données au niveau de la couche d'application dans la carte C. Chaque module de protocole MP1, MP2 est dédié à un protocole 1 8 de transfert de message de données au niveau applicatif. Par exemple le module MP1 est dédié au protocole HTTP (HyperText Transfer Protocol) et le module MP2 est dédié au protocole FTP (File Transfer Protocol), ou bien encore à des commandes d'interrogation de machine selon le protocole Telnet, ou tout autre protocole de transfert de données connu. Pour chaque application de service, l'un des modules MP1, MP2 est sélectionné par le module serveur MS en fonction d'un identificateur de protocole de transfert extrait des requêtes RQ.
Chaque interface d'administration IAdl, IAd2, IAd3 est spécifique à urne application de service relative à un service géré par le module d'administration MAd. Par exemple, l'interface IAdl est compatible avec le protocole de transfert HTTP et spécifique à une application de service pour gérer un répertoire téléphonique. L'interface IAd2 est également compatible avec le protocole de transfert HTTP et spécifique à une application de service par exemple pour gérer un abonnement à des informations particulières par exemple d'actualités, sportives ou boursières. L'interface IAd3 est compatible avec le protocole de transfert FTP et spécifique à une application de service pour gérer des fichiers, par exemple concernant des courriers électroniques et des répertoires. Chaque interface d'administration interprète les données dans les messages de requête communiqués par le module de protocole respectif et les identificateurs de commande dans les requêtes RQ et peut établir un formulaire F en réponse à une requête.
Les fonctions des modules MS, MP et IAd sont détaillées au cours de la description de la figure 6.
La suite de la description relative au procédé d'administration d'applications de service de la carte ne se réfère qu'à l'échange entre la carte à microcontrôleur C et le terminal T selon l'exemple de référence avec le protocole HTTP et des données requises par le terminal sous forme de formulaire HTML. La manière de transmettre les paquets et les messages inclus dans les paquets, comme décrite ci-dessus selon les réalisations montrées aux figures 3A lC) et 3B, n'influe pas sur le déroulement du procédé d'administration selon l'invention.
En référence à la figure 5, un algorithme du procédé d'administration d'applications de service selon l'invention pour administrer depuis le terminal T des applications de service interactives implémentées dans la carte à microcontrôleur C comprend des étapes El à E9 après ouverture d'une session entre le terminal T et la carte C débutant par une négociation d'algorithmes de chiffrement et une authentification mutuelle.
A l'étape El, l'usager du terminal client T saisit par l'intermédiaire du clavier une demande d'un service S parmi une pluralité de services dispensés par des applications de service gérées par le module d'administration MAd. Cette demande démarre une session d'administration d'une application de service. L'élément de consultation (navigateur) ECT du terminal T traite cette demande et construit et transmet une requête RQ1 comportant d'une part un en-tête En (figure 6) incluant un identificateur de protocole de transfert du terminal et d'autre part un identificateur ISa du service demandé S, par exemple une adresse désignant des données et instructions relatives à l'application du service demandé et mémorisées dans la mémoire M2 de la carte C. A l'étape E2, l'élément de traitement ETR de la carte C reçoit la requête RQ1 et l'interprète, c'està-dire récupère l'identificateur ISa du service S demandé par l'usager et la délivre au module d'administration MAd via le module de transfert MP et l'interface d'administration IA compatibles avec l'application du service demandé S. 1C) En fonction de l'identificateur ISa, le module d'administration MAd recherche, à l'étape E3, dans la mémoire M3 de la carte C des données Da relatives au service demandé S, et fournit les données trouvées Da et éventuellement un ou des identificateurs de commande ICa nécessaires à l'administration de l'application du service S à l'élément ETR.
A l'étape E4, l'élément de traitement ETR crée en fonction de l'identificateur ou des identificateurs ICa et de premières données Da un 2C premier formulaire numérique F1 lié au service S demandé, comme par exemple celui représenté à la figure 2. Les données Da peuvent être un ou plusieurs caractères alphanumériques, par exemple un ou plusieurs mots, et/ou signes. Le formulaire F1 comporte les données recherchées Da, des champs de saisie CS et des champs de commande CC relatifs à des commandes exécutables par le module MAd traitant le service S. L'élément de traitement ETR construit, formate et transmet une première réponse RP1 au terminal T. La réponse RP1 comporte d'une part un en-tête En (figure 6) relatif au protocole de transport standard utilisé entre le terminal et la carte et d'autre part l'identificateur ISa du service demandé S et le formulaire Fl précédemment créé avec les premières données Da. 2:
L'élément de consultation ECT du terminal reçoit la réponse RP1, la traite et affiche le formulaire Fl avec les données Da sur l'afficheur du terminal T, à l'étape E5.
A l'étape E6, l'usager modifie par l'intermédiaire du clavier du terminal les données Da, y compris peut ajouter ou supprimer des données, pour créer finalement des deuxièmes données Db du service S en dépendance des premières données Da via un ou plusieurs champs de saisie CS et/ou valide des commandes dans des champs de commande CC associés aux champs de saisie CS. Les deuxièmes données Db peuvent être saisies au clavier en fonction de premières données affichées Da, ou sélectionnées parmi les données Da. En reprenant: l'exemple du répertoire téléphonique montré à la figure 2, l'usager peut soit sélectionner un contact Dbl dans le champ de saisie CS1 pour le du répertoire et valider une commande "Supprimer " sur le bouton de commande CC1, soit 2G saisir le nom d'un nouveau contact Db2 et son numéro téléphonique Db3 dans les champs de saisie respectifs CS2 et CS3 et valider une commande "Ajouter" sur le bouton de commande CC3 associé. L'usager peut également valider directement une commande "Autres Services" sur un bouton de commande relatif à une demande d'un autre service S ou à l'arrêt de la session. Selon l'exemple de la figure 2, l'usager sélectionne et valide le bouton de commande CC3 pour invoquer un lien vers un autre service.
L'élément de consultation ECT du terminal T construit et transmet une deuxième requête RQ2 à l'élément ETR de la carte. La requête RQ2 comporte, outre un en-tête En incluant l'identificateur de protocole de transfert, l'identificateur ISb du service demandé S selon le service demandé par l'usager, les deuxièmes données Db et un ou des identificateurs ICb de champs de commande validés CC. Par exemple, si l'usager demande la modification de données du service de gestion du répertoire téléphonique, l'identificateur ISb est identique à l'identificateur reçu ISa et est inclus en tant qu'identificateur de service relatif au service de gestion d'un répertoire téléphonique, dans la requête RQ2. Si l'usager valide le lien vers un autre lC) service, la requête RQ2 ne comprend que l'identificateur de service ISb relatif audit autre service et est ainsi différent de l'identificateur reçu ISa.
A l'étape E7, l'élément de traitement ETR reçoit la requête RQ2 et l'interprète.
Si à l'étape E8 l'identificateur de service ISb est différent du premier identificateur de service ISa et correspond donc à un autre service, l'élément ETR et l'élément ECT exécute les étapes E3 à E7 précédentes en fonction des données et commandes relatives audit autre service demandé. En particulier l'élément ETR crée dynamiquement un deuxième formulaire différent du premier formulaire en fonction de données dudit autre service demandé lues dans la carte et donc modifiées par rapport aux données reçues Db.
Si à l'étape E8 l'identificateur ISb est identique à l'identificateur ISa et correspond au premier service demandé S, l'élément ETR délivre les deuxièmes données Db et le ou les identificateurs de commande ICb des champs de commande validés CC associés audites données Db et extraits de la requête RQ2, au module d'administration MAd. A l'étape E9, le module MAd traite les données Db et exécute les commandes correspondant aux identificateurs de commande ICb. En reprenant l'exemple précédent relatif au service de gestion de répertoire téléphonique, les données Db sont, ou bien supprimées dans la mémoire M2 de la carte, ou bien mémorisées directement dans la mémoire M2, c'est-à-dire des données Dc mémorisées sont lues dans la mémoire M2 de la carte en fonction des données reçues Db afin de produire des données modifiées Dcm écrites dans la mémoire M2. Par exemple, le procédé retourne à l'étape E3 afin que le module MAd recherche des données Da qui doivent être actualisées en fonction des modifications précédentes et qui sont ensuite appliquées en tant que données modifiées Dcm à l'élément ETR qui les inclut dans une deuxième réponse RP2 et la transmet à l'élément ECT du terminal. A une étape suivante E4, l'élément ETR crée dynamiquement et transmet ainsi au terminal la deuxième réponse RP1=RP2 avec un formulaire qui inclut les données modifiées Da=Dcm relatives au service demandé et qui peut être similaire au ou différent du premier formulaire précédemment affiché.
A La fin de la session, l'usager sélectionne un champ de commande de fin de session inclus dans le formulaire. Le champ de commande de fin de session validé est transmis dans une requête à l'élément ETR de la carte qui en informe le module d'administration MAd et qui transmet une réponse acquittant la fin de la session.
Selon une variante complémentaire, le service S demandé par l'usager peut nécessiter un droit d'accès désigné par un code de sécurité. Des étapes supplémentaires viennent compléter les étapes E3 et E4, d'une manière analogue à la suite d'étapes E3 à E7.
Lors de l'étape E3 en réponse à la première requête RQ1, le module MAd délivre à l'élément de traitement ETR dans la carte un identificateur de commande pour inviter l'usager à fournir un code de sécurité. L'élément ETR crée et transmet au terminal un formulaire de sécurité FS comportant au moins un champ de saisie et un champ de validation pour code de sécurité. Après saisie et validation du code de sécurité dans les champs de saisie et de validation du formulaire de sécurité FS sur l'afficheur AF du terminal, l'élément de consultation ECT du terminal retourne dans une deuxième requête au moins le code de sécurité en tant que données saisies, l'identificateur du champ de validation validé et l'identificateur de service IS. L'élément ETR applique le code de sécurité saisi au module MAd qui le traite. Le module MAd accepte l'administration du service S par l'usager si le module MAd reconnaît le code de sécurité saisi en association au profil de 2C l'usager pré- mémorisé dans la carte et à l'identificateur de service IS; le procédé reprend alors à l'étape E4 et le module MAd retourne les données Da. Si le module d'administration retourne une information d'erreur de sécurité à l'élément ETR, celui-ci transmet au terminal une réponse d'interdiction d'administration de l'application de service demandé, le cas échéant accompagnée d'un formulaire d'abonnement au service demandé.
Le fonctionnement de:L'élément de traitement ETR dans la carte depuis la réception d'une requête jusqu'à la construction et la transmission d'une réponse est maintenant décrit selon des étapes S1 à S12 montrées à la figure 6, détaillant une combinaison d'étapes dans la carte analogue aux étapes E2 à E4, ou E7 à E4 par exemple.
A l'étape S1, le terminal client T transmet une requête RQ au module serveur MS de l'élément ETR. La requête comprend au moins un champ d'entête En et l'identificateur ISa du service demandé S. Si la requête est induite, comme la requête RQ2, par la validation d'un champ de commande d'un formulaire affiché sur l'afficheur AF du terminal, elle comprend également au moins des données créées Db, saisies ou sélectionnées, et un identificateur de commande validée ICb. Le module serveur MS identifie le protocole de transfert utilisé en fonction d'un identificateur de protocole de transfert extrait de l'en-tête En de la requête afin de sélectionner un module de protocole MP dédié au protocole de transfert identifié pour traiter la requête selon le protocole de transfert identifié et de lui délivrer la requête RQ pour la traiter, à l'étape S2. Par 2C exemple, l'en-tête En de la requête comporte l'identificateur du protocole de transfert HTTP, et le module MS délivre cette requête au module sélectionné MP1 dédié au protocole identifié HTTP.
Si à l'étape S3 la requête RQ ne comporte pas de données Db et d'identificateur de commande ICb, comme la requête RQ1, signifiant ainsi que l'usager du terminal requiert un service S, le module MP s'adresse à l'interface d'administration IAd dédiée à l'application du service demandé S en fonction de l'identificateur ISa, à l'étape S4, et applique l'identificateur ISa à l'interface d'administration IAd. A l'étape S5, l'interface IAd fournit l'identificateur ISa au module MAd. A l'étape S6, le module MAd recherche les données Da relatives au service demandé S désigné par l'identificateur ISa et fournit des données Da et un ou des identificateurs de commande ICa propres à l'administration de l'application du service S à l'interface d'administration IAd. Si l'administration du service S nécessite un code de sécurité selon la variante complémentaire, le module d'administration MAd fournit préalablement à l'interface IAd un identificateur de commande IC pour solliciter un code de sécurité dans le terminal.
1C En revenant à l'étape S3, si la requête RQ comporte, comme la requête RQ2, au moins des données saisies ou sélectionnées Db et un identificateur de commande ICb indiquant qu'un champ de commande du formulaire affiché sur l'afficheur AF a été validé dans le terminal, le module MP à l'étape S7 s'adresse à l'interface d'administration IAd dédiée à l'application du service demandé S en fonction de l'identificateur de service ISa extrait de la requête. Le module MP applique les données Db et l'identificateur de commande ICb à l'interface d'administration IAd. A l'étape S8, l'interface IAd fournit les données Db et l'identificateur de commande ICb au module MAd. A l'étape S9, le module MAd exécute la ou les commandes associées à l'identificateur de commande ICb pour modifier des données Dc mémorisées et lues dans la mémoire M2 de la carte en fonction des données Db afin de produire des données modifiées Dcm qui sont écrites dans la mémoire M2 et qui peuvent être un statut sur la commande exécutée et plus généralement sur des opérations relatives aux commandes exécutées associées à l'identificateur de commande ICb. Puis le module MAd peut compléter les données modifiées par d'autres données relatives au service S et transmet les données modifiées Da=-Dcm et des identificateurs 2.
de commande ICa nécessaires à l'administration de l'application du service S à l'interface d'administration IAd.
A l'étape S10, l'interface IAd crée dynamiquement dans une réponse RP1, RP2 d'un formulaire numérique F correspondant au service demandé S et comportant les données Da, DaDcm, le ou les champs de saisie CS et/ou le ou les champs de commande CC sélectionnés en fonction du ou des 1C identificateurs de commande ICa, ICb propres à l'administration de l'application du service S et fournis par le module MAd.
Selon une première variante, la création d'un formulaire est fondée sur un modèle de formulaire numérique invoqué directement par l'interface IAd en fonction de l'un des indicateurs de commande fournis ICa, ICb. Le modèle de formulaire a été pré-mémorisé dans la mémoire M2 de la carte et comporte des champs vides qui sont remplis avec les données Da, Da=Dcm, fournies par le module MAd.
Selon une deuxième variante, l'interface IAd invoque un programme de création de formulaire numérique pré-mémorisé dans la mémoire M2 de la carte, en fonction de l'un des identificateurs de commande ICa, ICb propres à l'administration de l'application du service. Le programme de création de formulaire comporte des instructions de création d'un formulaire en fonction de l'application du service demandé S, c'est-àdire en fonction de l'identificateur de commande ICa propre à l'administration de l'application, impliquant la présence de champs de saisie et de champs de commande spécifiques, et des données Da, DaDcm.
Dans ces deux variantes, le modèle de formulaire ou le programme de création de formulaire invoqué est indépendant de l'interface d'administration IAd dédiée à l'application du service demandé S et du protocole de transfert utilisé. Pcur la variante complémentaire, la mémoire M2 comprend par exemple un modèle ou un programme de création de formulaire de sécurité et de formulaire d'erreur de traitement.
Lorsque le formulaire est créé, l'interface IAd le délivre au module MP qui a été précédemment identifié par l'identificateur de protocole de transfert extrait de l'en-tête En de la requête à l'étape S2. Le module MP construit et formate à l'étape S11 une réponse RP comportant un en- tête En relatif au protocole de transfert, l'identificateur de service ISa du service demandé S et le formulaire créé F. Le module MP applique la réponse RP au module MS. A l'étape S12, le module MS transmet la réponse dans un paquet selon le protocole de transport au terminal T. Les étapes S10 à S12 sont ensuite exécutées pour 2C créer un formulaire actualisé similaire au formulaire précédent.
Selon un autre exemple, l'échange entre la carte à microcontrôleur C et le terminal T est basé sur le protocole de transfert de fichier FTP (File Transfert Protocol). Les données Da, Dcm dans des réponses RP1, RP2 de la carte peuvent inclure au moins un identificateur de fichier ou des informations de fichier ou un fichier, et les données Db dans des requêtes RQ2 du terminal peuvent inclure au moins un identificateur de fichier ou des informations de fichier ou un fichier. Une requête inclut par exemple un identificateur de fichier sélectionné par l'usager parmi des identificateurs de fichiers extraits d'une réponse précédente de la carte, ou des informations 2 9 de fichier sélectionnées et modifiées décrivant un fichier, ou un fichier sélectionné et modifié par l'usager parmi des fichiers extraits d'une réponse précédente, ou un fichier ou des informations de fichier initialement mémorisé et récupéré dans le terminal et à introduire dans la carte ou un identificateur de ce fichier récupéré. Ces fichiers peuvent être ceux de répertoires d'une application particulière ou de diverses applications implémentées dans la carte.
L'invention décrite ici concerne un procédé et un système d'administration d'application de service. Selon une implémentation préférée, les étapes du procédé de l'invention sont déterminées par les instructions d'un programme d'ordinateur incorporé dans le système d'administration combinant la carte à microcontrôleur C et le terminal, ou au moins en partie dans un support d'enregistrement portable à microcontrôleur tel que la carte à microcontrôleur C. Le programme comporte des instructions de programme qui, lorsque ledit programme est chargé et exécuté dans le système, exécutent les étapes du procédé selon l'invention.

Claims (1)

  1. 3 C) REVENDICATIONS
    1 - Procédé pour administrer un support d'enregistrement à microcontrôleur (C) agissant comme un serveur depuis un terminal (T) agissant comme un client, le terminal et le support d'enregistrement reposant sur un protocole de transfert de données, le terminal recevant du support d'enregistrement une première réponse (RP1) incluant des premières données (Da) relatives à une application de service (S) implémentée dans le support d'enregistrement et demandée préalablement par le terminal dans une première requête (RQl), le terminal affichant les premières données afin que des deuxièmes données (Db) soient créées en dépendance des premières données et une commande (CC) en relation avec les deuxièmes données soit validée, caractérisé en ce que le support d'enregistrement (ETR) exécute les étapes suivantes.
    en réponse à une deuxième requête (RQ2) transmise (E7, S1, S7) depuis le terminal et incluant les deuxièmes données (Db) et un identificateur de commande (ICb) associé à la commande validée, exécution (E9, S9) par le support d'enregistrement d'une commande correspondant à l'identificateur de commande extrait de la deuxième requête pour modifier des données (Dc) incluses dans le support d'enregistrement en fonction des deuxièmes données (Db) en des données modifiées (Dcm), et création dynamique (E3, E4, S10) d'une deuxième réponse (RP2) incluant les données modifiées (Dcm) , ou un statut sur la commande exécutée, afin de la transmettre au terminal. 3 1
    2 - Procédé conforme à la revendication 1, selon lequel, lorsque le protocole de transfert de données est un protocole de transfert d'hypertexte, les données sont textuelles, les deuxièmes données créées (Db) sont saisies ou sont sélectionnées parmi les premières données, et la commande en relation avec les deuxièmes données est un champ de commande validé (CC).
    3 - Procédé conforme à la revendication 1, selon lequel, lorsque le protocole de transfert de données est un protocole de transfert de fichier, les données sont des identificateurs de fichiers ou des informations de fichier ou des fichiers, et les deuxièmes données créées (Db) sont un identificateur de fichier sélectionné parmi les identificateurs de fichiers, ou des informations de fichier sélectionnées et modifiées ou un fichier sélectionné parmi les fichiers, ou un fichier ou des informations de fichier initialement mémorisé dans le terminal.
    4 - Procédé conforme à l'une quelconque des revendications revendication 1 à 3, comprenant à la réception (S2) d'une requête dans la carte, une identification du protocole de transfert en fonction d'un identificateur de protocole de transfert extrait de la requête afin de traiter la requête selon le protocole de transfert identifié.
    5 - Procédé conforme à l'une quelconque des revendications 1 à 3, comprenant une transmission d'un formulaire de sécurité (FS) par le support d'enregistrement au terminal en réponse à la première requête (RQ1) afin que le terminal retourne une requête comportant un code de sécurité, un identificateur de champ de validation validé et l'identificateur de service pour sécuriser l'administration de l'application identifiée par l'identificateur de servicje.
    6 - Procédé conforme à l'une quelconque des revendications 1 à 5, dans lequel la création dynamique de réponse (RP2) est fondée sur un modèle de formulaire pré-mémorisé dans le support d'enregistrement (C) et invoqué en fonction d'un identificateur de commande (ICb) propre à l'administration de l'application du service, indépendamment du protocole de transfert.
    7 - Procédé conforme à l'une quelconque des revendications 1 à 5, dans lequel la création de dynamique de réponse (RP2) est fondé sur un programme de création de formulaire pré-mémorisé dans le support d'enregistrement et invoqué en fonction d'un identificateur de commande (ICa) propre à l'administration de l'application du service, indépendamment du protocole de transfert.
    8 - Système pour administrer un support d'enregistrement à microcontrôleur (C) agissant comme un serveur depuis un terminal (T) agissant comme un client, le terminal et le support d'enregistrement comportant respectivement un moyen de consultation (ECT) et un moyen de traitement (ETR) reposant sur un protocole de transfert de données, le moyen de consultation recevant du moyen de traitement une première réponse (RP1) incluant des premières données (Da) relatives à une application de service (S) implémentée dans le support d'enregistrement et demandée préalablement par le terminal dans une première requête (RQ1), le terminal affichant les premières données afin que des deuxièmes données (Db) soient créées en dépendance des premières données et une commande (CC) en relation avec les deuxièmes données soit validée, caractérisé en ce que le moyen de traitement (ETR) comprend: un moyen d'administration d'application (MAd) pour exécuter, en réponse à une deuxième requête (RQ2) transmise depuis le terminal et incluant les 1C deuxièmes données (Db) et un identificateur de commande (ICb) associé à la commande validée, une commande correspondant à l'identificateur de commande extrait de la deuxième requête pour modifier des données (Dc) incluses dans le support d'enregistrement en fonction des deuxièmes données (Db) en des données modifiées (Dcm), et un moyen (MP, IAd) pour créer dynamiquement une deuxième réponse (RP2) incluant les données modifiées (Dcm), ou un statut sur la commande exécutée, afin de la transmettre au terminal.
    9 - Système conforme à la revendication 8, dans lequel le support d'enregistrement (C) est connecté à un lecteur de support d'enregistrement (L) relié à un réseau de télécommunications (R) connecté au terminal (T), le lecteur segmente et encapsule chaque requête (RQ) transmise par le terminal dans des commandes (CMD-APDU) transmises au support d'enregistrement, et le support d'enregistrement décapsule les commandes pour recomposer la requête et la traiter.
    - Système conforme à la revendication 8, dans lequel le terminal (T) accueille lui-même le support d'enregistrement (C).
    11 - Système conforme à la revendication 8, dans lequel le support d'enregistrement (C) échange des requêtes (RQ) et des réponses (RP) avec le terminal seulement à travers un réseau de télécommunications (R).
    12 - Support d'enregistrement à microcontrôleur (C) agissant comme un serveur et communiquant avec un terminal (T) agissant comme un client, le terminal et 1C un moyen de traitement (ETR) dans le support d'enregistrement reposant: sur un protocole de transfert de données, le terminal recevant du moyen de traitement une première réponse (RP1) incluant des premières données (Da) relatives à une application de service (S) implémentée dans le support d'enregistrement et demandée préalablement par le terminal dans une première requête (RQ1), le terminal affichant les premières données afin que des deuxièmes données (Db) soient créées en dépendance des premières données et une commande (CC) en relation avec les deuxièmes données soit validée, caractérisé en ce que le moyen de traitement (ETR) comprend: un moyen d'administration d'application (MAd) pour exécuter, en réponse à une deuxième requête (RQ2) transmise (E7, S1, S7) depuis le terminal et incluant les deuxièmes données (Db) et un identificateur de commande (ICb) associé à la commande validée, une commande correspondant à l'identificateur de commande extrait de la deuxième requête pour modifier des données (Do) incluses dans le support d'enregistrement en fonction des deuxièmes données (Db) en des données modifiées (Dcm), et un moyen (MP, IAd) pour créer dynamiquement une deuxième réponse (RP2) incluant les données modifiées (Dcm), ou un statut sur la commande exécutée, afin de la transmettre au terminal.
    13 - Support d'enregistrement à microcontrôleur conforme à la revendication 12, dans lequel le moyen de traitement (ETR) comprend un moyen (MS) pour identifier le protocole de transfert en fonction d'un identificateur de protocole de transfert extrait d'une requête reçue par le support d'enregistrement afin de sélectionner un moyen (MP) dans le support d'enregistrement pour traiter la requête selon le protocole de transfert identifié.
    14 - Support d'enregistrement à microcontrôleur conforme à la revendication 12 ou 13, dans lequel le moyen de traitement (ETR) comprend un moyen de sécurité (MS) pour gérer une couche de sécurité entre le protocole de transfert de données et l'application et garantir la confidentialité et l'intégrité des données échangées entre le support d'enregistrement et le terminal.
FR0501316A 2005-02-09 2005-02-09 Administration d'application de service dans une carte a microcontroleur depuis un terminal Pending FR2881855A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0501316A FR2881855A1 (fr) 2005-02-09 2005-02-09 Administration d'application de service dans une carte a microcontroleur depuis un terminal
PCT/EP2006/050528 WO2006084800A1 (fr) 2005-02-09 2006-01-30 Administration d'application de service dans une carte a microcontroleur depuis un terminal

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0501316A FR2881855A1 (fr) 2005-02-09 2005-02-09 Administration d'application de service dans une carte a microcontroleur depuis un terminal

Publications (1)

Publication Number Publication Date
FR2881855A1 true FR2881855A1 (fr) 2006-08-11

Family

ID=35457265

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0501316A Pending FR2881855A1 (fr) 2005-02-09 2005-02-09 Administration d'application de service dans une carte a microcontroleur depuis un terminal

Country Status (2)

Country Link
FR (1) FR2881855A1 (fr)
WO (1) WO2006084800A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2071467A1 (fr) * 2007-12-13 2009-06-17 Gemplus Procédé de personnalisation de politique de gestion de la durée de vie d'une mémoire dans un jeton électronique

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102622547A (zh) * 2012-03-13 2012-08-01 上海华御信息技术有限公司 一种基于key的服务器数据读取方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2805059A1 (fr) * 2000-02-10 2001-08-17 Bull Cp8 Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit "applet"

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2805059A1 (fr) * 2000-02-10 2001-08-17 Bull Cp8 Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit "applet"

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2071467A1 (fr) * 2007-12-13 2009-06-17 Gemplus Procédé de personnalisation de politique de gestion de la durée de vie d'une mémoire dans un jeton électronique
WO2009074515A1 (fr) * 2007-12-13 2009-06-18 Gemalto Sa Méthode de personnalisation de la politique de gestion de la durée de vie de la mémoire d'un jeton électronique
US8281088B2 (en) 2007-12-13 2012-10-02 Gemalto Sa Method of customizing a memory lifespan management policy in an electronic token

Also Published As

Publication number Publication date
WO2006084800A1 (fr) 2006-08-17

Similar Documents

Publication Publication Date Title
JP3794926B2 (ja) スマートカードと協働する「ｗｅｂ」タイプのブラウザを用いたオブジェクトへのアクセスシステム
EP1142256B1 (fr) Terminal securise muni d'un lecteur de carte a puce destine a communiquer avec un serveur via un reseau de type internet
KR100886137B1 (ko) 스마트카드에 소프트웨어 콤포넌트, 특히 애플릿을로딩하는 방법
TW567700B (en) Method of registration a user on a directory server of an internet type network and/or of localization of a user on this network, and chip card for using such method
US9497620B2 (en) Method and system for implementing smart card remote operation based on smart card web server
JP3913984B2 (ja) ネットワークインターフェース手段を備えたオンボードシステム、およびこのオンボードシステムに配置されるアプリケーションの作動方法
JP2003522361A (ja) サーバとチップカード端末との間のインターネット型ネットワーク上での高速データストリーム特にマルチメディアデータストリームの送信方法
WO1998057474A1 (fr) Carte a puce, telephone sans fil, systeme et procede d'acces et de communication par internet
EP1498856A2 (fr) Procédé de communication entre une station d'utilisateur et un réseau, notamment du type internet, et architecture de mise en oeuvre
US20080010456A1 (en) Communication between a smart card and a server
Kumar et al. WAP: present and future
WO2008006811A1 (fr) Serveur de gestion de donnees confidentielles anonymes
FR2881855A1 (fr) Administration d'application de service dans une carte a microcontroleur depuis un terminal
EP1566068B1 (fr) Chargement d'une application a deployer dans un terminal et une carte a puce
EP1190398A1 (fr) Preparation et execution d'un programme dans une carte a puce additionnelle d'un terminal
EP1127339B1 (fr) Systemes d'organisation de carte a puce en vue de son utilisation en tant que serveur dans un reseau du type internet
Kilian-Kehr Mobile Security with Smartcards
FR2812486A1 (fr) Securisation de session avec un moyen de traitement de donnees sous la commande de entites
EP1894407B1 (fr) Procede et dispositif de securite pour la gestion d'acces a des contenus multimedias
Guthery et al. The WebSIM− Clever Smartcards Listen to Port 80
FR2924295A1 (fr) Procede de traitement de requetes http par un serveur web heberge dans un dispositif electronique portable