EP1256066A2 - Microcontroleur et procede pour la gestion d'applications interactives - Google Patents

Microcontroleur et procede pour la gestion d'applications interactives

Info

Publication number
EP1256066A2
EP1256066A2 EP01907717A EP01907717A EP1256066A2 EP 1256066 A2 EP1256066 A2 EP 1256066A2 EP 01907717 A EP01907717 A EP 01907717A EP 01907717 A EP01907717 A EP 01907717A EP 1256066 A2 EP1256066 A2 EP 1256066A2
Authority
EP
European Patent Office
Prior art keywords
command
portable object
terminal
card
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP01907717A
Other languages
German (de)
English (en)
Inventor
Tarik Slassi
Christian Dietrich
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales DIS France SA
Original Assignee
Schlumberger Systemes SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Schlumberger Systemes SA filed Critical Schlumberger Systemes SA
Publication of EP1256066A2 publication Critical patent/EP1256066A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
    • G06F15/7807—System on chip, i.e. computer system on a single chip; System in package, i.e. computer system on one or more chips in a single package
    • G06F15/7814—Specially adapted for real time processing, e.g. comprising hardware timers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229—Use of the SIM of a M-device as secure element
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/356—Aspects of software for card payments
    • G06Q20/3563—Software being resident on card
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices

Definitions

  • FIG. 6 is a third of communication between a device for managing the microcontroller of the first portable object, the second microcontroller of the second portable object and the terminal of FIG. 3.
  • FIG. 7 is a fourth communication link between a device for managing the microcontroller of the first portable object, the second microcontroller of the second portable object and the terminal of FIG. 3.
  • integrated circuit card is meant, for example, a card in ISO format, a card in token format commonly called in English "plug-in" format, such as a subscriber identification module (SIM) or an electronic label.
  • SIM subscriber identification module
  • the invention applies generally to any microcontroller intended to be incorporated into any other portable object such as for example a ring or a key holder. It is the same for said second portable object.
  • the first card C l is a card supplied by an operator of a telecommunications network
  • the second card C2 is a bank card supplied by a service provider such as a bank
  • the terminal T is a mobile communicating with the telecommunication network of said operator (not shown).
  • FETCH search command making it possible to search for an interface command, for a third group of commands, coming from a second card C2 and to send it to the mobile
  • the server sends the balance of the account number NB on the screen interface of the mobile T.
  • commands coming from an interactive application of a second card C2 can affect the functioning of interactive applications being on the first card C l.
  • a SETUPMENU menu insertion command from the second card C2. This command makes it possible to insert a menu in a system menu of the terminal T which appears on the screen S.
  • the command calls upon various identifiers ITEM_ID corresponding to services which the user can choose from the menu.
  • the interactive application of the first card C l also includes a menu and identifiers, there is a risk of mixing the different identifiers of the different interactive menus.
  • the DSG management device includes means for renumbering identifiers according to the menu selected and the service selected.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un microcontrôleur destiné à être incorporé dans un premier objet portatif, notamment au format carte, coopérant avec un terminal. L'invention se caractérise en ce que le microcontrôleur comprend un dispositif de gestion d'applications interactives d'un deuxième objet portatif, ledit deuxième objet portatif comportant au moins une application interactive comprenant des commandes d'interface et des données permettant une interaction avec au moins une interface dudit terminal, ledit dispositif étant apte à gérer des échanges de données et une exécution desdites commandes d'interface entre ledit terminal et ledit deuxième objet portatif. L'invention s'applique, en particulier, au domaine de la téléphonie mobile.

Description

