EP1074007A1 - Systeme embarque possedant des moyens d'interface de reseau, et procede d'activation d'applications localisees dans ce systeme embarque - Google Patents

Systeme embarque possedant des moyens d'interface de reseau, et procede d'activation d'applications localisees dans ce systeme embarque

Info

Publication number
EP1074007A1
EP1074007A1 EP00906418A EP00906418A EP1074007A1 EP 1074007 A1 EP1074007 A1 EP 1074007A1 EP 00906418 A EP00906418 A EP 00906418A EP 00906418 A EP00906418 A EP 00906418A EP 1074007 A1 EP1074007 A1 EP 1074007A1
Authority
EP
European Patent Office
Prior art keywords
smart card
application
terminal
software
network
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
EP00906418A
Other languages
German (de)
English (en)
Inventor
Alain Boudou
Christoph Siegelin
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 EP1074007A1 publication Critical patent/EP1074007A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/077—Constructional details, e.g. mounting of circuits in the carrier
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/34—Director, elements to supervisory
    • G05B2219/34444—Web control system, with intelligent control components each with web server

Definitions

  • the present invention relates to an on-board system having network interface means, and to a method for activating applications located in this on-board system.
  • the method according to the invention is more particularly concerned with a user station provided with a "smart" card reader and connected to the Internet.
  • the term "user station” must be understood in a general sense.
  • the aforementioned 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.
  • network includes any network comprising a set of servers linked together, in particular a planetary network in which information is transported from end to end. These are in particular the Internet network, any network in which data exchanges are carried out according to a protocol of the Internet type, private networks of companies or the like, called “intranet”, and networks extending them to the Internet. exterior, called “extranet”.
  • terminal equipped with a smart card reader and connected to an Internet type network.
  • a smart card-based application system generally includes the following main elements: - a smart card;
  • a communication network namely the Internet network in the preferred application
  • FIG. 1A schematically illustrates an example of architecture of this type.
  • the terminal for example a personal computer, includes a smart card reader 3. This reader 3 may or may not be physically integrated into the terminal 1.
  • the smart card 2 has an integrated circuit 20 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.
  • 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
  • ISP Internet Service Provider
  • Terminal 1 naturally includes all the circuits and organs necessary for its proper functioning, and which have not been shown for the purpose of simplifying the drawing: central unit, random access memory and fixed memory, mass memory with magnetic disk, floppy drive and / or CédéRom, etc.
  • the terminal 1 is also connected to conventional peripherals, integrated or not, such as a display screen 5 and a keyboard 6.
  • the terminal l can be put in communication with servers connected to the RI network, of which only one, 4, is illustrated in FIG. 1.
  • 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 by means of special software 10, called browser.
  • browser is meant any means offering the following functions:
  • This browser function corresponds to that referred to by the English term "browser”.
  • 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.
  • the browser provides access to various applications distributed over the entire RI network, generally in a "client-server” mode.
  • communications on networks are carried out in accordance with protocols meeting standards comprising several software layers. superimposed.
  • communications are carried out according to protocols specific to this type of communications, which will be detailed below, but which also include several software layers.
  • the communication protocol is chosen according to the application more particularly targeted: interrogation of "WEB” pages, file transfers, electronic mail (e-mel, or “e-mail” according to Anglo-Saxon terminology), forums or “news”, etc.
  • FIG. 1B The logical architecture of the system comprising a terminal, a smart card reader and the smart card, is shown diagrammatically in FIG. 1B. 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 the 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 201 have been represented.
  • the layers corresponding to ISO 7816-3 are referenced 200 and the "ADPU” order manager (ISO 7816-4 standard) is referenced 201.
  • the applications are referenced A ⁇ , ... , A ⁇ , ..., 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 “APD ⁇ r .co-7--7iand” and a response “APDU” is noted “APDU.response”.
  • a ⁇ application is, for example, in the form of a piece of software, known as an "applet”, in the "JAVA” language (registered trademark), which will be called “cardlet” below.
  • 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.
  • a smart card-based application system as illustrated by the architecture of FIG. 1B, the latter can be assigned various functions.
  • card 3 cannot communicate directly with commercial browsers, except to modify the code of these.
  • 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 host system associated with the card reader 3, that is to say the terminal 1 is also associated with a particular application.
  • the host system associated with the card reader 3, that is to say the terminal 1 is also associated with a particular application.
  • the invention therefore relates in particular to a method of activating applications located in a smart card by a browser of the so-called "WEB" type, making it possible to overcome the drawbacks of the known art, some of which have just been recalled .
  • 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, which allows the user to choose a particular application among those available and offered by the card to chip.
  • HTML HyperText Markup Language
  • applet for "HyperText Markup Language ")
  • JAVA JAVA
  • the host system is seen as a peripheral of the smart card, and it makes available to it hardware resources, such as a display screen, a keyboard, etc.
  • 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.
  • agents paired in the respective specific communication layers associated with the terminal and the smart card. According to the method of the invention, sessions are established between paired agents.
  • 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.
  • script translators which receive requests from a browser and translate them into "APDU” orders understandable by the "CGA” type application.
  • the method of the invention makes it possible to manage applications of an unconventional type, without having to modify the architecture of the system. According to another characteristic, the method of
  • 1 invention allows dynamic downloading of new applications in the smart card, traditional or not, as well as updating or deleting one or more applications.
  • the subject of the invention is therefore 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 that he understands:
  • 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;
  • application interface means arranged to establish a correspondence between instructions circulating on the network and assigned to at least one application stored in the on-board system (these instructions notably emanating from a browser or intended for a browser), and instructions for exchanging information between said network interface means and said application.
  • the invention also relates to a method for activating at least one application stored in an on-board system, equipped with a chip comprising information processing means and information storage means, and intended to cooperate with a network through of a terminal, characterized in that it uses an on-board system comprising network interface means, arranged to cooperate with paired network interface means, located in the terminal, so that the embedded system constitutes an information server on the network, and application interface means, arranged to establish a correspondence between instructions circulating on the network and assigned to at least one application stored in the embedded system, and instructions information exchange between said network interface means and said application, and in that it comprises the following phases:
  • the invention also relates to a method of activating at least one application located in a smart card connected to a terminal, called local, provided with a reader of said smart card, by means of a browser. , characterized in that it comprises at least the following phases: a / a first preliminary phase consisting in implanting, in said smart card, a first specific piece of software, forming an interface with at least said applications, recorded in the smart card chip; b / a second preliminary phase consisting in installing, in the terminal, a second specific piece of software forming an interface with at least said browser;
  • said first and second pieces of specific software also comprise at least one pair of first paired software entities, each of said entities cooperating with one another so as to allow the establishment of an exchange session bidirectional data between said terminal and said smart card, so that said smart card offers the functionality of an information server;
  • a third preliminary phase consisting of implanting in said smart card a second software entity capable of interpreting a sequence of instructions and translating it into a sequence of orders, said second software entity cooperating with said applications and said second specific piece of software;
  • FIG. 1A and 1B schematically illustrate the hardware and logic architectures, respectively, of an example application system based on smart card according to the known art,
  • FIG. 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 an exchange between terminal and smart card in the form of a menu page in "HTLM" language
  • - Figure 4 illustrates in a simplified way the logical architecture of a system in which the smart card comprises intelligent agents
  • FIG. 5A to 5D illustrate architectures of systems according to the invention, according to several embodiments, in which the smart card comprises intelligent agents translating scripts;
  • FIG. 6 illustrates an example of a form transmitted to the smart card by the terminal.
  • FIG. 7 schematically illustrates the main phase of exchanges between a browser and a smart card according to the method of the invention.
  • OSI Open System Interconnection
  • ISO Open System Interconnection
  • a given layer offers its services to the layer immediately above it and requires other services from the layer 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.
  • FIG. 2 An example of such an architecture is shown diagrammatically in FIG. 2.
  • the elements common to FIG. 1 have the same references and will only be re-described as necessary.
  • FIG. 1 screen 5 and keyboard 6, for example.
  • FIG. 1 screen 5 and keyboard 6, for example.
  • 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 include the lower software layers Ci and C 2 , corresponding to the "physical" and "data link” layers.
  • the upper layers C 3 and C4 have also been shown, corresponding to the "network addressing"("IP”, in the case of the Internet) and "transport”("TCP") layers.
  • the upper application layer ("http”, “ftp”, "e-mail”, etc.) has not been shown.
  • the interface between the lower layers, Ci and C2, and the upper layers, C 3 and C 4 is constituted by a software layer generally called "low layer driver".
  • the upper layers, C 3 and C 4 rely on this interface and are implemented by means of libraries of specific functions or network libraries 14, with which they correspond.
  • libraries of specific functions 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. 1) to ask requests to a server 4 (FIG. 1), for consulting "WEB” pages (“HTTP” protocol), for transferring files (“FTP” protocol) or sending electronic mail (“e-mail” protocol), in a completely classic way.
  • HTTP HyperText Transfer Protocol
  • FTP File Transfer Protocol
  • e-mail electronic mail
  • the terminal 1 also includes a card reader 3, integrated or not.
  • the card reader also includes two layers bass, CCi (physical layer) and CC 2 (data link layer), playing a similar role to layers Ci and C 2 .
  • the software interfaces with the layers CCi and CC2 are described, for example, by the specification "PC / SC"("part 6, service provider").
  • the layers themselves, CCi and CC2 are in particular described by ISO standards 7816-1 to 7816-4, as has been recalled.
  • An additional software layer 16 forms the interface between the application layers (not shown) and the lower layers, CCi and CC2.
  • 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 (“READ "), WRITE, CLOSE, etc.
  • OPEN OPEN
  • READ READ
  • WRITE WRITE
  • CLOSE CLOSE
  • CCai physical layer
  • CCa 2 data link layer
  • a first characteristic provision is made, on either side, that is to say in the terminal 1 and in the smart card 2a, two layers of specific protocols: 13 and 23a, respectively, corresponding to means network interface.
  • the specific layer 13 interfaces with the "low layer drivers” 15, with the libraries 14 of the network layers, C 3 and C4, and with the protocol layers of the card reader 3, that is to say the lower layers, CCi and CC 2 , via the multiplexing layer 16.
  • the specific layer 13 allows the transfer network packets from and to the smart card 2a.
  • it adapts existing applications such as the Internet browser 10 (FIG. 2), electronic mail, etc., for uses using the smart card 2a.
  • a module, 130 or 230a for transferring information blocks between the layers 13 and 23a, via the conventional layers CCi, CC 2 , CCai and CCa 2 ; - 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.
  • level two data link layers
  • CC2 and CCa 2 ensure the exchange between the smart card 2a and the terminal 1.
  • These layers are responsible for the detection and possible correction of transmission errors .
  • Different protocols can be used, and as non-exhaustive examples the following: - the ETSI GSM 11.11 recommendation;
  • HDLC High-Level Data Link Control procedure
  • the ISO 7816-3 protocol will preferably be used, in block mode.
  • each protocol layer is associated with a certain number of primitives which allow the exchange of data between layers of the same level and from one layer to another.
  • the primitives associated with the layer of level two are of the type "data request” ("Data .request”) and “sending of data” by the card (“Data .response”), as well as “ data confirmation "(” jData.co.n.fir-71 "), 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, as will be shown with regard to FIG. 3. They also allow the establishment of a configuration suitable for the transmission and / or reception of data packets.
  • the layers include three separate entities.
  • the first layer, 130 or 230a is essentially constituted by a software multiplexer. It allows the exchange of information between the smart card 2a and the host terminal 1, in the form of protocol data units. It plays a role similar to that of a data packet switch. These units are issued or received via level 2 layer (data link layer).
  • This particular communication protocol makes it possible to put at least one pair of "intelligent agents" into communication.
  • the first agent of each pair, 132 is located in layer 13, on the terminal side 1, the second, 232a, is located in layer 23i, 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 6535). This identifier is used, for example, in a protocol data unit constituting a destination reference and a source reference.
  • agents of the "server” type which are identified by a fixed reference
  • agents of the "client” type which are identified by a variable reference, delivered by the management module. configuration, 130 or 230a.
  • 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:
  • agent who initiates a session
  • agent who receives a session request.
  • Intelligent agents are used to exchange data (hypertext for example), but also to trigger network transactions.
  • the configuration management modules, 131 and 231a can be assimilated, as indicated, to particular intelligent agents.
  • the module 131 on the host terminal side 1, manages in particular information relating to the configuration of this terminal (operating modes), list of the other agents present, etc.
  • the module 231a on the smart card side 2a, has similar functions. These two agents can be put in communication with each other to establish a session.
  • 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 2i 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 Location") defining a loopback on the terminal 1 itself, and not a pointing on an external server .
  • 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 port number.
  • FIG. 3 schematically illustrates this process.
  • the smart card 2a in response to the request from the browser 10, the smart card 2a has a page P in "HTML" language, page displayed for example on the display member 5 of the terminal 1.
  • the page P which we will describe as reception, can display, in the usual way, different graphic or text elements, but includes at least a certain number of hyperlinks to external servers, Hl ⁇ , Hl 2 ⁇ ••• / Hl ⁇ , at i and n being arbitrary numbers, n represents the maximum number of possible choices. It naturally depends on the smart card 2a inserted in the reader 3, and on the maximum number n of application A ⁇ (FIG. 1B) present on this card. The choices presented may depend on the rights which are granted to the owner of the smart card 2a: subscription subscribed to services, level of authorization, etc.
  • the process described uses all or part of the standard communication layers (not shown), as well as the specific layers, 13 and 23a.
  • Each hyperlink points to an external "URL” resource.
  • the structure of the "URL” can be as follows: http: //127.0.0.1.8081/www.NOM.com/index.html (2), in which 127.0.0.1 is the "IP” address and 8081 is the port number, "NOM.com” the name of a website for a company or other entity, in accordance with the rules of naming usually used, and "index.html” the home page of this site.
  • suffix ".corn” a priori used for commercial organizations, there are other suffixes, such as “.fr", ".gov”, etc. , which are associated with the location of the website or the nature of the organization.
  • FIG. 4 illustrates in a simplified manner the logical architecture of a system of which the smart card 2a comprises intelligent agents, of which only two have been shown: an intelligent agent of the type not precisely defined 232a ⁇ and an intelligent agent 232a ⁇ , type called "WEB".
  • the logical stack comprises, the lower protocol layers, referenced 200a, meeting ISO standards 7816-3 (FIG. 2: CCai and CCa 2 ), the "APDU" command manager 201a, and the packet multiplexer 230a, the latter being interface to intelligent agents, in particular the intelligent agent "WEB" 232a ⁇ -
  • the first stack includes the organs 11 (FIG. 2: Ci and C 2 ) for accessing the network (OSI standards 1 and 2) and the "TCP / IP" protocol layers (FIG. 2: C 3 and C4), referenced 100 These latter layers are interfaced with the "WEB" browser 10.
  • the other stack includes the lower protocol layers, referenced 101, meeting the ISO 7816-3 standards (FIG. 2: Ci and C 2) the order manager 101 "APDU" and the packet multiplexer 102, the latter being 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 201a also interfaces with one or more level layers applications, which we will simply call 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.
  • the applications, Ai to An 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 according to the known art.
  • WEB offered by the smart card, includes application interface means, corresponding to a mechanism similar to the so-called “CGI” function (for "Common Gateway
  • 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
  • an "HTTP" request for a "URL” address of the type:
  • host refers to a host system (generally remote)
  • WEB writeback server
  • command script of the "CGI” type named "xxx” and present in the " cgi-bin "from this host system.
  • name of the directory can be a priori arbitrary, by convention, it is the name given to the directory storing scripts of type "CGI”.
  • a script is a series of instructions from the operating system of the host system, the final result of which is transmitted to the "WEB" browser issuing the above request.
  • Different languages can be used to write this script, for example the language "PERL” (registered trademark).
  • the request is usually displayed on a computer screen in the form of a form included in a "HTLM” page.
  • the "HTLM” language allows you to translate a form into a "URL” address.
  • the form includes one or more fields, mandatory or not, which are filled in by a user using the usual input methods: keyboard for text, mouse for checkboxes or so-called “radio” buttons, etc.
  • the content of the form (as well as possibly so-called “hidden” information and instructions) is sent to the "WEB” server.
  • the "HTLM” code on the page describes the physical structure of the form (frame, graphics, color, and any other attribute), as well as the structure of the data fields to be entered (name, length, type of data, etc.).
  • Transmission can take place in two main types of formats.
  • a first format uses the so-called "POST” method and a second uses the so-called "GET” method.
  • Format type information is present in the code of the form page.
  • the example form has two numeric fields, Ch ⁇ and Ch2, entitled “Certificate” and Debit “, as well as two buttons “radio”, i> ⁇ and b2, entitled “Submit” and “Reset”, respectively. It also includes, on the right of the figure, the usual function called "elevator”. This form is displayed on the display screen (figure 1: 5) of terminal 1.
  • a third step the user completes the two numeric fields, C ⁇ i and Ch 2 .
  • both fields must be completed.
  • Ji the user transmits the content of the form.
  • £ 2 it erases all the data displayed, either to correct them or to enter a new series.
  • the data is sent and received by the network agent 132. It is recalled that the "WEB" browser is not necessarily located in the local terminal 1. It can be either in this one ci or located in any system connected to the network
  • 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 card at bullet 2a. They then pass through the protocol layers 200a, the "APDU” order manager 201a, the packet multiplexer 230a to be received by the agent.
  • the data sent to the "WEB” agent 232a ⁇ is transported conventional 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 Ai to A n .
  • the packet multiplexer 230a is seen by the "APDU” order manager 201a as an ordinary "CGA” application.
  • the "HTTP" request is then 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 an application particular, for example "pme” in the case of the example described.
  • the full path is therefore, in this case "cgi-smart / pme”.
  • the above entity designates a particular script associated with an equally particular application ("PME" in this case).
  • the script is then 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 agent capable of translating all the scripts present in the smart card 2a; c / 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, from select applications, from Ai to A, but also to offer an intelligent agent type interface. It is therefore capable, according to one of the characteristics of the method, of communicating with all the intelligent agents of the system (via sessions), whether these agents are located in the terminal 1 or the smart card 2a.
  • FIG. 5A illustrates an example of architecture for which the translating agents are of the "ATSD" type. They are referenced ATS1 to ATSn and associated with the applications Ai to A - The selected application being assumed to be the application A ⁇ , the session is established between the "WEB" agent 232a ⁇ and the agent ATS ⁇ .
  • a script translator agent generates a sequence of "APDU” orders.
  • a session is opened between the translating 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” A ⁇ 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 of the "CGA” A ⁇ application are transmitted to the "APDU” order manager 201a, to the "APDU” agent 2010a, then again to the ATS agent ⁇ (and more generally to the script translator agent).
  • the script translator for example the ATS ⁇ agent in the example in FIG. 5A, creates a page in "HTML" language and transmits it via the different layers borrowed by the initial request, but in reverse, this to be presented on the display screen 5 ( Figure 1).
  • the smart card 2a must be able to continue to be used in conjunction with a conventional terminal.
  • the smart card no longer plays the role of "WEB” server and the "intelligent agents” functionalities are not used. It is the same for the specific layer 23a ( Figure 2).
  • These various components remain “transparent” vis-à-vis the exchanges between terminal and smart card. These exchanges are carried out in a purely conventional manner, by exchange of "ADPU" orders between an application located in the terminal and an application located in the smart card, as has been explained with reference to FIGS. 1A and 1B.
  • FIG. 7 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) of a request
  • HTTP 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 a page "HTLM”, referenced PR.
  • the answer could also consist in the transmission of a file, or a piece of software or "Applet”.
  • the system can accommodate unconventional applications. By this is meant applications which do not need to exchange "APDU" orders.
  • This type of application which does not meet the aforementioned ISO standards, is not accessible by conventional terminals, but is, without requiring any additional modification of their architecture, by terminals in accordance with the invention, that is to say that is to say comprising the specific layer 13.
  • FIG. 5B schematically illustrates an example of an architecture conforming to this additional variant.
  • the applications have been referenced A'i to A ' ⁇ .
  • ATSDA Dedicated and Autonomous Script Translator Agent
  • this agent can be either the "WEB” 232al agent, with double capacity, or an "ATSDA” agent, unique for the whole system, or the "APDU” agent 2010a, with a double capacity, or again, as illustrated in FIG. 5B, a plurality of "ATSDA” agents, referenced ATS'l to ATS'n.
  • each "ATSDA” agent is associated with a single application.
  • the terminal 1 does not undergo any modification of architecture and it can communicate either with smart cards comprising non-conventional applications or with entirely conventional smart cards.
  • the smart card 2a itself comprises the conventional protocol layers, it is possible to store therein, both conventional applications, of the "CGA" type, accessible according to the process explained with reference to FIG. 5A or by a conventional terminal, and unconventional applications, accessible only by the variant of the method which has just been explained.
  • FIG. 5C only the components of the smart card part 2a have been shown, it being understood that the terminal must necessarily have an architecture in accordance with the invention (see FIG. 2, for example) in order to be able to benefit from these advantageous features. It is indeed necessary to use the "WEB" server function offered by the smart card 2a, according to one of the characteristics of the method of the invention. To do this, the terminal must therefore include the specific layer 13 ( Figure 2).
  • the general architecture of the smart card 2a is similar to that described with reference to FIG. 5A, and the common components will only be re-described as necessary.
  • a piece of software 7 the function of which is to monitor downloads. It should be understood that the "downloader” 6 and “download monitoring” 7 functions can be confused by modifying the piece of software 6.
  • the additional piece of software 7 "warns" the order manager "APDU” when it detects the download of a new application, the Aj application in this case. The latter then saves this modification. He can therefore now send the Aj application.
  • the specific layer is updated, in particular the component 231a, configuration manager of the smart card 2a. It is further necessary to update the translating agent "ATS", “ATSD”, or “ATSDA”, as the case may be, if it is a single agent, or to create a new ATSj, associated with the new Aj application. The information required for this update is downloaded at the same time as the new Aj application.
  • Updates or deletions of applications can be done using the same mechanism.
  • the smart card 2a When the smart card 2a is again connected to a terminal according to the invention, the latter can be notified of the new possibilities of the smart card or of modifications, by sending a "HTLM" page, similarly to what has been described with reference to FIG. 5A.
  • a specific application is provided in the smart card 2, which will be referenced by AQ convention, associated with a dedicated script translator ATSo.
  • the translation can also be carried out centrally, as previously indicated ("WEB" agent, etc.).
  • This Ao application is assigned the role of downloading and monitoring downloaded, modified or deleted applications.
  • 1 • ATSo translator agent interacting with the Ao application, generates a PMAJ page, which will be called update page.
  • This can be in the form of a menu indicating the applications present in the smart card 2a, with possibly information on their version and / or the date of downloading or modification, menu transmitted automatically or on request. of browser 10 of terminal 1.
  • the downloading, updating or deletion of applications can be carried out directly from the browser 10, using the "WEB" server function of the smart card 2a.
  • the necessary data are transmitted by exchanges between the terminal 1 and the smart card 2a, according to the usual process.
  • the Ao application then takes care of updating the configuration information of the smart card 2a, in particular by interacting on the "APDU" order manager (not shown in FIG. 5D), as well as possibly updating or create the script translator associated with a new application, or a modified application.
  • the "APDU" order manager can then send the new downloaded application.
  • the Ao application and its script translator therefore constitutes a complete service for updating applications, an additional service offered by the smart card 2a. It should be clear that this update service remains compatible with the existing one.
  • the smart cards 2a can continue to be downloaded from an external device EXT, on the other hand, the applications downloaded or updated by means of the browser 10, can be of a conventional "CGA" or unconventional type. In the first case, they remain compatible with the terminals of the known art.
  • the invention applies in particular to an electronic purse service, but cannot in any case be limited to this single application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un procédé d'activation d'une (Ai) des applications (A1-An) d'un système embarqué, notamment d'une carte à puce (2a) connectée à un terminal (1), muni d'un lecteur, par l'intermédiaire d'un navigateur de type "WEB". Le terminal (1) et la carte à puce (2a) comprennent chacun, outre des couches protocolaires conventionnelles (101-102), répondant aux normes ISO 7816, une couche 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". En outre, la carte à puce (2a) comprend des agents intelligents (ATS1-ATSn), dits traducteurs de scripts, interagissant avec les applications (A1-An), ce qui permet d'activer une application sélectionnée (Ai), à l'aide d'ordres conventionnels, répondant aux normes ISO 7816. Dans une variante de réalisation, on prévoit des dispositions pour une mise à jour dynamique de la carte à puce (2a), notamment à partir du navigateur. L'invention concerne aussi le système embarqué correspondant.

