FR2805059A1 - Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit "applet" - Google Patents

Abstract

L'invention concerne le chargement d'une " applet " dans une carte à puce (2a), à l'aide de deux programmes de chargement, dits "In-loader" (IL), stocké dans la carte, et " Off-loader " (OL), respectivement. Selon l'invention, on prévoit deux couches protocolaires de communication spécifiques, l'une dans un terminal (1) hébergeant le lecteur de la carte, l'autre dans la carte. Ces couches comprennent notamment des agents intelligents permettant à la carte d'offrir une fonctionnalité de client/serveur " WEB " et de passerelle "CGI". Le procédé comprend au moins une étape pendant laquelle une requête "HTTP " est envoyée à la carte, pour adresser une page " HTML ", une étape de récupération de données de paramétrage véhiculées par un formulaire " HTML " et une étape d'exécution du second programme de chargement (IL), par mise en oeuvre de la fonctionnalité " CGI ", pour charger l'"applet "

Description

L'invention concerne un procédé de chargement d'une pièce de logiciel dans une carte à puce.

Elle s'applique plus particulièrement au chargement d'une pièce de logiciel appelée en français "appliquette", plus connue sous le terme anglo- saxon d' "applet". II s'agit d'une application écrite en langage "JAVA" (marque déposée). Ces applications, généralement peu volumineuses, sont indépendantes des architectures des systèmes sur lesquelles elles sont implantées. Elles peuvent donc fonctionner sur n'importe quel système informatique, dans la mesure où celui-ci implémente le concept dit de "machine virtuelle JAVA" ("Java Virtual Machine"). Une application écrite en langage JAVA est en général traduite en un langage intermédiaire dit "Byte Code". La machine virtuelle JAVA précitée constitue un interprétateur de ce "Byte Code", de manière à être exécutée directement sur un système cible hôte de ladite machine virtuelle.

Généralement, les architectures de système sur lesquelles tourne ce type d'applications sont du type dit client-serveur. Dans ce cas, on parle également de "servlet" pour une application stockée sur un système serveur et "applet" pour une application stockée sur un système client. Dans ce qui suit, on utilisera le terme "applet" de façon générique.

Des pièces de logiciel, se présentant sous la forme d' "applet" qui vient d'être rappelée, dans la mesure où la quantité de code n'est pas trop volumineuse, peuvent être stockées dans une mémoire non volatile présente sur une carte à puce, au même titre que toute autre application.

Aussi, le procédé selon l'invention est plus particulièrement concerné par un terminal ou station d'utilisateur muni d'un lecteur de carte à "puce".

