FR2805108A1 - Procede d'enregistrement d'un usager sur un serveur d'annuaire d'un reseau de type internet et/ou de localisation d'un usager sur ce reseau, et carte a puce pour la mise en oeuvre du procede - Google Patents

Abstract

L'invention concerne un procédé d'enregistrement d'un usager sur un serveur d'annuaire et/ou de localisation d'un internaute sur un réseau de type Internet (RI), par interrogation d'un serveur d'annuaire (SAi ), de manière à déterminer une adresse "IP" associée à cet internaute. Pour ce faire, on utilise une carte à puce (2a) stockant des applications (AI ) associées chacune à un protocole d'enregistrement et/ou de localisation ( " PL " ). Des profils d'abonnés peuvent être stockés dans la carte à puce (2a). Plusieurs protocoles différents peuvent être stockés, transformant la carte à puce (2a) en base de données multi-annuaire. La carte (2a) est dotée de fonctionnalités client/serveur " WEB " et "CGI", de manière à pouvoir initier des transmissions selon des protocoles Internet entre des serveurs d'annuaire (SAi ) et la carte à puce (2a), et activer les applications (AI ) stockées dans celle-ci, pour le déroulement des protocoles d'enregistrement et/ou localisation ( " PL " ).L'invention concerne aussi la carte associée.

Description

L'invention concerne un procédé d'enregistrement d'un usager sur un serveur d'annuaire d'un réseau notamment de type Internet et/ou de localisation d'un usager sur un tel réseau, à l'aide de cartes à puce connectées à des terminaux munis lecteur de carte à puce.

L'invention concerne également une carte à puce pour la mise en oeuvre de ce procédé.

Dans le cadre de l'invention, le terme "réseau Internet" doit être compris dans son sens plus général. Il concerne, outre le réseau Internet proprement dit, les réseaux privés d'entreprise ou similaires, du type dit "intranet", et les réseaux les prolongeant vers l'extérieur, du type dit "extranet", et de façon générale tout reseau dans lequel les échanges de donnees s'effectuent selon un protocole type Internet. Dans ce qui suit un tel reseau sera appelé de façon générique "réseau Internet".

De meure, 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 marques déposées). II peut être aussi constitué par une station de travail, un ordinateur portable ou un terminal de dit dédié. Dans le cadre plus particulier de l'invention, il existe également terminaux dédiés Internet, ne possédant qu'un minimum de ressources informatiques propres, voire aucun moyens de stockage permanent, de type disque Il apparaît tout d'abord utile de rappeler brièvement caractéristiques principales des protocoles de communication sur les réseaux.

L'architecture des réseaux de communication est decrite par diverses couches. A titre d'exemple, le standard "OSI" ("Open System lnterconnection"), 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 à couche qui lui est immédiatement supérieure et requiert de la couche lui immédiatement inférieure 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 inférieure : la couche dite d'application ("http", "ftp", "e-mail", etcj, couche dite transport ("TCP"), la couche dite d'adressage de réseau ("1P"), couche dite liens de données ("PPP", "Slip", etc.) et la couche dite physique.

