EP1076972A1 - Systemd d'acces a un objet a l'aide d'un navigateur de type "web" cooperant avec une carte a puce - Google Patents

Systemd d'acces a un objet a l'aide d'un navigateur de type "web" cooperant avec une carte a puce

Info

Publication number
EP1076972A1
EP1076972A1 EP00910949A EP00910949A EP1076972A1 EP 1076972 A1 EP1076972 A1 EP 1076972A1 EP 00910949 A EP00910949 A EP 00910949A EP 00910949 A EP00910949 A EP 00910949A EP 1076972 A1 EP1076972 A1 EP 1076972A1
Authority
EP
European Patent Office
Prior art keywords
network
terminal
object file
file
information
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
EP00910949A
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 EP1076972A1 publication Critical patent/EP1076972A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/59—Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
    • 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/2866—Architectures; Arrangements
    • H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the invention relates to an on-board system containing information making it possible to instantiate an object located on a network, and a method for instantiating this object.
  • the invention relates more particularly still to a secure access method to this object.
  • object In the context of the invention, the term "object” must be considered in its most general sense. It encompasses many types of IT resources, such as text files, image files or multimedia files (video, sound, etc.). It also includes transactions or connections to a computer system, according to a given protocol.
  • the term "user station” must be understood in a general sense.
  • the aforementioned user station 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 card terminal, called a dedicated terminal.
  • the term “network” includes any network comprising a set of servers linked together, in particular a planetary network in which the information is transported from end to end.
  • These include the Internet, any network in which data is exchanged according to an Internet protocol, private networks of companies or similar, called “intranets", and networks extending them to the exterior, called “extranet”.
  • It can in particular also be a GSM network (from the English Global System Mobile), ATM, UMTS, GPRS (from the English Global Packet Radio System), a so-called “Wireless Network” network such as for example I3E 802.11, BLUE TOOTH.
  • 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 network.
  • FIG. 1A schematically illustrates an example of architecture of this type.
  • the terminal 1 for example a personal computer, includes a smart card reader 3. This reader 3 may or may not be physically integrated into the terminal 1.
  • the smart card 2 has an integrated circuit 20 including input connections -outlets are flush with the surface of its support to authorize a supply of electrical energy and communications with the terminal 1.
  • the latter comprises circuits for accessing a network of RI data transmissions. These circuits depend, in particular, on the nature of the RI network and of the terminal 1. For example, it can be a network card for a local type network or a modem to connect to a line. dial-up telephone or to a digital integrated services network (“ISDN”), to connect to the Internet, for example via an Internet service provider ("Internet Service Provider" or "ISP", according to English terminology) .
  • ISDN digital integrated services network
  • 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 and a keyboard 6.
  • 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. 1A.
  • server is meant any information server capable of processing communication protocols, either to give access to documents, or to give access to machines.
  • the access circuits 11 put the terminal 1 in communication with the servers 4 using special software 10, called a browser of the "WEB” type, or “browser” depending on the Anglo-Saxon terminology. This allows access to various applications distributed over the entire RI network, generally in a “client-server” mode.
  • browser is meant any means offering the following functions:
  • An SGML page contains presentation attributes, and links to other SGML documents, or "hyper-links" to the outside world, that is to say also URIs (from the English Unified Resource Identifier, or Universal resource identifier).
  • the SGML language comprises in a manner known per se several dialects, including HTML, XML, and WML.
  • communications on networks are carried out in accordance with protocols meeting standards comprising several superimposed software layers.
  • 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 ("news” in Anglo-Saxon terminology), etc.
  • FIG. 1 B The logical architecture of the system comprising a terminal, a smart card reader and the smart card, is represented diagrammatically by FIG. 1 B. It is described by the ISO 7816 standard, which itself comprises several sub-assemblies: - ISO 7816-1 and 7816-2, with regard to the dimensions and marking of cards;
  • FIG. 1B on the terminal side 1, only the layers meeting the ISO 7816-3 standard, referenced 101, and the "APDU” order manager (ISO 7816-4 standard), referenced 102, have been represented.
  • the layers meeting the ISO 7816-3 standard are referenced 200 and the "ADPU” order manager (ISO 7816-4 standard) is referenced 201.
  • the applications are referenced A, ..., Aj, ..., A n ; n being the maximum number of applications present on the smart card 2.
  • This game typically presents writing orders and reading orders.
  • the format of the orders is known by the Anglo-Saxon 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 “.”
  • an application A is, for example, in the form of a piece of software, called “applet”, in the language “JAVA” (registered trademark), which will be called hereinafter "cardlet”.
  • the selection of a particular "cardlet” A ⁇ is obtained using an "APDU” of the selection type ("SELECT"). Once this choice has been made, the "APDUs" which follow it are routed to this "cardlet”.
  • 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.
  • Aj application is conventional applications, which will be called hereinafter "GCA” (for "Generic Card Application”).
  • GCA for "Generic Card Application”
  • the latter can be assigned various functions, in particular security functions.
  • card 3 cannot communicate directly with commercial browsers, unless the code of the latter is changed.
  • Current smart cards which moreover comply with the standards recalled above, have a hardware and software configuration which also does not allow direct communication with the Internet. In particular, they cannot receive and transmit data packets, according to one or the other of the protocols used on this type of network. It is therefore necessary to provide an additional piece of software, located in terminal 1, generally in the form of what is called a "plug-in", according to English terminology.
  • This piece of software which bears the reference 12 in FIG. 1A, performs the interface between the browser 10 and the card 2, more precisely the electronic circuits 20 of this card 2.
  • the system host associated with card reader 3, that is to say terminal 1 is also associated with a particular application.
  • a specific terminal called “dedicated”, for each particular application.
  • the capacity for recording information in memory circuits, whether live or fixed, of a smart card remains and will remain very limited, if we compare this capacity to that offered by a "host” terminal of this smart card, and naturally to those offered by larger systems, “mini-computers” or large systems of the so-called “main frame” type ".
  • the invention aims to overcome the drawbacks of the devices of the known art and some of which have just been recalled, while meeting the needs which are felt.
  • it must be possible to access a large number of applications, even large in terms of quantity of data, diverse in nature and distributed across the Internet.
  • the accesses must benefit from maximum security, that is to say in practice be carried out via and under the control of a smart card containing all the data necessary for securing data exchanges.
  • these accesses must be able to be made from a commercial browser and be transparent for a user, who must not
  • the smart card presents to the host system, that is to say the terminal, a model of virtual terminal, for example in the form of a page in "HTML" language (for "HyperText Markup Language "), or more generally in hypertext language, or even in the form of an" applet ", in” JAVA “language (registered trademark), which allows the user to choose a particular application from those available and offered by the smart card.
  • HTML HyperText Markup Language
  • JAVA registered trademark
  • 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. They are only involved 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.
  • the specific communication software layers notably comprise software components, called “intelligent agents", allowing in particular protocol conversions.
  • intelligent agents paired in the respective specific communication layers associated with the terminal and the smart card.
  • sessions are established between paired intelligent 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 what whether it be.
  • one or more intelligent agents called script translators are provided, which receive requests from a browser and translate them into "APDU” orders understandable by the "CGA” type application.
  • This technical characteristic makes it possible to install in a smart card, the architecture of which conforms to the method of the invention, a mechanism similar to the so-called “CGI” function (for "Common Gateway Interface") installed in the "WEB” servers. "classic.
  • this allows access to computer resources distributed over a data transmission network to which the terminal is connected, in particular the Internet network or an equivalent network (intranet, extranet), without the user having to worry about their locations.
  • these resources will be called “virtual objects", static or dynamic.
  • an intelligent script translator agent dedicated to this task is implemented, cooperating with the other intelligent agents present in the terminal and / or the smart card. This agent makes it possible to define the virtual objects to which the smart card can access, and therefore also the user (or holder of the smart card), on the one hand, and provides the interrogator browser, via the smart card , methods for accessing these virtual objects on the other hand.
  • the invention therefore relates to an on-board system, equipped with a chip comprising information processing means and information storage means, and intended to cooperate with a network through a terminal, characterized in that: it stores at least one object file containing information associated with an object located on the network and allowing an instance of this object to be produced;
  • network interface means arranged to cooperate with paired network interface means, located in the terminal, so that the on-board system constitutes an information server on the network;
  • object file interface means arranged to establish a correspondence between information passing through the network interface means and assigned to at least said object file, and information exchanged with said d file. 'object.
  • the object file comprises a piece of autonomous software executable on navigation software.
  • this piece of autonomous software is capable of implementing an object file management system of the embedded system.
  • said object file includes a description of actions to be performed to instantiate an object.
  • the actions include actions carried out inside the on-board system and consisting of sessions between agents of the on-board system.
  • the actions include actions performed outside the on-board system and consisting of sessions with agents of the terminal in order to obtain information from information servers of the network.
  • said network interface means are arranged to cooperate with the paired network interface means, located in the terminal, so that the on-board system behaves like a client capable of connecting to at least one server of the network.
  • the invention also relates to a method for instantiating an object located on a network, and using the abovementioned embedded system, characterized in that it makes it possible to describe a set of sessions between agents by an object file, by means of at minus the following steps:
  • an appeal argument describes the opening of a session with another agent.
  • an agent modifies the list of arguments used by another agent.
  • the method is characterized in that it implements sessions between agents described by an object file executed from the information server of the embedded system by means of at least the following steps:
  • the identification is carried out by a particular directory name.
  • the identification is carried out by a particular file attribute.
  • the identification is carried out by a specific naming convention.
  • the execution is carried out by instantiating the first agent associated with the object file.
  • the execution is carried out by instantiating one or more agents referenced by the object file.
  • the method is characterized in that it implements sessions between agents described by an object file executed from a navigation software by means of at least the following steps:
  • the production of the specific software is carried out by means of any interpreted language, executable by the navigation software.
  • the object file interpreter is produced using navigation software.
  • the method is characterized in that it allows the on-board system to make possible the implementation of sessions between agents described by an object file executed from a navigation software, and in that it comprises the step consisting in identifying, by means of a universal resource identifier, specific software arranged to implement the navigation software.
  • the universal resource identifier is integrated into a hyper-text document.
  • said hyper-text document is contained in the on-board system.
  • said hyper-text document is contained on a network information server, remote from the on-board system.
  • said specific software is loaded by a method available on the navigation software and deduced from the universal resource identifier.
  • the invention also relates to an on-board system, equipped with a chip comprising information processing means and information storage means, and intended to cooperate with a network through a terminal, characterized in that it comprises network interface means, arranged to cooperate with paired network interface means, located in the terminal, so that the on-board system constitutes an information server on the network and / or behaves like a client capable of connecting to at least one server on the network.
  • the invention also relates to a terminal intended to cooperate with a network and comprising means for processing information, means for storing information, and means for cooperation with an on-board system, equipped with a chip comprising means for information processing and information storage means, characterized in that it comprises network interface means, arranged to cooperate with paired network interface means, located in the on-board system so that the embedded system constitutes an information server on the network and / or behaves like a client capable of connecting to at least one server of the network.
  • the terminal dynamically acquires said network interface means by a software loading mechanism from the network. It can notably be a “plug-in” mechanism, according to Anglo-Saxon terminology.
  • said paired network interface means constitute, in the terminal and in the on-board system, a stack comprising one or more communication layers such that they allow the on-board system to share all or part of the communication layers of the terminal.
  • the terminal advantageously has access points on its communication layers, which allow it to derive a flow of information from or to one or more of these layers. These access points correspond to the points known per se under the name "SAP" defined by the ISO standard (Service Access Point, according to English terminology).
  • the invention also relates to an on-board system, equipped with a chip comprising information processing means and information storage means, and intended to cooperate with a network through a terminal, characterized in that it comprises network interface means, arranged to cooperate with paired network interface means, located in the terminal, so that at least part of an information flow exchanged between an application of the terminal and the network crosses the network interface means of the on-board system, according to criteria known to the terminal.
  • the invention also relates to a terminal intended to cooperate with a network and comprising means for processing information, means for storing information, and means for cooperation with an on-board system, equipped with a chip comprising means for information processing and information storage means, characterized in that it comprises network interface means, arranged to cooperate with paired network interface means, located in the on-board system so that at least part of an information flow exchanged between an application of the terminal and the network passes through the network interface means of the on-board system, according to criteria known to the terminal.
  • the derivation of part of the information flow to the on-board system is advantageously carried out by the information processing means of the terminal according to pre-established criteria either statically or in a negotiated manner by a dialogue with the system on board; in the latter case, the terminal can, for example, ask the on-board system for its "IP" address (if it is an Internet network), using known protocols.
  • the above criteria include one of the following:
  • FIGS. 1A and 1B schematically illustrate the hardware and logic architectures, respectively, of an example of a card-based application system chip according to known art
  • - Figure 2 schematically illustrates an example of a smart card-based application system according to the invention, the latter acting as a "WEB"server
  • FIG. 3 illustrates in a simplified manner the logical architecture of a system in which the smart card comprises intelligent agents
  • - Figure 4 illustrates a system architecture according to the invention, in which the smart card comprises intelligent agents translating scripts
  • FIG. 5 is a diagram schematically illustrating the main phase of exchanges between a browser and a smart card presenting the architecture of FIG. 4
  • FIG. 1A and 1B schematically illustrate the hardware and logic architectures, respectively, of an example of a card-based application system chip according to known art
  • - Figure 2 schematically illustrates an example of a smart card-based application system according to the invention, the latter acting as a "WEB"server
  • FIG. 3 illustrates in a simplified manner the logical
  • FIG. 6 is a diagram schematically illustrating an essential aspect of the method according to the invention by which it is possible to access virtual objects distributed over a network of Internet type via a smart card and a browser of type "WEB";
  • - Figure 7 schematically illustrates the organization of a so-called virtual file management system for the implementation of this aspect of the method of the invention;
  • FIG. 8 is an example of architecture comprising a virtual file management system according to FIG. 7;
  • - Figures 9 to 15 are diagrams schematically illustrating several embodiments of the method according to the invention.
  • OSI Open System Interconnection
  • P "ISO” Open System Interconnection
  • L Low Layer
  • high layers for example the so-called "application” layer
  • transport intermediate layers
  • a given layer offers its services to the layer immediately above it and requires other services from the layer immediately below, via appropriate interfaces.
  • Layers communicate using primitives. They can also communicate with layers of the same level. In some architectures, one or the other of these layers may be nonexistent.
  • the terminal 1 comprises circuits 11 for accessing the RI network, consisting for example of a modem for the Internet network or of a network card for a local network. These circuits group together the lower software layers Ci and C2, corresponding to the "physical” and “data link” layers.
  • the upper layers C3 and C4 have also been shown, corresponding to the “network addressing" ("IP”, in the case of the Internet) and “transport” (“TCP”) layers.
  • IP Internet addressing
  • TCP transport layer
  • 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 (FIG. 1A) to make requests to a server 4 (FIG. 1A), for consulting "WEB” pages (“HTTP” protocol), for transferring files (“FTP” protocol). ) or sending e-mail ("e-mail” protocol), in a completely classic way.
  • the terminal 1 also includes a card reader 3, integrated or not.
  • the card reader also includes two lower layers, CC1 (physical layer) and CC2 (data link layer), playing a role similar to layers C and C2.
  • CC1 physical layer
  • CC2 data link layer
  • the software interfaces with the layers CC1 and CC2 are described, for example, by the specification "PC / SC" ("part 6, service provider").
  • PC / SC part 6, service provider
  • CC1 and CC2 are notably described by the ISO 7816-1 to 7816-4 standards, as it has been recalled.
  • An additional software layer 16 forms the interface between the application layers (not shown) and the lower layers, CC-
  • the main function assigned to this layer is a multiplexing / demultiplexing function.
  • the communications with the smart card 2a are carried out according to a paradigm similar to that used for the manipulation of files in an operating system of the type "UNIX" (registered trademark): OPEN ("OPEN”), READ
  • CCai physical layer
  • CCa2 data link layer
  • the specific layer 13 interfaces with the "low layer drivers” 15, with the libraries 14 with 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 browser
  • Internet 10 (FIG. 2), electronic mail, etc., for uses implementing the smart card 2a.
  • modules 130 or 230a for transferring information blocks 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;
  • a specific configuration management module 131 and 231a, respectively; module which can be likened to a particular intelligent agent. There is therefore, in the terminal 1 and the smart card 2a, a protocol communication stack between the two entities.
  • level two data link layers
  • CC2 and CCa2 ensure the exchange between the smart card 2a and the terminal 1.
  • These layers are responsible for the detection and possible correction of transmission errors.
  • Different protocols can be used, and as non-exhaustive examples the following:
  • 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 level two layer are of the "data request” ("Dafa.reg_; esf") and "data send” by card (“Data.response”) type, 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 establishment 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 2 layer (data link layer).
  • This particular communication protocol makes it possible to connect at least one pair of "intelligent agents".
  • 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 "intelligent agents" is associated with a session.
  • a session is a two-way data exchange between these two agents.
  • An intelligent agent 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.
  • a particular intelligent agent is advantageously identified by an integer, for example on 16 bits (number between 0 and 65535). This identifier is used, for example, in a protocol data unit constituting a destination reference and a source reference.
  • type agents There are two main categories of intelligent agents: type agents
  • server which are identified by a fixed reference
  • client type agents, which are identified by a variable reference, delivered by the configuration management module, 131 or 231a.
  • the process for opening a session is usually as follows: an intelligent agent of the "client” type opens the session to an intelligent agent of the "server” type.
  • Layers 130 and 230a manage tables (not shown) which contain the list of intelligent agents present, on the host terminal side 1 and smart card 2a.
  • Intelligent agents are associated with particular properties or attributes. To fix ideas, and by way of nonlimiting example, the following six properties are associated with intelligent agents: "host”: agent located in the terminal; - "card”: agent located in the smart card;
  • the configuration management modules, 131 and 231a can be assimilated, as indicated, to particular intelligent agents.
  • the module 131, on the host terminal side l manages in particular information relating to the configuration of this terminal (operating modes), list of the other intelligent agents present, etc.
  • the module 231a, on the smart card side 2a has similar functions. These two intelligent agents can be put in communication with each other to establish a session.
  • the smart card 2a offers the host system, that is to say the terminal 1, a model of virtual terminal. To do this, the smart card 2a behaves like a "WEB" server.
  • the smart card 2a is "addressed" by the browser 10. It then transmits to it a "WEB” type page in "HTML” language, an “applet” or any other piece of software.
  • the "WEB” page can be in the form of a home page giving a choice of possible applications and / or hyperlinks to external servers.
  • the smart card 2a is advantageously "addressed” by using a "URL” address (for "Universal Resource Locator") defining a loopback on the terminal 1 itself, and not a pointing on a server external.
  • a "URL” address for "Universal Resource Locator”
  • the structure of this "URL” is usually as follows: http: //127.0.0.1: 8080 (1), in which 127.0.0.1 is the loopback "IP" address and 8080 is the number of port.
  • FIG. 3 illustrates in a simplified manner the logical architecture of a system of which the smart card 2a comprises intelligent agents, only two of which have been represented: an intelligent agent of the type not precisely defined 232a2 and an intelligent agent 232a ⁇ , of the type says "WEB".
  • the logical stack includes, the lower protocol layers, referenced 200a, meeting the standards
  • the packet multiplexer 230a being an interface to intelligent agents, in particular the intelligent agent "WEB" 232a-
  • 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: Ci and C2) > the 102 order manager "APDU "and the packet multiplexer 130, the latter being an interface with intelligent agents, of which only one 132 is shown.
  • the latter which will be assumed to be "network type" can also communicate, on the one hand with the browser 10, via the "TCP / IP” layers 100, on the other hand with the Internet network RI, via these same layers “TCP / IP” 100 and member 11, for access to the RI network.
  • the "APDU" order manager 201 a also interfaces with one or more application-level layers, which will simply be called applications. These applications are, as has been indicated, applications of the conventional type, which have been called “cardlets”.
  • the "WEB server” function provided by the smart card 2a, can be performed by combining the intelligent agent "WEB” 232a ⁇ in the smart card and the network agent 132 in the terminal 1 The smart card 2a therefore clearly presents the "WEB” server functionality.
  • any conventional application, Ai to A n of the aforementioned "CGA” type, can be activated through this "WEB” server, or by the "WEB” browser. "10 present in terminal 1, either by a remote browser, located at any point on the Internet RI network.
  • the applications, A- ⁇ to A n do not need to be rewritten and are implemented as they are.
  • these applications remain accessible to a terminal of the conventional type, that is to say in accordance with the known part.
  • the "WEB” server function offered by the smart card 2a, includes a mechanism similar to the so-called “CGI” function (for "Common Gateway Interface”) installed in conventional "WEB” servers.
  • CGI Common Gateway Interface
  • CGI is a specification for the implementation, from a “WEB” server, of applications written for the "UNIX” (registered trademark), "DOS”, or "WINDOWS” (registered trademark) operating systems.
  • UNIX registered trademark
  • DOS registered trademark
  • WINDOWS registered trademark
  • the request is usually displayed on a computer screen in the form of a form included in an "HTML" page.
  • the "HTML” 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 "HTML” code of 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.
  • a user invokes from his browser "WEB” ( Figure 3: 10) a "URL” which can appear as follows: "http: // @ card: 8080 / xxx .html "(3), in which "@card” is an IP address of the smart card (for example the loopback address "127.0.01" previously described: see formula (1)), and "xxx.html” is a page in language “ HTML "relating to a particular application” xxx "offered by the smart card.
  • the smart card returns an "HTML" page, for example of the form type.
  • the user fills in the fields of the form and transmits the content to the smart card, usually by clicking on a particular field, of the "push button” type.
  • the data is then sent and received by the network agent 132.
  • the data then passes through the packet multiplexer 130 (which constitutes one of the components of the specific layer 13, terminal side 1), the "APDU” order manager 102, the protocol layers 101, to be transmitted to the smart card 2a. They then pass through the protocol layers 200a, the "APDU” order manager 201a, the packet multiplexer 230a to be received by the "WEB" agent 232a-
  • a logical session is therefore established between the two intelligent agents, as explained above.
  • the data sent to the "WEB” agent 232a ⁇ is transported, in a conventional manner per se, in the form of "APDU” orders intended for the particular application "Packet multiplexer".
  • the “APDU” order manager 201a selects this application in a manner very similar to the other “CGA” type applications present in the smart card 2a, referenced A to An- In other words, the packet multiplexer 230a is seen by the order manager "APDU" 201a as an ordinary "CGA” application.
  • the "HTTP" request is analyzed by the "WEB” agent 232a ⁇ which detects a reference to a particular directory, which will be called hereinafter by convention “cgi-smart", on the one hand, and to a particular application , for example "xxx” in the case of the example described, on the other hand.
  • the full path is therefore, in this case "cgi-smart / xxx”.
  • the above entity designates a particular script associated with an equally particular application "xxx”.
  • the script is interpreted by an intelligent agent called
  • Script translator agent which will be called “ATS” below.
  • 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 translator capable of translating all of the scripts present in the smart card 2a; cl by a dedicated scripting agent which will be called “ATSD” below (one per script); or d / by an agent “APDU” 2010a of the order manager "APDU” 201a, which is equipped, in this case, with a double capacity.
  • the "APDU” agent 2010a is a component of the "APDU” order management layer 201a.
  • the latter is a layer capable of centralizing all the "APDU” orders sent and / or received by the system, of selecting applications, from A to A n , but also of offering an interface of the type intelligent agent. It is therefore capable, according to one of the characteristics of the process, of communicating with all the intelligent agents of the system (via sessions), that these agents are located in the terminal
  • FIG. 4 illustrates an example of architecture for which the translating agents are of the "ATSD” type. They are referenced ATS ⁇ to ATSn and associated with the applications A- to An- The selected application being assumed to be the Aj application, 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 translator agent, for example the ATS agent, and the "APDU” agent 2010a. The orders are then issued to the "APDU” agent 2010a.
  • the "APDU” order manager 201a selects the "CGA” Aj application (for example the "PME” 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 from the "CGA” Aj application are transmitted to the "APDU” order manager 201a, to the "APDU” agent 2010a, then again to the ATSj agent (and more generally to the translator agent script).
  • the script translator for example the ATSj agent in the example in Figure 4, creates a page in "HTML" language and transmits it via the different layers taken by the initial request, but in reverse, this to be presented on the display screen 5 ( Figure 1A).
  • FIG. 5 schematically summarizes the main stages of the process which has just been described: a / transmission via the Internet network RI (or from the local terminal: in both cases using a conventional browser 10) an "HTTP" request, referenced RQ; b / response from the “WEB” server of the smart card 2a, in the form of a form, referenced FO; c / transmission of the completed form, in the form of a new RQ request; and d / response in the form of an "HTML" page, referenced PR.
  • the answer could also consist in the transmission of a file, or a piece of software or "Applet”.
  • the method according to the invention will make it possible to define an environment advantageously virtual secured by smart card.
  • this environment is compatible with so-called multimedia type applications.
  • This last characteristic is particularly advantageous because recent "WEB" browsers, but of a completely classic type in themselves, allow, by nature, to build multimedia environments (moving images, sounds, etc.). They are indeed associated with software tools, integrated or not, allowing to handle multimedia files (viewer, etc.).
  • browsers make it possible to download multimedia data files, usually large and to store them on a hard disk, for example in the terminal, or on a similar mass storage device.
  • the method according to the invention allows this mode of operation.
  • the multimedia virtual environment secured by smart card makes it possible to: define virtual objects to which the smart card can access; provide methods of accessing these objects.
  • FIG. 6 schematically illustrates this essential aspect of the method according to the invention.
  • a user Uj interrogates the smart card 2a using the "WEB" browser 10 included in the terminal 1.
  • the smart card 2a will return to the browser a list of so-called virtual objects Obvj, i being an arbitrary index, to which it has access, that is to say in a practical manner for which the smart card 2a or the user Uj has rights d 'access.
  • these access rights can be strictly linked to the smart card 2a and immutable. They can also be linked to a user profile, the user Uj providing, for example, identification data and a password.
  • the smart card 2a verifies by comparison with data from a security database stored in a fixed memory and, if the result of the comparison is positive, provides a list of virtual objects Obvj associated with the pair: " identification data - password ".
  • this first phase can implement an encryption process for the data exchanged between the terminal and the smart card 2a or implement a secure transmission protocol "HTTPS".
  • HTTPS secure transmission protocol
  • the smart card 2a will also provide a list of methods of accessing the Obvj virtual objects.
  • the virtual objects Obvj which are of the static or dynamic type as indicated above, can be located either in the smart card 2a, or in the terminal 1, or, more generally, in any system connected to the Internet network RI.
  • this location is “transparent” for the browser 10, and therefore for the user Uj, as will be shown.
  • the method according to the invention calls in particular on what will be called hereinafter a virtual file management system, or "SGFV”, and an intelligent agent translator of specialized script, which will be called “ATSDA / SGVF” , dedicated to this task.
  • This intelligent agent provides the list of virtual objects Obvj to which the smart card 2a can access.
  • a specific "URL” address is associated with each Obvj virtual object. Invoking this "URL” from "WEB" browser 10 makes it possible to instantiate the virtual object Obvj, by means of a determined call method, specific or not to this object.
  • SGF file management system
  • a directory is a particular file whose content is a list of file descriptors.
  • a descriptor includes for example the following elements: the name of the file; - the length of the file; the date of creation; a reference to find the list of blocks in the file (number of the first block, table of block numbers, etc.); and and attributes that specify particular properties of the file (directory, read, write, execute, etc.).
  • the first directory is usually called the root directory.
  • a directory that is not root is called a subdirectory.
  • the directory that contains the descriptor of a given file is its parent directory.
  • the address of a file in the "SGF" is therefore a succession of directory names, from the root directory to the parent directory of the file, which defines a path. As an example, such a path looks like this:
  • the "SGFV" file management system which will be called virtual, makes it possible to define virtual objects Obvj to which the smart card 2a can have access.
  • a virtual object Obvj is associated with a virtual elementary file.
  • the content of a virtual elementary file is made up of all the information which makes it possible to access the associated virtual object Obvj and to obtain an instance of it in terminal 1.
  • the "SGFV” system can constitute a subset of a conventional "SGF” system, and, more precisely, an “SGFV” is housed inside 'an elementary file, as defined by the aforementioned ISO 7816-4 standard.
  • a file descriptor will usually include the following: the name of the file; - the length of the file; the date of creation; a reference (advantageously an integer) which makes it possible to find the list of blocks in the file (number of the first block, table of block numbers, etc.): a virtual file is identified by its name or this unique reference; and file attributes that specify particular file references
  • direct virtual object an object which is instantiated from the smart card 2a. It is typically a static Obvj virtual object that can be manipulated by the browser, for example displayed (image, etc.).
  • indirect virtual object an Obvj virtual object which is instantiated from the browser.
  • FIG. 8 schematically illustrates the architecture of a smart card system making it possible to instantiate a virtual object Obvj located at any location on the Internet network RI, via the browser 10 and the smart card 2a.
  • the elements common to the previous figures have the same references and will only be re-described as necessary.
  • FIG. 8 The architecture illustrated in FIG. 8 is very similar to that of FIG. 4.
  • the essential difference is constituted by the fact that a "SGFV” 8 has been provided, stored in the smart card 2a, and an intelligent agent. specific script translator "ATSDA / SGFV", referenced 7.
  • the operating mode is similar to that illustrated in FIG. 4 when it is desired to access a particular application Aj. It is therefore unnecessary to re-describe it in detail.
  • the particular application is replaced by the virtual file management system "SGFV" 8.
  • a session is established between the intelligent network agent 132 and the intelligent "WEB" agent 232a-
  • a session is then established between the "WEB” agent 232a ⁇ and the intelligent agent "ATSDA / SGFV" 7.
  • ATSDA / SGFV 7 is accessible by "URLs", typically of the type:
  • URL of a directory designates an "HTML” page which contains the list of its elements.
  • the "URL” address of an elementary file is used to create an instance of the Obvj virtual object associated with this virtual file.
  • This root directory is made up of a set of subdirectories and files as shown schematically in Figure 9.
  • a root directory rep # 0 at the top level
  • a real elementary file fe # 7 and a sub - real directory srep # 1 at the level immediately below
  • a virtual sub-directory rep # 2 and a virtual elementary file fe # 5 at the lowest level, both dependent on the real sub-directory , the reference numbers being purely arbitrary.
  • the intelligent agent "ATSDA / SGFV" 7 transmits to the browser 10, in response to the request received, an "HTML" page (not shown) showing, in one form or another, the hierarchical structure from "SGFV” 8.
  • the page is usually displayed on a display screen (FIG. 1A: 5), for example in the form of a menu.
  • Each line of the menu consists of a hyperlink describing a sub-directory or an elementary file.
  • the display can advantageously be in graphic form, associated or not with a descriptive text, the drawing of the tree in FIG. 9 being displayed on the aforementioned screen. You can still display icons or complex shapes (for example in 3 dimensions), each one associated with one of the virtual objects to be instantiated, and which can be representative of their nature (for example, a camera representing a file video), whether or not associated with a descriptive text.
  • the user Uj is invited to click on a hyperlink (on a node or on a branch in the case of a graphic). By this action, he will be able to obtain an instance of the desired Obvj virtual object.
  • the "SGFV" system 8 is advantageously recorded in a memory of the re-programmable type included in the smart card 2a, for example of the type "EEPROM” (electrically erasable memory), as illustrated diagrammatically in FIG. 10.
  • the "SGFV" 8 reproduces the structure of the tree in FIG. 9.
  • the non-virtual files are saved in the smart card 2a and conform to the usual paradigm which governs the "SGF". They contain data, such as for example keys, data useful to the intelligent agent "ATSDA / SGFV" 7. Different conventions are possible as for the definition of the information necessary for instantiating a virtual object Obvj, and by example
  • a virtual file of zero length inherits the access methods from its parent directory; - a virtual directory is associated with a virtual elementary file whose name is imposed (for example "virtual”), and which contains the access methods of this directory.
  • an intelligent agent "ATSDA / SGFV" 7 must also provide a method of access to a given virtual object Obvj, this from all or part of the information contained in a virtual file elementary.
  • Figure 11 schematically illustrates this process.
  • two access methods are provided, which will be called direct and indirect, respectively, according to the attributes of the virtual elementary file considered.
  • the direct method consists of a description of a chain of intelligent agents implemented in the process making it possible to access a virtual object Obvj and to obtain an instance of it in the terminal.
  • a given intelligent agent receives from the agent who initiates this session, a list of call structures which will be referred to below as “call method” or "Method PDU” (for "Method Protocol Data Unit”).
  • a call structure includes:
  • the first intelligent agent addressed by the aforementioned list "consumes” a first call structure intended for it. It forwards the rest of the structure list to a next intelligent agent, with which it establishes a session, until the list is exhausted.
  • an example of the various stages of exchanges between the intelligent agent "ATSDA / SGFV” 7 and two intelligent agents in cascade, 232am and 232a ⁇ is illustrated diagrammatically by figure 12.
  • the call structure list issued by the intelligent agent "ATSDA / SGFV” 7 actually comprises two separate sublists, identified # 1 and # 2 in their headers, respectively.
  • the first is consumed by the first intelligent agent, 232am, and the second by the second intelligent agent, 232a ⁇ -
  • An intelligent agent for example the intelligent agent 232am, is identified by a reference, or agent identifier ("Agent Identifier # 1 "or” Agent Identifier # 2 ").
  • Agent Identifier # 1 or Agent Identifier # 2 ".
  • the arguments of the sub- list it retains (“Argument # 1" or "Argument # 1" is made up of a set of data useful for the proper functioning of this agent.
  • a data item can be a file name (not virtual) or direct virtual).
  • a given intelligent agent for example the intelligent agent 232am, can modify the rest of the call structure list before transmitting it to the next intelligent agent, 232a ⁇ - To do this, it addresses this intelligent agent, 232years old, and establishes a session with him.
  • the calling method can be advantageously described using the ASN.1 language (“Abstract Syntax Notation 1” of PISO)
  • the direct access method ultimately makes it possible to instantiate a virtual object Obvj directly from the smart card 2a. It is a p ⁇ ori a static object.
  • the instantiated object is usually in the form of an "HTML" page or an "applet” transmitted to the browser 10.
  • the second access method, or indirect access method is actually also a method of 'direct access, but implemented from terminal 1, and no longer from smart card 2a. This method is mainly used to instantiate Obvj virtual objects of the dynamic type.
  • the intelligent agent "ATSDA / SGFV” 7 transmits to the browser 10 an "HTML" page which includes a hyperlink pointing to the method direct access associated with the Obvj virtual object
  • Two variants can be implemented. The first variant is to use an "applet”. The link on the access method is then an "applet" located at the address "@card”, which can itself be designated by: the name (ie a "URL") of a non-virtual file, saved on the smart card 2a; - a "URL” which designates a direct virtual file.
  • a call parameter of this "applet” is a call structure list, for example coded in ASN.1 as indicated above.
  • the "applet” contained in a “HTLM” page is downloaded, from the smart card 2a or the Internet network RI, to the browser 10, then executed by the latter on a mandatory basis (forcing).
  • This "applet” establishes a session with a first intelligent agent, arbitrarily referenced 232ap.
  • the connection to this intelligent agent 232ap uses, for example, a data exchange model of the client-server type "TCP / IP" (that is to say the class called “socket JAVA").
  • FIG. 13 schematically illustrates the different phases of the exchanges making it possible to instantiate a virtual object by the indirect method.
  • the parameters of the example previously described in this case, the virtual elementary file fe # 5, which results in the "URL" address of the configuration (6) above. It has been assumed that the address of the smart card to be used is "@card” and the port 8080.
  • the request is transmitted to the intelligent agent "ATSDA / SGFV" 7 according to the process previously described.
  • the next phase consists, for the browser, in requesting the map applet 2a by means of the call structure list, which defines the parameters for calling the Papplet.
  • the card transmits the Papplet to it, which will be loaded by the browser on its "Java” virtual machine, where it will be executed.
  • the next phase consists, for the browser, in calling the intelligent agent 232ap using the “socket” class of the “Java” language.
  • Each intelligent agent for example 232ap, performs a specific task: decryption of an encrypted message, verification of passwords and / or security data, conversion of a file from one first format to another, etc.
  • 232ap Although only one intelligent agent, 232ap, has been represented, it is possible to provide, as necessary, several intelligent agents in cascade as in the previous case (FIG. 12), which is illustrated in the figure. 13 by the dotted lines.
  • each intelligent agent, 232ap consumes part of the list structure, that which is intended for it, and transmits the rest, unchanged or modified, to the following intelligent agent (not shown).
  • FIG. 14 schematically illustrates the sequence of steps for instantiating such a virtual object, referenced FS. It is assumed that the browser 10 does not have an appropriate reader for such a format. This player, referenced LS, will be sought on a website, which may or may not be separate from the site where the FS sound file is located.
  • the sequence of steps is as follows.
  • a / the user Uj clicks on a hyperlink (text, icon or any other graphic representation of the object to be searched for, that is to say the FS file):
  • a request / is transmitted to the smart card 2a;
  • an "HTML” page is transmitted, by the smart card 2a, to the terminal 1 and to the browser 10;
  • the sought-after reader LS is downloaded and installed in the terminal 1; el the browser 10 again addresses the smart card 2a, request / 3, in order to obtain an instance of the audio file FS; and in response, the browser 10 receives this audio file FS, the latter being able to be read, that is to say played by the terminal 1, which now has the appropriate LS sound player. It should be noted that all the operations are transparent for the user Uj, more precisely for the browser 10, which only "knows" the smart card 2a.
  • the LS reader (or more generally another "applet") and / or the virtual object sought, that is to say the FS file in the example, if their sizes had been compatible with the storage capacity of the smart card 2a, could also have been recorded therein (re-loopings symbolized by dotted lines in Figure 14).
  • the browser 10 does not know the exact location of the virtual objects Obvj. Only the smart card 2a, more precisely the intelligent agent "ATSDA / SGFV" 7, knows the location of the virtual objects in the "SGFV" list 8 and the method for accessing them.
  • the intelligent agent "ATSDA / SGFV" 7 also knows the list of the only virtual objects accessible to a given user Uj (authorizations). It is therefore a secure system.
  • the term "secure” should be considered in its broadest sense. By way of example, it also relates to toll cards giving access to certain resources, according to a determined subscription for example, or cards ensuring secure access proper to confidential resources, depending on a level for example.
  • Obvj virtual resources or objects can be constituted by transactions.
  • a hyperlink can be used which defines the "TCP / IP" address of the first intelligent agent associated with the access method.
  • the address is of the type "@Agent: AgentPort", with "@Agent”, the actual address of the intelligent agent concerned and "AgentPort” the port of this one.
  • the "MethodPDU” list is in this case a parameter of a "URL”.
  • the virtual object Obvj is an image to be displayed on a screen ( Figure 1A: 5), of a particular format, using the browser 10 and that the latter does not have 'a program suitable for this display, generally called a viewer or “viewer” according to English terminology. It is, for example, a program executable under the operating system used on terminal 1, of type "XXX.exe”, with
  • the browser is "forced” to request the loading of an "applet”. All steps are performed automatically.
  • the user Uj is invited to click on a hyperlink or to perform a similar action.
  • the function of the intelligent agent associated with the virtual file management system can be fulfilled by a non-dedicated agent: the agent

Abstract

L'invention concerne un procédé et une architecture permettant d'accéder, de façon sécurisée, à des objets virtuels (Obv?i?) répartis dans des systèmes connectés au réseau Internet (RI), et d'en obtenir une instance. Cet accès s'effectue, via une carte à puce (2a), par l'intermédiaire d'un navigateur de type "WEB" (10). Le terminal (1) et la carte à puce (2a) comprennent chacun une couche protocolaire spécifique (13, 23a). Cette dernière comprend des agents intelligents (132, 232a1) pour l'établissement de sessions d'échanges bidirectionnels de données, ce qui permet à la carte à puce (2a) de présenter une fonctionnalité de serveur "WEB". La carte à puce (2a) comprend aussi des agents intelligents, dits traducteurs de scripts, et un système de gestion de fichier virtuel (8) coopérant avec un agent intelligent traducteur de scripts spécialisé (7). Chaque objet virtuel (Obv?i?) est associé à un fichier virtuel du système de gestion de fichier virtuel (8). L'agent intelligent spécialisé (7) présente au navigateur (10) la liste des objets virtuels accessibles (Obv?i?) et génère des méthodes d'accès à ces objets.

Description

SYSTEME D'ACCES A UN OBJET A L'AIDE D'UN NAVIGATEUR DE TYPE 'WEB" COOPERANT AVEC UNE CARTE A PUCE
L'invention concerne un système embarqué contenant des informations permettant d'instancier un objet situé sur un réseau, et un procédé pour instancier cet objet. L'invention concerne plus particulièrement encore un procédé d'accès sécurisé à cet objet.
Dans le cadre de l'invention, le terme "objet" doit être considéré dans son sens le plus général. Il englobe de nombreux types de ressources informatiques, tels que des fichiers textes, des fichiers images ou des fichiers multimédias (vidéo, son, etc.). Il englobe également des transactions ou des connexions à un système informatique, selon un protocole donné.
Dans le premier cas, on parlera ci-après d'objets statiques, car leur instance ne dépend pas du temps. Dans le second cas, on parlera d'objets dynamiques, car leur instance varie en fonction du temps. On peut citer, à titre d'exemple non limitatif, dans le cadre d'un réseau de type Internet, une connexion de type "Telnet".
Toujours dans le cadre de l'invention, le terme "station d'utilisateur" doit être compris dans un sens général. La station d'utilisateur précitée peut être notamment constituée par un ordinateur personnel fonctionnant sous divers systèmes d'exploitation, tels WINDOWS ou UNIX (tous deux étant des marques déposées). Elle peut être aussi constituée par une station de travail, un ordinateur portable ou un terminal de carte, dit dédié.
De même, dans le cadre de l'invention, le terme "réseau " englobe tout réseau comportant un ensemble de serveurs reliés entre eux, notamment un réseau planétaire dans lequel l'information est transportée de bout en bout. Il s'agit notamment du réseau Internet, de tout réseau dans lequel les échanges de données s'effectuent selon un protocole du type internet, des réseaux privés d'entreprises ou similaires, dits "intranet", et des réseaux les prolongeant vers l'extérieur, dits "extranet". Il peut notamment s'agir aussi d'un réseau GSM (de l'anglais Global System Mobile), ATM, UMTS, GPRS (de l'anglais Global Packet Radio System), d'un réseau dit « Wireless Network » comme par exemple I3E 802.11 , BLUE TOOTH. Dans ce qui suit, sans en limiter en quoi que ce soit la portée, on se placera dans le cadre de l'application préférée de l'invention, sauf mention contraire. On considérera donc une station d'utilisateur, que l'on appellera simplement "terminal", munie d'un lecteur de carte à puce et connecté à un réseau de type Internet. 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. 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 à un réseau de transmissions de données RI. Ces circuits dépendent, notamment, de la nature du réseau RI et du terminal 1. A titre d'exemple, il peut s'agir d'une carte réseau pour un réseau de type local ou d'un modem pour se connecter à une ligne téléphonique commutée ou à un réseau numérique à intégration de services ("RNIS"), pour se connecter au réseau Internet, par exemple via un prestataire de services Internet ("Internet Service Provider" ou "ISP", selon la terminologie anglo- saxonne). 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 et un clavier 6.
Le terminal 1 peut être mis en communication avec des serveurs ou tous systèmes informatiques connectés au réseau RI, dont un seul, 4, est illustré sur la figure 1A. Par « serveur », on entend tout serveur d'information apte à traiter des protocoles de communication, soit pour donner accès à des documents, soit pour donner accès à des machines. Dans le cas de l'application préférée de l'invention, les circuits d'accès 11 mettent le terminal 1 en communication avec les serveurs 4 grâce à un logiciel particulier 10, appelé navigateur de type "WEB", ou "browser" selon la terminologie anglo-saxonne. Celui-ci permet d'accéder à diverses applications réparties sur l'ensemble du réseau RI, généralement selon un mode "client-serveur". Par «navigateur », on entend tout moyen offrant les fonctions suivantes :
-visualisation d'une page, notamment d'une page au standard « SGML » (de l'anglais « Standard Generalized Markup Langage », ou langage de balisage standard généralisé) ;
-rapatriement de ressources offertes dans la page.
Cette fonction navigateur correspond à celle visée par le terme anglais
« browser ». Une page SGML contient des attributs de présentation, et des liens vers d'autres documents SGML, ou « hyper-liens » vers le monde extérieur, c'est-à-dire encore des URI (de l'anglais Unified Resource Identifier, ou Identifiant universel de ressources).
Quant au langage SGML, il comporte de façon connue en soi plusieurs dialectes, dont HTML, XML, et WML. 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 nouvelles ("news" selon la terminologie anglo-saxonne), etc.
L'architecture logique du système comprenant un terminal, un lecteur de carte à puce et la carte à puce, est représentée schématiquement par la figure 1 B. Elle est décrite par la norme ISO 7816, qui elle-même comportent plusieurs sous-ensembles : - ISO 7816-1 et 7816-2, en ce qui concerne les dimensions et 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 1B, 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 le 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 "cardlet" (marque déposée), Aj, présente dans la carte à puce 2 (figure 1A), 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. Un "APDU" de commande est noté "APDU.command' et un "APDU" de réponse est noté "APDU.response". Les "APDU" sont échangés 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 dialogue avec une seule application à la fois. Une application A se présente, par exemple, sous la forme d'une pièce de logicielle, dite "applet", en langage "JAVA" (marque déposée), que l'on appellera ci-après "cardlet". La sélection d'un "cardlet" particulier A\ est obtenu à l'aide d'un "APDU" du type sélection ("SELECT"). Une fois ce choix effectué, les "APDU" qui le suivent sont acheminés vers ce "cardlet". Un "APDU SELECT" nouveau 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'effectue 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). Dans un système d'applications à base de carte à puce, comme illustré par l'architecture de la figure 1 B, cette dernière peut se voir dévolu diverses fonctions, notamment des fonctions de sécurité. Il est en effet avantageux de stocker les données liées à la sécurité (mots de passe, droits d'accès, etc.) dans une carte à puce qui peut être conservée par l'utilisateur. En outre les données étant enregistrées dans une mémoire fixe, sous une forme qui peut être chiffrée, elles ne sont pas facilement modifiables, ni même directement lisibles de l'extérieur.
Cependant, il est à noter que la carte 3 ne peut communiquer directement avec les navigateurs du commerce, sauf à modifier le code de ces derniers. Les cartes à puce actuelles, qui par ailleurs sont conformes aux standards 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 l'interface entre le navigateur 10 et la carte 2, plus précisément les circuits électroniques 20 de cette carte 2. Dans l'état actuel de la technique, le système hôte associé au lecteur de carte 3, c'est-à-dire le terminal 1 , est associé également à une application particulière. En d'autres termes, il est nécessaire de prévoir un terminal spécifique, dit "dédié", pour chaque application particulière. En outre, il est clair que, même compte tenu de la rapide évolution passée des technologies et de leur évolution future prévisible, la capacité d'enregistrement d'informations dans des circuits de mémoire, vive ou fixe, d'une carte à puce reste et restera très limitée, si on compare cette capacité à celle offerte par un terminal "hôte" de cette carte à puce, et naturellement à celles offertes par des systèmes plus importants, "mini-ordinateurs" ou grands systèmes de type dit "main frame". Aussi, il n'est pas possible de stocker les données d'un nombre important d'applications dans une carte à puce, et notamment des fichiers de type multimédia très volumineux.
L'invention vise à pallier les inconvénients des dispositifs de l'art connu et dont certains viennent d'être rappelés, tout en répondant aux besoins qui se font sentir. Il doit notamment être possible d'accéder à un grand nombre d'applications, même volumineuses d'un point de vue quantité de données, de natures diverses et réparties sur tout le réseau Internet. En outre, dans un mode de réalisation préféré, les accès doivent bénéficier d'une sécurité maximale, c'est-à-dire dans la pratique s'effectuer via et sous le contrôle d'une carte à puce contenant toutes les données nécessaires à la sécurisation des échanges de données. Enfin, ces accès doivent pouvoir s'effectuer à partir d'un navigateur du commerce et être transparents pour un utilisateur, qui ne doit
"voir" que la carte à puce comme unique interlocuteur, quel que soit le lieu de stockage de l'application.
Selon une première caractéristique du procédé, la carte à puce présente au système hôte, c'est-à-dire le terminal, un modèle de terminal virtuel, par exemple sous la forme d'une page en langage "HTML" (pour "HyperText Markup Language"), ou plus généralement en langage hypertexte, ou encore sous la forme d'un "applet", en langage "JAVA" (marque déposée), ce qui permet à l'utilisateur de choisir une application particulière parmi celles disponibles et proposées par la carte à puce. De ce fait, le terminal se trouve donc banalisé et supporte une pluralité d'applications. Le système hôte est vu comme un périphérique de la carte à puce, et il met à sa disposition des ressources matérielles, tels un écran de visualisation, un clavier, etc.
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. Elles n'interviennent que dans le processus d'échange de données bidirectionnel entre la carte à puce et le terminal, d'une part, et la carte à puce et le réseau.
Les couches logicielles de communication spécifiques comprennent notamment des composants logiciels, dits "agents intelligents", permettant en particulier des conversions de protocoles. Il existe des agents intelligents 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 intelligents appareillés. Selon une deuxième caractéristique, 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 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". Cette caractéristique technique permet d'implanter dans une carte à puce, dont l'architecture est conforme au procédé de l'invention, un mécanisme similaire à la fonction dite "CGI" (pour "Common Gateway Interface") implantée dans les serveurs "WEB" classique.
Enfin, selon une autre caractéristique du procédé de l'invention, en mettant en œuvre les fonctions et mécanismes précités, celui-ci permet d'accéder à des ressources informatiques réparties sur un réseau de transmission de données auquel est connecté le terminal, notamment le réseau Internet ou un réseau de type équivalent (intranet, extranet), sans que l'utilisateur ait à se soucier de leurs emplacements. Dans ce qui suit, comme il a été indiqué, ces ressources seront appelées "objets virtuels", statiques ou dynamiques. Pour ce faire, il est mis en œuvre un agent intelligent traducteur de script dédié à cette tâche, coopérant avec les autres agents intelligents présents dans le terminal et/ou la carte à puce. Cet agent permet de définir les objets virtuels auxquels la carte à puce peut accéder, et de ce fait également l'utilisateur (ou porteur de la carte à puce), d'une part, et fournit au navigateur interrogateur, via la carte à puce, des méthodes permettant d'accéder à ces objets virtuels d'autre part.
L'invention concerne donc un système embarqué, équipé d'une puce comprenant des moyens de traitement d'information et des moyens de mémorisation d'information, et destiné à coopérer avec un réseau au travers d'un terminal, caractérisé en ce que : -il stocke au moins un fichier d'objet contenant des informations associées à un objet situé sur le réseau et permettant de réaliser une instance de cet objet ;
-il comprend des moyens d'interface de réseau, agencés pour coopérer avec des moyens d'interface de réseau appariés, situés dans le terminal, de façon que le système embarqué constitue un serveur d'information sur le réseau ; et
-il comprend des moyens d'interface de fichier d'objet, agencés pour établir une correspondance entre des informations transitant par les moyens d'interface de réseau et affectées à au moins ledit fichier d'objet, et des informations échangées avec ledit fichier d'objet.
Avantageusement, le fichier d'objet comprend une pièce de logiciel autonome exécutable sur un logiciel de navigation. Avantageusement, cette pièce de logiciel autonome est capable de mettre en œuvre un système de gestion de fichier d'objet du système embarqué.
Avantageusement, ledit fichier d'objet comprend une description d'actions à réaliser pour instancier un objet. Avantageusement, les actions comprennent des actions réalisées à l'intérieur du système embarqué et consistant en des sessions entre agents du système embarqué.
Avantageusement, les actions comprennent des actions réalisées à l'extérieur du système embarqué et consistant en des sessions avec des agents du terminal en vue d'obtenir des informations à partir de serveurs d'information du réseau.
Avantageusement, lesdits moyens d'interface de réseau sont agencés pour coopérer avec les moyens d'interface de réseau appariés, situés dans le terminal, de façon que le système embarqué se comporte comme un client capable de se connecter à au moins un serveur du réseau. L'invention concerne aussi un procédé pour instancier un objet situé sur un réseau, et utilisant le système embarqué précité, caractérisé en ce qu'il permet de décrire un ensemble de sessions entre agents par un fichier d'objet, au moyen d'au moins les étapes suivantes :
-établir une liste des agents mis en œuvre ;
-pour chaque agent, définir des arguments d'appel, nécessaires à l'agent.
Avantageusement, un argument d'appel décrit l'ouverture d'une session avec un autre agent.
Avantageusement, un agent modifie la liste des arguments utilisés par un autre agent.
En variante, le procédé est caractérisé en ce qu'il met en œuvre des sessions entre agents décrites par un fichier d'objet exécuté depuis le serveur d'information du système embarqué au moyen d'au moins les étapes suivantes :
-identification d'un fichier d'objet ;
-exécution de ce fichier d'objet.
Avantageusement, l'identification est effectuée par un nom de répertoire particulier.
Avantageusement, l'identification est effectuée par un attribut de fichier particulier.
Avantageusement, l'identification est effectuée par une convention de nommage particulière.
Avantageusement, l'exécution est effectuée par instanciation du premier agent associé au fichier objet. Avantageusement, l'exécution est effectuée par instanciation d'un ou plusieurs agents référencés par le fichier objet.
En variante, le procédé est caractérisé en ce qu'il met en œuvre des sessions entre agents décrites par un fichier d'objet exécuté depuis un logiciel de navigation au moyen d'au moins les étapes suivantes :
-chargement par le logiciel de navigation d'un fichier d'objet et d'un logiciel spécifique capable de le mettre en œuvre ;
-exécution du logiciel spécifique par le logiciel de navigation.
Avantageusement, la réalisation du logiciel spécifique est effectuée au moyen de tout langage interprété, exécutable par le logiciel de navigation.
Avantageusement, l'interpréteur de fichier objet est réalisé sur un logiciel de navigation.
En variante, le procédé est caractérisé en ce qu'il permet au système embarqué de rendre possible la mise en œuvre de sessions entre agents décrites par un fichier d'objet exécuté depuis un logiciel de navigation, et en ce qu'il comprend l'étape consistant à identifier, au moyen d'un identificateur universel de ressource, un logiciel spécifique agencé pour mettre en œuvre le logiciel de navigation.
Avantageusement, l'identificateur universel de ressource est intégré à un document hyper-texte.
Avantageusement, ledit document hyper-texte est contenu dans le système embarqué.
Avantageusement, ledit document hyper-texte est contenu sur un serveur d'information du réseau, distant du système embarqué. Avantageusement, ledit logiciel spécifique est chargé par une méthode disponible sur le logiciel de navigation et déduite de l'identificateur universel de ressource.
L'invention concerne aussi un système embarqué, équipé d'une puce comprenant des moyens de traitement d'information et des moyens de mémorisation d'information, et destiné à coopérer avec un réseau au travers d'un terminal, caractérisé en ce qu'il comprend des moyens d'interface de réseau, agencés pour coopérer avec des moyens d'interface de réseau appariés, situés dans le terminal, de façon que le système embarqué constitue un serveur d'information sur le réseau et/ou se comporte comme un client capable de se connecter à au moins un serveur du réseau. L'invention concerne aussi un terminal destiné à coopérer avec un réseau et comprenant des moyens de traitement d'information, des moyens de mémorisation d'information, et des moyens de coopération avec un système embarqué, équipé d'une puce comprenant des moyens de traitement d'information et des moyens de mémorisation d'information, caractérisé en ce qu'il comprend des moyens d'interface de réseau, agencés pour coopérer avec des moyens d'interface de réseau appariés, situés dans le système embarqué de façon que le système embarqué constitue un serveur d'information sur le réseau et/ou se comporte comme un client capable de se connecter à au moins un serveur du réseau. Avantageusement, le terminal acquiert dynamiquement lesdits moyens d'interface de réseau par un mécanisme de chargement de logiciel depuis le réseau. Il peut s'agir notamment d'un mécanisme de « plug-in », selon la terminologie anglo-saxonne. Si le terminal ne connaît pas l'extension du fichier contenant ledit logiciel, il va chercher sur un serveur le logiciel associé à cette extension, appelé usuellement « helper » selon la terminologie anglo-saxonne. Avantageusement, lesdits moyens d'interface de réseau appariés constituent, dans le terminal et dans le système embarqué, une pile comprenant une ou plusieurs couches de communication telles qu'elles permettent au système embarqué de partager tout ou partie des couches de communication du terminal. Par ailleurs, le terminal dispose avantageusement de points d'accès sur ses couches de communication, qui lui permettent de dériver un flux d'information depuis ou vers une ou plusieurs de ces couches. Ces points d'accès correspondent aux points connus en soi sous le nom « SAP » défini par la norme ISO (Service Accès Point, selon la terminologie anglo-saxonne).
L'invention concerne aussi un système embarqué, équipé d'une puce comprenant des moyens de traitement d'information et des moyens de mémorisation d'information, et destiné à coopérer avec un réseau au travers d'un terminal, caractérisé en ce qu'il comprend des moyens d'interface de réseau, agencés pour coopérer avec des moyens d'interface de réseau appariés, situés dans le terminal, de façon qu'au moins une partie d'un flux d'information échangé entre une application du terminal et le réseau traverse les moyens d'interface de réseau du système embarqué, en fonction de critères connus du terminal. L'invention concerne aussi un terminal destiné à coopérer avec un réseau et comprenant des moyens de traitement d'information, des moyens de mémorisation d'information, et des moyens de coopération avec un système embarqué, équipé d'une puce comprenant des moyens de traitement d'information et des moyens de mémorisation d'information, caractérisé en ce qu'il comprend des moyens d'interface de réseau, agencés pour coopérer avec des moyens d'interface de réseau appariés, situés dans le système embarqué de façon qu'au moins une partie d'un flux d'information échangé entre une application du terminal et le réseau traverse les moyens d'interface de réseau du système embarqué, en fonction de critères connus du terminal. La dérivation d'une partie du flux d'information vers le système embarqué est avantageusement effectuée par les moyens de traitement d'information du terminal en fonction de critères pré-établis soit de manière statique, soit de manière négociée par un dialogue avec le système embarqué ; dans ce dernier cas, le terminal peut par exemple demander au système embarqué son adresse « IP » (s'il s'agit du réseau Internet), par des protocoles connus. Avantageusement, les critères précités comprennent l'un des suivants :
-l'adresse « IP » du système embarqué, ou son adresse « ATM » dans le cas d'un réseau ATM ;
-l'adresse IP du terminal et un port « TCP » ou « UDP » particulier ;
-tout point d'accès SAP qui référencie le système embarqué.
L'invention va maintenant être décrite de façon plus détaillée en se référant aux dessins annexés, parmi lesquels : les figures 1A et 1 B illustrent schématiquement les architectures matérielles et logiques, respectivement, d'un exemple de système d'application à base de carte à puce 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 serveur "WEB" ; la figure 3 illustre de façon simplifiée l'architecture logique d'un système dans lequel la carte à puce comprend des agents intelligents ; - la figure 4 illustre une architecture de système conforme à l'invention, dans laquelle la carte à puce comprend des agents intelligents traducteurs de scripts ; la figure 5 est un diagramme illustrant schématiquement les principales phase d'échanges entre un navigateur et une carte à puce présentant l'architecture de la figure 4 ; la figure 6 est un diagramme illustrant schématiquement un aspect essentiel du procédé selon l'invention par lequel il est possible d'accéder à des objets virtuels répartis sur un réseau de type Internet via une carte à puce et un navigateur de type "WEB" ; - la figure 7 illustre schématiquement l'organisation d'un système de gestion de fichiers dit virtuel pour la mise en œuvre de cet aspect du procédé de l'invention ; la figure 8 est un exemple d'architecture comprenant un système de gestion de fichier virtuel selon la figure 7 ; - les figures 9 à 15 sont des diagrammes illustrant schématiquement plusieurs mode de réalisation du procédé selon l'invention. Avant de décrire le procédé d'activation d'applications localisées dans une carte à puce selon l'invention et de détailler une architecture pour sa mise en œuvre, 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 P "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, l'une ou l'autre de ces couches peut être inexistante.
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 d'application ("http", "ftp", "e-mail", etc.), la couche de transport ("TCP"), la couche d'adressage de réseau ("IP"), la couche de liens de données ("PPP", "Slip", etc.) et la couche physique. Ces rappels étant effectués, on va maintenant décrire une architecture de système d'application à base de carte à puce autorisant celle-ci à agir comme un serveur "WEB". Un exemple d'une telle architecture est représenté schématiquement sur la figure 2. Les éléments communs aux figures 1A et 1 B portent les mêmes références et ne seront re-déchts qu'en tant que de besoin. Pour simplifier le dessin, on n'a pas représenté les divers périphériques connectés au terminal (figure 1A : écran 5 et clavier 6, par exemple). 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 à Part connu.
Le terminal 1 comprend des circuits 11 d'accès au réseau RI, constitués par exemple d'un modem pour le réseau Internet ou d'une carte réseau pour un réseau local. Ces circuits regroupent les couches logicielles inférieures Ci et C2, correspondant aux couches "physique" et de "lien de données". On a également représenté les couches supérieures C3 et C4, correspondant 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 (figure 1 A) de poser des requêtes vers un serveur 4 (figure 1A), 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.
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 englobe également deux couches basses, CC1 (couche physique) et CC2 (couche de lien de données), jouant un rôle similaire aux couches C 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, CC-| et CC2- La fonction principale dévolue à cette couche 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 une première caractéristique, 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 des paquets réseaux de et vers la carte à puce 2a. En outre, elle adapte les applications existantes telles le navigateur
Internet 10 (figure 2), 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. 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" ("Dafa.reg_;esf") 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 2 (couche de liens de données). Ce protocole particulier de communication permet de mettre en communication au moins une paire d' "agents intelligents". 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 intelligents" est associée à une session. Une session est un échange de données bidirectionnel entre ces deux agents.
Un agent intelligent 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. Un agent intelligent particulier est identifié avantageusement par un nombre entier, par exemple sur 16 bits (nombre compris entre 0 et 65535). Cet identificateur est utilisé, par exemple, dans une unité de donnée de protocole constituant une référence de destination et une référence de source.
Il existe deux grandes catégories d'agents intelligents : 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, délivrée par le module de gestion de configuration, 131 ou 231a.
Le processus d'ouverture d'une session est habituellement le suivant : un agent intelligent de type "client" ouvre la session vers un agent intelligent de type "serveur". Les couches 130 et 230a gèrent des tables (non représentées) qui contiennent la liste des agents intelligents présents, côté terminal hôte 1 et carte à puce 2a. Les agents intelligents 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 intelligents : "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 ; "client" : agent qui initialise une session ; "serveur" : agent qui reçoit une demande de session. Les agents intelligents permettent d'échanger des données (de l'hypertexte par exemple), mais également de déclencher des transactions réseau. Les modules de gestion de configuration, 131 et 231a, respectivement, sont assimilables, comme il a été indiqué, à des agents intelligents particuliers. Par exemple, le module 131 , côté terminal hôte l , gère notamment des informations relatives à la configuration de ce terminal (modes de fonctionnement), liste des autres agents intelligents présents, etc. Le module 231a, côté carte à puce 2a, a des fonctions analogues. Ces deux agents intelligents peuvent être mis en communication l'un avec l'autre pour établir une session. Selon une caractéristique, la carte à puce 2a propose au système hôte, c'est- à-dire au terminal 1 , un modèle de terminal virtuel. Pour ce faire, la carte à puce 2a se comporte comme un serveur "WEB".
La carte à puce 2a est "adressée" par le navigateur 10. Elle lui transmet alors une page de type "WEB" en langage "HTML", un "applet" ou toute autre pièce de logiciel. A titre d'exemple, la page "WEB" peut se présenter sous la forme d'une page d'accueil donnant un choix d'applications possibles et/ou d'hyperliens vers des serveurs extérieurs.
De façon pratique, la carte à puce 2a est avantageusement "adressée" par utilisation d'une adresse "URL" (pour "Universal Resource 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 lequelle 127.0.0.1 est l'adresse "IP" de rebouclage et 8080 est le numéro de port.
La figure 3 illustre de façon simplifiée l'architecture logique d'un système dont la carte à puce 2a comprend des agents intelligents, dont deux seulement ont été représentés : un agent intelligent de type non précisément défini 232a2 et un agent intelligent 232aι , 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 intelligents, notamment l'agent intelligent "WEB" 232a-| .
Du côté terminal, il existe deux piles, l'une communiquant avec le réseau Internet RI, l'autre avec la carte à puce 2a. La première pile comprend les organes 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 : Ci et C2)> le gestionnaire 102 d'ordres "APDU" et le multiplexeur de paquets 130, ce dernier étant interface avec des agents intelligents, 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" 100, d'autre part avec le réseau Internet RI, via ces mêmes couches "TCP/IP" 100 et l'organe 11 , d'accès au réseau RI.
Le gestionnaire d'ordres "APDU" 201 a est également interface avec une ou plusieurs couches de niveau applications, que l'on appellera simplement applications. Ces applications sont, comme il a été indiqué, des applications de type conventionnel, que l'on a appelé "cardlet". En résumé, la fonction "serveur WEB", fournie par la carte à puce 2a, peut être réalisée par l'association de l'agent intelligent "WEB" 232aι dans la carte à puce et de l'agent réseau 132 dans le terminal 1. La carte à puce 2a présente donc bien la fonctionnalité serveur "WEB". En outre, selon une caractéristique du procédé de l'invention, n'importe quelle application conventionnelle, Ai à An, du type "CGA" précité, peut être activée au travers de ce serveur "WEB", soit par le navigateur "WEB" 10 présent dans le terminal 1 , soit par un navigateur éloigné, localisé en un point quelconque du réseau Internet RI. Selon le procédé de l'invention, les applications, A-\ à An, ne nécessitent pas d'être ré-écrites et sont mises en œuvre telles quelles.
Selon une autre caractéristique de l'invention, ces applications restent accessibles à un terminal de type conventionnel, c'est-à-dire conforme à Part connu.
Pour répondre à ces exigences, la fonction serveur "WEB", offerte par la carte à puce 2a, inclut un mécanisme similaire à la fonction dite "CGI" (pour "Common Gateway Interface") implantée dans les serveurs "WEB" classiques. 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" 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 "HTML". Le langage "HTML" 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 "HTML" 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é 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 2a, par référence à la figure 4.
Lors d'une première étape, un utilisateur (non représenté) invoque depuis son navigateur "WEB" (figure 3 :10) une "URL" qui peut se présenter de la façon suivante : "http://@carte:8080/xxx.html" (3), dans laquelle "@carte" est une adresse IP de la carte à puce (par exemple l'adresse de rebouclage "127.0.01" précédemment décrite : voir formule (1)), et "xxx.html" est une page en langage "HTML" relative à une application particulière "xxx" offerte par la carte à puce. Lors d'une deuxième étape, de la manière décrite précédemment, la carte à puce renvoie une page "HTML", par exemple de type formulaire. Lors d'une troisième étape l'utilisateur renseigne les champs du formulaire et en transmet le contenu à la carte à puce, habituellement en cliquant sur un champ particulier, de type "bouton poussoir". Les données sont alors émises et reçues par l'agent réseau 132. Les données traversent alors le multiplexeur de paquets 130 (qui constitue l'un des composants de la couche spécifique 13, côté terminal 1), le gestionnaire d'ordres "APDU" 102, les couches protocolaires 101 , pour être transmises à la carte à puce 2a. Elles traversent ensuite les couches protocolaires 200a, le gestionnaire d'ordres "APDU" 201a, le multiplexeur de paquets 230a pour être reçues par l'agent "WEB" 232a-| . Il s'établit donc une session logique entre les deux agents intelligents, comme explicité précédemment.
Il convient de remarquer que les données adressées à l'agent "WEB" 232aι sont transportées, de façon conventionnelle en soi, sous formes d'ordres "APDU" destinés à l'application particulière "Multiplexeur de paquets". Le gestionnaire d'ordres "APDU" 201a sélectionne cette application de manière tout à fait similaire aux autres applications de type "CGA" présentes dans la carte à puce 2a, référencées A à An- En d'autres termes, le multiplexeur de paquets 230a est vu par le gestionnaire d'ordres "APDU" 201a comme une application "CGA" ordinaire.
La requête "HTTP" est analysée par l'agent "WEB" 232aι qui détecte une référence à un répertoire particulier, que l'on appellera ci-après par convention "cgi-smart", d'une part, et à une application particulière, par exemple "xxx" dans le cas de l'exemple décrit, d'autre part. Le chemin complet est donc, en l'occurrence "cgi-smart/xxx". Selon une caractéristique du procédé de l'invention, l'entité ci-dessus désigne un script particulier associé à une application également particulière "xxx".
Lors d'une quatrième étape, le script est interprété par un agent intelligent dit
"Agent traducteur de script", que l'on appellera "ATS" ci-après. 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 traducteur de script unique capable de traduire l'ensemble des scripts présents dans la carte à puce 2a ; cl par un agent de script dédié que l'on appellera "ATSD" ci-après (un par script) ; ou d/ par un agent "APDU" 2010a du gestionnaire d'ordres "APDU" 201a, 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, comme il a été indiqué, 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 du procédé, de communiquer avec tous les agents intelligents du système (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 4 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 être l'application Aj, 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 ATS\, et l'agent "APDU" 2010a. Les ordres sont alors émis vers l'agent "APDU" 2010a. Le gestionnaire d'ordres "APDU" 201a sélectionne l'application "CGA" Aj (par exemple l'application "PME") 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 "CGA" Aj sont transmises au gestionnaire d'ordres "APDU" 201a, à l'agent "APDU" 2010a, puis de nouveau à l'agent ATSj (et de façon plus générale à l'agent traducteur de script).
En fonction de la réussite ou de l'échec du déroulement du script, l'agent traducteur de script, par exemple l'agent ATSj dans l'exemple de la figure 4, élabore une page en langage "HTML" et la transmet via les différentes couches empruntées par la requête initiale, mais en sens inverse, ce pour être présentée sur l'écran de visualisation 5 (figure 1A).
Les différents cheminements sont représentés symboliquement sur la figure 4 par des traits pleins reliant les blocs fonctionnels ou en pointillés à l'intérieur de ces blocs.
La figure 5 résume de façon schématique les principales étapes du processus qui vient d'être décrit : a/ transmission via le réseau Internet RI (ou à partir du terminal local : dans les deux cas à l'aide d'un navigateur conventionnel 10) d'une requête "HTTP", référencée RQ ; b/ réponse du serveur "WEB" de la carte à puce 2a, sous la forme d'un formulaire, référencé FO ; c/ transmission du formulaire rempli, sous la forme d'une nouvelle requête RQ ; et d/ réponse sous la forme d'une page "HTML", référencée PR.
La réponse pourrait d'ailleurs consister en la transmission d'un fichier, ou d'une pièce de logiciel ou "Applet".
En mettant en œuvre les mécanismes et fonctions qui viennent d'être décrits, notamment la fonction serveur "WEB" et le recours à des agents intelligents traducteurs de scripts, selon une caractéristique essentielle, le procédé selon l'invention va permettre de définir un environnement virtuel, avantageusement sécurisé par la carte à puce. Dans un mode de réalisation préféré, cet environnement est compatible avec les applications de type dit multimédia. Cette dernière caractéristique est particulièrement avantageuse car les navigateurs "WEB" récents, mais de type tout à fait classique en soi, permettent, par nature, de construire des environnements multimédias (images animées, sons, etc.). Ils sont en effet associés à des outils logiciels, intégrés ou non, permettant de manipuler des fichiers multimédia (visionneuse, etc.). En tout état de cause, les navigateurs permettent de télécharger des fichiers de données multimédias, habituellement volumineux et de les stocker sur un disque dur, par exemple dans le terminal, ou sur un organe de stockage de masse similaire. On a notamment proposé des technologies permettant l'affichage en temps réel ou quasi-réel de séquences vidéos ou la reproduction de son, à partir de sites "WEB" du réseau Internet. Cependant, une carte à puce, comme il a été rappelé, ne présente qu'une faible capacité de mémoire. En outre, elle n'autorise qu'un très faible débit de données lors des échanges. Il n'est donc pas possible d'enregistrer un grand nombre de fichiers de données dans celle-ci. Il n'est pas non plus envisageable, de façon pratique, de stocker des fichiers multimédias, à l'exception de très courtes séquences ou de séquences sonores codées sous un format particulier, tel que le codage "MIDI".
En dehors de ces limitations d'ordre technologique, il est aussi souhaitable de pouvoir avoir accès à des applications éloignées, tout en bénéficiant d'une sécurisation de haut niveau, que seule la mise en œuvre d'une carte à puce est apte à offrir. Le procédé selon l'invention permet ce mode de fonctionnement. L'environnement virtuel multimédia sécurisé par carte à puce, selon un mode de réalisation préféré, permet de : définir des objets virtuels auxquels la carte à puce peut accéder ; fournir des méthodes d'accès à ces objets. La figure 6 illustre schématiquement cet aspect essentiel du procédé selon l'invention. Un utilisateur Uj interroge la carte à puce 2a grâce au navigateur "WEB" 10 compris dans le terminal 1. Selon un mécanisme qui va être précisé ci-après, grâce notamment à la fonction "serveur WEB" précédemment décrite, la carte à puce 2a va renvoyer au navigateur une liste d'objets dits virtuels Obvj, i étant un indice arbitraire, auquel il a accès, c'est-à-dire de façon pratique pour lesquels la carte à puce 2a ou l'utilisateur Uj possède des droits d'accès. En effet, ces droits d'accès peuvent être liés strictement à la carte à puce 2a et immuables. Ils peuvent également être liés à un profil utilisateur, l'utilisateur Uj fournissant, par exemple, des données d'identification et un mot de passe. La carte à puce 2a effectue une vérification par comparaison avec des données d'une base de données de sécurité enregistrées dans une mémoire fixe et, si le résultat de la comparaison est positif, fournit une liste d'objets virtuels Obvj associée au couple : "données d'identification - mot de passe". De façon connue en soi, cette première phase peut mettre en œuvre un procédé de chiffrage des données échangées entre le terminal et la carte à puce 2a ou mettre en œuvre un protocole de transmission sécurisé "HTTPS". La carte à puce 2a va également fournir une liste de méthodes d'accès aux objets virtuels Obvj. Les objets virtuels Obvj, qui sont de type statique ou dynamique comme indiqué précédemment, peuvent être localisés indifféremment dans la carte à puce 2a, ou dans le terminal 1 , ou, de façon plus générale, dans un système quelconque connecté au réseau Internet RI. Selon une caractéristique de l'invention, cet emplacement est "transparent" pour le navigateur 10, et donc pour l'utilisateur Uj, comme il va l'être montré. Le procédé selon l'invention fait appel notamment à ce qui va être appelé ci- après un système de gestion de fichier virtuel, ou "SGFV", et un agent intelligent traducteur de script spécialisé, que l'on appellera "ATSDA/SGVF", dédié à cette tâche. Cet agent intelligent fournit la liste des objets virtuels Obvj auxquels la carte à puce 2a peut accéder. Une adresse "URL" particulière est associée à chaque objet virtuel Obvj. L'invocation de cette "URL" depuis le navigateur "WEB" 10 permet d'instancier l'objet virtuel Obvj, au moyen d'une méthode d'appel déterminée, spécifique ou non à cet objet. On va tout d'abord rappeler brièvement les principales caractéristiques d'un système de gestion de fichiers classique, appelé ci-après "SGF". Un tel système est utilisé pour stocker de l'information sur un support tel qu'un disque dur. L'information est mémorisée sous la forme d'un fichier. Un fichier, que ce soit des données pures ou des instructions de programme, est composé classiquement d'une suite de blocs de taille fixe. Un mécanisme bien connu permet d'obtenir la liste des blocs de mémoire qui constitue le fichier et leurs adresses dans la mémoire.
Un répertoire est un fichier particulier dont le contenu est une liste de descripteurs de fichier. Un tel descripteur comprend par exemple les éléments suivants : le nom du fichier ; - la longueur du fichier ; la date de création ; une référence permettant de retrouver la liste des blocs du fichier (numéro du premier bloc, tableau des numéros de blocs, etc.) ; et et des attributs qui spécifient des propriétés particulières du fichier (répertoire, lecture, écriture, exécution, etc.).
Le premier répertoire est habituellement appelé répertoire racine. Un répertoire qui n'est pas racine est dit sous-répertoire. Le répertoire qui contient le descripteur d'un fichier donné est son répertoire père. L'adresse d'un fichier dans le "SGF" est donc une succession de noms de répertoires, depuis le répertoire racine jusqu'au répertoire père du fichier, ce qui définit un chemin. A titre d'exemple, un tel chemin se présente comme suit :
"/racine/répertoire1/répertoire2/nom_du_fichier" (4), les chiffres 1 et 2 étant arbitraires, "racine" étant le nom du répertoire racine et "nom_de_fichier" un nom quelconque de fichier. Pour une carte à puce, la norme ISO 7816-4 définit le répertoire racine dit "MF" (pour "Master File" ou fichier maître), des sous-répertoires dits "DF" (pour "Dedicated Files" ou fichiers dédiés) et des fichiers élémentaires dits "EF" (pour
"Elementary Files).
Dans le cadre de l'invention, le système de gestion de fichiers "SGFV", que l'on appellera virtuel, permet de définir des objets virtuels Obvj auxquels la carte à puce 2a peut avoir accès. Selon le procédé de l'invention, un objet virtuel Obvj est associé à un fichier élémentaire virtuel. Le contenu d'un fichier élémentaire virtuel est constitué par l'ensemble des informations qui permettent d'accéder à l'objet virtuel associé Obvj et d'en obtenir une instance dans le terminal 1.
De façon pratique, comme illustré schématiquement par la figure 7, le système "SGFV" peut constituer un sous-ensemble d'un système "SGF" classique, et, de façon plus précise, un "SGFV" est logé à l'intérieur d'un fichier élémentaire, tel que définit par la norme ISO 7816-4 précitée.
Un descripteur de fichier comportera généralement les éléments suivants : le nom du fichier ; - la longueur du fichier ; la date de création ; une référence (avantageusement un nombre entier) qui permet de retrouver la liste des blocs du fichier (numéro du premier bloc, tableau de numéros de blocs, etc.) : un fichier virtuel est identifié par son nom ou cette référence unique ; et des attributs du fichier qui spécifient les références particulières du fichier
: répertoire ou fichier élémentaire, virtuel ou non virtuel, direct ou indirect.
On appelle "objet virtuel direct", un objet qui est instancié depuis la carte à puce 2a. Il s'agit typiquement d'un objet virtuel Obvj statique qui peut être manipulé par le navigateur, par exemple affiché (image, etc.). On appelle " objet virtuel indirect", un objet virtuel Obvj qui est instancié depuis le navigateur
10, typiquement à l'aide d'un "applet".
La figure 8 illustre schématiquement l'architecture d'un système à carte à puce permettant d'instancier un objet virtuel Obvj localisé à un endroit quelconque du réseau Internet RI, via le navigateur 10 et la carte à puce 2a. Les éléments communs aux figures précédentes portent les mêmes références et ne seront re-décrits qu'en tant que de besoin.
L'architecture illustrée sur la figure 8 est très similaire à celle de la figure 4. La différence essentielle est constituée par le fait que l'on a prévu un "SGFV" 8, stocké dans la carte à puce 2a, et un agent intelligent traducteur de script spécifique "ATSDA/SGFV", référencé 7. Le mode de fonctionnement est similaire à celui illustré par la figure 4 lorsque l'on désire accéder à une application particulière Aj. Il est donc inutile de le re-décrire en détail. Dans le cas présent l'application particulière est remplacée par le système de gestion de fichier virtuel "SGFV" 8. On établit tout d'abord une session entre l'agent intelligent réseau 132 et l'agent intelligent "WEB" 232a-| . Selon le mécanisme précédemment explicité, il s'établit ensuite une session entre l'agent "WEB" 232aι et l'agent intelligent "ATSDA/SGFV" 7.
De façon pratique, l'agent intelligent "ATSDA/SGFV" 7 est accessible par des "URL", typiquement du type :
"http://www.host.com/cgi-smart/sgfv?" (5), dans lesquelles "sgfv" est une application de type "CGI" associée à l'agent intelligent "ATSDA/SGFV" 7. La requête ci-dessus permet de parcourir l'arbre des répertoires et de "montrer" leur contenu au navigateur 10, au moyen d'une page "HTML". Les "feuilles "de l'arbre sont des fichiers élémentaires, virtuels ou non virtuels, associés à un hyperlien. La transmission dans le sens "carte à puce 2a - terminal 1" est réalisée de la manière qui a été explicitée en regard de la figure 4. En d'autres termes, l'agent intelligent "ATSDA/SGFV" 7 associe à tout élément du "SGFV" 8, répertoire ou fichier élémentaire, une adresse "URL". L'adresse
"URL" d'un répertoire désigne une page "HTML" qui contient la liste de ses éléments. L'adresse "URL" d'un fichier élémentaire permet de créer une instance de l'objet virtuel Obvj associé à ce fichier virtuel.
Pour fixer les idées, si on utilise l'adresse "URL" (5) ci-dessus, on obtient une page "HTML" qui présente le contenu du répertoire racine au navigateur 10. Ce répertoire racine est constitué par un ensemble de sous-répertoires et de fichiers comme illustré schématiquement par la figure 9. Sur cette figure, on a représenté un répertoire racine rep#0, au niveau supérieur, un fichier élémentaire réel fe#7 et un sous-répertoire réel srep#1 , au niveau immédiatement inférieur, et un sous-répertoire virtuel rep#2 et un fichier élémentaire virtuel fe#5, au niveau le plus bas, tous deux dépendants du sous- répertoire réel , les numéros de référence étant purement arbitraires .
Lors d'une première phase, l'agent intelligent "ATSDA/SGFV" 7 transmet au navigateur 10, en réponse à la requête reçue, une page "HTML" (non représentée) montrant, sous une forme ou une autre, la structure hiérarchique du "SGFV" 8. La page est habituellement affichée sur un écran de visualisation (figure 1A : 5), par exemple sous la forme d'un menu. Chaque ligne du menu est constituée d'un hyperlien décrivant un sous-répertoire ou un fichier élémentaire. L'affichage peut être avantageusement sous forme graphique, associée ou non à un texte descriptif, le dessin de l'arbre de la figure 9 étant affiché sur l'écran précité. On peut encore afficher des icônes ou des formes complexes (par exemple en 3 dimensions), chacune étant associée à l'un des objets virtuels à instancier, et pouvant être représentative de leur nature (à titre d'exemple, une caméra représentant un fichier vidéo), associée ou non à un texte descriptif.
L'utilisateur Uj est invité à cliquer sur un hyperlien (sur un nœud ou sur une branche dans le cas d'un graphique). Par cette action, il va pouvoir obtenir une instance de l'objet virtuel Obvj désiré. Le système "SGFV" 8 est avantageusement enregistré dans une mémoire de type re-programmable comprise dans la carte à puce 2a, par exemple du type "EEPROM" (mémoire effaçable électriquement), comme illustré schématiquement sur la figure 10. Le "SGFV" 8 reproduit la structure de l'arbre de la figure 9.
Toujours dans l'exemple décrit, une fois obtenu la page de menu, obtenue lors d'une phase initiale, en cliquant sur une "URL" qui pourrait être typiquement la suivante : "http://www.host.com/cgi-smart/sgvf ?/file#5 (6), l'utilisateur Uj obtient une instance de l'objet virtuel Obv$ associé au fichier élémentaire référencé fe#5 sur la figure 10. De même, il aurait pu obtenir le contenu d'un sous-répertoire, le paramètre "file#5" étant remplacé par "file#x" dans (6), #x étant le numéro associé au sous-répertoire.
Les fichiers non virtuels sont enregistrés dans la carte à puce 2a et sont conformes au paradigme usuel qui gouverne les "SGF". Ils contiennent des données, telles que par exemple des clés, données utiles à l'agent intelligent "ATSDA/SGFV" 7. Différentes conventions sont possibles quant à la définition des informations nécessaires à l'instanciation d'un objet virtuel Obvj, et par exemple
un fichier virtuel de longueur nulle hérite des méthodes d'accès de son répertoire père ; - un répertoire virtuel est associé à un fichier élémentaire virtuel dont le nom est imposé (par exemple "virtual"), et qui contient les méthodes d'accès de ce répertoire.
En effet, outre la liste des objets virtuels accessibles Obvj, un agent intelligent "ATSDA/SGFV" 7 doit également fournir une méthode d'accès à un objet virtuel donné Obvj, ce à partir de tout ou partie des informations contenues dans un fichier virtuel élémentaire. La figure 11 illustre schématiquement ce processus.
Selon le procédé de l'invention, on prévoit deux méthodes d'accès, que l'on appellera directe et indirecte, respectivement, en fonction des attributs du fichier élémentaire virtuel considéré.
La méthode directe consiste en une description d'une chaîne d'agents intelligents mis en œuvre dans le processus permettant d'accéder à un objet virtuel Obvj et d'en obtenir une instance dans le terminal. Lors de l'ouverture d'une session, un agent intelligent donné reçoit, de l'agent qui initie cette session, une liste de structures d'appel qui sera dénommée ci-après "méthode d'appel" ou encore "Method PDU" (pour "Method Protocol Data Unit"). Une structure d'appel comprend :
- un identificateur de l'agent intelligent avec lequel la session est ouverte ; - des données, ou argument, nécessaires à son utilisation.
Le premier agent intelligent adressé par la liste précitée "consomme" une première structure d'appel qui lui est destinée. Il transmet le reste de la liste de structure à un agent intelligent suivant, avec lequel il établit une session, jusqu'à épuisement de la liste. Pour fixer les idées, un exemple des différentes étapes d'échanges entre l'agent intelligent "ATSDA/SGFV" 7 et deux agents intelligents en cascade, 232am et 232aπ, est illustré schématiquement par la figure 12. La liste de structure d'appel émise par l'agent intelligent "ATSDA/SGFV" 7 comporte en réalité deux sous-listes distinctes, repérées #1 et #2 dans leurs en-têtes, respectivement. La première est consommée par le premier agent intelligent, 232am, et la seconde par le second agent intelligent, 232aπ- Un agent intelligent, par exemple l'agent intelligent 232am, est identifié par une référence, ou identificateur d'agent ("Identificateur Agent #1" ou "Identificateur Agent #2"). L'agent intelligent adressé, et avec lequel s'établit une session, retient la sous-liste qui lui est destinée grâce à Pen-tête ("Structure dAppel #1 ou "Structure dAppel #2"). Les arguments de la sous-liste qu'il retient ("Argument#1" ou "Argument#1") sont constitués par un ensemble de données utiles au bon fonctionnement de cet agent. A titre d'exemple, une donnée peut être un nom de fichier (non virtuel ou virtuel direct). Un agent intelligent donné, par exemple l'agent intelligent 232am, peut modifier le reste de la liste de structure d'appel avant de la transmettre à l'agent intelligent suivant, 232aπ- Pour ce faire, il adresse cet agent intelligent, 232an, et établit une session avec lui.
La méthode d'appel peut être avantageusement décrite au moyen du langage ASN.1 (« Abstract Syntax Notation 1 » de PISO) La méthode d'accès directe permet en définitive d'instancier un objet virtuel Obvj directement depuis la carte à puce 2a. Il s'agit a pήori d'un objet statique. L'objet instancié se présente habituellement sous la forme d'une page "HTML" ou d'un "applet" transmis au navigateur 10. La seconde méthode d'accès, ou méthode d'accès indirect, est en réalité également une méthode d'accès direct, mais mise en œuvre à partir du terminal 1 , et non plus de la carte à puce 2a. Cette méthode est essentiellement utilisée pour instancier des objets virtuels Obvj du type dynamique. Selon cette variante du procédé, en réponse à un "URL" qui désigne un fichier élémentaire virtuel fe#x, l'agent intelligent "ATSDA/SGFV" 7 transmet au navigateur 10 une page "HTML" qui comporte un hyperlien pointant sur la méthode d'accès directe associée à l'objet virtuel Obvj Deux variantes peuvent être mises en œuvre. La première variante consiste à utiliser un "applet". Le lien sur la méthode d'accès est alors un "applet" localisé à l'adresse "@carte", qui peut elle-même être désignée par : le nom (c'est-à-dire une "URL") d'un fichier non virtuel, enregistré sur la carte à puce 2a ; - une "URL" qui désigne un fichier virtuel direct.
Un paramètre d'appel de cet "applet" est une liste de structure d'appel, par exemple codée en ASN.1 comme indiqué ci-dessus. L' "applet" contenu dans une page "HTLM" est téléchargé, depuis la carte à puce 2a ou le réseau Internet RI, vers le navigateur 10, puis exécuté par celui-ci de façon obligatoire (forçage). Cet "applet" établit une session avec un premier agent intelligent, arbitrairement référencé 232ap. La connexion à cet agent intelligent 232ap utilise, par exemple, un modèle d'échange de données du type client-serveur "TCP/IP" (c'est-à-dire la classe dite "socket JAVA"). L' "applet" se comporte comme un client "TCP/IP" et se connecte à un serveur "TCP/IP" (ce dernier étant également un agent intelligent) identifié par l'adresse de la carte et un port : "@carte : port". La figure 13 illustre schématiquement les différentes phases des échanges permettant d'instancier un objet virtuel par la méthode indirecte. On a repris sur cette figure 13 les paramètres de l'exemple précédemment décrit, en l'occurrence, le fichier élémentaire virtuel fe#5, ce qui se traduit par l'adresse "URL" de la configuration (6) ci-dessus. On a supposé que l'adresse de la carte à puce à utiliser est "@carte" et le port 8080. La requête est transmise à l'agent intelligent "ATSDA/SGFV" 7 selon le processus précédemment décrit. Celui-ci renvoie au navigateur 10 une page "HTML" P constituée par un "applet". Dans un but de simplification du dessin, les différentes instructions de cet "applet" ont été résumées sur la figure 13 par la mention "Code applet' placée entre les marqueurs <applet ...> et </applet>. De façon connue en soi, P "applet" est associé à une classe "JAVA", que l'on a appelée arbitrairement "tv.class", pour "terminal virtuel". Le code comprend également des instructions indiquant l'adresse du premier agent intelligent de la structure de liste , référencé 232ap, et l'adresse et le port à utiliser, en l'occurrence l'adresse "@carte" et le port 8081. Il est à noter que cet agent intelligent 232ap peut être localisé dans la carte à puce 2a ou dans le terminal 1.
La phase suivante consiste, pour le navigateur, à demander Papplet à la carte 2a au moyen de la liste de structure d'appel, laquelle définit les paramètres d'appel de Papplet. En réponse, la carte lui transmet Papplet, lequel sera chargé par le navigateur sur sa machine virtuelle « Java », où il sera exécuté. La phase suivante consiste, pour le navigateur, à appeler l'agent intelligent 232ap en utilisant la classe « socket » du langage « Java ».
Chaque agent intelligent, par exemple 232ap, exécute une tâche précise : déchiffrement d'un message chiffré, vérification de mots de passe et/ou de données de sécurité, conversion d'un fichier depuis un premier format à un autre, etc. Bien que l'on n'ait représenté qu'un seul agent intelligent, 232ap, on peut prévoir, en tant que de besoin, plusieurs agents intelligents en cascade comme dans le cas précédent (figure 12), ce qui est illustré sur la figure 13 par les pointillés. Comme précédemment également chaque agent intelligent, 232ap, consomme une partie de la structure de liste, celle qui lui est destinée, et transmet le reste, inchangé ou modifié, à l'agent intelligent suivant (non représenté).
Pour mieux illustrer la première variante, et pour fixer les idées, on va considérer que l'utilisateur Uj désire télécharger et exécuter un fichier audio, codé par exemple au format "MP3". Ce fichier constitue l'un des objets virtuels, ici référencé FS, proposés par la page de menu "HTML" transmise par l'agent intelligent "ATSDA/SGFV" 7, lors de la phase initiale. La figure 14 illustre schématiquement la séquence d'étapes permettant d'instancier un tel objet virtuel, référencé FS. On suppose que le navigateur 10 ne dispose pas d'un lecteur approprié pour un tel format. Ce lecteur, référencé LS, va être cherché sur un site Internet, qui peut être distinct ou non du site où se trouve le fichier son FS.
Dans l'exemple décrit, la séquence d'étapes est la suivante. a/ l'utilisateur Uj clique sur un hyperlien (texte, icône ou toute autre représentation graphique de l'objet à rechercher, c'est-à-dire le fichier FS) : une requête / est transmise à la carte à puce 2a ; b/ en réponse, R-| , une page "HTML" est transmise, par la carte à puce 2a, au terminal 1 et au navigateur 10 ; c/ la page "HTML" reçue force le navigateur 10 à demander un "applet" : interrogation /2 (dans le cas présent, il s'agit d'aller chercher le lecteur de son approprié LS) ;
61 en réponse, R2, le lecteur recherché LS est téléchargé et installé dans le terminal 1 ; el le navigateur 10 adresse de nouveau la carte à puce 2a, requête /3, en vue d'obtenir une instance du fichier audio FS; et il en réponse, le navigateur 10 reçoit ce fichier audio FS, ce dernier pouvant être lu, c'est-à-dire joué par le terminal 1 , qui dispose désormais du lecteur de son LS approprié. Il est à noter que toutes les opérations sont transparentes pour l'utilisateur Uj, plus précisément pour le navigateur 10, qui ne "connaît" que la carte à puce 2a. Le lecteur LS (ou de façon plus générale un autre "applet") et/ou l'objet virtuel recherché, c'est-à-dire le fichier FS dans l'exemple, si leurs tailles avaient été compatibles avec la capacité de mémorisation de la carte à puce 2a, auraient d'ailleurs pu être enregistrés dans celle-ci (re-bouclages symbolisés par des traits en pointillés sur la figure 14). Le navigateur 10 ne connaît pas la localisation exacte des objets virtuels Obvj. Seule la carte à puce 2a, de façon plus précise l'agent intelligent "ATSDA/SGFV" 7, connaît la localisation des objets virtuels de la liste du "SGFV" 8 et la méthode pour y accéder.
Dans une variante préférée du procédé, l'agent intelligent "ATSDA/SGFV" 7 connaît également la liste des seuls objets virtuels accessibles à un utilisateur Uj donné (autorisations). Il s'agit donc bien d'un système sécurisé. Le terme "sécurisé" doit être considéré dans son sens le plus large. A titre d'exemple, il concerne aussi bien des cartes à péage donnant accès à certaines ressources, en fonction d'un abonnement déterminé par exemple, ou des cartes assurant un accès sécurisé proprement dit à des ressources confidentielles, en fonction d'un niveau d'habilitation par exemple. Comme il a été indiqué, les ressources ou objets virtuels Obvj peuvent être constituées par des transactions. Ces remarques s'appliquent d'ailleurs aussi pour les méthodes d'accès direct. Cela constitue une caractéristique du procédé selon l'invention. Selon une seconde variante, illustrée schématiquement par la figure 15, on peut utiliser un hyperlien qui définit l'adresse "TCP/IP" du premier agent intelligent associé à la méthode d'accès. L'adresse est du type "@Agent:AgentPort", avec "@Agent", l'adresse proprement dite de l'agent intelligent concerné et "AgentPort" le port de celui-ci. La liste "MethodPDU" est dans ce cas un paramètre d'une "URL". L'hyperlien sera associé, par exemple à une image ou un formulaire d'une page "HTML" P'. Ainsi, à titre d'exemple, une "URL" ayant la structure suivante : http://@Agent:AgentPort/MethodPDU?Value=xx... (7), permet d'atteindre un agent intelligent qui se comporte comme un serveur "WEB TCP/IP", référencé arbitrairement 232ag. Cet agent intelligent 232ag est localisé à l'adresse "@Agent:AgentPort" et reçoit la liste de structure d'appel "MethodPDU", avec le paramètre "Value=xx...". Pour fixer les idées, on suppose que l'objet virtuel Obvj est une image à afficher sur un écran (figure 1A :5), d'un format particulier, à l'aide du navigateur 10 et que celui-ci ne dispose pas d'un programme approprié pour cet affichage, généralement appelé visionneuse ou "viewer" selon la terminologie anglo-saxonne. Il s'agit, par exemple, d'un programme exécutable sous le système d'exploitation utilisé sur le terminal 1 , de type "XXX.exe", avec
"XXX" le nom de ce programme. L'action de cliquer sur l'hyperlien (7) ci-dessus va permettre de rechercher ce programme exécutable, celui-ci pouvant être localisé dans le terminal 1 ou dans un système éloigné.
La différence entre les deux variantes de réalisation est que dans le premier cas, le navigateur se voit "forcé" de demander le chargement d'un "applet". Toutes les étapes sont réalisées automatiquement. Dans le second cas, l'utilisateur Uj est invité à cliquer sur un hyperlien ou à exécuter une action similaire.
A la lecture de ce qui précède, on constate aisément que l'invention atteint bien les buts qu'elle s'est fixés.
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 à
15.
En particulier, comme en ce qui concerne les autres agents intelligents traducteurs de script; la fonction de l'agent intelligent associé au système de gestion de fichier virtuel peut être remplie par un agent non dédié : l'agent
"WEB" ou l'agent "APDU".

Claims

REVENDICATIONS
1 Système embarqué, équipé d'une puce comprenant des moyens de traitement d'information et des moyens de mémorisation d'information, et destiné à coopérer avec un réseau au travers d'un terminal, caractérisé en ce que :
-il stocke au moins un fichier d'objet contenant des informations associées à un objet situé sur le réseau et permettant de réaliser une instance de cet objet ;
-il comprend des moyens d'interface de réseau, agencés pour coopérer avec des moyens d'interface de réseau appariés, situés dans le terminal, de façon que le système embarqué constitue un serveur d'information sur le réseau ; et
-il comprend des moyens d'interface de fichier d'objet, agencés pour établir une correspondance entre des informations transitant par les moyens d'interface de réseau et affectées à au moins ledit fichier d'objet, et des informations échangées avec ledit fichier d'objet.
2. Système embarqué selon la revendication 1 , dans lequel le fichier d'objet comprend une pièce de logiciel autonome exécutable sur un logiciel de navigation.
3. Système embarqué selon la revendication 1 , dans lequel lesdits moyens d'interface de réseau sont agencés pour coopérer avec les moyens d'interface de réseau appariés, situés dans le terminal, de façon que le système embarqué se comporte comme un client capable de se connecter à au moins un serveur du réseau.
4. Procédé pour instancier un objet situé sur un réseau, caractérisé en ce qu'il utilise un système embarqué, équipé d'une puce comprenant des moyens de traitement d'information et des moyens de mémorisation d'information, et destiné à coopérer avec un réseau au travers d'un terminal, le système embarqué stockant au moins un fichier d'objet contenant des informations associées à un objet situé sur le réseau et permettant de réaliser une instance de cet objet, et comprenant d'une part des moyens d'interface de réseau, agencés pour coopérer avec des moyens d'interface de réseau appariés, situés dans le terminal, de façon que le système embarqué constitue un serveur d'information sur le réseau, et d'autre part des moyens d'interface de fichier d'objet, agencés pour établir une correspondance entre des informations transitant par les moyens d'interface de réseau et affectées à au moins ledit fichier d'objet, et des informations échangées avec ledit fichier d'objet, le procédé étant en outre caractérisé en ce qu'il permet de décrire un ensemble de sessions entre agents par un fichier d'objet, au moyen d'au moins les étapes suivantes :
-établir une liste des agents mis en œuvre ;
-pour chaque agent, définir des arguments d'appel, nécessaires à l'agent.
5. Procédé selon la revendication 4, dans lequel un argument d'appel décrit l'ouverture d'une session avec un autre agent.
6. Procédé selon la revendication 4, dans lequel un agent modifie la liste des arguments utilisés par un autre agent.
7. Procédé pour instancier un objet situé sur un réseau, caractérisé en ce qu'il utilise un système embarqué, équipé d'une puce comprenant des moyens de traitement d'information et des moyens de mémorisation d'information, et destiné à coopérer avec un réseau au travers d'un terminal, le système embarqué stockant au moins un fichier d'objet contenant des informations associées à un objet situé sur le réseau et permettant de réaliser une instance de cet objet, et comprenant d'une part des moyens d'interface de réseau, agencés pour coopérer avec des moyens d'interface de réseau appariés, situés dans le terminal, de façon que le système embarqué constitue un serveur d'information sur le réseau, et d'autre part des moyens d'interface de fichier d'objet, agencés pour établir une correspondance entre des informations transitant par les moyens d'interface de réseau et affectées à au moins ledit fichier d'objet, et des informations échangées avec ledit fichier d'objet, le procédé étant en outre caractérisé en ce qu'il met en œuvre des sessions entre agents décrites par un fichier d'objet exécuté depuis le serveur d'information du système embarqué au moyen d'au moins les étapes suivantes :
-identification d'un fichier d'objet ;
-exécution de ce fichier d'objet.
8. Procédé selon la revendication 7, dans lequel l'exécution est effectuée par instanciation du premier agent associé au fichier objet.
9. Procédé selon la revendication 7, dans lequel l'exécution est effectuée par instanciation d'un ou plusieurs agents référencés par le fichier objet.
10. Procédé pour instancier un objet situé sur un réseau, caractérisé en ce qu'il utilise un système embarqué, équipé d'une puce comprenant des moyens de traitement d'information et des moyens de mémorisation d'information, et destiné à coopérer avec un réseau au travers d'un terminal, le système embarqué stockant au moins un fichier d'objet contenant des informations associées à un objet situé sur le réseau et permettant de réaliser une instance de cet objet, et comprenant d'une part des moyens d'interface de réseau, agencés pour coopérer avec des moyens d'interface de réseau appariés, situés dans le terminal, de façon que le système embarqué constitue un serveur d'information sur le réseau, et d'autre part des moyens d'interface de fichier d'objet, agencés pour établir une correspondance entre des informations transitant par les moyens d'interface de réseau et affectées à au moins ledit fichier d'objet, et des informations échangées avec ledit fichier d'objet, le procédé étant en outre caractérisé en ce qu'il met en œuvre des sessions entre agents décrites par un fichier d'objet exécuté depuis un logiciel de navigation au moyen d'au moins les étapes suivantes : -chargement par le logiciel de navigation d'un fichier d'objet et d'un logiciel spécifique capable de le mettre en œuvre ;
-exécution du logiciel spécifique par le logiciel de navigation.
11. Procédé selon la revendication 10, dans lequel la réalisation du logiciel spécifique est effectuée au moyen de tout langage interprété, exécutable par le logiciel de navigation.
12. Procédé selon la revendication 10, dans lequel l'interpréteur de fichier objet est réalisé sur un logiciel de navigation.
13. Procédé pour instancier un objet situé sur un réseau, caractérisé en ce qu'il utilise un système embarqué, équipé d'une puce comprenant des moyens de traitement d'information et des moyens de mémorisation d'information, et destiné à coopérer avec un réseau au travers d'un terminal, le système embarqué stockant au moins un fichier d'objet contenant des informations associées à un objet situé sur le réseau et permettant de réaliser une instance de cet objet, et comprenant d'une part des moyens d'interface de réseau, agencés pour coopérer avec des moyens d'interface de réseau appariés, situés dans le terminal, de façon que le système embarqué constitue un serveur d'information sur le réseau, et d'autre part des moyens d'interface de fichier d'objet, agencés pour établir une correspondance entre des informations transitant par les moyens d'interface de réseau et affectées à au moins ledit fichier d'objet, et des informations échangées avec ledit fichier d'objet, le procédé étant en outre caractérisé en ce qu'il permet au système embarqué de rendre possible la mise en œuvre de sessions entre agents décrites par un fichier d'objet exécuté depuis un logiciel de navigation, et en ce qu'il comprend l'étape consistant à identifier, au moyen d'un identificateur universel de ressource, un logiciel spécifique agencé pour mettre en œuvre le logiciel de navigation.
14. Procédé selon la revendication 13, dans lequel l'identificateur universel de ressource est intégré à un document hyper-texte.
15. Procédé selon la revendication 13, dans lequel ledit logiciel spécifique est chargé par une méthode disponible sur le logiciel de navigation et déduite de l'identificateur universel de ressource.
EP00910949A 1999-03-15 2000-03-15 Systemd d'acces a un objet a l'aide d'un navigateur de type "web" cooperant avec une carte a puce Withdrawn EP1076972A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR9903172 1999-03-15
FR9903172A FR2791159B1 (fr) 1999-03-15 1999-03-15 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
PCT/FR2000/000625 WO2000056030A1 (fr) 1999-03-15 2000-03-15 Systeme d'acces a un objet a l'aide d'un navigateur de type 'web' cooperant avec une carte a puce

Publications (1)

Publication Number Publication Date
EP1076972A1 true EP1076972A1 (fr) 2001-02-21

Family

ID=9543203

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00910949A Withdrawn EP1076972A1 (fr) 1999-03-15 2000-03-15 Systemd d'acces a un objet a l'aide d'un navigateur de type "web" cooperant avec une carte a puce

Country Status (10)

Country Link
US (1) US6944650B1 (fr)
EP (1) EP1076972A1 (fr)
JP (2) JP3794926B2 (fr)
KR (1) KR100693196B1 (fr)
CN (1) CN100385889C (fr)
AU (1) AU776016C (fr)
CA (1) CA2332283C (fr)
FR (1) FR2791159B1 (fr)
HK (1) HK1036539A1 (fr)
WO (1) WO2000056030A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7636749B2 (en) 1999-05-19 2009-12-22 Ricoh Company, Ltd. System for distributing, installing and running web applications (agents)

Families Citing this family (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2793576B1 (fr) * 1999-05-11 2001-11-16 Gemplus Card Int Terminal radiotelephonique avec une carte a puce dotee d'un navigateur
US7933968B1 (en) * 2000-06-20 2011-04-26 Koninklijke Philips Electronics N.V. Token-based personalization of smart appliances
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
US7421480B2 (en) * 2000-02-28 2008-09-02 O2 Micro International Limited Personal computing environment using mozilla
FR2815801B1 (fr) * 2000-10-20 2004-10-29 Trusted Logic Protocole de transmission d'une pluralite de flux logiques d'echange multiple de couples de commande/reponse sur un canal physique unique d'echange entre maitre et esclave et systeme de suivi et de controle d'execution d'appliquettes
US6824064B2 (en) 2000-12-06 2004-11-30 Mobile-Mind, Inc. Concurrent communication with multiple applications on a smart card
FR2820848B1 (fr) * 2001-02-13 2003-04-11 Gemplus Card Int Gestion dynamique de listes de droits d'acces dans un objet electronique portable
SG154320A1 (en) 2001-02-16 2009-08-28 Sony Corp Data processing method and its apparatus
JP4765174B2 (ja) * 2001-02-16 2011-09-07 ソニー株式会社 アプリケーション実行装置、通信システム、およびアプリケーション実行方法
EP1233333A1 (fr) * 2001-02-19 2002-08-21 Hewlett-Packard Company Procédé pour exécuter un service téléchargeable avec réception de droits d'accès restrictifs pour au moins un fichier de profiles
US7861091B2 (en) * 2001-02-28 2010-12-28 O2Micro International Limited Smart card enabled secure computing environment system
US20020143700A1 (en) * 2001-03-29 2002-10-03 Wu Guangdian Guordon Method and apparatus for individual-centric use of the internet
US8543823B2 (en) 2001-04-30 2013-09-24 Digimarc Corporation Digital watermarking for identification documents
US20020162021A1 (en) * 2001-04-30 2002-10-31 Audebert Yves Louis Gabriel Method and system for establishing a remote connection to a personal security device
US8028083B2 (en) * 2001-04-30 2011-09-27 Activcard Ireland, Limited Method and system for remote activation and management of personal security devices
DE60203277T2 (de) * 2001-04-30 2006-03-30 Activcard Ireland Ltd. Verfahren und system zur authentifizierung eines personal security device gegenüber mindestens einem fernrechnersystem
US7363486B2 (en) * 2001-04-30 2008-04-22 Activcard Method and system for authentication through a communications pipe
US7225465B2 (en) * 2001-04-30 2007-05-29 Matsushita Electric Industrial Co., Ltd. Method and system for remote management of personal security devices
US20020174206A1 (en) * 2001-05-21 2002-11-21 Moyer Alan L. Web-based file manipulating system
US20020194499A1 (en) * 2001-06-15 2002-12-19 Audebert Yves Louis Gabriel Method, system and apparatus for a portable transaction device
FR2826826B1 (fr) * 2001-06-28 2003-09-26 Cit Alcatel Module d'identification d'abonne et terminal associe
FR2828358B1 (fr) * 2001-08-02 2004-01-16 Gemplus Card Int Procede et dispositif de mise en compatibilite de communication sur reseau de terminaux, par exemple pour permettre un dialogue avec une application sur une carte a puce
ES2262828T3 (es) * 2001-08-24 2006-12-01 Windmill Microsystems Holding B.V. Sistema para la adquisicion remota de datos basado en la comunicacion de mensajes por correo electronico a traves de redes publicas y privadas.
FR2830151A3 (fr) * 2001-09-25 2003-03-28 Bahia 21 Corp Appareil de communication portatif, et systeme associe
US6868480B2 (en) 2001-09-28 2005-03-15 Ui Evolution, Inc. Removable active application specific medium
US7346783B1 (en) * 2001-10-19 2008-03-18 At&T Corp. Network security device and method
US7162631B2 (en) * 2001-11-02 2007-01-09 Activcard Method and system for scripting commands and data for use by a personal security device
CN101159621B (zh) * 2001-12-05 2010-12-22 微软公司 移动式和嵌入式设备的配置和管理系统
US7783901B2 (en) * 2001-12-05 2010-08-24 At&T Intellectual Property Ii, L.P. Network security device and method
CA2470094C (fr) 2001-12-18 2007-12-04 Digimarc Id Systems, Llc Elements de securite a images multiples pour documents d'identification, et procedes de realisation
US7728048B2 (en) 2002-12-20 2010-06-01 L-1 Secure Credentialing, Inc. Increasing thermal conductivity of host polymer used with laser engraving methods and compositions
FR2834850B1 (fr) * 2002-01-17 2004-03-19 Gemplus Card Int Procede de chargement de donnees ou d'applications dans un equipement de poste mobile mettant en oeuvre une carte sim pro-active
US20030135618A1 (en) * 2002-01-17 2003-07-17 Ravikumar Pisupati Computer network for providing services and a method of providing services with a computer network
US20100174717A1 (en) * 2002-02-28 2010-07-08 Olivier Fambon Interative serialisation procedure for structured software objects
US20030167399A1 (en) * 2002-03-01 2003-09-04 Yves Audebert Method and system for performing post issuance configuration and data changes to a personal security device using a communications pipe
KR100858703B1 (ko) * 2002-04-13 2008-09-17 주식회사 케이티프리텔 스마트 카드 기반의 자동 입력 서비스 방법
US7824029B2 (en) 2002-05-10 2010-11-02 L-1 Secure Credentialing, Inc. Identification card printer-assembler for over the counter card issuing
DE602004030434D1 (de) 2003-04-16 2011-01-20 L 1 Secure Credentialing Inc Dreidimensionale datenspeicherung
US7546357B2 (en) 2004-01-07 2009-06-09 Microsoft Corporation Configuring network settings using portable storage media
US8127137B2 (en) 2004-03-18 2012-02-28 Digimarc Corporation Watermark payload encryption for media including multiple watermarks
SE528373C2 (sv) * 2004-08-25 2006-10-31 Smarttrust Ab Förfarande och system för apparathantering
GB2430582B (en) * 2005-09-26 2008-04-09 Nec Technologies Method of managing connectivity status for a mobile radio communications device, and such a device
EP1791055A1 (fr) 2005-11-23 2007-05-30 Incard SA Système de fichier pour carte à circuit intégré
DE102007026870A1 (de) * 2007-06-11 2008-12-18 Giesecke & Devrient Gmbh Ressourcenzugriff unter Vermittlung durch ein Sicherheitsmodul
CN101413803B (zh) * 2007-10-19 2011-07-27 神达电脑股份有限公司 提供终端使用者内容的导航系统及架构
CN101415015B (zh) * 2007-10-19 2014-06-04 神达电脑股份有限公司 提供终端使用者内容的导航系统及架构
KR100873211B1 (ko) * 2007-10-26 2008-12-10 주식회사 케이티프리텔 브라우저 초기화면 정보가 저장된 스마트 카드, 스마트카드가 탑재된 이동통신 단말기 및 스마트 카드를 이용한브라우저 초기화면 설정 방법
US8316150B2 (en) * 2007-10-31 2012-11-20 Time Warner Cable Inc. System and method for remotely accessing cablecard
WO2009066920A2 (fr) * 2007-11-23 2009-05-28 Lg Electronics Inc. Terminal mobile et dispositifs de stockage associés ayant des serveurs web, procédé de commande de ces derniers
US8140855B2 (en) * 2008-04-11 2012-03-20 Microsoft Corp. Security-enhanced log in
CN101576989A (zh) 2009-06-09 2009-11-11 阿里巴巴集团控股有限公司 移动终端中实现支付的方法及移动设备
KR101088168B1 (ko) 2009-06-12 2011-12-02 (주) 케이비씨테크 Ｓｃｗｓ를 이용하여 웹기반 ｏｓ를 구비한 스마트카드 및 이를 이용한 이동통신 단말기
CN102073634B (zh) * 2009-11-20 2013-10-23 中国银联股份有限公司 一种智能卡文件系统及其文件选择方法
JP2011150560A (ja) * 2010-01-22 2011-08-04 Kddi Corp ソフトウェア保護システム、ソフトウェア保護方法、ソフトウェア変換方法およびプログラム
KR101089023B1 (ko) 2010-08-06 2011-12-01 삼성에스디에스 주식회사 스마트 카드, 및 이를 이용한 안티-바이러스 시스템 및 스캐닝 방법
FR2975551B1 (fr) 2011-05-16 2013-09-27 Ethertrust Procede de securisation d'une architecture d'authentification, dispositifs materiels et logiciels correspondants
JP2013037554A (ja) * 2011-08-09 2013-02-21 Mega Chips Corp メモリシステム、セキュリティメモリおよび情報保護方法
ITMI20120561A1 (it) * 2012-04-05 2013-10-06 St Microelectronics Srl Metodo per proteggere un programma applicativo
CN106412126A (zh) * 2016-12-05 2017-02-15 深圳中兴网信科技有限公司 Docker镜像描述信息的展示方法及展示装置
US11531971B2 (en) * 2020-09-02 2022-12-20 Capital One Services, Llc Computer-based systems and device configured for electronic authentication and verification of documents and methods thereof

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5465401A (en) * 1992-12-15 1995-11-07 Texas Instruments Incorporated Communication system and methods for enhanced information transfer
US5694471A (en) * 1994-08-03 1997-12-02 V-One Corporation Counterfeit-proof identification card
US5590197A (en) * 1995-04-04 1996-12-31 V-One Corporation Electronic payment system and method
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
US5812765A (en) * 1996-03-22 1998-09-22 Axxs Technologies Corporation Multi-media remote data access terminals and system
US6282522B1 (en) * 1997-04-30 2001-08-28 Visa International Service Association Internet payment system using smart card
ZA985151B (en) * 1997-06-13 1999-04-13 Gemplus Card Int Smartcard wireless telephone system and method for accessing and communication with the internet
US5983273A (en) * 1997-09-16 1999-11-09 Webtv Networks, Inc. Method and apparatus for providing physical security for a user account and providing access to the user's environment and preferences
US6226744B1 (en) * 1997-10-09 2001-05-01 At&T Corp Method and apparatus for authenticating users on a network using a smart card
US6247644B1 (en) * 1998-04-28 2001-06-19 Axis Ab Self actuating network smart card device
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
FR2782435B1 (fr) * 1998-08-13 2000-09-15 Bull Cp8 Procede de communication entre une station d'utilisateur et un reseau, notamment de type internet, et architecture de mise en oeuvre
FI109756B (fi) * 1998-09-21 2002-09-30 Nokia Corp Menetelmä tiedonsiirtojärjestelmässä paikallisten resurssien hyödyntämiseksi, tiedonsiirtojärjestelmä ja langaton viestin
FR2790629A1 (fr) * 1999-02-19 2000-09-08 Bull Cp8 Procede d'activation d'applications localisees dans une carte a puce par un navigateur du type dit "web"
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
FR2805062B1 (fr) * 2000-02-10 2005-04-08 Bull Cp8 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, notamment d'un flux de donnees multimedia
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

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0056030A1 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7636749B2 (en) 1999-05-19 2009-12-22 Ricoh Company, Ltd. System for distributing, installing and running web applications (agents)

Also Published As

Publication number Publication date
CA2332283A1 (fr) 2000-09-21
JP3794926B2 (ja) 2006-07-12
JP2002539546A (ja) 2002-11-19
KR20010043648A (ko) 2001-05-25
US6944650B1 (en) 2005-09-13
AU776016B2 (en) 2004-08-26
CN100385889C (zh) 2008-04-30
CN1300494A (zh) 2001-06-20
JP2006134335A (ja) 2006-05-25
CA2332283C (fr) 2011-03-08
FR2791159A1 (fr) 2000-09-22
FR2791159B1 (fr) 2001-05-04
AU3298200A (en) 2000-10-04
HK1036539A1 (en) 2002-01-04
KR100693196B1 (ko) 2007-03-13
AU776016C (en) 2005-03-24
WO2000056030A1 (fr) 2000-09-21

Similar Documents

Publication Publication Date Title
WO2000056030A1 (fr) Systeme d&#39;acces a un objet a l&#39;aide d&#39;un navigateur de type &#39;web&#39; cooperant avec une carte a puce
EP1169837B1 (fr) Procede de gestion de transmissions de donnees multimedias via internet et carte a puce pour la mise en oeuvre du procede
EP1188116A1 (fr) Procede de chargement d&#39;une piece de logiciel dans une carte a puce, notamment du type dit &#34;applet&#34;
FR2805108A1 (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
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
EP1044436B1 (fr) Procede de communication entre une station d&#39;utilisateur et un reseau, notamment du type internet, et architecture de mise en oeuvre
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
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
EP1145522A2 (fr) Procede et architecture de pilotage a distance d&#39;une station d&#39;utilisateur via un reseau de type internet

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

17P Request for examination filed

Effective date: 20010321

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

Owner name: CP8 TECHNOLOGIES

17Q First examination report despatched

Effective date: 20060811

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: 20141001