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

Abstract

La carte à puce (CP) comprend un descripteur (DAP) d'une application (AP) composée de plusieurs éléments distants 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 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.

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

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, 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 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 à 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 AP1 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 AP1 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 Il, A1 et S1 et au moins deux connexions CIA1 et CASi interconnectant deux à deux les composants Il et A1 et les composants

A1 et Si.

Par exemple, le premier composant Il 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 Ai, 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 S1 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 Il est localisé dans le terminal d'accueil TE, tandis que les deux autres composants A1 et Si sont localisés dans des sites différents. Seuls les deux premiers composants Il et A1 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 l'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 les 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 DI1, DCIA1, DA1, DCAS1, DS1 de l'élément Il, CIA1, Ai, 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 à l'application ou à un type d'application, comme la propriété "numéro de compte" associée à un composant, agent de consultation ou serveur 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

6 2816429

(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 l'applet est associé un client, appelé pilote de déploiement PIl (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 l'interroge avant de mettre à sa

disposition l'ensemble des méthodes de l'applet.

Lorsque l'usager a sélectionné une application AP1, 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 AP1 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 à partir du descripteur DAP1 de l'application sélectionnée AP1 afin qu'un dialogue soit établi entre le pilote de déploiement PIl 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 l'é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 implémenté 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 AP1 assignée à une première banque B1, 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 I2, d'un agent de consultation bancaire A2, d'un serveur bancaire S2 et de connexions CIA2 et CAS2 entre les composants I2 et A2, et A2 et S2. Même si les deux applications de service bancaire AP1 et AP2 ont leurs descripteurs mémorisés dans une carte à puce multi-applications commune, les applications AP1 et AP2 sont complètement séparées et indépendantes, bien que les agents de consultation A1 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 S1 et S2. Il en est de

même relativement aux interfaces d'usager I1 et I2.

En pratique, l'usager ne peut pas effectuer des

opérations dépendant de ces deux comptes bancaires.

Par exemple, si les agents A1 et A2 sont des agents de virement, un virement du compte bancaire géré par le premier serveur S1 vers le compte bancaire géré par le deuxième serveur S2 est impossible par l'un ou

l'autre des agents A1 et A2.

En outre, le déploiement d'une application AP1 est total. En d'autres termes, tous les composants AP1, A1 et S1 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 B1, les composants de l'application AP1, 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 l'intervention du composant serveur S1.

Pour cette lecture, l'application de consultation bancaire AP1 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 application composée de plusieurs éléments distants répartis depuis un objet électronique portable conforme à l'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 depuis 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 ou 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 l'é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 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 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 l'application ayant une propriété associée à un poids, sélectionnée préalablement, ou bien 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 propriété ou l'une de plusieurs propriétés dans le descripteur d'au moins un élément de l'é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 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

lecture de la description suivante de plusieurs

réalisations préférées de l'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 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 l'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 AG1 à AGM et des serveurs de données SE1 à 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 AG1 à AGM et des connexions CAS11-CASlN à CASM1-CASMN respectivement entre chacun des agents AG1 à AGM et les serveurs SE1

à 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 carte à puce comprend au moins le descripteur DAP de l'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

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 recherche MR et au moins une bibliothèque d'éléments d'application BI, comme cela a déjà été décrit en référence à la figure 2. L'interface d'usager constitue essentiellement l'interface homme-machine qui est paramétrée par l'usager notamment au niveau 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, comme le verra dans la suite. Inversement, des commandes à traiter par un agent de l'é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 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 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 SE1 à 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 de l'application dépendant essentiellement de caractéristiques du terminal 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 l'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 l'é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 l'agent AGm traite des données de l'un ou de plusieurs des serveurs SE1 à 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 AG1 à 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 l'agent AGmrelié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 l'agencement de l'interface IU, de tous les agents AG1 à 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 AG1 à AGM pouvant être reliés chacun à l'interface d'usager IU et/ou à un ou plusieurs

serveurs respectifs SE1 à 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 inter-

compte. 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 SB1 à SBN contenant les données des divers comptes que l'usager

a ouverts dans N banques.

Dans l'un de premiers états Ti 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 SB1 à 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 SB1 à 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, l'agent de virement bancaire AGV est intermédiaire entre l'interface d'usager IU et l'un ou plusieurs des serveurs de banque SB1 à 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 pen et 1 < p < N.

Comme déjà dit, les descriptions des états de

l'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 l'application de service bancaire APB.

A la figure 5A, l'état T3 concerne la connexion entre l'interface d'usager IU et l'agent de o 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 SB1 à 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 l'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 l'agent AGC vers les serveurs SB1 à 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

SB1 à 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 l'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 l'intermédiaire de l'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 + Mn; - au contraire, pour régler des dépenses débitées sur le compte cheque 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 l'agent de virement bancaire AGV ne peut être effectuée que sur une plateforme d!exécution, en l'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'interface 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 AGC1, AGCm et AGCM n'est connecté qu'à

un serveur de données respectif SC1, 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 AGC1 à 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 AGC1 à AGCM afin d'effectuer des virements automatiques de l'un vers l'autre des comptes dont les données sont incluses

dans les serveurs SCl à 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 AGC1 à AGCM qualifiant chacun au moins un processus, et plusieurs serveurs de données SCl à 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 SJi à SJN.

L'application APJ est par exemple relative à un jeu commun à N joueurs J1 à JN, y compris le joueur, par exemple J1, possesseur de la carte puce CP et déployant l'application de jeu APJ sur le terminal

TE. Par exemple l'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 J1 à 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 l'invention montrée à la figure 8 concerne une application APE dont l'état global comprend M agents AGE1 à AGEM pouvant être connectés chacun à l'interface 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 AGE1 à AGEM filtrent les messages chacun selon des

conditions prédéterminées.

Par exemple, l'agent AGE1 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 AGE1 et AGEm afin de ne filtrer que les messages provenant d'expéditeurs non répertoriés dans ces deux annuaires et signaler à l'interface 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 AGE1 à 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 E1 à 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éléphonique 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, à l'é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 l'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 TE, 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 l'é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 l'é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 de sélection d'application et d'état d'application et de paramétrage des composants de l'état sélectionné E1 à 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 à El0. 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 l'état sélectionné de l'application sélectionnée AP est sélectionnée par l'usager possesseur de la carte a 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 une perte de qualité ou de performance du résultat attendu produit par le composant ou la connexion. Cette dégradation est introduite lors de l'installation de l'élément au cours de l'é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 la virgule, le pilote PI émet un message d'erreur qui stoppe le déploiement de l'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 l'é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 de 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 chiffres 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é à l'étape Ell. 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 des 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 à l'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 à l'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 l'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 l'é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 Ell ou E12, l'état d'application sélectionné déployé T est

exécuté à l'étape E13 à partir du terminal TE.

Claims (11)

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 (T1-

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 (SCl-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 (AGE1-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 à 6 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 (BI) 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 l'é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 - Procédé 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.

- 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 l'é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 à l'une quelconque des

revendications 10 à 13, selon lequel l'un des

déploiements comporte l'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.

- Procédé conforme à l'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).