MICROCONTROLEUR ET PROCEDE POUR LA GESTION
D'APPLICATIONS INTERACTIVES
La présente invention concerne un microcontrôleur destiné à être incorporé dans un objet portatif, notamment au format carte appelée carte à circuit intégré, coopérant avec un terminal. Elle concerne également un procédé de gestion d'applications d'un tel microcontrôleur.
L'invention trouve une application particulièrement avantageuse dans le domaine de la téléphonie.
Dans le domaine de la téléphonie, le terminal est un téléphone portable appelé mobile comprenant généralement un écran et un clavier. Ledit mobile coopère avec la carte à circuit intégré appelée carte SIM. Cette dernière est fournie par un opérateur de télécommunications gérant un réseau de télécommunication et permet à un utilisateur du mobile un accès audit réseau. Une carte à circuit intégré se compose d'un corps de carte dans lequel est incorporé le microcontrôleur. Ce dernier comporte au moins une application appelée application « toolkit » basée sur un protocole de communication appelé protocole « toolkit » décrit dans les standards GSM 1 1. 1 1 et GSM 1 1. 14 édités par l'ETSI.
Une application « toolkit » comprend des commandes qui sont envoyées au mobile et qui permettent, par exemple, d'afficher du texte sur l'écran du mobile, d'envoyer des messages à un serveur à travers ledit réseau de télécommunications, de faire des appels téléphoniques automatiques sans entrer de numéro. Lesdites commandes permettent ainsi une interaction avec des interfaces dudit mobile telles que le clavier, l'écran ou le réseau.
A l'aide des applications toolkits et grâce à une fonctionnalité appelée en langage anglo-saxon « Multiple Card » définie dans le standard GSM 1 1. 14, on peut également adresser une deuxième carte à circuit intégré connectée au mobile, en envoyant des commandes sur ladite deuxième carte à partir du microcontrôleur de la première carte.
Cette deuxième carte peut être utilisée par un fournisseur de service, par exemple une banque. Elle comporte un microcontrôleur comprenant une application bancaire permettant d'effectuer des services connus de transactions bancaires ou de porte-monnaie électronique.
La banque peut vouloir rendre accessible sur un mobile certains de ces services tels qu'une visualisation de l'état d'un compte bancaire ou un virement bancaire. Aussi, afin de permettre l'accès à un utilisateur du mobile auxdits services proposés par la banque, selon un dispositif connu de l'état de la technique et divulgué dans ledit standard GSM 1 1 . 14, le microcontrôleur de la première carte comporte une application toolkit relative auxdits services bancaires, des commandes associées ainsi que des données nécessaires à une exécution desdits services telles qu'une valeur de clef secrète permettant un échange sécurisé de données ou un numéro de compte bancaire. Cette application toolkit est généralement fournie par le fournisseur de service à l'opérateur. Ce dernier la met sur sa première carte. Dans l'application toolkit, on utilise la fonctionnalité « Multiple
Card » pour permettre notamment d'exécuter dans le microcontrôleur de la deuxième carte des commandes telles qu'une lecture de numéro de compte bancaire, numéro que l'on transfère par la suite dans la première carte. Dans le dispositif décrit ci-dessus se pose alors le problème d'accès aux interfaces du terminal au moyen du microcontrôleur de la deuxième carte. En effet, au moyen de la deuxième carte, on ne peut communiquer directement avec le terminal. Seule la première carte peut directement dialoguer avec le terminal et accéder aux interfaces clavier/ écran/ réseau du terminal au moyen du protocole de communication « toolkit ». Par suite, seule une première carte peut accéder, via ledit terminal, à des serveurs distants tels qu'un serveur du fournisseur de service comprenant par exemple des données relatives au numéro de compte bancaire. Il serait intéressant que la deuxième carte puisse également dialoguer directement avec le terminal.
Ce dispositif présente encore de nombreux autres inconvénients, tels que : un partage des données du fournisseur entre la première carte et la deuxième carte. En effet, des données du fournisseur de service se trouvant dans le microcontrôleur de la première carte de l'opérateur, ce dernier doit garantir à un fournisseur de service un degré suffisant de confidentialité de ces données comprenant couramment des données secrètes et ce en effectuant, généralement, une évaluation sécuritaire sur sa propre première carte, évaluation qui est longue, complexe et très coûteuse, une adaptation d'une application d'un fournisseur de service à chaque nouvel ensemble de premières cartes de chaque nouvel opérateur. Un microcontrôleur d'un ensemble de premières carte d'un opérateur comporte généralement des caractéristiques différentes d'un microcontrôleur d'un autre ensemble de premières cartes du même opérateur ou d'un autre opérateur. Aussi, l'application du fournisseur doit être adaptée en fonction de chaque ensemble de premières cartes d'un opérateur donné ce qui entraîne une gestion lourde des applications,
- une obligation pour un opérateur de fournir une carte comportant un microcontrôleur comprenant une grande capacité mémoire pour stocker l'ensemble des applications de l'ensemble des fournisseurs de service. Aussi, un problème technique à résoudre par l'objet de la présente invention est de proposer un microcontrôleur destiné à être incorporé dans un objet portatif, notamment au format carte, coopérant avec un terminal, ainsi qu'un procédé de gestion d'applications d'un tel microcontrôleur, qui permettraient, de gérer, d'une part, au moins un deuxième objet portatif d'un fournisseur de service, et, d'autre part, de permettre un échange de communications entre ledit deuxième objet portatif et ledit terminal tout en palliant aux différents inconvénients cités ci-dessus. Une solution au problème technique posé se caractérise, selon un premier objet de la présente invention, en ce que ledit microcontrôleur comprend un dispositif de gestion d'applications interactives d'un deuxième objet portatif, ledit deuxième objet portatif comportant au moins une application interactive comprenant des commandes d'interface et des données permettant une interaction avec au moins une interface dudit terminal, ledit dispositif étant apte à gérer des échanges de données et une exécution desdites commandes d'interface entre ledit terminal et ledit deuxième objet portatif.
Selon un second objet de la présente invention, cette solution se caractérise en ce que le procédé de gestion d'applications gère des échanges de données et une exécution de commandes d'interface entre ledit terminal et un deuxième objet portatif au moyen d'un dispositif de gestion d'applications interactives compris dans ledit microcontrôleur, ledit deuxième objet portatif comportant au moins une application interactive comprenant lesdites commandes d'interface et lesdites données permettant une interaction avec au moins une interface dudit terminal.
Ainsi, comme on le verra en détail plus loin, le dispositif de l'invention permet de gérer au moins une application interactive d'un fournisseur qui est enregistrée directement dans un microcontrôleur dudit deuxième objet portatif et non plus dans le premier microcontrôleur du premier objet portatif. On envoie et on exécute, grâce au dispositif de gestion, des commandes d'interface de ladite application interactive dudit deuxième objet portatif audit terminal ou des commandes dudit terminal vers ledit deuxième objet portatif. Ce dernier a ainsi accès aux interfaces clavier/ écran /réseau du terminal, le premier microcontrôleur comprenant le dispositif de gestion ne servant que d'intermédiaire dans les communications entre le terminal et le microcontrôleur du deuxième objet portatif. La description qui va suivre au regard des dessins annexés, donnés à titre d'exemples non limitatifs, 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 microcontrôleur incorporé dans un premier objet portatif conforme à l'invention, par exemple, une carte à circuit intégré.
La figure 2 est un schéma du microcontrôleur de la figure 1 , d'un deuxième microcontrôleur d'un deuxième objet portatif et d'un terminal.
La figure 3 est un autre schéma du microcontrôleur du premier objet portatif, du deuxième microcontrôleur du deuxième objet portatif et du terminal de la figure 2.
La figure 4 est un premier schéma de communication entre un dispositif de gestion du microcontrôleur du premier objet portatif, le deuxième microcontrôleur du deuxième objet portatif et le terminal de la figure 3. La figure 5 est un deuxième de communication entre un dispositif de gestion du microcontrôleur du premier objet portatif, le deuxième microcontrôleur du deuxième objet portatif et le terminal de la figure 3.
La figure 6 est un troisième de communication entre un dispositif de gestion du microcontrôleur du premier objet portatif, le deuxième microcontrôleur du deuxième objet portatif et le terminal de la figure 3. La figure 7 est un quatrième de communication entre un dispositif de gestion du microcontrôleur du premier objet portatif, le deuxième microcontrôleur du deuxième objet portatif et le terminal de la figure 3. Le présent exposé de l'invention a trait à l'exemple des cartes à circuit intégré. Par carte à circuit intégré, on entend, par exemple, une carte au format ISO, une carte au format jeton couramment appelé dans le langage anglo-saxon format "plug-in", tel qu'un module d'identification abonné (SIM) ou encore une étiquette électronique. Néanmoins, il est bien entendu que l'invention s'applique de manière générale à tout microcontrôleur destiné à être incorporé dans tout autre objet portatif tel que par exemple une bague ou un porte-clef. Il en est de même pour ledit deuxième objet portatif.
Sur la figure 1 est représenté un premier microcontrôleur incorporé dans une première carte C l à circuit intégré. Ce microcontrôleur MC 1 comprend un élément 1 1 de commande (par exemple une unité centrale de traitement ou CPU), une mémoire 12 non volatile réinscriptible, une mémoire 13 non volatile non réinscriptible, et un bloc 14 de contacts destiné à une connexion électrique/ électromagnétique avec par exemple un connecteur d'un lecteur de cartes contact/ sans contact placé dans un terminal T. Le microcontrôleur MC I comporte en outre un dispositif de gestion DSG d'applications interactives d'une carte à circuit intégré et une première application A l . La première carte C l est de préférence insérée dans le terminal T. Le dispositif DSG peut se trouver dans la mémoire 13 non volatile non réinscriptible ou dans la mémoire 12 non volatile réinscriptible.
Il comporte des moyens d'aiguillage et d'exécution de commande
M d'application interactive. Il comporte en outre les moyens suivants : - des moyens de vérification d'application M l étant aptes à vérifier si ladite au moins application interactive A3 du deuxième objet portatif C2 est supportée par le dispositif de gestion DSG, des moyens d'information M2 étant aptes à informer le deuxième objet portatif C2 relativement notamment aux commandes et événements supportés par le terminal T et par le dispositif de gestion DSG, des moyens de sélection d'application M3 étant aptes à sélectionner ladite au moins application interactive A3 du deuxième objet portatif C2,
- des moyens de scrutation périodique M4 du deuxième objet portatif C2 étant aptes à vérifier périodiquement si une commande d'interface de ladite application interactive A3 est en attente d'être envoyée. Enfin, le dispositif de gestion DSG comporte une commande applicative d'envoi de commande PERFORMCARDAPDU à la deuxième carte C2. Comme on le verra par la suite, les moyens d'information M2, les moyens de sélection M3 et les moyens de scrutation périodique M4 du deuxième objet portatif C2 comprennent ladite commande applicative d'envoi de commande PERFORMCARDAPDU.
Comme montré à la figure 2, le terminal T comporte une interface écran S, une interface clavier K et une interface réseau N. Il est apte à coopérer avec une deuxième carte C2 à circuit intégré. Cette deuxième carte C2 peut être insérée ou non dans le terminal T. Elle comporte un microcontrôleur MC2 comprenant une deuxième application A2 et au moins une application interactive A3.
Pour alléger la description, on dira qu'une carte comporte les applications au lieu de dire que le microcontrôleur de la carte comporte les applications et on parlera du dispositif de gestion DSG de la première carte C l au lieu de parler du dispositif de gestion DSG du microcontrôleur de la première carte C l . De même, par exemple, on parlera de commande exécutée dans une carte tout en sachant que la commande est exécutée dans le microcontrôleur de la carte. Enfin, on parlera indifféremment de carte coopérant avec le terminal ou de microcontôleur coopérant avec le mobile.
Dans l'exemple de la figure 3, la première carte C l est une carte fournie par un opérateur d'un réseau de télécommunication, la deuxième carte C2 est une carte bancaire fournie par un fournisseur de service telle qu'une banque et le terminal T est un mobile communiquant avec le réseau de télécommunication dudit opérateur (non représenté) .
La première application A l est, par exemple, une application téléphonique standard permettant un échange de communications avec le mobile T et avec le réseau de communication. Elle se trouve de préférence dans la mémoire 13 non volatile non réinscriptible du microcontrôleur MC I de la première carte C l .
La deuxième application A2 est, par exemple, une application bancaire standard permettant couramment de gérer les opérations de transactions bancaires avec un terminal bancaire. Elle se trouve de préférence dans la mémoire 13 non volatile non réinscriptible de la deuxième carte C2.
L'application interactive A3 est, par exemple, une application bancaire mobile couramment appelée dans le langage anglo-saxon « mobile banking ». Elle se trouve de préférence dans la mémoire 12 non volatile réinscriptible de la deuxième carte C2. Ainsi, la banque si elle le souhaite peut modifier son application A3 sans contraintes.
Ladite application interactive A3 utilise des données DATA et plus particulièrement des données secrètes telles qu'un numéro de compte bancaire NB. La deuxième carte C2 comporte toutes les données DATA, y compris les données secrètes, relatives à ladite application interactive A3. Lesdites données et ne sont par suite connues ni de la première carte C l , ni des autres deuxièmes cartes C2 qui pourraient venir coopérer avec le mobile. Par suite, une sécurité et une indépendance des données sont préservées. Ainsi un opérateur n'aura pas à garantir à un fournisseur de service un degré suffisant de confidentialité des données notamment secrètes dudit fournisseur et par suite n'aura pas besoin d'effectuer une évaluation sécuritaire sur sa propre première carte C l . Les données DATA se trouvent de préférence dans la mémoire 12 non volatile réinscriptible.
L'application interactive A3 permet une interaction avec au moins une interface du mobile. Elle est gérée au moyen du dispositif de gestion DSG de la première carte C l qui administre des échanges de données et une exécution de commandes de l'application interactive A3 entre ledit mobile T et ladite au moins deuxième carte C2. On notera que le dispositif de gestion DSG se trouvant dans une première carte C l présente l'avantage qu'un opérateur pourra utiliser sa première carte C l dans tout terminal pouvant communiquer avec sa carte. Il ne sera pas dépendant d'un fournisseur de terminal donné. Grâce au moyens d'aiguillage et d'exécution de commande M du dispositif de gestion DSG, on aiguille au moins une commande provenant de l'application interactive A3 de ladite deuxième carte C2 vers le mobile T, on exécute ladite commande dans ledit mobile T et on envoie une réponse issue du mobile T vers cette même carte C2. De même, grâce à ces moyens, on aiguille au moins une commande provenant dudit mobile T vers ladite deuxième carte C2, on exécute ladite commande dans ladite deuxième carte C2 et on envoie une réponse issue de ladite deuxième carte C2 vers ledit mobile T.
A cette fin, les moyens d'aiguillage M du dispositif de gestion DSG comprennent les moyens suivants : des moyens de recherche de commande d'interface M5 étant aptes à rechercher une commande d'interface, provenant de l'application interactive de la deuxième carte C2, en attente d'être envoyée, - des moyens de réception et de sauvegarde de commande d'interface M6 étant aptes à réceptionner et à sauvegarder la commande d'interface envoyée à partir de la deuxième carte C2, des moyens d'envoi et d'exécution de commande d'interface M7 étant aptes à envoyer et à exécuter dans le mobile T la commande d'interface provenant de la deuxième carte C2, des moyens de sauvegarde de réponse d'exécution de commande d'interface M8 étant aptes à sauvegarder une réponse d'exécution de commande d'interface issue du mobile T suite à l'exécution de ladite commande, des moyens d'envoi de réponse M9 étant aptes à envoyer ladite réponse à la deuxième carte C2. Les moyens de recherche de commande M5 et les moyens d'envoi de réponse M9 comprennent ladite commande applicative d'envoi de commande PERFORMCARDAPDU.
Ladite commande applicative PERFORMACARAPDU est apte à encapsuler une commande. De plus, elle est apte à déclencher, d'une part, l'envoi de la commande encapsulée dudit mobile à ladite deuxième carte C2, et, d'autre part, l'exécution de ladite commande dans ladite deuxième carte C2, lorsqu'elle est envoyée de la première carte C l audit mobile T par le dispositif de gestion DSG. La commande d'envoi de commande PERFORMCARDAPDU est apte à encapsuler au moins une commande appartenant à un groupe de commandes de gestion de protocole. Préférentiellement, des commandes appartenant à deux groupes différents peuvent être encapsulées (non représenté) .
Le premier groupe de commandes comporte notamment des commandes envoyées par le mobile T, appelées commandes simples, telles que : une commande d'état STATUS donnant à une deuxième carte C2 les moyens d'indiquer au dispositif de gestion DSG qu'une commande commande d'interface est en attente d'être envoyée, une commande de sélection, une commande de mise à jour de données.... Le deuxième groupe de commandes comporte notamment des commandes de gestion de protocole, appelés dans le standard GSM 1 1 . 14 commandes toolkit et protocole toolkit, telles que :
- une commande de propriété TERMINALPROFILE permettant d'indiquer notamment à une deuxième carte C2 quelles sont les commandes d'interface supportées par le mobile T et par ledit dispositif de gestion DSG,
- une commande de recherche FETCH permettant de chercher une commande d'interface, d'un troisième groupe de commandes, provenant d'une deuxième carte C2 et de l'envoyer au mobile,
- une commande de réponse TERMINALRESPONSE permettant d'envoyer, à partir du mobile vers une deuxième carte C2, une réponse provenant de l'exécution de la commande d'interface précédemment envoyée,
- une commande d'indication d'événement ENVELOPE permettant d'envoyer à partir du mobile T vers une deuxième carte C2 un événement (sélection d'un menu, réception d'un message) .... Le troisième groupe de commandes (non représenté) comporte notamment des commandes d'interface envoyées par une carte, appelées dans le standard GSM 1 1. 14 commandes proactives, telles que : - une commande d'affichage DISPLAYTEXT d'un message sur l'écran du terminal, une commande de saisie de texte GETINPUT sur le clavier du terminal, une commande d'envoi de message SENDSMS au réseau de télécommunication....
Au moyen de l'application interactive « mobile banking » A3 se trouvant sur la deuxième carte C2, un utilisateur du mobile va, par exemple, pouvoir consulter un solde de son compte bancaire sur l'écran de son mobile. On suppose que l'utilisateur a programmé une exécution automatique de l'application interactive A3 toutes les douze heures à partir d'un temps TO, afin d'avoir automatiquement toutes les douze heures l'affichage de son solde à l'écran de son mobile.
Avant d'exécuter ladite application A3 on effectue préalablement les étapes suivantes montrées à la figure 4 : - une première étape S I d'information de la première carte C l de la présence de ladite au moins deuxième carte C2, - une deuxième étape S2 d'activation de ladite au moins deuxième carte C2.
Lors de la première étape S I , lorsqu'au moins une deuxième carte C2 est connectée au mobile T, on envoie une commande d'information au moyen du mobile T vers la première carte C l permettant de renseigner le dispositif de gestion DSG de la première carte C l sur l'état de ladite au moins deuxième carte C2. Par exemple, on envoie la commande appelée « Envelope (EventDownLoad(CardreaderStatus)» décrite dans la norme GSM 1 1. 14. Lors de la deuxième étape S2, on active la deuxième carte C2 en envoyant une commande d'activation à partir de la première carte Cl au moyen du dispositif de gestion DSG, par exemple on envoie la commande appelée « PowerOnCard » décrite dans la norme GSM 1 1. 14. Par suite, la deuxième carte C2 envoie une réponse d'activation audit mobile T, appelée couramment dans le langage anglo-saxon « answer to reset ». On notera que si deux deuxièmes cartes sont connectées dans un mobile, on active chaque carte par ordre de connexion dans ledit mobile T. Lorsque la deuxième carte C2 est connectée et activée, au moyen du dispositif de gestion DSG, on effectue les étapes suivantes montrées à la figure 5 :
- une troisième étape S3 selon laquelle on vérifie si ladite au moins application interactive de la deuxième carte C2 est supportée par le dispositif de gestion DSG, une quatrième étape S4 selon laquelle on informe ladite deuxième carte C2 relativement notamment aux commandes d'interface et événements supportés par le mobile T et par le dispositif de gestion DSG, - une cinquième étape S5 selon laquelle on sélectionne, si nécessaire, une application interactive dans la deuxième carte C2,
- une sixième étape S6 selon laquelle on scrute périodiquement ladite deuxième carte C2 afin de vérifier périodiquement si une commande de l'application interactive est en attente d'être envoyée, - une septième étape S7 selon laquelle on recherche une commande, provenant de l'application interactive de la deuxième carte C2, en attente d'être envoyée,
- une huitième étape S8 selon laquelle on réceptionne et on sauvegarde la commande envoyée à partir de la deuxième carte C2, - une neuvième étape S9 selon laquelle, on envoie au mobile T et on exécute dans ledite mobile la commande provenant de la deuxième carte C2,
- une dixième étape S 10 selon laquelle on sauvegarde une réponse d'exécution de commande issue du mobile T suite à l'exécution de ladite commande, une onzième étape S U selon laquelle on envoie ladite réponse à ladite deuxième carte C2, une douzième étape S 12 selon laquelle on recherche la commande en attente dans la deuxième carte C2 et ainsi de suite.
Dans la troisième étape S3, on vérifie grâce aux moyens de vérification d'applications M l du dispositif de gestion DSG si l'application interactive « mobile banking » A3 de la carte C2 est supportée par le dispositif de gestion DSG. Par exemple, le dispositif de gestion DSG comporte une liste d'identifiants L_AID uniques associés aux applications interactives qu'il peut gérer. Dans un premier mode de réalisation, si la deuxième carte C2 comporte plusieurs applications interactives, elle comporte une liste des identifiants desdites applications interactives. Pour chaque application interactive, on vérifie si on retrouve l'identifiant AID de l'application interactive de la deuxième carte C2 dans la liste L_AID dudit dispositif DSG. Dans un autre mode de réalisation, si la deuxième carte C2 ne comporte qu'une application interactive, simultanément à l'envoi d'une réponse d'activation (« answer to reset ») au mobile T, on envoie l'identifiant de ladite application. La vérification se fait sur cet identifiant.
Dans la quatrième étape, on indique, grâce aux moyens d'information M2, à la deuxième carte C2, les commandes d'interface et les événements supportés par ledit mobile T et par le dispositif de gestion DSG. A cet fin, on encapsule dans la commande applicative d'envoi de commande PERFORMCARDAPDU la commande de propriété TERMINALPROFILE. Ladite commande applicative
PERFORMCARDAPDU comporte des paramètres PAR sauvegardés après qu'une commande de propriété TERMINALPROFILE a été envoyée précédemment par le mobile T à la première carte C l . Les paramètres PAR sont fonction des commandes d'interface et événement supportés par le mobile T. Préalablement à la sauvegarde des paramètres dans la première carte C l , grâce à des moyens d'adaptation de paramètres (non représenté), on adapte lesdits paramètres PAR en fonction également du dispositif de gestion DSG. Ainsi, lesdits paramètres PAR sont également fonction des commandes d'interface et événements supportés par le dispositif de gestion DSG. Dans un mode de réalisation non limitatif, chaque commande supportée est représentée par un élément binaire à un. Une commande non supportée est représentée par un élément binaire à zéro. On envoie ladite commande applicative PERFORMCARDAPDU, encapsulant la commande de propriété TERMINALPROFILE, de la première carte C l au mobile T. Le mobile envoie par la suite la commande de propriété TERMINALPROFILE à ladite deuxième carte C2. La commande est exécutée dans la carte et la carte est adaptée en fonction des paramètres vus précédemment. On évite ainsi que ladite deuxième carte C2 fasse appel à une commande non supportée par ledit mobile T ou ledit dispositif de gestion DSG.
Optionnellement, dans une cinquième étape S5, grâce aux moyens de sélection M3 du dispositif de gestion DSG, on sélectionne une application interactive se trouvant sur la deuxième carte C2. Dans un mode de réalisation non limitatif, l'application sélectionnée est celle sélectionnée par l'utilisateur, par exemple au moyen d'une commande d'indication d'événement ENVELOPE(MENUSELECTION) décrite dans le standard GSM 1 1. 14. Cette cinquième étape n'est pas nécessaire lorsque l'identifiant de l'application interactive a été envoyé en même temps que la réponse d'activation (« answer to reset »), comme vu précédemment, car l'application est sélectionnée automatiquement par défaut. Dans la sixième étape S6, grâce aux moyens de scrutation périodique M4, on envoie périodiquement une commande d'état STATUS à partir du mobile T vers la deuxième carte C2 afin de vérifier si une commande interactive n'est pas en attente d'être envoyée. A cette fin, on effectue les étapes suivantes comme montrées à la figure 6 : - une première commande d'état STATUS est envoyée à partir du mobile T à la première carte C l et sauvegardée dans un tampon mémoire, lorsque la première carte C l est inactive c'est à dire qu'aucune opération n'est en cours d'exécution, un indicateur d'état 91XA, indiquant qu'une commande est en attente d'être envoyée par la première carte C l , est envoyé à partir du dispositif de gestion DSG au mobile T, la commande de recherche de commande FETCH est envoyée du mobile à la carte C 1 afin de rechercher la commande en attente de la première carte C l dont une longueur XA a été indiquée dans l'indicateur d'état 91XA, la commande recherchée étant la commande applicative d'envoi de commande PERFORMCARDAPDU encapsulant la commande d'état STATUS, par suite, la commande applicative d'envoi de commande PERFORMCARDAPDU est envoyée à partir du dispositif de gestion
DSG au mobile T, ladite commande encapsulant la commande d'état STATUS sauvegardée auparavant dans le tampon mémoire, - l'envoi de la commande d'état STATUS par le mobile T à la deuxième carte C2 est déclenché, et, - la commande d'état STATUS est exécutée dans la deuxième carte C2. Dans le cadre de notre application « mobile banking » permettant la consultation du solde d'un compte, lorsqu'on a atteint douze heures après le temps TO, à ce moment, la deuxième carte C2 comportant ladite application interactive envoie comme réponse un indicateur d'état 91XB indiquant qu'une commande d'interface est en attente d'être envoyée, la commande en attente étant, dans notre exemple, une commande de saisie de numéro de compte GETINPUT_NB de longueur XB.
Dans la septième étape S7 montrée à la figure 6, on recherche la commande en attente comme suit : le mobile T transfère la réponse de la deuxième carte en envoyant à la première carte C l la commande de réponse TERMINALRESPONSE ayant pour paramètre l'indicateur d'état 91XB, un indicateur d'état 91XC, indiquant qu'une commande est en attente d'être envoyée par la première carte C l , est envoyé à partir du dispositif de gestion DSG au mobile T,
- la commande de recherche de commande FETCH est envoyée du mobile à la carte C 1 afin de rechercher la commande en attente de la première carte C l , la commande recherchée étant la commande applicative d'envoi de commande PERFORMCARDAPDU encapsulant une autre commande de recherche de commande FETCH 1 ,
- la commande applicative d'envoi de commande PERFORMCARDAPDU est envoyée à partir du dispositif de gestion DSG au mobile T, - par suite, l'envoi de la commande de recherche FETCH 1 par le mobile T à la deuxième carte C2 est déclenché afin de rechercher la commande de saisie de numéro de compte GETINPUTJMB de longueur XB, et,
- la commande de saisie de numéro de compte GETINPUT_NB est envoyée en réponse à la commande de recherche FETCH 1 , Dans la huitième étape, le dispositif de gestion DSG reçoit la commande et la sauvegarde selon les étapes suivantes : le mobile transfère la réponse de la deuxième carte en envoyant à la première carte Cl la commande de réponse TERMINALRESPONSE ayant pour paramètre la commande de saisie GETINPUT_NB, la commande de saisie est sauvegardée dans un tampon mémoire.
Dans la neuvième étape, la commande de saisie de l'application interactive est envoyée au mobile et exécutée comme suit :
- un indicateur d'état 91XD, indiquant qu'une commande est en attente d'être envoyée par la première carte C l , est envoyé à partir du dispositif de gestion DSG au mobile T, la commande de recherche de commande FETCH est envoyée du mobile à la carte C 1 afin de rechercher la commande en attente de la première carte Cl , la commande recherchée étant la commande de saisie GETINPUT_NB de longueur XD, la commande de saisie est récupérée dans le tampon mémoire, et, la commande de saisie GETINPUT_NB est envoyée au mobile T, la commande de saisie provenant de la deuxième carte C2 est exécutée dans le mobile T. L'exécution de la commande de saisie GETINPUT se traduit par un affichage d'un message à l'écran du mobile invitant l'utilisateur à entrer le numéro de son compte NB.
Lorsque l'utilisateur a tapé le numéro de son compte NB au clavier de son mobile, la dixième étape est effectuée de la manière suivante : - le mobile T transfère la réponse de la commande de saisie GETINPUT JMB en envoyant au dispositif de gestion DSG la commande de réponse TERMINALRESPONSE ayant pour paramètre le numéro NB du compte tapé,
- la réponse qui est le numéro de compte tapé est sauvegardée dans un tampon mémoire. Dans la onzième étape, sur réception de la réponse, le dispositif de gestion DSG envoie le numéro de compte NB à la deuxième carte selon les étapes suivantes :
- un indicateur d'état 91XE, indiquant qu'une commande est en attente d'être envoyée par la première carte C l , est envoyé à partir du dispositif de gestion DSG au mobile T, la commande de recherche de commande FETCH est envoyée du mobile à la carte C 1 afin de rechercher la commande en attente de la première carte C l , la commande recherchée étant la commande applicative d'envoi de commande PERFORMCARDAPDU encapsulant la commande de réponse TERMINALRESPONSE ayant comme paramètre le numéro de compte NB, la commande applicative d'envoi de commande
PERFORMCARDAPDU est envoyée à partir du dispositif de gestion DSG au mobile T, la deuxième carte reçoit la réponse qui est le numéro de compte NB.
Avec le numéro de compte bancaire, on doit maintenant interroger un serveur de la banque comportant le solde dudit compte bancaire.
Pour se faire, une autre commande de l'application interactive « mobile banking » de la deuxième carte C2 doit être envoyée. La commande en attente d'être envoyée est cette fois-ci un message d'interrogation
SENDSMS à envoyer via le réseau de communication au serveur de la banque.
Aussi, dans la douzième étape S 12, comme il est montré à la figure 7, on recherche ladite commande en attente dans la deuxième carte conformément à la septième étape vue précédemment. Le dispositif de gestion DSG reçoit le message d'interrogation SENDSMS et l'envoie au mobile T, conformément à la huitième étape décrite précédemment. La commande d'interrogation est exécutée dans le mobile T. L'exécution de la commande se traduit par un envoi du message au serveur de la banque via le réseau de communication. Le serveur envoie une réponse d'acquittement de message DR au mobile T, qui conformément à la dixième étape décrite l'envoie au dispositif de gestion DSG. Sur réception de la réponse, le dispositif de gestion DSG envoie le message d'acquittement DR à la deuxième carte C2 conformément à la onzième étape. La deuxième carte C2 envoie un indicateur d'état 9000 indiquant qu'aucune autre commande n'est en attente d'être envoyée.
Par la suite, le serveur envoie le solde du numéro compte NB sur l'interface écran du mobile T. On notera que certaines commandes provenant d'une application interactive d'une deuxième carte C2, peuvent affecter le fonctionnement d'applications interactives se trouvant sur la première carte C l . Par exemple, une commande d'insertion de menu SETUPMENU provenant de la deuxième carte C2. Cette commande permet d'insérer un menu dans un menu système du terminal T qui apparaît sur l'écran S. La commande fait appel à différents identifiants ITEM_ID correspondants à de services que l'utilisateur pourra choisir dans le menu. Si l'application interactive de la première carte C l comporte également un menu et des identifiants, il risque d'y avoir un mélange entre les différents identifiants des différents menus interactifs. Aussi, le dispositif de gestion DSG comporte des moyens de renumérotation d'identifiants en fonction du menu sélectionné et du service sélectionné.
Ainsi, l'objet de la présente invention permet une gestion d'applications interactives diverses et variées se trouvant sur une deuxième carte C2 coopérant avec ledit terminal T, et, notamment permet à toute deuxième carte C2 d'avoir aussi bien accès aux interface écran/ clavier du terminal en vue d'établir un dialogue avec un utilisateur, qu'à des serveurs distants via une interface réseau auquel le terminal est connecté. Selon ce qui précède, l'objet de la présente invention présente de nombreux avantages aussi bien pour le fournisseur de service que pour le fournisseur de la carte comportant le dispositif de gestion, par exemple un opérateur. En particulier, un premier avantage de l'objet de la présente invention se trouve dans le fait qu'une adaptation de l'application interactive du fournisseur par rapport aux cartes de chaque nouvel opérateur n'est plus nécessaire, puisque celle-ci se trouve dans la carte dudit fournisseur de service. Le fournisseur n'est plus dépendant des caractéristiques des premières cartes et un degré de sécurité suffisant est respecté pour ses applications.
Pour l'opérateur, la présente invention comporte un avantage selon lequel il n'est plus obligé de produire des cartes comportant une grande capacité mémoire. De plus, il n'est plus obligé de supporter une administration des différentes applications des fournisseurs de service ce qui simplifie la gestion de ses cartes. Un autre avantage est que l'opérateur n'a plus à définir un mécanisme de chargement d'applications de fournisseurs dans ses cartes après la mise en circulation desdites cartes. Un tel mécanisme se fait généralement au moyen de serveurs connectés au réseau dudit opérateur. Par suite, grâce à la présente invention, l'opérateur n'a plus à gérer ces applications au moyen de son réseau, ce qui auparavant créait une surcharge dudit réseau.
Bien entendu, la présente invention s'applique à tout autre application, autre qu'une application bancaire, telle qu'une application de fidélité, qui implique une interaction entre au moins deux objets portatifs et un terminal.

