WO2002037435A1 - Carte a puce avec descripteur d'application - Google Patents

Carte a puce avec descripteur d'application Download PDF

Info

Publication number
WO2002037435A1
WO2002037435A1 PCT/FR2001/003390 FR0103390W WO0237435A1 WO 2002037435 A1 WO2002037435 A1 WO 2002037435A1 FR 0103390 W FR0103390 W FR 0103390W WO 0237435 A1 WO0237435 A1 WO 0237435A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
elements
state
electronic object
portable electronic
Prior art date
Application number
PCT/FR2001/003390
Other languages
English (en)
Inventor
Olivier Potonniee
Marie-Claude Pellegrini
Original Assignee
Gemplus
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 Gemplus filed Critical Gemplus
Priority to EP01983669A priority Critical patent/EP1337980A1/fr
Priority to AU2002215096A priority patent/AU2002215096A1/en
Publication of WO2002037435A1 publication Critical patent/WO2002037435A1/fr

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3576—Multiple memory zones on card

Definitions

  • the present invention relates to applications described in a portable electronic object, such as a smart card, also known as a microcontroller card or integrated circuit card, and deployed through an application execution means notably comprising a terminal reception of the smart card, in a wide and heterogeneous context.
  • a portable electronic object such as a smart card, also known as a microcontroller card or integrated circuit card
  • an application execution means notably comprising a terminal reception of the smart card, in a wide and heterogeneous context.
  • an application is composed of software components dispersed in one. telecommunications network and must be able to be executed from heterogeneous terminals having hardware and software characteristics
  • Heterogeneous terminals differ, for example, in their operating systems and their coding characteristics.
  • the terminal To correctly run the applications, the terminal must have service data relating to
  • a given application presents a complex graphical interface based on windows in a personal computer, and simple text menus in a mobile radiotelephone, or establishes an audio or video communication according to the speed offered by the network.
  • an API application in a smart card CP1, or any other portable electronic object having a relatively small memory capacity, by a descriptor DAP1 of a first API application identifying elements essentials of the application, such as the software components of the application and the connections between these components two by two.
  • an application comprises at least three components II, Al and SI and at least two connections CIA1 and CAS1 interconnecting in pairs the components II and Al and the components Al and SI.
  • the first component II is a user interface containing the entry point of the application, which needs a consultation service, for example a banking consultation service offered by the second component A1, so to recover information taken from a personal bank account of the user who owns the card managed by the third component SI constituted by a server of a bank with which one or more user accounts have been opened.
  • the user interface component II is located in the reception terminal TE, while the other two components A1 and SI are located in different sites. Only the first two components II and Al are configurable.
  • the application can be executed, adapting to the execution context essentially constituted by the terminal.
  • An application component is a software processing unit encapsulating functionalities, small enough to be able to create and maintain it, and large enough to be able to install and support it.
  • the functional properties of a component are the processing possibilities offered by the component and are programmed and invariant whatever the context.
  • the component also has non-functional properties which represent system aspects linked to the implementation of the component, such as transaction, security, persistence, fault tolerance, and which are variable depending on the context and the application. The separation between invariable functional properties and variable non-functional properties makes it possible to execute the component in a different way on an execution platform.
  • the component is also provided with communication interfaces so that it can cooperate with other components and thus present its behavior to these other components.
  • a software component can be installed on any site of an RT telecommunications network.
  • a connection defines the relationships between the communication interfaces of two components.
  • Application connection parameters are also adapted to the context of the execution platform.
  • the application descriptor DAP1 does not contain the element itself, the software component or the connection, but a descriptor DU, DCIA1, DA1, DCAS1, DSI of the element II, CIA1, Al, CAS1, SI containing properties and parameters of the element defining it and allowing it to be found among a multitude of elements.
  • the properties of the descriptor of an element are fixed once and for all by the supplier of the application which specializes the element, component or connection, in order to satisfy the needs of the application and the user according to the characteristics of subscription. They indicate the characteristics of the platform on which the element can be executed, as well as the system requirements necessary for execution.
  • a property is the type or address of an element which is associated with each element and used for searching for the code or the implementation of the element, or is intimately linked to the application or to a type of application, such as the "account number" property associated with a component, consultation agent or bank account server 1 .
  • These properties are, according to the prior art, frozen when subscribing to the service corresponding to the application by the user of the smart card, and are only accessible in read-only mode.
  • Other properties, called parameters are preferably personalized by the user and can be modified at any time.
  • a parameter has the value of the display currency of an amount, or a range of colors for displaying pages on a screen, or the value of the bit rate or of a transmission characteristic in a connection.
  • Each descriptor of an application is represented in the form of an object graph in object-oriented language, for example JAVA language (trademark).
  • the descriptors of the applications in a multi-application smart card are combined in an applet which acts as a descriptor server creating the tree of objects representing the components and the connections of the descriptors.
  • application descriptors are written in XML (Extensible Markup Language) language.
  • the descriptor server constituting the applet is associated with a client, called a PII deployment driver (in English bootstrap) which constitutes within the smart card.
  • CP1 an application to configure the selected application according to its descriptor.
  • the pilot manages the deployment of elements of the selected application, after the introduction of the CP1 card in the TE reception terminal. By grouping the descriptor server and the deployment pilot in the card, the confidentiality of the descriptors is ensured so that the reading of the descriptors by the " deployment pilot constituting a known client does not require authentication.
  • the pilot Deployment authenticates each client who interrogates it before making available all of the methods of the applet.
  • the PI deployment pilot informs the descriptor server which then considers all the requests addressed to it as relating to the DAP1 descriptor of the selected application.
  • the PI driver thus processes one or more application deployments according to the DAP1 descriptor of the selected application API and the execution context of the application. consisting essentially of the TE terminal.
  • an application element, component or connection is configured according to the context of the application, that is to say the hardware and software properties of the platform where the application will be executed, and parameters chosen by the user and customizing the application.
  • the properties of the execution context provided by the terminal are for example the type of reception terminal used TE, the name of the terminal, a certificate or key identifying the terminal, the location of the terminal in the telecommunications network and a date of manufacture of the terminal. All this information is gathered in the descriptor of the application element so that the PI deployment pilot filters the information contained in the descriptor of the element according to the context of the application and the personalization parameters of the user. .
  • the deployment pilot PI located in the smart card CP transmits deployment commands to a deployment portal PO which is an application element implemented in the reception terminal TE.
  • the main role of the portal is to receive deployment commands and re-issue them to the deployment platform in order to install the selected application.
  • the deployment portal mainly has a function of informing the smart card about the environment in which the installation and execution of the selected application must be done, and a function of communication with the card in order to receive various commands for deploying the selected application.
  • the deployment of an application is synchronous, that is to say the commands developed by the deployment pilot PI are transmitted sequentially to the terminal TE, one after the other, respectively for the installation of the elements of the application , then for the configuration of the elements of the application. After these installations and configuration of elements, the application is launched by an execution command (RUN) which contains the name of the component of the selected application determining the entry point of the application, generally the component of user interface.
  • RUN execution command
  • the deployment is carried out by the deployment pilot from the descriptor DAP1 of the selected application API so that a dialogue is established between the deployment pilot PII in the smart card CP1 and the deployment portal PO in the terminal.
  • the portal can contain an element search engine, or be linked to one or more MR element search engines, as shown in FIG. 2.
  • Each MR search engine constitutes a directory of application elements to reference and search for application elements in libraries of BI application elements across the RT telecommunications network.
  • Each element in a library is memorized with its descriptor and managed by the designer of the element.
  • the set of components and connections constituting an application defines a profile of the application. So two different users can have different application profiles because of the parameters of the user-defined applications with different values, such as bank account numbers. Conversely, a single user can configure an application according to several different profiles.
  • the profiles of an application are thus defined either by the user, or automatically according to the context of use of the application, which can depend in particular on the reception terminal and in particular on the operating system implemented in it. .
  • certain values of the parameters of a component depend in particular on the type, name and location of the terminal.
  • the descriptor of the application AP2 also shown in FIG. 2 includes descriptors DI2, DA2, DS2, DCIA2 and DCAS2 of a user interface 12, of a bank consultation agent A2, of a bank server S2 and CIA2 and CAS2 connections between components 12 and A2, and A2 and S2.
  • the user cannot carry out operations dependent on these two bank accounts.
  • the agents A1 and A2 are transfer agents, a transfer from the bank account managed by the first server SI to the bank account managed by the second server S2 is impossible by either of the agents A1 and A2.
  • the deployment of an API application is total.
  • ' all API, Al and SI components of the application must be found by the search engine MR regardless of the execution context , in particular the TE terminal, to execute the application.
  • the components of the API application including the server SI, must be installed while the last information consulted is stored in the card CP1 and their reading does not require the intervention of the server component SI.
  • the API bank consultation application is deployed on a secure terminal, although the secure nature of the terminal is not necessary for such an application.
  • the invention therefore aims to remedy the aforementioned drawbacks.
  • the description of the applications with elements distributed according to the prior art so as to offer more applications global for the user and can be deployed only partially under the user's control or depending on the context surrounding the application's execution platform.
  • a portable electronic object of the microcontroller card type comprising a means for describing an application composed of several remote elements distributed with descriptors of the elements, and a means for deploying the application outside the electronic object.
  • the means for describing combines several states of the application which are selectively deployed outside the electronic object under the control of the means for deploying, and which each comprise at minus an element of the application.
  • Said at least one element can for example be a user interface, or an agent qualifying at least one process and operating alone, or even a server operating alone.
  • an application state includes two, or some or all of the elements of the application.
  • the means for describing the application can then comprise the descriptor of a user interface, and / or the descriptor of at least one element qualifying at least one process, and / or the descriptor of at least one data server. .
  • One of the states of the application can comprise the parameters of at least one element included in this state.
  • states differ for example by parameters of a common element.
  • the invention also relates to a method for configuring and deploying an application composed of several remote elements distributed from a portable electronic object in accordance with the invention, containing descriptors of the elements, through a data processing means connected to means for implanting the elements to execute the configured and deployed application.
  • the method is characterized in that after a transmission of characteristics of the execution context of the application from the processing means to the portable electronic object, it comprises a selection of one of the states of the application which each include at least one element of the application.
  • an element for example an agent qualifying a process
  • the method comprises, with the transmission of characteristics of the execution context of the application, the transmission of a key associated with an element of the application, and the deployment of a selected state of the application comprising the element only in response to a prior detection of the predetermined key by the portable electronic object.
  • several keys can be associated respectively with elements of the application, the selection of a state from among states of the application comprising at least connections with the elements associated with the transmitted keys.
  • the method preferably comprises a selection of one of several deployments of the selected state of the application, so as to adapt the deployment in the context of the application and if possible increase the speed of execution.
  • the deployment is essentially asynchronous, or else essentially
  • One of the asynchronous or synchronous deployments can include the installation of at least one element
  • FIG. 1 already commented on, shows the modularity of two applications in three components for example;
  • - Figure 2 already discussed, is a schematic block diagram of the means used in a telecommunications network for the deployment of applications of distributed remote elements, according to the prior art;
  • FIG. 3 is a graph of the states of a global application according to the invention.
  • FIG. 4 is similar to Figure 2, but with a smart card according to the invention
  • - - Figure 5 is a graph of the main states of a banking application according to the invention
  • FIGS. 5A and 5B are state graphs only between two components of the application of Figure 5, respectively, - - Figure 6 is a state graph for a variant banking application;
  • - Figures 7 and 8 are graphs of two applications according to the invention respectively with a single agent and a single server; and - Figure 9 is an application configuration and deployment algorithm according to the invention.
  • an application AP is composed of several distributed remote elements which are a user interface IU, agents AGI to AGM and data servers SEl to SEN, at least one of the integers M and N being greater than 1.
  • FIG. 3 also represents other elements of the application AP constituting connections CIAG1 to CIAGM respectively between the interface UI and the agents AGI to AGM and connections CAS11-CAS1N to CASM1-CASMN respectively between each of the agents AGI to AGM and SEl servers at SEN.
  • One or more such applications are described in the form of descriptors in a smart card CP, or any other portable electronic object, as shown in FIG. 4. According to this figure, the
  • • 5 smart card includes at least the DAP descriptor of the AP application including the IUD descriptors, DAG1 to DAGM and DSE1 to DSEN of the components and the descriptors of the application connections.
  • the descriptors of the connections in FIG. 4 are not marked for clarity.
  • the user interface IU is located in the reception terminal TE of the smart card CP, the reception terminal TE being connected to a network of
  • the user interface essentially constitutes the human interface. machine which is configured by the user, in particular at level 0 of. , screen page design and listening to. voice messages.
  • the user interface IU thus visually and / or vocally presents data transmitted by at least one of the agents AGI to AGM included in the selected state of the application, as will be seen below.
  • commands to be processed by an agent of the selected state are entered by the interface UI to trigger operations on data in one or more of the servers SEl to SEN included in 0 the selected state of the application. .
  • the user may be able to select states of the AP application and data relating thereto. These states and these data are contained in the descriptor DIU and saved in the non-volatile memory EEPROM of the chip card CP between two application sessions, that is to say between two selections of application states.
  • the user interface IU is thus a session type component which is created at the start of the session and totally or partially destroyed at the end of the session.
  • the user interface IU constitutes the entry point of the AP application for the user, and therefore intervenes each time the user wishes to have one of the states of the AP application executed directly.
  • An AGm agent qualifies at least one predetermined process for processing data transmitted by the user interface IU when it is linked to the AGm agent, and / or for processing transmitted data by at least one of the servers SEl to SEN when the latter is connected to the agent AGm for the selected state of the application.
  • the agent AGm can be configured by the user from the interface UI and / or according to the characteristics of the context of the application essentially depending on the characteristics of the reception terminal TE of the smart card CP.
  • the descriptor DAGm of the agent AGm thus has several parameters, the values programmed in particular by the user are saved in the non-volatile memory of the smart card.
  • the agent AGm is therefore of the process type, which implies that it can be maintained during a partial termination of the selected state of the application.
  • this offline state is executed so that the agent AGm processes data from one or more SEl to SEN servers included in the selected application state, without any intervention of the user interface UI which is kept offline.
  • a data server SEn is an entity containing data which can be consulted or processed by one of the agents AGI to AGM so as to retransmit the data without or with modification to the user interface IU and / or to the server SEn and / or at least one other server.
  • the state of the server SEn is independent of the user, that is to say cannot be modified by the user interface IU, and is managed by the designer of the server SEn, just as an agent AGm is managed by the designer of the AGm agent, from an appropriate terminal through the RT network.
  • the server SEn can optionally process several requests from agents relating to several applications and therefore to several users respectively.
  • a state of the application AP which is not very wide comprises at least one or two different components, either the user interface IU and / or the agent AGm connected by the corresponding connection CIAGm, or an agent AGm and / or one servers SEl to SEN connected by the corresponding connection CASml to CASmN, with 1 ⁇ m ⁇ M.
  • the most extensive "global" state of the application is the arrangement of the interface UI, of all the agents AGI to AGM and of all the servers SEl to SEN with all the connections shown in FIG. 3.
  • intermediate states include one or more agents AGI to AGM which can each be linked to the user interface IU and / or to one or more respective servers SEl to SEN.
  • agents AGI to AGM can each be linked to the user interface IU and / or to one or more respective servers SEl to SEN.
  • an APB application relates to an inter-bank and inter-account service.
  • the APB application generally includes as elements, a user interface IU, two agents AGC and AGV dedicated to banking consultation and to bank transfer, and N data servers SBl to SBN containing the data of the various accounts that the user opened in N banks.
  • the banking consultation agent AGC is connected to the user interface and to one or more of the servers of SBl bank at SBN.
  • the user can then select his accounts from a list presented by the interface UI in order to connect the accounts which are opened in the various banks corresponding to the servers SBl to SBN in relation with the agent AGC.
  • the bank transfer agent AGV is intermediate between the user interface IU and one or more of the servers of SBl bank at SBN.
  • the AGV agent can be configured by the user to make an automatic transfer for example between two accounts managed by the same server SBn, or between two accounts managed respectively by different servers SBn and SBp, with p ⁇ n and 1 ⁇ p ⁇ N.
  • the descriptions of the states of the interface UI and of the agents AGC and AGV are saved in the non-volatile memory of the card.
  • smart CP thus it stores the list of identifiers of the user's bank accounts and at least their last known balances, and the recently configured functional states of the agents AGC and AGV.
  • Figures 5A and 5B show minimum states T3 and T4 of the application. APB banking service.
  • the state T3 relates to the connection between. 1 UI user interface and 1 AGC banking consultation agent. This state is selected by the user when the latter wishes to consult again the last 'data it has stored in the smart card CP at, recent consultations SBI servers SBN.
  • the T3 state can be imposed by the execution context of the application.
  • a predetermined key KAGC is associated with the descriptor DAGC of the agent AGC contained in the descriptor DAP of the application AP included in the chip card CP. If no key or a key of zero value is transmitted with the characteristics of the application context by the portal PO from the terminal TE to the deployment pilot PI in the smart card CP prior to the selection of one .
  • the driver - PI not recognizing the KAGC key does not install and therefore prohibits any connection from the AGC agent to the SBl servers at SBN. Consequently, the driver PI only authorizes the connection of the agent AGC with the user interface IU according to the application state T3 shown in FIG. 5A.
  • the TE terminal transmits the KAGC key to the PI deployment pilot, the latter authorizes the agent AGC to be connected to at least one of the servers SB1 to SBN.
  • the KAGC key thus makes it possible to validate secure connections in predetermined states of the application. More generally, concomitantly with the transmission of characteristics of the execution context of the application from the terminal TE to the pilot PI, the transmission of a predetermined key KAGC, KAGV associated with a given element, such as one of. AGC and AGV agents qualifying at least one process, capable of being connected to two other elements of the application, such as two of the servers SBn to SBp or one of these servers and the user interface IU, by the TE reception terminal is mandatory so that the PI driver on the CP card does not authorize the deployment of a selected state of
  • the state T4 of the APB application shown in FIG. 5B. connects the bank transfer agent AGV and two SBn and SBp bank servers.
  • This state is an offline state for which the user interface IU is not connected to the AGV agent, that is to say for which the user terminal TE has no access to servers. through the AGV agent.
  • the state T4 has been programmed by the user during a previous state connecting the user interface IU to the servers SBn and SBp by the intermediary of the bank transfer agent AGV so as to configure automatic transfers to the less between one of the accounts managed by the SBn server and one of the accounts managed by the SBp server. For example, if one of the accounts managed by the SBn server is a checking account and if one of the accounts managed by the SBp server is a savings account, the user can program one of the following two sets of operations:
  • Each of the two preceding automatic transfers is programmed by the user in the AGV agent so that it can be executed offline, as shown in FIG. 5B, in a periodic manner, for example after each day, as soon as the balance Cn of the checking account has become greater than. SUP threshold or has become below the INF threshold.
  • a transfer operation by means of one bank transfer AGV can only be carried out on an execution platform, in this case • the reception terminal TE,. who has provided a KAGV security key which is only known to the user and recognized by the PI driver in the chip card CP so as to install the AGV agent connections with servers according to the descriptor thereof contained in the DAP descriptor of the AP application.
  • the user can also choose parameter values of the IU interface and of the agents AGC and AGV-. For example, the user selects one of several display languages in the user interface IU and one of several currencies in the AGC agent or the AGV agent.
  • the APC application is a variant of a banking service application.
  • the agent and server pairs AGCl-SCl, AGCm-SCm and AGCM-SCM relate to viewing and managing a checking account, a savings account and a securities account .
  • the AGCM agent can also be connected to a market data server SCB. All AGCl agents at AGCM. are connected to the user interface UI.
  • an AGVC transfer agent is intermediary between the user interface IU and the account consultation agents AGCl at AGCM in order to carry out automatic transfers from one to the other of the accounts whose the data is included in the SCI servers at SCM.
  • the descriptor describing the APC application in the CP card only includes the descriptors of the following elements: the user interface UI, • several elements AGCl to AGCM each qualifying at least one process, and several data servers SCI to SCM can be connected respectively to the qualifying elements.
  • an application APJ comprises a global state which brings together a single agent AGJ with the user interface IU and N data server SJ1 to SJN.
  • the application APJ is for example relating to a game common to N players Jl to JN, including the player, for example Jl, possessor of the chip card CP and deploying the game application APJ on the terminal TE.
  • the agent AGJ is a game concentrator-broadcaster while the server components SJ1 to SJN are installed respectively in players' terminals J1 to JN.
  • the descriptor describing the APJ application in the CP card includes the descriptors of the following elements: the user interface IU, the element APJ qualifying at least one process, and several data servers SJ1 to SJN which can be selectively connected to the qualifying element.
  • a third realization of. application 'according to the invention shown in Figure 8 relates to an APE application whose overall state includes M agents AGEl to AGEM which can each be connected to one user interface IU and to a common data server SE.
  • the server SE is an electronic mail server receiving electronic messages from various correspondents of the user possessing the smart card CP.
  • the agents AGEl at AGEM filter the messages each according to predetermined conditions. For example, the agent AGEl retransmits to the user interface UI only all the messages coming from private senders whose addresses are listed in a first directory so as to store only these private messages in the card smart CP; the AGEm agent filters messages from only professional senders listed in a second directory and only signals the reception of a professional message at the user interface UI and retransmits each professional message to a destination server located on the site user professional; the AGEM agent contains the first and second directories of the agents AGEl and AGEm in order to filter only the messages coming from senders not listed in these two directories and to signal to the user interface IU that such a message has been recorded and that an acknowledgment, pending message processing has been returned to the sender of the message.
  • the descriptor describing the APE application in the CP card only includes the descriptors of the following elements: the user interface IU, several elements AGEl to AGEM each qualifying at least one process, and a single data server SE can be selectively connected to "qualifying elements.
  • the configuration and deployment of a selected state selected application AP in a smart card multi-application CP comprises the steps, following El to E13.
  • the user inserts the smart card CP into the reader slot of the reception terminal TE in step E1, the reception terminal being for example a mobile radiotelephone terminal, a personal electronic assistant or a personal computer.
  • the reception terminal being for example a mobile radiotelephone terminal, a personal electronic assistant or a personal computer.
  • the smart card After the introduction of the smart card, it authenticates the user by means of a confidential code or a biometric fingerprint entered by the terminal TE, in step E2.
  • characteristics of the execution context are transmitted by the terminal TE to the deployment pilot PI in the smart card CP, in step E3.
  • the context of the hardware environment external to the smart card is defined by characteristics of the execution platform which are transmitted by the terminal TE to the smart card CP in step E3.
  • the characteristics of the execution context provided by the terminal are for example the type of reception terminal used TE, the name of the terminal, a certificate or key identifying the terminal, the location of the terminal in the telecommunications network and a date of manufacture of the terminal. These characteristics allow the PI deployment pilot to limit the amount of data that he transmits to the PO deployment portal and thus minimize the duration of the deployment.
  • the characteristics of the execution context may include at least one security key, such as the keys KAGC and KAGV (FIGS. 5A, 5B), composed by the user in the terminal TE and capable of being assigned to the access of connections with elements, such as AGC and AGV agents, of the selected application AP below.
  • KAGC and KAGV KAGC and KAGV
  • step E4 the user selects one of the applications AP whose descriptors DAP are stored in the smart card CP.
  • the pilot PI retransmits the list of states T of the selected application AP authorized by the card CP according to the context.
  • step E5 one of the authorized states of the selected application AP is selected by the user from the list of authorized states displayed by the terminal TE.
  • the selected state T includes at least connections with the elements associated with the transmitted keys.
  • step E6 the terminal TE according to the context and preferably according to the wishes of the user sets the descriptor DT, that is to say sets some or all of the descriptors of the components and connections of the state selected T from the selected application AP.
  • the configuration by the user is classic using tree menus asking for parameter values.
  • the method offers several deployment choices in steps E7, E8, E9 and E10 according to a complete realization of the invention, although in a variant, the method can only comprise one or some of the steps E7 to E10.
  • steps E7, E8 and E9 one of the values of a property or one of several properties in the descriptor of at least one element EL of the selected state of the selected application AP is selected by the user possessing the chip card CP, or by the chip card CP as a function of characteristics of the context of execution of the application transmitted by the terminal TE.
  • step E7 the user decides that the selected application is at least partially degraded. Otherwise, the process goes to step E8.
  • a degradation consists in step E71 in selecting at least one EL of the elements of the selected state T of the selected application AP that can be degraded.
  • the degradation of an EL element, component or connection consists of a loss of quality or performance of the expected result produced by the component or connection. This degradation is introduced during the installation of the element during the next deployment step proper Eli or E12.
  • the degradation of a calculator-type component concerns, as a parameter, the number of. decimal points of the decimal result of a predetermined calculation. If the user has configured in step E6 that the result of the calculation would contain P digits after the decimal point, he can accept in step E71 that the result and therefore the calculation " be performed only with Q digits after the decimal point, with ' Q ⁇ P.
  • the search engine MR searches for all the calculation components that can calculate with decimal numbers including Q to P digits after the decimal point, and the PI driver does not maintain l installation only of the component found having decimal numbers to be calculated having the largest number of digits after the decimal point.
  • Step E8 relates to the selection of a weighting on the value of at least one property in at least one EL of the elements of the selected state T of the selected application AP. If the user does not want any weighting, the method proceeds to the next step E9.
  • the user selects one of the weightings associated with at least one. EL of the elements, components and connections, of the selected state of the application selected in step E81.
  • the purpose of the weighting is to assist the PI deployment pilot in his reaction to errors and to allow the smart card to be intrinsically scalable over time.
  • one or more properties in one or more descriptors of the EL element are assigned weight so that the user configures the deployment prior to the execution of the actual deployment of the application state comprising at least the affected elements of a selected weight.
  • the weights assigned to the different values of the properties of certain elements of the state of the application allow the PI deployment pilot to choose a configuration of the state of the application according to a degree of satisfaction of the user.
  • PP and PQ denote low and high weights assigned to calculations performed with decimal numbers having P digits and Q encrypted after the decimal point, with P> Q. If the user is looking for rapid deployment, he selects a high weight such as PQ. On the contrary if the user is looking for a more computational result precise and therefore a slower deployment, it selects a low weight, such as PP.
  • a weight can be assigned as a function of the more or less long duration of the execution of a component or of the duration of a connection between two components.
  • the weight of a weighted property of an element is corrected as a function of predetermined quality criteria on at least the deployment of a previous state of the selected application containing said element.
  • the weight of a weighted property is revalued according to the weighted average of quality measurements carried out during the previous deployment or during a predetermined number of previous deployments. The weighting is thus conditioned by the history of previous deployments.
  • step E9 the user decides to select a configuration of at least one property of one of the elements of the selected state T of the selected application AP. Otherwise, the method goes to step E10.
  • a component of the selected application state has configurations that differ in a few different properties.
  • the component can be a means of calculation in decimal numbers having P and Q digits after the decimal point in two configurations, or else a graphical interface presenting color combinations according to two configurations.
  • configurations of at least one selected component or connection of the selected application state, and more generally of. several selected elements of the application state having configurations are selected.
  • the installation of the first configuration found among the selected configurations of each of the elements sought by the search engine MR is then maintained by the deployment pilot PI which ignores the other configurations by a special destruction command (Abort) of these additional configurations .
  • Abort special destruction command
  • the deployment pilot selects one of these configurations a posteriori, for example by retaining only the first which has been received, or by retaining the one which satisfies a predetermined quality criterion, and destroys the other installed configurations.
  • the deployment pilot PI When several configurations of an EL element are selected in step E91, the deployment pilot PI successively transmits several installation commands containing respectively the descriptors of these different configurations of the element, during the deployment below.
  • step E10 the synchronous or asynchronous character of the deployment is selected. If synchronous deployment is chosen, this is developed in step E1.
  • the synchronous deployment of the selected state T of the selected application AP mainly consists of the transmission of sequential commands, one after the other, by the pilot PI to the portal PO to first install all the components of the state d selected application T which are dependent on installations of other elements of the application state T, to configure the components installed respectively in response to acknowledgments from the installations of the components transmitted by the PO portal and according to parameters contained in the descriptors of the components, then to install all the connections of the selected application state T each dependent on two respective installed components respectively in response to acknowledgments of the settings' of the two respective components and as a function of the connection descriptors, and of the settings of all the connections respectively in response to acknowledgments from the connection installations and as a function of parameters contained in the connection descriptors.
  • Asynchronous deployment essentially consists of the transmission of commands in parallel by the PI pilot to the PO portal to install and configure the various elements of the selected state T of the selected application AP.
  • the . Asynchronous deployment naturally begins with the installation of elements, such as the components of the application state T, the installation of which is independent of other installations and depends on the descriptors of the components.
  • the pilot approves substantially in parallel, independently of any scheduling of the elements, parameter settings of the components respectively in response to acknowledgments of installation of; components and according to parameters contained in the component descriptors, installations of the connections of the selected application state T each dependent on at least one installation of two respective components respectively in response each to the acknowledgment of configuration of the two respective components and according to the descriptors connections, and settings of the connections respectively in response to acknowledgments of installation of the connections and according to parameters contained in the descriptors of the connections.
  • the descriptors of the elements of the state of application selected T in the commands include characteristics in particular of property which were selected in the preceding steps E7 to E91. These characteristics concerning the degradation, the weighting and of the configurations of element as well as the synchronous or asynchronous character of the deployment can be selected entirely by the user or selected by the deployment pilot PI possibly with the help of information provided by the user. the user and / or by the reception terminal TE as a function of characteristics of the context transmitted by the terminal TE in step E3, or can be selected in part by the user and in part by the terminal TE.
  • the IP default driver selects the synchronous character for one user or the terminal TE does not intervene, in 'forcing the deployment that it is synchronous.
  • This default choice of synchronous deployment makes it possible to deploy the selected application state on all the terminals, including those which do not have the means to trigger several commands during the processing of the current command.
  • step E11 or E12 After deployment in step E11 or E12, the selected application state deployed T is executed in step E13 from the terminal TE.

