EP1169839A1 - 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

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

Info

Publication number
EP1169839A1
EP1169839A1 EP01907762A EP01907762A EP1169839A1 EP 1169839 A1 EP1169839 A1 EP 1169839A1 EP 01907762 A EP01907762 A EP 01907762A EP 01907762 A EP01907762 A EP 01907762A EP 1169839 A1 EP1169839 A1 EP 1169839A1
Authority
EP
European Patent Office
Prior art keywords
smart card
software
data
user
type
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP01907762A
Other languages
German (de)
English (en)
Inventor
Pascal Urien
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CP8 Technologies SA
Original Assignee
Bull CP8 SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull CP8 SA filed Critical Bull CP8 SA
Publication of EP1169839A1 publication Critical patent/EP1169839A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols

Definitions

  • 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.
  • Internet network 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”.
  • 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.
  • dedicated Internet terminals having only a minimum of own IT resources, or even no permanent storage means, of the hard disk type.
  • OSI Open System Interconnection
  • ISO Open System Interconnection
  • 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.
  • 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).
  • ISP 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.
  • the user connects to so-called “IRC” servers (for "Internet Relay Chat”).
  • IRC 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.
  • the servers “IRC” will be called more generally “directory servers", which will simply be called “SA”.
  • 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.
  • 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”.
  • "subscriber” means a “physical” entity. By extension, it can be a
  • 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 ".
  • Subscriber Profile 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.). ;
  • IP intellectual property
  • SA directory server
  • PL location protocol
  • 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.
  • 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.
  • 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.
  • 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 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.
  • ISDN integrated services digital network
  • 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).
  • ISP Internet Service Provider
  • 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.
  • 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.
  • communications on networks are carried out in accordance with protocols meeting standards comprising several superimposed software layers.
  • 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.
  • FIG. 1 C 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:
  • 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.
  • 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”.
  • terminal 1 only dialogs with one application at a time.
  • 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
  • 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.
  • 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.
  • the smart card behaves like a server / client of the "WEB" type for the terminal associated with it.
  • 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”.
  • agents paired in the respective specific communication layers associated with the terminal and the smart card.
  • sessions are established between paired agents.
  • 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.
  • 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.
  • 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.
  • 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
  • the invention also relates to a smart card for the implementation of this method.
  • 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
  • FIG. 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
  • FIG. 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
  • FIG. 7 schematically illustrates the main steps of the phase of locating a user on the Internet by interrogating a directory server
  • FIG. 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.
  • 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.
  • 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.
  • HTTP HyperText Transfer Protocol
  • FTP Transfer Protocol
  • e-mail electronic mail
  • the terminal 1 also includes a card reader 3, integrated or not.
  • 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.
  • OPEN OPEN
  • READ READ
  • WRITE WRITE
  • CLOSE CLOSE
  • CCai physical layer
  • CCa2 data link layer
  • 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.
  • 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.
  • agents intelligent agents
  • CCa2 ensure the exchange between the smart card 2a and the terminal 1.
  • the ISO 7816-3 protocol will preferably be used, in block mode.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • agent 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
  • 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.
  • pdu for "protocol data unit”, according to English terminology
  • pdu SmartTP pdu
  • Smart Card chip card
  • 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 "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 session is opened with another agent, an "S-Agent" session being identified by a pair of references;
  • 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
  • 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.
  • 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 can be compared to specific agents.
  • 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
  • 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.
  • 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-
  • 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.
  • 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".
  • 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.
  • the applications, A- ⁇ to A n do not need to be repeated and are implemented as they are.
  • 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.
  • the server function "WEB"
  • 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.
  • CGI Common Gateway Interface
  • CGI is a specification for implementing, from a “WEB” server, applications written for the "UNIX” (registered trademark), "DOS”, or "WINDOWS” (registered trademark) operating systems.
  • UNIX registered trademark
  • DOS registered trademark
  • WINDOWS registered trademark
  • 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.
  • CGI command script
  • 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).
  • 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.
  • 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”
  • 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
  • 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 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.
  • operation of the smart card as a "WEB” server / client, including a "CGI” function.
  • the first phase concerns the registration of a subscriber profile in a particular directory server which will be referred to as SA, below.
  • the smart card 2a is addressed by the browser 10 of the terminal 1, via the layers 13 and
  • 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.) .
  • radio radio type button, check boxes, data entry areas, etc.
  • 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.
  • FIG. 6C illustrates a possible example of a form, referenced P 2 . 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
  • HTML "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:
  • 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.
  • 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.
  • the translation of the scripts can be carried out in other ways (by the agent "WEB" 232a ! (figure 5 ), etc.
  • 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 2 .
  • 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.
  • the data associated with the subscriber profiles 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.
  • 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 3 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.
  • a send button B s is provided , making it possible to transmit the content of the form to the smart card 2a.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the Internet user selects one or more directory servers and provides identification data of the Internet user sought.
  • 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.
  • HTTP HyperText Transfer Protocol
  • This server 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.
  • 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.
  • 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.
  • 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”).
  • SSL 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.
  • HTTP HyperText Transfer Protocol
  • the smart card 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.
  • 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.
  • 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".
  • ISO standardized protocol
  • the use of a smart card allows secure transactions and, in particular, "robust" authentication.
  • the invention is not limited to only the examples of embodiments explicitly described, in particular in relation to FIGS. 2 to 8.
  • the two series of proprietary software need not be " PE “and” PL "are stored in the smart card, although this arrangement is particularly advantageous.
  • 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.
  • 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
  • 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 ,
  • 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 2 ), of the so-called server type, said entities (S 2 , S 2 ) 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
  • 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.
  • CGI gateway interface functionality

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

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 (Al) 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 (Al) 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

