FR2806188A1 - Dispositif a circuit integre comportant un programme applicatif - Google Patents

Abstract

L'invention concerne un dispositif à circuit intégré comprenant une mémoire et au moins un programme applicatif résident dans ladite mémoire. L'invention se caractérise en ce que ledit programme applicatif comprend une liste de pointeurs de commandes applicatives, une liste d'enchaînement de telles commandes, une classe associée à chaque commande et une liste de paramètres configurables associée à chaque classe, et, d'autre part, chaque classe comporte un moyen de paramétrage d'une commande et un moyen de recherche d'une commande suivante et de ses paramètres. L'invention s'applique, en particulier, aux cartes à puce.

Description

<B>DISPOSITIF A CIRCUIT</B> INTEGRE <B>COMPORTANT UN</B> PROGRAMME APPLICATIF La présente invention concerne un dispositif à circuit integré comprenant une mémoire et au moins un programme applicatif résident dans ladite mémoire, ledit programme utilisant au moins une commande applicative. Elle concerne également un procédé de gestion d'un programme applicatif d'un tel dispositif.

Lesdits dispositifs sont en particulier des objets portatifs tels que des cartes à puce comprenant des programmes applicatifs concernant le domaine de la santé, de la téléphonie mobile, ou encore, concernant le domaine bancaire.

Lesdites cartes à puce comportent généralement un corps de carte dans lequel est intégré un module électronique comprenant de manière classique un élément de commande (par exemple une unité centrale de traitement ou CPU) et une mémoire. Ladite mémoire comporte au moins un programme applicatif utilisant des commandes applieatives permettant un dialogue avec un terminal tel que, par exemple, téléphone portable dans le domaine de la téléphonie. Le programme applicatif peut être chargé au travers d'un réseau de communication dans carte, en particulier les programmes applicatifs codés langage orienté objets, par exemple en ,JAVA (marque déposée). Généralement, un programme applicatif est relatif à un service offert par fournisseur de carte à un client. Par exemple, le fournisseur est un opérateur de télécommunication et le client un utilisateur d'un téléphone portable dans lequel est insérée une carte à puce.

vue de créer de tels programmes applicatifs, l'état de la technique propose des dispositifs qui prévoient de limiter au maximum un emploi de composants objets (classes et instances) ainsi qu'une hiérarchisation de classes, de tels objets et une telle hiérarchisation occupant beaucoup de place en mémoire. taille du code du programme est ainsi réduite.

Bien que ces dispositifs permettent de diminuer la taille du code en mémoire, celle-ci reste un problème majeur les cartes à puce où la mémoire est très limitée. De plus, le temps de développement d'un programme applicatif reste élevé car les programmes applicatifs doivent être adaptés à chaque service spécifique offert par le fournisseur de carte à un client. Aussi, le code d'un programme applicatif est difficilement réutilisable pour un autre service. Enfin, si on effectue une modification mineure dans le programme applicatif, on doit automatiquement recharger complètement le programme dans les cartes, ce qui pose un problème lorsque les cartes sont déjà sur le terrain c'est-à-dire lorsqu'elles ont déjà été vendues aux clients.

Aussi un problème technique à résoudre par l'objet de la présente invention est de proposer un dispositif à circuit intégré comprenant une mémoire et au moins un programme applicatif résident dans ladite mémoire, ledit programme utilisant au moins une commande applicative, ainsi qu'un procédé de gestion programme applicatif d'un tel dispositif, qui permettraient, d'une part, de réduire sensiblement la taille du code d'un programme applicatif, d'autre part, de réduire le temps de développement programme applicatif en réutilisant une grande partie de code d'un autre programme applicatif, et, enfin, de pouvoir modifier un programme applicatif lorsque le dispositif est sur le terrain, sans pour autant recharger ledit programme dans ledit dispositif.