Claims

REVENDICATIONS
1 - Microcontrôleur destiné à être incorporé dans un premier objet portatif (C l), notamment au format carte, coopérant avec un terminal (T), caractérisé en ce qu'il comprend un dispositif de gestion (DSG) d'applications d'un deuxième objet portatif (C2), ledit deuxième objet portatif (C2) comportant au moins une application interactive (A3) comprenant des commandes d'interface et des données permettant une interaction avec au moins une interface dudit terminal, ledit dispositif (DSG) étant apte à gérer des échanges de données et une exécution desdites commandes d'interface entre ledit terminal (T) et ledit deuxième objet portatif (C2).
2 - Microcontrôleur selon la revendication 1 , caractérisé en ce que le terminal (T) avec lequel il coopère est un mobile.
3 - Microcontrôleur selon l'une quelconque des revendications 1 ou 2, caractérisé en ce que le dispositif de gestion (DSG) comporte des moyens d'aiguillage et d'exécution (M) de commande d'application interactive. 4 - Microcontrôleur selon la revendication 3, caractérisé en ce que lesdits moyens d'aiguillage et d'exécution de commande (M) comprennent :
- des moyens de recherche de commande d'interface (M5) étant aptes à rechercher une commande d'interface, provenant de l'application interactive du deuxième objet portatif (C2), en attente d'être envoyée,
- des moyens de réception et de sauvegarde de commande d'interface (M6) étant aptes à réceptionner et à sauvegarder la commande d'interface envoyée à partir du deuxième objet portatif (C2), - des moyens d'envoi et d'exécution de commande d'interface (M7) étant aptes à envoyer et à exécuter dans le terminal (T) la commande d'interface provenant du deuxième objet portatif (C2) , - des moyens de sauvegarde de réponse d'exécution de commande d'interface (M8) étant aptes à sauvegarder une réponse d'exécution de commande d'interface issue du terminal (T) suite à l'exécution de ladite commande d'interface.
- des moyens d'envoi de réponse (M9) étant aptes à envoyer ladite réponse audit deuxième objet portatif (C2).
5 - Microcontrôleur selon l'une quelconque des revendications précédentes 1 à 4, caractérisé en ce que le dispositif de gestion comporte en outre : des moyens de vérification d'application (M l) étant aptes à vérifier si ladite au moins application interactive du deuxième objet portatif (C2) est supportée par le dispositif de gestion (DSG),
- des moyens d'information (M2) étant apte à informer le deuxième objet portatif (C2) relativement aux commandes d'interface et à des événements supportés par le terminal (T) et par le dispositif de gestion (DSG),
- des moyens de sélection d'application (M3) étant aptes à sélectionner ladite au moins application interactive du deuxième objet portatif (C2), - des moyens de scrutation périodique (M4) du deuxième objet portatif (C2) étant aptes à vérifier périodiquement si une commande d'interface de ladite application interactive est en attente d'être envoyée.
6 - Microcontrôleur selon l'une quelconque des revendications précédentes 1 à 5, caractérisé en ce que le dispositif de gestion (DSG) comporte en outre une commande applicative d'envoi de commande (PERFORMCARDAPDU).
7 - Microcontrôleur selon la revendication 6, caractérisé en ce que ladite commande applicative d'envoi de commande (PERFORMCARDAPDU) est apte à encapsuler une commande.
8 - Microcontrôleur selon la revendication 6, caractérisé en ce que la commande applicative d'envoi de commande (PERFORMCARDAPDU) est apte à encapsuler au moins une commande appartenant à un groupe de commandes de gestion de protocole.
9 - Microcontrôleur selon la revendication 6, caractérisé en ce que ladite commande applicative (PERFORMCARDAPDU) d'envoi de commande est apte à déclencher, d'une part, l'envoi de la commande encapsulée dudit terminal (T) audit deuxième objet portatif (C2) , et, d'autre part, l'exécution de ladite commande dans ledit deuxième objet (C2), lorsqu'elle (PERFORMCARDAPDU) est envoyée du premier objet portatif (C l) audit terminal (T) par le dispositif de gestion (DSG) .
10 - Microcontrôleur selon les revendications précédentes 4 et 6, caractérisé en ce que les moyens de recherche de commande (M5) et les moyens d'envoi de réponse (M9) comprennent ladite commande applicative d'envoi de commande
(PERFORMCARDAPDU) .
11 - Microcontrôleur selon les revendications précédentes 5 et 6, caractérisé en ce que les moyens d'information (M2), les moyens de sélection (M3) et les moyens de scrutation périodique (M4) du deuxième objet portatif (C2) comprennent ladite commande applicative d'envoi de commande (PERFORMCARDAPDU).
12 - Microcontrôleur selon l'une quelconque des revendications précédentes 1 à 1 1 , caractérisé en ce que ledit deuxième objet portatif (C2) comporte toutes les données (DATA) , y compris des données secrètes, relatives à ladite au moins application interactive (A3) .
13 - Microcontrôleur selon l'une quelconque des revendications précédentes 1 à 12, caractérisé en ce que ledit premier objet portatif (C l) est une carte à circuit intégré.
14 - Microcontrôleur selon l'une quelconque des revendications précédentes 1 à 13, caractérisé en ce que ledit deuxième objet portatif (C2) est une carte à circuit intégré. 15 - Procédé de gestion d'applications à partir d'un microcontrôleur destiné à être incorporé dans un premier objet portatif (C l), notamment au format carte, coopérant avec un terminal (T), caractérisé en ce qu'il gère des échanges de données et une exécution de commandes d'interface entre ledit terminal (T) et un deuxième objet portatif (C2) au moyen d'un dispositif de gestion d'applications (DSG) compris dans ledit microcontrôleur, ledit deuxième objet portatif (C2) comportant au moins une application interactive (A3) comprenant lesdites commandes d'interface et lesdites données permettant une interaction avec au moins une interface dudit terminal (T).
16 - Procédé selon la revendication 15, caractérisé en ce que le terminal (T) avec lequel le microcontrôleur coopère est un mobile.
17 - Procédé selon l'une quelconque des revendications précédentes 15 ou 16, caractérisé en ce qu'il comporte une étape d'aiguillage et d'exécution de commande d'application interactive effectuée au moyen du dispositif de gestion (DSG).
18 - Procédé selon la revendication 17, caractérisé en ce que l'étape d'aiguillage et d'exécution de commande comprend les étapes selon lesquelles : on recherche une commande d'interface, provenant de l'application interactive du deuxième objet portatif (C2), en attente d'être envoyée, on réceptionne et on sauvegarde la commande d'interface envoyée à partir du deuxième objet portatif (C2), on envoie au terminal et on exécute dans ledit terminal (T) la commande d'interface provenant du deuxième objet portatif (C2), on sauvegarde une réponse d'exécution de commande d'interface issue du terminal (T) suite à l'exécution de ladite commande, on envoie ladite réponse audit deuxième objet portatif (C2).
19 - Procédé selon l'une quelconque des revendications précédentes 15 à 18, caractérisé en ce qu'il comporte en outre des étapes supplémentaires selon lesquelles : on vérifie si ladite au moins application interactive de la deuxième carte (C2) est supportée par le dispositif de gestion
(DSG), on informe le deuxième objet portatif (C2) relativement notamment aux commandes et événements supportés par le terminal (T) et par le dispositif de gestion (DSG), on sélectionne, si nécessaire, une application interactive de la deuxième carte (C2), on scrute périodiquement ledit deuxième objet portatif (C2) afin de vérifier périodiquement si une commande d'interface de ladite application interactive (A3) est en attente d'être envoyée,
20 - Procédé selon l'une quelconque des revendications précédentes 15 à 19, caractérisé en ce que le dispositif de gestion (DSG) comporte en outre une commande applicative d'envoi de commande (PERFORMCARDAPDU). 21 - Procédé selon la revendication 20, caractérisé en ce qu'il comporte une étape supplémentaire selon laquelle : - on encapsule une commande dans la commande applicative d'envoi de commande (PERFORMCARDAPDU). 22 - Procédé selon la revendication 20, caractérisé en ce qu'il comporte les étape supplémentaire selon lesquelles : en envoyant ladite commande applicative
(PERFORMCARDAPDU) d'envoi de commande, du premier objet portatif (Cl) audit terminal (T) au moyen du dispositif de gestion (DSG), on déclenche l'envoi de la commande encapsulée dudit terminal audit deuxième objet portatif (C2), et, on déclenche l'exécution de ladite commande dans ledit deuxième objet (C2).
23 - Procédé selon la revendication 20, caractérisé en ce qu'il comporte une étape supplémentaire selon laquelle : on encapsule au moins une commande appartenant à un groupe de commandes de gestion de protocole.
24 - Procédé selon les revendications précédentes 18 et 20, caractérisé en ce que les étapes de recherche de commande et d'envoi de réponse utilisent ladite commande applicative d'envoi de commande (PERFORMCARDAPDU).
25 - Procédé selon les revendications précédentes 19 et 20, caractérisé en ce que les étapes d'information, de sélection et de scrutation périodique du deuxième objet portatif (C2) utilisent ladite commande applicative d'envoi de commande
(PERFORMCARDAPDU) .
26 - Procédé selon l'une quelconque des revendications précédentes 15 à 25, caractérisé en ce que ledit deuxième objet portatif (C2) comporte toutes les données (DATA), y compris des données secrètes, relatives à ladite au moins application interactive.
27 - Procédé selon l'une quelconque des revendications précédentes 15 à 26, caractérisé en ce que ledit premier objet portatif (C l) est une carte à circuit intégré.
28 - Procédé selon l'une quelconque des revendications 15 à 27, caractérisé en ce que ledit deuxième objet portatif (C2) est une carte à circuit intégré.
EP01907717A 2000-02-07 2001-02-06 Microcontroleur et procede pour la gestion d'applications interactives Withdrawn EP1256066A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0001502A FR2804769B1 (fr) 2000-02-07 2000-02-07 Microcontroleur et procede pour la gestion d'applications interactives
FR0001502 2000-02-07
PCT/FR2001/000351 WO2001057699A2 (fr) 2000-02-07 2001-02-06 Microcontroleur et procede pour la gestion d'applications interactives