Procédé d'enregi strement d'un usager sur un serveur d'annuaire d'un réseau de type Internet et/ou de localisation d'un usager sur ce réseau, et carte à puce pour la mise en œuvre du procédé
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 d'un lecteur de carte à puce.
L'invention concerne également une carte à puce pour la mise en œuvre de ce procédé.
Dans le cadre de l'invention, le terme "réseau Internet" doit être compris dans son sens le 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 réseau dans lequel les échanges de données s'effectuent selon un protocole du type Internet. Dans ce qui suit un tel réseau sera appelé de façon générique "réseau Internet".
De même, le terme "terminal" doit être compris dans un sens général. Le terminal précité peut être notamment constitué par un ordinateur personnel fonctionnant sous divers systèmes d'exploitation, tels WINDOWS ou UNIX (tous deux étant des marques déposées). Il peut être aussi constitué par une station de travail, un ordinateur portable ou un terminal de carte dit dédié. Dans le cadre plus particulier de l'invention, il existe également des terminaux dédiés Internet, ne possédant qu'un minimum de ressources informatiques propres, voire aucun moyens de stockage permanent, de type disque dur.
Il apparaît tout d'abord utile de rappeler brièvement les caractéristiques principales des protocoles de communication sur les réseaux. L'architecture des réseaux de communication est décrite par diverses couches. A titre d'exemple, le standard "OSI" ("Open System Interconnection"), défini par I' "ISO", comporte sept couches qui vont des couches dites basses (par exemple la couche dite "physique" qui concerne le support de transmission physique) aux couches dites hautes (par exemple la couche dite "d'application"), en passant par des couches intermédiaires, notamment la couche dite de "transport". Une couche donnée offre ses services à la couche qui lui est immédiatement supérieure et requiert de la couche qui lui immédiatement 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 à la couche inférieure : la couche dite d'application ("http", "ftp", "e-mail", etc.), la couche dite de transport ("TCP"), la couche dite d'adressage de réseau ("IP"), la couche dite de 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 des terminaux Internet qui possèdent une adresse "IP" fixe, ou variable lorsque l'on a recours à un prestataire de service Internet, généralement connu sous le sigle anglo-saxon "ISP" (pour "Internet Service Provider).
Un premier inconvénient est constitué par le fait qu'une adresse "IP" n'est pas 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 a 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 "UserlD", son adresse "IP". 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 "IP". Cependant la localisation d'un internaute sur le réseau Internet, c'est-à-dire l'établissement de la correspondance précitée, présuppose que celui-ci ait été au préalable enregistré dans le serveur d'annuaire "SA".
L'adresse d'un internaute dans le réseau Internet est donc constituée du couple : "Adresse SA" - "UserlD". De façon usuelle, par "abonné", on entend une entité "physique". Par extension, il peut s'agir d'une
"fonction". Cependant, ci-après, on donnera à "abonné" son sens commun, sans que cela soit limitatif en quoi que ce soit de la portée de l'invention.
De façon pratique, un internaute indique sa localisation dans le réseau Internet par un acte volontaire en fournissant au serveur (annuaire) son adresse "IP" actuelle à l'aide d'un protocole d'enregistrement que l'on appellera ci-après "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. Ce profil "PA" permet d'identifier de façon plus complète un abonné
(ou internaute), en sus de son identifiant de base "UserlD".
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é (internaute), et par exemple : - l'adresse du "Serveur d'Annuaire" ("SA") ; l'identifiant de l'abonné ("UserlD") ; les abonnés (identifiés par leurs "UserlD") 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 "IP". Cette information est obtenue à l'aide d'un serveur d'annuaire ("SA") et d'un protocole de localisation ("PL").
On doit noter que le profil d'abonné "PA" est, par nature, spécifique à l'abonné, mais peut dépendre aussi des caractéristiques du serveur d'annuaire, notamment du type et de la nature des informations qui doivent lui être fournies ou qu'il peut accepter. On doit noter enfin que le protocole "PL" est, comme le protocole
"PE", de type dit propriétaire, puisqu'il adresse un serveur d'annuaire a priori non standardisé ou répondant à des normes universellement reconnues.
Ces deux caractéristiques constituent des inconvénients supplémentaires. En résumé de ce qui vient d'être rappelé, pour qu'un premier internaute puisse localiser d'autres internautes et puisse être localisé par ceux-ci, il est nécessaire que le terminal qu'il utilise stocke des logiciels spécifiques permettant de mettre en œuvre les protocoles "PE" et "PL". Il 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.
En d'autres termes, le terminal utilisé par un abonné quelconque est également spécifique, en ce sens que, si cet abonné désire changer de terminal, il 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-ci, notamment les adresses "IP" des correspondants recherchés et leurs profils "SA".
Il serait donc intéressant d'utiliser des terminaux banalisés pour effectuer les opérations d'enregistrement et, surtout, de localisation d'internautes sur le réseau Internet, ce qui permettrait d'accéder de façon commode au concept appelé "nomadisme". Les logiciels associés aux protocoles précités, "PE" et "PL" ne nécessitent pas habituellement de disposer d'une grande quantité de mémoire. Il en est de même des données de profil "PA". On pourrait donc penser les enregistrer dans les 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-après, ce qui interdit toute communication directe entre le réseau Internet et une carte à 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 système d'application à base de carte à puce comporte généralement les éléments principaux suivants : une carte à puce ; un système hôte constituant le terminal précité ; - un réseau de communication, à savoir le réseau Internet dans l'application préférée ; et un serveur d'application connecté au réseau Internet.
La figure 1A illustre schématiquement un exemple d'architecture de ce type. Le terminal 1 , par exemple un ordinateur individuel, comporte un lecteur 3 de carte à puce 2. Ce lecteur 3 peut être ou non physiquement intégré dans le terminal 1. La carte à puce 2 comporte un circuit intégré 20 dont des connexions d'entrées-sorties affleurent en surface de son support pour autoriser une alimentation en énergie électrique et 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 via un prestataire de services Internet ("Internet Service Provider" ou "ISP", selon la terminologie anglo-saxonne). On peut également avoir recours à un système intermédiaire tel qu'un "proxy" ou un système d'isolation dit "firewall" ("pare- feu" ou encore appelé "garde barrière").
Le terminal 1 comprend naturellement tous les circuits et organes nécessaires à son bon fonctionnement, et qui n'ont pas été représentés dans un 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 6b, 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 1 A. Les circuits d'accès 11 mettent le terminal 1 en communication avec les serveurs 4 grâce à un logiciel particulier 10, appelé navigateur "WEB", ou "browser" selon la terminologie anglo-saxonne. Celui- ci permet d'accéder à diverses applications ou fichiers de données répartis sur l'ensemble du réseau RI, généralement selon un mode "client-serveur".
Habituellement, les communications sur les réseaux s'effectuent conformément à des protocoles répondant à des standards comprenant plusieurs couches logicielles superposées. Dans le cas d'un réseau RI 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 est choisi en fonction de l'application plus particulièrement visée : interrogation de pages "WEB", transferts de fichiers, courrier électronique (e-mel, ou "e-mail" selon la terminologie anglo-saxonne), forums ou "news", etc.
L'architecture logique du système comprenant un terminal, un lecteur de carte à puce et une carte à puce, est représentée schématiquement par la figure 1 C. 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 le marquage des cartes ;
ISO 7816-3, en ce qui concerne le transfert de données entre le terminal et la carte à puce ; et - ISO 7816-4, en ce qui concerne la structure du jeu d'ordres et le format des commandes.
Sur la figure 1 B, du côté terminal 1 , on n'a représenté que les couches répondant à la norme ISO 7816-3, référencées 101 , et un gestionnaire d'ordres "APDU" (norme ISO 7816-4), référencé 102. Du côté carte à puce 2, les couches répondant à la 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 A-\ , ..., Aj, ..., An ; n étant le nombre maximum d'applications présentes sur la carte à puce 2.
Une application, Aj, présente dans la carte à puce 2, dialogue avec le terminal 1 au moyen d'un jeu d'ordres. Ce jeu présente typiquement des ordres d'écriture et des ordres de lecture. Le format des ordres est connu sous l'abréviation anglo-saxonne de "APDU" (pour "Application Protocol Data Unit"). Il est défini par la norme ISO 7816-4 précitée. Une "APDU" de commande est notée "APDU.command" et 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 d'un 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 à puce 2 inclut plusieurs applications distinctes, comme illustré sur la figure 1 B, on parle de carte multi-applicative.
Cependant, le terminal 1 ne dialogue qu'avec une seule application à la fois.
La sélection d'une application particulière Aj 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 A\ 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
Aj et le dialogue avec celle-ci s'effectuent par échanges d'ordres "APDU". On suppose que les applications Aj sont des applications conventionnelles, que l'on appellera ci-après "GCA" (pour "Generic Card Application" ou application de carte générique). Ces rappels étant effectués, il est à noter que la carte à puce 2 ne peut communiquer directement avec les navigateurs standards du commerce 10, sauf à modifier le code de ces derniers.
En outre, et surtout, les cartes à puce actuelles, qui par ailleurs sont conformes aux standards et normes rappelés ci-dessus, ont une configuration matérielle et logicielle qui ne permet pas non plus de communiquer directement avec le réseau 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. Il est donc nécessaire de prévoir une pièce de logiciel additionnelle, implantée dans le terminal 1 , généralement sous la forme de ce qui est appelé un "plug-in", selon la terminologie anglo-saxonne. Cette pièce de logiciel, qui porte la référence 12 sur la figure 1A, effectue I interface entre le navigateur 10 et la carte 2, plus précisément les circuits élecrroniques 20 de cette carte 2.
L'invention vise à pallier les inconvénients des procédés et dispositifs de l'art connu, et dont certains viennent d'être rappelés, tout en répondant aux besoins qui se font sentir.
Selon un mode de réalisation avantageux de l'invention, les applications nécessaires à la mise en œuvre des protocoles d'enregistrement ("PE") et de localisation ("PL"), ainsi que les données caractérisant le profil d'abonné ("PA") sont des fichiers stockés, en tout ou partie, dans des mémoires d'une carte à puce, les 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 le terminal. Le terme "spécifique" doit être entendu comme spécifique au procédé de l'invention. En effet, ces couches de communications, dites spécifiques, sont banalisées quelle que soit l'application considérée. En particulier, elles sont indépendantes des applications nécessaires à la mise en œuvre des protocoles "PE" et "PL". Elles n'interviennent que dans le processus d'échanges de données bidirectionnels entre la carte à puce et le terminal, d'une part, et la carte à puce et le réseau, d'autre part.
Les couches logicielles de communication spécifiques comprennent notamment des composants logiciels, dits "agents intelligents", permettant en particulier des conversions de protocoles. Les agents intelligents seront appelés ci-après plus simplement "agents". Il existe des agents appareillés dans les couches de communication spécifiques respectives associées au terminal et à la 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écité, localisées 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 les traduisent en ordres "APDU" compréhensibles par l'application de type "CGA". De ce fait, on implante dans la carte à puce une fonction similaire à celle connue par ailleurs sous la dénomination "CGI" dans les serveurs "WEB" classiques. Cette fonction permet de mettre en œuvre une application dans la 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 œuvre 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 à des 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 d'un même profil d'abonné "PA" sur un même serveur d'annuaire "SA", et de localiser ces entités en les associant à des adresses "IP" 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 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 qu'au moins l'une desdites pièces de logiciel est stockée dans ladite carte à puce ; en ce que cette carte à puce comprenant une première pièce de 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 et 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 : 1/ 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 pièces de logiciel propriétaire, en vue de la sélection d'un desdits serveurs d'annuaire ; 2/ 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 ; 3/ ouverture d'une troisième séquence d'échanges de données entre ledit terminal et ladite carte à puce pour transmettre des données de sélection et des paramètres optionnels, lesdites données et lesdits paramètres optionnels comportant une référence à une desdites pièces de logiciel d'enregistrement et/ou de localisation ; 4/ mise en œuvre de ladite fonctionnalité "CGI" et exécution de ladite pièce de logiciel d'enregistrement et/ou de localisation ; et
5/ en résultat de ladite exécution, ouverture d'une quatrième séquence d'échanges de données entre ladite carte à puce et un desdits serveurs d'annuaire, 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.
L'invention a également pour objet une carte à puce pour la mise en œuvre de ce procédé.
Un mode préféré, mais non limitatif, de réalisation de 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 ilii stre de façon simplifiée l'architecture logique d'un système selon l'invention dans lequel la carte à puce comprend des agents intelligents ; la figure 5 illustre de façon simplifiée l'architecture logique d'un système selon un autre aspect de l'invention selon lequel la carte à puce comprend des agents intelligents traducteurs de scripts, de manière à implanter une fonction dite "CGI" ; la figure 6A illustre schématiquement une première étape de la phase d'enregistrement d'un internaute 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 de la phase d'enregistrement d'un internaute sur un serveur d'annuaire ; la figure 6E illustre schématiquement les principales étapes de la phase d'enregistrement d'un internaute plusieurs serveurs d'annuaire ;
- la figure 7 illustre schématiquement les principales étapes de la phase de localisation d'un internaute sur le réseau Internet par interrogation d'un serveur d'annuaire ; et - la figure 8 illustre schématiquement une architecture à carte à 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.
A l'exception de couches logicielles de protocole de communication spécifiques, référencées 13 et 23a, respectivement implantées dans le terminal 1 et la carte à puce 2a, les autres éléments, matériels ou logiciels, sont communs à l'art connu, notamment à ce qui a été décrit en regard des figures 1 A et 1 B, et il n'y a pas lieu de les re-décrire de façon détaillée. Le terminal 1 comprend des circuits 1 1 d'accès au réseau RI, constitués par exemple d'un modem. Ces circuits regroupent les couches logicielles inférieures, Ci 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" ("IP", dans le cas d'Internet) et de "transport" ("TCP"). La couche supérieure d'application ("http", "ftp", "e-mail", etc.) n'a pas été représentée.
L'interface entre les couches inférieures, Ci et C2, et les couches supérieures, C3 et C4, est constituée par une couche logicielle généralement appelée "driver couches basses". Les couches supérieures, C3 et C4, s'appuient sur cette interface et sont mises en œuvre par l'intermédiaire de bibliothèques de fonctions spécifiques ou bibliothèques réseau 14, avec lesquelles elles correspondent. Dans le cas du réseau Internet, "TCP/IP" est mis en œuvre au moyen de bibliothèques dites de "sockets".
Cette organisation permet à un navigateur 10 de poser des requêtes vers un serveur 4, pour la consultation de pages "WEB" (protocole "HTTP"), pour le transfert de fichiers (protocole "FTP") ou l'envoi de courrier électronique (protocole "e-mail"), ce de façon tout à fait classique en soi.
Le terminal 1 comprend également un lecteur de carte 3, intégré ou non. Pour communiquer avec la carte à puce 2a, le lecteur de carte 30 englobe également deux couches basses, CC1 (couche physique) et CC2 (couche de lien de données), jouant un rôle similaire aux couches Ci et C2. Les interfaces logicielles avec les couches CC1 et CC2 sont décrites, par exemple, par la spécification "PC/SC" ("part 6, service provider"). Les couches elles-mêmes, CC1 et CC2, sont notamment décrites par les normes ISO 7816-1 à 7816-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, CC1 et CC2. La fonction principale dévolue à cette couche 16 est une fonction de multiplexage/démultiplexage.
Les communications avec la carte à puce 2a s'effectuent selon un paradigme similaire à celui utilisé pour la manipulation de fichiers dans un système d'exploitation du type "UNIX" (marque déposée) : OUVRIR ("OPEN"), LIRE ("READ"), ECRIRE ("WRITE"), FERMER ("CLOSE"), etc.
Du côté de la carte à puce 2a, on retrouve une organisation similaire, à savoir la présence de deux couches basses, référencées CCai (couche physique) et CCa2 (couche de lien de données), ainsi qu'une couche d'interface 26a, tout à fait similaire à la couche 16.
Selon l'invention, on prévoit, de part et d'autre, c'est-à-dire dans le terminal 1 et dans la carte à puce 2a, deux couches de protocoles spécifiques : 13 et 23a, respectivement.
Dans le terminal 1 , la couche spécifique 13 s'interface aux "drivers couches basses" 15, aux bibliothèques 14 des couches réseau, C3 et C4, et aux couches protocolaires du lecteur de carte 3, c'est-à-dire les couches inférieures, CC1 et CC2, via la couche de multiplexage 16. La couche spécifique 13 permet le transfert de paquets réseaux de et vers la carte à puce 2a. En outre, elle adapte les applications existantes telles le navigateur Internet 10, le courrier électronique, etc., pour des utilisations mettant en œuvre la carte à puce 2a.
Du côté de la carte à puce 2a, on retrouve une organisation tout à fait similaire constituée par une instance supplémentaire de la couche spécifique, référencée 23a, pendant de la couche 13. De façon plus précise, les couches spécifiques, 13 et 23a, sont subdivisées en trois éléments logiciels principaux : un module, 130 ou 230a, de transfert de blocs d'informations entre les couches 13 et 23a, via les couches conventionnelles CC1 , CC2, CCai et CCa2 ; une ou plusieurs pièces de logiciel, dites "agents intelligents", 132 ou 232a, qui réalisent, par exemple, des fonctions de conversion de protocoles ; et un module de gestion de la configuration spécifique, 131 et 231a, respectivement ; module qui peut être assimilé à un agent intelligent particulier.
Pour simplifier, on appellera ci-après les agents intelligents, "agents", comme il a été précédemment indiqué.
On retrouve donc, dans le terminal 1 et la carte à puce 2a, une pile protocolaire de communication entre les deux entités.
Les couches de niveau deux (couches de lien de données), CC2 et
CCa2, assurent l'échange entre la carte à puce 2a et le terminal 1. Ces couches sont responsables de la détection et l'éventuelle correction d'erreurs de transmission. Différents protocoles sont utilisables, et à titre d'exemples non exhaustifs les suivants :
- la recommandation ETSI GSM 11.11 ;
- le protocole défini par la norme ISO 7816-3, en mode caractère
T=0 ; le protocole défini par la norme ISO 7816-3, en mode bloc T=1
- ou le protocole défini par la norme ISO 3309, en mode trame "HDLC" (pour "High-Level Data Link Control procédure" ou procédure de commande de liaison à haut niveau).
Dans le cadre de l'invention, on utilisera de préférence le protocole ISO 7816-3, en mode bloc.
De façon connue en soi, à chaque couche de protocole, il est associé un certain nombre de primitives qui permettent les échanges de données entre couches de même niveau et d'une couche à l'autre. A titre d'exemple, les primitives associées à la couche de niveau deux sont du type "demande de données" ("ϋata.request") et "envoi de données" par la carte {"Data.response"), ainsi que "confirmation de données" {"Data.confirm"), etc. De façon plus spécifique, les couches 13 et 23a sont chargées du dialogue entre la carte à puce 2a et l'hôte, c'est-à-dire le terminal 1. Ces couches permettent l'échange d'informations entre un utilisateur (non représenté) du terminal 1 et la carte à puce 2a, par exemple via des 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 réception de paquets de données. Comme il a été indiqué ci-dessus, les couches comprennent trois entités distinctes.
La première couche, 130 ou 230a, est essentiellement constituée par un multiplexeur logiciel. Elle permet l'échange d'informations entre la carte à puce 2a et 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 unités sont émises ou reçues via la couche de niveau deux (couche de liens de données). Ce protocole particulier de communication permet de mettre en communications au moins une paire d' "agents". Le premier agent de chaque paire, 132, est situé dans la couche 13, côté terminal 1 , le second, 232a, est situé 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". Une session est un échange de données bidirectionnel entre ces deux agents. Si 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 les modules 131 et 231a, qui constituent des agents particuliers.
De façon plus précise, un agent est une entité logicielle autonome qui peut réaliser tout ou partie de fonctions des couches de niveau trois et quatre, en fonction de la configuration mise en œuvre par le terminal 1. Les agents sont associés à des propriétés ou attributs particuliers. Pour fixer les idées, et à titre d'exemple non limitatif, les six propriétés suivantes sont associées aux agents :
"hôte" : agent localisé dans le terminal ; - "carte" : agent localisé dans la carte à puce ;
"local" : agent ne communiquant pas avec le réseau ; "réseau" : agent communiquant avec le réseau (côté 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, par exemple un nombre entier de 16 bits (c'est-à-dire compris entre 0 et 65535). Le 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).
Il 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", qui sont identifiés par une référence variable, que l'on peut qualifier d'éphémère, délivrée par le module de gestion de configuration, 131 ou
231 a.
Les agents communiquent entre eux à l'aide d'entité dites "unités de donnée de protocole" ou "pdu" (pour "protocol data unit", selon la terminologie anglo-saxonne) constituant une référence de destination et une référence de source. On pourrait également appeler cette "pdu" particulière "SmartTP pdu", en référence au terme anglais "Smart Card" (carte à puce) couramment utilisé. Les "pdu" utilisent notamment les références définies ci- dessus.
Une "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 des 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 est en attente d'une réponse de son correspondant et suspend toute activité. On appellera jeton une "pdu" qui ne comporte pas de données.
L'entité "SmartTP" contrôle l'existence de l'agent destinataire et réalise la commutation d'un paquet vers ce dernier.
Une session agent "S-Agent" possède trois états remarquables, à savoir : - un état déconnecté : aucune session n'est ouverte avec un autre agent
- un état connecté : une session est ouverte avec un autre agent, une session "S-Agent" étant identifiée par une paire de références ; et
- un état bloqué, l'agent étant connecté et attendant une réponse de 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" à 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 la "pdu" avec le drapeau "OPEN" et passe à l'état connecté
Une fois une session ouverte, deux agents échangent des données via des "pdu".
Le mécanisme de fermeture d'une session est le suivant : - un agent émet une "pdu" avec le drapeau "CLOSE" positionné (et qui comporte éventuellement des données ; et - l'autre agent reçoit une "pdu" avec le drapeau "CLOSE" positionné (et qui comporte éventuellement des données) et la session "S-Agent" passe à l'état déconnecté.
La figure 3 illustre de façon schématique le diagramme d'états des sessions "S-Agent", telles qu'elles viennent d'être rappelées.
Les couches 130 et 230a gèrent 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, les agents permettent d'échanger des données (de l'hypertexte, par exemple), mais également 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 231a, respectivement, sont assimilables à des agents particuliers. Par exemple, le module 131 , côté terminal hôte 1 , gère notamment des informations relatives à la configuration de ce terminal (modes de fonctionnement), liste des autres agents présents, etc. Le module 231a, côté carte à puce 2a, 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 "Universal Reεource Locator") définissant un rebouclage sur le terminal 1 lui-même, et non un pointage sur un serveur externe. A titre d'exemple, la structure de cette "URL" est habituellement la suivante : http://127.0.0.1 :8080 (1 ), dans laquelle 127.0.0.1 est l'adresse "IP" de rebouclage et 8080 est le numéro de port.
La figure 4 illustre de façon simplifiée l'architecture logique d'un système selon l'invention du type représenté sur la figure 2, mais décrite de façon plus détaillée. La carte à puce 2a comprend plusieurs agents, dont deux seulement ont été représentés : un agent de type non précisément défini 232aι et un agert 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 7816-3 (figure 2 : CCai et CCa2), le gestionnaire de commandes "APDU" 201 ai , et le multiplexeur de paquets 230a, ce dernier étant interface 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 : Ci et C2) d'accès au réseau (normes OSI 1 et 2) et les couches de protocole "TCP/IP" (figure 2 : C3 et C4), référencées 100. Ces dernières couches sont interfacées avec le navigateur "WEB" 10. L'autre pile comprend les couches de protocole inférieures, référencées 101 , répondant aux normes ISO 7816-3 (figure 2 : C-| et C2), le gestionnaire 102 d'ordres "APDU" et le multiplexeur de paquets 130, ce dernier étant interface avec des agents, dont un seul 132, 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 "TCP/IP" 101 , d'autre part avec le réseau Internet RI, via ces mêmes couches "TCP/IP" 101 et l'organe 11 , d'accès au réseau RI. Le gestionnaire d'ordres "APDU" 201a est également interface avec une ou plusieurs couches de niveau applications, que l'on appellera simplement applications. Ces applications, A , ..., At, ..., An, sont, comme il a été indiqué, des applications de type conventionnel.
En 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" 232aι dans la carte à puce et de l'agent réseau 132 dans le terminal 1 , et par la mise en œuvre de sessions entre agents, comme il a été décrit.
La carte à puce 2a présente donc bien la fonctionnalité client/serveur "WEB". En outre, selon une caractéristique avantageuse du procédé de l'invention, n'importe quelle application conventionnelle, A-\ à An, du type "CGA" précité, peut être activée au travers de ce client/serveur "WEB", soit par le navigateur "WEB" 10 présent dans le terminal 1 , soit par un navigateur éloigné 4, localisé en un point quelconque du réseau Internet RI, par la mise en œuvre de sessions entre agents. Selon le procédé de l'invention, les applications, A-\ à An, ne nécessitent pas d'être ré-éc tes et sont mises en œuvre telles quelles.
Dans le cadre de l'invention, tout ou partie des applications A-\ à An peut être constitué par des applications associées à un ou plusieurs protocole(s) "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. Il 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 œuvre, 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.3".
Toujours à titre d'exemple, une requête "HTTP" pour une adresse "URL", du type : "http://www.host.com/cgi-bin/xxx.cgi" (2), dans laquelle "host" se réfère à un système hôte (généralement éloigné), est interprétée par un serveur "WEB" comme l'exécution d'un script de commande, de type "CGI" nommé "xxx" et présent dans le répertoire "cgi- bin" de ce système hôte. Bien que le nom du répertoire puisse être a priori quelconque, par convention, c'est le nom donné au répertoire stockant les scripts de type "CGI". Un script est une suite d'instructions du système d'exploitation du système hôte dont le résultat final est transmis au navigateur "WEB" émetteur de la requête précitée. Différents langages peuvent être utilisés pour écrire ce script, par exemple le langage "PERL" (marque déposée).
De façon pratique, la requête est habituellement affichée sur un écran informatique sous la forme d'un formulaire compris dans une page "HTLM". Le langage "HTLM" permet de traduire un formulaire en une adresse "URL". Le formulaire comporte un ou plusieurs champs, obligatoires ou non, qui sont remplis par un utilisateur à l'aide des moyens de saisie habituels : clavier pour le texte, souris pour les cases à cocher ou les boutons dits "radio", etc. 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 que la structure des champs de données à saisir (nom, longueur, type de données, etc.).
La transmission peut s'effectuer selon deux types de formats principaux. Un premier format utilise la méthode dite "POST" et un second la méthode dite "GET". Une information de type de format est présente dans le code de la page formulaire.
Ce mécanisme n'est cependant pas directement transposable à une carte à puce, même si 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 à l'un des aspects de l'invention, on prévoit des agents intelligents particuliers, que 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 : a/par l'agent "WEB" 232aι lui-même, qui est doté dans ce cas d'une double capacité ; b/par un agent script unique capable de traduire l'ensemble des scripts présents dans la carte à puce 2a ; c/par un agent de script dédié que l'on appellera "ATSD" ci-après (un agent par script) ; ou d/par 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 le système, de sélectionner des applications, parmi A à An, mais également d'offrir une interface de type agent intelligent. Elle est donc capable, selon l'une des 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 la carte à puce 2a. Dans le cas c/ ci-dessus, une session est ouverte entre l'agent
"WEB" 232aι 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 A à An. L'application sélectionnée étant supposée .s'.; être l'application Aιt la session s'établit entre l'agent "WEB" 232aι 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 ATSt, et l'agent "APDU" 2101a. Les ordres sont alors émis vers l'agent "APDU" 2101a. Le gestionnaire d'ordres "APDU" 210a sélectionne l'application "CGA" A/ et lui transmet les ordres "APDU", ordres traduits et donc conventionnels, qu'elle est en mesure de comprendre. Cette application est donc correctement activée, sans avoir à la modifier ou à la réécrire.
Les réponses de l'application At sont transmises au gestionnaire d'ordres "APDU" 210a, à l'agent "APDU" 2010a, puis de nouveau à l'agent ATSι (et de façon plus générale à l'agent traducteur de script).
Les différents cheminements sont représentés symboliquement sur la figure 5 par des traits pleins reliant les blocs fonctionnels, ou en pointillés à l'intérieur de ces blocs.
Le procédé selon l'invention utilise les deux caractéristiques qui viennent d'être rappelées : fonctionnement de la carte à puce en tant que serveur/client "WEB", incluant une fonction "CGI". On va maintenant décrire de façon détaillée les différentes phases et étapes du procédé selon l'invention par référence aux figures 6A à 8.
La 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 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, formulaire en langage "HTML" que l'on appellera arbitrairement "download.html".
Cette récupération est effectuée en consultant une page correspondante dont l'URL est typiquement de la forme suivante : http://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 qu'elle a été définie par la relation (1 ), et "download.html" la page "HTML" à obtenir. Cette requête met en œuvre une session entre agents intelligents comme il a été décrit en regard des figures 2 à 4, selon un premier aspect de l'invention. La carte à puce 2a joue alors le rôle d'un serveur "WEB".
La carte à puce 2a envoie le formulaire "download.html" lors d'une deuxième étape, toujours par ouvertures de sessions entre agents intelligents appariés, selon le procédé de l'invention. Le formulaire obtenu peut être affiché sur un écran 5 par l'intermédiaire du navigateur 10 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 un 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 un serveur d'annuaire unique, référencé SAU, et selon un profil unique d'abonné, référencé PAU. On suppose également que ce profil unique PAU est enregistré dans la carte à 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 Zt. Ces zones affichent typiquement le nom "xxx" du serveur d'annuaire (SAU), l'action proposée "enregistrement" et diverses aides (par exemple "cliquer ici"). Puisque l'on a supposé que les données du profil d'abonné PAU é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 1A : 6b) ou d'appuyer sur la touche "entrée" d'un clavier (figure 1A : 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é P2. Il comprend une première zone de texte fixe Zn, similaire à celle de la figure 6B (Z,) et une ou plusieurs zone(s) de saisie de données, sous la référence unique ZΆ. On prévoit comme précédemment un bouton d'envoi β s, mais aussi avantageusement un bouton Braz de ré-initialisation du formulaire P2, qui permet d'effacer les données saisies en cas d'erreur. La ou les zones de saisies de données ZΆ peu(ven)t être du type dit "TEXTAREA" en langage "HTML" et présenter une facilité dite d' "ascenseur" pour l'affichage déroulant de textes longs
Le code "HTML" nécessaire pour programmer un tel formulaire est bien connu en soi et est à la portée de l'homme de métier. Il n'est pas nécessaire de le détailler de nouveau. On peut cependant indiquer qu'il contient notamment une ligne de code en langage "HTML" qui se présente typiquement sous la forme :
<form action="http://127.0.01 :8080/cgi-smart/pe"> (4) dans laquelle http://127.0.01 :8080 est l'URL de rebouclage de la relation (1 ), cgi-smart le répertoire "CGI" précité contenant un script "pe" associé à une des applications stockées dans la carte à puce 2a, référencée par exemple Ae. cette application permet l'enregistrement de l'abonné (internaute) sur l'annuaire SAU avec le profil PAU. Cette action s'effectue de la manière décrite en regard de la figure 5, par mise en œuvre des fonctionnalités "CGI", d'une part, et client/serveur, d'autre part, offertes par la carte à puce 2a. L'application Ae se comporte comme un client. Dans le premier cas (figure 6B), il n'est pas nécessaire de passer des paramètres à la carte à puce 2a. En effet, les données de profil d'abonné PAU sont uniques et enregistrées dans la carte à puce 2a.
Dans le second cas (figure 6C), les données saisies sont passées en tant que paramètres à 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 SAU, constitué par un des serveurs 4 (figures 2 ou 4). La référence unique SWEB regroupe différents modules de la figure 5 permettant à la carte à puce 2a d'offrir les fonctionnalités combinées de client/serveur WEB et de passerelle "CGI". On a également supposé que l'application Ae permettant la mise en œuvre du protocole d'enregistrement "PE" était associée à un agent traducteur de script dédié Ate ;. 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 Ae, par l'intermédiaire de l'agent traducteur de script Ate. Lors d'une étape ultérieure, l'application Ae pose une requête "HTTP" par ouverture de sessions entre paires d'agents intelligents, notamment impliquant un agent de type "réseau" (figure 5 : 132). La requête est transmise au serveur d'annuaire SAU, avec passage de paramètres. Les paramètres sont constitués notamment par les données de profil abonné PAU, de façon à permettre son enregistrement dans l'annuaire. L'adresse "URL" du serveur d'annuaire est obtenue à partir du profil d'abonné SAU enregistré dans la carte à puce 2a ou à partir des données saisies dans le formulaire P2.
A priori, le processus d'enregistrement est terminé à ce stade. Il peut cependant comprendre une ou plusieurs étapes supplémentaires. Une 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é de 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 est 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, que l'on peut référencer Ae ..., Aei, ...Aen, 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 l'on référencera PA ..., PA, ..., PAq, peuvent être stockées dans la carte à puce 2a, 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 un 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 à PAD, chacun des profils permettant de s'enregistrer sur un seul serveur d'annuaire, soit SAA à SAD. Un formulaire, ou page d'accueil, référencé P3, permettant cet enregistrement, peut se présenter comme illustré schématiquement par la figure 6E. il comprend une première zone de texte d'en-tête Zte similaire à la zone de texte Zf de la figure 6B, éventuellement complétée par des zones graphiques. Il comprend quatre zones de textes supplémentaires, ZtA à ZtD , associée aux quatre serveurs d'annuaires, SAA à SAD.. Le formulaire permet de sélectionner un ou plusieurs, voire tous.
Pour effectuer un choix entre ces serveurs d'annuaires, on peut prévoir des zones dites "cases à cocher", CCA à CCD. A titre d'alternative, on peut prévoir des hyperliens sur la page d'accueil P3, chaque hyperlien adressant la carte à puce 2a par l'intermédiaire d'une dresse de rebouclage du type de celle de la 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'abonné, PAA à PAD, et en 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+pa, (5), avec "sa, " le nom du serveur d'annuaire d'indice arbitraire / parmi les n possibles, "enr" l'action requise d'enregistrement proprement dit et "pa," le profil d'abonné à utiliser parmi les q possibles.
Une ou plusieurs requêtes "HTTP" sont posées et transmises aux serveurs d'annuaires concernés, SAA à SAD (figure 6E) et dans le cas général SAA à SAn, s'il existe n serveurs d'annuaire sélectionnâmes.
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ésentés dépendent des droits qui sont accordés à l'internaute possesseur de la carte à puce 2a, notamment des abonnements souscrits à des services donnés 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 internaute associé à 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 de localisation de cet internaute. Enfin, s'il existe plusieurs serveurs d'annuaires interrogeables, SA à SAn, il est généralement nécessaire également, comme dans le cas de l'enregistrement, de disposer de plusieurs protocoles de localisation distincts.
Ces protocoles de localisation peuvent être mis en œuvre à l'aide d'applications stockées dans la carte à puce 2a.
Le processus de localisation se déroule de façon tout à fait similaire à celui de l'enregistrement de l'internaute sur un ou plusieurs serveurs d'annuaire SA,. La seule exception notable est qu'un profil d'abonné PAS n'est plus explicitement requis. Il suffit de fournir à la carte à puce 2a l'identifiant de l'internaute recherché et l'adresse du serveur d'annuaire SA,, ou pour le moins des paramètres permettant à l'application associée à l'un des protocoles de localisation de déterminer cette adresse "URL". Un profil d'abonné PAt peut toutefois être utilisé pour en dériver automatiquement l'adresse "URL" du serveur d'annuaire SA, à l'aide duquel lequel un internaute désire localiser un autre internaute. Comme il a été indiqué, l'identifiant de l'internaute recherché peut être son adresse e-mel, adresse qui se présente typiquement sous la forme suivante : pseudo@fournisseur.com (6), avec "pseudo" le nom d'utilisateur de messagerie de l'internaute ou 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 internaute 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 F. 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'internaute sélectionne un ou plusieurs serveurs d'annuaires et fournit des données d'identification de l'internaute 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" à la carte à puce 2a et est interprétée par un agent traducteur de script At, associé à une application /A, de mise en œuvre de protocole "PL".
Par le double mécanisme client/serveur "WEB" et "CGI" (module référencé SWEB comme précédemment), une requête du type : http://127.0.0.1/? sa =loc+pseudo@fournisseur.com (7), est interprétée par la carte à puce 2a comme une demande de localisation de l'internaute 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. Il recherche dans sa base de données une adresse "IP" correspondant aux données d'identification reçues. En cas de succès, c'est-à-dire si l'internaute demandeur est effectivement enregistré, si cet internaute a le droit d'obtenir cette adresse et si les données reçues sont correctes, les données retransmises comprennent l'adresse "IP" de l'internaute recherché, ce qui permet de le localiser.
Ces différentes étapes mettent en œuvre des sessions entre agents appariés, selon un des aspects de l'invention.
On peut également stocker dans la carte à puce 2a plusieurs applications, chacune étant destinée à la mise en œuvre 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 das applications permettant la mise en œuvre de plusieurs protocoles d'enregistrement, plusieurs protocoles de 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 été représenté. Il est cependant clair que celui-ci est nécessaire à la mise en œuvre 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, PEX, PLy et PAZ, 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 internaute porteur de la carte à puce 2a, soit pour localiser un internaute 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 œuvre 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'internaute 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é de l'invention atteint bien les buts qu'elle s'est fixés.
Il permet notamment à un internaute de s'enregistrer sur un ou plusieurs serveurs d'annuaires et/ou de localiser un internaute 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 logiciels spécifiques nécessaires à la mise en œuvre 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'internaute 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.
Il n'est pas requis que l'internaute 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é "ISO" précité. On peut donc mettre en œuvre un lecteur de carte à puce standard. Seule la présence d'une couche logicielle spécifique dans le terminal est nécessaire, ce qui ne nécessite que peu de modifications et peut être réalisé 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 carte à puce, et quelle que soient leurs natures. Enfin, l'utilisation d'une carte à puce permet une sécurisation des transactions et, notamment, une authentification "robuste".
Il doit être clair cependant que l'invention n'est pas limitée aux seuls exemples de réalisations explicitement décrits, notamment en relation avec les 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, la (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 a priori moins fréquente(s) que les phases de localisation, on pourrait se contenter de ne stocker dans la carte à puce que les applications spécifiques associées à cette dernière opération. De même, comme il a été indiqué, il est possible de 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). Il est encore possible de n'enregistrer qu'une partie des profils d'abonné, profils qui pourront être fournis de façon automatique.
L'invention concerne aussi 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 d'au moins une pièce de logiciel dite d'enregistrement et/ou de localisation, le terminal et la carte à puce comprenant des moyens de traitement d'information et des moyens de stockage d'information, 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 qu'au moins l'une desdites pièces de logiciel (Ae, A,) est stockée dans ladite carte à 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 une couche protocolaire de communication spécifique, lesdites première et seconde pièces de logiciel (13, 23a) comprennent en outre au moins une paire de premières entités logicielles appariées (132, 232a), chacune desdites entités (132, 232a) coopérant l'une avec l'autre, grâce auxdits moyens de traitement d'information, de manière à permettre l'établissement d'une session d'échanges de données bidirectionnels entre au moins ledit terminal (1 ) et ladite carte à puce (2a), et/ou ledit réseau de type Internet, de manière à ce que ladite carte à puce (2a) offre la fonctionnalité d'un client/serveur "WEB" ; en ce que ladite carte à puce (2a) comprend, dans les moyens de stockage d'information, au moins une deuxième entité logicielle (ATe, AT,) 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) grâce auxdits moyens de traitement d'information du terminal et de la 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 pièces de logiciel propriétaire (Ae, A,), en vue de la sélection d'un desdits serveurs d'annuaire (S/4;) ; 2/ ouverture d'une deuxième séquence d'échanges de données entre ladite carte à puce (2a) et ledit terminal (1 ) pour lui transmettre lesdites données, grâce auxdits moyens de traitement d'information du terminal et de la carte à puce ; 3/ ouverture d'une troisième séquence d'échanges de données entre ledit terminal (1 ) et ladite carte à puce (2a) grâce auxdits moyens de traitement d'information du terminal et de la carte à puce, pour transmettre des données de sélection et des paramètres optionnels, lesdites données et lesdits paramètres optionnels comportant une référence à une desdites pièces de logiciel d'enregistrement et/ou de localisation ;
4/ mise en œuvre de ladite fonctionnalité "CGI" et exécution de ladite pièce de logiciel d'enregistrement et/ou de localisation {Ae, A , grâce auxdits moyens de traitement d'information de la carte à puce ; et
5/ en résultat de ladite exécution, ouverture), grâce auxdits moyens de traitement d'information de la carte à puce, 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.
L'invention concerne aussi une carte à puce comprenant des moyens de traitement d'information et des moyens de stockage d'information et 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 déterminés, caractérisé en ce que ladite carte à puce (2a) stocke, dans les moyens de stockage d'information, au moins une 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, dans les moyens de stockage d'information, une pièce de logiciel (23a), formant une couche protocolaire de communication spécifique, comprenant en outre au moins une première 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, grâce aux moyens de traitement d'information, 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 réseau de type Internet {RI), et en ce que ladite carte à puce (2a) comprend, dans les moyens de stockage d'information, au moins une deuxième entité logicielle {ATe, AT,) coopérant, grâce aux moyens de traitement d'information, 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 {Aβ, Aj) associées aux dits protocoles déterminés d'enregistrement et de localisation.