Abstract

La carte à puce (CP) comprend un descripteur (DAP) d'un application (AP) composée de plusieurs éléments distante répartis avec des descripteurs (DIU, DAGm, DSEm) des éléments, et un pilote (PI) pour déployer l'application par exemple dans le terminal d'accueil (TE) de la carte. L'application peut être déployée partiellement par le pilote selon l'un de plusieurs états en fonction du contexte et de l'usager de la carte. Un état d'application peut comprendre au moins un, quelques uns ou tous les éléments de l'application. En général, l'application comprend le descripteur (DAGm) d'au moins un élément qualifiant au moins un processus et les descripteurs (DIU, DSEn) d'une interface d'usager et d'au moins un serveur de données. L'invention concerne également le déploiement sélectif de l'application.

Description

Carte à puce avec descripteur d'application
La présente invention concerne des applications décrites dans un objet électronique portable, tel 5 qu'une carte à puce, dite également carte à microcontrôleur ou carte à circuit intégré, et déployée à travers un moyen d'exécution d'application comprenant notamment un terminal d'accueil de la carte à puce, dans un contexte étendu et hétérogène.
10 Dans ce contexte, une application est composée de composants logiciels dispersés dans un . réseau de télécommunication et doit pouvoir être exécutée à partir de terminaux hétérogènes ayant des caractéristiques matérielles et logicielles
15 différentes, tels qu'un terminal radiotéléphone mobile, un assistant électronique personnel et un ordinateur personnel .. Les terminaux hétérogènes diffèrent par exemple par leurs systèmes d'exploitation et leurs caractéristiques de codage de
20 données et de communication.
Actuellement, des usagers accèdent à diverses applications à travers des réseaux de télécommunication, notamment le réseau Internet,
25. quasiment à l'aide de n'importe quel terminal parmi divers terminaux hétérogènes, depuis leurs bureaux, leurs domiciles, ou des bornes d'accès publiques. Malheureusement, les applications ne sont pas capables de se configurer automatiquement en fonction
30 de caractéristiques personnelles à l'usager et il est nécessaire de reconfigurer le terminal de l'usager en fonction de l'application choisie. Pour exécuter correctement les applications, le terminal doit disposer de données de service relatives à
35 l'application à exécuter et aux serveurs distants offrant ces applications, et de données individuelles confidentielles propres à chaque usager et personnalisant l'accès à une ou plusieurs applications. Lorsque les usagers sont sédentaires ces informations sont généralement statiques sur leurs terminaux. En revanche, lorsque les usagers sont itinérants, la carte à puce offre un support autonome, sûr et portable pour fournir ces données aux terminaux que l'usager est susceptible d'utiliser.
Par ailleurs, les fournisseurs d'applications ont intérêt à ce que leurs applications soient utilisables depuis un très grand nombre de terminaux. Une application doit donc être capable de s'adapter au terminal dans lequel elle est exécutée. Par exemple, une application donnée présente une interface graphique complexe à base de fenêtres dans un ordinateur personnel, et de simples menus textuels dans un radiotéléphone mobile, ou établit une communication audio ou vidéo en fonction du débit offert par le réseau.
L'adaptabilité des applications distribuées à leur contexte d'exécution et aux besoins de l'usager devient ainsi une nécessité (cf. article intitulé "Adaptabilité des applications pour des usagers mobiles", Michel RIVEILL et al., OCM'2000, Objets Composants Modèles, 8 Mai 2000) . Il est donc nécessaire de déployer des applications de service en fonction du type du terminal et d'une personnalisation de configuration par l'usager. Cette souplesse requise est obtenue pour une architecture modulaire de chaque application. Chaque application est conçue comme un graphe de composants interconnectés par des connexions. Le déploiement de l'application crée des instances de ces composants en fonction du contexte d'exécution et de caractéristiques personnelles.
Comme montré aux figures 1 et 2, il est connu de définir une application API dans une carte à puce CP1, ou tout autre objet électronique portable présentant une capacité de mémoire relativement faible, par un descripteur DAP1 d'une première application API identifiant des éléments essentiels de l'application, tels que les composants logiciels de l'application et des connexions entre ces composants deux à deux. En général, une application comprend au moins trois composants II, Al et SI et au moins deux connexions CIA1 et CAS1 interconnectant deux à deux les composants II et Al et les composants Al et SI.
Par exemple, le premier composant II est une interface d'usager contenant le point d'entrée de l'application, qui a besoin d'un service de consultation, par exemple un service de consultation bancaire offert par le deuxième composant Al, de manière à récupérer des informations prélevées dans un compte bancaire personnel à l'usager propriétaire de la carte géré par le troisième composant SI constitué par un serveur d'une banque auprès de laquelle un ou plusieurs comptes de l'usager ont été ouverts. Le composant d'interface d'usager II est localisé dans le terminal d'accueil TE, tandis que les deux autres composants Al et SI sont localisés dans des sites différents. Seuls les deux premiers composants II et Al sont paramétrables . Quel que soit le type de terminal, tel qu'un radiotéléphone, un assistant personnel ou ordinateur personnel, l'application peut être exécutée, en s 'adaptant au contexte d'exécution constitué essentiellement par le terminal .
Un composant d'application est une unité de traitement logiciel encapsulant des fonctionnalités, assez petite pour que l'on puisse la créer et la maintenir, et assez grande pour que 1 ' on puisse l'installer et en assurer, le support. Les propriétés fonctionnelles d'un composant sont les possibilités de traitement offertes par le composant et sont programmées et invariantes quel que soit le contexte. Le composant possède également des propriétés non- fonctionnelles qui représentent des aspects systèmes liés à l'implantation du composant, tels que transaction, sécurité, persistance, tolérance aux fautes, et qui sont variables en fonction du contexte et de l'application. La séparation entre propriétés fonctionnelles invariables et non-fonctionnelles variables permet d'exécuter le composant de manière différente sur une plate-forme d'exécution. Le composant est également doté d ' interfaces de communication pour qu'il puisse coopérer avec d'autres composants et ainsi présenter son comportement à ces autres composants. En pratique, un composant logiciel peut être implanté sur n'importe quel site d'un réseau de télécommunication RT.
• Une connexion définit lés relations entre les interfaces de communication de deux composants. Des paramètres des connexions de l'application sont également adaptés au contexte de la plate-forme d'exécution.
Au niveau de la carte à puce CP1, le descripteur d'application DAP1 ne contient pas l'élément lui- même, le composant logiciel ou la connexion, mais un descripteur DU, DCIA1, DA1, DCAS1, DSI de l'élément II, CIA1, Al, CAS1, SI contenant des propriétés et des paramètres de l'élément le définissant et permettant de le retrouver parmi une multitude d' éléments . Les propriétés du descripteur d'un élément sont fixées une fois pour toutes par le fournisseur de l'application qui spécialise l'élément, composant ou connexion, afin de satisfaire les besoins de l'application et de l'usager selon les caractéristiques d'abonnement. Elles indiquent les caractéristiques de la plate-forme sur laquelle l'élément peut être exécuté, ainsi que les besoins systèmes nécessaires à l'exécution. Par exemple, une propriété est le type ou l'adresse d'un élément qui est associé à chaque élément et utilisé pour la recherche du code ou de l'implantation de l'élément, ou est intimement liée a 1 ' application ou à un type d'application, comme la propriété "numéro de compte" associée à un composant, agent de consultation ou serveur1 de compte bancaire. Ces propriétés sont, selon la technique antérieure, figées lors de la souscription au service correspondant à l'application par l'usager de la carte à puce, et ne sont accessibles qu'en lecture seule. D'autres propriétés, dites paramètres, sont de préférence personnalisées par l'usager et peuvent être modifiées à tout instant. Par exemple, un paramètre a pour valeur la monnaie d'affichage d'un montant, ou bien une panoplie de couleurs pour l'affichage de pages sur un écran, ou bien encore la valeur du débit ou d'une caractéristique de transmission dans une connexion.
Chaque descripteur d'une application est représenté sous la forme d'un graphe d'objet en langage orienté objet, par exemple le langage JAVA (marque "déposée) . Les descripteurs des applications dans une carte à puce multi-applications sont réunis dans une applet qui fait office d'un serveur de descripteur créant l'arborescence des objets représentant les composants et les connexions des descripteurs. Selon un autre exemple, les descripteurs des applications sont écrits avec le langage XML (Extensible Markup Langage) .
Au serveur de descripteurs constituant .1 'applet est associé un client, appelé pilote de déploiement PII (en anglais bootstrap) qui constitue au sein de la carte à puce. CP1 une application pour configurer l'application sélectionnée en fonction de son descripteur. Le pilote gère le déploiement d'éléments de l'application sélectionnée, après l'introduction de la carte CP1 dans le terminal d'accueil TE. En groupant le serveur de descripteurs et le pilote de déploiement dans la carte, la confidentialité des descripteurs est assurée si bien que la lecture des descripteurs par le "pilote de déploiement constituant un client connu ne nécessite pas d'authentification. En revanche, le pilote de déploiement authentifie chaque client qui 1 ' interroge avant de mettre à sa disposition l'ensemble des méthodes de l' applet. Lorsque l'usager a sélectionné une application API, le pilote de déploiement PI informe le serveur de descripteurs qui considère alors toutes les requêtes qui lui sont adressées comme étant relatives au descripteur DAP1 de l'application sélectionnée. Le pilote PI traite ainsi un ou plusieurs déploiements d'application en fonction du descripteur DAP1 de l'application sélectionnée API et du contexte d'exécution de l'application constitué essentiellement par le terminal TE. Comme déjà dit, un élément d'application, composant ou connexion, est configuré en fonction du contexte de l'application, c'est-à-dire des propriétés matérielles et logicielles de la plate- forme où sera exécutée l'application, et de paramètres choisis par l'usager et personnalisant l'application. Les propriétés du contexte d'exécution fournies par le terminal sont par exemple le type du terminal d'accueil utilisé TE, le nom du terminal, un certificat ou clé d'identification du terminal, la localisation du terminal dans le réseau de télécommunication et une date de fabrication du terminal. Toutes ces informations sont regroupées dans le descripteur de l'élément d'application afin que le pilote de déploiement PI filtre les informations contenues dans le descripteur de l'élément en fonction du contexte de l'application et des paramètres de personnalisation de l'usager.
Le pilote de déploiement PI localisé dans la carte à puce CP transmet des commandes de déploiement à un portail de déploiement PO qui est un élément applicatif implémenté dans le terminal d'accueil TE. Le portail a pour principal rôle de recevoir les commandes de déploiement et de les ré-émettre vers la plate-forme de déploiement afin d'installer l'application sélectionnée. Ainsi le portail de déploiement a principalement une fonction d'information de la carte à puce sur l'environnement dans lequel l'installation et l'exécution de l'application sélectionnée doivent être faites, et une fonction de communication avec la carte afin de recevoir diverses commandes de déploiement de l'application sélectionnée. Le déploiement d'une application est synchrone, c'est-à-dire les commandes élaborées par le pilote de déploiement PI sont transmises séquentiellement au terminal TE, les unes' après les autres, respectivement pour l'installation des éléments de l'application, puis pour le paramétrage des éléments de l'application. Après ces installations et paramétrages d'éléments, l'application est lancée par une commande d'exécution (RUN) qui contient le nom du composant de l'application sélectionnée déterminant le point d'entrée de l'application, généralement le composant d'interface d'usager.
Le déploiement est réalisé par le pilote de déploiement a partir du descripteur DAP1 de l'application sélectionnée API afin qu'un dialogue soit établi entre le pilote de déploiement PII dans la carte à puce CP1 et le portail de déploiement PO dans le terminal d'accueil TE. Le portail peut contenir un moteur de recherche d'éléments, ou être en liaison avec un ou plusieurs moteurs de recherche d'éléments MR, comme montré à la figure 2.. Chaque moteur de recherche MR constitue un annuaire d'éléments d'application pour référencer et rechercher, des éléments d'application dans des bibliothèques d'éléments d'application BI à travers le réseau de télécommunication RT. Chaque élément dans une bibliothèque est mémorisé avec son descripteur et géré par le concepteur de 1 ' élément .
Selon la technique antérieure, l'ensemble des composants et connexions constituant une application, avec les valeurs de ces propriétés et paramètres, définit un profil de l'application. Ainsi deux usagers différents peuvent avoir des profils d'application différents à cause des paramètres des applications définis par les usagers avec des valeurs différentes, telles que les numéros de compte bancaire. Réciproquement, un seul usager peut configurer une - application suivant plusieurs profils différents. Les profils d'une application sont ainsi définis soit par l'usager, soit automatiquement en fonction du contexte d'utilisation de l'application, qui peut dépendre notamment du terminal d'accueil et particulièrement du système d'exploitation implemente dans celui-ci. Ainsi, lors du déploiement de l'application, certaines valeurs des paramètres d'un composant dépendent notamment du type, du nom et de la localisation du terminal.
Toutes ces modifications d'un ou plusieurs. paramètres d'un ou plusieurs composants de l'application ne permettent pas à l'usager de déployer l'application de consultation bancaire API assignée à une première banque Bl, pour l'exécuter en relation avec .une deuxième banque B2, bien que les opérations de consultation des comptes dans les deux banques soient a priori analogues pour l'usager.
Si l'usager a ouvert des comptes dans une deuxième banque, il possède une deuxième carte à puce CP2 contenant un pilote de déploiement PI2 et le descripteur d'une deuxième application CP2 similaire à la première application CP1, comme montré à la figure 1. Le descripteur de l'application AP2 également montré à la figure 2 comporte des descripteurs DI2, DA2, DS2, DCIA2 et DCAS2 d'une interface d'usager 12, d'un agent de consultation bancaire A2 , d'un serveur bancaire S2 et de connexions CIA2 et CAS2 entre les composants 12 et A2, et A2 et S2. Même si les deux applications de service bancaire API et AP2 ont leurs descripteurs mémorisés dans une carte à puce multi-applications commune, les applications API et AP2 sont complètement séparées et indépendantes, bien que les agents de consultation Al et A2 présentent des fonctionnalités analogues par rapport à la gestion des comptes bancaires dont les données sont incluses dans les composants serveurs SI et S2. Il en est de même relativement aux interfaces d'usager II et 12.
En pratique, l'usager ne peut pas effectuer des opérations dépendant de ces deux comptes bancaires . Par exemple, si les agents Al et A2 sont des agents de virement, un virement du compte bancaire géré par le premier serveur SI vers le compte bancaire géré par le deuxième serveur S2 est impossible par l'un ou l'autre des agents Al et A2. En outre, le déploiement d'une application API est total.. En d'autres termes,' tous les composants API, Al et SI de l'application doivent être trouvés par le moteur de recherche MR quel que soit le contexte d'exécution, en particulier le terminal TE, pour exécuter l'application. Par exemple, si l'usager souhaite consulter de nouveau ses comptes relatifs à la banque Bl, les composants de l'application API, y compris le serveur SI, doivent être installés alors que les dernières informations consultées sont mémorisées dans la carte CP1 et leur lecture ne nécessite pas 1 ' intervention du composant serveur SI . Pour cette lecture, l'application de consultation bancaire API est déployée sur un terminal sécurisé, bien que le caractère sécurisant du terminal ne soit pas nécessaire pour une telle application.
L'invention a donc pour objectif de remédier aux inconvénients précités. de la description des applications à éléments répartis selon la technique antérieure de manière à offrir des applications plus globales pour l'usager et pouvant être déployées que partiellement sous la commande de l'usager ou en fonction du contexte environnant la plate-forme d'exécution de l'application.
A cette fin, un objet électronique portable du type carte à microcontrôleur, comprenant un moyen pour décrire une application composée de plusieurs éléments distants répartis avec des descripteurs des éléments, et un moyen pour déployer l'application à l'extérieur de l'objet électronique en fonction des descripteurs d'éléments, est caractérisé en ce que le moyen pour décrire combine plusieurs états de l'application qui sont déployés sélectivement à l'extérieur de l'objet électronique sous la commande du moyen pour déployer, et qui comprennent chacun au moins un élément de l'application. Ledit au moins un élément peut être par exemple une interface d'usager, ou un agent qualifiant au moins un processus et fonctionnant seul, ou bien encore un serveur fonctionnant seul. Toutefois, un état de l'application comprend deux, ou quelques uns ou tous les éléments de l'application. Le moyen pour décrire l'application peut comprendre alors le descripteur d'une interface d'usager, et/ou le descripteur d'au moins un élément qualifiant au moins un processus, et/ou le descripteur d'au moins un serveur de données .
L'un des états de l'application peut comprendre les paramètres d'au moins un élément compris dans cet état. Ainsi, des états diffèrent par exemple par des paramètres d'un élément commun.
L'invention concerne également un procédé pour configurer et déployer une applicatio composée de plusieurs éléments distants répartis depuis un objet électronique portable conforme à 1 ' invention, contenant des descripteurs des éléments, à travers un moyen de traitement de données relié à des moyens d'implantation des éléments pour exécuter l'application configurée et déployée. Le procédé est caractérisé en qu'après une transmission de caractéristiques du contexte d'exécution de l'application dépuis le moyen de traitement vers l'objet électronique portable, il comprend une sélection de l'un des états de l'application qui comprennent chacun au moins un élément de l'application.
De préférence, un élément, par exemple un agent qualifiant un processus, n'est activé que par l'usager u par la plate-forme d'exécution, par exemple le terminal d'accueil d'une carte, à puce inclus dans ledit moyen de traitement de données . A cet égard, le procédé comprend, avec la transmission de caractéristiques du contexte d'exécution de l'application, la transmission d'une clé associée à un élément de l'application, et le déploiement d'un état sélectionné de l'application comprenant 1 ' élément seulement en réponse à une détection préalable de la clé prédéterminée par l'objet électronique portable. En variante, plusieurs clés peuvent être associées respectivement à des éléments de l'application, la sélection d'un état parmi des états de l'application comprenant au moins des connexions avec les éléments associées aux clés transmises .
Le procédé comprend de préférence une sélection de l'un de plusieurs déploiements de l'état sélectionné de l'application, de manière à adapter le déploiement au contexte de l'application et si possible augmenter la rapidité d'exécution.
Selon l'invention, le déploiement est essentiellement asynchrone, ou bien essentiellement
5 synchrone, le caractère synchrone pouvant être choisi par défaut parce qu'il est compatible avec tous les moyens de traitement de données actuels.
L'un des déploiements asynchrone ou synchrone peut comporter l'installation d'au moins un élément
10 de l'application ayant au moins une propriété présentant une dégradation, sélectionnée préalablement, ou bien l'installation d'au moins un élément de 1 ' application ayant une propriété associée à un poids, sélectionnée préalablement, ou bien
15 encore l'installation de la première trouvée de plusieurs configurations sélectionnées, préalablement d'au moins un élément de l'application, les configurations d'élément ayant au moins une valeur de propriété différente. L'une de valeurs d'une
20 propriété ou l'une de plusieurs propriétés dans le descripteur d ' au moins un élément de 1 ' état d'application sélectionné peut être sélectionnée par un usager possesseur de l'objet électronique portable ou par l'objet électronique portable en fonction du
25 contexte d'exécution de l'application transmis par le moyen de traitement.
D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la
30. lecture de la description suivante de plusieurs réalisations préférées de 1 ' invention en référence aux dessins annexés correspondants dans lesquels : la figure 1, déjà commentée, montre la modularité de deux applications en trois composants 35 par exemple ; - la figure 2, déjà commentée, est un bloc- diagramme schématique des moyens mis en oeuvre dans un réseau de télécommunication pour le déploiement d'applications d'éléments distants répartis, selon la technique antérieure ;
- la figure 3 est un graphe des états d'une application globale selon 1 ' invention ;
- la figure 4 est analogue à la figure 2, mais avec une carte à puce selon l'invention , - - la figure 5 est un graphe des états principaux d'une application bancaire selon l'invention ;
- les figures 5A et 5B sont des graphes d ' états seulement entre deux composants de l'application de la figure 5, respectivement ,- - la figure 6 est un graphe d'états pour une variante d'application bancaire ;
- les figures 7 et 8 sont des graphes de deux applications selon l'invention respectivement à un seul agent et à un seul serveur ; et - la figure 9 est un algorithme de configuration et déploiement d'application selon l'invention.
En référence à la figure 3, une application AP selon l'invention est composée de plusieurs éléments distants répartis qui sont une interface d'usager IU, des agents AGI à AGM et des serveurs de données SEl à SEN, l'un au moins des entiers M et N étant supérieur à 1. Dans . la figure 3 sont également représentés d'autres éléments de l'application AP constituant des connexions CIAG1 à CIAGM respectivement entre l'interface IU et les agents AGI à AGM et des connexions CAS11-CAS1N à CASM1-CASMN respectivement entre chacun des agents AGI à AGM et les serveurs SEl à SEN. Une ou plusieurs telles applications sont décrites sous la forme de descripteurs dans une carte à puce CP, ou tout autre objet électronique portable, comme montré à la figure 4. Selon cette figure, la
•5 carte à puce comprend au moins le descripteur DAP de 1 ' application AP incluant les descripteurs DIU, DAG1 à DAGM et DSE1 à DSEN des composants et les descripteurs des connexions de l'application. Les descripteurs des connexions dans la figure 4 ne sont 0 pas repérés pour plus de clarté.
L'interface d'usager IU est localisée dans le terminal d'accueil TE de la carte à puce CP, le terminal d'accueil TE étant relié à un réseau de
. télécommunication RT avec au moins un moteur de 5 recherche MR et au moins une bibliothèque d'éléments d'application Bl, comme cela a déjà été décrit en référence à la figure 2. L'interface d'usager constitue essentiellement 1 ' interface homme-machine qui est paramétrée par l'usager notamment au niveau 0 du., graphisme des pages d'écran et de l'écoute de. messages vocaux. L'interface d'usager IU présente ainsi visuellement et/ou vocalement des données transmises par au moins l'un des agents AGI à AGM inclus dans l'état sélectionné de l'application, 5 comme le verra dans la suite. Inversement, des commandes à traiter par un agent de 1 ' état sélectionné sont saisies par l'interface IU pour déclencher des opérations sur des données dans l'un ou plusieurs des serveurs SEl à SEN inclus dans 0 l'état sélectionné de l'application. Initialement, l'usager peut avoir la possibilité de sélectionner des états de l'application AP et des données relatives à ceux-ci. Ces états et ces données sont contenus dans le descripteur DIU et sauvegardés dans 5 la mémoire non volatile EEPROM de la carte à puce CP entre deux sessions de l'application, c'est-à-dire entre deux sélections d'états de l'application. L'interface d'usager IU est ainsi un composant de type session qui est créé en début de session et détruit totalement ou partiellement à chaque fin de session. L'interface d'usager IU constitue le point d'entrée de l'application AP pour l'usager, et intervient donc chaque fois que l'usager souhaite faire exécuter directement l'un des états de l'application AP.
Un agent AGm, avec 1 < m < M, qualifie au moins un processus prédéterminé pour traiter des données transmises par l'interface d'usager IU lorsque celle- ci est reliée à l'agent AGm, et/ou pour traiter des données transmises par au moins l'un des serveurs SEl à SEN lorsque celui-ci est relié à l'agent AGm pour l'état sélectionné de l'application. L'agent AGm est paramétrable par l'usager depuis l'interface IU et/ou selon les caractéristiques du contexte dé l'application dépendant essentiellement de caractéristiques du terminai d'accueil TE de la carte à puce CP. Le descripteur DAGm de l'agent AGm possède ainsi plusieurs paramètres dont les valeurs programmées notamment par 1 'usager sont sauvegardées dans la mémoire non volatile de la carte à puce. L ' agent AGm est donc de type processus ce qui implique qu'il peut être maintenu lors d'une terminaison partielle de 1 ' état sélectionné de l'application. A cet égard, par exemple, lorsque l'usager a requis lors d'une session précédente un état hors ligne de l'application, cet état hors ligne est exécuté pour que 1 ' agent AGm traite des données de l'un ou de plusieurs des serveurs SEl à SEN inclus dans l'état d'application sélectionné, sans aucune intervention de l'interface d'usager IU qui est maintenue hors ligne.
Un serveur de données SEn est une entité contenant des données qui peuvent être consultées ou traitées par l'un des agents AGI à AGM de manière à retransmettre les données sans ou avec modification à l'interface d'usager IU et/ou au serveur SEn et/ou au moins à un autre serveur. L'état du serveur SEn est indépendant de l'usager, c'est-à-dire ne peut être modifié par l'interface d'usager IU, et est géré par le concepteur du serveur SEn, tout comme un agent AGm est géré par le concepteur de l'agent AGm, depuis un terminal approprié à travers le réseau RT. Le serveur SEn peut traiter éventuellement en parallèle plusieurs requêtes provenant d'agents relatifs respectivement à plusieurs applications et donc à plusieurs usagers.
De très nombreux états de l'application AP peuvent être sélectionnés. Un état de l'application AP peu étendu comprend au minimum un ou deux composants différents, soit l'interface d'usager IU et/ou 1 ' agent AGm reliés par la connexion correspondante CIAGm, soit un agent AGm et/ou l'un des serveurs SEl à SEN reliés par la connexion correspondante CASml à CASmN, avec 1 < m < M. L'état "global" le plus étendu de l'application est 1 ' agencement de 1 ' interface IU, de tous les agents AGI à AGM et de tous les serveurs SEl à SEN avec toutes les connexions montrées à la figure 3. Entre les états "minimums" peu étendus et l'état très étendu, des états intermédiaires comprennent un ou plusieurs agents AGI à AGM pouvant être reliés chacun à l'interface d'usager IU et/ou à un ou plusieurs serveurs respectifs SEl à SEN. Afin de fixer les idées, plusieurs réalisations d'application APB, APC, APJ et APE présentant plusieurs états selon l'invention sont décrites ci- après .
Comme montré à la figure 5, une application APB est relative à un service inter-bancaire et intercompte. L'application APB comprend globalement comme éléments, une interface d'usager IU, deux agents AGC et AGV dédiés à de la consultation bancaire et à du virement bancaire, et N serveurs de données SBl à SBN contenant les données des divers comptes que l'usager a ouverts dans N banques.
Dans l'un de premiers états Tl de l'application APB, comme montré en trait plein à la figure 5, l'agent de consultation bancaire AGC est relié à l'interface d'usager et à l'un ou plusieurs des serveurs de banque SBl à SBN. L'usager peut alors sélectionner ses comptes dans une liste présentée par l'interface IU afin de connecter les comptes qui sont ouverts dans les diverses banques correspondant aux serveurs SBl à SBN en relation avec l'agent AGC.
A l'un de deuxièmes états T2 de l'application APB, comme montré en traits pointillés à la figure 5, 1 ' agent de virement bancaire AGV est intermédiaire entre l'interface d'usager IU et l'un ou plusieurs des serveurs de banque SBl à SBN. L'agent AGV peut être paramétré par l'usager pour effectuer un virement automatique par exemple entre deux comptes gérés par le même serveur SBn, ou entre deux comptes gérés respectivement par des serveurs différents SBn et SBp, avec p≠n et 1 < p < N.
Comme déjà dit, les descriptions des états de 1 ' interface IU et des agents AGC et AGV sont sauvegardées dans la mémoire non volatile de la carte à puce CP ; ainsi celle-ci mémorise la liste des identificateurs des comptes bancaires de l'usager et au moins leurs derniers soldes connus, et les états fonctionnels dernièrement paramétrés des agents AGC et AGV.
Les figures 5A et 5B montrent des états minimums T3 et T4 de 1 ' application. de service bancaire APB.
A la. figure 5A, l'état T3 concerne la connexion entre . 1 ' interface d 'usager IU et 1 ' agent de consultation bancaire AGC. Cet état est sélectionné par l'usager lorsque celui-ci souhaite consulter à nouveau les dernières' données qu'il a sauvegardé dans la carte à puce CP lors de, dernières consultations des serveurs SBl à SBN. Toutefois, l'état T3 peut être imposé par le contexte d'exécution de l'application. A cet égard, une clé prédéterminée KAGC est associée - au descripteur DAGC de 1 ' agent AGC contenu dans le descripteur DAP de l'application AP inclus dans la carte à puce CP. Si aucune clé ou une clé de valeur nulle est transmise avec les caractéristiques du contexte d'application par le portail PO du terminal TE au pilote de déploiement PI dans la carte à puce CP préalablement à la sélection d'un. état d'application, ou plus généralement de l'application AP, comme on le verra dans la suite, le pilote - PI ne reconnaissant pas la clé KAGC n'installe pas et donc interdit toute connexion depuis 1 ' agent AGC vers les serveurs SBl à SBN. Par conséquent le pilote PI n'autorise que la connexion de l'agent AGC avec l'interface d'usager IU selon l'état d'application T3 montré à la figure 5A.
En revanche, si le terminal TE transmet la clé KAGC au pilote de déploiement PI, ce dernier autorise l'agent AGC à être relié à au moins l'un des serveurs SBl à SBN.
La clé KAGC permet ainsi de valider des connexions sécurisées dans des états prédéterminés de l'application. Plus généralement, concomitamment à la transmission de caractéristiques du contexte d'exécution de l'application depuis le terminal TE vers le pilote PI, la transmission d'une clé prédéterminée KAGC, KAGV associée à un élément donné, tel que l'un des. agents AGC et AGV qualifiant au moins un processus, susceptible d'être connecté à deux autres éléments de l'application, tels que deux des serveurs SBn à SBp ou l'un de ces serveurs et l'interface d'usager IU, par le terminal d'accueil TE est obligatoire afin que le pilote PI de la carte CP n'autorise le déploiement d'un état sélectionné de
•l'application comprenant ledit élément donné AGC ou
AGV connecté aux deux autres éléments IU et SBn ou
SBp seulement en réponse à une détection préalable de la clé prédéterminée par la carte à puce CP. La clé est seulement connue par l'usager et saisie par l'interface IU.
L'état T4 de l'application APB montré à la figure 5B . met en relation 1 ' agent de virement bancaire AGV et deux SBn et SBp des serveurs de banque. Cet état est un état hors ligne pour lequel l'interface d'usager IU n'est pas connectée à l'agent AGV, c'est-à-dire pour lequel le terminal d'usager TE n'a aucun accès à des serveurs à travers l'agent AGV. L'état T4 a été programmé par l'usager lors d'un état précédent connectant l'interface d'usager IU aux serveurs SBn et SBp par 1 ' intermédiaire de 1 ' agent de virement bancaire AGV de manière à paramétrer des virements automatiques au moins entre l'un des comptes géré par le serveur SBn et l'un des comptes gérés par le serveur SBp. Par exemple, si l'un Cn des comptes gérés par le serveur SBn est un compte chèque et si l'un Cp des ..comptes gérés par le serveur SBp est un compte d'épargne, l'usager peut programmé l'un des deux ensembles d'opérations suivants :
- pour épargner un montant Mn dans le compte Cp lorsque le solde du compte chèque Cn atteint un seuil SUP, soit le virement automatique suivant : si Cn > SUP alors Cn = Cn - Mn et Cp = Cp 4- Mn ; au contraire, pour régler des dépenses débitées sur le compte chèque Cn en créditant , un montant Mp tiré du compte d'épargne Cp lorsque le compte chèque Cn à un solde inférieur à un seuil INF, soit le virement automatique suivant : si Cn < INF avec INF < SUP alors Cp = Cp - Mp et Cn = Cn + Mp. Chacun des deux virements automatiques précédents est programmé par l'usager dans l'agent AGV afin qu'il puisse être exécuté hors ligne, comme montré à la figure 5B, d'une manière périodique, par exemple après chaque journée, dès que le solde Cn du compte chèque est devenu supérieur au. seuil SUP ou est devenu inférieur au seuil INF.
De préférence, comme, déjà dit, une opération de virement au moyen de 1 ' gent de virement bancaire AGV ne peut être effectuée que sur une plate-forme d'exécution, en 1 ' occurrence • le terminal d'accueil TE, . qui a fournie une clé de sécurité KAGV qui est seulement connue par l'usager et reconnue par le pilote PI dans la carte à puce CP de manière à installer les connexions de l'agent AGV avec des serveurs en fonction du descripteur de celui-ci contenu dans le descripteur DAP de l'application AP.
Il sera noté qu'en addition à la sélection de l'un des états de l'application APB, l'usager peut également choisir des valeurs de paramètre de l'interface IU et des agents AGC et AGV-. Par exemple, l'usager sélectionne l'une de plusieurs langues d'affichage dans l'interf ce d'usager IU et l'une de plusieurs monnaies dans l'agent AGC ou l'agent AGV.
Une application APC, comme montré à la figure 6, présente un état global dans lequel chacun d'au moins M = 3 agents AGCl, AGCm et AGCM n'est connecté qu'à un serveur de données respectif SCI, SCm ou SCM. Par exemple, l'application APC est une variante d'une application de service bancaire. Les couples d'agent et de serveur AGCl-SCl, AGCm-SCm et AGCM-SCM sont relatifs à la consultation et à la gestion d'un compte chèque, d'un compte de livret d'épargne et d'un compte de titres. Optionnellement, l'agent AGCM peut être également connecté à un serveur de données boursières SCB. Tous les agents AGCl à AGCM. sont connectés à l'interface d'usager IU. Dans cette architecture d'application, un agent de virement AGVC est intermédiaire entre l'interface d'usager IU et les agents de consultation de compte AGCl à AGCM afin d'effectuer des virements automatiques de l'un vers 1 ' autre des comptes dont les données sont incluses dans les serveurs SCI à SCM. Ainsi, le descripteur décrivant l'application APC dans la carte CP ne comprend que les descripteurs des éléments suivants : l'interface d'usager IU, • plusieurs éléments AGCl à AGCM qualifiant chacun au moins un processus, et plusieurs serveurs de données SCI à SCM pouvant être connectés respectivement aux éléments qualifiants.
Selon une deuxième réalisation, 'une application APJ comprend un état global qui met en relation un seul agent AGJ avec l'interface d'usager IU et N serveur de données SJ1 à SJN.
L'application APJ est par exemple relative à un jeu commun à N joueurs Jl à JN, y compris le joueur, par exemple Jl, possesseur de la carte puce CP et déployant l'application de jeu APJ sur le terminal TE . Par exemple 1 ' agent AGJ est un concentrateur- diffuseur de jeu tandis que les composants de serveur SJ1 à SJN sont installés respectivement dans des terminaux des joueurs Jl à JN.
Ainsi, le descripteur décrivant l'application APJ dans la carte CP comprend les descripteurs des éléments suivants : l'interface d'usager IU, l'élément APJ qualifiant au moins un processus, et plusieurs serveurs de données SJ1 à SJN pouvant être connectés sélectivement à l'élément qualifiant.
Une troisième réalisation d.' application ' selon 1 ' invention montrée à la figure 8 concerne une application APE dont l'état global comprend M agents AGEl à AGEM pouvant être connectés chacun à 1 ' interf ce d' usager IU et à un serveur de données commun SE.
Par exemple, le serveur SE est un serveur de courrier électronique recevant des messages électroniques de divers correspondants de l'usager possesseur de la carte à puce CP. Les agents AGEl à AGEM filtrent les messages chacun selon des conditions prédéterminées . Par exemple, l'agent AGEl ne retransmet à l'interface d'usager IU que tous les messages provenant d'expéditeurs privés dont les adresses sont répertoriées dans un premier annuaire de manière à ne mémoriser que ces messages d'ordre privé dans la carte à puce CP ; l'agent AGEm filtre des messages ne provenant que d'expéditeurs professionnels répertoriés dans un deuxième annuaire et signale seulement la réception d'un message professionnel à l'interface d'usager IU et retransmet chaque message professionnel vers un serveur destinateur situé sur le lieu professionnel de l'usager ; l'agent AGEM contient les premier et deuxième annuaires des agents AGEl et AGEm afin de ne filtrer que les messages provenant d ' expéditeurs non répertoriés dans ces deux annuaires et signaler à l'interf ce d'usager IU qu'un tel message a été enregistré et qu'un acquittement, d'attente de traitement de message a été renvoyé à l'expéditeur du message. Ainsi, le descripteur décrivant l'application APE dans la carte CP ne comprend que les' descripteurs des éléments suivants : l'interface d'usager IU, plusieurs éléments AGEl à AGEM qualifiant chacun au moins un processus, et un seul serveur de données SE pouvant être connecté sélectivement aux" éléments qualifiants.
En référence maintenant à la figure 9, la configuration et le déploiement de l'état sélectionné d'une application sélectionnée AP dans une carte à puce multi-applications CP comprend les étapes, suivantes El à E13.
Tout d'abord, l'usager introduit la carte à puce CP dans la fente de lecteur du terminal d'accueil TE à l'étape El, le terminal d'accueil étant par exemple un terminal radiotélephonique mobile, un assistant électronique personnel ou un ordinateur personnel . Après l'introduction de la carte à puce, celle-ci authentifie l'usager par l'intermédiaire d'un code confidentiel ou d'une empreinte biomêtrique saisie par le terminal TE, à 1 ' étape E2.
Puis au cours du dialogue établi entre la carte à puce et le terminal d'accueil, des caractéristiques du contexte d'exécution sont transmises par le terminal TE au pilote de déploiement PI dans la carte à puce CP, à l'étape E3. Le contexte de 1 ' environnement matériel extérieur à la carte à puce est défini par des caractéristiques de la plate-forme d'exécution qui sont transmises par le terminal TE à la carte à puce CP à l'étape E3. Les caractéristiques du contexte d'exécution fournies par le terminal sont par exemple le type du terminal d'accueil utilisé TE, le nom du terminal, un certificat ou clé d'identification du terminal, la localisation du terminal dans le réseau de télécommunication et une date de fabrication du terminal. Ces caractéristiques permettent au pilote de déploiement PI de limiter la quantité de données qu'il transmet au portail de déploiement PO et ainsi de minimiser la durée du déploiement. Les caractéristiques du contexte d ' exécution peuvent comprendre au moins une clé de sécurisation, telle que les clés KAGC et KAGV (figures 5A, 5B) , composées par l'usager dans le terminal TE et susceptibles d'être attribuées à l'accès de connexions avec des éléments, tels qu'agents AGC et AGV, de l'application sélectionnée AP ci-après.
A l'étape suivante E4, l'usager sélectionne l'une AP des applications dont les descripteurs DAP sont mémorisés dans la carte à puce CP. En fonction notamment des clés de contexte composées par l'usager et transmises par le terminal TÈ, le pilote PI retransmet la liste des états T de l'application sélectionnée AP autorisés par la carte CP en fonction du contexte. A l'étape E5, l'un T des états autorisés de l'application sélectionnée AP est sélectionné par l'usager dans la liste d'états autorisés affichée par le terminal TE. En particulier, l'état sélectionné T comprend au moins des connexions avec les éléments associés aux clés transmises.
A 1 ' étape E6 , le terminal TE selon le contexte et de préférence selon des souhaits de l'usager paramètre le descripteur DT, c'est-à-dire paramètre certains des ou éventuellement tous les descripteurs des composants et connexions de 1 ' état sélectionné T de l'application sélectionnée AP. Le paramétrage par l'usager est classique à l'aide de menus arborescents demandant des valeurs de paramètre .
A la suite des étapes dé sélection d'application et d'état d'application et de paramétrage des composants de l'état sélectionné El à E6, le procédé propose plusieurs choix de déploiement à des étapes E7, E8, E9 et E10 selon une réalisation complète de l'invention, bien qu'en variante, le procédé ne peut comprendre que l'une ou quelques unes des étapes E7 à E10. En particulier, aux étapes E7, E8 et E9, l'une de valeurs d'une propriété ou l'une de plusieurs propriétés dans le descripteur d'au moins un élément EL de 1 ' état sélectionné de 1 ' application sélectionnée AP est sélectionnée par l'usager possesseur de la carte à puce CP, ou par la carte à puce CP en fonction de caractéristiques du contexte d'exécution de l'application transmis par le terminal TE. A l'étape E7, l'usager décide que l'application sélectionnée soit dégradée au moins partiellement. Sinon, le procédé passe à l'étape E8.
Une dégradation consiste à l'étape E71 à sélectionner au moins l'un EL des éléments de l'état sélectionné T de l'application sélectionnée AP pouvant être dégradée. La dégradation d'un élément EL, composant ou connexion, consiste en μne perte de qualité ou de performance du résultat attendu produit par le composant ou la connexion. Cette dégradation est introduite lors de 1 ' installation de l'élément au cours de 1 ' étape suivante de déploiement proprement dit Eli ou E12.
Par exemple, la dégradation d'un composant de type calculette concerne, comme paramètre, le nombre de. chiffres suivant la virgule du résultat décimal d'un calcul prédéterminé. Si l'usager a paramétré à l'étape E6 que le résultat du calcul contiendrait P chiffres après la virgule, il peut accepter à l'étape E71 que le résultat et par conséquent le calcul "soit effectué uniquement avec Q chiffres après la virgule, avec' Q<P. Lors de l'installation du composant de calcul, le moteur de recherche MR recherche tous les composants de calcul pouvant calculer avec des nombres décimaux comprenant Q à P chiffres après la virgule,, et le pilote PI ne maintient l'installation que du composant trouvé présentant des nombres décimaux à calculer ayant le plus grand nombre de chiffres après la virgule. Si aucun composant de calcul n'est trouvé avec des nombres décimaux ayant au moins Q chiffres après là virgule, le pilote PI émet un message d'erreur qui stoppe le déploiement de 1 'application. L'étape E8 est relative à la sélection d'une pondération sur la valeur d'au moins une propriété dans au moins l'un EL des éléments de l'état sélectionné T de l'application sélectionnée AP. Si l'usager ne souhaite aucune pondération, le procédé passe à l'étape suivante E9.
Lorsque la pondération est sélectionnée, l'usager sélectionne l'une des pondérations associées à au moins l'un. EL des éléments, composants et connexions, de l'état sélectionné de l'application sélectionnée à l'étape E81. La pondération a pour objectif d'assister le pilote de déploiement PI dans sa réaction aux erreurs et de permettre à la carte à puce d'être intrinsèquement évolutive, au cours du temps.
Préalablement, une ou plusieurs propriétés dans un ou plusieurs descripteurs de 1 ' élément EL sont affectées de poids afin que l'usager configure le déploiement préalablement à l'exécution du déploiement proprement dit de l'état d'application comprenant au moins les éléments affectés d'un poids sélectionné. Les poids attribués aux différentes valeurs des propriétés de certains éléments dé l'état de l'application permettent au pilote de déploiement PI de choisir une configuration de l'état de l'application selon un degré de satisfaction de l'usager.
Selon l'exemple précédent, il est supposé que PP et PQ désignent des poids faible et élevé attribués à des calculs effectués avec des nombres décimaux ayant P chiffres et Q chiffrés après la virgule, avec P>Q. Si l'usager recherche un déploiement rapide, il sélectionne un poids élevé tel que PQ. Au contraire si l'usager recherche un résultat de calcul plus précis et donc un déploiement plus lent, il sélectionne un poids faible, tel que PP.
Selon un autre exemple, un poids peut être affecté en fonction de la durée plus ou moins longue de l'exécution d'un composant ou de la durée d'une connexion entre deux composants.
De préférence, le poids d'une propriété pondérée d'un élément est corrigé en fonction de critères de qualité prédéterminés sur au moins le déploiement d'un état précédent de l'application sélectionnée contenant ledit élément. Par exemple, le poids d'une propriété pondérée est revalorisé en fonction de la moyenne pondérée de mesures de qualité effectuées lors du déploiement précédent ou lors d'un nombre prédéterminé de déploiements précédents. La pondération est ainsi conditionnée par l'historique des déploiements précédents.
A l'étape E9, l'usager décide de sélectionner une configuration d'au, moins une propriété de l'un des éléments de l'état sélectionné T de l'application sélectionnée AP. Sinon, le procédé passe à l'étape E10.
Par exemple, un composant de l'état d'application sélectionné présente des configurations qui diffèrent par quelques propriétés différentes. Le composant peut être un moyen de calcul en nombre décimaux ayant P et Q chiffres après la virgule selon deux configurations, ou bien une interface graphique présentant des combinaisons de couleur selon deux configurations. A l'étape E91, des configurations d'au moins un composant ou une connexion sélectionné de l'état d'application sélectionné, et plus généralement de. plusieurs éléments sélectionnés de l'état d'application présentant des configurations, sont sélectionnées. L'installation de la première configuration trouvée parmi les configurations sélectionnées de chacun des éléments recherchés par le moteur de recherche MR est alors maintenue par le pilote de déploiement PI qui ignore les autres configurations par une commande de destruction spéciale (Abort) de ces configurations supplémentaires. Plus précisément, après réception des acquittements des installations de ces différentes configurations d'élément, le pilote de déploiement sélectionne a posteriori l'une de ces configurations, par exemple en ne retenant que la première qui a été reçue, ou en ne retenant celle qui satisfait un critère de qualité prédéterminé, et en détruisant les autres configurations installées.
Lorsque plusieurs configurations d'un élément EL sont sélectionnées à l'étape E91, le pilote de déploiement PI transmet successivement plusieurs commandes d'installation contenant respectivement les descripteurs de ces différentes configurations de l'élément, lors du déploiement ci-après.
Puis à l'étape E10, le caractère synchrone ou asynchrone du déploiement est sélectionné. Si le déploiement synchrone est choisi, celui-ci est développé à 1 ' étape Eli . Le déploiement synchrone de l'état sélectionné T de l'application sélectionnée AP consiste principalement en la transmission de commandes séquentielles, les unes après les autres, par le pilote PI au portail PO pour d'abord installer tous les composants de l'état d'application sélectionné T qui sont dépendants d'installations d'autres éléments de l'état d'application T, pour paramétrer les composants installés respectivement en réponse à des acquittements des installations des composants transmis par le portail PO et en fonction de paramètres contenus dans les descripteurs dés composants, puis pour installer toutes les connexions de l'état d'application sélectionné T dépendantes chacune de deux composants installés respectifs respectivement en réponse chacune à des acquittements des paramétrages' des deux composants respectifs et en fonction des descripteurs des connexions, et des paramétrages de toutes les connexions respectivement en réponse à des acquittements des installations des connexions et en fonction de paramètres contenus dans les descripteurs des connexions .
Si le déploiement sélectionné est . asynchrone, celui-ci est développé à l'étape E12. Le déploiement asynchrone consiste essentiellement en la transmission de commandes en parallèle par le pilote PI au portail PO pour installer et paramétrer les différents éléments de l'état sélectionné T de l'application sélectionnée AP. Le . déploiement asynchrone commence naturellement par les installations d'éléments, tels que les composants de l'état d'application T, dont l'installation est indépendante d'autres installations et fonction des descripteurs des composants. Puis le pilote autorise sensiblement en parallèle, indépendamment de tout ordonnancement des éléments, des paramétrages des composants respectivement en réponse à des acquittements d'installation des ; composants et en fonction de paramètres contenus dans les descripteurs des composants, des installations des connexions de l'état d'application sélectionné T dépendantes chacune d'au moins une installation de deux composants respectifs respectivement en réponse chacune à 1 ' acquittement de paramétrage des deux composants respectifs et en fonction des descripteurs des connexions, et des paramétrages des connexions respectivement en réponse à des acquittements d'installation des connexions et en fonction de paramètres contenus dans les descripteurs des connexions .
Quel que soit le caractère du déploiement choisi, les descripteurs des éléments de l'état d'application sélectionné T dans les commandes comprennent des caractéristiques notamment de propriété qui ont été sélectionnées aux étapes précédentes E7 à E91. Ces caractéristiques concernant la dégradation, la pondération et des configurations d'élément ainsi que le caractère synchrone ou asynchrone du déploiement peuvent être sélectionnées totalement par l'usager ou sélectionnées par le pilote de déploiement PI éventuellement à 1 ' aide d'informations fournies par l'usager et/ou par le terminal d'accueil TE en fonction de caractéristiques du contexte transmises par le terminal TE à l'étape E3, ou peuvent être sélectionnées pour partie par l'usager et pour partie par le terminal TE.
En variante, s 'agissant du caractère synchrone ou. asynchrone, le pilote PI choisit par défaut le caractère synchrone pour que 1 'usager ou le terminal TE n'intervienne pas, en' forçant le déploiement à ce qu'il soit synchrone. Ce choix par défaut du déploiement synchrone permet de déployer 1 ' état d'application sélectionné sur tous les terminaux, y compris ceux ne disposant pas de moyen pour déclencher plusieurs commandes pendant le traitement de la commande courante.
Après le déploiement à l'étape Eli ou E12, l'état d'application sélectionné déployé T est exécuté à l'étape E13 à partir du terminal TE.