Une solution au problème technique posé se caractérise, selon un premier objet de la présente invention, en ce que, d'une part, ledit programme applicatif comprend une liste de pointeurs de commandes applicatives, une liste d'enchaînement de telles commandes, une classe associée à chaque commande et une liste de paramètres configurables associée à chaque classe, et, d'autre part, chaque classe comporte un moyen de paramétrage d'une commande et un moyen de recherche d'une commande suivante et de ses paramètres.

Selon un second objet de la présente invention, cette solution se caractérise en ce que le procédé de gestion comporte les etapes consistant à - créer, dans ledit programme applicatif, une liste de pointeurs commandes applicatives, une liste d'enchaînement de telles commandes et une classe associée à chaque commande applicative, - creer, dans ledit programme applicatif, une liste de paramètres configurables associée à chaque classe, - paramétrer une commande applicative, - executer ladite commande, - rechercher la commande suivante et ses paramètres.

Ainsi, comme on le verra en détail plus loin, le dispositif de l'invention permet, grâce aux listes de pointeurs et d'enchaînement de commandes, d'éviter de coder tout un enchaînement de commandes et ainsi de reduire la taille du code de façon considérable. De plus, on peut modifier directement dans des listes les paramètres l'enchaînement des commandes, sans pour autant modifier et recharger tout le programme applicatif. Enfin, les caractéristiques telles que l'enchaînement et les paramètres des commandes d'un service associé à un programme applicatif étant dans des listes et non pas dans une classe, une classe sera générique et pourra ainsi être réutilisée dans un autre programme applicatif qui réduira également le temps de développement.

La description qui va suivre au regard des dessins annexés, donnée à titre d'exemple non limitatif, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. La figure 1 est un schéma d'un dispositif à circuit intégré, ici une carte à puce, comportant un programme applicatif.

La figure 2 est un schéma du programme applicatif de la carte de figure 1.

La figure 3 représente une liste de pointeurs de commandes comprise dans le programme applicatif de la carte de la figure 1.

La figure 4 représente une liste d'enchaînement de commandes comprise dans le programme applicatif de la carte de la figure 1.

La figure S représente des listes de paramètres comprises dans le programme applicatif de la carte de la figure 1.

La figure 6 est un diagramme montrant une exécution d'un programme applicatif de la figure 1.

Le présent exposé de l'invention a trait à l'exemple des cartes à circuit intégré appelées également cartes à puce. Par carte à circuit intégré, on entend, par exemple, une carte au format ISO une carte au format jeton couramment appelé dans la langue anglaise format "plug- ", tel qu'un module d'identification abonné (SIM) encore une étiquette électronique.

Sur la figure 1 est représenté un dispositif 10 à circuit intégré, ici une carte à puce. Cette carte 10 comporte un élément 11 commande (par exemple une unité centrale de traitement ou CPU), mémoire 12 un bloc 13 de contacts destiné à une connexion électrique avec un terminal T, par exemple, un connecteur d'un lecteur de cartes. La mémoire 12 comprend un programme applicatif A. Préférentiellement, la mémoire 12 est non volatile réinscriptible.

La carte à puce est généralement fournit par un fournisseur de service à un client, comme par un exemple un opérateur gérant un reseau de télécommunication. Dans ce cas, le client est un utilisateur de la carte et possède un terminal appelé téléphone portable. La carte est insérée dans le téléphone portable. Préférentiellement, un programme applicatif A est associé à un ou plusieurs services offerts par le fournisseur. Par exemple, on a un service permettant à l'utilisateur d'envoyer des messages sur le réseau l'opérateur en entrant préalablement un mot de passe sur son téléphone.