Dans l'art connu, un usager, que l'on appellera ci-après "internaute", utilise terminaux Internet qui possèdent une adresse "1P" fixe, ou variable lorsque a recours à un prestataire de service Internet, généralement connu sous le sigle anglo-saxon "ISP" (pour "Internet Service Provider).

premier inconvénient est constitué par le fait qu'une adresse "IP" n'est associée à un internaute, mais à un système informatique connecté au réseau Internet. Même dans le cas où le système informatique est doté d'une adresse fixe, il n'existe pas de correspondance<I>a</I> priori entre une adresse "IP" et une personne physique. Pour établir une telle relation l'internaute se connecte à des serveurs dits "IRC" (pour "Internet Relay Chat"). Ces serveurs associent à un identifiant de l'internaute, dit "UserID", son adresse "1P". L'identifiant est généralement constitué par son adresse courrier e-mel, ou "e-mail" selon la terminologie anglo-saxonne, mais un pseudonyme quelconque peut également être utilisé. Ci-après, les serveurs "IRC" seront dénommés de façon plus générale "serveurs d'annuaires", que l'on appellera simplement "SA".

Cette association n'est généralement pas authentifiée de telle sorte que le service (généralement gratuit) puisse être utilisé de la manière la plus commode possible. Cette disposition n'est cependant pas exempte d'inconvénients, en particulier pour des applications dites "sensibles".

Une des premières contraintes rencontrées est donc la localisation d'un internaute dans le réseau Internet, c'est à dire l'établissement d'une correspondance entre un identifiant fixe et une adresse "1P". Cependant la localisation d'un internante sur le réseau Internet, c'est-à- dire l'établissement de la correspondance précitée, présuppose que celui-ci ait été préalable enregistré dans le serveur d'annuaire "SA".

L'adresse d'un internante dans le réseau Internet donc constituée du couple : "Adresse SA" - "UserID". De façon usuelle, abonné", on entend entité "physique". Par extension, il peut s'agir d'une "fonction". Cependant, après, on donnera à "abonné" son sens commun, sans cela soit limitatif en quoi que ce soit de la portée de l'invention.

De façon pratique, un internante indique sa localisation dans le réseau Internet par un acte volontaire en fournissant au serveur (annuaire) son adresse "1P" actuelle à l'aide d'un protocole d'enregistrement appellera ci- apres "PE".

Cette opération implique que le terminal possède un logiciel spécifique (ou application) délivré par le fournisseur du service, et personnalisé avec un profil d'abonné particulier, que l'on appellera "PA" ci-après. profil "PA" permet d'identifier de façon plus complète un abonné (ou internante), en sus de identifiant de base "UserID".

On désigne généralement par "Profil d'Abonné" ("PA") l'ensemble des informations qui sont fournies au serveur d'annuaire "SA" lors de l'enregistrement de l'abonné (internante), et par exemple - l'adresse du "Serveur d'Annuaire" ("SA") ; - l'identifiant de l'abonné ("UserID") ; - les abonnés (identifiés par leurs "UserID") avec lesquels l'utilisateur accepte d'entrer en communication ou auxquels il désire notifier sa localisation dans le réseau ; et - les informations qu'il accepte de rendre publiques sur le serveur d'annuaire (par exemple : nom, nationalité, contacts recherchés, etc.). ; Pour joindre un correspondant à travers le réseau Internet, ce correspondant étant dûment enregistré, il est nécessaire de connaître son adresse "1P". Cette information est obtenue à l'aide d'un serveur d'annuaire ("SA") et d'un protocole de localisation ("PL"). doit noter que le profil d'abonné "PA" est, par nature, spécifique à l'abonne mais peut dépendre aussi des caractéristiques du serveur d'annuaire, notamment du type et de la nature des informations qui doivent être fournies ou qu'il peut accepter.

doit noter enfin que le protocole "PL" est, comme le protocole "PE", de type propriétaire, puisqu'il adresse un serveur d'annuaire a priori non standardise ou répondant à des normes universellement reconnues.

deux caractéristiques constituent des inconvénients supplémentaires.

résumé de ce qui vient d'être rappelé, pour qu'un premier internaute puisse localiser d'autres internautes et puisse être localisé ceux-ci, il est nécessaire que le terminal qu'il utilise stocke des logiciels spécifiques permettant de mettre en ceuvre les protocoles "PE" et "PL". peut également être nécessaire qu'il stocke des données afférentes à son profil d'abonné "PA". Cette remarque s'applique de façon similaire aux terminaux des autres internautes.

d'autres termes, le terminal utilisé par un abonne quelconque est également spécifique, en ce sens que, si cet abonné desire changer de terminal, doit retrouver sur le nouveau terminal utilisé, au moins le ou les logiciels associés au protocole "PL", en admettant qu'il ait procédé à une phase préliminaire d'enregistrement sur le premier terminal, en faisant appel au protocole "PE" et en fournissant son profil "PA" au serveur d'annuaire "SA". En effet, la présence du protocole "PL" sera nécessaire pour adresser le serveur d'annuaire et avoir accès aux données enregistrées dans celui ' notamment les adresses "1P" des correspondants recherchés et leurs profils serait donc intéressant d'utiliser des terminaux banalisés pour effectuer les opérations d'enregistrement et, surtout, localisation d'internautes sur le réseau Internet, ce qui permettrait d'acceder de façon commode au concept appelé "nomadisme".

logiciels associés aux protocoles précités,<B>"PE"</B> et "PL" ne nécessitent pas habituellement de disposer d'une grande quantité de mémoire. Il en est même des données de profil "PA". On pourrait donc penser les enregistrer dans circuits de mémoire d'une carte à puce, ce que permet la technologie actuelle.

Cependant, on se heurte à une double difficulté technique, comme il va l'être montré ci-apres, ce qui interdit toute communication directe entre le réseau Internet et une à puce.

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

Un systeme d'application à base de carte à puce comporte généralement les elements principaux suivants - une à puce ; - un système hôte constituant le terminal précité ; - un reseau 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 illustre schématiquement un exemple d'architecture de ce type. Le terminal , exemple un ordinateur individuel, comporte un lecteur 3 de carte à puce lecteur 3 peut être ou non physiquement intégré dans le terminal 1. La a 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 energie électrique et des communications avec le terminal 1. 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 téléphonique commutée ou à une voie de communication à plus haut débit 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 ' 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'Yirewall" ("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 but de simplification du dessin : unité centrale, mémoires vive et fixe, mémoire de masse à disque magnétique, lecteur de disquette et/ou de CédéRom, etc.

Habituellement, le terminal 1 est aussi relié à des périphériques classiques, intégrés ou non, tels un écran de visualisation 5, un clavier 6a et une souris 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 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 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 de 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 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; - iS0 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 B, côté terminal 1, on n'a représenté que les couches répondant à la norme 7816-3, référencées 101, et un gestionnaire d'ordres "APDU" (norme ISO 6-4), référencé 102. Du côté carte à puce 2, les couches répondant à norme ISO 7816-3 sont référencées 200 et le gestionnaire d'ordres "ADPU" (norme ISO 7816-4) est référencé 201. Les applications sont référencées A1,<I>..., A;, ..., An ;</I> n étant le nombre maximum d'applications présentes sur la carte à puce 2.

Une application, Ai, présente dans la carte à puce 2, dialogue avec le terminal 1 au moyen d'ordres. Ce jeu présente typiquement des ordres d'écriture et des ordres lecture. Le format des ordres est connu sous l'abréviation anglo-saxonne "APDU" (pour "Application Protocol Data Unit"). II est défini par la norme 6-4 précitée. Une "APDU" de commande est notée "APDU.command' une "APDU" de réponse est notée "APDU.response". Les "APDU" sont échangées entre le lecteur de carte et la carte à puce au moyen protocole spécifié par la norme ISO 7816-3 précitée (par exemple en mode caractère: T=0 ; ou en mode bloc: T=1).

Lorsque la carte a puce 2 inclut plusieurs applications distinctes, comme illustré sur la figure 1 on parle de carte multi-applicative. Cependant, le terminal 1 ne dialogue qu avec seule application à la fois.

La sélection d'une application particulière A; 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. Une "APDU SELECT" nouvelle a pour effet d'abandonner l'application en cours et d'en choisir une autre. Le sous-ensemble logiciel gestionnaire des "APDU" 201 permet de choisir une application particulière Ai dans la carte à puce 2, de mémoriser 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<B>Ai</B> et le dialogue avec celle-ci effectuent par échanges d'ordres "APDU". On suppose que les applications sont des applications conventionnelles, que l'on appellera ci-après "GCA" (pour "Generic Card Application" ou application de carte générique). rappels étant effectués, il est à noter que la à puce 2 ne peut communiquer directement avec les navigateurs standards commerce 10, sauf à modifier code 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 et logicielle qui ne permet pas non plus de communiquer directement avec le roseau 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. 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 ce qui est appelé un "plug ' selon la terminologie anglo-saxonne. Cette piece de logiciel, qui porte la reference 12 sur la figure 1A, effectue l'interface entre le navigateur 10 et la carte plus précisément les circuits électroniques 20 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 en répondant aux besoins se font sentir. Selon un mode de réalisation avantageux de l'invention, les applications nécessaires à la mise en couvre des protocoles d'enregistrement ("PE") et de localisation ("PL"), ainsi que les données caractérisant profil d'abonné ("PA") sont fichiers stockés, en tout ou partie, dans des mémoires d'une carte à puce, fichiers de type exécutable étant des applications standards du type "GCA" précité.

Selon l'invention, la carte à puce se comporte comme un serveur/client de type "WEB" pour le terminal qui lui est associé.

Pour ce faire, on prévoit une couche de logiciel de communication spécifique dans la carte à puce et son pendant dans terminal. Le terme "spécifique" doit être entendu comme spécifique au procedé de l'invention. En effet, couches de communications, dites spécifiques, sont banalisées quelle que soit l'application considérée. En particulier, elles sont indépendantes des applications nécessaires à la mise en couvre des protocoles "PE" et "PL". Elles n'interviennent que dans le processus d'échanges de données bidirectionnels entre carte à puce et le terminal, d'une part, et la carte à puce et le réseau, d'autre couches logicielles de communication spécifiques comprennent notamment des composants logiciels, dits "agents intelligents", permettant en particulier conversions de protocoles. Les agents intelligents seront appeles ci-après plus simplement "agents". II existe des agents appareillés dans couches communication spécifiques respectives associées au terminal et à carte à puce. Selon le procédé de l'invention, il s'établit des sessions entre agents appareillés.

Avantageusement, le procédé de l'invention rend possible l'activation d'applications de type conventionnel, c'est-à-dire du type "CGA" précite, localisees dans une carte à puce, sans devoir les modifier en quoi que ce 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 ordres "APDU" compréhensibles par l'application de type "CGA". De ce fait, 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 ceuvre une application dans carte @ puce par un protocole Internet de type "HTTP".

Ces diverses dispositions permettent à la carte à puce, et plus précisément aux applications présentent dans celle-ci, de communiquer directement avec un serveur éloigné connecté au réseau Internet par la mise en ceuvre de protocoles de type Internet. La fonctionnalité "CGI" offerte par la carte à puce permet pour sa part l'accession aux applications associées aux protocoles "PE" et "PL" et leur exécution, sans nécessiter la présence d'applications de type propriétaire dans le terminal. Seul un navigateur, avantageusement de type standard du commerce, est nécessaire.

Dans une variante préférée de réalisation de l'invention, on stocke dans la carte à puce plusieurs jeux composés d'applications associées à protocoles "PE" et "PL" et/ou de profils d'abonnés "PA" distincts.

Cette disposition avantageuse permet, d'une part, d'enregistrer plusieurs profils d'abonné "PA" distincts ou plusieurs occurrences distinctes même profil d'abonné "PA" sur un même serveur d'annuaire "SA", et de localiser ces entites en les associant à des adresses "1P" uniques. Elle permet, d'autre part, de pouvoir adresser plusieurs serveurs d'annuaire "SA", avec un même et/ou plusieurs profils d'abonnés "PA" distincts. La carte à puce présente alors une fonctionnalité de base de données multi-annuaire.

L'invention a donc pour objet principal un procédé de mise en relation d'un premier usager avec au moins un serveur d'annuaire, en vue de son enregistrement et/ou de la localisation d'au moins un deuxième usager sur un réseau notamment de type Internet, ladite mise en relation s effectuant par l'intermédiaire d'un terminal muni d'un lecteur de carte à puce et moins une pièce de logiciel dite d'enregistrement et/ou de localisation, ledit terminal étant connecté à chacun desdits serveurs d'annuaire via ledit réseau type Internet et communiquant avec ladite carte à puce selon un premier protocole déterminé, caractérisé en ce qu'au moins l'une desdites pièces de logiciel stockée dans ladite à puce ; en ce que cette carte à puce comprenant une première pièce logiciel, formant une couche protocolaire de communication spécifique, et ledit terminal comprenant une seconde pièce de logiciel, formant une couche protocolaire de communication spécifique, lesdites première seconde pièces de logiciel comprennent en outre au 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, et/ou ledit réseau de type Internet, de manière à ce que ladite carte à puce offre la fonctionnalité d'un client/serveur "WEB" ; en ce que ladite carte à puce comprend au moins une deuxième entité logicielle coopérant avec ladite seconde pièce de logiciel spécifique pour que ladite carte à puce offre une fonctionnalité d'interface passerelle dite "CGI" et en ce qu'il comprend au moins les étapes suivantes 1I ouverture d'une première séquence d'échanges de données entre au moins ledit terminal et ladite carte à puce, pour la transmission d'une requête pour que ledit navigateur de type "WEB" récupère des données permettant de sélectionner et d'activer une desdites pieces de logiciel propriétaire, en vue de la sélection d'un desdits serveurs d'annuaire ; 21 ouverture d'une deuxième séquence d'échanges de données entre ladite carte à puce et ledit terminal pour lui transmettre lesdites données ; 3l ouverture d'une troisième séquence d'échanges de données entre ledit terminal et ladite carte à puce pour transmettre des donnees de sélection des paramètres optionnels, lesdites données et lesdits paramètres optionnels comportant une référence à une desdites pieces de logiciel d'enregistrement et/ou de localisation ; 41 mise en oeuvre de ladite fonctionnalité "CGI" et exécution de ladite pièce logiciel d'enregistrement et/ou de localisation ; et en résultat de ladite exécution, ouverture d'une quatrième sequence d'échanges de données entre ladite carte à puce et un desdits serveurs d'annuaire, sélectionné par lesdites données sélection, de manière à transmettre une requête pour la réalisation d'une opération determinée d'enregistrement ou de localisation.

L'invention a également pour objet une carte à puce pour la mise en ceuvre ce procédé.

mode préféré, mais non limitatif, de réalisation l'invention va maintenant être décrit de façon plus détaillée en se référant aux dessins annexés, parmi lesquels - les figures 1A et 1 B illustrent les architectures matérielle et logique, respectivement, d'un exemple de système d'application à base de carte à puce connecté à un réseau Internet selon l'art connu ; - la figure 2 illustre schématiquement un exemple de système d'application à base de carte à puce selon l'invention, cette dernière agissant en tant que client/serveur "WEB", selon un aspect de l'invention ; - la figure 3 est un diagramme d'états d'une session entre des entités logicielles dites agents intelligents, selon un aspect de l'invention; - la figure 4 illustre de façon simplifiée l'architecture logique système selon l'invention dans lequel la carte à puce comprend agents intelligents ; - la figure 5 illustre de façon simplifiée l'architecture logique système selon un autre aspect de l'invention selon lequel la carte a puce comprend des agents intelligents traducteurs de scripts, manière à implanter une fonction dite "CGI" ; la figure 6A illustre schématiquement une première étape phase d'enregistrement d'un internante sur un serveur d'annuaire ; les figures 6B et 6C illustrent des exemples de formulaires "HTLM" utilisables pour cette phase d'enregistrement ; la figure 6D illustre schématiquement les principales étapes phase d'enregistrement d'un internante sur un serveur d'annuaire ; la figure 6E illustre schématiquement les principales étapes phase d'enregistrement d'un internante plusieurs serveurs d'annuaire ; la figure 7 illustre schématiquement les principales étapes de la phase de localisation d'un internante sur le réseau Internet par interrogation d'un serveur d'annuaire ; et - la figure 8 illustre schématiquement une architecture à carte a puce selon l'invention présentant une fonctionnalité de base de données multi-annuaire portable.

La figure 2 illustre schématiquement un exemple de système d'application à base de carte à puce selon un premier aspect de l'invention, permettant à cette dernière d'agir en tant que client/serveur "WEB.

l'exception de couches logicielles de protocole de communication spécifiques, référencées 13 et 23a, respectivement implantées dans terminal et la carte à puce 2a, les autres éléments, matériels ou logiciels, sont communs à l'art connu, notamment à ce qui a été décrit en regard des figures 1A et 1 et il n'y a pas lieu de les re-décrire de façon détaillée.

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

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

L'interface entre les couches inférieures, C1 et C2, et les couches supérieures, et C4, est constituée par une couche logicielle généralement appelée "driver couches basses". Les couches supérieures, C3 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 avec lesquelles elles correspondent. Dans le cas du réseau Internet, "TCPIIP" mis en oeuvre 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é Pour communiquer avec la carte à puce 2a, le lecteur de carte 30 englobe également deux couches basses, CC1 (couche physique) et CC2 (couche de lien de données), jouant un rôle similaire aux couches C1 et C2. Les interfaces logicielles avec les couches CC1 et CC2 sont décrites, par exemple, la spécification "PC/SC" ("part 6, service provider"). Les couches elles-memes, CC1 et CC2, sont notamment décrites par les normes ISO 7816-1 à 6-4, comme il a été rappelé.

Une couche logicielle supplémentaire 16 forme interface entre les couches applicatives (non représentées) et les couches inférieures, 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 "UNIR" (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 , tout à fait similaire à la couche 16.

Selon l'invention, on prévoit, de part et d'autre, c'est-à-dire dans le terminal 1 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 ' la couche de multiplexage 16. La couche spécifique 13 permet le transfert paquets réseaux de et vers la carte à puce 2a. outre, elle adapte les applications existantes telles le navigateur Internet le courrier électronique, , pour des utilisations mettant en oeuvre la carte a puce 2a.

Du côte 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 , pendant de la couche 13.

De façon plus précise, les couches spécifiques, 13 23a, sont subdivisées trois éléments logiciels principaux - 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, realisent, par exemple, des fonctions de conversion de protocoles ; - 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 eté 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 suivants recommandation ETSI GSM 11.11 ; protocole défini par la norme ISO 7816-3, en mode caractère T=0 ; protocole défini par la norme ISO 7816-3, en mode bloc =1 ; ou le protocole défini par la norme ISO 3309, en mode trame "HDLC" (pour "High-Level Data Link Control procedure" ou procedure de commande de liaison à haut niveau).

Dans le cadre de l'invention, on utilisera de préférence le protocole ISO 7816- en mode bloc.

façon connue en soi, à chaque couche de protocole, il associé un certain nombre de primitives qui permettent les échanges de donnees entre couches 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> request") et "envoi de données" par la carte <I>("Data.</I> response"), ainsi que confirmation de données"<I>("Data.</I> confrrm"), 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 la 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 carte à puce 2a et le terminal hôte 1, sous la forme d'unités de données de protocole. Elle joue un rôle similaire à celui d'un commutateur de paquets de données. Ces unites sont émises ou reçues via la couche de niveau deux (couche de liens de données). Ce protocole particulier de communication permet mettre en communications au moins une paire d' "agents". Le premier agent de chaque paire, 132, est situé dans fa couche 13, côté terminal 1, le second, 232a, est situe dans la 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 echange de données bidirectionnel entre ces deux agents. l'une ou l'autre des couches, 13 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 a, 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 idées, et à titre d'exemple non limitatif, les six propriétés suivantes sont associees 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 = 1) 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", qui 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 l'on peut qualifier d'éphémere, délivrée par le module de gestion de configuration, 131 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 la terminologie anglo-saxonne) constituant une référence de destination et une réference 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 "flags" qui précisent la nature de la "pdu", et données optionnelles le drapeau "OPEN" (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 en attente d'une reponse de son correspondant et suspend toute activité.

appellera jeton une "pdu" qui ne comporte pas de donnees.

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

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<I>Agent'</I> étant identifiée par une paire de références ; un état bloqué, l'agent étant connecté et attendant une réponse de son 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 ou terminal), cet agent étant identifié par une référence éphémère pseudo- unique ; - l'agent client émet une pdu" <I>à</I> destination d'un agent serveur (dont la référence est connue par ailleurs) avec le drapeau "OPEN" positionné et l'agent client passe à l'état connecté ou bloqué selon la valeur du drapeau "BLOCK" ; et - l'agent serveur reçoit "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 " avec le drapeau "CLOSE" positionné (et qui comporte éventuellement des donnees ; et - l'autre agent reçoit une avec le drapeau<I>"CLOSE'</I> positionné (et qui comporte éventuellement données) et la session "S-Agent' passe à l'état déconnecté.