Claims

REVENDICATIONS
1 - Objet électronique portable du type carte à microcontrôleur (CP) , comprenant un moyen (DAP) pour décrire une application (AP) composée de plusieurs éléments distants répartis (IU, AGm, SEm) avec des descripteurs (DIU, DAGm, DSEm) des éléments, et un moyen (PI) pour déployer l'application à l'extérieur
(TE) de l'objet électronique en fonction des descripteurs d'éléments, caractérisé en ce que le moyen pour décrire (DAP) combine plusieurs états (Tl- T4) de l'application (AP) qui sont déployés sélectivement à l'extérieur de l'objet électronique sous la commande du moyen pour déployer (PI) , et qui comprennent chacun au moins un élément (IU ; AGm ; SBn) de l'application.
2 - Objet électronique portable conforme à la revendication 1, dans lequel l'un des états comprend les paramètres d'au moins un élément compris dans cet état .
3 - Objet électronique portable conforme à la revendication 1 ou 2, dans lequel le moyen (DAP) pour décrire l'application comprend le descripteur d'une interface d'usager (IU) , et/ou le descripteur d'au moins un élément (AGm) qualifiant au moins un processus, et/ou le descripteur d'au moins un serveur de données (SEn)-.
4 - Objet électronique portable conforme à la revendication.1 ou 2, dans lequel le moyen (DAP) pour décrire l'application (APC) ne comprend que les descripteurs des éléments suivants : une interface d'usager (IU) , plusieurs éléments (AGC1-AGCM) qualifiant chacun au moins un processus, et plusieurs serveurs de données (SC1-SCM) pouvant être connectés respectivement aux éléments qualifiants.
5 - Objet électronique portable conforme à la revendication 1 ou 2, dans lequel le moyen (DAP) pour décrire l'application (APJ) ne comprend que les descripteurs des éléments suivants : une interface d'usager (IU) , un élément (APJ) qualifiant au moins un processus, et plusieurs serveurs de données (SJ1- SJN) pouvant être connectés sélectivement à l'élément qualifiant.
6 - Objet électronique portable conforme à la revendication 1 ou 2, dans lequel le moyen (DAP) pour décrire l'application (APE) ne comprend que les descripteurs des éléments suivants : une interface d'usager (IU) , plusieurs éléments (AGEl-AGEM) qualifiant chacun au moins un processus, et un seul serveur de données (SE) pouvant être connecté sélectivement aux éléments qualifiants.
7 - Procédé pour configurer et déployer une application (AP) composée de plusieurs éléments distants répartis (IU, AGm, SEm) depuis un objet électronique portable (CP) conforme à l'une quelconque des revendications 1 à G contenant des descripteurs (DIU, DAGm, DSEm) des éléments, à travers un moyen de traitement de données (TE) relié à des moyens d'implantation des éléments (Bl) pour exécuter l'application configurée et déployée, caractérisé en qu'après une transmission (E3) de caractéristiques du contexte d'exécution de l'application depuis le moyen de traitement (TE) vers l'objet électronique portable (CP) , il comprend une sélection (E5) de l'un des états' (T) de l'application (AP) qui comprennent chacun au moins un élément (IU ; AGm ; SBn) de l'application.
8 - Procédé conforme à la revendication 7,. comprenant, avec la transmission de caractéristiques du contexte d'exécution de l'application, la transmission (E3) d'une clé (KAGC ; KAGV) associée à un élément (AGC ; AGV) de l'application, et le déploiement d'un état sélectionné de l'application comprenant 1 ' élément seulement en réponse à une détection préalable de la clé prédéterminée par l'objet électronique portable (CP) .
9 - Objet électronique portable conforme à la revendication 7, comprenant la transmission (E3) de clés prédéterminées (KAGC ; KAGV) associées respectivement à des éléments (AGC ; AGV) de l'application (APB), et la sélection (E4) d'un état (T) parmi des états de l'application comprenant au moins des connexions avec les éléments associées aux clés transmises.
10 - Procédé conforme à l'une quelconque des revendications 7 à 9, caractérisé en . ce qu'il comprend une sélection (E7 à E10) de l'un de plusieurs déploiements de 1 ' état sélectionné (T) de l'application (AP) .
11 - Procédé conforme à la revendication 10, selon lequel l'un des déploiements comporte l'installation d'au moins un élément (EL) de l'état d'application sélectionné (T) ayant au moins une propriété présentant une dégradation, sélectionnée préalablement (E71) . 12 - Procédé conforme à la revendication 10 ou 11, selon lequel l'un des déploiements comporte l'installation d'au moins un élément (EL) de l'état d'application sélectionné (T) ayant une propriété associée à un poids, sélectionnée préalablement (E81) .
13 - Procédé conforme à la revendication 12, selon lequel le poids est corrigé en fonction de critères de qualité prédéterminés sur au moins le déploiement précédent de l'état d'application sélectionné.
14 - Procédé conforme à 1 ' une quelconque des revendications 10 à 13, selon lequel l'un des déploiements comporte 1 ' installation de la première trouvée (E91) de plusieurs configurations sélectionnées préalablement d' au moins un élément (EL) de l'état d'application sélectionné (T) , les configurations d'élément ayant au moins une valeur de propriété différente.
15 - Procédé conforme à 1 ' une quelconque des revendications 11 à 14, selon lequel l'une de valeurs d'une propriété ou l'une de plusieurs propriétés dans le descripteur d'au moins un élément (EL) de l'état d'application sélectionné (T) est sélectionnée par un usager possesseur de l'objet électronique portable (CP) ou par l'objet électronique portable (CP) en fonction du contexte d'exécution de l'application
(AP) transmis par le moyen de traitement (TE) . 16 - Procédé conforme à l'une quelconque des revendications 10 à 15, selon lequel l'un des déploiements est asynchrone (E12) .
PCT/FR2001/003390 2000-11-06 2001-10-31 Carte a puce avec descripteur d'application WO2002037435A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP01983669A EP1337980A1 (fr) 2000-11-06 2001-10-31 Carte a puce avec descripteur d'application
AU2002215096A AU2002215096A1 (en) 2000-11-06 2001-10-31 Smart card with application descriptor

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0014364A FR2816429B1 (fr) 2000-11-06 2000-11-06 Carte a puce avec descripteur d'application
FR0014364 2000-11-06