Le programme A est représenté à la figure 2. Dans cet exemple, le programme utilise une commande applicative génerique d'entrée de texte GETINPUT et une commande applicative générique d'envoi de messages SENDSMS. Avantageusement, à chaque commande applicative genérique est associée une classe. Ainsi, une première et deuxième classes GETINPUTPAGE, SENDSMSPAGE sont respectivement associées à chacune des commandes applicatives génériques l'exemple. De plus, préférentiellement, à chaque commande applicative générique est associée une ou plusieurs commandes applicatives spécifiques. Une commande applicative générique comporte préférentiellement un ensemble de paramètres communs à toutes les commandes spécifiques associées tandis qu'une commande applicative spécifique comporte des paramètres qui lui sont propres.

Le programme A comporte en outre - une liste de pointeurs de commandes génériques L PTRPAGES, - une liste d'enchainement de commandes L NEXTPAGES, et, - une liste de paramètres configurables associée à chaque classe, soient, dans l'exemple, une première liste de paramètres d'entrée de texte L GETINPUT et seconde liste de paramètres d'envoi de message L SENDSMS.

La liste d'enchainement de commandes L_NEXTPAGES comporte au moins une référence relative à la liste de pointeurs commandes L PTRPAGES et au moins référence relative à une liste de paramètres configurables. Chaque classe comporte un moyen de paramétrage de commandes, ici une commande opérationnelle paramétrage BUILDCMD, un moyen de recherche d'une commande suivante et de ses paramètres, ici, une commande opérationnelle de recherche PROCESSRESP et un moyen de construction commande CONSTRUCTOR appelée également constructeur de la classe dans le langage orienté objet. En outre, préférentiellement, une classe peut comporter un paramètre d'emplacement OFFSETNEXTPAGES permettant de situer l'emplacement de l'enchaînement d'une commande dans la liste d'enchaînement L NEXTPAGES. Le moyen de construction de commande CONSTRUCTOR permet d'affecter une valeur audit parametre OFFSETNEXTPAGES. Chaque constructeur est appelé lors du chargement du programme applicatif A dans la carte à puce 10. Un constructeur permet de créer une instance de classe c'est-à-dire crée un objet type de la classe associée.

Afin que le programme A puisse s'exécuter, faut créer au préalable les listes et classes décrites ci-dessus.

Dans une première étape, on crée, dans ledit programme applicatif A, la liste de pointeurs de commandes applicatives L PTRPAGES, la liste d'enchaînement de telles commandes L NEXTPAGES, et les classes GETINPUTPAGE, SENDSMSPAGE associées respectivement aux commandes génériques d'entrée de texte et d'envoi de message.

Comme le montre la figure 3, la liste de pointeurs L PTRPAGES comporte préférentiellement un premier pointeur d'index PTR 1 non adressé, un deuxième pointeur d'index PTR2 pointant une instance de la première classe GETINPUTPAGE et un troisième pointeur d'index PTR3 pointant sur instance de la deuxième classe SENDSMSPAGE. La liste ne comporte pas obligatoirement un pointeur pour une unique instance de classe mais peut également comporter des pointeurs pour plusieurs instances d'une même classe.

Dans une deuxième étape, on crée, dans ledit programme applicatif A, les listes de paramètres configurables L_GETINPUT et L SENDSMS associées à chaque classe ou commande générique.

Dans une troisième étape, on construit un lien entre la liste d'enchaînement de commandes L NEXTPAGES et les commandes applicatives.

cet effet, on crée dans chaque classe le moyen de recherche PROCESSRESP, ledit moyen utilisant la liste d'enchainement L NEXTPAGES.

liste d'enchaînement des commandes L NEXTPAGES comporte les enchaînements des commandes relatifs aux services proposés par l'opérateur de télécommunications à son client, soit dans notre exemple d'envoi message, l'enchaînement suivant - entrée d'un mot de passe, utilisant une première commande spécifique d'entrée de texte GETINPUT 1, - entrée du texte du message à envoyer, utilisant une deuxième commande spécifique d'entrée de texte GETINPUT2, envoi du message sur le réseau, utilisant une commande d'envoi de message SENDSMS 1.