La figure 3 illustre façon schématique le diagramme d'états des sessions "S-Agent', telles elles viennent d'être rappelées.

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

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

De façon pratique, la carte à puce 2a est avantageusement "adressée" par utilisation d'une adresse "URL" (pour "Universel Resource Locator") définissant un rebouclage sur 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:ll127.0.0.1:8080 (1), dans laquelle 127.0.0.1 est l'adresse "1P" de rebouclage 8080 est le numéro port.

figure 4 illustre de façon simplifiée l'architecture logique système selon l'invention du type représenté sur la figure 2, mais décrite façon plus détaillée. carte à puce 2a comprend plusieurs agents, dont deux seulement ont été representés : un agent de type non précisément défini 232a1 et un agent 232a2, de type dit "WEB". La pile logique comprend, les couches de protocole inférieures, référencées 200a, répondant aux normes ISO 781 -3 (figure 2 CCal et CCa2), le gestionnaire de commandes "APDU" a1, et le multiplexeur de paquets 230a, ce dernier étant interfacé aux agents, notamment l'agent "WEB" 231 a2.

Du côté terminal 1, 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 11 (figure 2 : C1 et C2) d'accès au réseau (normes 1 et 2) et les couches de protocole "TCPIIP" (figure 2 : C3 et C4), référencees 100. Ces dernières couches sont interfacées avec le navigateur "WEB" L'autre pile comprend couches de protocole inférieures, référencées 101, repondant 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 , est représenté. Ce dernier, que l'on supposera de "type réseau", peut en outre communiquer, d'une part avec le navigateur 10, via les couches "TCPIIP" , d'autre part avec le réseau Internet Ri, via ces mêmes couches "TCPIIP" et l'organe 11, d'accès au réseau R!.

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