Dans le cadre de l'invention, le terme "terminal" doit être compris dans un sens général. Le terminal précité peut être notamment constitué par un ordinateur personnel fonctionnant sous divers systèmes d'exploitation, tels WINDOWS ou UNIX (tous deux étant des marques déposées). peut être aussi constitué par une station de travail, un ordinateur portable un terminal de carte dit dédié. Dans l'état actuel de la technique, le chargement d'une "applet" sur une carte à puce (encore appelé téléchargement) se fait grâce à deux programmes spécifiques. Ces programmes sont généralement connus sous les termes anglo- saxons "Off-Loader", pour le premier, et "In-Loader", pour le second. Le programme "Off-Loader" s'exécute sur le terminal et le programme "In-Loader" s'exécute dans la carte à puce. Les programmes de chargement "Off-Loader" "In-Loader" communiquent entre eux au travers d'une liaison normalisée de type ISO 7816-3, protocole universellement retenu pour les communications entre une carte à puce et son terminal hôte. Ce protocole met en oeuvre une suite d'échanges généralement propriétaires (commandes d'un type dit "APDU" seront explicitées ci-après) afin de réaliser le chargement d'une "applet".

La figure 1A annexée à la présente description illustre de façon schématique l'architecture mise en ceuvre pour le chargement d' "applets" dans une carte à puce selon l'art connu.

Le terminal 1 stocke un premier programme spécifique de chargement ("Off-Loader"), référencé OL. II communique avec une carte à puce 2, via lecteur de carte à puce 3. Les transmissions s'effectuent selon un protocole de communication normalisé, faisant appel aux commandes précitées, protocole qui sera détaillé ci-après, La carte à puce 2, pour sa part stocke un second programme spécifique de chargement ("In-Loader"), référencé IL.

Un premier inconvénient de ce procédé est que les programmes IL et OL doivent être appariés pour pouvoir communiquer entre eux.<B>Il</B> s'ensuit que s'ils sont d'origines différentes, ils ne sont pas,<I>a</I> priori, compatibles. Cette caractéristique est liée au jeu de commandes à utiliser.

Un deuxième inconvénient est dû au fait que les communications s'effectuent selon le protocole ISO 7816 précité. En effet, celui-ci impose une proximité physique entre les programmes OL et IL. II s'ensuit que le programme OL doit généralement s'exécuter directement sur le terminal 1 et non, par exemple, sur un autre terminal ou un serveur éloigné.

Or, avec l'essor spectaculaire du réseau Internet, un nombre toujours croissant de terminaux sont connectés à ce réseau, notamment pour pouvoir être en liaison avec des serveurs éloignés, de type "WEB". II serait donc intéressant, par exemple, de pouvoir stocker la partie "Off-Loader" OL des programmes de chargement d' "applets" sur un serveur "WEB" connecté à ce réseau. "applets" à charger sur une ou plusieurs carte(s) à puce pourraient d'ailleurs etre aussi stockées sur ce serveur ou sur un ou plusieurs autres serveurs ce type.

Dans l'état actuel de la technique, ce mode opératoire bute sur une double impossibilité. La première a déjà été évoquée : la norme retenue pour les communications entre le terminal et la carte à puce impose<I>a</I> priori une proximité physique entre la localisation des programmes "Off-Loader", et "In- Loader", D'autre part, les transmissions entre deux systèmes, par exemple un terminal un serveur éloigné, via le réseau Internet, font appel à des protocoles type Internet. Dans l'état actuel de la technique, est pas possible realiser des communications directes entre une carte puce et le réseau Internet, comme il va l'être explicité également.

Dans le cadre de l'invention, le terme "réseau Internet" englobe, outre le réseau Internet proprement dit, les réseaux privés d'entreprises similaires, du type dit intranet", et les réseaux les prolongeant vers l'extérieur, type dit "extranet", de façon générale tout réseau dans lequel les échanges de données s'effectuent selon un protocole du type Internet. Dans ce suit un tel réseau sera appelé de façon générique "réseau Internet".

tout d'abord rappeler brièvement l'architecture genérale d'un système d'application à base de carte à puce, relié à un réseau Internet, par référence figures 1 B et 1 C.

système d'application à base de carte à puce comporte généralement les éléments principaux suivants une carte à puce<B>;</B> un système hôte constituant le terminal précité ; un réseau de communication, à savoir le réseau Internet dans l'application préférée ; et un serveur d'application connecté au réseau Internet. La figure 1 B illustre schématiquement un exemple d'architecture de ce type. Le terminal 1, par exemple un ordinateur individuel, comporte un lecteur 3 carte à puce 2. Ce lecteur 3 peut être ou non physiquement intégré dans le terminal 1. La carte à puce 2 comporte un circuit intégré 20 dont des connexions d'entrées-sorties affleurent en surface de son support pour autoriser une alimentation en énergie électrique et ries communications avec le terminal . Ce dernier comprend des circuits d'accès 11 au réseau Internet RI. Ces circuits peuvent être constitués par un modem pour se connecter à une ligne teléphonique commutée ou à une voie de communication à plus haut debit réseau numérique à intégration de services ("RNIS"), câble ou liaisons par satellite, etc. Les circuits 11 permettent de se connecter au réseau Internet RI, directement ou via un prestataire de services Internet ("Internet Service Provider" ou "ISP", selon la terminologie anglo-saxonne). On peut également avoir recours à un système intermédiaire tel qu'un "proxy" ou un système d'isolation dit "firewall" ("pare-feu" ou encore appelé "garde barrière").

Le terminal 1 comprend naturellement tous les circuits et organes nécessaires à son bon fonctionnement, et qui n'ont pas été représentés dans un de simplification du dessin :.unité centrale, mémoires vive et fixe, mémoire masse à disque magnétique, lecteur de disquette et/ou de CédéRom, Habituellement, le terminal 1 est aussi relié à des péripheriques classiques, intégrés ou non, tels un écran de visualisation 5, un clavier 6a et une souris 66, etc.

Le terminal 1 peut être mis en communication avec des serveurs ou tous systèmes informatiques connectés au réseau RI, dont un seul, 4, est illustré sur la figure 1A. Les circuits d'accès 11 mettent le terminal 1 en communication avec les serveurs 4 grâce à un logiciel particulier 10, appelé navigateur "WEB", ou "browser" selon la terminologie anglo-saxonne. Celui-ci permet d'accéder à diverses applications ou fichiers de données répartis sur l'ensemble du réseau RI, généralement selon un mode "client-serveur".

Habituellement, les communications sur les réseaux s'effectuent conformément à des protocoles répondant à des standards comprenant plusieurs couches logicielles superposées. Dans le cas d'un réseau RI type Internet, les communications s'effectuent selon des protocoles spécifiques à ce type de communications, qui seront détaillés ci-après, mais qui comprennent également plusieurs couches logicielles. Le protocole de communication choisi en fonction de l'application plus particulièrement visée : interrogation pages "WEB", transferts de fichiers, courrier électronique (e-mel, ou "e-mail" selon la terminologie anglo-saxonne), forums ou "news", etc.

L'architecture logique du système comprenant un terminal, un lecteur de carte à puce et une carte à puce, est représentée schématiquement par figure<B>1C.</B> Elle est décrite par la norme ISO 7816, qui elle-même comportent plusieurs sous-ensembles - ISO 7816-1 et 7816-2, en ce qui concerne les dimensions et marquage des cartes<B>;</B> - ISO 7816-3, en ce qui concerne le transfert de données entre terminal et la carte à puce ; et - ISO 7816-4, en ce qui concerne la structure du jeu d'ordres et format des commandes.

Sur la figure 1 C, du côté terminal 1, on n'a représenté que les couches répondant à la norme ISO 7816-3, référencées 101, et un gestionnaire d'ordres "APDU" (norme ISO 7816-4), référencé 102. Du côté carte à puce 2, couches répondant à la norme ISO 7816-3 sont référencées 200 et gestionnaire d'ordres "ADPU" (norme ISO 7816-4) est référencé 201. applications sont référencées A1, ..., A;,<I>..., An ;</I> n étant le nombre maximum d'applications présentes sur la carte à puce 2.

Une application, Al, présente dans la carte à puce 2, dialogue avec terminal 1 au moyen d'un jeu d'ordres. Ce jeu présente typiquement des ordres d'écriture et des ordres de lecture. Le format des ordres est connu sous l'abréviation anglo-saxonne de "APDU" (pour "Application Protocol Data Unit"). est défini par la norme ISO 7816-4 précitée. Une "APDU" de commande notée "APDU.command' et une "APDU" de réponse est notee "APDU.response". Les "APDU" sont échangées entre le lecteur de carte et carte à puce au moyen d'un protocole spécifié par la norme ISO 7816-3 précitee (par exemple en mode caractère: T=0 ; ou en mode bloc: T=1). Lorsque la carte à puce 2 inclut plusieurs applications distinctes, comme illustré sur la figure<B>1C,</B> on parle de carte multi-applicative. Cependant, le terminal 1 ne dialogue qu'avec une seule application à la fois. Une application <I>Ai</I> se présente, par exemple, sous la forme d'une "applet" qui peut être enregistrée initialement, ou encore chargée à partir du terminal 1. Pour ce faire, comme illustré par la figure 1A, on a recours à un programme "Off-Loader", OL, enregistré dans le terminal 1 et à un programme "In-Loader", IL, qui forme l'une des applications Ai de la carte à puce 2.

La sélection d'une application particulière Ai est obtenue à l'aide d'une "APDU" du type sélection ("SELECT"). Une fois ce choix effectué, les "APDU" qui le suivent sont acheminés vers cette application. "APDU SELECT" nouvelle a pour effet d'abandonner l'application en cours d'en choisir une autre. Le sous-ensemble logiciel gestionnaire des "APDU" permet de choisir une application particulière Ai dans la carte à puce 2, de memoriser l'application ainsi choisie, et de transmettre et/ou recevoir des "APDU" vers et depuis cette application.

En résumé de ce qui vient d'être décrit, la sélection d'une application Ai et le dialogue avec celle-ci s'effectuent par échanges d'ordres "APDU". On suppose que les applications Ai sont des applications conventionnelles, que l'on appellera ci-après "GCA" (pour "Generic Card Application" ou application de carte génerique).

mode opératoire explique que les programmes et IL doivent être appariés, pour que les ordres "APDU" échangés puissent etre compatibles et compris ces deux applications.

rappels étant effectués, il est à noter que la carte à puce 2 ne peut communiquer directement avec les navigateurs standards commerce, sauf à modifier de ces derniers.

outre, et surtout, les cartes à puce actuelles, par ailleurs sont conformes aux standards et normes rappelés ci-dessus, une configuration matérielle logicielle qui ne permet pas non plus de communiquer directement avec le reseau Internet. En particulier, elles ne peuvent recevoir et transmettre des paquets de données, selon l'un ou l'autre des protocoles utilisés sur ce type de réseau. II est donc nécessaire de prévoir une pièce de logiciel additionnelle, implantée dans le terminal 1, généralement sous la forme de ce qui est appelé un "plug-in", selon la terminologie anglo-saxonne. Cette pièce de logiciel, qui porte la référence 12 sur la figure 1 B, effectue l'interface entre 1e navigateur 10 et la carte 2, plus précisément les circuits électroniques 20 de cette carte 2.

L'invention vise à pallier les inconvénients des procedés et dispositifs de l'art connu, et dont certains viennent d'être rappelés, tout répondant aux besoins qui se font sentir.

Selon une première caractéristique de l'invention, les deux programmes de chargement, OL et IL ne sont plus dépendants l'un de l'autre. En d'autres termes, ils n'ont plus à être appariés pour être compatibles.

Selon une deuxième caractéristique de l'invention, la partie OL des programmes de chargement n'a plus à être stockée obligatoirement dans le terminal, c'est-à-dire en relation de proximité physique avec la seconde partie IL. Tout au contraire, le programme OL peut être stocké sur un serveur éloigné, connecté au terminal via un réseau de type Internet.

Pour ce faire, et selon une autre caractéristique de l'invention, la carte à puce se comporte comme un serveur/client de type "WEB" pour le terminal qui lui est associé.

Pour atteindre ce but, on prévoit une couche de logiciel de communication spécifique dans la carte à puce et son pendant dans le terminal. Le terme "spécifique" doit être entendu comme spécifique au procédé de l'invention. En effet, ces couches de communications, dites spécifiques, sont banalisées quelle que soit l'application considérée. Elles n'interviennent que dans le processus d'échanges de données bidirectionnels entre la carte à puce et le terminal, d'une part, et la carte à puce et le réseau, d'autre part.

Les couches logicielles de communication spécifiques comprennent notamment des composants logiciels, dits "agents intelligents", permettant en particulier des conversions de protocoles. Les agents intelligents seront appelés ci-après plus simplement "agents". II existe des agents appareillés dans les couches de communication spécifiques respectives associées au terminal et à la à puce. Selon le procédé de l'invention, il s'établit des sessions entre agents appareillés.

Selon une autre caractéristique, le procédé de l'invention rend possible l'activation d'applications de type conventionnel, c'est-à-dire du type "CGA" precité, localisées dans une carte à puce, sans devoir les modifier en quoi soit. Pour ce faire, on prévoit un ou plusieurs agents intelligents particuliers dits traducteurs de script, qui reçoivent des requêtes d'un navigateur et traduisent en ordres "APDU" compréhensibles par l'application de type "CGA".

ce fait, on implante dans la carte à puce une fonction similaire à celle connue par ailleurs sous la dénomination "CGI" dans les serveurs "WEB" classiques. Cette fonction permet de mettre en oeuvre une application dans à puce par un protocole Internet de type "HTTP".

Le chargement d'une "applet" dans la carte à puce peut s'effectuer cette interface "CGI". La partie IL du programme de chargement est considere comme étant un script de commandes, que l'on appellera "cgi-script", attache a fonctionnalité serveur "WEB" offerte par la carte à puce. Les échanges entre programmes OL et IL peuvent se dérouler avec l'aide de formulaires classiques en langage "HTML" ou "forms" selon la terminologie anglo-saxonne.

Tout en conservant les normes ISO précitées pour les communications entre terminal et carte à puce, via le lecteur de carte à puce, le procédé selon l'invention permet des échanges entre les parties de programmes chargement OL et IL en faisant appel au protocole de communication Internet "TCPIIP", la partie OL et les "applets" à charger pouvant être stockées en local dans un serveur éloigné.

L'invention a donc pour objet principal un procédé de chargement d'une pièce de logiciel dans une carte à puce à partir d'un terminal connecté à ladite carte à puce par l'intermédiaire d'un lecteur de carte à puce permettant communications selon un premier protocole déterminé, ledit chargement effectuant par la mise en ceuvre et la coopération de premier et second programmes de chargement, ledit second programme de chargement étant stocké dans ladite carte à puce, caractérisé en ce qu'il comprend au moins les phases suivantes une première phase préliminaire consistant à implanter, dans ladite à puce, une première pièce de logiciel, formant une couche protocolaire de communication spécifique; une deuxième phase préliminaire consistant à implanter, dans ledit terminal, une seconde pièce de logiciel, formant une couche protocolaire communication spécifique; ce que lesdites première et seconde pièces de logiciel comprennent en outre moins une paire de premières entités logicielles appariées, chacune desdites entités coopérant l'une avec l'autre de manière à permettre l'établissement d'une session d'échanges de données bidirectionnels entre au moins ledit terminal et ladite carte à puce, de manière à ce que ladite à puce offre la fonctionnalité d'un client/serveur "WEB" ; ce qu'il comprend une troisième phase préliminaire consistant à implanter dans ladite carte à puce au moins une deuxième entité logicielle, apte à interpréter une suite d'instructions et à la traduire en une suite d'ordres, maniere à coopérer avec ladite seconde pièce de logiciel spécifique pour ladite carte à puce offre une fonctionnalité d'interface passerelle dite "CGI", dite carte à puce comprenant au moins une desdites suites d'instructions associée au dit second programme de chargement; en ce qu'il comprend au moins les étapes suivantes ouverture d'une première session d'échanges de données entre au moins ledit terminal et ladite carte à puce, pour la transmission d'une requête pour que ledit premier programme de chargement récupère des données de paramétrage de chargement fournies par ledit second programme de chargement; 21 ouverture d'une deuxième session d'échanges de données entre ladite carte à puce et au moins ledit terminal pour transmettre lesdites données de paramétrage de chargement au dit premier programme de chargement, lesdites données de paramétrage comportant une référence aux dites instructions associées au dit second programme de chargement ; et <B>31</B> ouverture d'une troisième session d'échanges de données entre au moins ledit terminal et ladite carte à puce, pour la soumission d'un fichier de chargement prenant en compte lesdites données de paramétrage de chargement, ledit fichier comprenant des données représentant ladite pièce de logiciel à charger; interprétation de ladite suite d'instructions associée au dit second programme de chargement, par mise en ceuvre de ladite fonctionnalité "CGI", de manière générer une suite d'ordres transmise au dit second programme de chargement, à exécuter ce programme et à obtenir ledit déchargement de ladite pièce de logiciel.

L'invention va maintenant être décrite de façon plus détaillée en se référant aux dessins annexés, parmi lesquels - la figure 1A illustre schématiquement un exemple de réalisation d'une architecture permettant le chargement d'une "applet" dans une carte à puce selon l'art connu ; - figures 1 B et 1 C illustrent les architectures matérielle et logique, respectivement, d'un exemple de système d'application à base de à puce connecté à un réseau Internet selon l'art connu, ; - figure 2 illustre schématiquement un exemple de systeme d'application à base de carte à puce selon l'invention, cette dernière agissant en tant que client/serveur "WEB" ; - figure 3 est un diagramme d'états d'une session entre entités logicielles dites agents intelligents, selon un aspect l'invention ; - figure 4 illustre de façon simplifiée l'architecture logique système selon l'invention dans lequel la carte à puce comprend agents intelligents ; - figure 5 illustre de façon simplifiée l'architecture logique système selon l'invention dans lesquels la carte à puce comprend agents intelligents traducteurs de scripts ; - la figure 6 illustre schématiquement un exemple de réalisation d'une architecture permettant le chargement d'une "applet" dans carte à puce selon l'invention ; - la figure 7 illustre la structure d'un fichier de chargement d'une "applet" pouvant être en #uvre par le procédé selon l'invention ; - la figure 8 illustre schématiquement les phases principales procédé de chargement d'une "applet" dans une carte à puce selon premier exemple de réalisation pratique ; - la figure 9 illustre schématiquement les phases principales procédé de chargement d'une "applet" dans une carte à puce selon deuxième exemple de réalisation pratique; - les figures 9 et 10 illustrent deux exemples de formulaires en langage "HTML" utilisables par le procédé de chargement d'une "applet" dans une carte à puce selon l'invention, pour la mise en ceuvre des méthodes dites "GET" et "POST", respectivement; et - les figures 12A à 12G illustrent plusieurs variantes de réalisation de réalisation d'architectures de systèmes permettant le chargement d'une "applet" dans une carte à puce selon l'invention.

Dans ce qui suit, sans en limiter en quoi que ce soit la portée, on se placera ci-après dans le cadre de l'application préférée de l'invention, sauf mention contraire, c'est-à-dire dans le cas d'un terminal connecté à un ou plusieurs serveurs éloignés via le réseau Internet.

Avant de décrire le procédé d'activation d'applications localisées dans une carte à puce selon l'invention et de détailler une architecture pour sa mise en oeuvre, par référence à la figure 2, il apparaît tout d'abord utile de rappeler brièvement les caractéristiques principales des protocoles de communication sur les réseaux.

L'architecture des réseaux de communication est décrite par diverses couches. A titre d'exemple, le standard "0S1" ("Open System Interconnection"), défini par l' "1S0", comporte sept couches qui vont des couches dites basses (par exemple la couche dite "physique" qui concerne le support de transmission physique) aux couches dites hautes (par exemple la couche dite "d'application"), en passant par des couches intermédiaires, notamment la couche dite de "transport". Une couche donnée offre ses services à la couche qui lui est immédiatement supérieure et requiert de la couche qui lui immédiatement inferieure d'autres services, via des interfaces appropriées. Les couches communiquent à l'aide de primitives. Elles peuvent également communiquer avec des couches de même niveau. Dans certaines architectures, plusieurs couches peuvent être inexistantes.

Dans un environnement de type Internet, les couches sont au nombre de cinq, et de façon plus précise, en allant de la couche supérieure à couche inferieure : la couche dite d'application ("http", "ftp", "e-mail", etc.), couche dite de transport ("TCP"), la couche dite d'adressage de réseau ("1P"), couche dite de liens de données ("PPP", "Slip", etc.) et la couche dite physique.

Si on se reporte de nouveau à la figure 2, à l'exception couches logicielles de protocole de communication spécifiques, référencées et 23a, respectivement implantées dans le terminal 1 et la carte à puce 2a, les autres éléments, matériels ou logiciels, sont communs à l'art connu, et il n'y a pas lieu de re-décrire de façon détaillée.

Le terminal 1 comprend des circuits 11 d'accès au réseau RI, constitués exemple d'un modem. Ces circuits regroupent les couches logicielles inferieures, C1 et C2, qui correspondent aux couches "physique" et de "lien de données".

On a également représenté les couches supérieures, C3 C4, qui correspondent aux couches "d'adressage de réseau" ("1P", dans le cas d'Internet) et de "transport" ("TCP"). La couche supérieure d'application ("http", "e-mail", etc.) n'a pas été représentée.

L'interface entre les couches inférieures, C1 et C2, et couches superieures, C3 et C4, est constituée par une couche logicielle généralement appelée "driver couches basses". Les couches supérieures, C3 et C4, s'appuient sur cette interface et sont mises en oeuvre par l'intermédiaire de bibliothèques de fonctions spécifiques ou bibliothèques réseau 14, avec lesquelles elles correspondent. Dans le cas du réseau Internet, "TCPIIP" est mis en ceuvre au moyen de bibliothèques dites de "sockets". Cette organisation permet à un navigateur 10 de poser des requêtes vers un serveur 4, pour la consultation de pages "WEB" (protocole "HTTP"), pour le transfert de fichiers (protocole "FTP") ou l'envoi de courrier électronique (protocole "e-mail"), ce de façon tout à fait classique en soi.

Le terminal 1 comprend également un lecteur de carte 3, intégré ou non. Pour communiquer avec la carte à puce 2a, le lecteur de carte 30 englobe également deux couches basses, CC1 (couche physique) et (couche de lien de données), jouant un rôle similaire aux couches C1 et Les interfaces logicielles avec les couches CC1 et CC2 sont décrites, exemple, par la spécification "PC/SC" ("part 6, service provider"). Les couches elles-mêmes, CC1 et sont notamment décrites par les normes ISO 7816-1 à7816-4, comme il a eté rappelé.

Une couche logicielle supplémentaire 16 forme interface entre les couches applicatives (non représentées) et les couches inférieures, CC1 et CC2. La fonction principale dévolue à cette couche 16 est une fonction de multiplexageldémultiplexage.

Les communications avec la carte à puce 2a s'effectuent selon un paradigme similaire à celui utilisé pour la manipulation de fichiers dans un système d'exploitation du type "UNIX" (marque déposée) : OUVRIR ("OPEN"), LIRE ("READ"), ECRIRE ("WRITE"), FERMER ("CLOSE"), etc.

Du côté de la carte à puce 2a, on retrouve une organisation similaire, à savoir la présence de deux couches basses, référencées CCa1 (couche physique) et CCa2 (couche de lien de données), ainsi qu'une couche d'interface 26a, tout à fait similaire à la couche 16.

Selon une première caractéristique de l'invention, on prévoit, de part et d'autre, c' -à-dire dans le terminal 1 et dans la carte à puce 2a, deux couches de protocoles spécifiques : 13 et 23a, respectivement.

Dans le terminal 1, la couche spécifique 13 s'interface aux "drivers couches basses" 15, aux bibliothèques 14 des couches réseau, C3 et C4, et aux couches protocolaires du lecteur de carte 3, c'est-à-dire les couches inférieures, CC1 et via la couche de multiplexage 16. La couche spécifique 13 permet le transfert de paquets réseaux de et vers la carte à puce 2a. En outre elle adapte les applications existantes telles le navigateur Internet 10, le courrier électronique, etc., pour des utilisations mettant en ceuvre la carte à puce Du côté de la carte à puce 2a, on retrouve une organisation tout ' fait similaire constituée par une instance supplémentaire de la couche spécifique, référencée 23a, pendant de la couche 13.

De façon plus précise, les couches spécifiques, 13 et 23a, sont subdivisées en trois éléments logiciels principaux - un module, 130 ou 230a, de transfert de blocs d'informations entre les couches 13 et 23a, via les couches conventionnelles CC1, CC2, CCal et CCa2 ; - une ou plusieurs pièces de logiciel, dites "agents intelligents", 132 ou 232a, qui réalisent, par exemple, des fonctions de conversion de protocoles ; - et un module de gestion de la configuration spécifique, 131 et 231a, respectivement ; module qui peut être assimilé à un agent intelligent particulier.

Pour simplifier, on appellera ci-après les agents intelligents, "agents", comme il a été précédemment indiqué.

On retrouve donc, dans le terminal 1 et la carte à puce 2a, une pile protocolaire de communication entre les deux entités.

Les couches de niveau deux (couches de lien de données), CC2 et CCa2, assurent l'échange entre la carte à puce 2a et le terminal 1. Ces couches sont responsables de la détection et l'éventuelle correction d'erreurs de transmission. Différents protocoles sont utilisables, et à titre d'exemples non exhaustifs les suivants - la recommandation ETSI GSM 11.11 ; - le protocole défini par la norme ISO 7816-3, en mode caractère T=0 ; - le protocole défini par la norme ISO 7816-3, en mode bloc T=1 ; - ou le protocole défini par la norme ISO 3309, en mode trame "HDLC" (pour "High-Level Data Link Control procedure" ou procédure de commande de liaison à haut niveau). Dans le cadre de l'invention, on utilisera de préférence protocole ISO 7816-3, en mode bloc.

De façon connue en soi, à chaque couche de protocole, il associé un certain nombre de primitives qui permettent les échanges de donnees entre couches de même niveau et d'une couche à l'autre. A titre d'exemple, les primitives associées à la couche de niveau deux sont du type "demande de données"<I>("Data.</I> requesY') et "envoi de données" par la carte <I>("Data.</I> response"), ainsi que "confirmation de données"<I>("Data.</I> confirm"), etc.

De façon plus spécifique, les couches 13 et 23a sont chargées du dialogue entre la carte à puce 2a et l'hôte, c'est-à-dire le terminal 1. Ces couches permettent l'échange d'informations entre un utilisateur (non représenté) terminal 1 et la carte à puce 2a, par exemple via menus déroulants sous la forme d'hypertexte au format "HTML". Elles permettent aussi la mise en place d'une configuration adaptée pour l'émission et/ou reception de paquets données.

Comme il a été indiqué ci-dessus, les couches comprennent trois entités distinctes.

La première couche, 130 ou 230a, est essentiellement constituée par un multiplexeur logiciel. Elle permet l'échange d'informations entre la carte à puce 2a et terminal hôte 1, sous la forme d'unités de données protocole. Elle joue un rote similaire à celui d'un commutateur de paquets de donnees. Ces unités sont émises ou reçues via la couche de niveau deux (couche liens de données). protocole particulier de communication permet mettre en communications au moins une paire d' "agents". Le premier agent chaque paire, 132, situé dans la couche 13, côté terminal 1, le second, 232a, est situé dans couche 23a, côté carte à puce 2a. Une liaison entre deux "agents" est associée à une session, que l'on pourra appeler "S-Agent'. session est un échange données bidirectionnel entre ces deux agents. l'une ou l'autre des couches, 3 et 23a, comporte plusieurs agents, les agents d'une même couche peuvent aussi établir de sessions entre eux et/ou avec modules 131 et 231a, qui constituent des agents particuliers. De façon plus précise, un agent est une entité logicielle autonome qui peut réaliser tout ou partie de fonctions des couches de niveau trois et quatre, en fonction de la configuration mise en oeuvre par le terminal 1.

Les agents sont associés à des propriétés ou attributs particuliers. Pour fixer les idées, et à titre d'exemple non limitatif, les six propriétés suivantes sont associées aux agents - "hôte" : agent localisé dans le terminal ; - "carte" : agent localisé dans la carte à puce ; - "local": agent ne communiquant pas avec le réseau ; - "réseau" : agent communiquant avec le réseau (côte terminal) ; - "client" : agent qui initialise une session ; - "serveur" : agent qui reçoit une demande de session.

Un agent particulier est identifié par une référence, exemple un nombre entier de 16 bits (c'est-à-dire compris entre 0 et 65535). bit de poids fort (b15 = ) indique si la référence est locale (communications locales à la carte à puce ou au terminal) ou distante (b15 = 0).

II existe deux grandes catégories d'agents : les agents de type "serveur", sont identifiés par une référence fixe, et les agents de type "client", sont identifiés par une référence variable, que peut qualifier d'éphémere, délivrée par le module de gestion de configuration, ou 231 a.

agents communiquent entre eux à l'aide d'entité dites "unités de donnée protocole" ou "pdu" (pour "protocol data unit", selon terminologie anglo-saxonne) constituant une référence de destination et une référence de source. pourrait également appeler cette "pdu" particulière "SmartTP pdu", en référence au terme anglais "Smart Card" (carte à puce) couramment utilisé. Les " utilisent notamment les références définies ci-dessus.

"SmartTP pdu", ou plus simplement "pdu" ci-après, comporte une référence source, une référence de destination, un ensemble de bits constituant des drapeaux ou "Tags" qui précisent la nature de la "pdu", et des données optionnelles - le drapeau<I>"OPEN'</I> (ouvert) est positionné pour indiquer l'ouverture d'une session ; - le drapeau "CLOSE" (fermé) indique la fermeture d'une session ; et - Le drapeau "BLOCK" (verrouillé) indique que l'agent est en attente d'une réponse de son correspondant et suspend toute activité.

On appellera jeton une "pdu" qui ne comporte pas de données.

L'entité "SmartTP' contrôle l'existence de l'agent destinataire et réalise la commutation d'un paquet vers ce dernier.

Une session agent "S-Agent" possède trois états remarquables, savoir - un état déconnecté : aucune session n'est ouverte avec un autre agent - un état connecté : une session est ouverte avec un autre agent, une session "S-Agent" étant identifiée par une paire de références ; et - un état bloqué, l'agent étant connecté et attendant une réponse de correspondant.

Le mécanisme d'établissement d'une session "S-Agent" est le suivant - une nouvelle instance d'un agent client est créée (côté carte à puce terminal), cet agent étant identifié par une référence éphémère pseudo unique ; - l'agent client émet une "pdu" à destination d'un agent serveur (dont la référence est connue par ailleurs) avec le drapeau<I>"OPEN'</I> positionné et l'agent client passe à l'état connecté ou bloqué selon la valeur du drapeau "BLOCK'; et - l'agent serveur reçoit la "pdu" avec le drapeau "OPEN' et passe à l'état connecté Une fois une session ouverte, deux agents échangent des données via des "pdu".

Le mécanisme de fermeture d'une session est le suivant - un agent émet une "pdu" avec le drapeau "CLOSE" positionné (et qui comporte éventuellement des données ; et - l'autre agent reçoit une "pdu" avec le drapeau "CLOSE" positionné qui comporte éventuellement des données) et la session "S-Agent" passe a l'état déconnecté. La figure 3 illustre de façon schématique le diagramme d'états des sessions "S-Agent', telles qu'elles viennent d'être rappelées.

couches 130 et 230a gèrent des tables (non representées) qui contiennent la liste des agents présents, côté terminal hôte 1 et à puce 2a. façon pratique, les agents permettent d'échanger données (de l'hypertexte, par exemple), mais également de déclencher transactions réseau, autorisant des communications entre la carte à puce et un serveur éloigné (figure 2).