cette fin, avantageusement, la liste d'enchainement L NEXTPAGES comporte pour chaque commande spécifique impliquant une commande suivante OK, - une référence PTR OK de commande suivante à exécuter dans la liste des pointeurs de commandes L PTRPAGES , et, - une référence OFFSET OK relative à la liste des paramètres associée à la commande suivante référencée. Avantageusement, ladite liste comporte également pour chaque commande spécifique impliquant une commande de retour BACK, - une référence PTR BACK de commande de retour à exécuter dans la liste des pointeurs de commandes L_PTRPAGES, et, - une référence OFFSET BACK relative à la liste des paramètres associée à la commande de retour référencée.

Dans le cas où il n'y a aucune commande de retour ou suivante, préférentiellement, les références PTR BACK et PTR_OK ne sont pas adressées, le premier pointeur d'index PTR1 leur est affecté et les références OFFSET BACK ou OFFSET OK ont une valeur zéro. Préférentiellement, une référence est sur un octet.

Ainsi, dans notre exemple, on aura, comme le montre la figure 4, les références suivantes avec leur valeur 1) pour première commande spécifique d'entrée de texte GETINPUT 1, OK = GETINPUT2 - OK = PTR2 - OFFSET OK = 02 BACK = - BACK = PTR 1 - OFFSET BACK = 00 2) pour deuxième commande spécifique d'entrée de texte GETINPUT2, OK = SENDSMS 1 - = PTR3 - OFFSET OK =<B>0 1</B> BACK = GETINPUT1 - BACK = PTR2 - OFFSET BACK =<B>0 1</B> La commande d'envoi de message SENDSMS 1 ne se trouve pas dans la liste L NEXTPAGES, car elle n'implique aucune commande suivante ou aucune commande de retour. Aussi, on comprend que la classe associée SENDSMSPAGE ne comporte pas de paramètre d'emplacement OFFSETNEXTPAGES.

Par la suite, avantageusement selon le paramètre d'emplacement OFFSETNEXTPAGES et la valeur de référence OFFSET de la liste de paramètres, grâce à la commande opérationnelle de recherche PROCESSRESP, on se positionne sur la commande applicative appropriée et sur ses paramètres dans la liste de paramètres associée. Par exemple<B>:</B> on a Dans une quatrième étape, on construit un lien entre les listes de paramètres configurables et les commandes applicatives associées.

A cet effet, on crée dans chaque classe le moyen de paramétrage BUILDCMD, ledit moyen utilisant une liste de parametres associée. Ainsi, le moyen de paramétrage BUILDCMD de 1a première classe GETINPUTPAGE utilise la liste de paramètres d'entrée de texte L GETINPUT, tandis que le moyen de paramétrage BUILDCMD de la deuxième classe SENDSMSPAGE utilise la liste de paramètres d'envoi de message L SENDSMS.

Préférentiellement, à chaque commande spécifique associé un groupe de paramètres dans la liste de paramètres de la classe associée de la commande générique associée.

Ainsi, dans l'exemple de la figure 5, la liste de parametres d'entrée texte L GETINPUT comporte deux groupes de paramètres G1, G2 correspondant respectivement aux deux commandes spécifiques d'entrée de texte GETINPUT1, GETINPUT2. Chaque groupe comporte, quatres paramètres MIN, MAX, TYPE, RFU avec les valeurs codées sur octet. Le premier et deuxième paramètres MIN, MAX représentent la longueur minimum et maximum du texte à entrer, le troisième paramètre TYPE, le type de texte entré, par exemple, texte en caractères ASCII et le quatrième paramètre RFU est réservé pour une utilisation future. Ainsi le mot de passe entré doit avoir une longueur de quatre caractères, tandis que le message à envoyer doit avoir une longueur minimum de caractère et maximum de cent soixante dix caractères.