Claims

REVENDICATIONS
1. 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 5 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 qu'au moins l'une desdites pièces de logiciel w {Ae, A) est stockée dans ladite carte à 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 une couche protocolaire de communication spécifique, lesdites première et seconde
15 pièces de logiciel (13, 23a) comprennent en outre au moins une paire de premières entités logicielles appariées (132, 232a), chacune desdites entités (132, 232a) coopérant l'une avec l'autre de manière à permettre établissement d'une session d'échanges de données bidirectionnels entre au moins ledit terminal (1 ) et ladite carte à puce (2a), et/ou ledit réseau de 0 type Internet, de manière à ce que ladite carte à puce (2a) offre la fonctionnalité d'un client/serveur "WEB" ; en ce que ladite carte à puce (2a) comprend au moins une deuxième entité logicielle {ATe, AT) 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" : 5 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θ, A,), en vue de la sélection d'un desdits serveurs d'annuaire {SA) ; 2/ ouverture d'une deuxième séquence d'échanges de données entre ladite carte à puce (2a) et ledit terminal (1 ) pour lui transmettre lesdites données ; 3/ ouverture d'une troisième séquence d'échanges de données entre ledit terminal (1 ) et ladite carte à puce (2a) pour transmettre des données de sélection et des paramètres optionnels, lesdites données et lesdits paramètres optionnels comportant une référence à une desdites pièces de logiciel d'enregistrement et/ou de localisation ; 4/ mise en œuvre de ladite fonctionnalité "CGI" et exécution de ladite pièce de logiciel d'enregistrement et/ou de localisation {Ae, A) ; et 5/ 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.
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 de données (130, 230a), formant interface avec lesdites couches basses (101 , 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.
3. 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 est constituée par un script et en ce que ladite deuxième entité logicielle est constituée par un module logiciel dit agent intelligent traducteur de script {ATe, AT) fournissant des ordres compréhensibles par pièces de logiciel propriétaire {Aβ, A),.
4. 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 par adressage d'une page déterminée (PrP3) 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 à puce (2a).
5. 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^-P3) 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 répertoire déterminé associé à l'une desdites pièces de logiciel d'enregistrement et/ou de localisation {Ae, A), à lui transmettre lesdits paramètres optionnels et à occasionner son exécution.
6. 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 {Ae, A), ladite requête comprenant lesdites données de sélection et lesdits paramètres optionnels.
7. Procédé selon la revendication 6, caractérisé en ce qu'une pièce de logiciel dite d'enregistrement {Ae) est associée à un premier protocole {PEX) permettant l'enregistrement dudit usager sur un serveur d'annuaire déterminé {SA), en ce que lesdits paramètres optionnels sont constitués par des données définissant un profil dit d'abonné (PAZ), comprenant au moins des données dites d'identification dudit premier usager, et en ce que ladite requête "HTTP" de ladite étape 3/ comprend des premières données indiquant que l'opération demandée est ledit enregistrement et 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 associées au dit profil d'abonné sont transmises, pendant ladite étape Al, à 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 "IP" par association de ladite adresse de serveur d'annuaire {SA) et desdites données d'identification dudit premier usager.
8. 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.
9. Procédé selon la revendication 8, 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).
10. Procédé selon la revendication 6, caractérisé en ce qu'une pièce de logiciel dite de localisation {A) 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
5 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 que ladite requête "HTTP" de ladite étape 3/ comprend des premières données indiquant que l'opération demandée est ladite localisation, des deuxièmes données identifiant ledit deuxième usager à w localiser et des troisièmes données permettant d'élaborer, par ladite pièce de logiciel de localisation (A , 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), de manière à réaliser ladite localisation
15 dudit deuxième usager, par la recherche d'une adresse de type "IP", en associant lesdites données d'identification de ce deuxième usager, reçues par ledit serveur d'annuaire {SA), à des données d'enregistrement stockées dans celui-ci, et la retransmission de ladite adresse de type "IP" à ladite carte à puce (2a), de manière à permettre ladite localisation. 0
11. 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 5 déterminés, caractérisé en ce que ladite carte à puce (2a) stocke au moins une 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 0 une première 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 réseau de type Internet {RI), et en ce que ladite carte à puce (2a) comprend au 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 {Ae, A) associées aux dits protocoles déterminés d'enregistrement et de localisation.
12. Carte à puce selon la revendication 11 , 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).
EP01907762A 2000-02-10 2001-02-09 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 Withdrawn EP1169839A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0001664 2000-02-10
FR0001664A FR2805108B1 (fr) 2000-02-10 2000-02-10 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
PCT/FR2001/000396 WO2001060026A1 (fr) 2000-02-10 2001-02-09 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