résumé, la fonction client/serveur "WEB", fournie par la carte à puce 2a, peut être réalisée par l'association de l'agent "WEB" 232a1 dans la carte à puce 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 à puce 2a présente donc bien la fonctionnalité client/serveur "WEB". outre, selon une caractéristique avantageuse 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 le terminal 1, soit un navigateur éloigné 4, localisé en un point quelconque du réseau Internet par la mise en ceuvre de sessions entre agents. Selon le procédé l'invention, les applications, à An, ne nécessitent pas d'être réécrites sont mises en oeuvre telles quelles.

Dans le cadre de l'invention, tout ou partie des applications A1<I>à An</I> peut être constitué par des applications associées à un ou plusieurs protocoles) "PE" et/ou un ou plusieurs protocole(s) "PL", et chargé dans une mémoire de la carte à puce 2a. Des données représentant un ou plusieurs profils "PA" peuvent également être stockées dans la carte à puce 2a.

La fonctionnalité client/serveur "WEB" offerte par la carte à puce 2a n'est pas suffisante pour qu'une application puisse s'exécuter. II est nécessaire de lui adjoindre une fonctionnalité supplémentaire.

En effet, selon un autre aspect de l'invention, la fonction serveur "WEB" offerte par la carte à puce 2a 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 de fonctionnement "CGI".

Le "CGI" est une spécification de mise en oeuvre, 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 "CGI 1.1 et pour le système d'exploitation "WINDOWS 95", la spécification est "CGI 1 Toujours à titre d'exemple, une requête "HTTP" pour une adresse "URL", du type "http host.comlcgi-binlxxx.cgi" (2), dans laquelle "host" se refè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é " et présent dans le répertoire "cgi-bin" de ce système hôte. Bien que le répertoire puisse être<I>a</I> priori quelconque, par convention, c'est le 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 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, requête est habituellement affichée sur un écran informatique sous la forme formulaire compris dans une page "HTLM". Le langage "HTLM" permet traduire un formulaire en une adresse "URL". Le formulaire comporte 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 cases à cocher ou les boutons dits "radio", etc. Le contenu du formulaire (ainsi qu'éventuellement des informations et instructions dites "cachées") est émis à destination du serveur "WEB". Le code "HTLM" de la page décrit la structure matérielle du formulaire (cadre, graphisme, couleur, et tout autre attribut), ainsi la structure des champs de données à saisir (nom, longueur, type de donnees, ).

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

Ce mécanisme est cependant pas directement transposable à une carte à puce, même ' celle-ci offre la fonctionnalité client/serveur "WEB" conformément à l'une des caractéristiques de l'invention. On 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 à des aspects de l'invention, on prévoit des agents intelligents particuliers, l'on appellera ci-après "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 de différentes manières alpar l'agent "WEB" 232a1 lui-même, est doté dans ce cas d'une double capacité<B>;</B> blpar un agent script unique capable traduire l'ensemble des scripts présents dans la carte à puce 2a ; clpar un agent de script dédié que appellera "ATSD" ci-après (un agent par script) ; ou dlpar un agent "APDU" 2010a du gestionnaire d'ordres "APDU" 201 a, qui 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 système, de sélectionner des applications, parmi Ai à<I>An,</I> mais également d'offrir interface de type agent intelligent. Elle est donc capable, selon l'une caractéristiques de l'invention de communiquer avec tous les agents intelligents (via des sessions), que ces agents soient localisés dans le terminal 1 ou carte a 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, à ATSn et associés aux applications Ai à<I>An.</I> L'application sélectionnée étant supposée être l'application A,, 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 ATS;, 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 ordres "APDU", ordres traduits et donc conventionnels, qu'elle en mesure comprendre. Cette application est donc correctement activee, sans avoir à modifier ou à la réécrire.

Les reponses 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).

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

procédé selon l'invention utilise les deux caractéristiques viennent d'être rappelées : fonctionnement de la carte à puce en tant serveur/client "WEB", incluant une fonction "CGI".

va maintenant décrire de façon détaillée les différentes phases étapes procédé selon l'invention par référence aux figures 6A à 8.

première phase concerne l'enregistrement d'un profil d'abonné dans un serveur d'annuaire particulier que l'on référencera SA; ci-après.