Publications (1)

Publication Number Publication Date
WO2002037435A1 true WO2002037435A1 (fr) 2002-05-10

Family

ID=8856223

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2001/003390 WO2002037435A1 (fr) 2000-11-06 2001-10-31 Carte a puce avec descripteur d'application

Country Status (4)

Country Link
EP (1) EP1337980A1 (fr)
AU (1) AU2002215096A1 (fr)
FR (1) FR2816429B1 (fr)
WO (1) WO2002037435A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100343803C (zh) 2004-07-26 2007-10-17 国际商业机器公司 将个性化计算环境从源平台移植到目标平台的方法和系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0757336A1 (fr) * 1995-08-04 1997-02-05 Belle Gate Investment B.V. Systèmes d'échange de données comprenant des unités de traitement de données portatives
EP0949595A2 (fr) * 1998-03-30 1999-10-13 Citicorp Development Center, Inc. Méthode et système pour la gestion des applications pour une carte à puce multifonctionnelle

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0757336A1 (fr) * 1995-08-04 1997-02-05 Belle Gate Investment B.V. Systèmes d'échange de données comprenant des unités de traitement de données portatives
EP0949595A2 (fr) * 1998-03-30 1999-10-13 Citicorp Development Center, Inc. Méthode et système pour la gestion des applications pour une carte à puce multifonctionnelle

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
A THOMAS: "Enterprise JavaBeans Technology - Server Component Model for the Java Platform", PATRICIA SEYBOLD GROUP, December 1998 (1998-12-01), XP002160756 *
BIGET P ET AL: "How smart cards can benefit from object-oriented technologies", FUTURE GENERATIONS COMPUTER SYSTEMS,NL,ELSEVIER SCIENCE PUBLISHERS. AMSTERDAM, vol. 13, no. 1, 1 July 1997 (1997-07-01), pages 75 - 90, XP004081711, ISSN: 0167-739X *
RIVEILL M, PELLEGRINI M-C, POTONNIÉE O, MARVIE R: "Adaptabilité des applications pour des usagers mobiles", OCM 2000, 8 May 2000 (2000-05-08), Nantes, XP002173622, Retrieved from the Internet <URL:http://www.gemplus.com/smart/r_d/publications/art2.htm> [retrieved on 20010730] *
TROMMLER P, DI GIORGIO R S: "Smart cards and the OpenCard Framework", JAVA WORLD, January 1998 (1998-01-01), XP002173639, Retrieved from the Internet <URL:http://www.javaworld.com/javaworld/jw-01-1998/jw-01-javadev_p.htm> [retrieved on 20010731] *