Publications (1)

Publication Number Publication Date
EP1256066A2 true EP1256066A2 (fr) 2002-11-13

Family

ID=8846730

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01907717A Withdrawn EP1256066A2 (fr) 2000-02-07 2001-02-06 Microcontroleur et procede pour la gestion d'applications interactives

Country Status (3)

Country Link
EP (1) EP1256066A2 (fr)
FR (1) FR2804769B1 (fr)
WO (1) WO2001057699A2 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2771205A1 (fr) * 1997-11-20 1999-05-21 Gemplus Card Int Procede, carte a puce et terminaux pour effectuer des transactions a travers un reseau de telecommunication

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI104223B1 (fi) * 1996-12-17 1999-11-30 Nokia Mobile Phones Ltd Menetelmä SIM-kortin ohjauskomentojen välittämiseksi ulkopuoliselta laitteelta SM-kortille

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2771205A1 (fr) * 1997-11-20 1999-05-21 Gemplus Card Int Procede, carte a puce et terminaux pour effectuer des transactions a travers un reseau de telecommunication

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Digital cellular telecommunications system (Phase 2+); Specification of the SIM Application Toolkit for the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface (GSM 11.14 version 7.3.1 Release 1998); TS 101 267", IEEE, LIS, SOPHIA ANTIPOLIS CEDEX, FRANCE, vol. 3-T3;SMG9, no. V7.3.1, 1 July 1999 (1999-07-01), XP014015913, ISSN: 0000-0001 *
ROB HUGHES: "HARDWARE PREVIEW Aten MiniView KVM Switch CS-14", 1999, Retrieved from the Internet <URL:http://www.geek.com/hwswrev/hardware/mvkvm/mvkvm.htm> [retrieved on 20100930] *
See also references of WO0157699A3 *

