EP1169839A1

EP1169839A1 - Method for registering a user on an internet-type network directory server and/or for locating a user on said network, and smart card therefor

Info

Publication number: EP1169839A1
Application number: EP01907762A
Authority: EP
Inventors: Pascal Urien
Original assignee: Bull CP8 SA
Current assignee: CP8 Technologies SA
Priority date: 2000-02-10
Filing date: 2001-02-09
Publication date: 2002-01-09
Also published as: WO2001060026A1; AU3565001A; KR100723006B1; FR2805108B1; TW567700B; FR2805108A1; CA2366570A1; CN1363174A; US20020124092A1; US7194545B2; AU782179B2; KR20020005683A; US20070208586A1; CN1161942C; JP2003523033A

Abstract

The invention concerns a method for registering a user on the directory and/or locating a cybernaut on an Internet-type network (RI), by interrogating a directory server (SAi), so as to determine an IP address associated with said cybernaut. The method consists in using a smart card (2a) storing applications (Al) each associated with a registering and/or locating protocol (PL). Subscriber profiles can be stored in the smart card (2a). Several different protocols can be stored, transforming the smart card (2a) into a multiple-directory database. The card (2a) is provided with WEB client/server and CGI functional capabilities, so as to be able to initiate transmissions in accordance with Internet protocols between directory server (SAi) and the smart card (2a), and activate the applications (Al) stored therein, for the process of registering and/or locating protocols (PL). The invention also concerns the related card.

Description

Method for registering a user on a directory server of an Internet type network and / or for locating a user on this network, and smart card for implementing the method

The invention relates to a method of registering a user on a directory server of a network, in particular of the Internet type and / or of locating a user on such a network, using smart cards connected. terminals equipped with a smart card reader.

The invention also relates to a smart card for implementing this method.

In the context of the invention, the term "Internet network" must be understood in its most general sense. It concerns, in addition to the Internet itself, corporate or similar private networks, of the so-called "intranet" type, and networks extending them outwards, of the so-called "extranet" type, and generally any network in which data exchanges are carried out according to an Internet type protocol. In what follows such a network will be called generically "Internet network".

Likewise, the term "terminal" should be understood in a general sense. The aforementioned terminal can in particular be constituted by a personal computer operating under various operating systems, such as WINDOWS or UNIX (both being registered trademarks). It can also consist of a workstation, a laptop or a so-called dedicated card terminal. In the more particular context of the invention, there are also dedicated Internet terminals, having only a minimum of own IT resources, or even no permanent storage means, of the hard disk type.

It first appears useful to briefly recall the main characteristics of communication protocols on networks. The architecture of communication networks is described by various layers. For example, the standard "OSI"("Open System Interconnection "), defined by" ISO ", comprises seven layers which go from the so-called low layers (for example the so-called" physical "layer which relates to the physical transmission medium) to the so-called high layers (for example the so-called" d 'application "), passing through intermediate layers, in particular the so-called" transport "layer. A given layer offers its services to the layer immediately above it and requires other services from the layer which is immediately below it, via appropriate interfaces. Layers communicate using primitives. They can also communicate with layers of the same level. In some architectures, several layers may be nonexistent.

In an Internet-type environment, there are five layers, and more precisely, going from the upper layer to the lower layer: the so-called application layer ("http", "ftp", "e- mail ", etc.), the so-called transport layer (" TCP "), the so-called network addressing layer (" IP "), the so-called data link layer (" PPP "," Slip ", etc.) ) and the so-called physical layer.

