WO2001059563A1 - Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit 'applet' - Google Patents

Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit 'applet' Download PDF

Info

Publication number
WO2001059563A1
WO2001059563A1 PCT/FR2001/000393 FR0100393W WO0159563A1 WO 2001059563 A1 WO2001059563 A1 WO 2001059563A1 FR 0100393 W FR0100393 W FR 0100393W WO 0159563 A1 WO0159563 A1 WO 0159563A1
Authority
WO
WIPO (PCT)
Prior art keywords
smart card
loading
software
terminal
data
Prior art date
Application number
PCT/FR2001/000393
Other languages
English (en)
Inventor
Pascal Urien
Alain Boudou
Christoph Siegelin
Original Assignee
Bull Cp8
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 filed Critical Bull Cp8
Priority to EP01907759A priority Critical patent/EP1188116A1/fr
Priority to CA002366556A priority patent/CA2366556A1/fr
Priority to KR1020017012941A priority patent/KR100886137B1/ko
Priority to AU35647/01A priority patent/AU3564701A/en
Priority to JP2001558826A priority patent/JP3834239B2/ja
Publication of WO2001059563A1 publication Critical patent/WO2001059563A1/fr
Priority to US12/000,766 priority patent/US20080163352A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • 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
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G06F9/44526—Plug-ins; Add-ons
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the invention relates to a method for loading a piece of software into a smart card.
  • Pieces of software in the form of an "applet" which has just been recalled, insofar as the quantity of code is not too large, can be stored in a non-volatile memory present on a memory card. puce, just like any other application.
  • the method according to the invention is more particularly concerned with a terminal or user station provided with a "smart" card reader.
  • terminal In the context of the invention, the term “terminal” must be understood in a general sense.
  • the aforementioned terminal can in particular be constituted by a personal computer operating under various operating systems, such as WINDOWS or UNIX (both being registered trademarks). It can also consist of a workstation, a laptop or a so-called dedicated card terminal.
  • FIG. 1A appended to the present description schematically illustrates the architecture implemented for the loading of "applets" into a chip card according to the known art.
  • Terminal 1 stores a first specific loading program ("Off-Loader"), referenced OL. It communicates with a smart card 2, via a smart card reader 3. The transmissions are carried out according to a standardized communication protocol, using the aforementioned commands, protocol which will be detailed below.
  • OL first specific loading program
  • the smart card 2 for its part, stores a second specific loading program ("In-Loader"), referenced IL.
  • IL a second specific loading program
  • a first drawback of this method is that the programs IL and OL must be paired in order to be able to communicate with each other. It follows that if they are of different origins, they are not, a priori, compatible. This characteristic is linked to the command set to be used.
  • a second drawback is due to the fact that the communications are carried out according to the aforementioned ISO 7816 protocol. Indeed, this imposes a physical proximity between the OL and IL programs. It follows that the OL program must generally run directly on terminal 1 and not, for example, on another terminal or a remote server.
  • Internet network includes, in addition to the Internet itself, private networks of companies or the like, of the so-called “intranet” type, and the networks extending them outwards, type called “extranet”, and generally any network in which data exchanges are carried out according to a protocol of the type Internet. In what follows such a network will be called generically "Internet network”.
  • a smart card-based application system generally has the following main components: a smart card; a host system constituting the aforementioned terminal; - a communication network, namely the Internet network in the preferred application; and an application server connected to the Internet.
  • FIG. 1B schematically illustrates an example of architecture of this type.
  • the terminal 1 for example a personal computer, includes a smart card reader 3. This reader 3 may or may not be physically integrated into the terminal 1.
  • the smart card 2 has an integrated circuit 20 including input connections -outlets are flush with the surface of its support to authorize a supply of electrical energy and communications with the terminal 1. The latter comprises access circuits 11 to the Internet network RI.
  • circuits 1 1 can be constituted by a modem to connect to a switched telephone line or to a higher speed communication channel: integrated service digital network ("ISDN”), cable or satellite links, etc.
  • ISDN integrated service digital network
  • the circuits 1 1 make it possible to connect to the Internet RI network, directly or via an Internet service provider ("Internet Service Provider” or "ISP", according to English terminology).
  • ISP Internet Service Provider
  • Terminal 1 naturally includes all the circuits and organs necessary for its proper functioning, and which have not been shown for the purpose of simplifying the drawing: central unit, random access memories and fixed, mass memory with magnetic disc, floppy and / or CD-ROM drive, etc.
  • the terminal 1 is also connected to conventional peripherals, integrated or not, such as a display screen 5, a keyboard 6a and a mouse 6b, etc.
  • the terminal 1 can be put into communication with servers or any computer system connected to the RI network, of which only one, 4, is illustrated in FIG. 1A.
  • the access circuits 11 put the terminal 1 in communication with the servers 4 using special software 10, called a "WEB" browser, or “browser” according to English terminology. This allows access to various applications or data files distributed over the entire RI network, generally in a "client-server” mode.
  • communications on networks are carried out in accordance with protocols meeting standards comprising several superimposed software layers.
  • communications are carried out according to protocols specific to this type of communications, which will be detailed below, but which also include several software layers.
  • the communication protocol is chosen according to the application more particularly targeted: interrogation of "WEB” pages, file transfers, electronic mail (e-mel, or “e-mail” according to Anglo-Saxon terminology), forums or “news”, etc.
  • FIG. 1 C The logical architecture of the system comprising a terminal, a smart card reader and a smart card is shown diagrammatically in FIG. 1 C. It is described by the ISO 7816 standard, which itself comprises several sub-assemblies:
  • ISO 7816-3 with regard to the transfer of data between the terminal and the smart card
  • ISO 7816-4 with regard to the structure of the command set and the format of commands.
  • FIG. 1C on the terminal side 1, only the layers meeting the ISO 7816-3 standard, referenced 101, and a "APDU" order manager (ISO 7816-4 standard), referenced 102, have been represented.
  • the layers corresponding to ISO 7816-3 are referenced 200 and the "ADPU” order manager (ISO 7816-4 standard) is referenced 201.
  • the applications are referenced A- ⁇ ,. .., Aj, ..., A n ; n being the maximum number of applications present on the smart card 2.
  • An application, Aj present in the smart card 2, dialogs with the terminal 1 by means of a set of commands. This game typically presents writing orders and reading orders.
  • the order format is known by the English abbreviation of "APDU” (for "Application Protocol Data Unit”). It is defined by the aforementioned ISO 7816-4 standard.
  • a command “APDU” is noted “APDU.command” and a response “APDU” is noted “APDU.response”.
  • T 0
  • T block mode
  • An application A / is, for example, in the form of an "applet” which can be recorded initially, or also loaded from the terminal 1. To do this, as illustrated in FIG. 1A, use is made of a "Off-Loader” program, OL, saved in terminal 1 and to an "In-Loader” program, IL, which forms one of the Aj applications of smart card 2.
  • the selection of a particular Aj application is obtained using an "APDU” of the selection type ("SELECT"). Once this choice has been made, the "APDUs” that follow are routed to this application. A new “APDU SELECT” has the effect of abandoning the current application and choosing another one.
  • the “APDU” manager software sub-assembly 201 makes it possible to choose a particular application A ⁇ in the smart card 2, to store the application thus chosen, and to transmit and / or receive “APDUs” to and from this application. .
  • the two loading programs, OL and IL are no longer dependent on each other. In other words, they no longer have to be paired to be compatible.
  • the OL part of the loading programs no longer has to be stored necessarily in the terminal, that is to say in relation to physical proximity with the second part IL.
  • the OL program can be stored on a remote server, connected to the terminal via a network such as the Internet.
  • the smart card behaves like a server / client of the "WEB" type for the terminal associated with it.
  • a specific communication software layer is provided in the smart card and its counterpart in the terminal.
  • the term "specific” should be understood as specific to the process of the invention. Indeed, these layers of communications, called specific, are trivialized whatever the application considered. They only intervene in the two-way data exchange process between the smart card and the terminal, on the one hand, and the smart card and the network, on the other hand.
  • the specific communication software layers notably comprise software components, called “intelligent agents", allowing in particular protocol conversions.
  • the intelligent agents will be referred to hereinafter more simply as “agents”.
  • agents paired in the respective specific communication layers associated with the terminal and the smart card.
  • sessions are established between paired agents.
  • the method of the invention makes it possible to activate applications of conventional type, that is to say of the aforementioned "CGA” type, located in a smart card, without having to modify them in anything.
  • one or more particular intelligent agents known as script translators are provided, which receive requests from a browser and translate them into "APDU" orders understandable by the "CGA” type application. Therefore, a function similar to that known elsewhere under the name "CGI” is implemented in the smart card in conventional "WEB” servers. This function makes it possible to implement an application in the smart card by an Internet protocol of the "HTTP" type.
  • the loading of an "applet” in the smart card can be done by this interface "CGI”.
  • the IL part of the loading program is considered to be a command script, which will be called “cgiscript”, attached to the "WEB” server functionality offered by the smart card.
  • the exchanges between the OL and IL programs can take place with the help of classic forms in "HTML” or “forms” language according to English terminology. While retaining the aforementioned ISO standards for communications between terminal and smart card, via the smart card reader, the method according to the invention allows exchanges between the parts of the loading programs OL and IL using the protocol of Internet communication "TCP / IP", the OL part and the "applets” to be loaded can be stored locally or in a remote server.
  • the main object of the invention is therefore a method of loading a piece of software into a smart card from a terminal connected to said smart card by means of a smart card reader allowing communications. according to a first determined protocol, said loading being effected by the implementation and cooperation of first and second loading programs, said second loading program being stored in said smart card, characterized in that it comprises at least the following phases: a / a first preliminary phase consisting in implanting, in said smart card, a first piece of software, forming a specific communication protocol layer; b / a second preliminary phase consisting in installing, in said terminal, a second piece of software, forming a specific communication protocol layer; in that said first and second pieces of software further comprise at least one pair of first paired software entities, each of said entities cooperating with each other so as to allow the establishment of a data exchange session bidirectional between at least said terminal and said smart card, so that said smart card offers the functionality of a client / server "WEB"; in that it comprises a third preliminary phase consisting in implanting in said
  • FIG. 1A schematically illustrates an exemplary embodiment of an architecture allowing the loading of an "applet" in a chip card according to the 'known art
  • FIGS. 1B and 1C illustrate the hardware and logic architectures, respectively, of an example application system based on a smart card connected to an Internet network according to the known art
  • - Figure 2 schematically illustrates an example of application system based on smart card according to the invention, the latter acting as client / server "WEB"
  • Figure 3 is a state diagram of a session between software entities called intelligent agents, according to one aspect of the invention
  • FIG. 1A schematically illustrates an exemplary embodiment of an architecture allowing the loading of an "applet" in a chip card according to the 'known art
  • FIGS. 1B and 1C illustrate the hardware and logic architectures, respectively, of an example application system based on a smart card connected to an Internet network according to the known art
  • - Figure 2 schematically illustrates an example of application system based on smart card according to the invention, the latter acting as client
  • FIG. 4 illustrates in a simplified manner the logical architecture of a system according to the invention in which the smart card comprises intelligent agents
  • FIG. 5 illustrates in a simplified manner the logical architecture of a system according to the invention in which the smart card comprises intelligent agents translating scripts
  • FIG. 6 schematically illustrates an exemplary embodiment of an architecture allowing the loading of an "applet" in a smart card according to the invention
  • - Figure 7 illustrates the structure of a file for loading a
  • FIG. 8 schematically illustrates the main phases of the process for loading an "applet” into a smart card according to a first practical example of embodiment
  • - Figure 9 schematically illustrates the main phases of the process of loading an "applet” in a smart card according to a second practical embodiment
  • FIGS. 9 and 10 illustrate two examples of forms in "HTML” language usable by the method of loading an "applet” in a smart card according to the invention, for the implementation of the methods known as “GET” and “ POST ", respectively
  • FIGS. 12A to 12G illustrate several variant embodiments of system architectures allowing the loading of an "applet” in a smart card according to 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, several layers may be nonexistent.
  • the terminal 1 comprises circuits 11 for access to the RI network, consisting for example of a modem. These circuits group together the lower software layers, Ci and C2, which correspond to the "physical" and “data link” layers. Also shown are the upper layers, C3 and C4, which correspond to the "network addressing"("IP", in the case of the Internet) and "transport”("TCP") layers. The upper application layer ("http”, “ftp”, "e-mail”, etc.) has not been shown.
  • the interface between the lower layers, Ci and C2, and the upper layers, C3 and C4, is constituted by a software layer generally called “low layer driver".
  • the upper layers, C3 and C4, rely on this interface and are implemented by means of specific function libraries or network libraries 14, with which they correspond. In the case of the Internet, "TCP / IP" is implemented by means of libraries known as "sockets".
  • This organization allows a browser 10 to make requests to a server 4, for consulting "WEB” pages (“HTTP” protocol), for transferring files (“FTP” protocol) or sending electronic mail ( "e-mail” protocol), in a completely classic way in itself.
  • HTTP HyperText Transfer Protocol
  • FTP Transfer Protocol
  • e-mail electronic mail
  • the terminal 1 also includes a card reader 3, integrated or not.
  • the card reader 30 also includes two lower layers, CC1 (physical layer) and CC2 (data link layer), playing a role similar to layers Ci and C2-
  • the software interfaces with the CC1 and CC2 layers are described, for example, by the specification "PC / SC" ("part 6, service provider").
  • the layers themselves, CC1 and CC2 are in particular described by ISO standards 7816-1 to 7816-4, as has been recalled.
  • An additional software layer 16 forms the interface between the application layers (not shown) and the lower layers, CC1 and CC2.
  • the main function assigned to this layer 16 is a multiplexing / demultiplexing function.
  • the communications with the smart card 2a take place according to a paradigm similar to that used for the manipulation of files in a "UNIX” (registered trademark) operating system: OPEN ("OPEN”), READ (“READ”), WRITE (“WRITE”), CLOSE (“CLOSE”), etc.
  • OPEN OPEN
  • READ READ
  • WRITE WRITE
  • CLOSE CLOSE
  • CCai physical layer
  • CCa2 data link layer
  • the specific layer 13 interfaces with the "low layer drivers” 15, with the libraries 14 of the network layers, C3 and C4, and with the protocol layers of the card reader 3, that is to say the layers lower, CC1 and CC2, via the multiplexing layer 16.
  • the specific layer 13 allows the transfer of network packets to and from the smart card 2a.
  • it adapts existing applications such as the Internet browser 10, e-mail, etc., for uses implementing the smart card 2a.
  • the specific layers, 13 and 23a are subdivided into three main software elements: a module, 130 or 230a, for transferring blocks of information between layers 13 and 23a, via the conventional layers CC-
  • agents intelligent agents
  • CCa2 ensure the exchange between the smart card 2a and the terminal 1.
  • These layers are responsible for the detection and possible correction of transmission errors.
  • 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
  • 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 information exchange between a user (not shown) of the terminal 1 and the smart card 2a, for example via drop-down menus in the form of hypertext in "HTML" format. They also allow the setting up of a configuration suitable for the transmission and / or reception of data packets.
  • the layers include three separate entities.
  • the first layer, 130 or 230a is essentially constituted by a software multiplexer. It allows the exchange of information between the smart card 2a and the host terminal 1, in the form of protocol data units. It plays a role similar to that of a data packet switch. These units are sent or received via the level two layer
  • This particular communication protocol makes it possible to put at least one pair of "agents" into communication.
  • the first agent of each pair, 132 is located in layer 13, terminal side 1, the second, 232a, is located in layer 23a, chip card side
  • a link between two “agents” is associated with a session, which can be called "S-Agent".
  • a session is a two-way data exchange between these two agents. If one or other of the layers, 13 and 23a, comprises several agents, the agents of the same layer can also establish sessions with each other and / or with the modules 131 and 231a, which constitute particular agents.
  • an agent is an autonomous software entity which can perform all or part of the functions of the layers of levels three and four, depending on the configuration implemented by the terminal 1.
  • Agents are associated with particular properties or attributes. To fix the ideas, and by way of nonlimiting example, the following six properties are associated with the agents:
  • type agents There are two main categories of agents: type agents
  • server which are identified by a fixed reference
  • client type agents, which are identified by a variable reference, which can be described as ephemeral, delivered by the configuration management module, 131 or
  • the agents communicate with each other using an entity called “protocol data units” or “pdu” (for "protocol data unit”, according to English terminology) constituting a destination reference and a source reference.
  • pdu for "protocol data unit”, according to English terminology
  • pdu for "protocol data unit”
  • SmartTP pdu with reference to the English term “Smart Card” (chip card) commonly used.
  • the “pdu” use in particular the references defined above.
  • the "BLOCK" flag indicates that the agent is waiting for a reply from his correspondent and suspends all activity.
  • a session is opened with another agent, an "S-Agent" session being identified by a pair of references;
  • the mechanism for establishing an "S-Agent" session is as follows: - a new instance of a client agent is created (chip card or terminal side), this agent being identified by an ephemeral pseudounic reference;
  • the client agent issues a "pdu" to a server agent (whose reference is known elsewhere) with the "OPEN” flag set and the client agent goes into the connected or blocked state depending on the value of the flag
  • the server agent receives the "pdu” with the "OPEN” flag and goes to the connected state
  • the mechanism for closing a session is as follows:
  • an agent issues a "pdu” with the "CLOSE” flag positioned (and which possibly includes data;
  • the other agent receives a "pdu” with the "CLOSE” flag set (and which possibly includes data) and the "S-Agent" session goes to the disconnected state.
  • FIG. 3 schematically illustrates the state diagram of the "S-Agent" sessions, as they have just been recalled.
  • Layers 130 and 230a manage tables (not shown) which contain the list of agents present, on the host terminal side 1 and smart card 2a.
  • the agents make it possible to exchange data (of hypertext, for example), but also to trigger network transactions, authorizing communications between the smart card 2a and a remote server 4 (FIG. 2).
  • the configuration management modules, 131 and 231a, respectively, can be compared to specific agents.
  • the module 131, on the host terminal side 1 manages in particular information relating to the configuration of this terminal (operating modes), list of the other agents present, etc.
  • the module 231a, on the smart card side 2a has similar functions. These two agents can be put in communication with each other to establish a session.
  • the smart card 2a is advantageously "addressed” by using a "URL” address (for "Universal Resource Locator") defining a loopback on the terminal 1 itself, and not a pointing on an external server .
  • a "URL” address for "Universal Resource Locator”
  • the structure of this "URL” is usually as follows: http://127.0.0.1: 8080 (1), in which 127.0.0.1 is the loopback "IP” address and 8080 is the number of port.
  • FIG. 4 illustrates in a simplified manner the logical architecture of a system according to the invention of the type shown in FIG. 2, but shown in more detail.
  • the smart card 2a comprises several agents, only two of which have been represented: an agent of the type not precisely defined 232a ⁇ and an agent 232a2, of the so-called "WEB" type.
  • the logic stack includes, the lower protocol layers, referenced 200a, meeting ISO standards 7816-3 (FIG. 2: CCai and CCa2), the "APDU" command manager 201 a- ⁇ , and the packet multiplexer 230a, this the latter being an interface to agents, in particular the "WEB" agent 23132-
  • the first stack includes the organs 11 (FIG. 2: Ci and C2) for accessing the network (OSI standards 1 and 2) and the "TCP / IP" protocol layers (FIG. 2: C3 and C4), referenced 100. These latter layers are interfaced with the "WEB" browser 10.
  • the other stack includes the lower protocol layers, referenced 101, meeting ISO standards 7816-3 (FIG. 2: Ci and C2). the manager 102 of "APDU" orders and the packet multiplexer 130, the latter being interface with agents, of which only one 132 is shown.
  • the latter which will be assumed to be "network type" can also communicate, on the one hand with the browser 10, via the "TCP / IP” layers 101, on the other hand with the Internet network RI, via these same "TCP / IP” layers 101 and member 11, for access to the RI network.
  • the “APDU” order manager 201a also interfaces with one or more application-level layers, which will simply be called applications. These applications, AMHz..., Alves ..., A n , are, as indicated, applications of the conventional type.
  • the client / server function "WEB”, provided by the smart card 2a can be performed by the combination of the agent "WEB" 232a ⁇ in the smart card and the network agent 132 in the terminal 1, and by the implementation of sessions between agents, as described.
  • the smart card 2a therefore clearly presents the client / server functionality "WEB”.
  • any conventional application, A- ⁇ to An of the aforementioned "CGA” type, can be activated through this client / server "WEB”, either by "WEB” browser 10 present in terminal 1, either by a remote browser 4, located at any point on the Internet RI network, by the implementation of sessions between agents.
  • the applications, A- ⁇ to An do not need to be rewritten and are implemented as they are.
  • all or part of the applications A- ⁇ to An can be constituted by "applets”, loaded initially in a non-volatile memory of the smart card 2 or, on the contrary, loaded via the two loading programs OL and IL, the nature and possible storage locations of which will be specified below.
  • the "WEB” server function offered by the smart card includes a mechanism similar to the so-called “CGI” function (for "Common Gateway Interface” or “gateway interface”) installed in the servers Classic "WEB”.
  • CGI Common Gateway Interface
  • CGI is a specification for implementing, from a “WEB” server, applications written for the "UNIX” (registered trademark), "DOS”, or "WINDOWS” (registered trademark) operating systems.
  • UNIX registered trademark
  • DOS registered trademark
  • WINDOWS registered trademark
  • an "HTTP" request for a "URL” address of the type: "http://www.host.com/cgi-bin/xxx.cgi” (2), in which "host” refers to a host system (generally remote)
  • "host” refers to a host system (generally remote)
  • "WEB” server is interpreted by a "WEB” server as the execution of a command script, of the "CGI” type named "xxx" and present in the "cgi- bin” directory of this host system.
  • the name of the directory can be a priori arbitrary, by convention, it is the name given to the directory storing scripts of type "CGI”.
  • a script is a series of instructions from the operating system of the host system, the final result of which is transmitted to the "WEB" browser issuing the above request.
  • the request is usually displayed on a computer screen in the form of a form included in a "HTLM” page.
  • the "HTLM” language allows you to translate a form into a "URL” address.
  • the form includes one or more fields, mandatory or not, which are filled in by a user using the usual input methods: keyboard for text, mouse for check boxes or so-called “radio” buttons, etc.
  • the content of the form (as well as possibly so-called “hidden” information and instructions) is sent to the "WEB” server.
  • the "HTLM” code on the page describes the physical structure of the form (frame, graphics, color, and any other attribute), as well as the structure of the data fields to be entered (name, length, type of data, etc.).
  • Transmission can take place in two main types of formats.
  • a first format uses the so-called "POST” method and a second uses the so-called "GET” method.
  • Format type information is present in the code of the form page.
  • Script translator agents or in shorthand “ATS”.
  • the script is then interpreted by one of the intelligent agents.
  • This translation can be carried out in different ways: a / by the "WEB” agent 232a ⁇ itself, which in this case is provided with a double capacity; b / by a single script agent capable of translating all the scripts present in the smart card 2a; c / by a dedicated script agent which will be called “ATSD” below (one agent per script); or 61 by an agent “APDU” 2010a of the order manager "APDU” 201a, which is equipped, in this case, with a double capacity.
  • the "APDU” agent 2010a is a component of the "APDU” order management layer 201a.
  • the latter is a layer capable of centralizing all the "APDU” orders sent and / or received by the system, of selecting applications from A to A n , but also of offering an interface of the intelligent agent type. It is therefore capable, according to one of the characteristics of the invention, of communicating with all the intelligent agents (via sessions), whether these agents are located in the enclosure 6 or the smart card 2a. In case c / above, a session is opened between the agent
  • FIG. 5 illustrates an example of architecture for which the translating agents are of the "ATSD" type. They are referenced ATS to ATS n and associated with applications / 1 to A ⁇ .
  • the selected application being assumed to be application A, the session is established between the "WEB" agent 232a ⁇ and the agent
  • a script translator agent generates a sequence of "APDU” orders.
  • a session is opened between the translator agent, eg ATS agent: and the agent “APDU” 2101a.
  • the orders are then issued to the "APDU” agent 2101a.
  • the "APDU” order manager 210a selects the "CGA” application A t and transmits to it the "APDU” orders, translated and therefore conventional orders, which it is able to understand. This application is therefore correctly activated, without having to modify or rewrite it.
  • the responses of the application A t are transmitted to the "APDU" order manager 210a, to the "APDU” agent 2010a, then again to the ATS agent. (and more generally to the script translator agent).
  • the method according to the invention uses the two characteristics which have just been mentioned: operation of the smart card as a "WEB” server / client, including a “cgi” function.
  • operation of the smart card as a "WEB” server / client, including a “cgi” function.
  • the loading of an "applet” in the smart card is effected via the "CGI" interface offered by it.
  • the loading program part IL located in the smart card 2a, is constituted by a script. It is, for example, a script associated with the application referenced A in FIG. 5.
  • This script is, according to a characteristic of the method of the invention, activated by a "HTTP" request, the exchanges between the OL part and the IL part being carried out according to the "TCP / IP" communication protocol.
  • the IL and OL programs therefore become a priori compatible. In addition, it is no longer necessary that physical proximity is respected, as in the known art (see Figure 1).
  • the OL part can now be located in the terminal or, preferably, in a remote server (the connections between the server and the terminal being carried out according to the "TCP / IP” protocol), or even, as will be shown, stored in the smart card itself.
  • the above-mentioned "HTTP" request is initiated by the OL party.
  • the data sent to the "WEB” agent 232a ⁇ is transported, in a conventional manner per se, in the form of "APDU” orders intended for the particular application constituted by the "Packet multiplexer” 230a.
  • the "APDU” order manager 201a selects this application in a manner very similar to the others "CGA” type applications, A- ⁇ to An, present in the smart card 2a.
  • the packet multiplexer 230a is seen by the "APDU" order manager 201a as an ordinary "CGA” application.
  • the "HTTP" request is analyzed by the "WEB” agent 232a ⁇ which detects a reference to a particular directory, which will be called hereinafter by convention “cgi-smart” (by analogy to “cgi-bin”), on the one hand, and for a particular application, IL in the case of the example described.
  • the full path is therefore, in this case “cgi-smart / il”.
  • the entity "it” above designates a particular script associated with an application which is also particular (IL in this case).
  • a session is opened between the translator agent, for example the ATS agent, and the "APDU” agent 2010a.
  • the ATS ⁇ script translator agent generates a sequence of "APDU” commands. Orders are issued to the "APDU” agent 2010a.
  • the "APDU” order manager 201a selects the "CGA” Aj application (for example the IL 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.
  • the response of the application IL (Aj) is transmitted in the opposite direction to the order manager "APDU" 201a, to the agent "APDU” 2010a, then again to the agent ATSj (and more generally to the 'script translator agent).
  • the response consisting of a form in "HTLM” language, takes the opposite path, by implementing sessions between paired intelligent agents, to be re-transmitted to terminal 1 and, possibly to a remote server 4 (FIG. 4), via the RI Internet network, to finally reach the OL application.
  • FIG. 6 schematically illustrates the logical architecture allowing the loading of an "applet” according to the method of the invention.
  • the hardware blocks constituted by the terminal 1, the smart card reader 3 and smart card 2a, communicating by implementing the aforementioned ISO 7816 standard protocol and the exchange of "APDU” orders, in a conventional manner per se.
  • the OL part is linked with the IL part (in the form of a script referenced ILs), by exchanges according to the Internet protocol "TCP / IP", in the manner described above, by implementing the server functions "HTTP "(referenced SC) and” CGI "of the smart card 2a.
  • the OL program is not necessarily stored in terminal 1.
  • the loading file of the "applet”, referenced 7, has the structure illustrated in FIG. 7: a header 70, a main body 71 consisting of "Byte Code” in "JAVA” language and an electronic signature 72.
  • the header represents an identifier of a particular application, generally called “Application Identifier” or simply “AID”.
  • the electronic signature 72 is an encrypted word with a public or private key, obtained from the code 71.
  • the entire file 7 can also be encrypted, for reasons of confidentiality, when it comes to so-called sensitive applications .
  • one or more additional electronic signature (s) may not be provided.
  • the OL loading program part retrieves, by a command of the "GET” type, a form loading from smart card 2a, form in "HTML” language which will be arbitrarily called “download. html”.
  • This recovery is carried out by consulting a corresponding page whose URL is typically of the following form: http://127.0.0.1: 8080 / download.html (3), in which http://127.0.0.1: 8080 is l the actual loopback URL, as defined by relation (1), and "download.html” the "HTML" page to obtain.
  • This request implements a session between intelligent agents as described with reference to FIGS. 2 to 4, according to a first aspect of the invention.
  • the smart card 2a then plays the role of a "WEB" server.
  • the smart card 2a sends the "download.html” form during a second step, always by opening sessions between paired intelligent agents, according to the method of the invention.
  • the form obtained can be displayed on a screen 5 via the browser 10.
  • FIG. 9 an example of such a form 8 is illustrated in FIG. 9.
  • the form includes display areas for the header 70 of the file. loading 7, the "Byte Code” 71 and the signature 72.
  • the display area 71 is of the so-called “TEXTAREA” type in "HTML” language and has a facility called “lift” for the scrolling display of texts long.
  • the corresponding information as it appears in figure 9, is purely arbitrary.
  • the send button 81 makes it possible to validate the form and forwards it to the smart card 2a ("submit the loading file” in FIG. 8) and the reset button 82 makes it possible to erase the information displayed and to re-initialize the form.
  • HTML "HTML” code necessary to program such a form is well known in itself and is within the reach of those skilled in the art. He is not necessary to retailer again. We can however indicate that it contains in particular a line of code in "HTML" language which typically takes the form:
  • the OL part sends an "HTTP" request of the "GET” type to the smart card 2a, still by opening sessions between paired intelligent agents.
  • the application IL is executed, the "WEB” server formed by the smart card 2a passing the parameters of the "HTTP" request to this last application.
  • a return code is transmitted from the IL part to the OL part, again by implementing sessions between matched agents. This is generally a simple acknowledgment or, if the operation has not been carried out correctly, an error code. In the latter case, it is necessary to repeat steps 1 to 4.
  • Figure 10 illustrates an example of such a form referenced 8 '.
  • These elements play a role quite similar to the elements with the same reference in FIG. 9 and there is no need to rewrite them.
  • the display area 71 'no longer explicitly displays the "Byte Code", but a directory or a sub-directory where the code of the "applet" to be loaded is saved.
  • this zone points to a file, arbitrarily called “APPLET.BIN”, saved on a storage unit called “C”, which can be a hard disk present in terminal 1.
  • An additional navigation button “browse”83 allows to scan the various (sub) directories of this disk and to select a particular file (" APPLET.BIN ").
  • the return from the part IL then contains a new form.
  • dynamic sequences of exchanges between the parts OL and IL can be carried out.
  • the IL party may request an additional authorization (that is to say an electronic signature), for example that of a government authority. It then returns to the OL a form which can typically have the following "HTML" structure (6):
  • the complete process then includes two additional steps before the final acknowledgment or error code step, i.e. six steps, as illustrated in FIG. 11.
  • the number of round trips can depend on parameters appearing in one or other of the forms exchanged between the smart card and the OL part of the loading programs.
  • the method according to the invention has in particular the additional advantage to no longer require physical proximity between the two parties OL and IL, since they are no longer dependent on the ISO 7816 communication protocol, the exchanges between these two portions of software implementing the Internet TCP / IP communication protocol. Also, the OL part, as well as the actual data of
  • I “applet” to load on the smart card 2a can be stored either locally, or in a remote site. In all cases, however, the exchanges between these two parties implement, as has just been recalled, a "TCP / IP” communication protocol and the loading of an "applet” takes place as previously recalled. thanks to the server / client functions "WEB” and "CGI” offered by the smart card 2a.
  • FIG. 12 A illustrates a system architecture according to which the OL part is stored locally on the terminal 1.
  • the latter is connected to a remote server 4, via the Internet network RI.
  • the data of the "applet” to be loaded into the smart card 2a, referenced Da, are stored on this server 4.
  • An "HTTP" request makes it possible to transfer them to the smart card 2a, via the terminal 1 (and a smart card reader not shown), by implementing the Internet communication protocol "TCP / IP".
  • the loading program part OL and the data Da are stored locally in the terminal 1.
  • the connection of the terminal 1 to the Internet network RI is optional. At the very least, it is not required for loading an "applet" according to the steps of the method of the invention. This connection has been shown in dotted lines. The terminal can therefore be autonomous.
  • the loading program part OL and the data Da are stored in a remote server 4.
  • the communications between the server 4 and the smart card 2a, via the Internet network RI, terminal 1 and the card reader puce (not shown) î'effectait by requests "HTTP", and implementation of the protocol "TCP / IP”.
  • FIG. 12D The system architecture shown in Figure 12D is similar to that of Figure 12C. The only difference is that the part of the OL loading program is stored in a first remote server, referenced
  • the part of the loading program here referred to as OL ′, consists of a component of the browser 10 itself. This is advantageously an “applet” integrated into this browser.
  • the type of entry to use in this case is "file”.
  • the data Da, of the "applet" to be loaded on the chip card 2a can be stored on an external data recording medium 9, for example a floppy disk as illustrated in FIG. 12E.
  • an external data recording medium 9 for example a floppy disk as illustrated in FIG. 12E.
  • Naturally other supports can be used:
  • CDROM compact CDROM, magnetic tape, etc.
  • the browser 10 is able, contrary to the known art, to communicate directly with the latter , as shown with reference to Figures 2 to 4. Communication takes place by opening sessions between paired agents.
  • the system architecture illustrated in FIG. 12F is a variant of the architecture in FIG. 12E.
  • the part of the loading program OL is stored in the smart card 2a itself, in the form of an "applet” in "JAVA” language.
  • this "applet” can be loaded dynamically on terminal 1, in OL ".
  • This loading is carried out using requests posed by the browser 10, during preliminary steps.
  • the OL part loaded the subsequent steps are common to the previous case.
  • the data Da can also be stored on an external medium, for example a floppy disk 8.
  • the system architecture of Figure 12G is a variation of that of Figure 12F.
  • the part of the OL loading program is stored on a remote server 4, in the form of an "applet” in "JAVA” language.
  • this "applet” can be loaded dynamically on the terminal 1, in OL ".
  • This loading is carried out using requests made by the browser 10, during preliminary steps.
  • the other steps are common to the previous case.
  • the use of the Internet protocols "HTTP" and “TCP / IP” for the exchanges between the loading program parts OL and IL makes it possible to physically separate them. Only “IP” packet routing is required on the terminal.
  • the loading can then be done in an ordinary smart card reader, since the ISO 7816 communication protocol is kept.
  • the terminal can be a simple standard microcomputer connected to the Internet.
  • the applications stored in the smart card remain standard, and therefore do not have to be rewritten.
  • the smart card and the terminal themselves require only a few modifications in order to be able to accommodate the process of the invention: the latter boil down to the implementation, in these two units, of a communication protocol software layer which has been called a specific, software layer including intelligent agents.
  • the part of the OL loading program can be loaded dynamically on the terminal, through the card, from the latter or from a remote "HTTP" server.
  • a simple Internet browser can be used as an OL loader.
  • HTML HyperText Markup Language
  • XML XML
  • the invention also relates to a method of loading a piece of software into a smart card from a terminal connected to said smart card through a smart card reader allowing communications according to a first determined protocol, the terminal and the smart card comprising information processing means and information storage means, said loading effected by the implementation and cooperation of first and second loading programs, said second loading program being stored in the information storage means of said smart card, characterized in that it comprises at least the following phases: a / a first preliminary phase consisting in implanting, in the information storage means of said smart card (2a), a first piece of software (23a), forming a specific communication protocol layer; b / a second preliminary phase consisting in implanting, in the information storage means of said terminal (1), a second piece of software (13), forming a specific communication protocol layer; in that said first and second pieces of software (13, 23a) further comprise at least one pair of first paired software entities (132, 232a), each of said entities (132, 232a) cooperating with each other, by means of said information processing

Landscapes

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

Abstract

L'invention concerne le chargement d'une 'applet' dans une carte à puce (2a), à l'aide de deux programmes de chargement, dits 'In-loader' (IL), stocké dans la carte, et 'Off-loader' (OL), respectivement. Selon l'invention, on prévoit deux couches protocolaires de communication spécifiques, l'une dans un terminal (1) hébergeant le lecteur de la carte, l'autre dans la carte. Ces couches comprennent notamment des agents intelligents permettant à la carte d'offrir une fonctionnalité de client/serveur 'WEB' et de passerelle 'CGI'. Le procédé comprend au moins une étape pendant laquelle une requête 'HTTP' est envoyée à la carte, pour adresser une page 'HTML', une étape de récupération de données de paramétrage véhiculées par un formulaire 'HTML' et une étape d'exécution du second programme de chargement (IL), par mise en oeuvre de la fonctionnalité 'CGI', pour charge l''Applet'.

Description

PROCEDE DE CHARGEMENT D'UNE PIECE DE LOGICIEL DANS UNE CARTE A PUCE, NOTAMMENT DU TYPE DIT "APPLET"
L'invention concerne un procédé de chargement d'une pièce de logiciel dans une carte à puce.
Elle s'applique plus particulièrement au chargement d'une pièce de logiciel appelée en français "appliquette", plus connue sous le terme anglo- saxon d' "applet". Il s'agit d'une application écrite en langage "JAVA" (marque déposée). Ces applications, généralement peu volumineuses, sont indépendantes des architectures des systèmes sur lesquelles elles sont implantées. Elles peuvent donc fonctionner sur n'importe quel système informatique, dans la mesure où celui-ci implemente le concept dit de "machine virtuelle JAVA" ("Java Virtual Machine"). Une application écrite en langage JAVA est en général traduite en un langage intermédiaire dit "Byte Code". La machine virtuelle JAVA précitée constitue un interprétateur de ce "Byte Code", de manière à être exécutée directement sur un système cible, hôte de ladite machine virtuelle.
Généralement, les architectures de système sur lesquelles tourne ce type d'applications sont du type dit client-serveur. Dans ce cas, on parle également de "servlet" pour une application stockée sur un système serveur et "applet" pour une application stockée sur un système client. Dans ce qui suit, on utilisera le terme "applet" de façon générique.
Des pièces de logiciel, se présentant sous la forme d' "applet" qui vient d'être rappelée, dans la mesure où la quantité de code n'est pas trop volumineuse, peuvent être stockées dans une mémoire non volatile présente sur une carte à puce, au même titre que toute autre application. Aussi, le procédé selon l'invention est plus particulièrement concerné par un terminal ou station d'utilisateur muni d'un lecteur de carte à "puce". Dans le cadre de l'invention, le terme "terminal" doit être compris dans un sens général. Le terminal précité peut être notamment constitué par un ordinateur personnel fonctionnant sous divers systèmes d'exploitation, tels WINDOWS ou UNIX (tous deux étant des marques déposées). Il peut être aussi constitué par une station de travail, un ordinateur portable ou un terminal de carte dit dédié.
Dans l'état actuel de la technique, le chargement d'une "applet" sur une carte à puce (encore appelé téléchargement) se fait grâce à deux programmes spécifiques. Ces programmes sont généralement connus sous les termes anglo-saxons "Off-Loader", pour le premier, et "In-Loader", pour le second. Le programme "Off-Loader" s'exécute sur le terminal et le programme "In-Loader" s'exécute dans la carte à puce. Les programmes de chargement "Off-Loader" et "In-Loader" communiquent entre eux au travers d'une liaison normalisée de type ISO 7816-3, protocole universellement retenu pour les communications entre une carte à puce et son terminal hôte. Ce protocole met en œuvre une suite d'échanges généralement propriétaires (commandes d'un type dit "APDU" qui seront explicitées ci- après) afin de réaliser le chargement d'une "applet".
La figure 1A annexée à la présente description illustre de façon schématique l'architecture mise en œuvre pour le chargement d' "applets" dans une carte à puce selon l'art connu.
Le terminal 1 stocke un premier programme spécifique de chargement ("Off-Loader"), référencé OL. Il communique avec une carte à puce 2, via un lecteur de carte à puce 3. Les transmissions s'effectuent selon un protocole de communication normalisé, faisant appel aux commandes précitées, protocole qui sera détaillé ci-après.
La carte à puce 2, pour sa part stocke un second programme spécifique de chargement ("In-Loader"), référencé IL.
Un premier inconvénient de ce procédé est que les programmes IL et OL doivent être appariés pour pouvoir communiquer entre eux. Il s'ensuit que s'ils sont d'origines différentes, ils ne sont pas, a priori, compatibles. Cette caractéristique est liée au jeu de commandes à utiliser.
Un deuxième inconvénient est dû au fait que les communications s'effectuent selon le protocole ISO 7816 précité. En effet, celui-ci impose une proximité physique entre les programmes OL et IL. Il s'ensuit que le programme OL doit généralement s'exécuter directement sur le terminal 1 et non, par exemple, sur un autre terminal ou un serveur éloigné.
Or, avec l'essor spectaculaire du réseau Internet, un nombre toujours croissant de terminaux sont connectés à ce réseau, notamment pour pouvoir être en liaison avec des serveurs éloignés, de type "WEB". Il serait donc intéressant, par exemple, de pouvoir stocker la partie "Off- Loader" OL des programmes de chargement d' "applets" sur un serveur "WEB" connecté à ce réseau. Les "applets" à charger sur une ou plusieurs carte(s) à puce pourraient d'ailleurs être aussi stockées sur ce serveur ou sur un ou plusieurs autres serveurs de ce type.
Dans l'état actuel de la technique, ce mode opératoire bute sur une double impossibilité. La première a déjà été évoquée : la norme retenue pour les communications entre le terminal et la carte à puce impose a priori une proximité physique entre la localisation des programmes "Off-Loader", OL, et "In-Loader", IL.
D'autre part, les transmissions entre deux systèmes, par exemple un terminal et un serveur éloigné, via le réseau Internet, font appel à des protocoles de type Internet. Dans l'état actuel de la technique, il n'est pas possible de réaliser des communications directes entre une carte à puce et le réseau Internet, comme il va l'être explicité également.
Dans le cadre de l'invention, le terme "réseau Internet" englobe, outre le réseau Internet proprement dit, les réseaux privés d'entreprises ou similaires, du type dit "intranet", et les réseaux les prolongeant vers l'extérieur, du type dit "extranet", et de façon générale tout réseau dans lequel les échanges de données s'effectuent selon un protocole du type Internet. Dans ce qui suit un tel réseau sera appelé de façon générique "réseau Internet".
On va tout d'abord rappeler brièvement l'architecture générale d'un système d'application à base de carte à puce, relié à un réseau Internet, par référence aux figures 1 B et 1 C.
Un système d'application à base de carte à puce comporte généralement les éléments principaux suivants : une carte à puce ; un système hôte constituant le terminal précité ; - un réseau de communication, à savoir le réseau Internet dans l'application préférée ; et un serveur d'application connecté au réseau Internet. La figure 1 B illustre schématiquement un exemple d'architecture de ce type. Le terminal 1 , par exemple un ordinateur individuel, comporte un lecteur 3 de carte à puce 2. Ce lecteur 3 peut être ou non physiquement intégré dans le terminal 1. La carte à puce 2 comporte un circuit intégré 20 dont des connexions d'entrées-sorties affleurent en surface de son support pour autoriser une alimentation en énergie électrique et des communications avec le terminal 1. Ce dernier comprend des circuits d'accès 11 au réseau Internet RI. Ces circuits peuvent être constitués par un modem pour se connecter à une ligne téléphonique commutée ou à une voie de communication à plus haut débit : réseau numérique à intégration de services ("RNIS"), câble ou liaisons par satellite, etc. Les circuits 1 1 permettent de se connecter au réseau Internet RI, directement ou via un prestataire de services Internet ("Internet Service Provider" ou "ISP", selon la terminologie anglo-saxonne). On peut également avoir recours à un système intermédiaire tel qu'un "proxy" ou un système d'isolation dit "firewall" ("pare- feu" ou encore appelé "garde barrière").
Le terminal 1 comprend naturellement tous les circuits et organes nécessaires à son bon fonctionnement, et qui n'ont pas été représentés dans un but de simplification du dessin : unité centrale, mémoires vive et fixe, mémoire de masso à disque magnétique, lecteur de disquette et/ou de CédéRom, etc.
Habituellement, le terminal 1 est aussi relié à des périphériques classiques, intégrés ou non, tels un écran de visualisation 5, un clavier 6a et une souris 6b, etc.
Le terminal 1 peut être mis en communication avec des serveurs ou tous systèmes informatiques connectés au réseau RI, dont un seul, 4, est illustré sur la figure 1A. Les circuits d'accès 11 mettent le terminal 1 en communication avec les serveurs 4 grâce à un logiciel particulier 10, appelé navigateur "WEB", ou "browser" selon la terminologie anglo-saxonne. Celui- ci permet d'accéder à diverses applications ou fichiers de données répartis sur l'ensemble du réseau RI, généralement selon un mode "client-serveur".
Habituellement, les communications sur les réseaux s'effectuent conformément à des protocoles répondant à des standards comprenant plusieurs couches logicielles superposées. Dans le cas d'un réseau RI de type Internet, les communications s'effectuent selon des protocoles spécifiques à ce type de communications, qui seront détaillés ci-après, mais qui comprennent également plusieurs couches logicielles. Le protocole de communication est choisi en fonction de l'application plus particulièrement visée : interrogation de pages "WEB", transferts de fichiers, courrier électronique (e-mel, ou "e-mail" selon la terminologie anglo-saxonne), forums ou "news", etc.
L'architecture logique du système comprenant un terminal, un lecteur de carte à puce et une carte à puce, est représentée schematiquement par la figure 1 C. Elle est décrite par la norme ISO 7816, qui elle-même comportent plusieurs sous-ensembles :
ISO 7816-1 et 7816-2, en ce qui concerne les dimensions et le marquage des cartes ;
ISO 7816-3, en ce qui concerne le transfert de données entre le terminal et la carte à puce ; et ISO 7816-4, en ce qui concerne la structure du jeu d'ordres et le format des commandes.
Sur la figure 1 C, du côté terminal 1 , on n'a représenté que les couches répondant à la norme ISO 7816-3, référencées 101 , et un gestionnaire d'ordres "APDU" (norme ISO 7816-4), référencé 102. Du côté carte à puce 2, les couches répondant à la norme ISO 7816-3 sont référencées 200 et le gestionnaire d'ordres "ADPU" (norme ISO 7816-4) est référencé 201. Les applications sont référencées A-\ , ..., Aj, ..., An ; n étant le nombre maximum d'applications présentes sur la carte à puce 2. Une application, Aj, présente dans la carte à puce 2, dialogue avec le terminal 1 au moyen d'un jeu d'ordres. Ce jeu présente typiquement des ordres d'écriture et des ordres de lecture. Le format des ordres est connu sous l'abréviation anglo-saxonne de "APDU" (pour "Application Protocol Data Unit"). Il est défini par la norme ISO 7816-4 précitée. Une "APDU" de commande est notée "APDU.command" et une "APDU" de réponse est notée "APDU.response". Les "APDU" sont échangées entre le lecteur de carte et la carte à puce au moyen d'un protocole spécifié par la norme ISO 7816-3 précitée (par exemple en mode caractère : T=0 ; ou en mode bloc : T=1 ). Lorsque la carte à puce 2 inclut plusieurs applications distinctes, comme illustré sur la figure 1 C, on parle de carte multi-applicative. Cependant, le terminal 1 ne dialogue qu'avec une seule application à la fois. Une application A/ se présente, par exemple, sous la forme d'une "applet" qui peut être enregistrée initialement, ou encore chargée à partir du terminal 1. Pour ce faire, comme illustré par la figure 1A, on a recours à un programme "Off-Loader", OL, enregistré dans le terminal 1 et à un programme "In-Loader", IL, qui forme l'une des applications Aj de la carte à puce 2.
La sélection d'une application particulière Aj est obtenue à l'aide d'une "APDU" du type sélection ("SELECT"). Une fois ce choix effectué, les "APDU" qui le suivent sont acheminés vers cette application. Une "APDU SELECT" nouvelle a pour effet d'abandonner l'application en cours et d'en choisir une autre. Le sous-ensemble logiciel gestionnaire des "APDU" 201 permet de choisir une application particulière A\ dans la carte à puce 2, de mémoriser l'application ainsi choisie, et de transmettre et/ou recevoir des "APDU" vers et depuis cette application.
En résumé de ce qui vient d'être décrit, la sélection d'une application Aj et le dialogue avec celle-ci s'effectuent par échanges d'ordres
"APDU". On suppose que les applications Aj sont des applications conventionnelles, que l'on appellera ci-après "GCA" (pour "Generic Card Application" ou application de carte générique).
Ce mode opératoire explique que les programmes OL et IL doivent être appariés, pour que les ordres "APDU" échangés puissent être compatibles et compris par ces deux applications. Ces rappels étant effectués, il est à noter que la carte à puce 2 ne peut communiquer directement avec les navigateurs standards du commerce, sauf à modifier le code de ces derniers.
En outre, et surtout, les cartes à puce actuelles, qui par ailleurs sont conformes aux standards et normes rappelés ci-dessus, ont une configuration matérielle et logicielle qui ne permet pas non plus de communiquer directement avec le réseau Internet. En particulier, elles ne peuvent recevoir et transmettre des paquets de données, selon l'un ou l'autre des protocoles utilisés sur ce type de réseau. Il est donc nécessaire de prévoir une pièce de logiciel additionnelle, implantée dans le terminal 1 , généralement sous la forme de ce qui est appelé un "plug-in", selon la terminologie anglo-saxonne. Cette pièce de logiciel, qui porte la référence 12 sur la figure 1 B, effectue l'interface entre le navigateur 10 et la carte 2, plus précisément les circuits électroniques 20 de cette carte 2. L'invention vise à pallier les inconvénients des procédés et dispositifs de l'art connu, et dont certains viennent d'être rappelés, tout en répondant aux besoins qui se font sentir.
Selon une première caractéristique de l'invention, les deux programmes de chargement, OL et IL ne sont plus dépendants l'un de l'autre. En d'autres termes, ils n'ont plus à être appariés pour être compatibles.
Selon une deuxième caractéristique de l'invention, la partie OL des programmes de chargement n'a plus à être stockée obligatoirement dans le terminal, c'est-à-dire en relation de proximité physique avec la seconde partie IL. Tout au contraire, le programme OL peut être stocké sur un serveur éloigné, connecté au terminal via un réseau de type Internet.
Pour ce faire, et selon une autre caractéristique de l'invention, la carte à puce se comporte comme un serveur/client de type "WEB" pour le terminal qui lui est associé.
Pour atteindre ce but, 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'échanges de données bidirectionnels entre la carte à puce et le terminal, d'une part, et la carte à puce et le réseau, d'autre part.
Les couches logicielles de communication spécifiques comprennent notamment des composants logiciels, dits "agents intelligents", permettant en particulier des conversions de protocoles. Les agents intelligents seront appelés ci-après plus simplement "agents". Il existe des agents appareillés dans les couches de communication spécifiques respectives associées au terminal et à la carte à puce. Selon le procédé de l'invention, il s'établit des sessions entre agents appareillés. Selon une au re 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 particuliers dits traducteurs de script, qui reçoivent des requêtes d'un navigateur et les traduisent en ordres "APDU" compréhensibles par l'application de type "CGA". De ce fait, on implante dans la carte à puce une fonction similaire à celle connue par ailleurs sous la dénomination "CGI" dans les serveurs "WEB" classiques. Cette fonction permet de mettre en œuvre une application dans la carte à puce par un protocole Internet de type "HTTP".
Le chargement d'une "applet" dans la carte à puce peut s'effectuer par cette interface "CGI". La partie IL du programme de chargement est considéré comme étant un script de commandes, que l'on appellera "cgi- script", attaché à la fonctionnalité serveur "WEB" offerte par la carte à puce. Les échanges entre les programmes OL et IL peuvent se dérouler avec l'aide de formulaires classiques en langage "HTML" ou "forms" selon la terminologie anglo-saxonne. Tout en conservant les normes ISO précitées pour les communications entre terminal et carte à puce, via le lecteur de carte à puce, le procédé selon l'invention permet des échanges entre les parties de programmes de chargement OL et IL en faisant appel au protocole de communication Internet "TCP/IP", la partie OL et les "applets" à charger pouvant être stockées en local ou dans un serveur éloigné.
L'invention a donc pour objet principal un procédé de chargement d'une pièce de logiciel dans une carte à puce à partir d'un terminal connecté à ladite carte à puce par l'intermédiaire d'un lecteur de carte à puce permettant des communications selon un premier protocole déterminé, ledit chargement s'effectuant par la mise en œuvre et la coopération de premier et second programmes de chargement, ledit second programme de chargement étant stocké dans ladite carte à puce, 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, formant une couche protocolaire de communication spécifique ; b/ une deuxième phase préliminaire consistant à implanter, dans ledit terminal, une seconde pièce de logiciel, formant une couche protocolaire de communication spécifique ; en ce que lesdites première et seconde pièces de logiciel comprennent en outre au moins une paire de premières entités logicielles appariées, chacune desdites entités coopérant l'une avec l'autre de manière à permettre l'établissement d'une session d'échanges de données bidirectionnels entre au moins ledit terminal et ladite carte à puce, de manière à ce que ladite carte à puce offre la fonctionnalité d'un client/serveur "WEB" ; en ce qu'il comprend une troisième phase préliminaire consistant à implanter dans ladite carte à puce au moins une deuxième entité logicielle, apte à interpréter une suite d'instructions et à la traduire en une suite d'ordres, de manière à coopérer avec ladite seconde pièce de logiciel spécifique pour que ladite carte à puce offre une fonctionnalité d'interface passerelle dite "CGI", la dite carte à puce comprenant au moins une desdites suites d'instructions associée au dit second programme de chargement ; et en ce qu'il comprend au moins les étapes suivantes : 1/ ouverture d'une première session d'échanges de données entre au moins ledit terminal et ladite carte à puce, pour la transmission d'une requête pour que ledit premier programme de chargement récupère des données de paramétrage de chargement fournies par ledit second programme de chargement ; 2/ ouverture d'une deuxième session d'échanges de données entre ladite carte à puce et au moins ledit terminal pour transmettre lesdites données de paramétrage de chargement au dit premier programme de chargement, lesdites données de paramétrage comportant une référence aux dites instructions associées au dit second programme de chargement ; et
3/ ouverture d'une troisième session d'échanges de données entre au moins ledit terminal et ladite carte à puce, pour la soumission d'un fichier de chargement prenant en compte lesdites données de paramétrage de chargement, ledit fichier comprenant des données représentant ladite pièce de logiciel à charger; interprétation de ladite suite d'instructions associée au dit second programme de chargement, par mise en œuvre de ladite fonctionnalité "CGI", de manière générer une suite d'ordres transmise au dit second programme de chargement, à exécuter ce programme et à obtenir ledit déchargement de ladite pièce de logiciel.
L'invention va maintenant être décrite de façon plus détaillée en se référant aux dessins annexés, parmi lesquels : la figure 1A illustre schematiquement un exemple de réalisation d'une architecture permettant le chargement d'une "applet" dans une carte à puce selon l'art connu ; les figures 1 B et 1 C illustrent les architectures matérielle et logique, respectivement, d'un exemple de système d'application à base de carte à puce connecté à un réseau Internet selon l'art connu, ; - la figure 2 illustre schematiquement un exemple de système d'application à base de carte à puce selon l'invention, cette dernière agissant en tant que client/serveur "WEB" ; la figure 3 est un diagramme d'états d'une session entre des entités logicielles dites agents intelligents, selon un aspect de l'invention ; la figure 4 illustre de façon simplifiée l'architecture logique d'un système selon l'invention dans lequel la carte à puce comprend des agents intelligents ; la figure 5 illustre de façon simplifiée l'architecture logique d'un système selon l'invention dans lesquels la carte à puce comprend des agents intelligents traducteurs de scripts ; la figure 6 illustre schematiquement un exemple de réalisation d'une architecture permettant le chargement d'une "applet" dans une carte à puce selon l'invention ; - la figure 7 illustre la structure d'un fichier de chargement d'une
"applet" pouvant être en œuvre par le procédé selon l'invention ; la figure 8 illustre schematiquement les phases principales du procédé de chargement d'une "applet" dans une carte à puce selon un premier exemple de réalisation pratique ; - la figure 9 illustre schematiquement les phases principales du procédé de chargement d'une "applet" dans une carte à puce selon un deuxième exemple de réalisation pratique ; les figures 9 et 10 illustrent deux exemples de formulaires en langage "HTML" utilisables par le procédé de chargement d'une "applet" dans une carte à puce selon l'invention, pour la mise en œuvre des méthodes dites "GET" et "POST", respectivement ; et les figures 12A à 12G illustrent plusieurs variantes de réalisation de réalisation d'architectures de systèmes permettant le chargement d'une "applet" dans une carte à puce selon l'invention. Dans ce qui suit, sans en limiter en quoi que ce soit la portée, on se placera ci-après dans le cadre de l'application préférée de l'invention, sauf mention contraire, c'est-à-dire dans le cas d'un terminal connecté à un ou plusieurs serveurs éloignés via le réseau Internet.
Avant de décrire le procédé d'activation d'applications localisées dans une carte à puce selon l'invention et de détailler une architecture pour sa mise en œuvre, par référence à la figure 2, il apparaît tout d'abord utile de rappeler brièvement los caractéristiques principales des protocoles de communication sur les léseaux.
L'architecture des réseaux de communication est décrite par diverses couches. A titre d'exemple, le standard "OSI" ("Open System Interconnection"), défini par I' "ISO", comporte sept couches qui vont des couches dites basses (par exemple la couche dite "physique" qui concerne le support de transmission physique) aux couches dites hautes (par exemple la couche dite "d'application"), en passant par des couches intermédiaires, notamment la couche dite de "transport". Une couche donnée offre ses services à la couche qui lui est immédiatement supérieure et requiert de la couche qui lui immédiatement inférieure d'autres services, via des interfaces appropriées. Les couches communiquent à l'aide de primitives. Elles peuvent également communiquer avec des couches de même niveau. Dans certaines architectures, plusieurs couches peuvent être inexistantes. Dans un environnement de type Internet, les couches sont au nombre de cinq, et de façon plus précise, en allant de la couche supérieure à la couche inférieure : la couche dite d'application ("http", "ftp", "e-mail", etc.), la couche dite de transport ("TCP"), la couche dite d'adressage de réseau ("IP"), la couche dite de liens de données ("PPP", "Slip", etc.) et la couche dite physique.
Si on se reporte de nouveau à la figure 2, à 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, et il n'y a pas lieu de les re-décrire de façon détaillée.
Le terminal 1 comprend des circuits 11 d'accès au réseau RI, constitués par exemple d'un modem. Ces circuits regroupent les couches logicielles inférieures, Ci et C2, qui correspondent aux couches "physique" et de "lien de données". On a également représenté les couches supérieures, C3 et C4, qui correspondent aux couches "d'adressage de réseau" ("IP", dans le cas d'Internet) et de "transport" ("TCP"). La couche supérieure d'application ("http", "ftp", "e-mail", etc.) n'a pas été représentée. L'interface entre les couches inférieures, Ci et C2, et les couches supérieures, C3 et C4, est constituée par une couche logicielle généralement appelée "driver couches basses". Les couches supérieures, C3 et C4, s'appuient sur cette interface et sont mises en œuvre par l'intermédiaire de bibliothèques de fonctions spécifiques ou bibliothèques réseau 14, avec lesquelles elles correspondent. Dans le cas du réseau Internet, "TCP/IP" est mis en œuvre au moyen de bibliothèques dites de "sockets".
Cette organisation permet à un navigateur 10 de poser des requêtes vers un serveur 4, pour la consultation de pages "WEB" (protocole "HTTP"), pour le transfert de fichiers (protocole "FTP") ou l'envoi de courrier électronique (protocole "e-mail"), ce de façon tout à fait classique en soi.
Le terminal 1 comprend également un lecteur de carte 3, intégré ou non. Pour communiquer avec la carte à puce 2a, le lecteur de carte 30 englobe également deux couches basses, CC1 (couche physique) et CC2 (couche de lien de données), jouant un rôle similaire aux couches Ci et C2- Les interfaces logicielles avec les couches CC1 et CC2 sont décrites, par exemple, par la spécification "PC/SC" ("part 6, service provider"). Les couches elles-mêmes, CC1 et CC2, sont notamment décrites par les normes ISO 7816-1 à 7816-4, comme il a été rappelé. Une couche logicielle supplémentaire 16 forme interface entre les couches applicatives (non représentées) et les couches inférieures, CC1 et CC2. La fonction principale dévolue à cette couche 16 est une fonction de multiplexage/démultiplexage.
Les communications avec la carte à puce 2a s'effectuent selon un paradigme similaire à celui utilisé pour la manipulation de fichiers dans un système d'exploitation du type "UNIX" (marque déposée) : OUVRIR ("OPEN"), LIRE ("READ"), ECRIRE ("WRITE"), FERMER ("CLOSE"), etc.
Du côté de la carte à puce 2a, on retrouve une organisation similaire, à savoir la présence de deux couches basses, référencées CCai (couche physique) et CCa2 (couche de lien de données), ainsi qu'une couche d'interface 26a, tout à fait similaire à la couche 16.
Selon une première caractéristique de l'invention, on prévoit, de part et d'autre, c'est-à-dire dans le terminal 1 et dans la carte à puce 2a, deux couches de protocoles spécifiques : 13 et 23a, respectivement. Dans le terminal 1 , la couche spécifique 13 s'interface aux "drivers couches basses" 15, aux bibliothèques 14 des couches réseau, C3 et C4, et aux couches protocolaires du lecteur de carte 3, c'est-à-dire les couches inférieures, CC1 et CC2, via la couche de multiplexage 16. La couche spécifique 13 permet le transfert de paquets réseaux de et vers la carte à puce 2a. En outre, elle adapte les applications existantes telles le navigateur Internet 10, le courrier électronique, etc., pour des utilisations mettant en œuvre la carte à puce 2a.
Du côté de la carte à puce 2a, on retrouve une organisation tout à fait similaire constituée par une instance supplémentaire de la couche spécifique, référencée 23a, pendant de la couche 13.
De façon plus précise, les couches spécifiques, 13 et 23a, sont subdivisées en trois éléments logiciels principaux : un module, 130 ou 230a, de transfert de blocs d'informations entre les couches 13 et 23a, via les couches conventionnelles CC-| , CC2, CCai et CCa2 ; une ou plusieurs pièces de logiciel, dites "agents intelligents", 132 ou 232a, qui réalisent, par exemple, des fonctions de conversion de protocoles ; et un module de gestion de la configuration spécifique, 131 et 231a, respectivement ; module qui peut être assimilé à un agent intelligent particulier.
Pour simplifier, on appellera ci-après les agents intelligents, "agents", comme il a été précédemment indiqué.
On retrouve donc, dans le terminal 1 et la carte à puce 2a, une pile protocolaire de communication entre les deux entités.
Les couches de niveau deux (couches de lien de données), CC2 et
CCa2, assurent l'échange entre la carte à puce 2a et le terminal 1. Ces couches sont responsables de la détection et l'éventuelle correction d'erreurs de transmission. Différents protocoles sont utilisables, et à titre d'exemples non exhaustifs les suivants : la recommandation ETSI GSM 11.11 ; le protocole défini par la norme ISO 7816-3, en mode caractère T=0 ; le protocole défini par la norme ISO 7816-3, en mode bloc T=1
» ou le protocole défini par la norme ISO 3309, en mode trame "HDLC" (pour "High-Level Data Link Control procédure" ou procédure de commande de liaison à haut niveau).
Dans le cadre de l'invention, on utilisera de préférence le protocole ISO 7816-3, en mode bloc.
De façon connue en soi, à chaque couche de protocole, il est associé un certain nombre de primitives qui permettent les échanges de données entre couches de même niveau et d'une couche à l'autre. A titre d'exemple, les primitives associées à la couche de niveau deux sont du type
"demande de données" ("Data.request") et "envoi de données" par la carte
("Data.response"), ainsi que "confirmation de données" ("Data.confirm"), etc.
De façon plus spécifique, les couches 13 et 23a sont chargées du dialogue entre la carte à puce 2a et l'hôte, c'est-à-dire le terminal 1. Ces couches permettent I échange d'informations entre un utilisateur (non représenté) du terminal 1 et la carte à puce 2a, par exemple via des menus déroulants sous la forme d'hypertexte au format "HTML". Elles permettent aussi la mise en place d'une configuration adaptée pour l'émission et/ou la réception de paquets de données.
Comme il a été indiqué ci-dessus, les couches comprennent trois entités distinctes.
La première couche, 130 ou 230a, est essentiellement constituée par un multiplexeur logiciel. Elle permet l'échange d'informations entre la carte à puce 2a et le terminal hôte 1 , sous la forme d'unités de données de protocole. Elle joue un rôle similaire à celui d'un commutateur de paquets de données. Ces unités sont émises ou reçues via la couche de niveau deux
(couche de liens de données). Ce protocole particulier de communication permet de mettre en communications au moins une paire d' "agents". Le premier agent de chaque paire, 132, est situé dans la couche 13, côté terminal 1 , le second, 232a, est situé dans la couche 23a, côté carte à puce
2a. Une liaison entre deux "agents" est associée à une session, que l'on pourra appeler "S-Agent". Une session est un échange de données bidirectionnel entre ces deux agents. Si l'une ou l'autre des couches, 13 et 23a, comporte plusieurs agents, les agents d'une même couche peuvent aussi établir de sessions entre eux et/ou avec les modules 131 et 231a, qui constituent des agents particuliers.
De façon plus précise, un agent est une entité logicielle autonome qui peut réaliser tout ou partie de fonctions des couches de niveau trois et quatre, en fonction de la configuration mise en œuvre par le terminal 1.
Les agents sont associés à des propriétés ou attributs particuliers. Pour fixer les idées, et à titre d'exemple non limitatif, les six propriétés suivantes sont associées aux agents :
"hôte" : agent localisé dans le terminal ; - "carte" : agent localisé dans la carte à puce ;
"local" : agent ne communiquant pas avec le réseau ; "réseau" : agent communiquant avec le réseau (côté terminal) ; "client" : agent qui initialise une session ; "serveur" : agent qui reçoit une demande de session. Un agent particulier est identifié par une référence, par exemple un nombre entier de 16 bits (c'est-à-dire compris entre 0 et 65535). Le bit de poids fort (b15 = 1 ) indique si la référence est locale (communications locales à la carte à puce ou au terminal) ou distante (b15 = 0).
Il existe deux grandes catégories d'agents : les agents de type
"serveur", qui sont identifiés par une référence fixe, et les agents de type "client", qui sont identifiés par une référence variable, que l'on peut qualifier d'éphémère, délivrée par le module de gestion de configuration, 131 ou
231 a.
Les agents communiquent entre eux à l'aide d'entité dites "unités de donnée de protocole" ou "pdu" (pour "protocol data unit", selon la terminologie anglo-saxonne) constituant une référence de destination et une référence de source. On pourrait également appeler cette "pdu" particulière "SmartTP pdu", en référence au terme anglais "Smart Card" (carte à puce) couramment utilisé. Les "pdu" utilisent notamment les références définies ci- dessus. Une "SmartTP pdu", ou plus simplement "pdu" ci-après, comporte une référence source, une référence de destination, un ensemble de bits constituant des drapeaux ou "flags" qui précisent la nature de la "pdu", et des données optionnelles :
- le drapeau "OPEN" (ouvert) est positionné pour indiquer l'ouverture d'une session ;
- le drapeau "CLOSE" (fermé) indique la fermeture d'une session ; et
- Le drapeau "BLOCK" (verrouillé) indique que l'agent est en attente d'une réponse de son correspondant et suspend toute activité.
On appellera jeton une "pdu" qui ne comporte pas de données. L'entité "SmartTP" contrôle l'existence de l'agent destinataire et réalise la commutation d'un paquet vers ce dernier. Une session agent "S-Agent" possède trois états remarquables, à savoir :
- un état déconnecté : aucune session n'est ouverte avec un autre agent
- un état connecté : une session est ouverte avec un autre agent, une session "S-Agent" étant identifiée par une paire de références ; et
- un état bloqué, l'agent étant connecté et attendant une réponse de son correspondant.
Le mécanisme d'établissement d'une session "S-Agent" est le suivant : - une nouvelle instance d'un agent client est créée (côté carte à puce ou terminal), cet agent étant identifié par une référence éphémère pseudounique ;
- l'agent client émet une "pdu" à destination d'un agent serveur (dont la référence est connue par ailleurs) avec le drapeau "OPEN" positionné et l'agent client passe à l'état connecté ou bloqué selon la valeur du drapeau
"BLOCK" ; et
- l'agent serveur reçoit la "pdu" avec le drapeau "OPEN" et passe à l'état connecté
Une fois une session ouverte, deux agents échangent des données via des "pdu".
Le mécanisme de fermeture d'une session est le suivant :
- un agent émet une "pdu" avec le drapeau "CLOSE" positionné (et qui comporte éventuellement des données ; et
- l'autre agent reçoit une "pdu" avec le drapeau "CLOSE" positionné (et qui comporte éventuellement des données) et la session "S-Agent" passe à l'état déconnecté.
La figure 3 illustre de façon schématique le diagramme d'états des sessions "S-Agent", telles qu'elles viennent d'être rappelées.
Les couches 130 et 230a gèrent des tables (non représentées) qui contiennent la liste des agents présents, côté terminal hôte 1 et carte à puce 2a. De façon pratique, les agents permettent d'échanger des données (de l'hypertexte, par exemple), mais également de déclencher des transactions réseau, autorisant des communications entre la carte à puce 2a et un serveur éloigné 4 (figure 2). Les modules de gestion de configuration, 131 et 231a, respectivement, sont assimilables à des agents particuliers. Par exemple, le module 131 , côté terminal hôte 1 , gère notamment des informations relatives à la configuration de ce terminal (modes de fonctionnement), liste des autres agents présents, etc. Le module 231a, côté carte à puce 2a, a des fonctions analogues. Ces deux agents peuvent être mis en communication l'un avec l'autre pour établir une session.
De façon pratique, la carte à puce 2a est avantageusement "adressée" par utilisation d'une adresse "URL" (pour "Universal Resource Locator") définissant un rebouclage sur le terminal 1 lui-même, et non un pointage sur un serveur externe. A titre d'exemple, la structure de cette "URL" est habituellement la suivante : http://127.0.0.1 :8080 (1 ), dans laquelle 127.0.0.1 est l'adresse "IP" de rebouclage et 8080 est le numéro de port. La figure 4 illustre de façon simplifiée l'architecture logique d'un système selon l'invention du type représenté sur la figure 2, mais représenté de façon plus détaillée. La carte à puce 2a comprend plusieurs agents, dont deux seulement ont été représentés : un agent de type non précisément défini 232aι et un agent 232a2, de type dit "WEB". La pile logique comprend, les couches de protocole inférieures, référencées 200a, répondant aux normes ISO 7816-3 (figure 2 : CCai et CCa2), le gestionnaire de commandes "APDU" 201 a-\ , et le multiplexeur de paquets 230a, ce dernier étant interface aux agents, notamment l'agent "WEB" 23132-
Du côté terminal, il existe deux piles, l'une communiquant avec le réseau Internet RI, l'autre avec la carte à puce 2a. La première pile comprend les organes 11 (figure 2 : Ci et C2) d'accès au réseau (normes OSI 1 et 2) et les couches de protocole "TCP/IP" (figure 2 : C3 et C4), référencées 100. Ces dernières couches sont interfacées avec le navigateur "WEB" 10. L'autre pile comprend les couches de protocole inférieures, référencées 101 , répondant aux normes ISO 7816-3 (figure 2 : Ci et C2). le gestionnaire 102 d'ordres "APDU" et le multiplexeur de paquets 130, ce dernier étant interface avec des agents, dont un seul 132, est représenté. Ce dernier, que l'on supposera de "type réseau", peut en outre communiquer, d'une part avec le navigateur 10, via les couches "TCP/IP" 101 , d'autre part avec le réseau Internet RI, via ces mêmes couches "TCP/IP" 101 et l'organe 11 , d'accès au réseau RI.
Le gestionnaire d'ordres "APDU" 201a est également interface avec une ou plusieurs couches de niveau applications, que l'on appellera simplement applications. Ces applications, A„ ..., A„ ..., An, sont, comme il a été indiqué, des applications de type conventionnel.
En résumé, la fonction client/serveur "WEB", fournie par la carte à puce 2a, peut être réalisée par l'association de l'agent "WEB" 232aι dans la carte à puce et de l'agent réseau 132 dans le terminal 1 , et par la mise en œuvre de sessions entre agents, comme il a été décrit. La carte à puce 2a présente donc bien la fonctionnalité client/serveur "WEB". En outre, selon une caractéristique du procédé de l'invention, n'importe quelle application conventionnelle, A-\ à An, du type "CGA" précité, peut être activée au travers de ce client/serveur "WEB", soit par le navigateur "WEB" 10 présent dans le terminal 1 , soit par un navigateur éloigné 4, localisé en un point quelconque du réseau Internet RI, par la mise en œuvre de sessions entre agents. Selon le procédé de l'invention, les applications, A-\ à An, ne nécessitent pas d'être ré-écrites et sont mises en œuvre telles quelles.
Dans le cadre de l'invention, tout ou partie des applications A-\ à An peut être constituée par des "applets", chargées initialement dans une mémoire non volatile de la carte à puce 2 ou, au contraire, chargées par l'intermédiaire des deux programmes de chargement OL et IL, dont on précisera ci-après la nature et les lieux de stockage possible.
Selon un autre aspect de l'invention, la fonction serveur "WEB" offerte par la carte à puce inclut un mécanisme similaire à la fonction dite "CGI" (pour "Common Gateway Interface" ou "interface de passerelle") implantée dans les serveurs "WEB" classique.
Avant de décrire un exemple d'architecture conforme à l'invention, permettant de réaliser une fonction de ce type, au sein même de la carte à puce, il est utile de rappeler les principales caractéristiques d'un mode de fonctionnement "CGI".
Le "CGI" est une spécification de mise en œuvre, depuis un serveur "WEB", d'applications écrites pour les systèmes d'exploitation "UNIX" (marque déposée), "DOS", ou "WINDOWS" (marque déposée). A titre d'exemple, pour le système d'exploitation "UNIX", la spécification est "CGI 1.1 " et pour le système d'exploitation "WINDOWS 95", la spécification est "CGI 1.3".
Toujours à titre d'exemple, une requête "HTTP" pour une adresse "URL", du type : "http://www.host.com/cgi-bin/xxx.cgi" (2), dans laquelle "host" se réfère à un système hôte (généralement éloigné), est interprétée par un serveur "WEB" comme l'exécution d'un script de commande, de type "CGI" nommé "xxx" et présent dans le répertoire "cgi- bin" de ce système hôte. Bien que le nom du répertoire puisse être a priori quelconque, par convention, c'est le nom donné au répertoire stockant les scripts de type "CGI". Un script est une suite d'instructions du système d'exploitation du système hôte dont le résultat final est transmis au navigateur "WEB" émetteur de la requête précitée. Différents langages peuvent être utilisés pour écrire ce script, par exemple le langage "PERL" (marque déposée). De façon pratique, la requête est habituellement affichée sur un écran informatique sous la forme d'un formulaire compris dans une page "HTLM". Le langage "HTLM" permet de traduire un formulaire en une adresse "URL". Le formulaire comporte un ou plusieurs champs, obligatoires ou non, qui sont remplis par un utilisateur à l'aide des moyens de saisie habituels : clavier pour le texte, souris pour les cases à cocher ou les boutons dits "radio", etc. Le contenu du formulaire (ainsi qu'éventuellement des informations et instructions dites "cachées") est émis à destination du serveur "WEB". Le code "HTLM" de la page décrit la structure matérielle du formulaire (cadre, graphisme, couleur, et tout autre attribut), ainsi que la structure des champs de données à saisir (nom, longueur, type de données, etc.).
La transmission peut s'effectuer selon deux types de formats principaux. Un premier format utilise la méthode dite "POST" et un second la méthode dite "GET". Une information de type de format est présente dans le code de la page formulaire.
Ce mécanisme n'est cependant pas directement transposable à une carte à puce, même si celle-ci offre la fonctionnalité client/serveur "WEB" conformément à l'une des caractéristiques de l'invention. On va maintenant décrire un exemple d'architecture permettant d'activer une application quelconque, de type conventionnel, via un serveur "WEB" sur la carte à puce, par référence à la figure 5.
Parmi les agents intelligents, conforme à l'un des aspects de l'invention, on prévoit des agents intelligents particuliers, que l'on appellera ci-après "Agents traducteurs de script" ou de façon abrégée "ATS". Le script est alors interprété par un des agents intelligents. Cette traduction peut être réalisée de différentes manières : a/ par l'agent "WEB" 232aι lui-même, qui est doté dans ce cas d'une double capacité ; b/ par un agent script unique capable de traduire l'ensemble des scripts présents dans la carte à puce 2a ; c/ par un agent de script dédié que l'on appellera "ATSD" ci-après (un agent par script) ; ou 61 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 est une couche capable de centraliser tous les ordres "APDU" émis et/ou reçus par le système, de sélectionner des applications, parmi A à An, mais également d'offrir une interface de type agent intelligent. Elle est donc capable, selon l'une des caractéristiques de l'invention de communiquer avec tous les agents intelligents (via des sessions), que ces agents soient localisés dans l'enceinte 6 ou la carte à puce 2a. Dans le cas c/ ci-dessus, une session est ouverte entre l'agent
"WEB" 232aι et l'un des agents "ATSD".
La figure 5 illustre un exemple d'architecture pour laquelle les agents traducteurs sont du type "ATSD". Ils sont référencés ATS à ATSn et associés aux applications / 1 à 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" 2101a. Les ordres sont alors émis vers l'agent "APDU" 2101a. Le gestionnaire d'ordres "APDU" 210a sélectionne l'application "CGA" At et lui transmet les ordres "APDU", ordres traduits et donc conventionnels, qu'elle est en mesure de comprendre. Cette application est donc correctement activée, sans avoir à la modifier ou à la réécrire. Les réponses de l'application At sont transmises au gestionnaire d'ordres "APDU" 210a, à l'agent "APDU" 2010a, puis de nouveau à l'agent ATS. (et de façon plus générale à l'agent traducteur de script).
Les différents cheminements sont représentés symboliquement sur la figure 5 par des traits pleins reliant les blocs fonctionnels, ou en pointillés à l'intérieur de ces blocs.
Le procédé selon l'invention utilise les deux caractéristiques qui viennent d'être rappelées : fonctionnement de la carte à puce en tant que serveur/client "WEB", incluant une fonction "cgi". Le chargement d'une "applet" dans la carte à puce s'effectue en effet via l'interface "CGI" offerte par celle-ci.
De façon plus précise, selon une caractéristique de l'invention, la partie de programme de chargement IL, localisée dans la carte à puce 2a, est constituée par un script. Il s'agit, par exemple, d'un script associé à l'application référencée A sur la figure 5. Ce script est, selon une caractéristique du procédé de l'invention, activé par une requête "HTTP", les échanges entre la partie OL et la partie IL s'effectuant selon le protocole de communication "TCP/IP". Les programmes IL et OL deviennent de ce fait a priori compatibles. En outre, il n'est plus nécessaire que la proximité physique soit respectée, comme dans l'art connu (voir figure 1 ). La partie OL peut désormais être localisée dans le terminal ou, de préférence, dans un serveur éloigné (les liaisons entre le serveur et le terminal s'effectuant suivant le protocole "TCP/IP"), voire, comme il le sera montré, être stockée dans la carte à puce elle-même. La requête "HTTP" précitée est initiée par la partie OL.
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 constituée par le "Multiplexeur de paquets" 230a. Le gestionnaire d'ordres "APDU" 201a sélectionne cette application de manière tout à fait similaire aux autres applications de type "CGA", A-\ à An, présentes dans la carte à puce 2a. En d'autres termes, le multiplexeur de paquets 230a est vu par le gestionnaire d'ordres "APDU" 201a comme une application "CGA" ordinaire.
La requête "HTTP" est analysée par l'agent "WEB" 232aι qui détecte une référence à un répertoire particulier, que l'on appellera ci-après par convention "cgi-smart" (par analogie à "cgi-bin"), d'une part, et à une application particulière, IL dans le cas de l'exemple décrit. Le chemin complet est donc, en l'occurrence "cgi-smart/il".
Selon une caractéristique du procédé de l'invention, l'entité "il" ci- dessus désigne un script particulier associé une application également particulière (IL en l'occurrence).
Une session est ouverte entre l'agent traducteur, par exemple l'agent ATS\, et l'agent "APDU" 2010a. L'agent traducteur de script ATS\ génère une suite d'ordres "APDU". Les ordres sont émis vers l'agent "APDU" 2010a. Le gestionnaire d'ordres "APDU" 201a sélectionne l'application "CGA" Aj (par exemple l'application IL) 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.
La réponse de l'application IL (Aj) est transmise en sens inverse au gestionnaire d'ordres "APDU" 201a, à l'agent "APDU" 2010a, puis de nouveau à l'agent ATSj (et de façon plus générale à l'agent traducteur de script).
La réponse, constituée par un formulaire en langage "HTLM" reprend le chemin inverse, par la mise en œuvre de sessions entre agents intelligents appariés, pour être re-transmise au terminal 1 et, éventuellement à un serveur éloigné 4 (figure 4), via le réseau Internet RI, pour atteindre finalement l'application OL.
La figure 6 illustre schematiquement l'architecture logique permettant le chargement d'une "applet" selon le procédé de l'invention. On retrouve sur ce schéma les blocs matériels constitués par le terminal 1 , le lecteur de carte à puce 3 et la carte à puce 2a, communiquant par mise en œuvre du protocole normalisé ISO 7816 précité et l'échange d'ordres "APDU", de manière classique en soi. La partie OL est mise en relation avec la partie IL (sous forme d'un script référencé ILs), par des échanges selon le protocole Internet "TCP/IP", de la manière décrite précédemment, par mise en œuvre des fonctions serveur "HTTP" (référencé SC) et "CGI" de la carte à puce 2a.
On doit bien comprendre que, bien que représentés à l'extérieur de la carte à puce 2a pour des raisons de commodité, les blocs SC et ILs sont constitués par différents modules internes de celle-ci, qui ont été décrits par référence à la figure 5.
Par contre, le programme OL n'est pas obligatoirement stocké dans le terminal 1.
On va maintenant détailler un premier exemple de chargement d'une "applet" dans une carte à puce 2a, par mise en œuvre de la méthode dite "GET".
On suppose que le fichier de chargement de I' "applet", référencé 7, présente la structure illustrée par la figure 7 : une entête 70, un corps principal 71 constitué par du "Byte Code" en langage "JAVA" et une signature électronique 72. L'entête représente un identifiant d'une application particulière, généralement appelé "Application Identifier" ou simplement "AID". La signature électronique 72 est un mot chiffré avec une clé publique ou privée, obtenu à partir du code 71. L'ensemble du fichier 7 peut également être chiffré, pour des raisons de confidentialité, lorsqu'il s'agit d'applications dites sensibles. Optionnellement, on peut prévoir une ou plusieurs signature(s) électronique(s) supplémentaire(s) non représentée(s).
Les principales étapes du processus sont illustrées schematiquement par la figure 8.
Pendant une première étape, la partie de programme de chargement OL récupère, par une commande de type "GET", un formulaire de chargement à partir de la carte à puce 2a, formulaire en langage "HTML" que l'on appellera arbitrairement "download. html".
Cette récupération est effectuée en consultant une page correspondante dont l'URL est typiquement de la forme suivante : http://127.0.0.1 :8080/download.html (3), dans laquelle http://127.0.0.1 :8080 est l'adresse URL de rebouclage proprement dite, telle qu'elle a été définie par la relation (1 ), et "download.html" la page "HTML" à obtenir. Cette requête met en œuvre une session entre agents intelligents comme il a été décrit en regard des figures 2 à 4, selon un premier aspect de l'invention. La carte à puce 2a joue alors le rôle d'un serveur "WEB".
La carte à puce 2a envoie le formulaire "download.html" lors d'une deuxième étape, toujours par ouvertures de sessions entre agents intelligents appariés, selon le procédé de l'invention. Le formulaire obtenu peut être affiché sur un écran 5 par l'intermédiaire du navigateur 10.
Pour fixer les idées, un exemple d'un tel formulaire 8 est illustré par la figure 9. Outre diverses zones graphiques et de textes 80 (titre, etc.), le formulaire comprend des zones d'affichage pour l'entête 70 du fichier de chargement 7, le "Byte Code" 71 et la signature 72. La zone d'affichage 71 est du type dit "TEXTAREA" en langage "HTML" et présente une facilité dite d' "ascenseur" pour l'affichage déroulant de textes longs. Les informations correspondantes, telles qu'elles apparaissent sur la figure 9, sont purement arbitraires. Enfin, on prévoit, de façon classique en soi, un bouton d'envoi "send", référencé 81 , et un bouton de remise à zéro "reset", référencé 82. Ces boutons sont à la disposition d'un utilisateur du terminal (non représenté). Le bouton d'envoi 81 permet de valider le formulaire et le retransmet à la carte à puce 2a ("soumettre le fichier de chargement" sur la figure 8) et le bouton de remise à zéro 82 permet d'effacer les informations affichées et de ré-initialiser le formulaire. Le code "HTML" nécessaire pour programmer un tel formulaire est bien connu en soi et est à la portée de l'homme de métier. Il n'est pas nécessaire de le détaillor de nouveau. On peut cependant indiquer qu'il contient notamment une ligne de code en langage "HTML" qui se présente typiquement sous la forme :
<form action="http://127.0.01 :8080/cgi-smart/loader"> (4), dans laquelle http://127.0.01 :8080 est l'URL de rebouclage de la relation (1 ), cgi-smart le répertoire "CGI" précité contenant le script de chargement "loader" que l'on a appelé "il", script associé à la partie IL du programme de chargement.
Si l'affichage visuel du formulaire 8 sur l'écran 5 n'est pas souhaité (par exemple s'il n'y a pas d'opérateur humain, les informations peuvent être cachées incorporant le paramètre "HTML" suivant : "TYPE=hidden" dans la ligne de code (4) précitée.
Lors d'une troisième étape, la partie OL envoie une requête "HTTP" de type "GET" à la carte à puce 2a, toujours par ouverture de sessions entre des agents intelligents appariés. En faisant appel à la fonction "CGI" offerte par la carte à puce 2a, telle qu'elle a été décrite en regard de la figure 5, l'application IL s'exécute, le serveur "WEB" formé par la carte à puce 2a passant les paramètres de la requête "HTTP" à cette dernière application.
La requête précitée contient une ligne de code typiquement de la forme suivante :
Smart/loader?AID=xxx&ByteCode=yyy&Signature=zzz (5),
Dans laquelle "xxx" est l'entête 70 ("2001 " dans l'exemple de la figure 9), "yyy" est le "Byte Code" 71 ("0123456789ABCDEF" dans l'exemple de la figure 9) et "zzz" la signature électronique 71 ("0123456789ABCDEF" dans l'exemple de la figure 9). Les trois parties du fichier de chargement sont donc bien insérées dans trois champs du formulaire "HTML" 8, sous forme concaténée.
Le chargement d'une "applet" particulière identifiée par l'entête 70 a lieu à ce moment. Enfin, lors d'une quatrième étape un code de retour est transmis de la partie IL à la partie OL, toujours par mise en œuvre de sessions entre agents appariés. Il s'agit en général d'un simple acquittement ou, si l'opération ne s'est pas réalisée correctement d'un code d'erreur. Dans ce dernier cas, il est nécessaire de renouveler les étapes 1 à 4.
Comme solution alternative, il est possible d'utiliser la méthode "POST" précitée. Pour fixer les idées, la figure 10 illustre un exemple d'un tel formulaire référencé 8'. On retrouve diverses zones de texte et de graphique 80, une zone d'affichage de l'entête 70 et une zone d'affichage de la signature électronique 72, ainsi que des boutons d'envoi "send" 81 et de remise à zéro "Reset" 82. Ces éléments jouent un rôle tout à fait similaire aux éléments de mêmes référence de la figure 9 et il est inutile de les redécrire. Par contre, la zone d'affichage 71 ' ne visualise plus explicitement le "Byte Code", mais un répertoire ou un sous-répertoire où le code de I' "applet" à charger est enregistré. En l'occurrence, cette zone pointe sur un fichier, appelé arbitrairement "APPLET.BIN", enregistré sur une unité de stockage appelée "C", qui peut être un disque dur présent dans le terminal 1. Un bouton supplémentaire de navigation "browse" 83 permet de balayer les divers (sous-)répertoires de ce disque et de sélectionner un fichier particulier ("APPLET.BIN").
La méthode "POST" comme la méthode "GET" est bien connue en soi, et il est inutile de la re-déc re en détail. Dans le cadre précis de l'invention, I' "applet" correspondant au fichier "APPLET.BIN" est chargée, à partir de l'unité "C", de manière similaire à ce qui a été décrit pour la méthode "GET".
On va maintenant décrire un deuxième exemple de chargement d' "applet" dans la carte à puce 2a.
Il est également possible d'enchaîner plusieurs formulaires lors du chargement. A la place d'un simple statut (acquittement ou code d'erreur dans le premier exemple décrite en regard de la figure 8), le retour de la partie IL contient alors un nouveau formulaire. Ainsi, des séquences dynamiques d'échanges entre les parties OL et IL peuvent être réalisées. Par exemple, après analyse du fichier de chargement, la partie IL peut demander une autorisation (c'est-à-dire une signature électronique) supplémentaire, par exemple celle d'une instance gouvernementale. Elle renvoie alors à la OL un formulaire qui peut avoir typiquement la structure "HTML" suivante (6) :
<TITLE>Authorisation form </TITLE>
<FORM ACTION="http://@carte:8080/cgi-smart/loader">
<INPUT TYPE="text" NAME="GouvSignature" MAXLENGTH="8">Signature
</FORM>
dans laquelle "Authorisation form", entre les balises "HTLM" dénommées
"<TITLE>" et </TITLE>, représente le titre (arbitraire) du formulaire, "@carte" la traduction littérale de l'adresse URL de rebouclage de la relation (1 ) et 8080 le numéro de port, la ligne de code :
<INPUT TYPE="text" NAME="GouvSignature" MAXLENTH="8">Signature
(7) requiert l'entrée d'une variable appelée arbitrairement "Signature", en mode texte, de longueur maximale 8 octets, et </FORM> est la balise "HTML" indiquant la fin du code de formulaire.
Le processus complet comprend alors deux étapes supplémentaires avant l'étape finale d'acquittement ou de code d'erreur, soit six étapes, comme illustré par la figure 11.
De façon plus générale, le nombre d'allers et retours peut dépendre de paramètres figurant dans l'un ou l'autre des formulaires échangés entre la carte à puce et la partie OL des programmes de chargement.
Jusqu'à ce point, la localisation de la partie OL n'a pas été précisée expressément. Outre le fait que le procédé rend, a priori, compatible OL et
IL, il permet aussi une très grande souplesse précisément quant à cette localisation, étant entendu que la partie IL est stockée dans la carte à puce
2a comme formant l'une des applications présente dans cette carte à puce.
Le procédé selon l'invention présente notamment l'avantage supplémentaire de ne plus exiger une proximité physique entre les deux parties OL et IL, puisqu'elles ne sont plus tributaires du protocole de communication ISO 7816, les échanges entre ces deux portions de logiciel mettant en œuvre le protocole de communication Internet TCP/IP. Aussi, la partie OL, ainsi que les données proprement dites de
I' "applet" à charger sur la carte à puce 2a peuvent être stockées soit en local, soit dans un site éloigné. Dans tous les cas cependant, les échanges entre ces deux parties mettent en œuvre, comme il vient d'être rappelé, un protocole de communication "TCP/IP" et le chargement d'une "applet" se déroule comme il a été rappelé précédemment grâce aux fonctions de serveur/client "WEB" et "CGI" offertes par la carte à puce 2a.
On va décrire maintenant, par référence aux figures 12A à 12G, les principales architectures pouvant être mises en œuvre dans le cadre de l'invention. La figure 12 A illustre une architecture de système selon laquelle la partie OL est stockée en local sur le terminal 1. Celui-ci est connecté à un serveur éloigné 4, via le réseau Internet RI. Les données de I' "applet" à charger dans la carte à puce 2a, référencées Da, sont stockées sur ce serveur 4. Une requête "HTTP" permet de les transférer vers la carte à puce 2a, via le terminal 1 (et un lecteur de carte à puce non représenté), par mise en œuvre du protocole de communication Internet "TCP/IP".
Dans l'architecture de système représentée sur la figure 12B, la partie de programme de chargement OL et les données Da sont stockées localement dans le terminal 1. La connexion du terminal 1 au réseau Internet RI est optionnelle. Pour le moins, elle n'est pas requise pour le chargement d'une "applet" selon les étapes du procédé de l'invention. Cette connexion a été représentée en traits pointillés. Le terminal peut donc être autonome.
Dans l'architecture de système représentée sur la figure 12C, la partie de programme de chargement OL et les données Da sont stockées dans un serveur distant 4. Les communications entre le serveur 4 et la carte à puce 2a, via le réseau Internet RI, le terminal 1 et le lecteur de carte à puce (non représenté) î'effectue par des requêtes "HTTP", et mise en œuvre du protocole "TCP/IP".
L'architecture de système représentée sur la figure 12D est similaire à celle de la figure 12C. La seule différence est que la partie de programme de chargement OL est stockée dans un premier serveur distant, référencé
4a, et que les données Da, sont stockées dans un second serveur distant, référencé Ab.
Dans l'architecture de la figure 12E, la partie du programme de chargement, référencée ici OL', est constituée par un composant du navigateur 10 lui-même. Il s'agit avantageusement d'une "applet" intégrée dans ce navigateur. Le type d'entrée à utiliser dans ce cas est "file" (fichier).
De façon avantageuse également, les données Da, de I' "applet" à charger sur la carte à puce 2a, peuvent être stockées sur un support d'enregistrement de données externe 9, par exemple une disquette comme illustré par la figure 12E. Naturellement d'autres supports sont utilisables :
CédéROM, bande magnétique, etc.
Si on utilise la méthode "POST" précitée, il suffit de spécifier la lettre de l'unité dé stockage, par exemple "A" pour la disquette 9, un éventuel chemin (répertoire, sous-répertoires) et le nom du fichier à charger. Pour fixer les idées, le chemin complet pourrait être typiquement :
A:\APPLET.BIN (8)
Du fait de la fonction serveur/client "WEB" offerte par la carte à puce 2a, selon une des caractéristiques du procédé de l'invention, le navigateur 10 est à même, contrairement à l'art connu, de communiquer directement avec cette dernière, comme il l'a été montré en regard des figures 2 à 4. Les communications s'effectuent par l'ouverture de sessions entre agents appariés.
L'architecture de système illustrée par la figure 12F est une variante de l'architecture de la figure 12E. Selon cette variante, la partie de programme de chargement OL est stockée dans la carte à puce 2a elle- même, sous forme d'une "applet" en langage "JAVA". Par une requête "HTTP", cette "applet" peut être chargée dynamiquement sur le terminal 1 , en OL". Ce chargement s'effectue à l'aide de requêtes posées par le navigateur 10, lors d'étapes préliminaires. Une fois la partie OL chargée, les étapes ultérieures sont communes au cas précédent. Les données Da peuvent également être stockées sur un support externe, par exemple une disquette 8.
L'architecture de système de la figure 12G est une variante de celle de la figure 12F. La seule différence est que la partie de programme de chargement OL est stockée sur un serveur éloigné 4, sous forme d'une "applet" en langage "JAVA". Comme précédemment, par une requête "HTTP", cette "applet" peut être chargée dynamiquement sur le terminal 1 , en OL". Ce chargement s'effectue à l'aide de requêtes posées par le navigateur 10, lors d'étapes préliminaires. Les autres étapes sont communes au cas précédent. II est clair que d'autres variantes d'architecture peuvent être mises en œuvre sans sortir du cadre de l'invention. Il est notamment possible de charger les données Da dans le terminal 1 à partir de diverses sources : par exemple à partir d'un autre système informatique, connecté au terminal 1 par un réseau local ou par tous autres moyens télématiques. 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.
La mise en œuvre du chargement d'une "applet" dans une carte à puce par l'interface "CGI" d'un serveur "WEB" logé dans cette carte à puce présente notamment les avantages suivants : L'utilisation de formulaires en langage "HTML" standardise le chargement et rend les parties de programmes de chargement OL et IL a priori compatibles. En effet, comme il a été montré, c'est la partie IL située dans la carte à puce qui décrit, dans les champs du ou des formulaire(s) renvoyé(s), le paramétrage de chargement auquel il s'attend. Par ailleurs, ce mécanisme de communication entre les parties de programme de chargement OL et IL permet de gérer simplement des séquences d'échanges dynamiques lors du chargement.
L'utilisation des protocoles Internet "HTTP" et "TCP/IP" pour les échanges entre les parties de programme de chargement OL et IL permet de les séparer physiquement. Seul un routage de paquets "IP" est nécessaire sur le terminal. Le chargement peut alors se faire dans un lecteur carte à puce banalisé, puisque l'on conserve le protocole de communication ISO 7816. Le terminal peut être un simple micro-ordinateur standard connecté à Internet.
Selon un aspect avantageux également du procédé de l'invention, les applications stockées dans la carte à puce restent standards, et donc n'ont pas à être ré-écrites. La carte à puce et le terminal eux-mêmes ne nécessitent que peu de modifications pour pouvoir accommoder le procédé de l'invention : ces dernières se résument à l'implantation, dans ces deux unités, d'une couche logicielle de protocole de communication qui a été appelée spécifique, couche logicielle incluant des agents intelligents.
Alternativement, la partie de programme de chargement OL peut être chargée dynamiquement sur le terminal, au travers la carte, à partir de celle-ci ou d'un serveur "HTTP" éloigné.
Un simple navigateur Internet peut être utilisé comme programme de chargement OL.
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 à 12G.
D'autre part, en lieu et place du langage "HTML", d'autres langages similaires, adaptés aux protocoles de communication de type "Internet" peuvent être utilisés, notamment le langage "XML".
L'invention concerne aussi un procédé de chargement d'une pièce de logiciel dans une carte à puce à partir d'un terminal connecté à ladite carte à puce par l'intermédiaire d'un lecteur de carte à puce permettant des communications selon un premier protocole déterminé, le terminal et la carte à puce comprenant des moyens de traitement d'information et des moyens de stockage d'information, ledit chargement s'effectuant par la mise en œuvre et la coopération de premier et second programmes de chargement, ledit second programme de chargement étant stocké dans les moyens de stockage d'information de ladite carte à puce, caractérisé en ce qu'il comprend au moins les phases suivantes : a/ une première phase préliminaire consistant à implanter, dans les moyens de stockage d'information de ladite carte à puce (2a), une première pièce de logiciel (23a), formant une couche protocolaire de communication spécifique ; b/ une deuxième phase préliminaire consistant à implanter, dans les moyens de stockage d'information dudit terminal (1 ), une seconde pièce de logiciel (13), formant une couche protocolaire de communication spécifique ; en ce que lesdites première et seconde pièces de logiciel (13, 23a) comprennent en outre au moins une paire de premières entités logicielles appariées (132, 232a), chacune desdites entités (132, 232a) coopérant l'une avec l'autre, grâce auxdits moyens de traitement d'information du terminal et de la carte à puce, de manière à permettre l'établissement d'une session d'échanges de données bidirectionnels entre au moins ledit terminal (1) et ladite carte à puce (2a), de manière à ce que ladite carte à puce (2a) offre la fonctionnalité d'un client/serveur "WEB" ; en ce qu'il comprend une troisième phase préliminaire consistant à implanter dans les moyens de stockage d'information de ladite carte à puce
(2a) au moins une deuxième entité logicielle (ATS, - ATSn), apte à interpréter une suite d'instructions et à la traduire en une suite d'ordres, de manière à coopérer avec ladite seconde pièce de logiciel spécifique (23a) pour que ladite carte à puce offre une fonctionnalité d'interface passerelle dite "CGI", la dite carte à puce comprenant au moins une desdites suites d'instructions associée au dit second orogramme de chargement (IL) ; et en ce qu'il comprend au moins les étapes suivantes :
1/ ouverture d'une première session d'échanges de données entre au moins ledit terminal (1 ) et ladite carte à puce (2a) grâce auxdits moyens de traitement d'information du terminal et de la carte à puce, pour la transmission d'une requête pour que ledit premier programme de chargement (OL) récupère des données de paramétrage de chargement fournies par ledit second programme de chargement (IL) ;
2/ ouverture d'une deuxième session d'échanges de données entre ladite carte à puce (2a) et au moins ledit terminal (1 ) grâce auxdits moyens de traitement d'information du terminal et de la carte à puce, pour transmettre lesdites données de paramétrage de chargement au dit premier programme de chargement (OL), lesdites données de paramétrage comportant une référence aux dites instructions associées au dit second programme de chargement (IL) ; et
3/ ouverture d'une troisième session d'échanges de données entre au moins ledit terminal (1 ) et ladite carte à puce (2a) grâce auxdits moyens de traitement d'information du terminal et de la carte à puce, pour la soumission d'un fichier de chargement (7) prenant en compte lesdites données de paramétrage de chargement, ledit fichier comprenant des données (70, 71 , 72) associées à ladite pièce de logiciel à charger (Da) ; interprétation de ladite suite d'instructions associée au dit second programme de chargement (IL), par mise en œuvre de ladite fonctionnalité "CGI", de manière à générer une suite d'ordres transmise au dit second programme de chargement (IL), à exécuter ce programme (IL) et à obtenir ledit déchargement de ladite pièce de logiciel (Da).

Claims

REVENDICATIONS
1. Procédé de chargement d'une pièce de logiciel dans une carte à puce à partir d'un terminal connecté à ladite carte à puce par l'intermédiaire d'un lecteur de carte à puce permettant des communications selon un premier protocole déterminé, ledit chargement s'effectuant par la mise en œuvre et la coopération de premier et second programmes de chargement, ledit second programme de chargement étant stocké dans ladite carte à puce, 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 (23a), formant une couche protocolaire de communication spécifique ; b/ une deuxième phase préliminaire consistant à implanter, dans ledit terminal (1 ), une seconde pièce de logiciel (13), formant une couche protocolaire de communication spécifique ; en ce que lesdites première et seconde pièces de logiciel (13, 23a) comprennent en outre au moins une paire de premières entités logicielles appariées (132, 232a), chacune desdites entités (132, 232a) coopérant l'une avec l'autre de manière à permettre l'établissement d'une session d'échanges de données bidirectionnels entre au moins ledit terminal (1 ) et ladite carte à puce (2a), de manière à ce que ladite carte à puce (2a) offre la fonctionnalité d'un client/serveur "WEB" ; en ce qu'il comprend une troisième phase préliminaire consistant à implanter dans ladite carte à puce (2a) au moins une deuxième entité logicielle (ATS, - ATSn), apte à interpréter une suite d'instructions et à la traduire en une suite d'ordres, de manière à coopérer avec ladite seconde pièce de logiciel spécifique (23a) pour que ladite carte à puce offre une fonctionnalité d'interface passerelle dite "CGI", la dite carte à puce comprenant au moins une desdites suites d'instructions associée au dit second programme de chargement (IL) ; et en ce qu'il comprend au moins les étapes suivantes :
1/ ouverture d'une première session d'échanges de données
5 entre au moins ledit terminal (1 ) et ladite carte à puce (2a), pour la transmission d'une requête pour que ledit premier programme de chargement (OL) récupère des données de paramétrage de chargement fournies par ledit second programme de chargement (IL) ;
2/ ouverture d'une deuxième session d'échanges de données w entre ladite carte à puce (2a) et au moins ledit terminal (1) pour transmettre lesdites données de paramétrage de chargement au dit premier programme de chargement (OL), lesdites données de paramétrage comportant une référence aux dites instructions associées au dit second programme de chargement (IL) ; et
15 3/ ouverture d'une troisième session d'échanges de données entre au moins ledit terminal (1 ) et ladite carte à puce (2a), pour la soumission d'un fichier de chargement (7) prenant en compte lesdites données de paramétrage de chargement, ledit fichier comprenant des données (70, 71 , 72) associées à ladite pièce de logiciel à charger 0 (Da) ; interprétation de ladite suite d'instructions associée au dit second programme de chargement (IL), par mise en œuvre de ladite fonctionnalité "CGI", de manière à générer une suite d'ordres transmise au dit second programme de chargement (IL), à exécuter ce programme (IL) et à obtenir ledit déchargement de ladite pièce de 5 logiciel (Da).
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 selon ledit premier protocole déterminé, définies par la norme ISO 7816,
30 chacune comprenant au moins des couches protocolaires de communication logicielles (101 , 200a), dites basses, de manière à permettre lesdits échanges de données entre ladite carte à puce (2a) et ledit terminal (1 ), ces couches formant interface avec lesdites première (13) et seconde (23a) pièces de logiciel spécifique formant lesdites couches protocolaires de communication spécifiques, respectivement, et en ce que ces pièces de logiciel (13, 23a) comprennent chacune deux entités supplémentaires constituées d'un module de transfert de données (130, 230a), formant interface avec lesdites couches basses (101 , 200a) des première et deuxième piles protocolaires, et d'un module de gestion (131 , 231a), et en ce que lesdites premières entités de chaque paire sont constituées de modules logiciels, dits agents intelligents (132, 232a1 ) établissant lesdites sessions.
3. Procédé selon la revendication 2, caractérisé en ce que ladite suite d'instructions à interpréter associée au dit second programme (IL) de déchargement est constituée par un script et en ce que ladite deuxième entité logicielle est constituée par un module logiciel dit agent intelligent traducteur de script (ATS, - ATSn) fournissant des ordres compréhensibles par ledit second programme de chargement (OL).
4. Procédé selon la revendication 3, caractérisé en ce que ladite première étape comprend l'émission d'une requête de type dit "HTTP" selon un protocole de type Internet par adressage d'une page déterminée en langage "HTML" contenant lesdites données de paramétrage, ladite adresse étant une adresse de type "URL" de rebouclage sur ladite carte à puce (2a).
5. Procédé selon la revendication 4, caractérisé en ce que ladite deuxième étape comprend l'envoi par ladite carte à puce (2a) d'un formulaire (8, 8') en langage "HTML" et en ce que ledit formulaire (8, 8') comprend au moins une adresse de type dit "URL" de rebouclage sur ladite carte à puce (2a) et un chemin menant à un répertoire déterminé contenant ledit script associé au dit second programme de chargement (IL), de manière à ce que ce dit premier programme de chargement (OL) récupère les dites données de paramétrage.
6. Procédé selon la revendication 5, caractérisé en ce que ladite troisième étape comprend l'envoi d'une requête de type dit "HTTP" à ladite adresse
"URL", désignant ledit répertoire contenant ledit script associé au dit second programme de chargement (IL), ladite requête comprenant lesdites données représentant ladite pièce de logiciel à charger (Da), l'interprétation dudit script et l'exécution dudit second programme de chargement (OL), de manière à obtenir ledit chargement de la dite pièce de logiciel (Da).
7. Procédé selon la revendication 6, caractérisé en ce que ladite pièce de logiciel (Da) est une appliquette écrite en langage "JAVA" (marque déposée).
8. Procédé selon la revendication 7, caractérisé en ce que ledit fichier de chargement (7) est incorporé dans ledit formulaire (8, 8') et comprend une entête (70) identifiant ladite appliquette, des données (71 ) et au moins une signature électronique (72) obtenue à partir du chiffrement desdites données.
9. Procédé selon la revendication 8, caractérisé en ce qu'il comprend au moins une première étape supplémentaire, réalisée après ladite troisième étape, et en ce que cette première étape supplémentaire consiste en l'ouverture première session supplémentaire d'échanges de données entre ladite carte à puce (2a) et au moins ledit terminal (1 ) pour transmettre un code prédéterminé reçu par ledit premier programme de chargement (OL).
10-Procédé selon la revendication 9, caractérisé en ce que ledit code prédéterminé consiste en un acquittement lorsque lesdites trois premières étapes se sont déroulées correctement ou un code d'erreur dans le cas contraire.
5 11. Procédé selon la revendication 10, caractérisé en ce qu'il comprend au moins deux étapes supplémentaires, réalisées après ladite troisième étape, comprenant l'ouverture de sessions d'échanges de données bidirectionnels entre ladite carte à puce (2a) et au moins ledit terminal (1 ) pour la transmission d'un formulaire supplémentaire requérant la w soumission de données supplémentaires.
12. Procédé selon la revendication 11 , caractérisé en ce que lesdites données supplémentaires comprennent une signature électronique supplémentaire.
13. Procédé selon la revendication 12, caractérisé en ce que ledit terminal 15 étant connecté à au moins un serveur éloigné (4) via un réseau de type
Internet (RI) et par la mise en œuvre de protocole de communication de type Internet, un desdits agents intelligents (132) est associé à un attribut dit de "réseau" permettant des communications avec ledit réseau Internet (RI) et en ce que ledit premier programme de chargement (OL) est stocké 0 sur l'un desdits serveurs éloignés (4, 4a).
14. Procédé selon la revendication 13, caractérisé en ce que, ledit terminal (1 ) comprenant un navigateur de type "WEB" (10), ledit premier programme de chargement (OL") est constitué par un composant logiciel dudit navigateur "WEB" (10).
5 15. Procédé selon la revendication 14, caractérisé en ce que ledit composant logiciel (OL") est obtenu par une étape initiale de chargement dynamique d'une appliquette (OL) écrite en langage "JAVA" et stockée dans ladite carte à puce (2a), ledit chargement étant obtenu par l'émission d'une requête de type "HTTP", avec un adressage de type "URL" de ladite carte à puce (2a).
16. Procédé selon la revendication 17, caractérisé en ce que ledit composant logiciel (OL") est obtenu par une étape initiale de chargement dynamique d'une appliquette (OL) écrite en langage "JAVA" et stockée dans un desdits serveurs éloignés (4), ledit chargement étant obtenu par l'émission d'une requête de type "HTTP", avec un adressage de type "URL" dudit serveur éloigné (4).
PCT/FR2001/000393 2000-02-10 2001-02-09 Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit 'applet' WO2001059563A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP01907759A EP1188116A1 (fr) 2000-02-10 2001-02-09 Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit "applet"
CA002366556A CA2366556A1 (fr) 2000-02-10 2001-02-09 Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit "applet"
KR1020017012941A KR100886137B1 (ko) 2000-02-10 2001-02-09 스마트카드에 소프트웨어 콤포넌트, 특히 애플릿을로딩하는 방법
AU35647/01A AU3564701A (en) 2000-02-10 2001-02-09 Method for loading a software component in a smart card, in particular applet
JP2001558826A JP3834239B2 (ja) 2000-02-10 2001-02-09 スマートカードの中にソフトウェア構成部分、特に「アプレット」と呼ばれる形式をロードする方法
US12/000,766 US20080163352A1 (en) 2000-02-10 2007-12-17 Method for loading a piece of software in a smart card, in particular applet

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0001661A FR2805059A1 (fr) 2000-02-10 2000-02-10 Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit "applet"
FR00/01661 2000-02-10

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/000,766 Division US20080163352A1 (en) 2000-02-10 2007-12-17 Method for loading a piece of software in a smart card, in particular applet

Publications (1)

Publication Number Publication Date
WO2001059563A1 true WO2001059563A1 (fr) 2001-08-16

Family

ID=8846856

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2001/000393 WO2001059563A1 (fr) 2000-02-10 2001-02-09 Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit 'applet'

Country Status (10)

Country Link
US (2) US20020174071A1 (fr)
EP (1) EP1188116A1 (fr)
JP (1) JP3834239B2 (fr)
KR (1) KR100886137B1 (fr)
CN (1) CN1221893C (fr)
AU (1) AU3564701A (fr)
CA (1) CA2366556A1 (fr)
FR (1) FR2805059A1 (fr)
TW (1) TW501063B (fr)
WO (1) WO2001059563A1 (fr)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003049056A2 (fr) * 2001-12-07 2003-06-12 Ecebs Limited Systeme de carte intelligente
EP1367487A1 (fr) * 2002-05-30 2003-12-03 Schlumberger Systèmes Correction à distance d'une application
KR20050047704A (ko) * 2003-11-18 2005-05-23 주식회사 비즈모델라인 아이피 기반 스마트 카드 시스템 및 운용 방법
FR2908209A1 (fr) * 2006-11-07 2008-05-09 Oberthur Card Syst Sa Entite electronique portable et procede de personnalisation d'une telle entite electronique
JP2009289272A (ja) * 2002-02-28 2009-12-10 Axalto Sa 構造化ソフトウェアオブジェクトについての反復式シリアライゼーションプロシージャ
EP2141591A1 (fr) * 2008-07-04 2010-01-06 Oberthur Technologies Dispositif électronique portable comprenant une application portable et un module sécurisé pouvant comminique entre eux, et procédé de communication associé
US7653602B2 (en) 2003-11-06 2010-01-26 Visa U.S.A. Inc. Centralized electronic commerce card transactions
US7725369B2 (en) 2003-05-02 2010-05-25 Visa U.S.A. Inc. Method and server for management of electronic receipts
US7857216B2 (en) 2003-09-12 2010-12-28 Visa U.S.A. Inc. Method and system for providing interactive cardholder rewards image replacement
US8005763B2 (en) 2003-09-30 2011-08-23 Visa U.S.A. Inc. Method and system for providing a distributed adaptive rules based dynamic pricing system
US8015060B2 (en) 2002-09-13 2011-09-06 Visa Usa, Inc. Method and system for managing limited use coupon and coupon prioritization
US8407083B2 (en) 2003-09-30 2013-03-26 Visa U.S.A., Inc. Method and system for managing reward reversal after posting
US8429048B2 (en) 2009-12-28 2013-04-23 Visa International Service Association System and method for processing payment transaction receipts
US8554610B1 (en) 2003-08-29 2013-10-08 Visa U.S.A. Inc. Method and system for providing reward status
US8626577B2 (en) 2002-09-13 2014-01-07 Visa U.S.A Network centric loyalty system
US8799350B2 (en) * 2001-08-02 2014-08-05 Gemalto Sa Method and device for establishing network communication compatibility of terminals
US9852437B2 (en) 2002-09-13 2017-12-26 Visa U.S.A. Inc. Opt-in/opt-out in loyalty system
US11132691B2 (en) 2009-12-16 2021-09-28 Visa International Service Association Merchant alerts incorporating receipt data

Families Citing this family (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2791159B1 (fr) * 1999-03-15 2001-05-04 Bull Cp8 Procede d'acces a un objet a l'aide d'un navigateur de type "web" cooperant avec une carte a puce et architecture pour la mise en oeuvre du procede
FR2805108B1 (fr) * 2000-02-10 2002-04-05 Bull Cp8 Procede d'enregistrement d'un usager sur un serveur d'annuaire d'un reseau de type internet et/ou de localisation d'un usager sur ce reseau, et carte a puce pour la mise en oeuvre du procede
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
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"
US7346783B1 (en) * 2001-10-19 2008-03-18 At&T Corp. Network security device and method
US7783901B2 (en) * 2001-12-05 2010-08-24 At&T Intellectual Property Ii, L.P. Network security device and method
KR20030046621A (ko) * 2001-12-16 2003-06-18 한국전자통신연구원 계층화 구조의 프로토콜 스택을 사용하는 스마트 카드와휴대 단말기의 통신 환경 설정 방법
US6986458B2 (en) * 2002-12-11 2006-01-17 Scheidt & Bachmann Gmbh Methods and systems for user media interoperability
DE10261916A1 (de) 2002-12-20 2004-07-01 Giesecke & Devrient Gmbh Tragbarer Datenträger mit Netzserverfunktionalität
US7281244B2 (en) * 2003-01-16 2007-10-09 Sun Microsystems, Inc. Using a digital fingerprint to commit loaded data in a device
US7484095B2 (en) * 2003-01-16 2009-01-27 Sun Microsystems, Inc. System for communicating program data between a first device and a second device
US20040143739A1 (en) * 2003-01-16 2004-07-22 Sun Mircosystems, Inc., A Delaware Corporation Run time code integrity checks
US8121955B2 (en) 2003-01-16 2012-02-21 Oracle America, Inc. Signing program data payload sequence in program loading
US7165246B2 (en) * 2003-01-16 2007-01-16 Sun Microsystems, Inc. Optimized representation of data type information in program verification
US7222331B2 (en) * 2003-01-16 2007-05-22 Sun Microsystems, Inc. Linking of virtual methods
US7272830B2 (en) * 2003-01-16 2007-09-18 Sun Microsystems, Inc. Ordering program data for loading on a device
US7178724B2 (en) * 2003-04-21 2007-02-20 Stmicroelectronics, Inc. Smart card device and method used for transmitting and receiving secure e-mails
US7380125B2 (en) * 2003-05-22 2008-05-27 International Business Machines Corporation Smart card data transaction system and methods for providing high levels of storage and transmission security
EP1761904A1 (fr) 2004-05-28 2007-03-14 International Business Machines Corporation Systeme de transfert de donnees au moyen d'une carte intelligente et methodes pour assurer la securite du stockage et de la transmission
FR2881855A1 (fr) * 2005-02-09 2006-08-11 Gemplus Sa Administration d'application de service dans une carte a microcontroleur depuis un terminal
CN101138158B (zh) * 2005-02-11 2016-05-04 圣迪斯克以色列有限公司 通信协议模拟装置
EP1737178A1 (fr) * 2005-06-24 2006-12-27 Axalto SA Méthode et système utilisant un objet portable permettant l'extension d'un serveur
KR100723688B1 (ko) * 2005-07-18 2007-05-30 에스케이 텔레콤주식회사 ＨＴＴＰ(Ｈｙｐｅｒ Ｔｅｘｔ ＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ)를 기반으로 한 스마트카드 명령어송수신 방법
EP1931283A2 (fr) * 2005-10-03 2008-06-18 SanDisk IL Ltd Systeme informatique modulaire
US8176249B2 (en) * 2006-05-21 2012-05-08 Amiram Grynberg Methods for embedding session secrets, within application instances
US20080005261A1 (en) * 2006-05-24 2008-01-03 Research In Motion Limited Grouping Application Protocol Data Units for Wireless Communication
US20080120712A1 (en) * 2006-11-21 2008-05-22 Telos Corporation Method and system for remote security token extension
US8045956B2 (en) 2007-01-05 2011-10-25 Macronix International Co., Ltd. System and method of managing contactless payment transactions using a mobile communication device as a stored value device
CN100452894C (zh) * 2007-02-09 2009-01-14 凤凰微电子（中国）有限公司 在智能卡上实现无线增值业务的方法
KR100741847B1 (ko) * 2007-04-04 2007-07-24 주식회사 스마트카드연구소 Ｕｓｉｍ 카드에서의 애플릿 설치 및 관리 방법
WO2009074173A1 (fr) * 2007-12-13 2009-06-18 Nokia Corporation Interaction entre des environnements sécurisés et non sécurisés
EP2141667A1 (fr) * 2008-06-25 2010-01-06 Gemalto SA Procédé de calcul d'identifiant pour services Web
KR100947103B1 (ko) * 2008-07-25 2010-03-10 주식회사 케이티 스마트 카드 웹 서버를 이용한 서블릿 제공 방법, 서블릿관리 방법 및 이를 위한 스마트 카드
KR100879910B1 (ko) * 2008-09-09 2009-01-22 주식회사 스마트카드연구소 Ｓｃｗｓ를 이용한 서블릿 서비스 제공 시스템 및 제공 방법
EP2461613A1 (fr) * 2010-12-06 2012-06-06 Gemalto SA Procédés et système pour la manipulation de données d'une UICC
US8676954B2 (en) * 2011-12-06 2014-03-18 Kaseya International Limited Method and apparatus of performing simultaneous multi-agent access for command execution through a single client
US8898769B2 (en) 2012-11-16 2014-11-25 At&T Intellectual Property I, Lp Methods for provisioning universal integrated circuit cards
US8959331B2 (en) * 2012-11-19 2015-02-17 At&T Intellectual Property I, Lp Systems for provisioning universal integrated circuit cards
DE102012022875A1 (de) * 2012-11-22 2014-05-22 Giesecke & Devrient Gmbh Verfahren und System zur Applikationsinstallation
CN104348951B (zh) * 2013-07-24 2016-10-19 北京握奇数据系统有限公司 一种卡片应用管理系统
US9036820B2 (en) 2013-09-11 2015-05-19 At&T Intellectual Property I, Lp System and methods for UICC-based secure communication
US9124573B2 (en) 2013-10-04 2015-09-01 At&T Intellectual Property I, Lp Apparatus and method for managing use of secure tokens
US9208300B2 (en) 2013-10-23 2015-12-08 At&T Intellectual Property I, Lp Apparatus and method for secure authentication of a communication device
US9240994B2 (en) 2013-10-28 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for securely managing the accessibility to content and applications
US9313660B2 (en) 2013-11-01 2016-04-12 At&T Intellectual Property I, Lp Apparatus and method for secure provisioning of a communication device
US9240989B2 (en) 2013-11-01 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for secure over the air programming of a communication device
US9713006B2 (en) 2014-05-01 2017-07-18 At&T Intellectual Property I, Lp Apparatus and method for managing security domains for a universal integrated circuit card
WO2016106277A2 (fr) 2014-12-22 2016-06-30 Capital One Services, LLC. Système, procédé et appareil de reprogrammation d'une carte de transaction
GB2542617B (en) * 2015-09-28 2020-06-24 Touchtech Payments Ltd Transaction authentication platform
EP3486830A1 (fr) * 2017-11-21 2019-05-22 Gemalto Sa Procédé de gestion de profils dans un élément sécurisé comprenant plusieurs contenants logiciels

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998017029A1 (fr) * 1996-10-17 1998-04-23 Telia Ab Transfert d'informations signees et cryptees
WO1998057474A1 (fr) * 1997-06-13 1998-12-17 Gemplus S.C.A. Carte a puce, telephone sans fil, systeme et procede d'acces et de communication par internet

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5353331A (en) * 1992-03-05 1994-10-04 Bell Atlantic Network Services, Inc. Personal communications service using wireline/wireless integration
WO1996007256A1 (fr) * 1994-08-30 1996-03-07 Kokusai Denshin Denwa Co., Ltd. Systeme de certification
US5742845A (en) * 1995-06-22 1998-04-21 Datascape, Inc. System for extending present open network communication protocols to communicate with non-standard I/O devices directly coupled to an open network
US5734831A (en) * 1996-04-26 1998-03-31 Sun Microsystems, Inc. System for configuring and remotely administering a unix computer over a network
US6557752B1 (en) * 1996-06-12 2003-05-06 Q-International, Inc. Smart card for recording identification, and operational, service and maintenance transactions
US5923884A (en) * 1996-08-30 1999-07-13 Gemplus S.C.A. System and method for loading applications onto a smart card
US6101543A (en) * 1996-10-25 2000-08-08 Digital Equipment Corporation Pseudo network adapter for frame capture, encapsulation and encryption
US5901303A (en) * 1996-12-27 1999-05-04 Gemplus Card International Smart cards, systems using smart cards and methods of operating said cards in systems
US6282522B1 (en) * 1997-04-30 2001-08-28 Visa International Service Association Internet payment system using smart card
JP3760581B2 (ja) * 1997-07-28 2006-03-29 富士通株式会社 通信相手情報検索装置及びそれを用いた通信支援システム
US6105008A (en) * 1997-10-16 2000-08-15 Visa International Service Association Internet loading system using smart card
US6498797B1 (en) * 1997-11-14 2002-12-24 At&T Corp. Method and apparatus for communication services on a network
US6250557B1 (en) * 1998-08-25 2001-06-26 Telefonaktiebolaget Lm Ericsson (Publ) Methods and arrangements for a smart card wallet and uses thereof
FI109756B (fi) * 1998-09-21 2002-09-30 Nokia Corp Menetelmä tiedonsiirtojärjestelmässä paikallisten resurssien hyödyntämiseksi, tiedonsiirtojärjestelmä ja langaton viestin
US6253203B1 (en) * 1998-10-02 2001-06-26 Ncr Corporation Privacy-enhanced database
US6347312B1 (en) * 1998-11-05 2002-02-12 International Business Machines Corporation Lightweight directory access protocol (LDAP) directory server cache mechanism and method
US6438550B1 (en) * 1998-12-10 2002-08-20 International Business Machines Corporation Method and apparatus for client authentication and application configuration via smart cards
US6481621B1 (en) * 1999-01-12 2002-11-19 International Business Machines Corporation System method and article of manufacture for accessing and processing smart card information
FR2790629A1 (fr) * 1999-02-19 2000-09-08 Bull Cp8 Procede d'activation d'applications localisees dans une carte a puce par un navigateur du type dit "web"
FR2791159B1 (fr) * 1999-03-15 2001-05-04 Bull Cp8 Procede d'acces a un objet a l'aide d'un navigateur de type "web" cooperant avec une carte a puce et architecture pour la mise en oeuvre du procede
US6366950B1 (en) * 1999-04-02 2002-04-02 Smithmicro Software System and method for verifying users' identity in a network using e-mail communication
US6751459B1 (en) * 1999-04-20 2004-06-15 Nortel Networks Limited Nomadic computing with personal mobility domain name system
US6547150B1 (en) * 1999-05-11 2003-04-15 Microsoft Corporation Smart card application development system and method
US20040040026A1 (en) * 1999-06-08 2004-02-26 Thinkpulse, Inc. Method and System of Linking a Smart Device Description File with the Logic of an Application Program
FR2805108B1 (fr) * 2000-02-10 2002-04-05 Bull Cp8 Procede d'enregistrement d'un usager sur un serveur d'annuaire d'un reseau de type internet et/ou de localisation d'un usager sur ce reseau, et carte a puce pour la mise en oeuvre du procede
FR2805059A1 (fr) * 2000-02-10 2001-08-17 Bull Cp8 Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit "applet"
FR2805107B1 (fr) * 2000-02-10 2002-04-05 Bull Cp8 Procede de gestion de transmissions de donnees multimedias via un reseau de type internet, notamment de donnees telephoniques, et carte a puce pour la mise en oeuvre du procede
US7003663B2 (en) * 2000-12-22 2006-02-21 Gemplus Distribution of deployment information for remote applications

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998017029A1 (fr) * 1996-10-17 1998-04-23 Telia Ab Transfert d'informations signees et cryptees
WO1998057474A1 (fr) * 1997-06-13 1998-12-17 Gemplus S.C.A. Carte a puce, telephone sans fil, systeme et procede d'acces et de communication par internet

Non-Patent Citations (1)

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

Cited By (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8799350B2 (en) * 2001-08-02 2014-08-05 Gemalto Sa Method and device for establishing network communication compatibility of terminals
AU2002350918B2 (en) * 2001-12-07 2009-09-10 Ecebs Limited Smartcard system
WO2003049056A3 (fr) * 2001-12-07 2003-12-18 Ecebs Ltd Systeme de carte intelligente
GB2398905A (en) * 2001-12-07 2004-09-01 Ecebs Ltd Smartcard system
WO2003049056A2 (fr) * 2001-12-07 2003-06-12 Ecebs Limited Systeme de carte intelligente
GB2398905B (en) * 2001-12-07 2005-11-09 Ecebs Ltd Smartcard system
JP2009289272A (ja) * 2002-02-28 2009-12-10 Axalto Sa 構造化ソフトウェアオブジェクトについての反復式シリアライゼーションプロシージャ
WO2003103155A2 (fr) * 2002-05-03 2003-12-11 Schlumberger Systemes Correction d'application a distance
EP1367487A1 (fr) * 2002-05-30 2003-12-03 Schlumberger Systèmes Correction à distance d'une application
WO2003103155A3 (fr) * 2002-05-30 2005-05-26 Axalto Sa Correction d'application a distance
US10460338B2 (en) 2002-09-13 2019-10-29 Visa U.S.A. Inc. Network centric loyalty system
US9852437B2 (en) 2002-09-13 2017-12-26 Visa U.S.A. Inc. Opt-in/opt-out in loyalty system
US8626577B2 (en) 2002-09-13 2014-01-07 Visa U.S.A Network centric loyalty system
US8239261B2 (en) 2002-09-13 2012-08-07 Liane Redford Method and system for managing limited use coupon and coupon prioritization
US8015060B2 (en) 2002-09-13 2011-09-06 Visa Usa, Inc. Method and system for managing limited use coupon and coupon prioritization
US9087426B2 (en) 2003-05-02 2015-07-21 Visa U.S.A. Inc. Method and administration system for management of electronic receipts
US7725369B2 (en) 2003-05-02 2010-05-25 Visa U.S.A. Inc. Method and server for management of electronic receipts
US7827077B2 (en) 2003-05-02 2010-11-02 Visa U.S.A. Inc. Method and apparatus for management of electronic receipts on portable devices
US7987120B2 (en) 2003-05-02 2011-07-26 Visa U.S.A. Inc. Method and portable device for management of electronic receipts
US8386343B2 (en) 2003-05-02 2013-02-26 Visa U.S.A. Inc. Method and user device for management of electronic receipts
US8793156B2 (en) 2003-08-29 2014-07-29 Visa U.S.A. Inc. Method and system for providing reward status
US8554610B1 (en) 2003-08-29 2013-10-08 Visa U.S.A. Inc. Method and system for providing reward status
US7857215B2 (en) 2003-09-12 2010-12-28 Visa U.S.A. Inc. Method and system including phone with rewards image
US7857216B2 (en) 2003-09-12 2010-12-28 Visa U.S.A. Inc. Method and system for providing interactive cardholder rewards image replacement
US8005763B2 (en) 2003-09-30 2011-08-23 Visa U.S.A. Inc. Method and system for providing a distributed adaptive rules based dynamic pricing system
US8407083B2 (en) 2003-09-30 2013-03-26 Visa U.S.A., Inc. Method and system for managing reward reversal after posting
US8244648B2 (en) 2003-09-30 2012-08-14 Visa U.S.A. Inc. Method and system for providing a distributed adaptive rules based dynamic pricing system
US9141967B2 (en) 2003-09-30 2015-09-22 Visa U.S.A. Inc. Method and system for managing reward reversal after posting
US7653602B2 (en) 2003-11-06 2010-01-26 Visa U.S.A. Inc. Centralized electronic commerce card transactions
US9710811B2 (en) 2003-11-06 2017-07-18 Visa U.S.A. Inc. Centralized electronic commerce card transactions
KR20050047704A (ko) * 2003-11-18 2005-05-23 주식회사 비즈모델라인 아이피 기반 스마트 카드 시스템 및 운용 방법
WO2008065264A1 (fr) 2006-11-07 2008-06-05 Oberthur Technologies Entite electronique portable et procede de personnalisation d'une telle entite electronique
FR2908209A1 (fr) * 2006-11-07 2008-05-09 Oberthur Card Syst Sa Entite electronique portable et procede de personnalisation d'une telle entite electronique
EP2141591A1 (fr) * 2008-07-04 2010-01-06 Oberthur Technologies Dispositif électronique portable comprenant une application portable et un module sécurisé pouvant comminique entre eux, et procédé de communication associé
FR2933510A1 (fr) * 2008-07-04 2010-01-08 Oberthur Technologies Dispositif electronique portable comprenant une application portable et un module securise pouvant communiquer entre eux, et procede de communication associe
US11132691B2 (en) 2009-12-16 2021-09-28 Visa International Service Association Merchant alerts incorporating receipt data
US8429048B2 (en) 2009-12-28 2013-04-23 Visa International Service Association System and method for processing payment transaction receipts
US8650124B2 (en) 2009-12-28 2014-02-11 Visa International Service Association System and method for processing payment transaction receipts

Also Published As

Publication number Publication date
JP3834239B2 (ja) 2006-10-18
FR2805059A1 (fr) 2001-08-17
US20020174071A1 (en) 2002-11-21
EP1188116A1 (fr) 2002-03-20
KR20010110736A (ko) 2001-12-13
CA2366556A1 (fr) 2001-08-16
US20080163352A1 (en) 2008-07-03
AU3564701A (en) 2001-08-20
KR100886137B1 (ko) 2009-02-27
CN1221893C (zh) 2005-10-05
TW501063B (en) 2002-09-01
CN1363064A (zh) 2002-08-07
JP2003523012A (ja) 2003-07-29

Similar Documents

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

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 01800191.2

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AU CA CN JP KR SG US

AL Designated countries for regional patents

Kind code of ref document: A1

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

WWE Wipo information: entry into national phase

Ref document number: 2001907759

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application
ENP Entry into the national phase

Ref document number: 2366556

Country of ref document: CA

Ref document number: 2366556

Country of ref document: CA

Kind code of ref document: A

Ref document number: 2001 558826

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 09958726

Country of ref document: US

Ref document number: 1020017012941

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 35647/01

Country of ref document: AU

WWP Wipo information: published in national office

Ref document number: 2001907759

Country of ref document: EP