Also Published As

Publication number Publication date
FR2804769A1 (fr) 2001-08-10
FR2804769B1 (fr) 2002-03-22
WO2001057699A3 (fr) 2001-12-20
WO2001057699A2 (fr) 2001-08-09

Similar Documents

Publication Publication Date Title
EP0932317B1 (fr) Procédé de transfert d&#39;information chiffrée entre un module d&#39;identification d&#39;abonné et un terminal mobile radio
EP1032925B1 (fr) Procede, carte a puce et terminaux pour effectuer des transactions a travers un reseau de telecommunication
EP2143053B1 (fr) Procédé de communication et de transmission d&#39;un message concernant une transaction d&#39;une application sans contact, terminal, module sécurisé et système associés
WO2002065414A1 (fr) Procede et systeme de telepaiement
EP1050145A1 (fr) Carte a puce, telephone sans fil, systeme et procede d&#39;acces et de communication par internet
FR2767437A1 (fr) Procede ameliore de chargement d&#39;une liste predeterminee d&#39;articles par un terminal mobile pilote par un module d&#39;identification d&#39;abonne, commande, module d&#39;identification d&#39;abonne et terminal mobile correspondants
FR2702323A1 (fr) Procédé pour délivrer un numéro de téléphone associé à un abonnement téléphonique, postes téléphoniques et téléphone mobile mettant en Óoeuvre ce procédé.
WO2007077119A1 (fr) Cle electronique generique munie d&#39;une carte a puce personnalisee
EP0896490B1 (fr) Procédé d&#39;adaptation du fonctionnement d&#39;un module d&#39;identification d&#39;abonné à une ou des interface(s) d&#39;un terminal mobile de radio-communication, module d&#39;identification d&#39;abonné et terminal mobile correspondants
EP1059824B1 (fr) Procédé d&#39;autorisation d&#39;accès à un réseau cellulaire de radiocommunications à partir d&#39;un téléphone mobile, système de radiocommunications et téléphone simplifié associés
FR2821231A1 (fr) Procede d&#39;administration d&#39;une carte d&#39;abonne pour un equipement de telephonie mobile du type a lecteur auxiliaire et systeme embarque pour la mise en oeuvre du procede
WO2002098146A2 (fr) Procede de mise a jour d&#39;un fichier d&#39;informations personnelles dans les appareils mobiles de reseaux de communications
FR2983027A1 (fr) Procede de selection d&#39;une application dans un terminal, et terminal mettant en oeuvre ce procede
WO2001065480A1 (fr) Procede de commande d&#39;une carte a puce
EP1064769A1 (fr) Terminal de telecommunication lecteur de carte a puce
WO2007071832A1 (fr) Exploitation d&#39;informations proprietaires transmises par un reseau de radiocommunications a un terminal mobile sous le controle d&#39;une carte a puce
WO2019016470A1 (fr) Procédé et système de gestion d&#39;un paiement par porte-monnaie électronique
EP1256066A2 (fr) Microcontroleur et procede pour la gestion d&#39;applications interactives
EP1179959B1 (fr) Procédé d&#39;exécution de plusieurs services au cours d&#39;un appel téléphonique
EP1556833B2 (fr) Jeu de cartes à microcircuit prédécoupées dans un même support plastique et comportant des fonctions complémentaires
EP3876096A1 (fr) Procédé mis en oeuvre dans un module à circuit intégré, module à circuit intégré correspondant, système comportant un tel module et programme d&#39;ordinateur associé
EP1588252B1 (fr) Procede et systeme de transfert de donnees entre des bornes publiques interactives et des terminaux personnels
EP2306414A1 (fr) Procédé de communication entre un lecteur et deux cartes à puce
WO2007026002A1 (fr) Execution d&#39;une commande pro-active elaboree dans un terminal
WO2001020565A1 (fr) Systeme et methode de chargement de donnees dans une carte a puce a travers un reseau de telecommunication au moyen de mels

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020829

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

RBV Designated contracting states (corrected)

Designated state(s): FR GB

REG Reference to a national code

Ref country code: DE

Ref legal event code: 8566

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: AXALTO S.A.

17Q First examination report despatched

Effective date: 20080314

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GEMALTO SA

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RIC1 Information provided on ipc code assigned before grant

Ipc: H04W 88/02 20090101AFI20120903BHEP

Ipc: G06F 15/78 20060101ALI20120903BHEP

Ipc: G06F 9/46 20060101ALI20120903BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20130213