WO2003073273A1 - Procede et dispositif de gestion decentralisee et personnalisee de services - Google Patents
Procede et dispositif de gestion decentralisee et personnalisee de services Download PDFInfo
- Publication number
- WO2003073273A1 WO2003073273A1 PCT/FR2002/000742 FR0200742W WO03073273A1 WO 2003073273 A1 WO2003073273 A1 WO 2003073273A1 FR 0200742 W FR0200742 W FR 0200742W WO 03073273 A1 WO03073273 A1 WO 03073273A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- terminal
- control module
- module
- modules
- execution
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
Definitions
- SIM smart card International acronym for "subscriber identity module”
- static programs which reside entirely on the card and are executed locally
- dynamic programs which provides for interaction with a remote server.
- the application program is entirely stored on the card. Its execution takes place locally and autonomously. This solution has obvious limits due to the lack of possibility of taking into account data which change over time. In addition, updating the program and / or program data itself is complicated.
- modules in the memory of the smart card are totally different from that of the prior art: in fact, all the modules of the same application program are combined in the same file structure.
- This memory management has many advantages of flexibility compared to the prior art. Indeed, the modules are small and loading them into a file presents many possibilities. As long as there is room in the file, it is possible to add modules, which allows the user to build a personalized service by storing in this file the modules of his choice.
- This personalized construction of the application program can be done in an execution phase of the application program, during which the user progressively downloads the modules which are necessary for him and which are not present in the SIM card 2 and decides or not to keep them locally. For example, a user can choose to locally keep modules that he uses regularly and that are unlikely to change. During a subsequent execution, it will therefore statistically use a large number of modules already present in its card, which will make execution faster.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Telephonic Communication Services (AREA)
Abstract
L'invention concerne la gestion de programmes applicatifs, ces derniers étant construits à partir de modules de commande représentant des commandes élémentaires de haut niveau. Elle s'applique particulièrement aux appareils de type GSM, pour lesquels une partie dite statique du programme applicatif se trouve stockée au sein de l'appareil et une autre partie, dite dynamique, se trouve stockée sur un serveur distant.
Description
PROCEDE ET DISPOSITIF DE GESTION DECENTRALISEE ET PERSONNALISEE DE SERVICES
L'invention concerne la gestion de programmes dits applicatifs qui représentent des services offerts par des entités communément appelées fournisseurs de services ou fournisseurs de contenu.
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-même 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 n' a 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, même 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 requête 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 œuvre à 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 œuvre 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=0x04, 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 .
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 même 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 même programme applicatif sont réunis dans une même 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 MCI produit par le fournisseur de cette billetterie, qui provoque l'affichage d'une liste des arrondissements de Paris. Ce module MCI, 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 même
fournisseur ; l'identifiant 26 du module de commande MC est unique pour ce module.
Le premier module de commande MCI, 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 MCI 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 MCI 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 requête, qui émet au fournisseur
(billetterie cinéma) un message SMS de requête. 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 requête 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 œuvre de manière analogue pour établir diverses autres conditions pour la réservation : nombre de places, date autre que le jour même, 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 œuvre 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 requête de celui- ci, par exemple en anticipation d'actions imminentes à accomplir, plutôt qu'individuellement par requête spécifique comme dans l'exemple.
Claims
1. Procédé d'exécution par un terminal (4) d'un programme applicatif fourni par une entité distante, caractérisé en ce qu'il comprend les étapes de exécuter un ensemble de modules de commande stockés sur le terminal de manière autonome, et
- télécharger et exécuter des modules de commande provenant de l'entité distante.
2. Procédé selon la revendication 1, caractérisé en ce que l'on confère à chaque module de commande :
- un identifiant qui lui est propre,
- un identifiant de l'entité distante, et - un identifiant de sa fonction.
3. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les modules de commande sont stockés sur le terminal dans un même fichier.
4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'un module de commande est téléchargé sur requête du terminal en fonction de l'exécution d'une commande par un module de commande précédent.
5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le module de commande comporte des données d'affichage sur l'écran (4a) du terminal (4) .
6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend une phase d'établissement de marque page, pour établir un lien au sein du terminal (4) vers au moins un module de commande de l'entité distante.
7. Support électronique, caractérisé en ce qu'il contient un moyen de stockage et d' exécution d' au moins un module de commande.
8. Support électronique selon la revendication précédente caractérisé en ce qu' il est une carte à puce .
9. Téléphone portable (4) apte à mettre en œuvre le procédé selon les revendications 1 à 6, caractérisé en ce qu'un module de commande est téléchargé dans le terminal (4) par un message au format SMS.
10. Téléphone portable (4) selon la revendication précédente caractérisé en ce qu'il contient au moins un module de commande stocké et exécuté sur sa carte à puce SIM.
11. Mise en œuvre du procédé selon l'une quelconque des revendications 1 à 6 pour obtenir un service auprès d'un fournisseur de contenu depuis un terminal de téléphonie mobile (4), comprenant les étapes de :
- exécuter au moins un module commande au sein du terminal avec prise en compte d'une sélection émise par l'utilisateur du terminal, et - émettre au fournisseur de contenu un message en fonction de l'exécution dudit module de commande.
12. Mise en œuvre du procédé selon l'une quelconque des revendications 1 à 6 par un fournisseur de contenu pour fournir un service à destination d'un terminal de téléphonie mobile (4), comprenant les étapes de :
- mettre à disposition du terminal (4) au moins un module de commande, et - répondre au terminal en fonction d'un message reçu de ce dernier en réponse à l'exécution du module de commande .
13. Programme applicatif caractérisé en ce qu'il comprend au moins un module de commande représentant une commande de haut niveau proposée par un fournisseur de service.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| AU2002241075A AU2002241075A1 (en) | 2002-02-28 | 2002-02-28 | Decentralised and customised service management method and device |
| PCT/FR2002/000742 WO2003073273A1 (fr) | 2002-02-28 | 2002-02-28 | Procede et dispositif de gestion decentralisee et personnalisee de services |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/FR2002/000742 WO2003073273A1 (fr) | 2002-02-28 | 2002-02-28 | Procede et dispositif de gestion decentralisee et personnalisee de services |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2003073273A1 true WO2003073273A1 (fr) | 2003-09-04 |
Family
ID=27763523
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/FR2002/000742 WO2003073273A1 (fr) | 2002-02-28 | 2002-02-28 | Procede et dispositif de gestion decentralisee et personnalisee de services |
Country Status (2)
| Country | Link |
|---|---|
| AU (1) | AU2002241075A1 (fr) |
| WO (1) | WO2003073273A1 (fr) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1703382A1 (fr) * | 2005-03-16 | 2006-09-20 | Sun Microsystems, Inc. | Procédé de chargement d'applications dans un dispositif mobile |
| WO2010078971A1 (fr) * | 2008-12-15 | 2010-07-15 | Sony Ericssn Mobile Communications Ab | Procédé, programme informatique et dispositif électronique |
| CN108804125A (zh) * | 2018-06-29 | 2018-11-13 | 四川科道芯国智能技术股份有限公司 | 应用管理方法、装置及终端设备 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0869691A2 (fr) * | 1997-04-04 | 1998-10-07 | Deutsche Telekom AG | Station mobile GSM, contrÔlable par le réseau |
| US6023620A (en) * | 1997-02-26 | 2000-02-08 | Telefonaktiebolaget Lm Ecrisson | Method for downloading control software to a cellular telephone |
| EP1049006A2 (fr) * | 1999-04-16 | 2000-11-02 | eMisis InfoCom Group Plc | Transfert des messages électroniques à un PDA |
-
2002
- 2002-02-28 AU AU2002241075A patent/AU2002241075A1/en not_active Abandoned
- 2002-02-28 WO PCT/FR2002/000742 patent/WO2003073273A1/fr not_active Application Discontinuation
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6023620A (en) * | 1997-02-26 | 2000-02-08 | Telefonaktiebolaget Lm Ecrisson | Method for downloading control software to a cellular telephone |
| EP0869691A2 (fr) * | 1997-04-04 | 1998-10-07 | Deutsche Telekom AG | Station mobile GSM, contrÔlable par le réseau |
| EP1049006A2 (fr) * | 1999-04-16 | 2000-11-02 | eMisis InfoCom Group Plc | Transfert des messages électroniques à un PDA |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1703382A1 (fr) * | 2005-03-16 | 2006-09-20 | Sun Microsystems, Inc. | Procédé de chargement d'applications dans un dispositif mobile |
| US7941656B2 (en) | 2005-03-16 | 2011-05-10 | Oracle America, Inc. | Card device for loading applications to a mobile device |
| US8225082B2 (en) | 2005-03-16 | 2012-07-17 | Oracle America, Inc. | Card device for loading applications to a mobile device |
| WO2010078971A1 (fr) * | 2008-12-15 | 2010-07-15 | Sony Ericssn Mobile Communications Ab | Procédé, programme informatique et dispositif électronique |
| CN108804125A (zh) * | 2018-06-29 | 2018-11-13 | 四川科道芯国智能技术股份有限公司 | 应用管理方法、装置及终端设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| AU2002241075A1 (en) | 2003-09-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20030065738A1 (en) | Wireless information systems and methods | |
| EP1726124B1 (fr) | Systeme et procede de controle d'equipements a distance a l'aide de commandes at, dispositif, module de radiocommunication et programme correspondants | |
| US20050232175A1 (en) | System and method for provisioning device management tree parameters over a client provisioning protocol | |
| EP2795878B1 (fr) | Procédé de partage d'un contenu multimédia entre utilisateurs | |
| EP1395962B1 (fr) | Deploiement d'application depuis une carte a puce | |
| US10887414B2 (en) | Theme-based push notifications | |
| FR2947130A1 (fr) | Module client ussd generique intelligent embarque dans un terminal de telecommunications | |
| FR2767011A1 (fr) | Procede d'adaptation du fonctionnement d'un module d'identification d'abonne a une ou des interface(s) d'un terminal mobile de radio-communication, module d'identification d'abonne et terminal mobile correspondants | |
| WO2001030093A1 (fr) | Systeme et procede de transmission de messages, et utilisation du systeme de transmission pour l'investigation de services fournis | |
| CN100334547C (zh) | 数据处理装置和数据处理装置的存储空间的优化处理方法 | |
| EP2327236B1 (fr) | Centre ussd générique d'applications et de services réseaux | |
| EP1551193A1 (fr) | Procédé de personnalisation automatique d'un terminal mobile en fonction du module d'identification de l'utilisateur et terminal mobile personnalisable | |
| WO2003073273A1 (fr) | Procede et dispositif de gestion decentralisee et personnalisee de services | |
| WO2001065480A1 (fr) | Procede de commande d'une carte a puce | |
| WO2007071695A1 (fr) | Exploitation d'informations proprietaires transmises par un reseau de radiocommunications a un terminal mobile sous le controle d'une carte a puce | |
| US20050101311A1 (en) | Data driven engine and system for wireless communications | |
| EP1208519B1 (fr) | Systeme et procede de chargement de commandes dans une carte a circuit integre | |
| EP3035723B1 (fr) | Procédé de transmission de données en relation avec une communication | |
| FR3128840A1 (fr) | Supervision du fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes | |
| EP2180673A1 (fr) | Procédé de messages contextuels dans des dispositifs de communication | |
| WO2009071836A1 (fr) | Procédé de gestion de l'interface utilisateur d'un terminal mobile associé à un module de sécurité et terminal mobile associé | |
| EP1233383A1 (fr) | Procédé et dispositif de gestion d'applications de cartes à puce | |
| WO2005059847A1 (fr) | Carte a microcircuit multi-compte permettant la restriction d’une fonctionnalite a un compte et procede de communication correspondant | |
| FR2816429A1 (fr) | Carte a puce avec descripteur d'application | |
| EP1256066A2 (fr) | Microcontroleur et procede pour la gestion d'applications interactives |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW |
|
| AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
| 122 | Ep: pct application non-entry in european phase | ||
| NENP | Non-entry into the national phase |
Ref country code: JP |
|
| WWW | Wipo information: withdrawn in national office |
Country of ref document: JP |