De même, selon un mode de réalisation non limitatif, la liste d'envoi de message L_SENDSMS comporte un unique groupe de paramètres comportant un unique paramètre TAB d'indication de numéro de tableau dans lequel on récupère l'ensemble des paramètres de la commande spécifique d'envoi de message SENDSMS 1. Le tableau est le premier. On aurait très bien pu imaginer mettre l'ensemble des paramètres de ladite commande spécifique d'envoi de message dans la liste L_SENDSMS ou encore mettre l'ensemble des paramètres de plusieurs commandes spécifiques dans un unique tableau et référencer les différents groupes de paramètres dans la liste L SENDSMS au moyen d'une reférence de recherche associé à chaque groupe.

Lorsque l'utilisateur envoie un message au moyen de son téléphone portable, le programme applicatif s'exécute. Comme montré à la figure 6, l'execution commence par la première commande d'entree de texte GETINPUT1. Le paramètre d'emplacement OFFSETNEXTPAGES a été préalablement initialisé, ici à zéro.

Par la suite, on paramètre la commande au moyen la commande opérationnelle de paramétrage BUILDCMD de la première classe GETINPUTPAGE. On utilise la liste de paramètres L GETINPUT et on récupère les paramètres selon la référence OFFSET-OK initialisée préalablement à la valeur O1.

Le calcul effectué est alors le suivant: 4*(OFFSET_OK - 1) pour récupérer le premier paramètre, 4*(OFFSET-OK - 1)+1 pour le deuxieme paramètre etc....

La commande est envoyée au terminal T et exécutée. Un message s'affiche sur le terminal T incitant l'utilisateur a entrer son mot de passe. L'utilisateur entre son mot de passe 1234 et appuie sur une touche BOK de son téléphone. Le terminal envoie réponse à la carte 10 ainsi que le mot de passe de l'utilisateur, la réponse correspondant à un résultat d'exécution de la commande. Préférentiellement, la réponse est codee sur un octet. Ici, la réponse a une valeur zero. Dans un autre exemple, si l'utilisateur appuie sur la touche BBACK, la réponse a une valeur hexadécimale 11 etc...

recherche la commande suivante et ses paramètres au moyen de la commande opérationnelle de recherche PROCESSRESP de la première classe GETINPUTPAGE. Cette commande utilise la liste d'enchaînement L NEXTPAGES. Grâce également au paramètre d'emplacement OFFSETNEXTPAGES, on recherche l'enchaînement d'une commande applicative spécifique, ici de la première commande applicative spécifique GETINPUT 1, dans la liste d'enchaînement L NEXTPAGES.

Le calcul effectué est alors le suivant: OFFSETNEXTPAGES + 4*(OFFSET OK - 1) + 2 pour la commande suivante, sinon OFFSETNEXTPAGES + 4*(OFFSET_BACK -1) pour la commande de retour.

commande suivante est la deuxième commande spécifique d'entrée de texte GETINPUT2 et la référence OFFSET OK de la liste de paramètres associée est 02. On se positionne sur la liste de paramètres associée L GETINPUT selon la référence OFFSET OK. La commande pointée par le deuxième pointeur d'index PTR2 appelée. On se positionne ainsi sur la bonne commande générique de la classe associée GETINPUTPAGE.

On prépare et on paramètre la deuxième commande spécifique GETINPUT2 au moyen de la commande opérationnelle de paramétrage BUILDCMD de la classe associée. On récupère ainsi les paramètres dans la liste associée L GETINPUT selon la référence OFFSET OK de valeur 02. On envoie la deuxième commande GETINPUT2 au terminal T. Elle est exécutée. Un message s'affiche sur le terminal T incitant l'utilisateur a entrer le message qu'il veut envoyer. L'utilisateur entre le texte de son message MSG et appuie sur le bouton On recherche la commande suivante et ses paramètres dans la liste d'enchaînement L NEXTPAGES.