modules de gestion de configuration, 131 et 231 a, respectivement, sont assimilables à des agents particuliers. Par exemple, le module 131, côté terminal hote 1, gère notamment des informations relatives à la configuration de ce terminal (modes de fonctionnement), liste des autres agents présents, etc. Le module côté carte à puce 2a, a des fonctions analogues. Ces deux agents peuvent etre ' en communication l'un avec l'autre pour établir une session.

façon pratique, la carte à puce 2a est avantageusement "adressée" par utilisation d'une adresse "URL" (pour "Universal Resource Locator") définissant rebouclage sur le terminal 1 lui-même, et non un pointage sur un serveur externe. A titre d'exemple, la structure de cette "URL" est habituellement la suivante http:/1127.0.0.1:8080 (1), dans laquelle 127.0.0.1 est l'adresse IF de rebouclage et 8080 le numéro de port.

figure 4 illustre de façon simplifiée l'architecture logique d'un système selon l'invention du type représenté sur la figure 2, mais représenté de façon plus détaillée. La carte à puce 2a comprend plusieurs agents, dont deux seulement ont été représentés : un agent de type non précisément défini 232a1 et un agent 232a2, de type dit "WEB". La pile logique comprend, couches de protocole inférieures, référencées 200a, répondant aux normes ISO 7816-3 (figure 2 : CCal et CCa2), le gestionnaire de commandes "APDU" 201a1, et le multiplexeur de paquets 230a, ce dernier étant interfacé aux agents, notamment l'agent "WEB" 231 a2. Du coté terminal, il existe deux piles, l'une communiquant avec le réseau Internet RI, l'autre avec la carte à puce 2a. La première pile comprend les organes 1 (figure 2 : C1 et C2) d'accès au réseau (normes OSI 1 et 2) et les couches protocole "TCP/IP" (figure 2 : C3 et C4), référencées 100. Ces dernières couches sont interfacées avec le navigateur "WEB" 10. L'autre pile comprend couches de protocole inférieures, référencées 101, répondant aux normes 7816-3 (figure 2 : C1 et C2), le gestionnaire 102 d'ordres "APDU" et le multiplexeur de paquets 130, ce dernier étant interfacé avec des agents, dont un seul 132, est représenté. Ce dernier, que l'on supposera de "type reseau", peut en outre communiquer, d'une part avec le navigateur 10, via les couches "TCP/IP" 101, d'autre part avec le réseau Internet RI, via ces mêmes couches "TCP/IP" 101 et l'organe 11, d'accès au réseau RI.