Publications (1)

Publication Number Publication Date
EP1169839A1 true EP1169839A1 (fr) 2002-01-09

Family

ID=8846859

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01907762A Withdrawn EP1169839A1 (fr) 2000-02-10 2001-02-09 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

Country Status (10)

Country Link
US (2) US7194545B2 (fr)
EP (1) EP1169839A1 (fr)
JP (1) JP2003523033A (fr)
KR (1) KR100723006B1 (fr)
CN (1) CN1161942C (fr)
AU (1) AU782179B2 (fr)
CA (1) CA2366570A1 (fr)
FR (1) FR2805108B1 (fr)
TW (1) TW567700B (fr)
WO (1) WO2001060026A1 (fr)

Families Citing this family (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2791159B1 (fr) * 1999-03-15 2001-05-04 Bull Cp8 Procede d'acces a un objet a l'aide d'un navigateur de type "web" cooperant avec une carte a puce et architecture pour la mise en oeuvre du procede
FR2805108B1 (fr) * 2000-02-10 2002-04-05 Bull Cp8 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
FR2805059A1 (fr) * 2000-02-10 2001-08-17 Bull Cp8 Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit "applet"
FR2805107B1 (fr) * 2000-02-10 2002-04-05 Bull Cp8 Procede de gestion de transmissions de donnees multimedias via un reseau de type internet, notamment de donnees telephoniques, et carte a puce pour la mise en oeuvre du procede
JP4391711B2 (ja) * 2001-08-28 2009-12-24 富士通株式会社 装置、装置利用者管理装置および装置利用者管理プログラム
US7346783B1 (en) * 2001-10-19 2008-03-18 At&T Corp. Network security device and method
US7783901B2 (en) * 2001-12-05 2010-08-24 At&T Intellectual Property Ii, L.P. Network security device and method
US20030145096A1 (en) * 2002-01-29 2003-07-31 International Business Machines Corporation Method and device for delivering information through a distributed information system
EP1508865A4 (fr) 2002-05-29 2006-06-07 Sony Corp Systeme de traitement d'informations
JP4301770B2 (ja) * 2002-06-10 2009-07-22 健 坂村 接続情報管理システム、接続情報管理方法、ｉｃカード、サーバ
JP4360778B2 (ja) * 2002-06-10 2009-11-11 健 坂村 Ｉｃカードの接続情報管理システム、接続情報管理方法、ｉｃカード、サーバ、端末装置
US7844717B2 (en) * 2003-07-18 2010-11-30 Herz Frederick S M Use of proxy servers and pseudonymous transactions to maintain individual's privacy in the competitive business of maintaining personal history databases
KR100971137B1 (ko) * 2003-01-09 2010-07-20 주식회사 비즈모델라인 스마트 카드 연계 처리형 마그네틱 스트라이프 기반 네트워크 카드 운영 시스템
DE10310351A1 (de) * 2003-03-10 2004-09-23 Giesecke & Devrient Gmbh Laden von Mediendaten in einen tragbaren Datenträger
US20050004968A1 (en) * 2003-07-02 2005-01-06 Jari Mononen System, apparatus, and method for a mobile information server
JP3839820B2 (ja) * 2004-04-21 2006-11-01 株式会社エヌ・ティ・ティ・ドコモ データ通信装置およびデータ通信方法
JP2005309781A (ja) * 2004-04-21 2005-11-04 Ntt Docomo Inc 電子価値交換システム、及び、電子価値交換方法
US8812613B2 (en) * 2004-06-03 2014-08-19 Maxsp Corporation Virtual application manager
US7908339B2 (en) * 2004-06-03 2011-03-15 Maxsp Corporation Transaction based virtual file system optimized for high-latency network connections
US9357031B2 (en) 2004-06-03 2016-05-31 Microsoft Technology Licensing, Llc Applications as a service
US7664834B2 (en) * 2004-07-09 2010-02-16 Maxsp Corporation Distributed operating system management
DE102004044454A1 (de) * 2004-09-14 2006-03-30 Giesecke & Devrient Gmbh Tragbares Gerät zur Freischaltung eines Zugangs
US7624086B2 (en) * 2005-03-04 2009-11-24 Maxsp Corporation Pre-install compliance system
US7512584B2 (en) * 2005-03-04 2009-03-31 Maxsp Corporation Computer hardware and software diagnostic and report system
US8589323B2 (en) 2005-03-04 2013-11-19 Maxsp Corporation Computer hardware and software diagnostic and report system incorporating an expert system and agents
US8234238B2 (en) * 2005-03-04 2012-07-31 Maxsp Corporation Computer hardware and software diagnostic and report system
JP4979912B2 (ja) * 2005-08-31 2012-07-18 フェリカネットワークス株式会社 情報処理システム，クライアント，サーバ，プログラム，情報処理方法
US8150944B2 (en) * 2005-09-30 2012-04-03 Sony Ericsson Mobile Communications Ab Electronic apparatus with server device for managing setting data
US8186496B2 (en) * 2005-10-14 2012-05-29 Gemalto Sa Smart card customization
US8364968B2 (en) * 2006-05-19 2013-01-29 Symantec Corporation Dynamic web services systems and method for use of personal trusted devices and identity tokens
US8811396B2 (en) * 2006-05-24 2014-08-19 Maxsp Corporation System for and method of securing a network utilizing credentials
US8898319B2 (en) 2006-05-24 2014-11-25 Maxsp Corporation Applications and services as a bundle
EP1883257A1 (fr) * 2006-07-28 2008-01-30 Gemplus Procédé de synchronisation entre un equipement mobile et une carte a puce
US7987307B2 (en) * 2006-09-22 2011-07-26 Intel Corporation Interrupt coalescing control scheme
US7840514B2 (en) * 2006-09-22 2010-11-23 Maxsp Corporation Secure virtual private network utilizing a diagnostics policy and diagnostics engine to establish a secure network connection
US9317506B2 (en) * 2006-09-22 2016-04-19 Microsoft Technology Licensing, Llc Accelerated data transfer using common prior data segments
WO2008064261A2 (fr) * 2006-11-21 2008-05-29 Telos Corporation Méthode et système d'extension du rayon d'action d'un jeton de sécurité
US8423821B1 (en) 2006-12-21 2013-04-16 Maxsp Corporation Virtual recovery server
US7844686B1 (en) 2006-12-21 2010-11-30 Maxsp Corporation Warm standby appliance
US7908493B2 (en) * 2007-06-06 2011-03-15 International Business Machines Corporation Unified management of power, performance, and thermals in computer systems
US8175418B1 (en) 2007-10-26 2012-05-08 Maxsp Corporation Method of and system for enhanced data storage
US8307239B1 (en) 2007-10-26 2012-11-06 Maxsp Corporation Disaster recovery appliance
US8645515B2 (en) 2007-10-26 2014-02-04 Maxsp Corporation Environment manager
US20100257359A1 (en) * 2007-11-12 2010-10-07 Mark Currie Method of and apparatus for protecting private data entry within secure web sessions
KR100971125B1 (ko) * 2008-01-09 2010-07-20 주식회사 비즈모델라인 마그네틱 스트라이프 기반 네트워크 카드 운영 방법
KR100971128B1 (ko) * 2008-01-09 2010-07-20 주식회사 비즈모델라인 마그네틱 스트라이프 기반 네트워크 카드 운영 방법
JP4546551B2 (ja) * 2008-03-18 2010-09-15 フェリカネットワークス株式会社 情報処理装置、情報処理方法、プログラムおよび情報処理システム
KR101062099B1 (ko) * 2008-08-14 2011-09-02 에스케이 텔레콤주식회사 카드에 저장된 어플리케이션의 활성화를 위한 시스템 및 방법
US8055477B2 (en) * 2008-11-20 2011-11-08 International Business Machines Corporation Identifying deterministic performance boost capability of a computer system
US8676954B2 (en) * 2011-12-06 2014-03-18 Kaseya International Limited Method and apparatus of performing simultaneous multi-agent access for command execution through a single client
US10841316B2 (en) 2014-09-30 2020-11-17 Citrix Systems, Inc. Dynamic access control to network resources using federated full domain logon
US20160285493A1 (en) * 2015-03-23 2016-09-29 Stmicroelectronics S.R.L. Methods for performing a remote management of a multi-subscription sim module, and corresponding sim module and computer program product
US10958640B2 (en) * 2018-02-08 2021-03-23 Citrix Systems, Inc. Fast smart card login
CN110596566B (zh) * 2018-06-12 2022-03-04 北京华峰测控技术股份有限公司 一种用于ate系统的dpat测试方法

Family Cites Families (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2682255B2 (ja) 1991-04-19 1997-11-26 富士ゼロックス株式会社 電子メールシステム
US5353331A (en) * 1992-03-05 1994-10-04 Bell Atlantic Network Services, Inc. Personal communications service using wireline/wireless integration
EP0748135B1 (fr) * 1993-06-15 1998-10-28 Celltrace Communications Limited Système de télécommunications
DE69533328T2 (de) * 1994-08-30 2005-02-10 Kokusai Denshin Denwa Co., Ltd. Beglaubigungseinrichtung
US5742845A (en) * 1995-06-22 1998-04-21 Datascape, Inc. System for extending present open network communication protocols to communicate with non-standard I/O devices directly coupled to an open network
US5734831A (en) * 1996-04-26 1998-03-31 Sun Microsystems, Inc. System for configuring and remotely administering a unix computer over a network
US6557752B1 (en) * 1996-06-12 2003-05-06 Q-International, Inc. Smart card for recording identification, and operational, service and maintenance transactions
US5923884A (en) * 1996-08-30 1999-07-13 Gemplus S.C.A. System and method for loading applications onto a smart card
US5901303A (en) * 1996-12-27 1999-05-04 Gemplus Card International Smart cards, systems using smart cards and methods of operating said cards in systems
US6282522B1 (en) * 1997-04-30 2001-08-28 Visa International Service Association Internet payment system using smart card
CA2293546A1 (fr) * 1997-06-13 1998-12-17 Clayton Simmons Carte a puce, telephone sans fil, systeme et procede d'acces et de communication par internet
JP3760581B2 (ja) 1997-07-28 2006-03-29 富士通株式会社 通信相手情報検索装置及びそれを用いた通信支援システム
US6498797B1 (en) * 1997-11-14 2002-12-24 At&T Corp. Method and apparatus for communication services on a network
JP4035873B2 (ja) 1997-11-21 2008-01-23 株式会社日立製作所 Ｉｃカード及びｉｃカードシステム
WO1999040549A1 (fr) 1998-02-03 1999-08-12 Mondex International Limited Systeme et procede de commande d'acces a un code d'ordinateur dans une carte a circuit integre (ic)
FI105761B (fi) * 1998-02-13 2000-09-29 Sonera Oyj Matkaviestintilaajan palveluprofiilin muuttaminen
US6986062B2 (en) * 1998-04-09 2006-01-10 Microsoft Corporation Set top box object security system
US6385651B2 (en) * 1998-05-05 2002-05-07 Liberate Technologies Internet service provider preliminary user registration mechanism provided by centralized authority
FR2781067B1 (fr) 1998-07-10 2000-09-22 Gemplus Card Int Systemes d'organisation de carte a puce en vue de son utilisation en tant que serveur dans un reseau du type internet
US6250557B1 (en) * 1998-08-25 2001-06-26 Telefonaktiebolaget Lm Ericsson (Publ) Methods and arrangements for a smart card wallet and uses thereof
FI109756B (fi) * 1998-09-21 2002-09-30 Nokia Corp Menetelmä tiedonsiirtojärjestelmässä paikallisten resurssien hyödyntämiseksi, tiedonsiirtojärjestelmä ja langaton viestin
US6253203B1 (en) * 1998-10-02 2001-06-26 Ncr Corporation Privacy-enhanced database
US6347312B1 (en) * 1998-11-05 2002-02-12 International Business Machines Corporation Lightweight directory access protocol (LDAP) directory server cache mechanism and method
US6438550B1 (en) * 1998-12-10 2002-08-20 International Business Machines Corporation Method and apparatus for client authentication and application configuration via smart cards
US6481621B1 (en) * 1999-01-12 2002-11-19 International Business Machines Corporation System method and article of manufacture for accessing and processing smart card information
FR2791159B1 (fr) * 1999-03-15 2001-05-04 Bull Cp8 Procede d'acces a un objet a l'aide d'un navigateur de type "web" cooperant avec une carte a puce et architecture pour la mise en oeuvre du procede
US6366950B1 (en) * 1999-04-02 2002-04-02 Smithmicro Software System and method for verifying users' identity in a network using e-mail communication
US6751459B1 (en) * 1999-04-20 2004-06-15 Nortel Networks Limited Nomadic computing with personal mobility domain name system
US6547150B1 (en) * 1999-05-11 2003-04-15 Microsoft Corporation Smart card application development system and method
US6591116B1 (en) * 1999-06-07 2003-07-08 Nokia Mobile Phones Limited Mobile equipment and networks providing selection between USIM/SIM dependent features
US20040040026A1 (en) * 1999-06-08 2004-02-26 Thinkpulse, Inc. Method and System of Linking a Smart Device Description File with the Logic of an Application Program
DE59912688D1 (de) * 1999-11-17 2005-11-24 Swisscom Mobile Ag Verfahren und system zur ausarbeitung und übermittlung von sms-meldungen in einem mobilfunknetz
EP1107550B1 (fr) * 1999-12-06 2005-11-09 Alcatel Terminal destiné à exécuter une application terminal
US6587873B1 (en) * 2000-01-26 2003-07-01 Viaclix, Inc. System server for channel-based internet network
US7111051B2 (en) * 2000-01-26 2006-09-19 Viaclix, Inc. Smart card for accessing a target internet site
FR2805059A1 (fr) * 2000-02-10 2001-08-17 Bull Cp8 Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit "applet"
FR2805108B1 (fr) * 2000-02-10 2002-04-05 Bull Cp8 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
FR2805107B1 (fr) * 2000-02-10 2002-04-05 Bull Cp8 Procede de gestion de transmissions de donnees multimedias via un reseau de type internet, notamment de donnees telephoniques, et carte a puce pour la mise en oeuvre du procede
US7003663B2 (en) * 2000-12-22 2006-02-21 Gemplus Distribution of deployment information for remote applications
US6837756B2 (en) * 2001-10-05 2005-01-04 Amphenol Corporation Radially resilient electrical connector and method of making the same

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO0160026A1 *

Also Published As

Publication number Publication date
TW567700B (en) 2003-12-21
CA2366570A1 (fr) 2001-08-16
KR20020005683A (ko) 2002-01-17
WO2001060026A1 (fr) 2001-08-16
CN1363174A (zh) 2002-08-07
KR100723006B1 (ko) 2007-05-30
AU782179B2 (en) 2005-07-07
CN1161942C (zh) 2004-08-11
US7194545B2 (en) 2007-03-20
FR2805108B1 (fr) 2002-04-05
FR2805108A1 (fr) 2001-08-17
JP2003523033A (ja) 2003-07-29
US20020124092A1 (en) 2002-09-05
AU3565001A (en) 2001-08-20
US20070208586A1 (en) 2007-09-06

Similar Documents

Publication Publication Date Title
EP1169839A1 (fr) Procede d&#39;enregistrement d&#39;un usager sur un serveur d&#39;annuaire d&#39;un reseau de type internet et/ou de localisation d&#39;un usager sur ce reseau, et carte a puce pour la mise en oeuvre du procede
EP1169837B1 (fr) Procede de gestion de transmissions de donnees multimedias via internet et carte a puce pour la mise en oeuvre du procede
EP1142256B1 (fr) Terminal securise muni d&#39;un lecteur de carte a puce destine a communiquer avec un serveur via un reseau de type internet
EP1188116A1 (fr) Procede de chargement d&#39;une piece de logiciel dans une carte a puce, notamment du type dit &#34;applet&#34;
EP1044436B1 (fr) Procede de communication entre une station d&#39;utilisateur et un reseau, notamment du type internet, et architecture de mise en oeuvre
EP1076972A1 (fr) Systemd d&#39;acces a un objet a l&#39;aide d&#39;un navigateur de type &#34;web&#34; cooperant avec une carte a puce
EP1208684B1 (fr) Procede de transmission de flux de donnees a haut debit sur un reseau de type internet entre un serveur et un terminal a carte a puce
WO2000049584A1 (fr) Systeme embarque possedant des moyens d&#39;interface de reseau, et procede d&#39;activation d&#39;applications localisees dans ce systeme embarque
EP1145522B1 (fr) Procede et architecture de pilotage a distance d&#39;une station d&#39;utilisateur via un reseau de type internet
FR2823333A1 (fr) Systeme terminal interactif a equipement central multi-applicatif et peripheriques

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

17P Request for examination filed

Effective date: 20020218

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: CP8 TECHNOLOGIES

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20070626