Also Published As

Publication number Publication date
FR2816429B1 (fr) 2003-04-11
AU2002215096A1 (en) 2002-05-15
FR2816429A1 (fr) 2002-05-10
EP1337980A1 (fr) 2003-08-27

Similar Documents

Publication Publication Date Title
EP1044436B1 (fr) Procede de communication entre une station d&#39;utilisateur et un reseau, notamment du type internet, et architecture de mise en oeuvre
EP1395962B1 (fr) Deploiement d&#39;application depuis une carte a puce
FR2791159A1 (fr) Procede d&#39;acces a un objet a l&#39;aide d&#39;un navigateur de type &#34;web&#34; cooperant avec une carte a puce et architecture pour la mise en oeuvre du procede
CA2309293A1 (fr) Procede, carte a puce et terminaux pour effectuer des transactions a travers un reseau de telecommunication
WO2006053958A9 (fr) Support personnel de mémoire de masse portatif et système informatique d&#39;accès sécurisé a un espace utilisateur via un réseau
WO2002065414A1 (fr) Procede et systeme de telepaiement
EP1074007A1 (fr) Systeme embarque possedant des moyens d&#39;interface de reseau, et procede d&#39;activation d&#39;applications localisees dans ce systeme embarque
FR2817055A1 (fr) Execution d&#39;une application dans un objet electronique portable a faible capacite de memoire
WO2001065480A1 (fr) Procede de commande d&#39;une carte a puce
EP1551193A1 (fr) Procédé de personnalisation automatique d&#39;un terminal mobile en fonction du module d&#39;identification de l&#39;utilisateur et terminal mobile personnalisable
WO2002037435A1 (fr) Carte a puce avec descripteur d&#39;application
WO2007144509A2 (fr) Dispositif de memorisation amovible et appareil electronique aptes a l &#39; autre et procede de sauvegarde de donnees d &#39; environnement
EP1772000A2 (fr) Terminal et procede de communication
EP1337979B1 (fr) Deploiement d&#39;application depuis une carte a puce
WO2007080328A2 (fr) Procédé de génération d&#39;un profil pour la personnalisation d&#39;une entité électronique et système associé
FR2854261A1 (fr) Procede d&#39;execution d&#39;une application logicielle par l&#39;intermediaire d&#39;un programme d&#39;amorce logicielle et architecture informatique pour la mise en oeuvre du procede
WO2004056071A1 (fr) Procede de communication entre serveurs avec conversion de format des donnees et dispositif pour sa mise en oeuvre
WO2002008897A1 (fr) Protocole d&#39;echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant
EP1065866A1 (fr) Méthode et dispositif de contrôle d&#39;accès à des services disponibles depuis un terminal de télécommunications
EP1086561B1 (fr) Interfonctionnement entre des equipements par page d&#39;accueil hypertexte
WO2011131852A1 (fr) Système informatique de partage et procédé correspondant
EP0991032A1 (fr) Procédé d&#39;utilisation d&#39;une carte en mode prépayé
WO2003073273A1 (fr) Procede et dispositif de gestion decentralisee et personnalisee de services
WO2003069475A2 (fr) Programme complementaire api pour traitement de transaction dans un reseau modulaire
EP1358640A1 (fr) Procede pour la creation de fichiers de donnees, prives securises et carte a puce comportant un fichier prive securise

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2001983669

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2001983669

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

NENP Non-entry into the national phase

Ref country code: JP