Le gestionnaire d'ordres "APDU" 201a est également interface avec une ou plusieurs couches de niveau applications, que l'on appellera simplement applications. Ces applications, A,, ..., A;, ..., A, sont, comme il a été indiqué, des applications de type conventionnel.

En résumé, la fonction client/serveur "WEB", fournie par la à puce 2a, peut être réalisée par l'association de l'agent "WEB" 232a1 dans la carte à puce et de l'agent réseau 132 dans le terminal 1, et par la mise en ceuvre de sessions entre agents, comme il a été décrit.

La carte à puce 2a présente donc bien la fonctionnalité client/serveur "WEB". En outre, selon une caractéristique du procédé de l'invention, n'importe quelle application conventionnelle, A1<I>à An,</I> du type "CGA" précité, peut etre activée au travers de ce client/serveur "WEB", soit par le navigateur "WEB" 10 présent dans terminal 1, soit par un navigateur éloigné 4, localisé en un point quelconque réseau Internet RI, par la mise en ceuvre de sessions entre agents. Selon le procédé de l'invention, les applications, A1<I>à An,</I> ne nécessitent pas d'être réécrites et sont mises en oeuvre telles quelles.

Dans le cadre de l'invention, tout ou partie des applications A1 à An peut être constituée par des "applets", chargées initialement dans une mémoire non volatile de la carte à puce 2 ou, au contraire, chargées par l'intermédiaire des deux programmes de chargement OL et IL, dont on précisera ci-après la nature et les lieux de stockage possible.