La commande suivante est la commande specifïque d'envoi de message SENDSMS 1 et la référence OFFSET de la liste de paramètres associée a pour valeur<B>01.</B> On se positionne sur la liste de paramètres associée L SENDSMS selon cette référence OFFSET-OK. La commande pointée par le deuxième pointeur d'index est appelée. On se positionne ainsi sur la bonne commande générique de la classe associée SENDSMSPAGE.

prépare et on paramètre la commande spécifique SENDSMS 1 au moyen de la commande opérationnelle de parametrage BUILDCMD de la classe associée. On récupère ainsi les paramètres dans la liste associée L SENDSMS selon la référence OFFSET de valeur<B>0 1</B> et par suite dans un premier tableau TAB. On envoie la commande spécifique SENDSMS 1 au terminal T. Elle est exécutée. L'exécution a pour conséquence l'envoi du message sur réseau de télécommunication.

Comme nous l'avons vu précédemment, préférentiellement, un programme applicatif A est associé à un ou plusieurs services offerts par le fournisseur. A cette fin, l'utilisateur peut sélectionner un service parmi plusieurs au moyen d'un menu de son téléphone portable. Par exemple, l'utilisateur a le choix entre le premier service d'envoi de message décrit précédemment et un service d'envoi direct d'un message préprogrammé dans la carte 10.

La sélection est exécutée grâce à une commande applicative de sélection SELECTITEM générique. Par suite, on crée classe associée SELECTITEMPAGE comprenant un moyen de paramétrage BUILDCMD et un moyen de recherche de commande PROCESSRESP. Dans ce cas, le moyen de recherche PROCESSRESP est semblable à ceux vus précédemment. La commande de sélection étant générique, le moyen de paramétrage comporte uniquement un moyen de préparation des paramètres dans un buffer utilisé par la suite lors l'exécution de la commande la classe de la commande de sélection comporte pas de liste de paramétrages. On notera que ce moyen de préparation est compris dans chaque classe et préférentiellement dans chaque moyen de paramétrage BUILDCMD.

La liste d'enchaînement L NEXTPAGES comprend les références suivantes avec leur valeur Pour commande spécifique de sélection SELECTITEM 1, BACK - 00 - PTR BACK = PTR I - OFFSET BACK = 00 SERVI = GETINPUT I - OK = PTR2 - OFFSET OK = Ol SERV2 = SENDSMS2 - OK = PTR3 - OFFSET OK = 02 Dans notre exemple, lesdites références sont incluses en premier dans la liste avant les références des autres classes.

Ainsi, si l'utilisateur choisit le premier service SERVI, la commande à exécuter est la première commande d'entrée de texte GETINPUT 1 et ainsi de suite comme vu précédemment. Si l'utilisateur choisit le deuxième service SERV2, la commande à exécuter est une deuxième commande d'envoi de message SENDSMS2 dont les paramètres sont, par exemple, récupérés dans un deuxième tableau TAB. Bien entendu, la liste des paramètres L_SENDSMS aura été mise à jour en conséquence avec un deuxième groupe G2. Si l'utilisateur appuie sur une touche de retour BBACK, il sort de son programme applicatif.

Quand un utilisateur choisit un service, le Terminal envoie une réponse comprenant un numéro de service associé, à la carte 10. Ainsi, le premier service SERV1 a le numéro associé O1, et le deuxième service SERV2 a le numéro associé 02. Le numéro associé au service du bouton BBACK est 0.

calcul effectué dans la commande de recherche PROCESSRESP est alors le suivant: OFFSETNEXTPAGES + 2*(numéro de service) pour la commande suivante, sinon OFFSETNEXTPAGES pour commande de retour, avec le paramètre d'emplacement OFFSETNEXTPAGES à zéro.

Tandis que pour les commandes d'entrée de texte et d'envoi de message, le calcul est Le calcul effectué est alors le suivant OFFSETNEXTPAGES + 4*(OFFSET OK - 1) + 2 pour la commande suivante, sinon OFFSETNEXTPAGES + 4*(OFFSET_BACK -1) pour la commande de retour, avec le paramètre d'emplacement OFFSETNEXTPAGES a une valeur de six.