Dans une première étape, illustrée par la figure 6A, la carte à puce est adressee par le navigateur 10 du terminal 1, via les couches 13 et 23a. récupère, par une commande de type "GET" par exemple, un formulaire chargement à partir de la carte à puce 2a, formulaire en langage "HTML" l'on appellera arbitrairement "download.html".

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

à 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 etre affiché sur un écran 5 par l'intermédiaire du navigateur 10 et est référencé P sur la figure 6A qui illustre schématiquement ce processus. Ce formulaire constitue une page d'accueil pour l'internaute désirant s'enregistrer sur serveur d'annuaire. La carte à puce se comporte alors comme un serveur "WEB".

La page P peut comporter, de façon usuelle, différents éléments de type graphique ou de type texte, ainsi que des éléments interactifs de commande (bouton de type dit "radio", cases à cocher, zones d'entrées de données, etc.).

On va supposer, dans un premier temps que la carte à puce 2a n'offre, à son porteur (non représenté), que la possibilité de s'enregistrer sur serveur d'annuaire unique, référencé SA,,, et selon un profil unique d'abonné référencé PA,,. On suppose également que ce profil unique PA" est enregistré dans la à puce 2a. Dans cette hypothèse, le formulaire P (c'est-à-dire la page d'accueil) affiché sur l'écran 5, peut se réduire à une présentation minimale, dont la figure 6B illustre un exemple possible: formulaire P,.

Le formulaire P, comprend diverses zones de textes, sous la référence unique Zr. Ces zones affichent typiquement le nom "xxx" du serveur d'annuaire (SAu), l'action proposée<I>"enregistrement'</I> et diverses aides (par exemple<I>"cliquer</I> Puisque l'on a supposé que les données du profil d'abonné étaient enregistrées dans la carte à puce 2a, il suffit de prévoir un bouton d'envoi Bs. Le fait pour l'internaute de cliquer sur ce bouton à l'aide d'une souris (figure<B>1A:</B> 6b) ou d'appuyer sur la touche<I>"entrée"</I> d'un clavier (figure : 6a), déclenche l'envoi du formulaire vers la carte à puce 2a.

Dans une autre variante du procédé selon l'invention, les données afférentes au profil de l'abonné sont saisies directement par celui-ci. Dans cette hypothèse, le formulaire est plus complexe. La figure 6C illustre un exemple possible de formulaire, référencé P. II comprend une première zone texte fixe Zn, similaire à celle de la figure 6B (Zr) et une ou plusieurs zone(s) de saisie données, sous la référence unique Zr2. On prévoit comme précédemment un bouton d'envoi Bs, mais aussi avantageusement un bouton B,e, de ré- initialisation du formulaire P, qui permet d'effacer les données saisies en cas d'erreur. La ou les zones de saisies de données Zo peu(ven)t être du type dit "TEXTAREA" en langage "HTML" et présenter une facilite dite d' "ascenseur" pour l'affichage déroulant de textes longs Le code "HTML" nécessaire pour programmer un formulaire est bien connu en soi est à la portée de l'homme de métier. II n' pas nécessaire de le détailler nouveau. On peut cependant indiquer qu' contient notamment une ligne code en langage "HTML" qui se présente typiquement sous la forme < form action="http:l/127.0.01:80801cgi-smart/pe"> (4) dans laquelle http:l/127.0.01:8080 est l'URL de rebouclage de la relation (1), cgi-smart répertoire "CGI" précité contenant un script " " associé à une des applications stockées dans la carte à puce 2a, référencée exemple Ae. cette application permet l'enregistrement de l'abonné (internaute) sur l'annuaire SA" avec le profil PA". Cette action s'effectue de la manière décrite en regard de la figure 5, mise en ceuvre des fonctionnalités "CGI", d'une part, et client/serveur, d'autre part, offertes par la carte à puce 2a. L'application<I>AB</I> se comporte comme un client.

Dans premier cas (figure 6B), il n'est pas nécessaire de passer des paramètres à carte à puce 2a. En effet, les données de profil d'abonné PA" sont uniques enregistrées dans la carte à puce 2a.

Dans second cas (figure 6C), les données saisies sont passées en tant que parametres à la carte à puce 2a, sous la forme d'une requête "HTTP". La figure 6D illustre schématiquement le processus global de la phase d'enregistrement d'un internaute sur un serveur d'annuaire<B>SA,,,</B> constitué par un des serveurs (figures 2 ou 4).

La réference unique SvvEe regroupe différents modules de la figure 5 permettant à carte à puce 2a d'offrir les fonctionnalités combinées de client/serveur et de passerelle "CGI". On a également supposé que l'application permettant la mise en ceuvre du protocole d'enregistrement "PE" était associee a un agent traducteur de script dédié Ate <I>;.</I> il s'agit d'une configuration conforme à celle illustrée par la figure 5. Cependant, comme il a été indiqué, la traduction des scripts peut s'effectuer d'autres manières (par l'agent "WEB" 232a, (figure 5), etc. L'envoi du formulaire, par ouverture de sessions entre agents intelligents, va permettre d'activé l'application<B>A,,,</B> par l'intermédiaire de l'agent traducteur de script Ate.

Lors d'une étape ultérieure, l'application Ae pose une requete "HTTP" par ouverture de sessions entre paires d'agents intelligents, notamment impliquant un agent de type "réseau" (figure 5 : 132). La requête transmise au serveur d'annuaire SA", avec passage de paramètres. Les paramètres sont constitués notamment par les données de profil abonné PA", façon à permettre son enregistrement dans l'annuaire. L'adresse "URL" serveur d'annuaire est obtenue à partir du profil d'abonné SA" enregistré dans carte à puce ou à partir des données saisies dans le formulaire P.

priori, le processus d'enregistrement est terminé à ce stade. II peut cependant comprendre une ou plusieurs étapes supplémentaires. de ces étapes peut consister en l'envoi par l'annuaire d'un accusé de réception, sous forme d'une requête "HTTP" adressant la carte à puce 2a. L'accusé réception peut comprendre une information indiquant que l'inscription s'est déroulée de façon satisfaisante, ou au contraire un code d'erreur. Dans ce dernier cas, le processus d'enregistrement doit être répété. Le serveur peut requérir l'envoi de données manquantes ou la ré-émission de données incorrectes ou corrompues. La demande d'enregistrement peut également être rejetée, notamment si la limite de validité de l'abonnement est dépassée.

Dans une variante préférée du procédé selon l'invention, il possible, pour un internaute de s'enregistrer sur plusieurs annuaires différents. Dans cette variante de réalisation, il est en général nécessaire de disposer également de plusieurs protocoles d'enregistrement. Pour ce faire, plusieurs applications associées à ces protocoles sont stockées dans la carte à puce 2a, l'on peut référencer Ae,, <I>..., A.;,</I> ... Ae", en admettant que le nombre maximum de protocoles distincts est n.

Comme précédemment, les données associées aux profils d'abonné, que référencera PA,,<I>..., PA;, ...,</I> PA,,, peuvent être stockées dans la carte à puce ou au contraire fournis, au coup par coup, par l'internaute selon une méthode similaire à ce qui à été décrit en regard de la figure 6C, par saisie dans un formulaire approprié. q est le nombre maximum de profils d'abonné disponibles. On notera que q n'est pas forcément égal à n. En effet, un serveur d'annuaire donné, que l'on référencera arbitrairement SA;, peut accepter plusieurs occurrences distinctes d'un même abonné (internaute), d'une part. D'autre part, plusieurs serveurs d'abonné, bien que distincts, peuvent accepter un même profil d'abonné et éventuellement partager protocole d'enregistrement commun.

Pour fixer les idées, on va supposer que la carte à puce 2a stocke quatre profils d'abonnés distincts, PAA <I>à</I> PAD, chacun des profils permettant de s'enregistrer sur un seul serveur d'annuaire, soit SAA <I>à</I> SAD. Un formulaire, ou page d'accueil, référencé P3, permettant cet enregistrement, peut présenter comme illustré schématiquement par la figure 6E. il comprend première zone de texte d'en-tête Zte similaire à la zone de texte Zt de la figure 6B, éventuellement complétée par des zones graphiques. Il comprend quatre zones de textes supplémentaires, Zt" à ZtD , associée aux quatre serveurs d'annuaires, <I>à SAD..</I> Le formulaire permet de sélectionner un ou plusieurs, voire tous. Pour effectuer un choix entre ces serveurs d'annuaires, on peut prévoir zones dites "cases à cocher", CCA <I>à</I> CCD. A titre d'alternative, on peut prevoir des hyperliens sur la page d'accueil P3, chaque hyperlien adressant la à puce 2a par l'intermédiaire d'une dresse de rebouclage type de celle de relation (1), mais avec des paramètres distincts.

Comme dans le cas de la figure 6B, on prévoit un bouton d'envoi BS, permettant de transmettre le contenu du formulaire à la carte à puce 2a.

Quelle que soit la méthode utilisée pour effectuer la sélection de tout ou partie des serveurs d'annuaires, les paramètres passés à la carte à puce2a doivent permettre de sélectionner un ou plusieurs profils d'abonne, PAA <I>à</I> PAD, et dériver une ou plusieurs adresses "URL". Les actions demandées, par les paramètres passés à la carte à puce 2a, sont typiquement du type ?sa;=enr+pai (5), avec "sa; " le nom du serveur d'annuaire d'indice arbitraire ' parmi les n possibles, "enr" l'action requise d'enregistrement proprement dit "pai" le profil d'abonné à utiliser parmi les q possibles. Une ou plusieurs requêtes "HTTP" sont posées transmises aux serveurs d'annuaires concernés, SAA à SAD (figure 6E) et dans le cas général SAA <B><I>à SA,,</I></B> s'il existe n serveurs d'annuaire sélectionnables.

Le choix présenté sur la page d'accueil P3 est naturellement fonction de la carte à puce 2a insérée dans le lecteur 3. Les choix présentes dépendent des droits qui sont accordés à l'internante possesseur de la à puce 2a, notamment des abonnements souscrits à des services donnes et de leurs périodes de validité.

Une deuxième phase du procédé selon l'invention, c'est-à-dire la localisation, sur le réseau Internet, d'un internante associe à un identifiant quelconque peut se dérouler de façon très similaire à la phase d'enregistrement.

Pour ce faire, il est nécessaire d'interroger un ou plusieurs serveur(s) d'annuaire(s). Il est nécessaire aussi de disposer d'au moins un protocole "PL" spécifique localisation de cet internante. Enfin, s'il existe plusieurs serveurs d'annuaires interrogeables, SA, à SA,, il est généralement nécessaire également, comme dans le cas de l'enregistrement, de disposer de plusieurs protocoles localisation distincts.

protocoles de localisation peuvent être mis ceuvre à l'aide d'applications stockées dans la carte à puce 2a.

processus de localisation se déroule de façon tout à fait similaire à celui l'enregistrement de l'internante sur un ou plusieurs serveurs d'annuaire La seule exception notable est qu'un profil d'abonné<I>PA;</I> n'est plus explicitement requis. Il suffit de fournir à la carte à puce 2a l'identifiant de l'internante recherché et l'adresse du serveur d'annuaire SA;, ou pour le moins des parametres permettant à l'application associée à l'un des protocoles de localisation de déterminer cette adresse "URL". Un profil d'abonné<I>PA;</I> peut toutefois être utilisé pour en dériver automatiquement l'adresse "URL" du serveur d'annuaire SA; à l'aide duquel lequel un internante désire localiser un autre internante. Comme il a été indiqué, l'identifiant de l'internante recherché peut être adresse e-mel, adresse qui se présente typiquement sous la forme suivante avec "pseudo" le nom d'utilisateur de messagerie de l'internante plus généralement un pseudonyme, et "fournisseur. com" le nom et le suffixe du prestataire de service Internet",.com" pouvant être remplacé selon les cas par divers suffixes: ".fr", ".net", etc.).