Selon un autre aspect de l'invention, la fonction serveur "WEB" offerte par la carte à puce inclut un mécanisme similaire à la fonction dite "CGI" (pour "Common Gateway Interface" ou "interface de passerelle") implantée dans les serveurs "WEB" classique.

Avant de décrire un exemple d'architecture conforme à l'invention permettant de réaliser une fonction de ce type, au sein même de la carte à puce, il est utile de rappeler les principales caractéristiques d'un mode fonctionnement "CGI".

Le "CGI" est une spécification de mise en ceuvre, depuis un serveur "WEB", d'applications écrites pour les systèmes d'exploitation "UNIX" (marque déposée), "DOS", ou "WINDOWS" (marque déposée). A titre d'exemple, pour le système d'exploitation "UNIX", la spécification est "CGl 1.1" et pour le système d'exploitation "WINDOWS 95", la spécification est "CGI 1.3".

Toujours à titre d'exemple, une requête "HTTP" pour une adresse "URL", du type "http:llwww.host.comlcgi-binlxxx.cgi" (2), dans laquelle "host" se réfère à un système hôte (généralement éloigné), est interprétée par un serveur "WEB" comme l'exécution d'un script de commande de type "CGI" nommé "xxx" et présent dans le répertoire "cgi-bin" de ce système hôte. Bien que le nom du répertoire puisse être<I>a</I> priori quelconque, convention, c'est le nom donné au répertoire stockant les scripts de type "CGI". Un script est une suite d'instructions du système d'exploitation du système hôte dont le résultat final est transmis au navigateur "WEB" émetteur de la requête précitée. Différents langages peuvent être utilisés pour écrire ce script, par exemple le langage "PERL" (marque déposée).

De façon pratique, la requête est habituellement affichée sur un écran informatique sous la forme d'un formulaire compris dans une page "HTLM". Le langage "HTLM" permet de traduire un formulaire en une adresse "URL". Le formulaire comporte un ou plusieurs champs, obligatoires ou non, qui sont remplis par un utilisateur à l'aide des moyens de saisie habituels : clavier pour le texte, souris pour les cases à cocher ou les boutons dits "radio", etc. contenu formulaire (ainsi qu'éventuellement des informations et instructions dites "cachées") est émis à destination du serveur "WEB". Le code "HTLM" la page decrit la structure matérielle du formulaire (cadre, graphisme, couleur, tout autre attribut), ainsi que la structure des champs de données à saisir (nom, longueur, type de données, etc.).

transmission peut s'effectuer selon deux types de formats principaux. Un premier format utilise la méthode dite "POST" et un second méthode dite "GET'. Une information de type de format est présente dans code de page formulaire.

mécanisme n'est cependant pas directement transposable à une carte à puce, même si celle-ci offre la fonctionnalité client/serveur "WEB" conformement à l'une des caractéristiques de l'invention.

va maintenant décrire un exemple d'architecture permettant d'activer une application quelconque, de type conventionnel, via un serveur "WEB" sur la carte à puce, par référence à la figure 5.

Parmi les agents intelligents, conforme à l'un des aspects de l'invention, on prévoit des agents intelligents particuliers, que l'on appellera ci-apres "Agents traducteurs de script" ou de façon abrégée "ATS". Le script est alors interprété par un des agents intelligents. Cette traduction peut être réalisée différentes manières a/ par l'agent "WEB" 232a1 lui-même, qui est doté dans ce cas d'une double capacité ; b/ par agent script unique capable de traduire l'ensemble des scripts présents dans la carte à puce 2a ; c/ par agent de script dédié que l'on appellera "ATSD" ci-après (un agent par script) ; ou d/ par agent "APDU" 2010a du gestionnaire d'ordres "APDU" 201a, est doté, dans ce cas, d'une double capacité.

L'agent "APDU" 2010a est une composante de la couche gestionnaire d'ordres "APDU" 201a. Cette dernière est une couche capable de centraliser tous les ordres "APDU" émis et/ou reçus par le système, de sélectionner applications, parmi Ai à A", mais également d'offrir une interface de type agent intelligent. Elle est donc capable, selon l'une des caractéristiques l'invention de communiquer avec tous les agents intelligents (via des sessions), que ces agents soient localisés dans l'enceinte 6 ou la carte à puce 2a.

Dans le cas cl ci-dessus, une session est ouverte entre l'agent "WEB" 232a1 et l'un des agents "ATSD".

La figure 5 illustre un exemple d'architecture pour laquelle les agents traducteurs sont du type "ATSD". Ils sont référencés ATS, à et associés aux applications A, à An. L'application sélectionnée étant supposée être l'application <I>A;,</I> la session s'établit entre l'agent "WEB" 232a1 et l'agent ATS;.

Un agent traducteur de script génère une suite d'ordres "APDU". Une session est ouverte entre l'agent traducteur, par exemple l'agent i, et l'agent "APDU" 2101a. Les ordres sont alors émis vers l'agent "APDU" 2101a. Le gestionnaire d'ordres "APDU" 210a sélectionne l'application "CGA" A; et lui transmet les ordres "APDU", ordres traduits et donc conventionnels qu'elle est en mesure de comprendre. Cette application est donc correctement activée, sans avoir à la modifier ou à la réécrire.

Les réponses de l'application A; sont transmises au gestionnaire d'ordres "APDU" 210a, à l'agent "APDU" 2010a, puis de nouveau ' l'agent ATS; (et de façon plus générale à l'agent traducteur de script).

Les différents cheminements sont représentés symboliquement sur la figure 5 des traits pleins reliant les blocs fonctionnels, ou pointillés à l'intérieur ces blocs.

procédé selon l'invention utilise les deux caractéristiques qui viennent d'être rappelées : fonctionnement de la carte à puce en tant que serveur/client "WEB", incluant une fonction "cgi". Le chargement d'une "applet" dans la à puce s'effectue en effet via l'interface "CGI" offerte celle-ci.

façon plus précise, selon une caractéristique de l'invention, la partie de programme de chargement IL, localisée dans la carte à puce 2a, est constituée un script. II s'agit, par exemple, d'un script associé a l'application référencée sur la figure 5. Ce script est, selon une caractéristique du procédé de l'invention, activé par une requête "HTTP", les échanges entre la partie et la partie IL s'effectuant selon le protocole de communication "TCPIIP". programmes IL et OL deviennent de ce fait<I>a priori</I> compatibles. En outre, il est plus nécessaire que la proximité physique soit respectée, comme dans connu (voir figure 1). La partie OL peut désormais être localisée dans le terminal ou, de préférence, dans un serveur éloigné (les liaisons entre le serveur et terminal effectuant suivant le protocole "TCPJIP"), voire, comme il le sera montré, etre stockée dans la carte à puce elle-même. La requête "HTTP" précitée initiée par la partie OL.

convient de remarquer que les données adressées à l'agent "WEB" 232a1 sont transportées, de façon conventionnelle en soi, sous formes d'ordres "APDU" destinés à l'application particulière constituée par le "Multiplexeur paquets" 230a. Le gestionnaire d'ordres "APDU" 201a sélectionne cette application de manière tout à fait similaire aux autres applications de type "CGA", à An, présentes dans la carte à puce 2a. En d'autres termes, multiplexeur de paquets 230a est vu par le gestionnaire d'ordres "APDU" 201 a comme une application "CGA" ordinaire.

La requête "HTTP" est analysée par l'agent "WEB" 232a1 qui détecte une référence à un répertoire particulier, que l'on appellera ci-après par convention "cgi-smart" (par analogie à "cgi-bin"), d'une part, et à une application particulière, IL dans le cas de l'exemple décrit. Le chemin complet est donc, en l'occurrence "cgi-smartlil".

