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

Microcontroleur et procede pour la gestion d'applications interactives Download PDF

Info

Publication number
WO2001057699A2
WO2001057699A2 PCT/FR2001/000351 FR0100351W WO0157699A2 WO 2001057699 A2 WO2001057699 A2 WO 2001057699A2 FR 0100351 W FR0100351 W FR 0100351W WO 0157699 A2 WO0157699 A2 WO 0157699A2
Authority
WO
WIPO (PCT)
Prior art keywords
command
portable object
terminal
card
application
Prior art date
Application number
PCT/FR2001/000351
Other languages
English (en)
Other versions
WO2001057699A3 (fr
Inventor
Tarik Slassi
Christian Dietrich
Original Assignee
Schlumberger Systemes
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 filed Critical Schlumberger Systemes
Priority to EP01907717A priority Critical patent/EP1256066A2/fr
Publication of WO2001057699A2 publication Critical patent/WO2001057699A2/fr
Publication of WO2001057699A3 publication Critical patent/WO2001057699A3/fr

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

  • the present invention relates to a microcontroller intended to be incorporated into a portable object, in particular in card format called an integrated circuit card, cooperating with a terminal. It also relates to a method for managing applications of such a microcontroller.
  • the invention finds a particularly advantageous application in the field of telephony.
  • the terminal is a portable telephone called a mobile generally comprising a screen and a keyboard. Said mobile cooperates with the integrated circuit card called a SIM card.
  • the latter is provided by a telecommunications operator managing a telecommunications network and allows a mobile user access to said network.
  • An integrated circuit card consists of a card body in which the microcontroller is incorporated. The latter comprises at least one application called “toolkit” application based on a communication protocol called “toolkit” protocol described in the GSM 1 1. 1 1 and GSM 1 1. 14 standards published by ETSI.
  • a “toolkit” application includes commands which are sent to the mobile and which allow, for example, to display text on the mobile screen, to send messages to a server through said telecommunications network, to make automatic phone calls without entering a number. Said commands thus allow interaction with interfaces of said mobile such as the keyboard, the screen or the network.
  • This second card can be used by a service provider, for example a bank. It comprises a microcontroller comprising a banking application making it possible to carry out known banking transaction or electronic purse services.
  • the microcontroller of the first card comprises a toolkit application relating to said banking services, associated commands as well as data necessary for the execution of said services such as a secret key value allowing a secure exchange of data or a bank account number .
  • This toolkit application is generally provided by the service provider to the operator. The latter puts it on his first card. In the toolkit application, we use the “Multiple
  • This device still has many other drawbacks, such as: sharing of supplier data between the first card and the second card.
  • data of the service provider being in the microcontroller of the first card of the operator, the latter must guarantee a service provider a sufficient degree of confidentiality of this data commonly comprising secret data and this by performing, generally, a security evaluation on its own first card, an evaluation which is long, complex and very costly, an adaptation of an application from a service provider to each new set of first cards from each new operator.
  • a microcontroller of a set of first cards of an operator generally has different characteristics from a microcontroller of another set of first cards of the same operator or another operator.
  • the supplier's application must be adapted according to each set of first cards of a given operator, which results in cumbersome application management,
  • a technical problem to be solved by the object of the present invention is to propose a microcontroller intended to be incorporated into a portable object, in particular in card format, cooperating with a terminal, as well as a method for managing applications of '' such a microcontroller, which would allow, on the one hand, to manage at least one second portable object of a service provider, and, on the other hand, to allow an exchange of communications between said second portable object and said terminal while overcoming the various drawbacks mentioned above.
  • a solution to the technical problem posed is characterized, according to a first object of the present invention, in that said microcontroller comprises a device for managing interactive applications of a second portable object, said second portable object comprising at least one interactive application comprising interface commands and data allowing interaction with at least one interface of said terminal, said device being capable of managing data exchanges and an execution of said interface commands between said terminal and said second portable object.
  • this solution is characterized in that the application management method manages data exchanges and an execution of interface commands between said terminal and a second portable object by means of a device. for managing interactive applications included in said microcontroller, said second portable object comprising at least one interactive application comprising said interface commands and said data allowing interaction with at least one interface of said terminal.
  • the device of the invention makes it possible to manage at least one interactive application from a supplier which is recorded directly in a microcontroller said second portable object and no longer in the first microcontroller of the first portable object.
  • the latter thus has access to the keyboard / screen / network interfaces of the terminal, the first microcontroller comprising the management device serving only as an intermediary in the communications between the terminal and the microcontroller of the second portable object.
  • Figure 1 is a diagram of a microcontroller incorporated in a first portable object according to the invention, for example, an integrated circuit card.
  • Figure 2 is a diagram of the microcontroller of Figure 1, a second microcontroller of a second portable object and a terminal.
  • FIG. 3 is another diagram of the microcontroller of the first portable object, of the second microcontroller of the second portable object and of the terminal of FIG. 2.
  • FIG. 4 is a first communication diagram 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. 5 is a second 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. 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.
  • FIG. 1 a first microcontroller incorporated in a first card C l with an integrated circuit.
  • This microcontroller MC 1 comprises a control element 1 1 (for example a central processing unit or CPU), a rewritable non-volatile memory 12, a non rewritable non volatile memory 13, and a block of contacts 14 intended for an electrical connection / electromagnetic with, for example, a connector of a contact / contactless card reader placed in a terminal T.
  • the microcontroller MC I also comprises a device for managing DSG interactive applications of an integrated circuit card and a first application A l.
  • the first card C l is preferably inserted in the terminal T.
  • the DSG device can be located in non-volatile non-rewritable memory 13 or in non-volatile rewritable memory 12.
  • M of interactive application It further comprises the following means: - application verification means M l being able to verify whether said at least interactive application A3 of the second portable object C2 is supported by the management device DSG, information means M2 being able to inform the second portable object C2 relatively in particular with respect to the commands and events supported by the terminal T and by the management device DSG, application selection means M3 being able to select said at least interactive application A3 of the second portable object C2 ,
  • the DSG management device comprises an application command for sending the PERFORMCARDAPDU command to the second card C2.
  • the information means M2, the selection means M3 and the periodic scanning means M4 of the second portable object C2 comprise said application command command sending PERFORMCARDAPDU.
  • the terminal T comprises a screen interface S, a keyboard interface K and a network interface N. It is able to cooperate with a second card C2 with integrated circuit. This second card C2 can be inserted or not in the terminal T. It includes a MC2 microcontroller comprising a second application A2 and at least one interactive application A3.
  • a card contains the applications instead of saying that the microcontroller of the card contains the applications and we will talk about the DSG management device of the first card C l instead of talking about the DSG management device of the microcontroller of the first card C l.
  • 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).
  • the first application A1 is, for example, a standard telephone application allowing an exchange of communications with the mobile T and with the communication network. It is preferably found in the non-volatile non-rewritable memory 13 of the microcontroller MC I of the first card C l.
  • the second application A2 is, for example, a standard banking application commonly used to manage banking transaction operations with a bank terminal. It is preferably found in the non-volatile non-rewritable memory 13 of the second card C2.
  • the interactive application A3 is, for example, a mobile banking application commonly called in the English language "mobile banking”. It is preferably in memory 12 no volatile rewritable from the second card C2. Thus, the bank if it wishes can modify its A3 application without constraints.
  • Said interactive application A3 uses DATA data and more particularly secret data such as a bank account number NB.
  • the second card C2 includes all the DATA data, including the secret data, relating to said interactive application A3.
  • Said data and are consequently known neither from the first card C l, nor from the other second cards C2 which could come to cooperate with the mobile.
  • the DATA data is preferably found in the rewritable non-volatile memory 12.
  • the interactive A3 application allows interaction with at least one mobile interface. It is managed by means of the management device DSG of the first card C l which administers data exchanges and an execution of commands from the interactive application A3 between said mobile T and said at least second card C2.
  • the DSG management device located in a first card C l has the advantage that an operator can use his first card C l in any terminal that can communicate with his card. It will not be dependent on a given terminal provider. Thanks to the referral and command execution means M of the DSG management device, at least one command from the interactive application A3 of said second card C2 is directed to the mobile T, said command is executed in said mobile T and we send a response from mobile T to this same card C2. Likewise, thanks to these means, at least one command is referred from said mobile T to said second card C2, said command is executed in said second card C2 and a response is sent from said second card C2 to said mobile T.
  • the switching means M of the management device DSG comprise the following means: interface command search means M5 being able to search for an interface command, coming from the interactive application of the second card C2, waiting to be sent, - means for receiving and saving an interface command M6 being able to receive and save the interface command sent from the second card C2, means for sending and of executing an interface command M7 being able to send and executing in the mobile T the interface command coming from the second card C2, means for saving the response of executing an interface command M8 being able to save an interface command execution response from the mobile T following the execution of said command, response sending means M9 being able to send said response to the second card C2.
  • the command search means M5 and the response sending means M9 include said application command command sending PERFORMCARDAPDU.
  • Said PERFORMACARAPDU application command is able to encapsulate an order.
  • it is capable of triggering, on the one hand, the sending of the encapsulated command from said mobile to said second card C2, and, on the other hand, the execution of said command in said second card C2, when it is sent from the first C card to the audit mobile T by the DSG management device.
  • the PERFORMCARDAPDU command sending command is able to encapsulate at least one command belonging to a group of protocol management commands. Preferably, commands belonging to two different groups can be encapsulated (not shown).
  • the first group of commands notably comprises commands sent by the mobile T, called simple commands, such as: a STATUS state command giving a second card C2 the means of indicating to the DSG management device that a command command d the interface is waiting to be sent, a selection command, a data update command, etc.
  • the second group of commands notably comprises protocol management commands, called in the GSM 11 standard. 14 toolkit commands and toolkit protocol, such as:
  • a TERMINALPROFILE property command making it possible in particular to indicate to a second card C2 which interface commands are supported by the mobile T and by said DSG management device,
  • 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
  • a TERMINALRESPONSE response command making it possible to send, from the mobile to a second card C2, a response originating from the execution of the interface command previously sent,
  • the third group of commands (not shown) notably includes interface commands sent by a card, called in the GSM 11 1 standard. 14 proactive commands, such as: - a command to display DISPLAYTEXT of a message on the screen of the terminal, a command to enter text GETINPUT on the keyboard of the terminal, a command to send a SENDSMS message to the telecommunications network ...
  • a mobile user By means of the interactive “mobile banking” A3 application located on the second card C2, a mobile user will, for example, be able to consult a balance of their bank account on the screen of their mobile. It is assumed that the user has programmed an automatic execution of the interactive application A3 every twelve hours from a TO time, in order to automatically have the display of his balance on the sound screen every twelve hours. mobile.
  • an information command is sent by means of the mobile T to the first card C l making it possible to inform the management device DSG of the first card C l on the state of said at least second card C2.
  • the command called "Envelope (EventDownLoad (CardreaderStatus)” described in the GSM 1114 standard.
  • the second card C2 is activated by sending an activation command from the first card C1 by means of the DSG management device, for example the command called “PowerOnCard” described in the GSM standard is sent 1 1. 14.
  • a third step S3 according to which it is checked whether said at least interactive application of the second card C2 is supported by the management device DSG, a fourth step S4 according to which one informs said second card C2 relatively in particular with interface commands and events supported by the mobile T and by the management device DSG, a fifth step S5 according to which an interactive application is selected, if necessary, in the second card C2,
  • step S6 according to which said second card C2 is periodically scanned in order to periodically check whether a command from the interactive application is waiting to be sent
  • step S7 a seventh step S7 according to which a command is sought from the interactive application of the second card C2, waiting to be sent
  • a tenth step S 10 according to which a command execution response from the mobile T is saved following the execution of said command, an eleventh step SU according to which said response is sent to said second card C2, a twelfth step S 12 according to which the pending command is searched for in the second card C2 and so on.
  • the DSG management device includes a list of unique L_AID identifiers associated with the interactive applications that it can manage.
  • the second card C2 includes several interactive applications, it includes a list of identifiers of said interactive applications.
  • the identifier AID of the interactive application of the second card C2 is found in the list L_AID of said DSG device.
  • the second card C2 only has an interactive application, simultaneously with the sending of an activation response (“answer to reset”) to the mobile T, the identifier of said said is sent application. The verification is done on this identifier.
  • the second card C2 indicates the interface commands and the events supported by said mobile T and by the management device DSG.
  • the property command is encapsulated in the application command sending command PERFORMCARDAPDU TERMINALPROFILE. Said application command
  • PERFORMCARDAPDU has PAR parameters saved after a TERMINALPROFILE property command was previously sent by the mobile T to the first card C l.
  • the PAR parameters are a function of the interface and event commands supported by the mobile T. Prior to saving the parameters in the first card C l, by means of parameter adaptation means (not shown), said PAR parameters are adapted also based on the DSG management system. Thus, said PAR parameters are also a function of interface commands and events supported by the DSG management device.
  • each supported command is represented by a binary element to one.
  • An unsupported command is represented by a binary element at zero.
  • Said application command PERFORMCARDAPDU is sent, encapsulating the TERMINALPROFILE property command, from the first card C 1 to the mobile T.
  • the mobile subsequently sends the TERMINALPROFILE property command to said second card C2.
  • the command is executed in the card and the card is adapted according to the parameters seen previously. This prevents said second card C2 from calling on a command not supported by said mobile T or said DSG management device.
  • a fifth step S5 using the selection means M3 of the management device DSG, an interactive application is selected which is located on the second card C2.
  • the application selected is that selected by the user, for example by means of an event indication command ENVELOPE (MENUSELECTION) described in the GSM 1114 standard.
  • ENVELOPE MENUSELECTION
  • This fifth step is not necessary when the identifier of the interactive application was sent at the same time as the activation response ("answer to reset"), as seen previously, because the application is automatically selected by default .
  • a status command STATUS is sent periodically from the mobile T to the second card C2 in order to check whether an interactive command is not waiting to be sent .
  • a first STATUS state command is sent from the mobile T to the first card C l and saved in a memory buffer, when the first card C l is inactive, i.e.
  • a 91XA status indicator indicating that a command is waiting to be sent by the first card C l, is sent from from the DSG management device to the mobile T
  • the FETCH command search command is sent from the mobile to the card C 1 in order to search for the command awaiting the first card C l whose length XA has been indicated in the indicator d 'state 91XA, the command sought being the application command to send the PERFORMCARDAPDU command encapsulating the STATUS state command, consequently, the application command to send the PERFORMCARDAPDU command is sent from the management device
  • the pending command is sought as follows: the mobile T transfers the response from the second card by sending the response command TERMINALRESPONSE having the indicator d as a parameter to the first card C l state 91XB, a state indicator 91XC, indicating that a command is waiting to be sent by the first card C l, is sent from the management device DSG to the mobile T,
  • the FETCH command search command is sent from the mobile to the card C 1 in order to search for the command awaiting the first card C l, the command sought being the application command command sending command PERFORMCARDAPDU encapsulating another search command FETCH 1 command,
  • the PERFORMCARDAPDU command sending application command is sent from the DSG management device to the mobile T, - consequently, the sending of the FETCH 1 search command by the mobile T to the second card C2 is triggered in order to find the command for entering the GETINPUTJMB account number of length XB, and,
  • the DSG management device receives the command and saves it according to the following steps: the mobile transfers the response from the second card by sending to the first card C1 the response command TERMINALRESPONSE having as parameter the input command GETINPUT_NB , the input command is saved in a memory buffer.
  • the command to enter the interactive application is sent to the mobile and executed as follows:
  • a status indicator 91XD indicating that a command is waiting to be sent by the first card C l, is sent from the management device DSG to the mobile T
  • the command search command FETCH is sent from mobile to card C 1 in order to search for the command awaiting the first card Cl, the command sought being the input command GETINPUT_NB of length XD, the input command is retrieved from the memory buffer, and, the input command GETINPUT_NB is sent to the mobile T, the input command coming from the second card C2 is executed in the mobile T.
  • the execution of the GETINPUT input command results in a message being displayed on the screen of the mobile inviting the user to enter their NB account number.
  • the tenth step is carried out as follows: - the mobile T transfers the response from the GETINPUT JMB input command by sending the DSG management device the response command TERMINALRESPONSE having as parameter the NB number of the account entered,
  • the DSG management device sends the account number NB to the second card according to the following steps:
  • a status indicator 91XE indicating that a command is waiting to be sent by the first card C l, is sent from the management device DSG to the mobile T
  • the command search command FETCH is sent from mobile to the card C 1 in order to search for the command awaiting the first card C l
  • the command sought being the application command for sending the PERFORMCARDAPDU command encapsulating the response command TERMINALRESPONSE having as parameter the account number NB, the command order sending application
  • PERFORMCARDAPDU is sent from the DSG management device to mobile T, the second card receives the response which is the account number NB.
  • SENDSMS to send via the communication network to the bank's server.
  • said command pending is searched for in the second card in accordance with the seventh step seen previously.
  • the DSG management device receives the SENDSMS interrogation message and sends it to the mobile T, in accordance with the eighth step described above.
  • the interrogation command is executed in the mobile T.
  • the execution of the command results in a sending of the message to the server of the bank via the communication network.
  • the server sends a message acknowledgment response DR to the mobile T, which in accordance with the tenth step described sends it to the management device DSG.
  • the management device DSG sends the acknowledgment message DR to the second card C2 in accordance with the eleventh step.
  • the second card C2 sends a status indicator 9000 indicating that no other command is waiting to be sent.
  • 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.
  • the object of the present invention allows management of various and varied interactive applications located on a second card C2 cooperating with said terminal T, and, in particular allows any second card C2 to have access to the screen interface as well / terminal keyboard in order to establish a dialogue with a user, only to remote servers via a network interface to which the terminal is connected.
  • the object of the present invention has numerous advantages both for the service provider and for the provider of the card comprising the management device, for example an operator.
  • a first advantage of the subject of the present invention lies in the fact that an adaptation of the interactive application of the supplier with respect to the cards of each new operator is no longer necessary, since this is found in the card of said service provider. The supplier is no longer dependent on the characteristics of the first cards and a sufficient degree of security is respected for its applications.
  • the present invention has an advantage according to which he is no longer obliged to produce cards comprising a large memory capacity. In addition, it is no longer obliged to support administration of the various applications of service providers, which simplifies the management of its cards.
  • Another advantage is that the operator no longer has to define a mechanism for loading supplier applications into his cards after the circulation of said cards. Such a mechanism is generally done by means of servers connected to the network of said operator. As a result, thanks to the present invention, the operator no longer has to manage these applications by means of his network, which previously created an overload of said network.
  • the present invention applies to any other application, other than a banking application, such as a loyalty application, which involves an interaction between at least two portable objects and a terminal.

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é.
PCT/FR2001/000351 2000-02-07 2001-02-06 Microcontroleur et procede pour la gestion d'applications interactives WO2001057699A2 (fr)