Description

SYSTEME EMBARQUE POSSEDANT DES MOYENS D'INTERFACE
DE RESEAU, ET PROCÉDÉ D'ACTIVATION D'APPLICATIONS
LOCALISÉES DANS CE SYSTEME EMBARQUE
La présente invention concerne un système embarqué possédant des moyens d'interface de réseau, et un procédé d'activation d'applications localisées dans ce système embarqué.
Le procédé selon 1 ' invention est plus particulièrement concerné par une station d'utilisateur munie d'un lecteur de carte à "puce" et connectée au réseau Internet.
Dans le cadre de l'invention, le terme "station d'utilisateur" doit être compris dans un sens général. La station 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".
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'exemples, 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 l peut être mis en communication avec des serveurs connectés au réseau RI, dont un seul, 4, est illustré sur la figure 1. 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. 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.
Le navigateur permet d'accéder à diverses applications réparties sur l'ensemble du réseau RI, généralement selon un mode "client-serveur".
Habituellement, les communications sur les réseaux s'effectuent conformément à des protocoles répondant à des standards comprenant plusieurs couches logicielles superposés. Dans le cas d'un réseau RI de type Internet, les communications s'effectuent selon des protocoles spécifiques à ce type de communications, qui seront détaillés ci-après, mais qui comprennent également plusieurs couches logicielles. Le protocole de communication est choisi en fonction de l'application plus particulièrement visée : interrogation de pages "WEB", transferts de fichiers, courrier électronique (e-mel, ou "e-mail" selon la terminologie anglo-saxonne), forums ou "news", etc.
L'architecture logique du système comprenant un terminal, un lecteur de carte à puce et la carte à puce, est représentée schématiquement par la figure 1B. 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é 201. 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± , ..., A± , ..., An ; n étant le nombre maximum d'applications présentes sur la carte à puce 2.
Une application "cardlet", A± , 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é "APDϋr.co-7--7iand" 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=l) .
Lorsque la carte à puce 2 inclue plusieurs applications distinctes, comme illustré sur la figure 1B, 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 A± et le dialogue avec celle-ci s ' effectue par échanges d ' ordres "APDU" . On suppose que les applications A± 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 1B, cette dernière peut se voir dévolues diverses fonctions.
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 1 ' 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.
L'invention a donc notamment pour objet un procédé d'activation d'applications localisées dans une carte à puce par un navigateur du type dit "WEB", permettant de palier les inconvénients de l'art connu, dont certains viennent d'être rappelés.
Selon une 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", 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 appareillés dans les couches de communication spécifiques respectives associées au terminal et à la carte à puce. Selon le procédé de l'invention, il s'établit des sessions entre agents appareillés.
Selon une autre caractéristique, le procédé de l'invention rend possible l'activation d'applications de type conventionnel, c'est-à-dire du type "CGA" 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".
Selon une autre caractéristique, le procédé de l'invention rend possible la gestion d'applications d'un type non conventionnel, sans devoir modifier l'architecture du système. Selon une autre caractéristique, le procédé de
1 ' invention permet un téléchargement dynamique de nouvelles applications dans la carte à puce, de type traditionnel ou non, ainsi que la mise à jour ou la suppression d'une ou plusieurs applications.
L'invention a donc pour objet 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
-des moyens d'interface d'application, agencés pour établir une correspondance entre des instructions circulant sur le réseau et affectées à au moins une application stockée dans le système embarqué (ces instructions émanant notamment d'un navigateur ou destinées à un navigateur), et des instructions d'échange d • information entre lesdits moyens d' interface de réseau et ladite application.
L'invention concerne aussi un procédé pour activer au moins une application stockée dans 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 utilise un système embarqué comprenant 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 des moyens d'interface d'application, agencés pour établir une correspondance entre des instructions circulant sur le réseau et affectées à au moins une application stockée dans le système embarqué, et des instructions d' échange d* information entre lesdits moyens d'interface de réseau et ladite application, et en qu'il comprend les phases suivantes :
-établir une session d'échange d'information entre le terminal et le système embarqué pour acheminer au système embarqué une requête d'activation de ladite au moins une application, par l'intermédiaire desdits moyens d' interface de réseau appariés ;
-effectuer une correspondance entre ladite requête et des instructions d'échange d'information entre lesdits moyens d'interface de réseau et ladite application, au moyen desdits moyens d'interface d'application ;
-effectuer une correspondance entre une réponse à ladite requête, émise par l'application, et des instructions de réponse émises sur le réseau, au moyen desdits moyens d'interface d'application.
L'invention a aussipour objet un procédé d'activation d'au moins une application localisée dans une carte à puce connectée à un terminal, dit local, muni d'un lecteur de ladite carte à puce, par l'intermédiaire d'un navigateur, caractérisé en ce qu'il comprend au moins les phases suivantes : a/ une première phase préliminaire consistant à implanter, dans ladite carte à puce, une première pièce de logiciel spécifique, formant interface avec au moins lesdites applications, enregistrée dans la carte à puce ; b/ une deuxième phase préliminaire consistant à implanter, dans le terminal, une seconde pièce de logiciel spécifique formant interface avec au moins ledit navigateur;
- en ce que lesdites première et seconde pièces de logiciel spécifique comprennent en outre au moins une paire de premières entités logicielles appariées, chacune desdites entités coopérant 1 'une avec 1 •autre de manière à permettre l'établissement d'une session d'échanges de données bidirectionnels entre ledit terminal et ladite carte à puce, de manière à ce que ladite carte à puce offre la fonctionnalité d'un serveur d ' information ;
- en ce qu'il est procédé à une troisième phase préliminaire consistant en 1 ' implantation dans ladite carte à puce d'une deuxième entité logicielle apte à interpréter une suite d'instructions et à la traduire en une suite d'ordres, ladite deuxième entité logicielle coopérant avec lesdites applications et ladite seconde pièce de logiciel spécifique ;
- et ce qu'il comprend au moins les étapes suivantes :
1/ établissement d'une session d'échanges de données entre ledit terminal et ladite carte à puce, par l'intermédiaire d'une desdites paires de premières entités logicielles appariées, de manière à transmettre une requête pour atteindre l'une desdites applications ;
2/ réception de ladite requête par l'une desdites deuxièmes entités logicielles, interprétation d'une desdites suites d'instructions, ladite suite d'instructions étant associée à ladite application à accéder, et transmission desdits ordres traduits à cette application, de manière à l'activer ; et 3/ élaboration et transmission audit navigateur, par l'intermédiaire de ladite deuxième entité logicielle, et via lesdites première et seconde pièces de logiciel spécifique, d'une réponse à ladite requête.
L'invention sera mieux comprise et d'autres caractéristiques et avantages apparaîtront à la lecture de la description qui suit en référence aux figures annexées, parmi lesquelles :
- les figures 1A et 1B 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 un échange entre terminal et carte à puce sous forme d'une page de menu en langage "HTLM" ; - la figure 4 illustre de façon simplifiée l'architecture logique d'un système dans lequel la carte à puce comprend des agents intelligents ;
- les figures 5A à 5D illustrent des architectures de systèmes conformes à l'invention, selon plusieurs modes de réalisation, dans lesquels la carte à puce comprend des agents intelligents traducteurs de scripts ;
- la figure 6 illustre un exemple de formulaire transmis à la carte à puce par le terminal ; et
- la figure 7 illustre schématiquement les principales phase d'échanges entre un navigateur et une carte à puce selon le procédé de 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 oeuvre, il apparaît tout d'abord intéressant 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 l' "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édiaire, 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, une ou 1 ' autre de ces couches peuvent être inexistantes .
Dans un environnement de type Internet, les couches sont au nombre de cinq, et de façon plus précise, en allant de la couche supérieure à la couche inférieure : la couche d'applications ("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 une serveur "WEB". Un exemple d'une telle architecture est représenté schématiquement sur la figure 2. Les éléments communs à la figure 1 portent les mêmes références et ne seront redécrits 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 1 : é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 à l'art 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 oeuvre par 1 ' 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 oeuvre au moyen de bibliothèques dites de "sockets".
Cette organisation permet à un navigateur 10 (figure 1) de poser des requêtes vers un serveur 4 (figure 1) , 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, CCi (couche physique) et CC2 (couche de lien de données), jouant un rôle similaire aux couches Ci et C2. Les interfaces logicielles avec les couches CCi et CC2 sont décrites, par exemple, par la spécification "PC/SC" ("part 6, service provider") . Les couches elles-mêmes, CCi 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, CCi 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, correspondant à des moyens d'interface de réseau.
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, CCi 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 oeuvre 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 CCi, 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=l ;
- 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" ("Data .request") et "envoi de données" par la carte ( "Data .response" ) , ainsi que "confirmation de données" ("jData.co.n.fir-71") , 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", comme il sera montré au regard de la figure 3. 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 1 'é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 communications 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 23i, 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 oeuvre 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 6535) . 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, 130 ou 230a.
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 1, gère notamment des informations relatives à la configuration de ce terminal (modes de fonctionnement) , liste des autres agents présents, etc. Le module 231a, côté carte à puce 2a, a des fonctions analogues. Ces deux agents peuvent être mis en communication l'un avec l'autre pour établir une session.
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 2i est "adressée" par le navigateur 10. Elle lui transmet alors une page de type "WEB" en langage "HTML", un "applet" ou tout 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 Location") 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 cet "URL" est habituellement la suivante : http://127.0.0.1:8080 (1), dans la quelle 127.0.0.1 est l'adresse "IP" de rebouclage et 8080 est le numéro de port.
La figure 3 illustre schématiquement ce processus.
On suppose sur cette figure, qu'en réponse à la requête du navigateur 10, la carte à puce 2a présente une page P en langage "HTML", page affichée par exemple sur l'organe de visualisation 5 du terminal 1. La page P, que l'on qualifiera d'accueil, peut afficher, de façon usuelle, différents éléments graphiques ou textes, mais comporte au moins un certain nombre d'hyperliens vers des serveurs externes, Hl± , Hl2 ι •••/ Hl ± , à i et n étant des nombres arbitraires, n représente le nombre maximum de choix possibles. Il est fonction naturellement de la carte à puce 2a insérée dans le lecteur 3 , et du nombre maximum n d'application A± (figure 1B) présentes sur cette cartes. Les choix présentés peuvent dépendre des droits qui sont accordés au possesseur de la carte à puce 2a : abonnement souscrit à des services, niveau d'habilitation, etc. Le processus décrit utilise tout ou partie des couches de communication standards (non représentées) , ainsi que les couches spécifiques, 13 et 23a.
Chaque hyperlien, par exemple l'hyperlien Hl± , pointe sur une ressource "URL" externe. A titre d'exemple, la structure de 1 ' "URL" peut être la suivante : http://127.0.0.1.8081/www.NOM.com/index.html (2) , dans laquelle 127.0.0.1 est l'adresse "IP" et 8081 est le numéro de port, "NOM.com" le nom d'un site Internet d'une société ou autre entité, conformément aux règles de nommage habituellement utilisées, et "index.html" la page d'accueil de ce site. En lieu et place du suffixe ".corn", a priori utilisé pour des organisations à caractère commercial, il existe d'autres suffixes, tels ".fr", ".gov", etc. , qui sont associés à la localisation du site Internet ou à la nature de l'organisme.
La figure 4 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 232aι 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" 201a , 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, 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 101 d'ordres "APDU" et le multiplexeur de paquets 102, 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" 201a 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, Ai à An , ne nécessitent pas d'être ré-écrites et sont mises en oeuvre telles quelles.
Selon une autre caractéristique de l'invention, ces applications restent accessibles à un terminal de type conventionnel, c'est-à-dire conforme à l'art connu.
En d'autres termes, la compatibilité avec l'existant, en ce qui concerne le mode d'échanges avec les applications présentes sur la carte à puce, doit subsister. On doit toute fois remarquer que, dans ce cas, le terminal (conventionnel) n'est pas banalisé : il doit être adapté aux applications.
Pour répondre à ces exigences, la fonction serveur
"WEB", offerte par la carte à puce, inclut des moyens d'interface d'application, correspondant à un mécanisme similaire à la fonction dite "CGI" (pour "Common Gateway
Interface") implantée dans les serveurs "WEB" classique. Avant de décrire un exemple d'architecture conforme à l'invention, permettant de réaliser une fonction de ce type, au sein même de la carte à puce, il est utile de rappeler les principales caractéristiques d'un mode de fonctionnement "CGI".
Le "CGI" est une spécification de mise en oeuvre, depuis un serveur "WEB", d'applications écrites pour les systèmes d'exploitation "UNIX" (marque déposée), "DOS", ou "WINDOWS" (marque déposée) . A titre d'exemple, pour le système d'exploitation "UNIX", la spécification est "CGI 1.1" et pour le système d'exploitation "WINDOWS 95", la spécification est "CGI 1.3".
Toujours à titre d'exemple, une requête "HTTP" pour une adresse "URL", du type :
"http://www.host.com/cgi-bin/xxx.cgi" (3),
dans laquelle "host" se réfère à un système hôte (généralement éloigné) , est interprétée par un serveur "WEB" comme l'exécution d'un script de commande, de type "CGI" nommé "xxx" et présent dans le répertoire "cgi-bin" de ce système hôte. Bien que le nom du répertoire puisse être a priori quelconque, par convention, c'est le nom donné au répertoire stockant les scripts de type "CGI". Un script est une suite d ' instructions du système d ' exploitation du système hôte dont le résultat final est transmis au navigateur "WEB" émetteur de la requête précitée. Différents langages peuvent être utilisés pour écrire ce script, par exemple le langage "PERL" (marque déposée) .
De façon pratique, la requête est habituellement affichée sur un écran informatique sous la forme d'un formulaire compris dans une page "HTLM". Le langage "HTLM" permet de traduire un formulaire en une adresse "URL". Le formulaire comporte un ou plusieurs champs, obligatoires ou non, qui sont remplis par un utilisateur à l'aide des moyens de saisie habituels : clavier pour le texte, souris pour les cases à cocher ou les boutons dits "radio", etc. Le contenu du formulaire (ainsi qu'éventuellement des informations et instructions dites "cachées") est émis à destination du serveur "WEB". Le code "HTLM" de la page décrit la structure matérielle du formulaire (cadre, graphisme, couleur, et tout autre attribut) , ainsi que la structure des champs de données à saisir (nom, longueur, type de données, etc.).
La transmission peut s'effectuer selon deux types de formats principaux. Un premier format utilise la méthode dite "POST" et un second la méthode dite "GET". Une information de type de format est présente dans le code de la page formulaire.
Ce mécanisme n'est cependant pas directement transposable à une carte à puce, même si celle-ci offre la fonctionnalité serveur "WEB" conformément à l'une des caractéristiques de l'invention.
On va maintenant décrire un exemple d'architecture permettant d'activer une application quelconque, de type conventionnel, via un serveur "WEB" sur la carte à puce, par référence à la figure 5A.
Lors d'une première étape, un utilisateur (non représenté) invoque depuis son navigateur "WEB" (figure 4 :10) une l'adresse "URL" qui peut se présenter de la façon suivante :
"http://@carte:8080/pme.html" (4),
dans laquelle "écarte" est une adresse IP de la carte à puce (par exemple l'adresse de rebouclage "127.0.01" décrite en regard de la figure 3 : voir formule (1)). Pour fixer les idées, et à titre d'exemple, "pme.htlm" est une page en langage "HTLM" relative à une application particulière offerte par la carte à puce, que l'on appellera ci-après "porte-monaie électronique" ou "PME". Lors d'une deuxième étape, de la manière décrite précédemment, la carte à puce renvoie une page "HTLM" qui peut se présenter sous la forme illustrée par la figure 6.
Outre divers attributs graphiques (cadre, graphisme, etc.) et informations (titre, libellés, etc) , le formulaire de l'exemple comporte deux champs numériques, Ch± et Ch2 , intitulés "Certificat" et Débit", ainsi que deux boutons "radio", i>ι et b2 , intitulés "Soumettre" et "RAZ", respectivement. Il comporte en outre, sur la droite de la figure, la fonction habituelle dite "d'ascenceur". Ce formulaire s'affiche sur l'écran de visualisation (figure 1 : 5) du terminal 1.
Lors d'une troisième étape l'utilisateur renseigne les deux champs numériques, Cήi et Ch2. Dans cet exemple, les deux champs doivent être obligatoirement renseignés. En cliquant sur Ji, l'utilisateur transmet le contenu du formulaire. En cliquant sur £2, il efface toutes les données affichées, soit pour les corriger, soit pour en saisir une nouvelle série.
Si l'utilisateur clique sur b± , les données sont émises et reçues par l'agent réseau 132. Il est rappelé que le navigateur "WEB" n'est pas obligatoirement situé dans le terminal local 1. Il peut être indifféremment dans celui-ci ou localisé dans un système quelconque connecté au réseau
Internet RI (voir figure 4, par exemple). 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és 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 Ai à 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 alors 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 "pme" dans le cas de l'exemple décrit. Le chemin complet est donc, en l'occurrence "cgi-smart/pme" .
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 ("PME" en l'occurrence).
Lors d'une quatrième étape, le script est alors 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 script unique capable de traduire l'ensemble des scripts présents dans la carte à puce 2a ; c/ par un agent de script dédié que l'on appellera "ATSD" ci-après (un 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 Ai à A , 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 5A illustre un exemple d'architecture pour laquelle les agents traducteurs sont du type "ATSD". Ils sont référencés ATS1 à ATSn et associés aux applications Ai à A - L'application sélectionnée étant supposée être l'application A± , 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" A± (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" A± sont transmises au gestionnaire d'ordres "APDU" 201a, à l'agent "APDU" 2010a, puis de nouveau à l'agent ATS± (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 ATS± dans l'exemple de la figure 5A, é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 1) .
Les différents cheminements sont représentés symboliquement sur la figure 5A par des traits pleins reliant les blocs fonctionnels ou en pointillés à l'intérieur de ces blocs.
Selon un autre aspect du procédé de l'invention, la carte à puce 2a doit pouvoir continuer à être utilisée en conjonction avec un terminal conventionnel. La carte à puce ne joue plus alors le rôle de serveur "WEB" et les fonctionnalités "agents intelligents" ne sont pas utilisées. Il en est de même de la couche spécifique 23a (figure 2) . Ces différents composants restent "transparents" vis-à-vis des échanges entre terminal et carte à puce. Ces échanges s'effectuent de façon purement conventionnelle, par échange d'ordres "ADPU" entre une application localisée dans le terminal et une application localisée dans la carte à puce, comme il a été explicité en regard des figures 1A et 1B.
La figure 7 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 "HTLM", 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" . Selon une autre caractéristique du procédé selon l'invention, et dans une variante de mise en oeuvre supplémentaire, le système peut accommoder des applications non conventionnelles. On entend par là des applications qui n • ont pas besoin d •échanges d * ordres "APDU" . Ce type d'application, ne répondant pas aux normes ISO précitées n'est pas accessible par des terminaux classiques, mais l'est, sans nécessiter aucune modification supplémentaire de leur architecture, par des terminaux conformes à l'invention, c'est-à-dire comportant la couche spécifique 13.
La figure 5B illustre schématiquement un exemple d'une architecture conforme à cette variante supplémentaire. Les applications ont été référencées A'i à A'^.
Les premières étapes du procédé selon cette variante supplémentaire sont similaires sinon identiques aux phases précédemment décrites en regard de la figure 5A. Par contre la traduction du script est réalisée par un agent intelligent spécifique que l'on appellera "Agent Traducteur de Script Dédié et Autonome" ou "ATSDA" . on doit bien comprendre que, comme précédemment, cet agent peut être, soit l'agent "WEB" 232al, doté d'une double capacité, soit un agent "ATSDA", unique pour tout le système, soit l'agent "APDU" 2010a, doté d'une double capacité, soit encore, comme illustré sur la figure 5B, une pluralité d'agents "ATSDA", référencés ATS'l à ATS'n. Dans ce cas, chaque agent "ATSDA" est associé à une seule application.
Comme il est aisé de constater sur la figure 5B, les échanges de données entre le terminal 1 et la carte à puce 2a s'effectuent directement entre les couches spécifiques 13 et 23a. il n'y a donc plus de liaisons entre les applications et un gestionnaire d'ordres "APDU". Cependant, dans une variante supplémentaire, ce dernier peut subsister, ainsi que les couches protocolaires conventionnelles. Il en est de même en ce qui concerne le terminal 1. Ces composants ont été représentés en traits pointillés. Cette disposition présente plusieurs avantage. D'une part, le terminal 1 ne subit aucune modification d'architecture et il peut communiquer indifféremment avec des cartes à puce comportant des applications non conventionnelles ou avec des cartes à puce entièrement conventionnelles. D'autre part, si la carte à puce 2a comprend elle-même les couches protocolaires conventionnelles, on peut y stocker, à la fois des applications conventionnelles, de type "CGA", accessibles selon le procédé explicité en regard de la figure 5A ou par un terminal conventionnel, et des applications non conventionnelles, accessibles uniquement par la variante du procédé qui vient d'être explicitée.
Selon une autre caractéristique du procédé selon l'invention, et dans une variante de mise en oeuvre supplémentaire, illustrée schématiquement par la figure 5C, il est possible de télécharger dynamiquement de nouvelles applications dans la carte à puce 2a. Il est également possible de mettre à jour les applications existantes ou d'en supprimer, ce toujours de façon dynamique, ce que ne permettent pas les cartes à puce de l'art connu. Pour ces dernières, il est nécessaire de modifier le terminal pour tenir compte des modifications effectuées dans la carte à puce.
Sur la figure 5C, on n'a représenté que les composants de la partie carte à puce 2a, étant entendu que le terminal est doté obligatoirement d'une architecture conforme à l'invention (voir figure 2, par exemple) pour pouvoir bénéficier de ces fonctionnalités avantageuses. Il est en effet nécessaire d'utiliser la fonction serveur "WEB" offerte par la carte à puce 2a, selon une des caractéristiques du procédé de l'invention. Pour ce faire, le terminal doit donc comporter la couche spécifique 13 (figure 2) . L'architecture générale de la carte à puce 2a est similaire à celle décrite en regard de la figure 5A, et les composants communs ne seront re-décrits qu'en tant que de besoin.
Le problème posé est de pouvoir télécharger et enregistrer dans la carte à puce 2a, une ou plusieurs applications supplémentaires. Pour fixer les idées, on supposera que l'on veuille ajouter l'application Aj , le nombre total d'application présentes dans la carte à puce 2a devenant égal à JÎ+1. On suppose que les applications présentes, ainsi que la nouvelle application, sont de type conventionnel ("CGA") , mais des applications non conventionnelles pourraient tout aussi bien être téléchargées dans la carte à puce 2a par le même procédé.
Dans l'état de l'art, il est habituel de prévoir une pièce de logicielle 6, connue sous l'appellation anglo- saxonne "loader" et que l'on appellera ci-après "téléchargeur" . La carte à puce 2a est placée dans un dispositif électronique externe approprié, que l'on a référencé EXT, qui permet de télécharger une nouvelle application et de l'enregistrer.
Selon le procédé de l'invention, on prévoit en outre une pièce de logiciel 7, dont la fonction est de surveiller les téléchargements. On doit bien comprendre que les fonctions "téléchargeur" 6 et "surveillance de téléchargement" 7 peuvent être confondues, en modifiant la pièce de logiciel 6.
La pièce de logiciel supplémentaire 7, "avertit" le gestionnaire d'ordres "APDU" lorsqu'elle détecte le téléchargement d'une nouvelle application, l'application Aj en l'occurrence. Celui-ci enregistre alors cette modification. Il pourra donc désormais adresser l'application Aj . De même la couche spécifique est mise à jour, notamment le composant 231a, gestionnaire de configuration de la carte à puce 2a. Il est en outre nécessaire de mettre à jour l'agent traducteur "ATS", "ATSD", ou "ATSDA", selon les cas, s'il s'agit d'un agent unique, ou d'en créer un nouveau ATSj , associé à la nouvelle application Aj . Les informations nécessaires à cette mise à jour sont téléchargées en même temps que la nouvelle application Aj .
Les mises à jour ou les suppressions d'applications peuvent s'effectuer selon le même mécanisme.
Lorsque la carte à puce 2a est de nouveau connectée à un terminal conforme à l'invention, celui-ci pourra être averti des nouvelles possibilités de la carte à puce ou des modifications, par l'envoi d'une page "HTLM", de façon similaire à ce qui a été décrit en regard de la figure 5A.
Dans une variante supplémentaire encore, illustrée schématiquement par la figure 5D, on prévoit une application spécifique dans la carte à puce 2, que l'on référencera par convention AQ , associée à un traducteur de script dédié ATSo . Cependant, la traduction peut également être effectuée de façon centralisée, comme précédemment indiquée (agent "WEB", etc.). A cette application Ao, on attribue le rôle de téléchargement et de surveillance des applications téléchargées, modifiées ou supprimées. Lorsque la carte à puce 2a est connectée à un terminal 1 selon l'invention, 1 • agent traducteur ATSo , interagissant avec l'application Ao, génère une page PMAJ, que l'on appellera page de mise à jour. Celle-ci peut se présenter sous la forme d'un menu indiquant les applications présentes dans la carte à puce 2a, avec éventuellement des informations sur leur version et/ou la date de téléchargement ou de modification, menu transmis de façon automatique ou sur requête du navigateur 10 du terminal 1.
Dans une variante préférée, le téléchargement, la mise à jour ou la suppression d'applications peut s'effectuer directement à partir du navigateur 10, en utilisant la fonction serveur "WEB" de la carte à puce 2a. Les données nécessaires sont transmises par échanges entre le terminal 1 et de la carte à puce 2a, selon le processus habituel. L'application Ao se charge alors de mettre à jour les informations de configuration de la carte à puce 2a, notamment en interagissant sur le gestionnaire d'ordres "APDU" (non représenté sur la figure 5D) , ainsi éventuellement que de mettre à jour ou de créer le traducteur de script associé à une nouvelle application, ou à une application modifiée. Le gestionnaire d'ordres "APDU" peut ensuite adresser la nouvelle application téléchargée.
L'application Ao et son traducteur de script, centralisé ou non (A-PSo) , constitue donc un service complet de mise à jour des applications, service supplémentaire offert par la carte à puce 2a. Il doit être clair que ce service de mise à jour reste compatible avec l'existant. D'une part, les cartes à puce 2a peuvent continuer à être téléchargée à partir d'un dispositif extérieur EXT, d'autre part, les applications téléchargées ou mises à jour par l'i termédiaire du navigateur 10, peuvent être d'un type conventionnel "CGA" ou non conventionnel. Dans le premier cas, elles restent compatibles avec les terminaux de l'art connu.
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.
Notamment, tout en restant compatible avec les applications et normes en vigueur, elle apporte de nombreuses possibilités supplémentaires. Elle permet d'accepter également des applications d'un type nouveau, que l'on pourra appeler "natives", sans nécessiter de changements de l'architecture du terminal communiquant avec la carte à puce, à l'exception des modifications nécessaires pour qu'il devienne conforme à l'invention (couche spécifique) . 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 à 7.
L'invention s'applique notamment à un service porte- monnaie électronique, mais ne saurait en aucun cas être limitée à cette seule application.

Claims

R E V E N D I C AT I O N S
1. Procédé d'activation d'au moins une application localisée dans une carte à puce connectée à un terminal, dit local, muni d'un lecteur de ladite carte à puce, par l'intermédiaire d'un navigateur, caractérisé en ce qu'il comprend au moins les phases suivantes :
a/ une première phase préliminaire consistant à implanter, dans ladite carte à puce (2a) , une première pièce de logiciel spécifique (23a) , formant interface avec au moins lesdites applications
(AI-AJÎ) , enregistrée dans la carte à puce (2a) ; b/ une deuxième phase préliminaire consistant à implanter, dans le terminal (1) , une seconde pièce de logiciel spécifique (13) formant interface avec au moins ledit navigateur (10) ;
- en ce que lesdites première et seconde pièces de logiciel spécifique (13, 23a) comprennent en outre au moins une paire de premières entités logicielles appariées (132, 232a), chacune desdites entités (132, 232a) coopérant l'une avec l'autre de manière à permettre l'établissement d'une session d'échanges de données bidirectionnels entre ledit terminal (1) et ladite carte à puce (2a) , de manière à ce que ladite carte à puce (2a) offre la fonctionnalité d'un serveur d'information ;
- en ce qu'il est procédé à une troisième phase initiale consistant en l'implantation dans ladite carte à puce (2a) d'une deuxième entité logicielle (ATS±-ATSn) , apte à interpréter une suite d'instructions et à la traduire en une suite d'ordres, ladite deuxième entité logicielle (ATS±-ATSn) coopérant avec lesdites applications (Aι~An) et ladite seconde pièce de logiciel spécifique (23a) ;
- et ce qu'il comprend au moins les étapes suivantes : 1/ établissement d'une session d'échanges de données entre ledit terminal (1) et ladite carte à puce (2a), par l'intermédiaire d'une desdites paires de premières entités logicielles appariées (132, 232aι) , de manière à transmettre une requête pour atteindre l'une desdites applications (A± ) ; 2/ réception de ladite requête par l'une desdites deuxièmes entités logicielles (ATS±) , interprétation d'une desdites suites d'instructions, ladite suite d'instructions étant associée à ladite application à accéder (A± ) , et transmission desdits ordres traduits à cette application, de manière à 1 'activer ; et 3/ élaboration et transmission audit navigateur (10), par l'intermédiaire de ladite deuxième entité logicielle (ATS± ) , et via lesdites première (13) et seconde (23a) pièces de logiciel spécifique, d'une réponse à ladite requête.
2. Procédé selon la revendication 1, caractérisé en ce que ledit lecteur de carte à puce (3) et ladite carte à puce (2a) comprennent des première et deuxième piles protocolaires pour lesdites transmissions de données, chacune comprenant au moins des couches de communication logicielles (101, 200a) , dites basses, de manière à permettre lesdits échanges de données entre ladite carte à puce (2a) et ledit terminal (1) , ces couches formant interface avec lesdites première (13) et seconde (23a) pièces de logiciel spécifique, respectivement, et en ce que ces pièces de logiciel spécifique (13, 23a) comprennent chacune deux entités supplémentaires constituées d'un module de transfert de données (130, 230a) , formant interface avec lesdites couches basses (101, 200a) des première et deuxième piles protocolaires, et d'un module de gestion (131, 231a), et en ce que lesdites premières entités de chaque paire sont constituées de modules logiciels, dits agents intelligents (132, 232aι) établissant lesdites sessions.
3. Procédé selon la revendication 2, caractérisé en ce que, ladite suite d'instructions à interpréter étant constituée par un script, chacune desdites deuxièmes entités logicielles est constituée par un module logiciel dit agent intelligent traducteur de script (ATS -ATSn) .
4. Procédé selon la revendication 3 , caractérisé en ce qu'il est prévu un seul agent traducteur de script, commun à toutes lesdites applications.
5. Procédé selon la revendication 4, caractérisé en ce que ledit agent traducteur de script est confondu avec ledit agent intelligent (232aι) établissant lesdites sessions.
6. Procédé selon la revendication 3, caractérisé en ce qu'il est prévu une pluralité d'agents traducteurs de script dits dédiés (ATS -ATSn) , chaque agent traducteur de script dédié étant associé à une seule desdites applications (Ai-An) .
7. Procédé selon la revendication 3, caractérisé en ce que lesdites applications sont d'un type devant être activé à l'aide d'un jeu d'ordres dits "ADPU" , définis par la norme ISO 7816, ledit terminal (1) et ladite carte à pu-se (2a) comprennent une entité logicielle supplémentaire (102, 201a), dite gestionnaire d'ordres "ADPU", en ce que ladite interface entre lesdites couches basses (101, 200a) des première (101) et deuxième (200a) piles protocolaires, d'une part, et lesdites première (13) et seconde (23a) pièces de logiciel spécifique (23a) , d'autre part, s'effectue par l'intermédiaire desdits gestionnaires d'ordres (102, 200a).
8. Procédé selon la revendication 7, caractérisé en ce que ledit gestionnaire d'ordres (201a), présent dans la carte à puce (2a) , enregistre notamment des données décrivant la configuration desdites applications Ai-An) , et en que le procédé comprend des étapes consistant, sur réception de ladite requête d'accès à une (A± ) des dites applications de la carte à puce (2a) , en la sélection, par ledit gestionnaire d'ordres (201a) , à partir des dites données de configuration, de ladite application à accéder (A±) et d'un desdits agents intelligents traducteurs de script (ATS± ) , associé à cette application (A±) , en la réception desdits ordres traduits par l'agent intelligent traducteur de script (ATS± ) et à l'envoi de ces ordres à ladite application sélectionnée (A±) .
9. Procédé selon la revendication 8, caractérisé en ce que ledit gestionnaire d'ordres (201a) de la carte à puce (2a) comprend en outre une entité logicielle du type agent intelligent (2010a) permettant l'établissement d'une session d'échanges de données bidirectionnels avec d'autres agents intelligents, cet agent (2010a) étant dit agent intelligent gestionnaire d'ordres, et en ce que ladite carte à puce (2a) comporte un seul agent intelligent traducteur de script confondu avec ledit agent intelligent gestionnaire d'ordres (2010a).
10. Procédé selon la revendication 8, caractérisé en ce que, la carte à puce (2a) comprenant en outre une entité logicielle (6) permettant de télécharger et d'enregistrer dans celle-ci au moins une application supplémentaire (Aj ) à partir d'un organe extérieur (EXT) , il est prévu une entité logicielle (7) de détection et de surveillance dudit téléchargement, et en ce que, lorsqu'un téléchargement d'une application supplémentaire (Aj ) est détecté, il est procédé à une étape de mise à jour desdites données de configuration, et à la création ou à la mise à jour d'un agent intelligent de traduction de script (ATSj ) associé à ladite application supplémentaire (Aj ) , et à une étape ultérieure de transmission audit terminal (1) de données reflétant la mise à jour de la carte à puce, par utilisation de ladite fonctionnalité serveur "WEB" de ladite carte à puce (2a) .
11. Procédé selon la revendication 8, caractérisé en ce qu'il comprend une phase préliminaire supplémentaire consistant à implanter, dans ladite carte à puce (2a) , une application spécifique (Ao) et un agent intelligent traducteur de script (ATSo) qui lui est associé, destinés à -offrir, via ladite fonctionnalité de serveur "WEB" un service dit de mise à jour de la carte à puce (2a) , et en ce que le procédé comprend au moins les étapes suivantes :
1/ sous la commande dudit navigateur "WEB" (10) , établissement d'une session d'échanges de données entre ledit terminal (1) et ladite carte à puce (2a), par l'intermédiaire d'une desdites paires d'agents intelligents (132, 232aι) formant les premières entités logicielles appariées, de manière à transmettre une requête d'accès à ladite application spécifique (Ao) et l'envoi de données provoquant une action déterminée consistant dans le chargement d'une application supplémentaire, la mise à jour d'une desdites applications ou sa suppression ;
2/ réception de ladite requête par ledit agent intelligent traducteur (ATSo) , interprétation d'une suite d'instructions associée à ladite application spécifique (A0) et transmission desdits ordres traduits à cette application (AQ ) , de manière à l'activer, à réaliser ladite action déterminée et à mettre à jour lesdites données de configuration ; et 3/ élaboration et transmission audit navigateur "WEB" (10), par l'intermédiaire dudit agent traducteur intelligent de script (ATSo) , et via lesdites première (13) et seconde (23a) pièces de logiciel spécifique, d'une réponse à ladite requête consistant en des données reflétant la nouvelle configuration de la carte à puce (2a) .
12. Procédé selon la revendication l, caractérisé en ce que ladite requête d'accès à une desdites applications est constituée par une page en langage "HTLM" comprenant un formulaire, en ce que ledit formulaire comporte au moins un champ de données (Ch± , Ch2 ) à remplir et/ou une case à cocher par un utilisateur, via ledit navigateur "WEB" (10) , de manière à ce que les données associées soient transmises à ladite carte à puce (2a) lorsque ledit Utilisateur effectue une action de validation prédéterminée.
13. Procédé selon la revendication 1, caractérisé en ce que lesdites réponses consistent en l'envoi audit navigateur "WEB" (10) d'une page en langage "HTLM" .
14. Procédé selon la revendication 1, caractérisé en ce que ledit navigateur "WEB" (10) est localisé dans ledit terminal local (1) .
15. Procédé selon la revendication 1, caractérisé en ce que ledit réseau de transmission de données est un réseau de type Internet (RI) , en ce que réseau (RI) est décrit par une troisième pile protocolaire comprenant un nombre déterminé de couches logicielles de communication (C1-C4) , et en ce que ladite première pièce de logiciel spécifique (13) forme interface avec lesdites couches basses (CC2-CC1) de la première pile protocolaire et avec des couches déterminées de ladite troisième pile protocolaire (C2, C3) .
16. Procédé selon la revendication 15, caractérisé en ce que ledit navigateur "WEB" (10) est localisé dans un terminal éloigné (4) , connecté audit réseau de type Internet (RI) .
17. 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
-des moyens d'interface d'application, agencés pour établir une correspondance entre des instructions circulant sur le réseau et affectées à au moins une application stockée dans le système embarqué, et des instructions d ' échange d * information entre lesdits moyens d'interface de réseau et ladite application.
18. Procédé pour activer au moins une application stockée dans 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 utilise un système embarqué comprenant 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 des moyens d'interface d'application, agencés pour établir une correspondance entre des instructions circulant sur le réseau et affectées à au moins une application stockée dans le système embarqué, et des instructions d'échange d' information entre lesdits moyens d' interface de réseau et ladite application, et en qu'il comprend les phases suivantes :
-établir une session d'échange d'information entre le terminal et le système embarqué pour acheminer au système embarqué une requête d'activation de ladite au moins une application, par l'intermédiaire desdits moyens d• interface de réseau appariés ;
-effectuer une correspondance entre ladite requête et des instructions d'échange d'information entre lesdits moyens d'interface de réseau et ladite application, au moyen desdits moyens d'interface d'application ;
-effectuer une correspondance entre une réponse à ladite requête, émise par l'application, et des instructions de réponse émises sur le réseau, au moyen desdits moyens d'interface d'application.
EP00906418A 1999-02-19 2000-02-17 Systeme embarque possedant des moyens d'interface de reseau, et procede d'activation d'applications localisees dans ce systeme embarque Withdrawn EP1074007A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR9902056A FR2790629A1 (fr) 1999-02-19 1999-02-19 Procede d'activation d'applications localisees dans une carte a puce par un navigateur du type dit "web"
FR9902056 1999-02-19
PCT/FR2000/000400 WO2000049584A1 (fr) 1999-02-19 2000-02-17 Systeme embarque possedant des moyens d'interface de reseau, et procede d'activation d'applications localisees dans ce systeme embarque

Publications (1)

Publication Number Publication Date
EP1074007A1 true EP1074007A1 (fr) 2001-02-07

Family

ID=9542260

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00906418A Withdrawn EP1074007A1 (fr) 1999-02-19 2000-02-17 Systeme embarque possedant des moyens d'interface de reseau, et procede d'activation d'applications localisees dans ce systeme embarque

Country Status (10)

Country Link
US (1) US6839756B1 (fr)
EP (1) EP1074007A1 (fr)
JP (1) JP3913984B2 (fr)
KR (1) KR100641241B1 (fr)
CN (1) CN1179307C (fr)
AU (1) AU775230B2 (fr)
CA (1) CA2329044C (fr)
FR (1) FR2790629A1 (fr)
TW (1) TW462029B (fr)
WO (1) WO2000049584A1 (fr)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2791159B1 (fr) * 1999-03-15 2001-05-04 Bull Cp8 Procede d'acces a un objet a l'aide d'un navigateur de type "web" cooperant avec une carte a puce et architecture pour la mise en oeuvre du procede
FR2793576B1 (fr) * 1999-05-11 2001-11-16 Gemplus Card Int Terminal radiotelephonique avec une carte a puce dotee d'un navigateur
AU1145800A (en) * 1999-11-19 2001-06-04 Swisscom Mobile Ag Adaptable chip card
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
SG154320A1 (en) 2001-02-16 2009-08-28 Sony Corp Data processing method and its apparatus
JP4765174B2 (ja) * 2001-02-16 2011-09-07 ソニー株式会社 アプリケーション実行装置、通信システム、およびアプリケーション実行方法
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
WO2003019883A2 (fr) * 2001-08-24 2003-03-06 Windmill Microsystems Holding Bv Systeme pour l'acquisition de donnees a distance, sur la base d'une communication de messages electroniques sur des reseaux publics et prives
US7346783B1 (en) * 2001-10-19 2008-03-18 At&T Corp. Network security device and method
JP3758554B2 (ja) * 2001-10-31 2006-03-22 ソニー株式会社 情報提供システム及び情報提供方法、記憶媒体、並びにコンピュータ・プログラム
US7783901B2 (en) 2001-12-05 2010-08-24 At&T Intellectual Property Ii, L.P. Network security device and method
US20030217125A1 (en) * 2002-05-15 2003-11-20 Lucent Technologies, Inc. Intelligent end user gateway device
US20030217129A1 (en) * 2002-05-15 2003-11-20 Lucent Technologies Inc. Self-organizing intelligent network architecture and methodology
TWI226588B (en) * 2003-04-23 2005-01-11 Winbond Electronics Corp Contactless radio frequency magnetic field data transmission card and associated application system
US8719840B2 (en) * 2005-02-17 2014-05-06 Koninklijke Philips N.V. Device for secure interprocess communication
DE102007041270A1 (de) * 2007-08-31 2009-03-05 Printed Systems Gmbh Multimediasystem
CN101184057B (zh) * 2007-10-24 2011-08-24 中兴通讯股份有限公司 在ims系统中传递事件信息的系统及方法
JP2009163384A (ja) * 2007-12-28 2009-07-23 Kyodo Printing Co Ltd データ入力システム及びデータ入力方法
US8838989B2 (en) * 2008-01-24 2014-09-16 Blackberry Limited Optimized biometric authentication method and system
US9378346B2 (en) * 2008-01-24 2016-06-28 Blackberry Limited Optimized biometric authentication method and system
MX2010014374A (es) * 2008-06-24 2011-03-01 Nxp Bv Metodo para accesar aplicaciones en un ambiente movil seguro.
EP2273748A1 (fr) * 2009-07-09 2011-01-12 Gemalto SA Procédé de gestion d'une application embarquée dans un dispositif électronique sécurisé
EP2395427A1 (fr) * 2010-06-08 2011-12-14 Gemalto SA Procédé de connexion d'un serveur distant à partir d'un navigateur doté d'une extension de navigateur dans un dispositif hôte

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2657445B1 (fr) * 1990-01-25 1992-04-10 Gemplus Card Int Procede de chargement de programmes d'application dans un lecteur de carte a memoire a microprocesseur et systeme destine a sa mise en óoeuvre.
FR2704704B1 (fr) * 1993-04-28 1995-09-01 Gemplus Card Int Systeme de communication.
AUPN447595A0 (en) * 1995-07-31 1995-08-24 Achelles, Peter Remote smart card terminal link
US6078308A (en) * 1995-12-13 2000-06-20 Immersion Corporation Graphical click surfaces for force feedback applications to provide user selection using cursor interaction with a trigger position within a boundary of a graphical object
US5943423A (en) * 1995-12-15 1999-08-24 Entegrity Solutions Corporation Smart token system for secure electronic transactions and identification
SE509033C2 (sv) * 1996-06-26 1998-11-30 Telia Ab Metod för säker överföring av datainformation mellan Internet www-servar och dataterminaler
EP0932865B1 (fr) * 1996-10-25 2002-08-14 SCHLUMBERGER Systèmes Utilisation de langage de programmation evolue avec un controleur microprogramme
US6293865B1 (en) * 1996-11-14 2001-09-25 Arcade Planet, Inc. System, method and article of manufacture for tournament play in a network gaming system
US6454648B1 (en) * 1996-11-14 2002-09-24 Rlt Acquisition, Inc. System, method and article of manufacture for providing a progressive-type prize awarding scheme in an intermittently accessed network game environment
US6645068B1 (en) * 1996-11-14 2003-11-11 Arcade Planet, Inc. Profile-driven network gaming and prize redemption system
WO1998025239A1 (fr) * 1996-12-03 1998-06-11 Strategic Analysis, Inc. Procede et dispositif de formatage de carte a puce et de lecteur de carte
US6233683B1 (en) * 1997-03-24 2001-05-15 Visa International Service Association System and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card
GB2326010A (en) * 1997-06-07 1998-12-09 Ibm Data processing system using active tokens

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
KR100641241B1 (ko) 2006-10-31
CA2329044C (fr) 2011-07-12
JP2002537617A (ja) 2002-11-05
TW462029B (en) 2001-11-01
CN1179307C (zh) 2004-12-08
AU775230B2 (en) 2004-07-22
CA2329044A1 (fr) 2000-08-24
JP3913984B2 (ja) 2007-05-09
AU2809900A (en) 2000-09-04
WO2000049584A1 (fr) 2000-08-24
US6839756B1 (en) 2005-01-04
KR20010052263A (ko) 2001-06-25
CN1352782A (zh) 2002-06-05
FR2790629A1 (fr) 2000-09-08

Similar Documents

Publication Publication Date Title
EP1074007A1 (fr) Systeme embarque possedant des moyens d'interface de reseau, et procede d'activation d'applications localisees dans ce systeme embarque
EP1188116A1 (fr) Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit "applet"
WO2001060026A1 (fr) 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
EP1142256B1 (fr) Terminal securise muni d'un lecteur de carte a puce destine a communiquer avec un serveur via un reseau de type internet
WO2000056030A1 (fr) Systeme d'acces a un objet a l'aide d'un navigateur de type 'web' 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
EP1044436B1 (fr) Procede de communication entre une station d'utilisateur et un reseau, notamment du type internet, et architecture de mise en oeuvre
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
EP1145522B1 (fr) Procede et architecture de pilotage a distance d'une station d'utilisateur via un reseau de type internet
WO2004056071A1 (fr) Procede de communication entre serveurs avec conversion de format des donnees et dispositif pour sa mise en oeuvre
FR2823333A1 (fr) Systeme terminal interactif a equipement central multi-applicatif et peripheriques

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

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

17P Request for examination filed

Effective date: 20010226

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

Owner name: CP8 TECHNOLOGIES

17Q First examination report despatched

Effective date: 20080204

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20160127

INTG Intention to grant announced

Effective date: 20160129

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