La figure 7 illustre les principales étapes de la phase de localisation d'un internante par interrogation d'un annuaire SA; Dans une première étape la carte à puce 2a est adressée par le navigateur 10 du terminal 1, via les couches 13 et 23a. On récupère, par une commande de type "GET" par exemple, un formulaire de chargement à partir de la carte à puce 2a sous la forme d'une page d'accueil référencée P. Cette page d'accueil peut prendre différents aspects, similaires notamment à ceux décrits en regard des figures 6C ou 6E. Selon qu'il y ait un choix ou plusieurs choix possibles, l'internante sélectionne un ou plusieurs serveurs d'annuaires et fournit des données d'identification de l'internante recherché. Sur la figure 7, on a supposé qu'un seul serveur d'annuaire SA; était interrogeable.

La page est transmise sous forme d'une requête "HTTP" à carte à puce 2a et est interprétée par un agent traducteur de script<I>At,</I> associé à une application A, de mise en couvre de protocole "PL".

Par le double mécanisme client/serveur "WEB" et "CGI" (module référencé SvvES comme précédemment), une requête du type http:ll127.0.0.11? sa,[email protected] est interprétée par la carte à puce 2a comme une demande de localisation de l'internante dont l'identifiant est (6) sur le serveur d'annuaire sa;.

Une requête "HTTP" est transmise à ce serveur qui renvoie les informations demandées, dans la mesure où elles sont disponibles. recherche dans sa base de données une adresse "1P" correspondant données d'identification reçues. En cas de succès, c'est-à-dire si l'internante demandeur est effectivement enregistré, si cet internante a le droit d'obtenir cette adresse et si les données reçues sont correctes, les données retransmises comprennent l'adresse "1P" de l'internante recherché, ce qui permet de le localiser.

Ces différentes étapes mettent en couvre des sessions entre agents appariés, selon un des aspects de l'invention. On peut également stocker dans la à puce 2a plusieurs applications, chacune étant destinée à la mise oeuvre d'un protocole de localisation distinct, a priori associé à un serveur d'annuaire également distinct.

Dans une variante préférée du procédé selon l'invention, on stocke dans la carte à puce 2a des applications permettant la mise en oeuvre de plusieurs protocoles d'enregistrement, plusieurs protocoles localisation et des fichiers de données pour l'enregistrement de plusieurs profils d'abonné. Cette disposition avantageuse permet de transformer la carte à puce 2a en base de données portable multi-annuaire comme illustré schématiquement par la figure 8. Sur cette figure, le terminal 1 n'a pas éte représenté. II est cependant clair que celui-ci est nécessaire à la mise oeuvre du procédé selon l'invention.

Les protocoles d'enregistrement, les protocoles de localisation et les profils d'abonné portent les références uniques, PE,, PL,, et<I>PAZ,</I> respectivement, avec x le nombre de protocoles d'enregistrement, y le nombre de protocoles de localisation et z le nombre de profils d'abonnés distincts. Cet ensemble permet d'établir des connexions avec n serveurs d'annuaires distincts, soit pour y enregistrer un internante porteur de la carte à puce 2a, soit pour localiser un internante sur le réseau Internet Ri.

Dans une autre variante encore du procédé selon l'invention, l'utilisation d'une carte à puce 2a permet une authentification robuste de son possesseur, lors de la phase d'enregistrement et/ou de la phase de localisation. En effet, il est possible de stocker des données de sécurité dans la carte à puce 2a qui reste propriété de son possesseur. De telles donnés de sécurité peuvent être constituées par des clés de chiffrage.