In the known art, a user, who will be called hereinafter "Internet user", uses Internet terminals which have a fixed "IP" address, or variable when using an Internet service provider, generally known by the acronym "ISP" (for "Internet Service Provider).

A first drawback is constituted by the fact that an "IP" address is not associated with an Internet user, but with a computer system connected to the Internet. Even if the computer system has a fixed address, there is no a priori correspondence between an "IP" address and a natural person. To establish such a relationship, the user connects to so-called "IRC" servers (for "Internet Relay Chat"). These servers associate an identifier of the Internet user, known as "UserlD", with his "IP" address. The identifier is generally constituted by its e-mail address, or "e-mail" according to English terminology, but any pseudonym can also be used. Below, the servers "IRC" will be called more generally "directory servers", which will simply be called "SA".

This association is generally not authenticated so that the service (generally free) can be used in the most convenient way possible. This arrangement is not, however, free from drawbacks, in particular for so-called "sensitive" applications.

One of the first constraints encountered is therefore the location of an Internet user on the Internet, that is to say the establishment of a correspondence between a fixed identifier and an "IP" address. However, the location of an Internet user on the Internet, that is to say the establishment of the aforementioned correspondence, presupposes that he has been previously registered in the directory server "SA".

The address of an Internet user on the Internet therefore consists of the pair: "Address SA" - "UserlD". Usually, "subscriber" means a "physical" entity. By extension, it can be a

"function". However, below, "subscriber" will be given his or her common sense, without this being in any way limiting the scope of the invention.

In practical terms, a user indicates his location on the Internet by a voluntary act by supplying the server (directory) with his current "IP" address using a registration protocol which will be called below " PE ".

This operation implies that the terminal has specific software (or application) delivered by the service provider, and personalized with a particular subscriber profile, which will be called "PA" below. This "PA" profile allows a more complete identification of a subscriber

(or Internet user), in addition to its basic identifier "UserlD".

The term "Subscriber Profile"("PA") is generally used to denote all the information which is supplied to the directory server "SA" when the subscriber (internet user) is registered, and for example: - l address of the "Directory Server"("SA"); the subscriber identifier ("UserlD"); subscribers (identified by their "UserlD") with which the user accepts to communicate or to whom he wishes to notify his location in the network; and the information it accepts to make public on the directory server (for example: name, nationality, contacts sought, etc.). ;

To reach a correspondent through the Internet, this correspondent being duly registered, it is necessary to know their "IP" address. This information is obtained using a directory server ("SA") and a location protocol ("PL").

It should be noted that the subscriber profile "PA" is, by nature, specific to the subscriber, but may also depend on the characteristics of the directory server, in particular on the type and nature of the information which must be supplied to it or that he can accept. Finally, it should be noted that the "PL" protocol is, like the protocol

"PE", of the so-called owner type, since it addresses a directory server which is a priori non-standardized or which meets universally recognized standards.

These two characteristics constitute additional disadvantages. In summary of what has just been recalled, for a first Internet user to be able to locate other Internet users and to be located by them, it is necessary that the terminal that he uses stores specific software making it possible to set up implements the "PE" and "PL" protocols. It may also be necessary for it to store data relating to its subscriber profile "PA". This remark applies similarly to the terminals of other Internet users.

In other words, the terminal used by any subscriber is also specific, in the sense that, if this subscriber wishes to change terminal, he must find on the new terminal used, at least the software or software associated with the "PL protocol ", admitting that it has carried out a preliminary phase of registration on the first terminal, by appealing to the "PE" protocol and by providing its "PA" profile to the "SA" directory server. Indeed, the presence of the "PL" protocol will be necessary to address the directory server and have access to the data recorded in it, in particular the "IP" addresses of the correspondents sought and their "SA" profiles.

It would therefore be interesting to use standard terminals to carry out the operations of recording and, above all, locating Internet users on the Internet, which would allow convenient access to the concept called "nomadism". The software associated with the aforementioned protocols, "PE" and "PL" does not usually require a large amount of memory. The same applies to "PA" profile data. One could therefore think of recording them in the memory circuits of a smart card, which allows current technology. However, there is a double technical difficulty, as will be shown below, which prohibits any direct communication between the Internet and a smart card.

We will first of all briefly recall the general architecture of a smart card-based application system, connected to an Internet network, with reference to FIGS. 1A and 1B.

A smart card-based application system generally has the following main components: a smart card; a host system constituting the aforementioned terminal; - a communication network, namely the Internet network in the preferred application; and an application server connected to the Internet.

FIG. 1A schematically illustrates an example of architecture of this type. The terminal 1, for example a personal computer, includes a smart card reader 3. This reader 3 may or may not be physically integrated into the terminal 1. The smart card 2 has an integrated circuit 20 whose input-output connections are flush with the surface of its support to authorize a supply of electrical energy and communications with the terminal 1. The latter comprises access circuits 11 to the Internet network RI. These circuits can be constituted by a modem to connect to a switched telephone line or to a higher speed communication channel: integrated services digital network ("ISDN"), cable or satellite links, etc. The circuits 11 allow connection to the Internet RI network, directly or via an Internet service provider ("Internet Service Provider" or "ISP", according to English terminology). One can also have recourse to an intermediate system such as a "proxy" or an isolation system called "firewall"("firewall" or also called "barrier guard").

Terminal 1 naturally includes all the circuits and organs necessary for its proper functioning, and which have not been shown for the purpose of simplifying the drawing: central unit, random access memory and fixed memory, mass memory with magnetic disk, floppy drive and / or CédéRom, etc.

Usually, the terminal 1 is also connected to conventional peripherals, integrated or not, such as a display screen 5, a keyboard 6a and a mouse 6b, etc.

The terminal 1 can be put in communication with servers or all computer systems connected to the RI network, of which only one, 4, is illustrated in FIG. 1 A. The access circuits 11 put the terminal 1 in communication with the servers 4 thanks to a particular software 10, called "WEB" browser, or "browser" according to English terminology. This allows access to various applications or data files distributed over the entire RI network, generally in a "client-server" mode.

Usually, communications on networks are carried out in accordance with protocols meeting standards comprising several superimposed software layers. In the case of an Internet-type IR network, communications are carried out according to protocols specific to this type of communications, which will be detailed below, but which also include several software layers. The communication protocol is chosen according to the application more particularly targeted: interrogation of "WEB" pages, file transfers, electronic mail (e-mel, or "e-mail" according to Anglo-Saxon terminology), forums or "news", etc.

The logical architecture of the system comprising a terminal, a smart card reader and a smart card is represented diagrammatically in FIG. 1 C. It is described by the ISO 7816 standard, which itself comprises several sub-assemblies:

ISO 7816-1 and 7816-2, with regard to the dimensions and marking of cards;

ISO 7816-3, with regard to the transfer of data between the terminal and the smart card; and - ISO 7816-4, with regard to the structure of the command set and the format of the commands.

In FIG. 1B, on the terminal side 1, only the layers meeting the ISO 7816-3 standard, referenced 101, and a "APDU" order manager (ISO 7816-4 standard), referenced 102, have been represented. On the smart card 2 side, the layers corresponding to ISO 7816-3 are referenced 200 and the "ADPU" order manager (ISO 7816-4 standard) is referenced 201. The applications are referenced A- \,. .., Aj, ..., An; n being the maximum number of applications present on the smart card 2.

An application, Aj, present in the smart card 2, dialogues with the terminal 1 by means of a set of orders. This game typically presents writing orders and reading orders. The order format is known by the English abbreviation of "APDU" (for "Application Protocol Data Unit"). It is defined by the aforementioned ISO 7816-4 standard. A command "APDU" is noted "APDU.command" and a response "APDU" is noted "APDU.response". The "APDU" are exchanged between the reader card and smart card using a protocol specified by the above-mentioned ISO 7816-3 standard (for example in character mode: T = 0; or in block mode: T = 1).

When the smart card 2 includes several distinct applications, as illustrated in FIG. 1B, we speak of a multi-application card.

However, terminal 1 only dialogs with one application at a time.

The selection of a particular Aj application is obtained using an "APDU" of the selection type ("SELECT"). Once this choice has been made, the

"APDUs" that follow are routed to this application. A new "APDU SELECT" has the effect of abandoning the current application and choosing another one. The “APDU” manager software sub-assembly 201 makes it possible to choose a particular application A \ in the smart card 2, to store the application thus chosen, and to transmit and / or receive “APDUs” to and from this application. . In summary of what has just been described, the selection of an application

Aj and the dialogue with it are carried out by exchanges of "APDU" orders. It is assumed that the Aj applications are conventional applications, which will be called hereinafter "GCA" (for "Generic Card Application"). These reminders being made, it should be noted that the smart card 2 cannot communicate directly with standard commercial browsers 10, unless the code of the latter is modified.

In addition, and above all, current smart cards, which moreover comply with the standards and norms recalled above, have a hardware and software configuration which also does not allow direct communication with the Internet. In particular, they cannot receive and transmit data packets, according to one or the other of the protocols used on this type of network. It is therefore necessary to provide an additional piece of software, located in terminal 1, generally in the form of what is called a "plug-in", according to the Anglo-Saxon terminology. This piece of software, which bears the reference 12 in FIG. 1A, performs the interface between the browser 10 and the card 2, more precisely the electronic circuits 20 of this card 2.

The invention aims to overcome the drawbacks of the methods and devices of the known art, and some of which have just been recalled, while meeting the needs which are felt.

According to an advantageous embodiment of the invention, the applications necessary for the implementation of the recording ("PE") and location ("PL") protocols, as well as the data characterizing the subscriber profile (" PA ") are files stored, in whole or in part, in memories of a smart card, the executable type files being standard applications of the aforementioned" GCA "type.

According to the invention, the smart card behaves like a server / client of the "WEB" type for the terminal associated with it. To do this, a specific communication software layer is provided in the smart card and its counterpart in the terminal. The term "specific" should be understood as specific to the process of the invention. Indeed, these layers of communications, called specific, are trivialized whatever the application considered. In particular, they are independent of the applications necessary for the implementation of the "PE" and "PL" protocols. They only intervene in the two-way data exchange process between the smart card and the terminal, on the one hand, and the smart card and the network, on the other hand.

The specific communication software layers notably comprise software components, called "intelligent agents", allowing in particular protocol conversions. The intelligent agents will be referred to hereinafter more simply as "agents". There are agents paired in the respective specific communication layers associated with the terminal and the smart card. According to the method of the invention, sessions are established between paired agents. Advantageously, the method of the invention makes it possible to activate applications of conventional type, that is to say of the aforementioned "CGA" type, located in a smart card, without having to modify them in any way. . To do this, one or more particular intelligent agents known as script translators are provided, which receive requests from a browser and translate them into "APDU" orders understandable by the "CGA" type application. Therefore, a function similar to that known elsewhere under the name "CGI" is implemented in the smart card in conventional "WEB" servers. This function makes it possible to implement an application in the smart card by an Internet protocol of the "HTTP" type.

These various arrangements allow the smart card, and more precisely the applications present therein, to communicate directly with a remote server connected to the Internet by implementing Internet-type protocols. The "CGI" functionality offered by the smart card allows access to the applications associated with the "PE" and "PL" protocols and their execution, without requiring the presence of proprietary type applications in the terminal. Only a browser, advantageously of the standard commercial type, is necessary.

In a preferred embodiment of the invention, there are stored in the smart card several sets composed of applications associated with "PE" and "PL" protocols and / or distinct "PA" subscriber profiles.

This advantageous arrangement makes it possible, on the one hand, to register several distinct "PA" subscriber profiles or several distinct occurrences of the same "PA" subscriber profile on the same "SA" directory server, and locate these entities by associating them with unique "IP" addresses. It also makes it possible to be able to address several "SA" directory servers, with the same and / or several distinct "PA" subscriber profiles. The smart card then presents a multi-directory database functionality. The main object of the invention is therefore a method of putting a first user into contact with at least one directory server, with a view to registering and / or locating at least one second user on a network in particular. of the Internet type, said connection being effected by means of a terminal provided with a smart card reader and at least one piece of software called recording and / or location software, said terminal being connected to each of said directory servers via said Internet type network and communicating with said smart card according to a first determined protocol, characterized in that at least one of said pieces of software is stored in said smart card; in that this smart card comprising a first piece of software, forming a specific communication protocol layer, and said terminal comprising a second piece of software, forming a specific communication protocol layer, said first and second pieces of software further comprise at least one pair of first paired software entities, each of said entities cooperating with each other so as to allow the establishment of a bidirectional data exchange session between at least said terminal and said smart card, and / or said Internet-type network, so that said smart card offers the functionality of a "WEB" client / server; in that said smart card comprises at least a second software entity cooperating with said second specific piece of software so that said smart card offers a so-called "CGI" gateway interface functionality: and in that it comprises at least the following steps: 1 / opening of a first sequence of data exchanges between at least said terminal and said smart card, for the transmission of a request for said browser of type "WEB" to recover data making it possible to select and activate one of said pieces of proprietary software, with a view to selecting one of said directory servers; 2 / opening of a second sequence of data exchanges between said smart card and said terminal to transmit said data to it; 3 / opening of a third sequence of data exchanges between said terminal and said smart card to transmit selection data and optional parameters, said data and said optional parameters comprising a reference to one of said pieces of recording software and / or location; 4 / implementation of said "CGI" functionality and execution of said piece of recording and / or localization software; and

5 / as a result of said execution, opening of a fourth sequence of data exchanges between said smart card and one of said directory servers, selected by said selection data, so as to transmit a request for carrying out a specific registration or localization operation.

The invention also relates to a smart card for the implementation of this method.

A preferred, but not limiting, embodiment of the invention will now be described in more detail with reference to the accompanying drawings, among which: FIGS. 1A and 1B illustrate the hardware and logic architectures, respectively, of a example of a smart card-based application system connected to an Internet network according to known art

- Figure 2 schematically illustrates an example of application system based on smart card according to the invention, the latter acting as client / server "WEB", according to one aspect of the invention; Figure 3 is a state diagram of a session between software entities called intelligent agents, according to one aspect of the invention; FIG. 4 ilii stre in a simplified manner the logical architecture of a system according to the invention in which the smart card comprises intelligent agents; FIG. 5 illustrates in a simplified way the logical architecture of a system according to another aspect of the invention according to which the smart card comprises intelligent agents translating scripts, so as to implement a so-called "CGI"function; FIG. 6A schematically illustrates a first step in the phase of registering an Internet user on a directory server; - Figures 6B and 6C illustrate examples of "HTLM" forms usable for this recording phase;

- Figure 6D schematically illustrates the main steps of the registration phase of a user on a directory server; FIG. 6E schematically illustrates the main steps of the registration phase of an Internet user with several directory servers;

- Figure 7 schematically illustrates the main steps of the phase of locating a user on the Internet by interrogating a directory server; and - Figure 8 schematically illustrates a smart card architecture according to the invention having a portable multi-directory database functionality.

FIG. 2 schematically illustrates an example of a smart card-based application system according to a first aspect of the invention, enabling the latter to act as a client / server "WEB.

With the exception of specific communication protocol software layers, referenced 13 and 23a, respectively located in the terminal 1 and the smart card 2a, the other elements, hardware or software, are common to the known art, in particular this which has been described with reference to FIGS. 1 A and 1 B, and there is no need to re-describe them in detail. The terminal 1 comprises circuits 11 for access to the RI network, consisting for example of a modem. These circuits group together the lower software layers, Ci and C2, which correspond to the "physical" and "data link" layers. Also shown are the upper layers, C3 and C4, which correspond to the "network addressing"("IP", in the case of the Internet) and "transport"("TCP") layers. The upper application layer ("http", "ftp", "e-mail", etc.) has not been shown.

The interface between the lower layers, Ci and C2, and the upper layers, C3 and C4, is constituted by a software layer generally called "low layer driver". The upper layers, C3 and C4, rely on this interface and are implemented by means of specific function libraries or network libraries 14, with which they correspond. In the case of the Internet, "TCP / IP" is implemented by means of libraries known as "sockets".

This organization allows a browser 10 to make requests to a server 4, for consulting "WEB" pages ("HTTP" protocol), for transferring files ("FTP" protocol) or sending electronic mail ( "e-mail" protocol), in a completely classic way in itself.

The terminal 1 also includes a card reader 3, integrated or not. To communicate with the smart card 2a, the card reader 30 also includes two lower layers, CC1 (physical layer) and CC2 (data link layer), playing a role similar to layers Ci and C2. The software interfaces with the layers CC1 and CC2 are described, for example, by the specification "PC / SC" ("part 6, service provider"). The layers themselves, CC1 and CC2, are in particular described by ISO standards 7816-1 to 7816-4, as has been recalled.

An additional software layer 16 forms the interface between the application layers (not shown) and the lower layers, CC1 and CC2. The main function assigned to this layer 16 is a multiplexing / demultiplexing function.

The communications with the smart card 2a take place according to a paradigm similar to that used for the manipulation of files in an operating system of the "UNIX" type (registered trademark): OPEN ("OPEN"), READ ("READ "), WRITE, CLOSE, etc.

On the side of the smart card 2a, there is a similar organization, namely the presence of two low layers, referenced CCai (physical layer) and CCa2 (data link layer), as well as an interface layer 26a, quite similar to layer 16.

According to the invention, provision is made, on either side, that is to say in the terminal 1 and in the smart card 2a, two layers of specific protocols: 13 and 23a, respectively.

In terminal 1, the specific layer 13 interfaces with the "low layer drivers" 15, with the libraries 14 of the network layers, C3 and C4, and with the protocol layers of the card reader 3, that is to say the layers lower, CC1 and CC2, via the multiplexing layer 16. The specific layer 13 allows the transfer of network packets to and from the smart card 2a. In addition, it adapts existing applications such as the Internet browser 10, e-mail, etc., for uses implementing the smart card 2a.

On the side of the smart card 2a, there is a completely similar organization constituted by an additional instance of the specific layer, referenced 23a, pendant from the layer 13. More specifically, the specific layers, 13 and 23a, are subdivided into three main software elements: a module, 130 or 230a, for transferring blocks of information between layers 13 and 23a, via the conventional layers CC1, CC2, CCai and CCa2; one or more pieces of software, called "intelligent agents", 132 or 232a, which perform, for example, protocol conversion functions; and a specific configuration management module, 131 and 231a, respectively; module which can be likened to a particular intelligent agent.

For simplicity, intelligent agents will hereinafter be called "agents", as has been previously indicated.

There is therefore, in the terminal 1 and the smart card 2a, a protocol communication stack between the two entities.

Level two layers (data link layers), CC2 and

CCa2, ensure the exchange between the smart card 2a and the terminal 1. These layers are responsible for the detection and possible correction of transmission errors. Different protocols can be used, and as non-exhaustive examples the following:

- the ETSI GSM 11.11 recommendation;

- the protocol defined by the ISO 7816-3 standard, in character mode

T = 0; the protocol defined by standard ISO 7816-3, in block mode T = 1

- or the protocol defined by ISO standard 3309, in "HDLC" frame mode (for "High-Level Data Link Control procedure" or high-level link control procedure).

Within the framework of the invention, the ISO 7816-3 protocol will preferably be used, in block mode.

In a manner known per se, each protocol layer is associated with a certain number of primitives which allow the exchange of data between layers of the same level and from one layer to another. For example, the primitives associated with the layer of level two are of the type "data request"("ϋata.request") and "data sending" by card {"Data.response"), as well as "data confirmation"{"Data.confirm"), etc. More specifically, the layers 13 and 23a are responsible for the dialogue between the smart card 2a and the host, that is to say the terminal 1. These layers allow the exchange of information between a user (not shown) of terminal 1 and the smart card 2a, for example via drop-down menus in the form of hypertext in "HTML" format. They also allow the setting up of a configuration suitable for the transmission and / or reception of data packets. As noted above, the layers include three separate entities.

The first layer, 130 or 230a, is essentially constituted by a software multiplexer. It allows the exchange of information between the smart card 2a and the host terminal 1, in the form of protocol data units. It plays a role similar to that of a data packet switch. These units are sent or received via the level two layer (data link layer). This particular communication protocol makes it possible to put at least one pair of "agents" into communication. The first agent of each pair, 132, is located in layer 13, on the terminal side 1, the second, 232a, is located in layer 23a, on the smart card side 2a. A link between two "agents" is associated with a session, which can be called "S-Agent". A session is a two-way data exchange between these two agents. If one or other of the layers, 13 and 23a, comprises several agents, the agents of the same layer can also establish sessions with each other and / or with the modules 131 and 231a, which constitute particular agents.

More specifically, an agent is an autonomous software entity which can perform all or part of the functions of the layers of levels three and four, depending on the configuration implemented by the terminal 1. Agents are associated with particular properties or attributes. To fix the ideas, and by way of nonlimiting example, the following six properties are associated with the agents:

"host": agent located in the terminal; - "card": agent located in the smart card;

"local": agent not communicating with the network; "network": agent communicating with the network (terminal side); "client": agent who initiates a session; "server": agent who receives a session request. A particular agent is identified by a reference, for example an integer of 16 bits (that is to say between 0 and 65535). The most significant bit (b15 = 1) indicates whether the reference is local (local communications to the smart card or to the terminal) or remote (b15 = 0).

There are two main categories of agents: "server" type agents, which are identified by a fixed reference, and type agents

"client", which are identified by a variable reference, which can be described as ephemeral, delivered by the configuration management module, 131 or

231 a.

The agents communicate with each other using an entity called "protocol data units" or "pdu" (for "protocol data unit", according to English terminology) constituting a destination reference and a source reference. We could also call this particular "pdu" "SmartTP pdu", with reference to the English term "Smart Card" (chip card) commonly used. The "pdu" use in particular the references defined above.

A "SmartTP pdu", or more simply "pdu" below, includes a source reference, a destination reference, a set of bits constituting flags or "flags" which specify the nature of the "pdu", and data optional: - the flag "OPEN" (open) is positioned to indicate the opening of a session; - the "CLOSE" flag indicates the end of a session; and

- The "BLOCK" flag indicates that the agent is waiting for a reply from his correspondent and suspends all activity. We will call token a "pdu" which does not contain data.

The "SmartTP" entity checks the existence of the destination agent and switches a packet to it.

An agent session "S-Agent" has three remarkable states, namely: - a disconnected state: no session is opened with another agent

- a connected state: a session is opened with another agent, an "S-Agent" session being identified by a pair of references; and

- a blocked state, the agent being connected and awaiting a response from his correspondent.

The mechanism for establishing an "S-Agent" session is as follows:

- a new instance of a client agent is created (chip card or terminal side), this agent being identified by a temporary pseudo-unique reference;

- the client agent issues a "pdu" to a server agent (whose reference is known elsewhere) with the "OPEN" flag set and the client agent goes into the connected or blocked state depending on the value of the "BLOCK 'flag; and - the server agent receives the" pdu "with the" OPEN "flag and goes to the connected state

Once a session is open, two agents exchange data via "pdu".

The mechanism for closing a session is as follows: - an agent issues a "pdu" with the "CLOSE" flag set (and which possibly includes data; and - the other agent receives a "pdu" with the "CLOSE" flag set (and which possibly includes data) and the "S-Agent" session goes to the disconnected state.

FIG. 3 schematically illustrates the state diagram of the "S-Agent" sessions, as they have just been recalled.

Layers 130 and 230a manage tables (not shown) which contain the list of agents present, on the host terminal side 1 and smart card 2a.

In practical terms, the agents make it possible to exchange data (of hypertext, for example), but also to trigger network transactions, authorizing communications between the smart card 2a and a remote server 4 (FIG. 2).

The configuration management modules, 131 and 231a, respectively, can be compared to specific agents. For example, the module 131, on the host terminal side 1, manages in particular information relating to the configuration of this terminal (operating modes), list of the other agents present, etc. The module 231a, on the smart card side 2a, has similar functions. These two agents can be put in communication with each other to establish a session. In practical terms, the smart card 2a is advantageously

"addressed" by using a "URL" address (for "Universal Reεource Locator") defining a loopback on the terminal 1 itself, and not a pointing on an external server. As an example, the structure of this "URL" is usually as follows: http://127.0.0.1: 8080 (1), in which 127.0.0.1 is the loopback "IP" address and 8080 is the number of port.

FIG. 4 illustrates in a simplified manner the logical architecture of a system according to the invention of the type shown in FIG. 2, but described in more detail. The smart card 2a includes several agents, including only two have been represented: an agent of the type not precisely defined 232aι and an agent 232a2, of the so-called "WEB" type. The logic stack comprises, the lower protocol layers, referenced 200a, meeting ISO standards 7816-3 (FIG. 2: CCai and CCa2), the "APDU" command manager 201 ai, and the packet multiplexer 230a, the latter being interface to agents, in particular the "WEB" agent 231 a2.

On the terminal side 1, there are two batteries, one communicating with the Internet network RI, the other with the smart card 2a. The first stack comprises the organs 11 (FIG. 2: Ci and C2) for accessing the network (OSI standards 1 and 2) and the "TCP / IP" protocol layers (FIG. 2: C3 and C4), referenced 100. These last layers are interfaced with the "WEB" browser 10. The other stack includes the lower protocol layers, referenced 101, meeting ISO 7816-3 standards (Figure 2: C- | and C2), the 102 order manager "APDU" and the packet multiplexer 130, the latter being interface with agents, of which only one 132, is shown. The latter, which will be assumed to be "network type", can also communicate, on the one hand with the browser 10, via the "TCP / IP" layers 101, on the other hand with the Internet network RI, via these same "TCP / IP" layers 101 and member 11, for access to the RI network. The “APDU” order manager 201a also interfaces with one or more application-level layers, which will simply be called applications. These applications, A, ..., A _t , ..., A _n , are, as indicated, applications of the conventional type.

In summary, the client / server function "WEB", provided by the smart card 2a, can be performed by the combination of the agent "WEB" 232aι in the smart card and the network agent 132 in the terminal 1, and by the implementation of sessions between agents, as described.

The smart card 2a therefore clearly presents the client / server functionality "WEB". In addition, according to an advantageous characteristic of the process of the invention, any conventional application, A- \ to A _n , of the type "CGA" above, can be activated through this client / server "WEB", either by the browser "WEB" 10 present in the terminal 1, or by a remote browser 4, located at any point of the Internet network RI, through the implementation of sessions between agents. According to the method of the invention, the applications, A- \ to A _n , do not need to be repeated and are implemented as they are.

In the context of the invention, all or part of the applications A- \ to An may consist of applications associated with one or more "PE" protocol (s) and / or one or more "PL" protocol (s), and loaded into a memory of the smart card 2a. Data representing one or more "PA" profiles can also be stored in the smart card 2a.

The client / server functionality "WEB" offered by the smart card 2a is not sufficient for an application to be able to run. It is necessary to add an additional functionality to it. According to another aspect of the invention, the server function

"WEB" offered by the smart card 2a includes a mechanism similar to the so-called "CGI" function (for "Common Gateway Interface" or "gateway interface") installed in conventional "WEB" servers.

Before describing an example of architecture in accordance with the invention, making it possible to perform a function of this type, even within the smart card, it is useful to recall the main characteristics of an "CGI" operating mode.

The "CGI" is a specification for implementing, from a "WEB" server, applications written for the "UNIX" (registered trademark), "DOS", or "WINDOWS" (registered trademark) operating systems. For example, for the "UNIX" operating system, the specification is "CGI 1.1" and for the "WINDOWS 95" operating system, the specification is "CGI 1.3".

Still by way of example, an "HTTP" request for a "URL" address, of the type: "http://www.host.com/cgi-bin/xxx.cgi" (2), in which "host" refers to a host system (usually remote), is interpreted by a "WEB" server as execution of a command script, of the "CGI" type named "xxx" and present in the "cgi- bin" directory of this host system. Although the name of the directory can be a priori arbitrary, by convention, it is the name given to the directory storing scripts of type "CGI". A script is a series of instructions from the operating system of the host system, the final result of which is transmitted to the "WEB" browser issuing the above request. Different languages can be used to write this script, for example the language "PERL" (registered trademark).

In practice, the request is usually displayed on a computer screen in the form of a form included in a "HTLM" page. The "HTLM" language allows you to translate a form into a "URL" address. The form includes one or more fields, mandatory or not, which are filled in by a user using the usual input methods: keyboard for text, mouse for check boxes or so-called "radio" buttons, etc. The content of the form (as well as possibly so-called "hidden" information and instructions) is sent to the "WEB" server. The "HTLM" code on the page describes the physical structure of the form (frame, graphics, color, and any other attribute), as well as the structure of the data fields to be entered (name, length, type of data, etc.).

Transmission can take place in two main types of formats. A first format uses the so-called "POST" method and a second uses the so-called "GET" method. Format type information is present in the code of the form page.

This mechanism cannot however be directly transposed to a smart card, even if the latter offers client / server functionality "WEB" in accordance with one of the characteristics of the invention. We will now describe an example of architecture making it possible to activate any application, of conventional type, via a "WEB" server on the smart card, with reference to FIG. 5.

Among the intelligent agents, in accordance with one aspect of the invention, special intelligent agents are provided, which will be called hereinafter "Script translating agents" or abbreviated as "ATS". The script is then interpreted by one of the intelligent agents. This translation can be carried out in different ways: a / by the "WEB" agent 232aι itself, which in this case is provided with a double capacity; b / by a single script agent capable of translating all the scripts present in the smart card 2a; c / by a dedicated script agent which will be called "ATSD" below (one agent per script); or d / by an agent "APDU" 2010a of the order manager "APDU"

201 a, which in this case has a double capacity.

The "APDU" agent 2010a is a component of the "APDU" order management layer 201a. The latter is a layer capable of centralizing all the "APDU" orders sent and / or received by the system, of selecting applications from A to A _n , but also of offering an interface of the intelligent agent type. It is therefore capable, according to one of the characteristics of the invention, of communicating with all the intelligent agents (via sessions), whether these agents are located in the terminal 1 or the smart card 2a. In case c / above, a session is opened between the agent

"WEB" 232aι and one of the agents "ATSD".

FIG. 5 illustrates an example of architecture for which the translating agents are of the "ATSD" type. They are referenced ATS, to ATS _n and associated with the applications A to A _n . The selected application being assumed .s .; be the application A _and the session is established between the "WEB" agent 232aι and the ATS agent.

A script translator agent generates a sequence of "APDU" orders. A session is opened between the translating agent, for example the ATS agent _t , and the "APDU" agent 2101a. The orders are then issued to the "APDU" agent 2101a. The "APDU" order manager 210a selects the "CGA" A _{/ application} and transmits to it the "APDU" orders, translated and therefore conventional orders, which it is able to understand. This application is therefore correctly activated, without having to modify or rewrite it.

The responses of the application A _t are transmitted to the "APDU" order manager 210a, to the "APDU" agent 2010a, then again to the ATS agent _ι (and more generally to the translator agent of script).

The different paths are symbolically represented in FIG. 5 by solid lines connecting the functional blocks, or in dotted lines inside these blocks.

The method according to the invention uses the two characteristics which have just been mentioned: operation of the smart card as a "WEB" server / client, including a "CGI" function. We will now describe in detail the different phases and steps of the method according to the invention with reference to FIGS. 6A to 8.

The first phase concerns the registration of a subscriber profile in a particular directory server which will be referred to as SA, below.

In a first step, illustrated in FIG. 6A, the smart card 2a is addressed by the browser 10 of the terminal 1, via the layers 13 and

23a. We recover, by a command of the "GET" type for example, a loading form from the smart card 2a, form in "HTML" language which we will arbitrarily call "download.html".

This recovery is carried out by consulting a corresponding page whose URL is typically of the following form: http://127.0.0.1: 8080 / download.html (3), in which http://127.0.0.1: 8080 is the actual loopback URL, as defined by the relation (1 ), and "download.html" the "HTML" page to obtain. This request implements a session between intelligent agents as it has been described with reference to FIGS. 2 to 4, according to a first aspect of the invention. The smart card 2a then plays the role of a "WEB" server.

The smart card 2a sends the "download.html" form during a second step, always by opening sessions between paired intelligent agents, according to the method of the invention. The form obtained can be displayed on a screen 5 via the browser 10 and is referenced P in FIG. 6A which schematically illustrates this process. This form constitutes a home page for the Internet user wishing to register on a directory server. The smart card then behaves like a "WEB" server.

The P page can usually include different graphic or text elements, as well as interactive control elements ("radio" type button, check boxes, data entry areas, etc.) . We will assume, firstly that the smart card 2a only offers its bearer (not shown) the possibility of registering on a single directory server, referenced SA _U , and according to a single profile subscriber, referenced PA _U. It is also assumed that this unique profile PA _U is recorded in the smart card 2a. In this hypothesis, the form P (that is to say the home page) displayed on the screen 5, can be reduced to a minimal presentation, of which FIG. 6B illustrates a possible example: form P

Form P includes various text areas, under the unique reference Z _t . These zones typically display the name "xxx" of the directory server (SA _U ), the proposed action "registration" and various aids (for example "click here"). Since it was assumed that the data from subscriber profile PA _U were recorded in the smart card 2a, it suffices to provide a send button B _s . The fact for the Internet user to click on this button using a mouse (Figure 1A: 6b) or to press the "enter" key on a keyboard (Figure 1A: 6a), triggers the sending from the form to the smart card 2a.

In another variant of the method according to the invention, the data relating to the profile of the subscriber are entered directly by the latter. In this hypothesis, the form is more complex. FIG. 6C illustrates a possible example of a form, referenced P ₂ . It comprises a first fixed text zone Z _n , similar to that of FIG. 6B (Z,) and one or more data entry zone (s), under the unique reference Z _Ά . Is provided as previously sending a ^β _s button, but advantageously also a button B _tidal re-initialization of the form P _2, which erases the data entered in error. The zone (s) for _entering data Z _Ά can (be) of the type known as "TEXTAREA" in "HTML" language and present a facility called "lift" for the scrolling display of long texts

The "HTML" code necessary to program such a form is well known in itself and is within the reach of those skilled in the art. There is no need to detail it again. We can however indicate that it contains in particular a line of code in "HTML" language which typically takes the form:

<form action = "http: //127.0.01: 8080 / cgi-smart / pe"> (4) in which http: //127.0.01: 8080 is the loopback URL for the relationship (1), cgi -smart the aforementioned "CGI" directory containing a "pe" script associated with one of the applications stored in the smart card 2a, referenced for example A _e . this application allows the subscriber (internet user) to be registered in the SA _U directory with the PA _U profile. This action is carried out in the manner described with reference to FIG. 5, by implementing the "CGI" functionalities, on the one hand, and client / server, on the other hand, offered by the smart card 2a. The application A _e behaves like a client. In the first case (FIG. 6B), it is not necessary to pass parameters to the smart card 2a. In fact, the subscriber profile data PA _U are unique and recorded in the smart card 2a.

In the second case (FIG. 6C), the data entered is passed as parameters to the smart card 2a, in the form of an "HTTP" request.

FIG. 6D schematically illustrates the overall process of the registration phase of an Internet user on a directory server SA _U , constituted by one of the servers 4 (FIGS. 2 or 4). The unique reference S _WEB groups together various modules of FIG. 5 allowing the smart card 2a to offer the combined functionalities of client / WEB server and "CGI" gateway. It has also been assumed that the application A _e allowing the implementation of the recording protocol "PE" was associated with a dedicated script translator agent At _e ;. it is a configuration conforming to that illustrated in figure 5. However, as it was indicated, the translation of the scripts can be carried out in other ways (by the agent "WEB" 232a _! (figure 5 ), etc. Sending the form, by opening sessions between intelligent agents, will activate the application A _e , through the script translator agent At _e . In a later step, the application A _e makes an "HTTP" request by opening sessions between pairs of intelligent agents, in particular involving an agent of the "network" type (FIG. 5: 132). The request is transmitted to the directory server SA _U , with passing parameters The parameters consist in particular of the subscriber profile data PA _U , so as to allow its recording in the directory The address "URL" of the directory server is obtained from the subscriber profile SA _U recorded in the smart card 2a or from the data entered in the form re P ₂ .

A priori, the registration process is completed at this stage. It may however include one or more additional steps. One of these steps may consist in sending an acknowledgment of receipt by the directory, in the form of an "HTTP" request addressing the smart card 2a. The acknowledgment may include information indicating that the registration has been completed satisfactorily, or on the contrary an error code. In the latter case, the registration process must be repeated. The server may request the sending of missing data or the re-transmission of incorrect or corrupted data. The registration request can also be rejected, in particular if the subscription validity limit is exceeded.

In a preferred variant of the method according to the invention, it is possible for an Internet user to register with several different directories. In this variant embodiment, it is generally necessary to also have several recording protocols. To do this, several applications associated with these protocols are stored in the smart card 2a, which can be referenced A _e ..., A _ei , ... A _by , assuming that the maximum number of distinct protocols is not.

As before, the data associated with the subscriber profiles, which will be referred to as PA ..., PA, ..., PA _q , can be stored in the smart card 2a, or, on the contrary, supplied, piecemeal , by the internet user according to a method similar to that which has been described with regard to FIG. 6C, by entering in an appropriate form, q is the maximum number of subscriber profiles available. Note that q is not necessarily equal to n. Indeed, a given directory server, which will be arbitrarily referred to as SA, can accept several distinct occurrences of the same subscriber (Internet user), on the one hand. On the other hand, several subscriber servers, although distinct, can accept the same subscriber profile and possibly share a common registration protocol.

To fix the ideas, we will assume that the smart card 2a stores four distinct subscriber profiles, PA _A to PA _D , each of the profiles making it possible to register on a single directory server, ie SA _A to SA _D . A form, or home page, referenced P ₃ , allowing this recording, can be presented as illustrated diagrammatically by FIG. 6E. he comprises a first header text area Z _te similar to the text area Z _f in FIG. 6B, possibly supplemented by graphic areas. It includes four additional text zones, Z _tA to Z _tD , associated with the four directory servers, SA _A to SA _D .. The form allows you to select one or more, or even all.

To make a choice between these directory servers, it is possible to provide zones called "check boxes", CC _A to CC _D. Alternatively, one can provide hyperlinks on the home page P ₃ , each hyperlink addressing the smart card 2a via a looping address of the type of that of relation (1), but with separate parameters.

As in the case of FIG. 6B, a send button B _{s is provided} , making it possible to transmit the content of the form to the smart card 2a.

Whatever the method used to select all or part of the directory servers, the parameters passed to the smart card2a must make it possible to select one or more subscriber profiles, PA _A to PA _D , and to derive one or more "URL" addresses. The actions requested, by the parameters passed to the smart card 2a, are typically of the type: îsa≈enr + pa, (5), with "sa," the name of the directory server of arbitrary index / among the n possible, "enr" the required registration action proper and "pa," the subscriber profile to be used among the possible qs.

One or more "HTTP" requests are made and transmitted to the directory servers concerned, SA _A to SA _D (FIG. 6E) and in the general case SA _A to SA _n , if there are n selected directory servers.

The choice presented on the home page P ₃ is naturally a function of the smart card 2a inserted in the reader 3. The choices presented depend on the rights which are granted to the internet user possessing the smart card 2a, in particular subscriptions subscribed to given services and their periods of validity. A second phase of the method according to the invention, that is to say the location, on the Internet, of an Internet user associated with any identifier can take place very similarly to the registration phase. To do this, it is necessary to query one or more directory server (s). It is also necessary to have at least one specific "PL" protocol for locating this Internet user. Finally, if there are several searchable directory servers, SA to SA _n , it is generally also necessary, as in the case of registration, to have several separate location protocols.

These location protocols can be implemented using applications stored in the smart card 2a.

The localization process takes place in a very similar way to that of the registration of the Internet user on one or more SA, directory servers. The only notable exception is that a subscriber profile PA _S is no longer explicitly required. It suffices to provide the smart card 2a with the identifier of the Internet user sought and the address of the directory server SA, or at least parameters allowing the application associated with one of the location protocols. to determine this "URL" address. A subscriber profile PA _t can however be used to automatically derive therefrom the "URL" address of the directory server SA, with the help of which a web user wishes to locate another web user. As indicated, the identifier of the Internet user sought may be their e-mail address, an address which typically takes the following form: pseudo@fournisseur.com (6), with "pseudo" the user name e-mail address of the Internet user or more generally a pseudonym, and "supplier.com" the name and suffix of the Internet service provider ", .com" can be replaced as appropriate by various suffixes: ".fr", ". net ", etc.). FIG. 7 illustrates the main stages of the phase of locating an internet user by interrogating a SA directory, In a first step, the smart card 2a is addressed by the browser 10 of the terminal 1, via the layers 13 and 23a. We recover, by a command of type "GET" for example, a loading form from the smart card 2a in the form of a home page referenced F. This home page can take different aspects, similar in particular to those described with reference to FIGS. 6C or 6E. Depending on whether there is a choice or several possible choices, the Internet user selects one or more directory servers and provides identification data of the Internet user sought. In FIG. 7, it has been assumed that a single directory server SA is interrogable. The page is transmitted in the form of an "HTTP" request to the smart card 2a and is interpreted by a script translator agent At, associated with an application / A, for implementing the "PL" protocol.

By the double client / server mechanism "WEB" and "CGI" (module referenced S _WEB as before), a request of the type: http://127.0.0.1/? sa =loc+pseudo@fournisseur.com (7), is interpreted by the smart card 2a as a request for the location of the internet user whose identifier is (6) on the sa, directory server.

An "HTTP" request is transmitted to this server which returns the requested information, as far as it is available. It searches its database for an "IP" address corresponding to the identification data received. If successful, ie if the requesting Internet user is actually registered, if this Internet user has the right to obtain this address and if the data received is correct, the data retransmitted includes the "IP" address of the Internet user sought, which makes it possible to locate it.

These different stages implement sessions between paired agents, according to one aspect of the invention.

It is also possible to store in the smart card 2a several applications, each intended for the implementation of a separate location protocol, a priori associated with a directory server which is also separate. In a preferred variant of the method according to the invention, two applications are stored in the smart card allowing the implementation of several recording protocols, several location protocols and data files for the recording of several profiles of 'subscriber. This advantageous arrangement makes it possible to transform the smart card 2a into a portable multi-directory database as illustrated diagrammatically in FIG. 8. In this figure, the terminal 1 has not been shown. It is however clear that this is necessary for the implementation of the method according to the invention. The recording protocols, the location protocols and the subscriber profiles bear the unique references, PE _X , PL _y and PA _Z , respectively, with x the number of recording protocols, y the number of location protocols and z the number of distinct subscriber profiles. This set makes it possible to establish connections with n separate directory servers, either to register an internet user carrying the smart card 2a, or to locate an internet user on the Internet RI network.

In yet another variant of the method according to the invention, the use of a smart card 2a allows robust authentication of its owner, during the recording phase and / or the location phase. Indeed, it is possible to store security data in the smart card 2a which remains the property of its owner. Such security data can consist of encryption keys.

Since, according to one of the advantageous aspects of the method according to the invention, the smart card can communicate directly with the Internet, by the implementation of sessions between intelligent agents, this data does not have to be transmitted to an external device, this would be terminal 1. The processing operations relating to security are carried out directly by the smart card 2a. This way of proceeding therefore offers a much higher degree of security than the simple use of so-called secure software layers of recent "WEB" browsers, known under the English abbreviation "SSL" (for "Secure Socket Layer"). The actual authentication can be carried out using the so-called certificate technique, in association with the aforementioned encryption keys stored in the smart card. This procedure may require additional transactions between the smart card 2a and the directory server (s) concerned, using “HTTP” requests passing through the Internet network RI. Depending on the result, positive or negative, of the authentication, the Internet user is authorized or not to carry out the processing, recording or localization that he wishes to carry out.

On reading the above, it is easy to see that the process of the invention does achieve the goals it has set for itself.

In particular, it allows an Internet user to register on one or more directory servers and / or to locate an Internet user on the Internet, also through one or more directories. Since the smart card has the combined functionality of a "WEB" client / server and a "CGI" gateway, this arrangement allows direct communications between the smart card and the directory server (s). It therefore authorizes the storage of specific software necessary for the implementation of recording and / or localization protocols, which allows great mobility. One or more subscriber profiles can also be stored in the smart card. The internet user is no longer required to use terminals configured specifically for the aforementioned protocols.

In particular, in a preferred embodiment, the smart card is transformed into a portable multi-directory database. The method according to the invention is entirely compatible with the existing one.

The Internet user sought is not required to have registered on one or more directory servers by making use of the method according to the invention. The transmissions on the Internet network are carried out according to the protocols in force and the communications between the terminal and the smart card use the aforementioned standardized protocol "ISO". We can therefore implement a standard smart card reader. Only the presence of a software layer specific in the terminal is necessary, which requires only a few modifications and can be carried out once and for all, regardless of the number of recording protocols, location and / or subscriber profiles carried by the card to puce, and whatever their nature. Finally, the use of a smart card allows secure transactions and, in particular, "robust" authentication.

It should be clear, however, that the invention is not limited to only the examples of embodiments explicitly described, in particular in relation to FIGS. 2 to 8. In particular, the two series of proprietary software need not be " PE "and" PL "are stored in the smart card, although this arrangement is particularly advantageous. By way of nonlimiting example, the recording phase (s), in one or more directory servers, which can be carried out once and for all, or at least being a priori less frequent (s) than the phases of localization, one could be satisfied to store in the smart card only the specific applications associated with this last operation. Likewise, as indicated, it is possible not to save subscriber profiles "PA" in the smart card (the data can be provided in real time when the subscriber is registered in a particular directory server). It is also possible to save only part of the subscriber profiles, profiles which can be provided automatically.

The invention also relates to a method of connecting a first user with at least one directory server, with a view to registering and / or locating at least one second user on a network, in particular of the Internet type. , said connection being effected by means of a terminal provided with a smart card reader and at least one piece of software called recording and / or localization software, the terminal and the card chip comprising information processing means and information storage means, said terminal being connected to each of said directory servers via said Internet-type network and communicating with said smart card according to a first determined protocol, characterized in that at least one of said pieces of software (A _e , A,) is stored in said smart card (2a); in that this smart card (2a) comprising a first piece of software (23a), forming a specific communication protocol layer, and said terminal (1) comprising a second piece of software (13), forming a communication protocol layer specific, said first and second pieces of software (13, 23a) further comprise at least one pair of first paired software entities (132, 232a), each of said entities (132, 232a) cooperating with each other, by virtue of to said information processing means, so as to allow the establishment of a bidirectional data exchange session between at least said terminal (1) and said smart card (2a), and / or said Internet-type network , so that said smart card (2a) offers the functionality of a client / server "WEB"; in that said smart card (2a) comprises, in the information storage means, at least one second software entity (AT _e , AT,) cooperating with said second specific piece of software (23a) so that said card puce offers a so-called "CGI" gateway interface functionality: and in that it comprises at least the following steps: 1 / opening of a first sequence of data exchanges between at least said terminal (1) and said card smart (2a) by means of said information processing means of the terminal and of the smart card, for the transmission of a request so that said "WEB" type browser retrieves data making it possible to select and activate one of said pieces of proprietary software (A _e , A,), for the selection of one of said directory servers (S / 4 _; ); 2 / opening a second sequence of data exchanges between said smart card (2a) and said terminal (1) to transmit said data to it, thanks to said information processing means of the terminal and of the smart card; 3 / opening of a third sequence of data exchanges between said terminal (1) and said smart card (2a) thanks to said information processing means of the terminal and of the smart card, to transmit selection data and optional parameters, said data and said optional parameters comprising a reference to one of said pieces of recording and / or localization software;

4 / implementation of said “CGI” functionality and execution of said piece of recording and / or localization software {A _e , A, using said information processing means of the smart card; and

5 / as a result of said execution, opening), thanks to said information processing means of the smart card, of a fourth sequence of data exchanges between said smart card (2a) and one of said directory servers {SA), selected by said selection data, so as to transmit a request for the performance of a determined registration or location operation.

The invention also relates to a smart card comprising information processing means and information storage means and intended to cooperate with a terminal provided with a smart card reader, for connecting a first user with at least one directory server, for the purpose of registering and / or locating at least one second user on a network, in particular of the Internet type, using recording and / or determined location, characterized in that said smart card (2a) stores, in the information storage means, at least one piece of software (A _e ,

A) associated with said determined recording and location protocols, in that this smart card (2a)) comprises, in the information storage means, a piece of software (23a), forming a communication protocol layer specific, further comprising at least a first autonomous software entity (S, of the so-called type client and a second autonomous software entity (S ₂ ), of the so-called server type, said entities (S ₂ , S ₂ ) cooperating, by means of information processing, so that said smart card (2a) offers the functionality of a client / server of the "WEB" type and to allow said connection of a first user with at least one directory server

{SA,), via said Internet type network (RI), and in that said smart card (2a) comprises, in the information storage means, at least one second software entity (AT _e , AT,) cooperating, thanks to the information processing means, with said specific piece of software (23a), so that said smart card (2a) offers a gateway interface functionality called "CGI" allowing the execution of said pieces of software { A _β , Aj) associated with said determined recording and localization protocols.

Claims

1. Method for bringing a first user into contact with at least one directory server, with a view to registering and / or locating at least one second user on a network, in particular of the Internet type, said implementation relationship carried out via a terminal equipped with a smart card reader and at least one piece of software called recording and / or localization, said terminal being connected to each of said servers directory via said Internet-type network and communicating with said smart card according to a first determined protocol, characterized in that at least one of said pieces of software w (A _e , A) is stored in said smart card ( 2a); in that this smart card (2a) comprising a first piece of software (23a), forming a specific communication protocol layer, and said terminal (1) comprising a second piece of software (13), forming a communication protocol layer specific, said first and second

15 pieces of software (13, 23a) further comprise at least one pair of first paired software entities (132, 232a), each of said entities (132, 232a) cooperating with each other so as to allow establishment of a bidirectional data exchange session between at least said terminal (1) and said smart card (2a), and / or said Internet-type network, so that said smart card (2a) offers the functionality a "WEB" client / server; in that said smart card (2a) comprises at least a second software entity (AT _e , AT) cooperating with said second specific piece of software (23a) so that said smart card offers a gateway interface functionality called "CGI"": 5 and in that it comprises at least the following steps:

1 / opening of a first sequence of data exchanges between at least said terminal (1) and said smart card (2a), for transmission a request for said "WEB" type browser to retrieve data making it possible to select and activate one of said pieces of proprietary software (A _θ , A,), with a view to selecting one of said directory servers {HER) ; 2 / opening of a second sequence of data exchanges between said smart card (2a) and said terminal (1) to transmit said data to it; 3 / opening of a third sequence of data exchanges between said terminal (1) and said smart card (2a) to transmit selection data and optional parameters, said data and said optional parameters comprising a reference to one of said pieces of recording and / or localization software; 4 / implementation of said "CGI" functionality and execution of said piece of recording and / or localization software (A _e , A); and 5 / as a result of said execution, opening of a fourth sequence of data exchanges between said smart card (2a) and one of said directory servers (SA), selected by said selection data, so as to transmit a request for carrying out a specific recording or localization operation.

Method according to claim 1, characterized in that said smart card reader (3) and said smart card (2a) comprise first and second protocol stacks for said data transmissions according to said first determined protocol, defined by the ISO standard 7816, each comprising at least software communication protocol layers (101, 200a), said to be low, so as to allow said data exchanges between said chip card (2a) and said terminal (1), these layers forming an interface with said first (13) and second (23a) pieces of specific software forming said specific communication protocol layers, respectively, and in that these pieces of software (13, 23a) each comprise two additional entities consisting of a data transfer module (130, 230a), forming an interface with said lower layers (101, 200a) of the first and second protocol stacks, and of a management module (131, 231a), and that said first entities of each pair consist of software modules, called intelligent agents (132, 232a1) establishing said sessions.

3. Method according to claim 2, characterized in that said series of instructions to be interpreted associated with each of said pieces of proprietary software is constituted by a script and in that said second software entity is constituted by a software module called intelligent translator agent script (AT _e , AT) providing understandable commands by pieces of proprietary software (A _β , A) ,.

4. Method according to claim 1, characterized in that said step 1 / comprises the emission of a request of type called "HTTP" according to an Internet type protocol by addressing a determined page (PrP ₃ ) in language

"HTML" containing said selection data and optional parameters, said address being an address of the "URL" type for looping back onto said smart card (2a).

5. Method according to claim 1, characterized in that said step 2 / comprises the sending by said smart card (2a) of a form in language

"HTML" {P ^ -P ₃ ) and in that said form comprises at least one address of the so-called "URL" type for looping back onto said smart card (2a) and a path leading to a determined directory associated with one said pieces of recording and / or localization software (A _e , A), to transmit said optional parameters to it and to cause its execution.

6. Method according to claim 5, characterized in that said step 3 / comprises the sending of a request of type called "HTTP" to said address "URL", designating said directory containing said piece of software recording and / or location (A _e , A), said request comprising said selection data and said optional parameters.

7. Method according to claim 6, characterized in that a piece of software called recording {A _e ) is associated with a first protocol {PE _X ) allowing the recording of said user on a determined directory server {SA ), in that said optional parameters consist of data defining a so-called subscriber profile (PA _Z ), comprising at least so-called identification data of said first user, and in that said "HTTP" request of said step 3 / includes first data indicating that the requested operation is said registration and second data making it possible to develop, by said piece of recording software (A _e ), an address of the "URL" type characteristic of said directory server determined (SA), and in that data associated with said subscriber profile are transmitted, during said step A1, to this directory server (SA), so as to carry out said registration of said first user, said registrant registration comprising the determination of an "IP" type address by association of said directory server address (SA) and said identification data of said first user.

8. Method according to claim 7, characterized in that it comprises at least one additional step consisting of sending to said smart card

(2a) an acknowledgment or an error code.

9. Method according to claim 8, characterized in that it comprises additional steps consisting in the exchange of data between one of said directory servers (SA) and said smart card (2a), so as to authenticate the latter. or said first user, and in that said authentication implements a certificate and at least one encryption key stored in said smart card (2a).

10. Method according to claim 6, characterized in that a piece of software called localization {A) is associated with a second protocol {PL _y ) allowing the localization of at least a second user on said Internet type network { RI), said second user being registered on a

5 determined directory server (SA), in that this said recording comprises at least so-called identification data of said second user, in that said "HTTP" request of said step 3 / includes first data indicating that the requested operation is said location, second data identifying said second user to be located w and third data making it possible to develop, by said piece of location software (A, an address of type "URL" characteristic of said determined directory server { SA), and in that data identifying said second user are transmitted, during said step 4 / to this directory server (SA), so as to perform said localization

15 of said second user, by searching for an "IP" type address, by associating said identification data of this second user, received by said directory server (SA), with registration data stored in that -this, and the retransmission of said "IP" type address to said smart card (2a), so as to allow said location. 0

11. Chip card intended to cooperate with a terminal provided with a chip card reader, for connecting a first user with at least one directory server, with a view to its registration and / or the location of at least a second user on a network, in particular of the Internet type, using determined recording and / or location protocols 5, characterized in that said smart card (2a) stores at least one piece of software (A _e , A) associated with said determined recording and location protocols, in that this smart card (2a)) comprises a piece of software (23a), forming a specific communication protocol layer, further comprising at least 0 a first autonomous software entity (S, of the so-called client type and a second autonomous software entity (S ₂ ), of said server type, said entities (S ₂ , S ₂ ) cooperating so that said smart card (2a) offers the functionality of a client / server of "WEB" type and enabling said connection of a first user with at least one directory server (SA), via said Internet type network (RI), and in that said smart card (2a) comprises at least a second software entity {AT _e , AT) cooperating with said specific piece of software (23a), so that said smart card (2a) offers a gateway interface functionality called "CGI" allowing the execution of said pieces of software {A _e , A) associated with said determined recording and location protocols.

12. Chip card according to claim 11, characterized in that said recording being carried out using data called subscriber profile, describing characteristics associated with said subscribers, at least one set of profile data subscribers (PA _Z ) is stored in said smart card (2a).