Priority Applications (1)

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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR00/01502 2000-02-07
FR0001502A FR2804769B1 (fr) 2000-02-07 2000-02-07 Microcontroleur et procede pour la gestion d'applications interactives

Publications (2)

Publication Number Publication Date
WO2001057699A2 true WO2001057699A2 (fr) 2001-08-09
WO2001057699A3 WO2001057699A3 (fr) 2001-12-20

Family

ID=8846730

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2001/000351 WO2001057699A2 (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
WO1998027767A1 (fr) * 1996-12-17 1998-06-25 Nokia Mobile Phones Limited Procede pour amener les instructions de commandes d'une carte sim depuis un dispositif externe a une carte sim

Family Cites Families (1)

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

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998027767A1 (fr) * 1996-12-17 1998-06-25 Nokia Mobile Phones Limited Procede pour amener les instructions de commandes d'une carte sim depuis un dispositif externe a une carte sim

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1256066A2 *

Also Published As

Publication number Publication date
FR2804769A1 (fr) 2001-08-10
EP1256066A2 (fr) 2002-11-13
FR2804769B1 (fr) 2002-03-22
WO2001057699A3 (fr) 2001-12-20

Similar Documents

Publication Publication Date Title
EP0932317B1 (fr) Procédé de transfert d'information chiffrée entre un module d'identification d'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'un message concernant une transaction d'une application sans contact, terminal, module sécurisé et système associés
EP1360665A1 (fr) Procede et systeme de telepaiement
EP1050145A1 (fr) Carte a puce, telephone sans fil, systeme et procede d'acces et de communication par internet
FR2767437A1 (fr) Procede ameliore de chargement d'une liste predeterminee d'articles par un terminal mobile pilote par un module d'identification d'abonne, commande, module d'identification d'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é.
FR2785135A1 (fr) Procede de lancement d'une application par un terminal, sous commande d'un module d'identification d'abonne, module d'identification d'abonne et terminal correspondants
WO2007077119A1 (fr) Cle electronique generique munie d'une carte a puce personnalisee
EP0896490B1 (fr) Procédé d'adaptation du fonctionnement d'un module d'identification d'abonné à une ou des interface(s) d'un terminal mobile de radio-communication, module d'identification d'abonné et terminal mobile correspondants
EP1059824B1 (fr) Procédé d'autorisation d'accès à un réseau cellulaire de radiocommunications à partir d'un téléphone mobile, système de radiocommunications et téléphone simplifié associés
FR2821231A1 (fr) Procede d'administration d'une carte d'abonne pour un equipement de telephonie mobile du type a lecteur auxiliaire et systeme embarque pour la mise en oeuvre du procede
EP1397927A2 (fr) Procede de mise a jour d'un fichier d'informations personnelles dans les appareils mobiles de reseaux de communications
FR2983027A1 (fr) Procede de selection d'une application dans un terminal, et terminal mettant en oeuvre ce procede
WO2001065480A1 (fr) Procede de commande d'une carte a puce
EP1064769A1 (fr) Terminal de telecommunication lecteur de carte a puce
EP1967023A1 (fr) Exploitation d'informations proprietaires transmises par un reseau de radiocommunications a un terminal mobile sous le controle d'une carte a puce
WO2019016470A1 (fr) Procédé et système de gestion d'un paiement par porte-monnaie électronique
WO2001057699A2 (fr) Microcontroleur et procede pour la gestion d'applications interactives
EP1179959B1 (fr) Procédé d'exécution de plusieurs services au cours d'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'ordinateur associé
EP2306414A1 (fr) Procédé de communication entre un lecteur et deux cartes à puce
WO2007026002A1 (fr) Execution d'une commande pro-active elaboree dans un terminal
FR2819909A1 (fr) Procede pour la creation de fichiers de donnees, prives securises et carte a puce comportant un fichier prive securise

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): BR CN JP US

AL Designated countries for regional patents

Kind code of ref document: A2

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): BR CN JP US

AL Designated countries for regional patents

Kind code of ref document: A3

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

WWE Wipo information: entry into national phase

Ref document number: 2001907717

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2001907717

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP