Plus particulièrement, l'invention est adaptée aux programmes applicatifs (ou appelés plus simplement « applications ») destinés à des appareils reliés en ligne à une source distante, tels que des terminaux de téléphonie mobile de deuxième ou troisième génération dans le cadre d'une transaction. Une première caractéristique de ces appareils est le faible espace mémoire et la faible puissance de calcul qu'ils possèdent. Une deuxième caractéristique est qu'ils possèdent un moyen de communication pour des données numériques. Par soucis de clarté, nous exposerons l'invention par la suite dans le contexte de la téléphonie mobile, de manière non limitative.

Actuellement, les programmes applicatifs de ces appareils sont principalement stockés dans leur carte à puce SIM (acronyme anglais de"subscriber identity module") et se divisent en deux catégories : les programmes statiques, qui résident en entier dans la carte et sont exécutés localement, et les programmes dynamiques, qui prévoit une interaction avec un serveur distant.

Dans le premier cas, le programme applicatif est entièrement stocké sur la carte. Son exécution se déroule localement et de manière autonome. Cette solution présente des limites évidentes du fait du manque de possibilité de prendre en compte des données qui changent avec le temps. De plus, la mise à jour des

données du programme et/ou du programme lui-mme est compliquée.

Pour résoudre le problème précédent, des applications dynamiques, qui se composent de deux parties, sont utilisées : la première partie, dite statique se trouve stockée sur la carte, et la deuxième partie, dite dynamique, sur un serveur distant. Cette deuxième partie peut avantageusement traiter les données numériques évolutives, dont la valeur change régulièrement en fonction du temps ainsi que des parties de programme représentant des options rarement utilisées. L'exécution d'un tel programme sur la carte fait appel en temps réel à la partie dynamique quand nécessaire. Il y a alors téléchargement à distance de la partie dynamique demandée, par l'intermédiaire de messages au format SMS, acronyme de l'expression anglaise « Short Message Service ». L'ensemble est construit selon la technique de navigation, à l'instar des pages Web sur Internet, et en utilisant un langage de type XML. Chaque page statique du programme applicatif représente un fichier de la carte à puce et chaque page dynamique est téléchargée par SMS quand nécessaire. L'optimisation d'une telle application consiste à trouver le compromis entre les pages statiques et les pages dynamiques. Un grand nombre de pages statiques présente l'inconvénient d'exiger un important espace mémoire localement. Un grand nombre de pages dynamiques présente l'inconvénient d'entraîner une lenteur et une lourdeur d'exécution par la nécessité de nombreux échanges de SMS, chacun étant limité en taille à 140 octets nets, et aussi de provoquer des erreurs dues à des mauvaises réceptions de message. Dans la pratique, le fournisseur du service et l'opérateur de communication décident à l'avance du compromis pour chaque service et prévoient le nombre de

fichiers nécessaires sur les cartes pour accueillir les pages statiques. Comme la marge en espace mémoire sur de telles cartes est en général nulle, l'utilisateur nta pas beaucoup de possibilité ultérieure pour modifier ce choix initial. De plus, lorsque ce dernier souhaite des données dynamiques, il doit télécharger au minimum une page Web, mme s'il n'est pas intéressé par la page entière. Cette gestion du service est centralisée et présente des inconvénients pour son utilisateur.

L'objet de l'invention est de proposer une solution qui ne présente pas ces inconvénients tout en gardant les avantages des applications dynamiques.

Pour cela, l'invention prévoit un programme applicatif formé de modules de commande, chaque module de commande représentant une commande élémentaire de haut niveau, pouvant tre identifié par un identifiant propre, contenant éventuellement un identifiant du fournisseur de service correspondant, ainsi qu'un identifiant de sa fonction.

D'autre part, l'invention concerne un procédé d'exécution dynamique d'un tel programme applicatif comprenant une première étape d'exécution de modules de commande stockés sur le terminal de manière autonome et une deuxième étape de téléchargement de modules de commande provenant d'une entité distante. Ce téléchargement peut tre fait sur requte du terminal en fonction de l'exécution d'une commande par un module de commande précédent.

Ce procédé pourra tre mis en oeuvre à l'aide d'un support électronique de type carte à puce, téléphone portable,... Le téléchargement pourra se faire à l'aide de messages SMS vers la carte SIM d'un téléphone portable.

L'invention et les avantages qui en découlent apparaîtront plus clairement à la lecture de la description qui suit d'un mode de réalisation, donné purement à titre d'exemple non-limitatif par référence aux dessins annexés, dans lesquels : - la figure 1 est un schéma qui illustre une application des modules de commande conformes à l'invention pour produire des fonctionnalités au niveau d'une carte à puce SIM ; et - la figure 2 est un schéma illustrant le déroulement d'un dialogue entre un utilisateur et un fournisseur de contenu par modules de commande conformes à l'invention.

Le mode de réalisation met en oeuvre un programme applicatif d'un terminal de téléphonie mobile qui est décomposé en modules fonctionnels autonomes, dits modules de commande, chacun produisant une action de haut niveau spécifique sur le terminal. Ces modules sont assemblés et enchaînés de manière modulaire pour constituer un programme exécutable complet. La nature autonome des modules fait qu'un tel programme applicatif peut tre constitué en appelant sélectivement le ou les modules choisis par un utilisateur. Notre invention permet ainsi à un utilisateur de personnaliser un service et représente une gestion de service selon une approche décentralisée. Ces points seront mieux compris par la description qui suit.

Tous les modules de commande ont un format commun composé de : - un champ d'identification (ID) (un octet) qui identifie le module de manière unique, - un champ d'identification du fournisseur de contenu (un octet) qui assure qu'un fournisseur de

contenu ne peut avoir accès à une application d'un autre fournisseur, - une identification du type du module (un octet) qui indique la fonction du module de commande, - un paramétrage pour un type de module spécifié ; il s'agit de définir une liste de données requises pour mettre en oeuvre un certain type de module de commande.

Par exemple, pour effectuer un affichage sur un écran, il faut le contenu du texte à afficher et le DCS, acronyme de « Data coding scheme", défini par la norme GSM 03.38, et - un champ d'identification du module suivant (un octet), qui comprend le champ d'identification du prochain module de commande à traiter.

Chaque module de commande possède un type qui correspond à une ou à une séquence d'action (s) prédéfinie (s), permettant de définir le flux de commandes d'une application. Il constitue ainsi une entité exécutable autonome.

Le mode de réalisation prévoit notamment un module de commande respectif pour chacune des actions suivantes : - sélection d'un élément (Select Item), - extraction d'une entrée (Get Input), - affichage de texte (Display Text), - établissement d'un appel (Setup Call), - liaison de modules (Link CP), - insertion de chaîne dans une pile mémoire (Push String), - lecture LOCI, acronyme de « Location Information", défini dans la norme GSM 11.11 (Read LOCI), - concaténation vers mémoire vive, - chiffrement à partir de mémoire vive, - affichage à partir de mémoire vive,

- émission de message SMS (acronyme anglais de "short message service") depuis module de commande, - émission de message SMS depuis mémoire vive, - émission de message SMS (numéro de destinataire dans le module de commande), - émission de message SMS (numéro de destinataire dans mémoire vive), - profil utilisateur, - effacement du module de commande (Delete), - répartition (dispatcher), - envoi tonalité (PlayTone), - formatage et échange de demi-octet (nibble), - extraction, et - vérification de plage de valeurs, - vérification de plage de longueur.

Il s'agit donc bien de commandes élémentaires de haut niveau. Pour détailler un exemple particulier, une commande « GET INPUT » pourra tre de la forme : Qualifier=OxO4, Min=5, Max=15 « What is your name ? ».

L'invention combine le mode dynamique de l'art antérieur et la structure modulaire de l'invention. On conserve ainsi l'avantage d'avoir un programme applicatif qui peut bénéficier de données à jour, accessibles sur un serveur distant. Pour cela, on utilise des échanges de messages au format SMS ; la longueur d'un module de commande est telle que chaque SMS peut contenir plusieurs modules. Pour optimiser encore cette gestion des échanges de message et remplir au maximum l'espace disponible par SMS, on peut aussi prévoir le découpage d'un module en deux morceaux, chacun se trouvant sur deux SMS distincts. L'invention permet d'optimiser la taille de l'ensemble des données à transférer et par conséquent le nombre de SMS

nécessaires, ce qui résout le problème de la lourdeur du traitement dynamique de l'art antérieur.

On prévoit notamment trois modules de commande dédiés aux échanges de SMS pour gérer la partie dynamique du programme applicatif.

-Un premier module appelé « Delete » qui contient comme paramètre la valeur des champs d'identification des modules à supprimer et permet ainsi d'effacer des modules spécifiques.

-Un deuxième module appelé « Update » de mise à jour d'un module de commande. Pour modifier un module de commande local, le fournisseur émet vers les terminaux concernés un module de modification « Update » portant l'identifiant du fournisseur, l'identifiant du module à mettre à jour, et l'indication du nouveau paramétrage ou du nouveau contenu. La mise à jour ainsi obtenue est transparente vis-à-vis des utilisateurs. Pour permettre d'en avertir l'utilisateur, la carte SIM comporte un module de communication, dit d'indication de mise à jour, qui provoque l'affichage d'un message fixe tel que "application mise à jour". Ce module d'indication peut tre déclenché par le module de modification. En variante, le module de commande de mise à jour peut comporter un champ d'affichage variable permettant de préciser le changement effectué.

-Un troisième module appelé « Trigger » qui permet de cibler un certain module de commande par son champ d'identification afin de commencer l'exécution du programme à partir de n'importe quel module.

La figure 1 illustre une application des modules de commande conformes à l'invention pour produire des fonctionnalités pour l'utilisateur au niveau d'une carte à puce SIM 2 d'un terminal de téléphonie mobile 4.

La carte à puce SIM 2 comprend son propre microprocesseur 6, une mémoire volatile du type RAM 8 ("random access memory"), une mémoire figée du type ROM 10 ("read only memory"), une mémoire ré-inscriptible électriquement effaçable du type EEPROM 12 ("electrically erasable programmable read only memory »), et une interface de communication 14 comportant des plots de contact pour relier la carte 2 fonctionnellement aux circuits du terminal 4.

La carte SIM 2 communique via le terminal de téléphonie mobile 4 avec des fournisseurs de contenus, chacun mettant à disposition un service en ligne : informations, commande d'achats, assistance, etc.

Pour communiquer avec un fournisseur de contenus 18, le terminal de téléphonie mobile 4 passe par un poste central 16, dit SMSC, qui agit en tant que relais pour la liaison sans fil au protocole GSM ou UMTS. Ce poste central regroupe tous les fournisseurs de contenus.

Le dialogue, i. e. la transaction, entre le terminal de téléphonie mobile 4 et un fournisseur de contenus 18 implique l'exécution en temps réel d'un programme applicatif au niveau de la carte SIM 2, pour gérer entre autres les échanges de données avec le fournisseur en externe et l'interface homme-machine via l'écran 4a et le clavier 4b en interne.

Conformément à l'invention, les programmes applicatifs pour dialoguer avec les fournisseurs de contenus sont composés de modules de commandes (MC) décrits ci-dessus. Dans l'exemple représenté sur la figure 1, ces modules MC sont stockés dans la portion de mémoire EEPROM 12, s'agissant d'éléments susceptibles d'tre modifiés ou supprimés à terme selon des choix d'application de l'utilisateur. Toutefois, certains modules de commande MC peuvent tre pré-

programmés dans la mémoire figée ROM 10 s'ils concernent des éléments immuables et fondamentaux, par l'exemple la gestion d'un menu principal. En cours de traitement, des modules de commande MC peuvent par ailleurs tre transférés provisoirement dans la mémoire vive RAM 8.

Naturellement, l'invention reste compatible avec le mode tout local ou statique, où l'ensemble de modules de commande MC susceptibles d'tre utilisés est préchargé en mémoire de la carte SIM 2 (par exemple dans la mémoire EEPROM 12). Dans ce cas, tous les utilisateurs du fournisseur de contenu ont donc à l'origine le mme ensemble de modules pré-chargés dans la carte SIM, soit en personnalisation, soit en post- personnalisation. Le fournisseur de contenu peut néanmoins à tout moment mettre à jour son programme par message SMS ou équivalent (par exemple pour insérer une nouvelle rubrique dans un module d'affichage de menu), ou par message de suppression ou d'adjonction sélective d'un module existant et de chargement d'un module de commande.

La gestion des modules dans la mémoire de la carte à puce est totalement différente de celle de l'art antérieur : en effet, tous les modules d'un mme programme applicatif sont réunis dans une mme structure de fichier. Cette gestion de la mémoire présente de nombreux avantages de flexibilité par rapport à l'art antérieur. En effet, les modules sont de petite taille et leur chargement dans un fichier présente de nombreuses possibilités. Tant qu'il reste de la place dans le fichier, il est possible d'ajouter des modules, ce qui permet à l'utilisateur de construire un service personnalisé en stockant dans ce fichier les modules de son choix.

Cette construction personnalisée du programme applicatif peut se faire dans une phase d'exécution du programme applicatif, durant laquelle, l'utilisateur télécharge au fur et à mesure les modules qui lui sont nécessaires et qui ne sont pas présents dans la carte SIM 2 et décide ou non de les conserver localement. Par exemple, un utilisateur peut choisir de conserver localement des modules qu'il utilise régulièrement et qui sont peu susceptibles de changer. Lors d'une exécution ultérieure, il utilisera donc statistiquement un grand nombre de modules déjà présents dans sa carte, ce qui rendra l'exécution plus rapide.

Quelques unes de ces possibilités sont décrites par l'exemple qui suit, illustré par la figure 2, d'un dialogue concernant une transaction entre un utilisateur d'un terminal de téléphonie mobile 4 comportant une carte SIM 2 prévue pour traiter des modules commandes conformes à l'invention et un fournisseur de contenu offrant une billetterie en ligne de cinémas parisiens.

L'utilisateur démarre le processus en faisant afficher sur son écran 4a le menu principal MP des différents fournisseurs de contenu accessibles en ligne. Il sélectionne le fournisseur de billetterie de cinémas parisiens, ce qui active automatiquement un premier module de commande MC1 produit par le fournisseur de cette billetterie, qui provoque l'affichage d'une liste des arrondissements de Paris.

Ce module MC1, ainsi que tous les autres modules utilisés dans le cadre de la transaction, comporte l'identifiant 24 du fournisseur de contenu IDFC (0x00 dans l'exemple), et son propre identifiant 26 de module de commande (0x01 dans l'exemple). L'identifiant 24 du fournisseur de contenu est unique pour un mme

fournisseur ; l'identifiant 26 du module de commande MC est unique pour ce module.

Le premier module de commande MC1, comme tout module destiné à produire un affichage de message, est du type comportant une commande d'affichage et un champ de données à afficher. Il est également prévu pour prendre acte d'une commande reçue par le clavier 4b sur la base de cet affichage.

Etant souvent évoqué, le premier module de commande MC1 est stockée en local dans la carte SIM 2.

En fonction de l'arrondissement sélectionné (deuxième) par le clavier 4b, le module de commande MC1 sélectionne et appel un deuxième module de commande MC2, également stocké en local, qui produit l'affichage de la liste des cinémas de cet arrondissement. Etant donné que la liste des cinémas est relativement constante dans le temps, ce deuxième module MC2 est également stocké en local dans la carte SIM 2.

Une fois le cinéma (Lumière) sélectionné, le deuxième module MC2 appel un troisième module de commande MC3, dit de requte, qui émet au fournisseur (billetterie cinéma) un message SMS de requte. Ce message comporte un champ paramétrable permettant d'indiquer les données requises. Dans le cas d'espèce, le troisième module de commande inscrit dans le champ adéquat le paramètre"PROG. LUMIERE", conformément à la sélection enregistrée par le deuxième module MC2, pour obtenir le programme du cinéma sélectionné.

En réponse, la billetterie cinéma ou le serveur central envoie à la carte SIM 2 un module de commande MC4 contenant les données concernant les films du cinéma sélectionné et une commande d'affichage de ces données. Ce module distant MC4 est activé dès réception pour afficher ses données sur l'écran 4b sous forme de liste de films.

Une fois que l'utilisateur sélectionne le film (film C), le module de commande MC4 appel un cinquième module de commande MC5 qui est un module de requte dont le champ paramétrable précise une demande d'horaires pour le film sélectionné"HOR. FILM C", conformément à la sélection enregistrée par le module précédant MC4.

En réponse, la billetterie ou son serveur central envoie à la carte SIM 2 un module de commande MC6 contenant les données concernant les horaires de séances pour le film C sélectionné et une commande d'affichage de ces données. Ce module distant MC6 est activé dès réception pour afficher ces données sur l'écran 4b sous forme de liste d'horaires pour le film B.

Une fois que l'utilisateur sélectionne l'horaire (19h45), le module de commande MC6 appel un septième module MC7 qui est un module de formatage de message SMS paramétré par deux champs : le nom du film"NOM FILM"et l'horaire"HORAIRE", afin d'établir la commande d'achat du billet. Ces champs sont remplis automatiquement respectivement sur la base des sélections enregistrées sur les quatrième et sixième modules MC4 et MC6. Ensuite, le septième module MC7 appel un huitième module MC8 d'émission à la billetterie ou du serveur central 18 du résultat de formatage établi par le module MC7. A réception du module MC8, la billetterie ou le serveur central extrait du résultat de formatage le contenu de deux champs"NOM FILM"et"HORAIRE"afin de réserver une place pour le film C à la séance de 19h45 pour l'utilisateur identifié par l'appel GSM.

Dans l'exemple, tous les modules distants sont transmis à la carte SIM 2 par messages SMS.

Bien entendu, d'autres modules peuvent tre mis en oeuvre de manière analogue pour établir diverses autres conditions pour la réservation : nombre de places, date autre que le jour mme, etc.

On remarque de l'exemple l'exécution de façon transparente pour l'utilisateur des modules de commande statiques stockés dans la carte SIM 2 et des modules de commande dynamiques stockés auprès du fournisseur de contenu (billetterie) ou le cas échéant de son serveur central. Le choix de stockage des modules en mode local ou distant est arbitraire et dépend de considérations de taille, de volume disponible en mémoire dans la carte SIM 2, de fréquence d'utilisation et de mise à jour, etc. Les modules de commande génériques, notamment pour l'émission d'un message SMS (MC3, MC5, MC8) ou pour un formatage (MC7) sont avantageusement stockés en mode local dans la carte SIM 2.

Les identifiants 26 des modules de commande sont avantageusement établis de manière dynamique en fonction de leur ordre d'utilisation, permettant de garder en mémoire une séquence d'utilisation de modules successifs. Les modules distants (par exemple MC4 et MC6) chargés dans la carte peuvent y rester après leur utilisation pour éviter de les recharger à nouveau en cas de besoin.

Cependant, afin de ne pas encombrer l'espace mémoire, ces modules distants peuvent tre effacés par une gestion interne de la carte. Ils peuvent aussi tre effacés automatiquement une fois leur utilité terminée.

Du fait que les modules de commande conformes à l'invention permettent de réaliser des applications sur mesure, il est prévu en option la possibilité de garder dans la carte SIM 2 un suivi, accessible à distance par le fournisseur de contenus, des applications

configurées sur la carte SIM 2 et correspondant au profil de son utilisateur.

L'invention permet en outre la mise en oeuvre avantageuse d'un marque page ou signet électronique (connu également par le terme anglais de"bookmark").

Le marque page permet à l'utilisateur de stocker tout module de commande"proactif"i. e. par lequel il peut interagir avec à la fois le lien et les données d'une session de télécommunication. De la sorte, une page précise peut tre évoquée et présentée.

Le marque page est géré par le biais de l'octet de configuration d'un module de commande, en positionnant un bit particulier de ce dernier à état logique prédéterminé.

La sauvegarde d'un marque page s'opère par inscription d'un raccourci à partir d'un menu. Les détails des marque pages sont séparés en trois sections - propriétés, soit la liste des marque pages et l'espace disponible pour le stockage de marque pages supplémentaires, - détails d'accès rapide, soit le nom du marque page et le lien (identification 26 du module de commande faisant l'objet d'un marque page), et - les données de la session, soit le chemin parcouru par une application et les résultats du chemin.

De préférence, seul le fournisseur de contenu est capable de créer un lien vers un marque page.

L'utilisateur se verra présenté une liste de raccourcis en mémoire.

Un marque page peut tre retiré par un menu afin de supprimer ainsi le lien depuis la liste et ainsi de libérer de l'espace mémoire.

L'invention permet de nombreuses variantes au

niveau des applications, de la structure des modules de commande, des actions qu'ils produisent, de leur contenu, de leur transport et de leur gestion interne.

Par exemple, cette structure modulaire peut tre combinée avec une structure classique de pages Web de manière à ne former qu'un seul service.

Par ailleurs, les modules de commande peuvent tre stockés sur tout support et exécutés sur tout support, par exemple toute carte à puce ou autre objet analogue à mémoire limitée, ordinateurs portables, périphérique d'ordinateur, assistant personnel numérique, etc. Ils peuvent tre appliqués à différentes technologies de communication avec un serveur distant, comme par exemple le GSM comme nous l'avons vu, mais aussi d'autres communications sans fil, ou Internet...

Par ailleurs, il est clair que plusieurs modules de commande peuvent tre chargés de manière groupée dans le terminal 4 en réponse à une requte de celui- ci, par exemple en anticipation d'actions imminentes à accomplir, plutôt qu'individuellement par requte spécifique comme dans l'exemple.