Du fait que, selon l'un des aspects avantageux du procédé selon l'invention, la carte à puce peut communiquer directement avec le réseau Internet, par la mise en oeuvre de sessions entre agents intelligents, ces données n'ont pas à être transmises à un dispositif externe, serait ce le terminal 1. Les traitements touchant à la sécurité sont effectués directement par la carte à puce 2a. Cette façon de procéder offre donc un degré de sécurité beaucoup plus élevé que la simple utilisation de couches logicielles dites sécurisées des navigateurs "WEB" récents, connues sous l'abréviation anglo- saxonne "SSL" (pour "Secure Socket Layer").

L'authentification proprement dite peut s'effectuer en ayant recours à la technique dite de certificat, en association avec les clés de chiffrage précitées stockées dans la carte à puce. Cette procédure peut nécessiter des transactions supplémentaires entre la carte à puce 2a et le ou les serveur(s) d'annuaire concerné(s), à l'aide de requêtes "HTTP" transitant par le réseau Internet Ri. En fonction du résultat, positif ou négatif, de l'authentification, l'internante est autorisé ou non à effectuer les traitements, enregistrements ou localisations qu'il désire réaliser.

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

II permet notamment à un internante de s'enregistrer sur un ou plusieurs serveurs d'annuaires et/ou de localiser un internante sur le réseau Internet également par l'intermédiaire de un ou plusieurs annuaires. La carte à puce présentant les fonctionnalités combinées d'un client/serveur "WEB" et d'une passerelle "CGI", cette disposition permet des communications directes entre la carte à puce et le ou les serveurs d'annuaire. Elle autorise de ce fait le stockage des spécifiques nécessaires à la mise en couvre des protocoles d'enregistrement et/ou de localisation, ce qui permet une grande mobilité. Un ou plusieurs profils d'abonné peuvent également être stockés dans la carte à puce. L'internante n'est plus astreint à l'utilisation de terminaux configurés spécifiquement pour les protocoles précités.

En particulier, dans une variante de réalisation préférée, la carte à puce est transformée en base de données portable multi-annuaire.

Le procédé selon l'invention est tout à fait compatible avec l'existant. II n'est pas requis que l'internante recherché se soit enregistré sur un ou plusieurs serveurs d'annuaires en faisant usage du procédé selon l'invention. Les transmissions sur le réseau Internet s'effectuent selon les protocoles en vigueur et les communications entre le terminal et la carte à puce font appel au protocole normalisé "1S0" précité. On peut donc mettre en couvre un lecteur de carte à puce standard. Seule la présence d'une couche logicielle spécifique dans le terminal nécessaire, ce qui ne nécessite que peu de modifications et peut être réalise une fois pour toute, quel que soit le nombre de protocoles d'enregistrement, de localisation et/ou de profils d'abonné portés par la à puce, et quelle soient leurs natures.

Enfin, l'utilisation d'une carte à puce permet une sécurisation transactions et, notamment, une authentification "robuste".

11 doit etre clair cependant que l'invention n'est pas limitée aux seuls exemples de realisations explicitement décrits, notamment en relation avec figures 2 à 8.

En particulier, il n'est pas nécessaire que les deux séries de logiciels propriétaires, "PE" et "PL" soient stockées dans la carte à puce, bien que cette disposition soit particulièrement avantageuse. A titre d'exemple non limitatif, (les) phase(s) d'enregistrement, dans un ou plusieurs serveurs d'annuaire(s), pouvant être réalisée(s) une fois pour toute, ou pour le moins étant<I>a</I> priori moins fréquente(s) que les phases de localisation, on pourrait se contenter ne stocker dans la carte à puce que les applications spécifiques associees a cette dernière opération. De même, comme il a été indiqué, il est possible ne pas enregistrer dans la carte à puce les profils d'abonné "PA" (les données pouvant être fournies en temps réel au moment de l'enregistrement de l'abonné dans un serveur d'annuaire particulier). II est encore possible de n'enregistrer qu'une partie des profils d'abonné, profils qui pourront être fournis de façon automatique.

Claims (1)