Selon une caractéristique du procédé de l'invention, l'entité "il" ci- dessus désigne un script particulier associé une application également particulière (IL en l'occurrence).

Une session est ouverte entre l'agent traducteur, par exemple l'agent ATSi, et l'agent "APDU" 2010a. L'agent traducteur de script ATSi génère suite d'ordres "APDU". Les ordres sont émis vers l'agent "APDU" 2010a. gestionnaire d'ordres "APDU" 201a sélectionne l'application "CGA" Ai (par exemple l'application IL) et lui transmet les ordres "APDU", ordres traduits et donc conventionnels, qu'elle est en mesure de comprendre. Cette application est donc correctement activée. La reponse de l'application IL (A;) est transmise sens inverse au gestionnaire d'ordres "APDU" 201 a, à l'agent "APDU" 201 puis de nouveau à l'agent ATSi de façon plus générale à l'agent traducteur script).

La reponse, constituée par un formulaire en langage "HTLM" reprend le chemin inverse, par la mise en oeuvre de sessions entre agents intelligents appariés, pour être retransmise au terminal 1 et, éventuellement à un serveur éloigné 4 (figure 4), via le réseau Internet RI, pour atteindre finalement l'application La figure 6 illustre schématiquement l'architecture logique permettant le chargement d'une "applet" selon le procédé de l'invention. retrouve sur ce schéma les blocs matériels constitués par le terminal 1, le lecteur de carte à puce 3 et la à puce 2a, communiquant par mise en oeuvre du protocole normalisé 7816 précité et l'échange d'ordres "APDU", manière classique en soi. La partie OL est mise en relation avec la partie IL (sous forme d'un script référencé ILs), par des échanges selon le protocole Internet "TCPIIP", de la manière decrite précédemment, par mise en oeuvre fonctions serveur "Hï?P" (référencé SC) et "CGI" de la carte à puce 2a.

doit bien comprendre que, bien que représentes à l'extérieur de la carte à puce 2a pour des raisons de commodité, les blocs SC et ILs sont constitues par différents modules internes de celle-ci, été décrits par référence à la figure 5.

contre, le programme OL n'est pas obligatoirement stocké dans le terminal va maintenant détailler un premier exemple chargement d'une "applet" dans une carte à puce 2a, par mise en ceuvre la méthode dite "GET".

suppose que le fichier de chargement de l' "applet", référencé 7, présente structure illustrée par la figure 7 : une entête corps principal 71 constitué par du "Byte Code" en langage "JAVA" et une signature électronique 72. L'entête représente un identifiant d'une application particulière, généralement appelé "Application Identifier" ou simplement "AID". La signature électronique 72 est un mot chiffré avec une clé publique ou privée, obtenu à partir du code 71. L'ensemble du fichier 7 peut également être chiffré, pour des raisons de confidentialité, lorsqu'il s'agit d'applications dites sensibles. Optionnellement, on peut prévoir une ou plusieurs signature(s) électronique(s) supplémentaire(s) non représentée(s).

Les principales étapes du processus sont illustrées schématiquement par la figure 8.

Pendant une première étape, la partie de programme de chargement OL récupère, par une commande de type "GET", un formulaire de chargement à partir de la carte à puce 2a, formulaire en langage "HTML" que l'on appellera arbitrairement "download.html".

Cette récupération est effectuée en consultant une page correspondante dont l'URL est typiquement de la forme suivante http:11127.0.0.1:80801download. html (3), dans laquelle http:11127.0.0.1:8080 est l'adresse URL de rebouclage proprement dite, telle qu'elle a été définie par la relation (1), "download.html" la page "HTML" à obtenir. Cette requête met en ceuvre session entre agents intelligents comme il a été décrit en regard des figures 2 à 4, selon un premier aspect de l'invention. La carte à puce 2a joue alors le rôle d'un serveur "WEB".

La carte à puce 2a envoie le formulaire "download.html" lors d'une deuxième étape, toujours par ouvertures de sessions entre agents intelligents appariés, selon le procédé de l'invention. Le formulaire obtenu peut être affiché sur un écran 5 par l'intermédiaire du navigateur 10.

Pour fixer les idées, un exemple d'un tel formulaire 8 est illustré par la figure 9. Outre diverses zones graphiques et de textes 80 (titre, etc.), le formulaire comprend des zones d'affichage pour l'entête 70 du fichier de chargement 7, le "Byte Code" 71 et la signature 72. La zone d'affichage 71 est du type dit 'TEXTAREA" en langage "HTML" et présente une facilité dite d' "ascenseur" pour l'affichage déroulant de textes longs. Les informations correspondantes, telles qu'elles apparaissent sur la figure sont purement arbitraires. Enfin, on prévoit, de façon classique en soi, bouton d'envoi "send", référencé 81, et un bouton de remise à zéro "reset", référencé 82. Ces boutons sont à la disposition d'un utilisateur du terminal (non représente). Le bouton d'envoi 81 permet de valider le formulaire et le retransmet à la à puce 2a ("soumettre le fichier de chargement" sur la figure 8) et le bouton remise à zéro 82 permet d'effacer les informations affichées et de ré-initialiser formulaire.

Le code "HTML" nécessaire pour programmer un tel formulaire est bien connu en soi est à la portée de l'homme de métier. II n'est pas nécessaire le détailler nouveau. On peut cependant indiquer qu'il contient notamment une ligne code en langage "HTML" qui se présente typiquement sous forme < form action="http:ll127.0.01:80801cgi-smartlloader"> (4), dans laquelle http:Il127.0.01:8080 est l'URL de rebouclage de la relation (1 cgi-smart répertoire "CGI" précité contenant le script de chargement "loader" que l'on a appelé "il", script associé à la partie IL du programme de chargement.

Si l'affichage visuel du formulaire 8 sur l'écran 5 n'est pas souhaité (par exemple a pas d'opérateur humain, les informations peuvent être cachées incorporant le paramètre "HTML" suivant : "TYPE=hidden" dans ligne de code précitée.

Lors d'une troisième étape, la partie OL envoie une requête "HTTP" type "GET" à carte à puce 2a, toujours par ouverture de sessions entre agents intelligents appariés. En faisant appel à la fonction "CGI" offerte par carte à puce telle qu'elle a été décrite en regard de la figure 5, l'application IL s'exécute, serveur "WEB" formé par la carte à puce 2a passant paramètres requête "HTTP" à cette dernière application.

La requete précitée contient une ligne de code typiquement de la forme suivante Smartlloader?AID=xxx & ByteCode=yyy & Signature=zzz (5), Dans laquelle "xxx" est l'entête 70 ("2001" dans l'exemple de figure 9), " le "Byte Code" 71 ("0123456789ABCDEF" dans l'exemple la figure 9) et " la signature électronique 71 ("0123456789ABCDEF" dans l'exemple de figure 9). Les trois parties du fichier de chargement sont donc bien insérées dans trois champs du formulaire "HTML" 8, sous forme concaténée.

Le chargement d'une "applet" particulière identifiée par l'entête 70 a lieu à ce moment.

Enfin, lors d'une quatrième étape un code de retour transmis de la partie IL à la partie OL, toujours par mise en oeuvre de sessions entre agents appariés. II s'agit en général d'un simple acquittement ou, si l'opération ne s'est pas réalisée correctement d'un code d'erreur. Dans ce dernier cas, il est nécessaire de renouveler les étapes 1 à 4.

Comme solution alternative, il est possible d'utiliser méthode "POST' précitée. Pour fixer les idées, la figure 10 illustre un exemple d'un tel formulaire référencé 8'. On retrouve diverses zones de texte et de graphique 80, une zone d'affichage de l'entête 70 et une zone d'affichage de la signature électronique 72, ainsi que des boutons d'envoi "send" 81 et remise à zéro "Reset" 82. Ces éléments jouent un rôle tout à fait similaire éléments de mêmes référence de la figure 9 et il est inutile de les re-décrire. Par contre, la zone d'affichage 71' ne visualise plus explicitement le "Byte Code", mais un répertoire ou un sous-répertoire où le code de l' "applet" à charger est enregistré. En l'occurrence, cette zone pointe sur un fichier, appelé arbitrairement "APPLET.BIN", enregistré sur une unité de stockage appelée "C", qui peut être un disque dur présent dans le terminal 1. Un bouton supplémentaire de navigation "browse" 83 permet de balayer les divers (sous-)répertoires de ce disque et de sélectionner un fichier particulier ("APPLET. BIN").

La méthode "POST" comme la méthode "GET" est bien connue en soi, et il est inutile de la re-décrire en détail. Dans le cadre précis de l'invention, l' "applet" correspondant au fichier "APPLET.BIN" est chargée, à partir de l'unité "C", de manière similaire à ce qui a été décrit pour la méthode "GET".

On va maintenant décrire un deuxième exemple de chargement d' "applet" dans la carte à puce 2a.

II est également possible d'enchaîner plusieurs formulaires lors du chargement. A la place d'un simple statut (acquittement ou code d'erreur dans le premier exemple décrite en regard de la figure 8), le retour de la partie IL contient alors un nouveau formulaire. Ainsi, des séquences dynamiques d'échanges entre les parties OL et IL peuvent être réalisées.

Par exemple, après analyse du fichier de chargement, la partie IL peut demander une autorisation (c'est-à-dire une signature électronique) supplémentaire, par exemple celle d'une instance gouvernementale. Elle renvoie alors à la OL un formulaire qui peut avoir typiquement la structure "HTML" suivante (6)

< TITLE>Authorisation <SEP> form <SEP> < ITITLE>
<tb> < FORM <SEP> ACTION="http:ll@carte:80801cgi-smartlloader">
<tb> < INPUT <SEP> TYPE="text" <SEP> NAME="GouvSignature" <SEP> MAXLENGTH="8">Signature
<tb> < IFORM> dans laquelle "Authorisation form", entre les balises "HTLM" dénommees " < TITLE>" et < ITITLE>, représente le titre (arbitraire) du formulaire, "@carte" la traduction litterale de l'adresse URL de rebouclage de la relation (1) et 8080 le numéro de la ligne de code < INPUT ="text" NAME="GouvSignature" MAXLENTH="8">Signature requiert l'entree d'une variable appelée arbitrairement "Signature", en mode texte, de longueur maximale 8 octets, et < IFORM> est la balise "HTML" indiquant la du code de formulaire.

Le processus complet comprend alors deux étapes supplémentaires avant l'étape finale d'acquittement ou de code d'erreur, soit six étapes, comme illustré par figure 11.

façon plus générale, le nombre d'allers et retours peut dépendre paramètres figurant dans l'un ou l'autre des formulaires échangés entre la à puce et partie OL des programmes de chargement.

Jusqu'à ce point, la localisation de la partie OL n'a pas été précisee expressément. Outre le fait que le procédé rend, a priori, compatible OL et IL, il permet aussi une très grande souplesse précisément quant à cette localisation, étant entendu que la partie IL est stockée dans la carte à puce 2a comme formant l'une des applications présente dans cette carte à puce. Le procédé selon l'invention présente notamment l'avantage supplémentaire de ne plus exiger proximité physique entre les deux parties OL et puisqu'elles ne sont plus tributaires du protocole de communication ISO les échanges entre deux portions de logiciel mettant en ceuvre protocole de communication Internet TCPIIP.

Aussi, la partie OL, ainsi que les données proprement dites de l' "applet" charger sur la carte à puce 2a peuvent être stockees soit en local, soit dans site éloigné. Dans tous les cas cependant, les echanges entre ces deux parties mettent en ceuvre, comme il vient d'être rappelé, un protocole de communication '7CPIIP" et le chargement d'une "applet" se deroule comme il a été rappele précédemment grâce aux fonctions de serveurlclient "WEB" et "CGI" offertes la carte à puce 2a.

va décrire maintenant, par référence aux figures 12A à 12G, les principales architectures pouvant être mises en ceuvre dans le cadre de l'invention.

figure 12 A illustre une architecture de système selon laquelle la partie est stockée en local sur le terminal 1. Celui-ci connecté à un serveur eloigné 4, via le réseau Internet RI. Les données de applet" à charger dans la à puce 2a, référencées Da, sont stockées sur ce serveur 4. Une requête "HTTP" permet de les transférer vers la carte à puce 2a, via le terminal 1 (et lecteur de carte à puce non représenté), par mise en #uvre du protocole de communication Internet "TCPIIP".

Dans l'architecture de système représentée sur la figure 12B, la partie de programme de chargement OL et les données<I>Da</I> sont stockées localement dans le terminal 1. La connexion du terminal 1 au réseau Internet RI est optionnelle. Pour le moins, elle n'est pas requise pour le chargement d'une "applet" selon les étapes du procédé de l'invention. Cette connexion a été représentée en traits pointillés. Le terminal peut donc être autonome.

Dans l'architecture de système représentée sur la figure 12C, la partie de programme de chargement OL et les données Da sont stockées dans un serveur distant 4. Les communications entre le serveur 4 et la carte à puce 2a, via le réseau Internet Ri, le terminal 1 et le lecteur de carte à puce (non représenté) s'effectue par des requêtes "HTTP", et mise en ceuvre protocole "TC PII P".

L'architecture de système représentée sur la figure 12D similaire à celle de la figure 12C. La seule différence est que la partie de programme de chargement OL est stockée dans un premier serveur distant, référencé 4a, et les données Da, sont stockées dans un second serveur distant, référencé 4b.

Dans l'architecture de la figure 12E, la partie du programme de chargement, référencée ici OU, est constituée par un composant navigateur 1 lui-même. II s'agit avantageusement d'une "applet" intégrée dans ce navigateur. Le type d'entrée à utiliser dans ce cas est "file" (fichier).

De façon avantageuse également, les données Da, de "applet" à charger sur la carte à puce 2a, peuvent être stockées sur un support d'enregistrement de données externe 9, par exemple une disquette comme illustré par la figure 12E. Naturellement d'autres supports sont utilisables CedéROM, bande magnétique, etc.

Si on utilise la méthode "POST" précitée, il suffit de spécifier la lettre de l'unité dé stockage, par exemple "A" pour la disquette 9, un éventuel chemin (répertoire, sous-répertoires) et le nom du fichier à charger. Pour fixer les idées, le chemin complet pourrait être typiquement A:IAPPLET. BIN (8) Du fait de la fonction serveur/client "WEB" offerte la carte à 2a, selon une des caractéristiques du procédé de l'invention, navigateur est à même, contrairement à l'art connu, de communiquer directement avec cette dernière, comme il l'a été montré en regard des figures à 4. Les communications s'effectuent par l'ouverture de sessions entre agents appariés. L'architecture de système illustrée par la figure 12F est une variante de l'architecture de la figure 12E. Selon cette variante, la partie de programme de chargement OL est stockée dans la carte à puce 2a elle-même, sous forme d'une "applet" en langage "JAVA". Par une requête "HTTP", cette "applet" peut être chargée dynamiquement sur le terminal 1, en OL". Ce chargement s'effectue à l'aide de requêtes posées par le navigateur 10, lors d'étapes préliminaires. Une fois la partie OL chargée, les étapes ultérieures sont communes au cas précédent. Les données Da peuvent également être stockées sur un support externe, par exemple une disquette 8.

L'architecture de système de la figure 12G est une variante de celle de la figure La seule différence est que la partie de programme de chargement est stockée sur un serveur éloigné 4, sous forme d'une "applet" en langage "JAVA". Comme précédemment, par une requête "HTTP", cette "applet" peut etre chargée dynamiquement sur le terminal 1, en OL". Ce chargement s'effectue à l'aide de requêtes posées par le navigateur 10, lors d'étapes préliminaires. Les autres étapes sont communes au cas précédent.

II est clair que d'autres variantes d'architecture peuvent être mises en oeuvre sans sortir du cadre de l'invention. II est notamment possible de charger les données dans le terminal 1 à partir de diverses sources : par exemple à partir d'un autre système informatique, connecté au terminal 1 par un réseau local ou tous autres moyens télématiques.

A lecture de ce qui précède, on constate aisément que l'invention atteint bien buts qu'elle s'est fixés.

La mise en oeuvre du chargement d'une "applet" dans une carte à puce par l'interface "CGI" d'un serveur "WEB" logé dans cette carte à puce présente notamment avantages suivants L'utilisation de formulaires en langage "HTML" standardise chargement rend les parties de programmes de chargement OL et IL<I>a</I> priori compatibles. effet, comme il a été montré, c'est la partie IL située dans carte à puce décrit, dans les champs du ou des formulaire(s) renvoyé(s), paramétrage chargement auquel il s'attend.

ailleurs, ce mécanisme de communication entre les parties programme chargement OL et IL permet de gérer simplement des séquences d'échanges dynamiques lors du chargement.

L'utilisation des protocoles Internet "HTTP" et "TCPIIP" pour échanges entre les parties de programme de chargement OL et IL permet de séparer physiquement. Seul un routage de paquets "IF est nécessaire sur terminal. chargement peut alors se faire dans un lecteur carte à puce banalisé, puisque l'on conserve le protocole de communication ISO 7816. terminal peut etre un simple micro-ordinateur standard connecté à Internet.

Selon un aspect avantageux également du procédé de l'invention, applications stockées dans la carte à puce restent standards, et donc n'ont à être réécrites. La carte à puce et le terminal eux-mêmes ne nécessitent peu de modifications pour pouvoir accommoder le procédé de l'invention : ces dernières se résument à l'implantation, dans ces deux unités, d'une couche logicielle de protocole de communication qui a été appelée spécifique, couche logicielle incluant des agents intelligents.

Alternativement, la partie de programme de chargement OL peut être chargée dynamiquement sur le terminal, au travers la carte, à partir de celle-ci ou d'un serveur "HTTP" éloigné.

Un simple navigateur Internet peut être utilisé comme programme chargement Il doit être clair cependant que l'invention n'est pas limitée aux seuls exemples de realisations explicitement décrits, notamment en relation avec figures 2 à D'autre part, en lieu et place du langage "HTML", d'autres langages similaires, adaptés aux protocoles de communication de type "Internet" peuvent être utilisés, notamment le langage "XML".

Claims (1)

1. <U>REVENDICATIONS</U> <B>1.</B> Procède de chargement d'une pièce de logiciel dans une carte à puce à partir terminal connecté à ladite carte à puce par l'intermédiaire lecteur carte à puce permettant des communications selon un premier protocole déterminé, ledit chargement s'effectuant par la mise en oeuvre coopération de premier et second programmes de chargement, ledit second programme de chargement étant stocké dans ladite carte à puce, caracterise en ce comprend au moins les phases suivantes al une première phase préliminaire consistant à implanter, dans ladite carte à puce (2a), une première pièce de logiciel (23a), formant une couche protocolaire de communication spécifique ; bl une deuxième phase préliminaire consistant à implanter, dans ledit terminal (1), une seconde pièce de logiciel (13), formant une couche protocolaire de communication spécifique ; en ce que lesdites première et seconde pièces de logiciel (13, 23a) comprennent en outre au moins une paire de premières entités logicielles appariées 32, 232a), chacune desdites entités (132, 232a) coopérant l'une avec l'autre de manière à permettre l'établissement d'une session d'échanges de données bidirectionnels entre au moins ledit terminal (1) et ladite à puce (2a), manière à ce que ladite carte à puce (2a) offre la fonctionnalite d'un client/serveur "WEB" ; en ce 'il comprend une troisième phase préliminaire consistant a implanter dans ladite carte à puce (2a) au moins une deuxième entité logicielle (ATS, <I>- A</I> apte à interpréter une suite d'instructions et à la traduire en suite d'ordres de manière à coopérer avec ladite seconde pièce de logiciel spécifique (23a) pour que ladite carte à puce offre une fonctionnalité d'interface passerelle dite "CGI", la dite carte à puce comprenant au moins une desdites suites d'instructions associée au dit second programme de chargement (IL) ; et en ce qu'il comprend au moins les étapes suivantes 1l ouverture d'une première session d'échanges de données entre au moins ledit terminal (1) et ladite carte à puce (2a), pour la transmission d'une requête pour que ledit premier programme de chargement (0L) recupère des données de paramétrage de chargement fournies par ledit second programme de chargement (IL) ; ouverture d'une deuxième session d'échanges de données entre ladite carte à puce (2a) et au moins ledit terminal (1) pour transmettre lesdites données de paramétrage de chargement au dit premier programme de chargement (0L), lesdites données de paramétrage comportant une référence aux dites instructions associées au dit second programme de chargement (IL) ; et ouverture d'une troisième session d'échanges de données entre au moins ledit terminal (1) et ladite carte à puce (2a), pour la soumission d'un fichier de chargement (7) prenant en compte lesdites données paramétrage de chargement, ledit fichier comprenant des données (70, , associées ladite pièce de logiciel à charger (Da) ; interprétation ladite suite d'instructions associée au dit second programme chargement (IL), par mise en ceuvre de ladite fonctionnalité "CGI", manière générer une suite d'ordres transmise au dit second programme chargement (IL), à exécuter ce programme (IL) et à obtenir ledit dechargement de ladite pièce de logiciel (Da). <B>2.</B> Procédé selon la revendication 1, caractérisé en ce que ledit lecteur de carte à puce (3) et ladite carte à puce (2a) comprennent des première et deuxième piles protocolaires pour lesdites transmissions de données selon ledit premier protocole déterminé, définies par la norme ISO 7816, chacune comprenant au moins des couches protocolaires de communication logicielles (101, 200a), dites basses, de manière à permettre lesdits échanges de données entre ladite carte à puce (2a) et ledit terminal (1), ces couches formant interface avec lesdites première (13) et seconde (23a) pièces de logiciel spécifique formant lesdites couches protocolaires de communication spécifiques, respectivement, et en ce que ces pièces de logiciel (13, 23a) comprennent chacune deux entités supplémentaires constituées d'un module de transfert données (130, 230a), formant interface avec lesdites couches basses 200a) des première et deuxième piles protocolaires, et d'un module de gestion (131, 231a), et en ce que lesdites premières entités de chaque paire sont constituées de modules logiciels, dits agents intelligents (132, 232a1) etablissant lesdites sessions. <B>3.</B> Procédé selon la revendication 2, caractérisé en ce que ladite suite d'instructions à interpréter associée au dit second programme (IL) de dechargement est constituée par un script et en ce que ladite deuxième entité logicielle est constituée par un module logiciel dit agent intelligent traducteur script (ATS, <I>-</I> ATS,) fournissant des ordres compréhensibles par ledit second programme de chargement (0L). <B>4.</B> Procédé selon la revendication 3, caractérisé en ce ladite première étape comprend l'émission d'une requête de type "HTTP" selon un protocole de type Internet par adressage d'une page determinée en langage "HTML" contenant lesdites données de paramétrage, ladite adresse étant une adresse de type "URL" de rebouclage sur ladite carte à puce (2a). <B>5.</B> Procédé selon la revendication 4, caractérisé en ce que ladite requête est du type dit "GET'. <B>6.</B> Procédé selon la revendication 4, caractérisé en ce que ladite requête est du type dit "POST'. <B>7.</B> Procédé selon la revendication 4, caractérisé en ce ladite deuxième étape comprend l'envoi par ladite carte à puce (2a) formulaire (8, 8') en langage "HTML" et en ce que ledit formulaire (8, 8') comprend au moins une adresse de type dit "URL" de rebouclage sur ladite à puce (2a) et un chemin menant à un répertoire déterminé contenant ledit script associé au dit second programme de chargement (IL), de manière à ce ce dit premier programme de chargement (0L) récupère les dites données paramétrage. <B>8.</B> Procédé selon la revendication 7, caractérisé en ce que ladite troisième étape comprend l'envoi d'une requête de type dit "HTTP" à ladite adresse "URL", designant ledit répertoire contenant ledit script associé au dit second programme de chargement (IL), ladite requête comprenant lesdites données représentant ladite pièce de logiciel à charger (Da), l'interprétation dudit script et l'exécution dudit second programme de chargement (0L), de manière obtenir ledit chargement de la dite pièce de logiciel (Da). <B>9.</B> Procède selon la revendication 8, caractérisé en ce que ladite pièce de logiciel<I>(Da)</I> est une appliquette écrite en langage "JAVA" (marque déposée). 10.Procédé selon la revendication 9, caractérisé en ce que ledit fichier de chargement (7) est incorporé dans ledit formulaire (8, 8') comprend une entête (70) identifiant ladite appliquette, des données (71) au moins une signature électronique (72) obtenue à partir du chiffrement desdites données. 11.Procédé selon la revendication 10, caractérisé en ce comprend au moins une première étape supplémentaire, réalisée après ladite troisième étape, en ce que cette première étape supplémentaire consiste en l'ouverture première session supplémentaire d'échanges de données entre ladite à puce (2a) et au moins ledit terminal (1) pour transmettre un code prédéterminé reçu par ledit premier programme de chargement (0L). 12.Procédé selon la revendication 11, caractérisé en que ledit code prédéterminé consiste en un acquittement lorsque lesdites trois premières étapes sont déroulées correctement ou un code d'erreur dans le cas contraire. 13.Procéde selon la revendication 12, caractérisé en ce 'il comprend au moins deux étapes supplémentaires, réalisées après ladite troisième étape, comprenant l'ouverture de sessions d'échanges de donnees bidirectionnels entre ladite carte à puce (2a) et au moins ledit terminal (1) pour la transmission d'un formulaire supplémentaire requérant la soumission de données supplémentaires. 14.Procédé selon la revendication 13, caractérisé en ce que lesdites données supplémentaires comprennent une signature électronique supplémentaire. 15.Procédé selon la revendication 14, caractérisé en ce que ledit premier programme de chargement (0L) et les données (Da) associées ' ladite pièce de logiciel sont stockées dans ledit terminal (1). 16.Procéde selon la revendication 14, caractérisé en ce que ledit terminal étant connecte à au moins un serveur éloigné (4) via un réseau de type Internet (RI) et la mise en ceuvre de protocole de communication de type Internet, un desdits agents intelligents (132) est associé à un attribut de "réseau" permettant des communications avec ledit réseau Internet (RI) en ce que ledit premier programme de chargement (0L) est stocké sur desdits serveurs eloignés (4, 4a). 17.Procéde selon la revendication 16, caractérisé en ce que, ledit terminal (1) comprenant un navigateur de type "WEB" (10), ledit premier programme de chargement (OU) est constitué par un composant logiciel dudit navigateur <B>"W E B"</B> 18.Procédé selon la revendication 17, caractérisé en ce que ledit composant logiciel (0L") est obtenu par une étape initiale de chargement dynamique d'une appliquette (0L) écrite en langage "JAVA" et stockée dans ladite carte à puce (2a), ledit chargement étant obtenu par l'émission d'une requête de type "HTTP", avec un adressage de type "URL" de ladite carte ' puce (2a). 19.Procédé selon la revendication 17, caractérisé en ce que ledit composant logiciel (OU) est obtenu par une étape initiale de chargement dynamique d'une appliquette (0L) écrite en langage "JAVA" et stockée dans un desdits serveurs éloignés (4), ledit chargement étant obtenu par l'emission d'une requête de type "HTTP", avec un adressage de type "URL" dudit serveur éloigné (4). 20.Procédé selon la revendication 17, caractérisé en ce ladite pièce de logiciel (Da) est stockée sur l'un desdits serveurs éloignés (4, 4b). 21.Procedé selon la revendication 17, caractérisé en ce ladite piece de logiciel (Da) stockée sur un support d'enregistrement de données externe au dit terminal (1) et destiné à être lu par ce terminal (1).