Ainsi, on comprend que l'objet de l'invention a pour avantage une réduction considérable de la taille du code grâce aux listes ci-dessus, une séparation nette entre des éléments génériques et des éléments plus spécifiques à un service. Cette séparation permet une réutilisation plus facile des éléments génériques tels que les classes dans d'autres programmes applicatifs et par suite un temps de développement plus court. plus, si on veut modifier un ou plusieurs services, on fera facilement même lorsque les cartes sont sur le terrain, au moyen de modifications sur les listes. Les modifications sont faîtes par exemple au moyen d'un téléchargement de données par un réseau hertzien de télécommunications en utilisant une technique connue de messages courts. Enfin, grâce à l'objet de l'invention decrite ci-dessus, on peut gérer différents cas de réponse du terminal T envoyée à la carte 10, les réponses correspondant à différents résultats d'exécution d'une commande. Dans les exemples ci-dessus, on gere deux cas de réponse, lorsque l'utilisateur appuie sur la touche BOK ou sur la touche BBACK de son téléphone portable. On peut gérer également des réponses dues à des erreurs telles que une non exécution de commande, une absence de réponse de la part de l'utilisateur.... A ce moment, selon ce qui précède on aura à chaque réponse du terminal à traiter, une commande suivante associée dans la liste d'enchaînement L NEXTPAGES. Ainsi, on comprend que dans chaque classe, on n'aura plus le codage induit par une gestion des différentes erreurs, ce qui réduira d'autant le code.

Claims (3)

1 - Procédé de gestion de commandes dans une mémoire d'un dispositif à circuit intégré, caractérisé en que chaque commande recherche automatiquement une commande suivante à partir d'un paramètre d'emplacement commandes (OFFSETNEXTPAGES) dans une liste d'enchaînement de commandes (L NEXTPAGES), ladite liste d'enchaînement comportant une référence dans une liste pointeurs de commandes (L PTRPAGES), ladite référence définissant une commande suivante, et une autre référence dans une liste de paramètres de commandes, ladite référence définissant les paramètres de la commande suivante, ledit procédé permettant de gagner de la place dans ladite mémoire.

2 - Procédé selon la revendication 1, caractérisé en ce que le dispositif à circuit intégré est une carte à puce.

3 - Dispositif à circuit intégré comprenant une mémoire et au moins un programme applicatif (A) résident dans ladite mémoire, ledit programme utilisant au moins une commande, caractérisé en ce que ledit programme applicatif (A) comprend une liste d'enchaînement de commandes (L_NEXTPAGES), ladite liste d'enchaînement de commandes (L NEXTPAGES) comportant une référence dans une liste de pointeurs de commandes (L_PTRPAGES), ladite référence définissant une commande suivante, et une autre référence dans une liste de paramètres configurables, ladite référence définissant les paramètres de la commande suivante, ledit dispositif permettant de gagner de la place dans ladite mémoire. <B>4</B> - Dispositif selon la revendication 3, caractérisé en ce qu'une classe est associée à chaque commande. 5 - Dispositif selon la revendication 4, caractérisé en ce qu'une liste de paramètres configurables est associée à chaque classe. <B>6</B> - Dispositif selon la revendication 4, caractérisé en ce que chaque classe comporte un moyen de recherche d'une commande suivante (PROCESSRESP) et moyen de paramétrage d'une commande (BUILDCMD). <B>?</B> - Dispositif selon la revendication 4, caractérisé en ce qu'une classe est apte à comporter un paramètre d'emplacement (OFFSETNEXTPAGES) de commandes dans la liste d'enchainement (L_NEXTPAGES) commandes. <B>8</B> - Dispositif selon la revendication 1, caractérisé en ce que le dispositif à circuit intégré est une carte à puce.