1. <U>REVENDICATIONS</U> <B>1.</B> Procédé de mise en relation d'un premier usager avec moins un serveur d'annuaire, en vue de son enregistrement et/ou de la localisation d'au moins un deuxième usager sur un réseau notamment de type Internet, ladite mise en relation s'effectuant par l'intermédiaire d'un terminal muni lecteur de carte à puce et d'au moins une pièce de logiciel dite d'enregistrement et/ou de localisation, ledit terminal étant connecté à chacun desdits serveurs d'annuaire via ledit réseau de type Internet et communiquant avec ladite carte à puce selon un premier protocole déterminé, caractérisé en ce moins l'une desdites pièces de logiciel (Ae, A,) est stockée dans ladite carte a puce (2a) ; en ce que cette carte à puce (2a) comprenant une première pièce de logiciel (23a), formant une couche protocolaire de communication spécifique, et ledit terminal (1 comprenant une seconde pièce de logiciel (13), formant couche protocolaire de communication spécifique, lesdites première et seconde pièces logiciel (13, 23a) comprennent en outre au moins une paire premières entités logicielles appariées (132, 232a), chacune desdites entités 32, 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) ladite carte à puce (2a), et/ou ledit réseau de type Internet, de manière à ce ladite carte à puce (2a) offre la fonctionnalité d'un client/serveur "WEB" ; en que ladite carte à puce (2a) comprend au moins une deuxième entité logicielle (ATe, <I>AT,)</I> coopérant avec ladite seconde pièce de logiciel spécifique (23a) pour que ladite carte à puce offre une fonctionnalité d'interface passerelle dite "CGI" et en ce qu'il comprend au moins les étapes suivantes 1 / ouverture d'une première séquence 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 navigateur de type "WEB" récupère des données permettant de sélectionner et d'activer une desdites pièces de logiciel propriétaire (A.,<I>A,),</I> en vue de la sélection d'un desdits serveurs d'annuaire (SA;) ; ouverture d'une deuxième séquence d'échanges de donnees entre ladite carte à puce (2a) et ledit terminal (1) pour lui transmettre lesdites données ouverture d'une troisième séquence d'échanges de données entre ledit terminal (1) et ladite carte à puce (2a) pour transmettre données de sélection et des paramètres optionnels, lesdites donnees et lesdits paramètres optionnels comportant une référence à une desdites pièces de logiciel d'enregistrement et/ou de localisation ; mise en ceuvre de ladite fonctionnalité "CGI" et exécution ladite pièce de logiciel d'enregistrement et/ou de localisation (AB, A,) ; et en résultat de ladite exécution, ouverture d'une quatrième séquence d'échanges de données entre ladite carte à puce (2a) et un desdits serveurs d'annuaire (SA;), sélectionné par lesdites données de sélection, de manière à transmettre une requête pour la réalisation d'une opération déterminée d'enregistrement ou de localisation. <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 01, 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) établissant lesdites sessions. <B>3.</B> Procédé selon la revendication 2, caractérisé en ce que ladite suite d'instructions à interpréter associée à chacune desdites pièces de logiciel propriétaire constituée par un script et en ce que ladite deuxième entité logicielle constituée par un module logiciel dit agent intelligent traducteur de script AT,) fournissant des ordres compréhensibles par pièces de logiciel proprietaire (Ae, A,),. <B>4.</B> Procédé selon la revendication 1, caractérisé en ce que ladite étape 1/ comprend l'émission d'une requête de type dit "HTTP" selon un protocole de type Internet adressage d'une page déterminée (P,-P) en langage "HTML" contenant lesdites données de sélection et des paramètres optionnels, ladite adresse étant une adresse de type "URL" de rebouclage sur ladite carte a puce (2a). <B>5.</B> Procédé selon la revendication 1, caractérisé en ce que ladite étape 2/ comprend l'envoi par ladite carte à puce (2a) d'un formulaire en langage "HTML" (P,- et en ce que ledit formulaire comprend au moins une adresse de type dit "URL" de rebouclage sur ladite carte à puce (2a) et un chemin menant à un repertoire déterminé associé à l'une desdites pièces de logiciel d'enregistrement et/ou de localisation<I>(AB, A,),</I> à lui transmettre lesdits paramètres optionnels et à occasionner son exécution. <B>6.</B> Procédé selon la revendication 5, caractérisé en ce que ladite étape 3/ comprend l'envoi d'une requête de type dit "HTTP" à ladite adresse "URL", désignant ledit répertoire contenant ladite pièce de logiciel d'enregistrement et/ou de localisation <I>(A., A,),</I> ladite requête comprenant lesdites données de sélection et lesdits paramètres optionnels. <B>7.</B> Procédé selon la revendication 6, caractérisé en ce qu'une pièce de logiciel dite d'enregistrement (AB) est associée à un premier protocole (PE,) permettant l'enregistrement dudit usager sur un serveur d'annuaire déterminé (SA;), en ce lesdits paramètres optionnels sont constitués des données définissant un profil dit d'abonné<I>(PAZ),</I> comprenant au moins des données dites d'identification dudit premier usager, et en ce ladite requête "HTTP" de ladite étape 3l comprend des premières données indiquant l'opération demandée est ledit enregistrement des deuxièmes données permettant d'élaborer, par ladite pièce de logiciel d'enregistrement (Ae), une adresse de type "URL" caractéristique dudit serveur d'annuaire déterminé (SA;), et en ce que des données associees au dit profil d'abonné sont transmises, pendant ladite étape 4l, à ce serveur d'annuaire (SA;), de manière à réaliser ledit enregistrement dudit premier usager, ledit enregistrement comprenant la détermination d'une adresse de type "1P" association de ladite adresse de serveur d'annuaire (SA;) et desdites données d'identification dudit premier usager. <B>8.</B> Procédé selon la revendication 7, caractérisé en ce que ledit profil d'abonnée (PAZ) est stocké dans ladite carte à puce (2a). <B>9.</B> Procédé selon la revendication 8, caractérisé en ce que plusieurs profils d'abonnés (PAZ) sont stockés dans la dite carte à puce (2a) et en que ladite requête "HTTP" de ladite étape 3l comprend des données permettant de sélectionner un desdits profils d'abonné<I>(PAZ).</I> <B>10.</B> Procédé selon la revendication 7, caractérisé en ce que ledit profil d'abonné (PAZ) est saisi par un opérateur sur des moyens d'entrée de données (6a) et transmis à ladite carte à puce (2a) comme paramètres pendant ladite étape 3l. <B>11.</B> Procédé selon la revendication 7, caractérisé en ce que plusieurs pièces distinctes de logiciel d'enregistrement (Ae) sont stockées dans ladite carte à puce (2a), associée chacune à un protocole d'enregistrement déterminé (PE,), de manière à permettre ledit enregistrement d'usager sur plusieurs serveurs d'annuaire de caractéristiques déterminées (SA,-SA"). <B>12.</B> Procédé selon la revendication 7, caractérisé en ce qu'il comprend au moins une étape supplémentaire consistant à l'envoi à ladite carte à puce (2a) d'un acquittement ou d'un code d'erreur. <B>13.</B> Procédé selon la revendication 12, caractérisé en ce qu'il comprend des étapes supplémentaires consistant en des échanges de données entre un desdits serveurs d'annuaire (SA;) et ladite carte à puce (2a), de manière à authentifier celle-ci ou ledit premier usager, et en ce que ladite authentification met en ouvre un certificat et au moins une clé de chiffrement stockée dans ladite carte à puce (2a). <B>14.</B> Procédé selon la revendication 6, caractérisé en ce qu'une pièce de logiciel dite de localisation <I>(A,)</I> est associée à un second protocole (PLy) permettant la localisation d'au moins un deuxième usager sur ledit réseau de type Internet (RI), ledit deuxième usager étant enregistré sur un serveur d'annuaire déterminé (SA;), en ce que ce dit enregistrement comprend au moins des données dites d'identification dudit deuxième usager, en ce ladite requête "HTTP" de ladite étape 3/ comprend des premières donnees indiquant que l'opération demandée est ladite localisation, des deuxièmes données identifiant ledit deuxième usager à localiser et des troisièmes données permettant d'élaborer, par ladite pièce de logiciel de localisation une adresse de type "URL" caractéristique dudit serveur d'annuaire déterminé (SA;), et en ce que des données identifiant ledit deuxième usager sont transmises, pendant ladite étape 4/ à ce serveur d'annuaire (SA;), manière à réaliser ladite localisation dudit deuxième usager, par la recherche d'une adresse de type "1P", en associant lesdites données d'identification ce deuxième usager, reçues par ledit serveur d'annuaire (SA;), à données d'enregistrement stockées dans celui-ci, et la retransmission ladite adresse de type "1P" à ladite carte à puce (2a), de manière à permettre ladite localisation. <B>15.</B> Procédé selon la revendication 14, caractérisé en ce que plusieurs pièces distinctes de logiciel de localisation (A,) sont stockées dans ladite carte à puce (2a), associé chacun à un protocole de localisation déterminé (PLy), de manière à permettre chacune ladite localisation d'au moins un deuxième usager sur ledit réseau de type Internet (RI), par sélection, parmi plusieurs -SA"), d'un serveur d'annuaire (SA,) de caractéristiques déterminées. <B>16.</B> Carte à puce destinée à coopérer avec un terminal muni d'un lecteur de carte à puce, pour la mise en relation d'un premier usager avec au moins un serveur d'annuaire, en vue de son enregistrement et/ou de la localisation d'au moins un deuxième usager sur un réseau notamment de type Internet, à l'aide de protocoles d'enregistrement et/ou de localisation determinés, caractérisé en ce que ladite carte à puce (2a) stocke au moins pièce de logiciel (Ae, A,) associée aux dits protocoles déterminés d'enregistrement et de localisation, en ce que cette carte à puce (2a) ) comporte une pièce de logiciel (23a), formant une couche protocolaire de communication spécifique, comprenant en outre au moins une premiere entité logicielle autonome (S,), de type dit client et une deuxième entité logicielle autonome (S2), de type dit serveur, lesdites entités (S2, S2) coopérant de manière à ce que ladite carte à puce (2a) offre la fonctionnalité d'un client/serveur de type "WEB" et à permettre ladite mise en relation d'un premier usager avec au moins un serveur d'annuaire (SA;), via ledit reseau de type Internet (RI), et en ce que ladite carte à puce (2a) comprend moins une deuxième entité logicielle (ATe, AT,) coopérant avec ladite pièce de logiciel spécifique (23a), pour que ladite carte à puce (2a) offre une fonctionnalité d'interface passerelle dite "CGI" permettant l'exécution desdites pièces de logiciel (AB,<I>A,)</I> associées aux dits protocoles déterminés d'enregistrement et de localisation. <B>17.</B> Carte à puce selon la revendication 16, caractérisé en ce que ledit enregistrement s'effectuant à l'aide de données dites de profil d'abonné, décrivant des caractéristiques associées aux dits abonnés, au moins un jeu de données de profil d'abonnés (PAZ) est stocké dans ladite carte à puce (2a).