EP1256066A2

EP1256066A2 - Microcontroller and method for managing interactive applications

Info

Publication number: EP1256066A2
Application number: EP01907717A
Authority: EP
Inventors: Tarik Slassi; Christian Dietrich
Original assignee: Schlumberger Systemes SA
Current assignee: Axalto SA
Priority date: 2000-02-07
Filing date: 2001-02-06
Publication date: 2002-11-13
Also published as: FR2804769A1; FR2804769B1; WO2001057699A3; WO2001057699A2

Abstract

The invention concerns a microcontroller designed to be incorporated in a first portable object, in particular having a card format, co-operating with a terminal. The invention is characterised in that the microcontroller comprises a device for managing interactive applications of a second portable object, said second portable object comprising at least an interactive application including interface commands and data enabling interaction with at least an interface of said terminal, said device being capable of managing data exchanges and executing said interface commands between said terminal and said second portable object. The invention is particularly applicable to the field of mobile telephone systems.

Description

MICROCONTROLLER AND METHOD FOR MANAGEMENT

INTERACTIVE APPLICATIONS

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.

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.

Using the toolkit applications and thanks to a functionality called in English language “Multiple Card” defined in the GSM standard 1.14, it is also possible to send a second card to integrated circuit connected to the mobile, by sending commands to said second card from the microcontroller of the first card.

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 bank may want to make some of these services available on a mobile, such as viewing the status of a bank account or a bank transfer. Also, in order to allow access to a mobile user of said services offered by the bank, according to a device known from the state of the art and disclosed in said GSM standard 11. 14, 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

Card ”to allow in particular to execute in the microcontroller of the second card commands such as a reading of bank account number, number which is subsequently transferred to the first card. In the device described above there then arises the problem of access to the interfaces of the terminal by means of the microcontroller of the second card. Indeed, by means of the second card, one cannot communicate directly with the terminal. Only the first card can directly communicate with the terminal and access the keyboard / screen / network interfaces of the terminal using the "toolkit" communication. As a result, only a first card can access, via said terminal, remote servers such as a server of the service provider comprising for example data relating to the bank account number. It would be interesting if the second card could also communicate directly with the terminal.

This device still has many other drawbacks, such as: sharing of supplier data between the first card and the second card. Indeed, 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. Also, the supplier's application must be adapted according to each set of first cards of a given operator, which results in cumbersome application management,

- an obligation for an operator to provide a card comprising a microcontroller comprising a large memory capacity for storing all the applications of all the service providers. Also, 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.

According to a second object of the present invention, 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.

Thus, as will be seen in detail below, 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. Is sent and executed, thanks to the management device, interface commands from said interactive application of said second portable object to said terminal or commands from said terminal to said second 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. The description which follows with regard to the appended drawings, given by way of nonlimiting examples, will make it clear what the invention consists of and how it can be implemented.

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. The present description of the invention relates to the example of the cards with integrated circuit. By 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. However, it is understood that 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.

In Figure 1 is shown 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.

It includes means of referral and execution of command

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 ,

- Periodic scanning means M4 of the second portable object C2 being able to periodically check whether an interface command from said interactive application A3 is waiting to be sent. Finally, the DSG management device comprises an application command for sending the PERFORMCARDAPDU command to the second card C2. As will be seen below, 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.

As shown in FIG. 2, 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.

To simplify the description, we will say that 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. Likewise, for example, we will speak of a command executed in a card while knowing that the command is executed in the microcontroller of the card. Finally, we will talk about either card cooperating with the terminal or microcontroller cooperating with the mobile.

In the example of FIG. 3, 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 and 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. As a result, data security and independence are preserved. Thus an operator will not have to guarantee to a service provider a sufficient degree of confidentiality of the data in particular secret of said provider and consequently will not need to carry out a security evaluation on his own first card C l. 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. Note that 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.

To this end, 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. In addition, 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,

a 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,

- an ENVELOPE event indication command making it possible to send an event (selection of a menu, reception of a message) from the mobile T to a second card C2. 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 ...

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.

Before executing said application A3, the following steps shown in FIG. 4 are carried out beforehand: - a first step SI of informing the first card C l of the presence of said at least second card C2, - a second step S2 d activation of said at least second card C2.

During the first step SI, when at least a second card C2 is connected to the mobile T, 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. For example, we send the command called "Envelope (EventDownLoad (CardreaderStatus)" described in the GSM 1114 standard. During the second step S2, 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. Consequently, the second card C2 sends an activation response to said mobile T, commonly called in the English language "answer to reset". It will be noted that if two second cards are connected in a mobile, each card is activated in order of connection in said mobile T. When the second card C2 is connected and activated, by means of the DSG management device, the following steps are shown: in Figure 5:

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,

- a sixth 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, - a seventh step S7 according to which a command is sought from the interactive application of the second card C2, waiting to be sent,

an eighth step S8 according to which the command sent from the second card C2 is received and saved, a ninth step S9 according to which, the mobile T is sent and the command coming from the second card C2 is executed in the said mobile,

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.

In the third step S3, it is checked using the application verification means M l of the DSG management device whether the interactive “mobile banking” application A3 of the card C2 is supported by the DSG management device. For example, the DSG management device includes a list of unique L_AID identifiers associated with the interactive applications that it can manage. In a first embodiment, if the second card C2 includes several interactive applications, it includes a list of identifiers of said interactive applications. For each interactive application, it is checked whether the identifier AID of the interactive application of the second card C2 is found in the list L_AID of said DSG device. In another embodiment, if 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.

In the fourth step, thanks to the information means M2, the second card C2 indicates the interface commands and the events supported by said mobile T and by the management device DSG. To this end, 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. In a nonlimiting embodiment, 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.

Optionally, in 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. In a non-limiting embodiment, 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. 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 . In the sixth step S6, thanks to the periodic scanning means M4, 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 . To this end, the following steps are carried out as shown in FIG. 6: - 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. no operation is in progress, 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

DSG to mobile T, said command encapsulating the STATUS state command previously saved in the memory buffer, - the sending of the STATUS state command by mobile T to the second card C2 is triggered, and, - the command d STATUS state is executed in the second card C2. Within the framework of our “mobile banking” application allowing the consultation of the balance of an account, when one has reached twelve hours after the time TO, at this moment, the second card C2 comprising said interactive application sends as an answer an indicator of 'state 91XB indicating that an interface command is waiting to be sent, the pending command being, in our example, a command to enter account number GETINPUT_NB of length XB.

In the seventh step S7 shown in FIG. 6, 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 command to enter the account number GETINPUT_NB is sent in response to the search command FETCH 1, In the eighth step, 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.

In the ninth step, 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.

When the user has typed the number of his NB account on the keypad of his mobile, 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 response which is the account number entered is saved in a memory buffer. In the eleventh step, on receipt of the response, 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.

With the bank account number, we must now interrogate a server of the bank containing the balance of said bank account.

To do this, another order from the interactive mobile banking application of the second C2 card must be sent. The command waiting to be sent is this time a query message

SENDSMS to send via the communication network to the bank's server.

Also, in the twelfth step S 12, as shown in FIG. 7, 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. On receipt of the response, 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.

Thereafter, the server sends the balance of the account number NB on the screen interface of the mobile T. It will be noted that certain 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. For example, 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. If 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. Also, the DSG management device includes means for renumbering identifiers according to the menu selected and the service selected.

Thus, 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. According to the above, 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. In particular, 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.

For the operator, 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.

Of course, 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.

Claims

1 - Microcontroller intended to be incorporated into a first portable object (C l), in particular in card format, cooperating with a terminal (T), characterized in that it comprises a device for managing (DSG) applications of a second portable object (C2), said second portable object (C2) comprising at least one interactive application (A3) comprising interface commands and data allowing interaction with at least one interface of said terminal, said device (DSG) being suitable managing data exchanges and an execution of said interface commands between said terminal (T) and said second portable object (C2).

2 - Microcontroller according to claim 1, characterized in that the terminal (T) with which it cooperates is a mobile.

3 - Microcontroller according to any one of claims 1 or 2, characterized in that the management device (DSG) comprises switching and execution means (M) of interactive application control. 4 - Microcontroller according to claim 3, characterized in that the said control switching and execution means (M) comprise:

- interface command search means (M5) being able to search for an interface command, coming from the interactive application of the second portable object (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 portable object (C2), - interface command sending and execution means (M7) being able to send and execute in the terminal (T) the interface command originating from the second portable object (C2), - backup means of an interface command execution response (M8) being able to save an interface command execution response coming from the terminal (T) following the execution of said interface command.

- response sending means (M9) being able to send said response to said second portable object (C2).

5 - Microcontroller according to any one of the preceding claims 1 to 4, characterized in that the management device further comprises: application verification means (M l) being able to verify whether said at least interactive application 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) relative to the interface commands and to 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 of the second portable object (C2), - periodic scanning means (M4) of the second portable object (C2) being able to periodically check whether an interface command of said interactive application is waiting to be sent.

6 - Microcontroller according to any one of the preceding claims 1 to 5, characterized in that the management device (DSG) also includes an application command to send commands (PERFORMCARDAPDU).

7 - Microcontroller according to claim 6, characterized in that said application command sending command (PERFORMCARDAPDU) is able to encapsulate an order.

8 - Microcontroller according to claim 6, characterized in that the application command sending command (PERFORMCARDAPDU) is able to encapsulate at least one command belonging to a group of protocol management commands.

9 - Microcontroller according to claim 6, characterized in that said application command (PERFORMCARDAPDU) of command sending is capable of triggering, on the one hand, the sending of the encapsulated command from said terminal (T) to said second portable object ( C2), and, on the other hand, the execution of said command in said second object (C2), when it (PERFORMCARDAPDU) is sent from the first portable object (C l) to said terminal (T) by the management device (DSG).

10 - Microcontroller according to the preceding claims 4 and 6, characterized in that the command search means (M5) and the response sending means (M9) comprise said application command sending command

(PERFORMCARDAPDU).

11 - Microcontroller according to the preceding claims 5 and 6, characterized in that the information means (M2), the selection means (M3) and the periodic scanning means (M4) of the second portable object (C2) comprise said command order sending application (PERFORMCARDAPDU).

12 - Microcontroller according to any one of the preceding claims 1 to 1 1, characterized in that said second object portable (C2) includes all the data (DATA), including secret data, relating to said at least interactive application (A3).

13 - Microcontroller according to any one of the preceding claims 1 to 12, characterized in that said first portable object (C l) is an integrated circuit card.

14 - Microcontroller according to any one of the preceding claims 1 to 13, characterized in that said second portable object (C2) is an integrated circuit card. 15 - Method for managing applications from a microcontroller intended to be incorporated into a first portable object (C l), in particular in card format, cooperating with a terminal (T), characterized in that it manages exchanges data and an execution of interface commands between said terminal (T) and a second portable object (C2) by means of an application management device (DSG) included in said microcontroller, said second portable object (C2) comprising at least one interactive application (A3) comprising said interface commands and said data allowing interaction with at least one interface of said terminal (T).

16 - Method according to claim 15, characterized in that the terminal (T) with which the microcontroller cooperates is a mobile.

17 - Method according to any one of the preceding claims 15 or 16, characterized in that it comprises a referral and execution step of interactive application command carried out by means of the management device (DSG).

18 - Method according to claim 17, characterized in that the referral and order execution step comprises the steps according to which: we search for an interface command, coming from the interactive application of the second portable object (C2), waiting to be sent, we receive and save the interface command sent from the second portable object (C2), the terminal is sent to the terminal and the interface command from the second portable object (C2) is executed in said terminal (T), an interface command execution response from the terminal (T) is saved following execution of said command, said response is sent to said second portable object (C2).

19 - Method according to any one of the preceding claims 15 to 18, characterized in that it also comprises additional steps according to which: it is checked whether said at least interactive application of the second card (C2) is supported by the device Management

(DSG), the second portable object (C2) is informed relative in particular to the commands and events supported by the terminal (T) and by the management device (DSG), we select, if necessary, an interactive application of the second card ( C2), said second portable object (C2) is periodically scanned in order to periodically check whether an interface command of said interactive application (A3) is waiting to be sent,

20 - Method according to any one of the preceding claims 15 to 19, characterized in that the management device (DSG) further comprises an application command sending command (PERFORMCARDAPDU). 21 - Method according to claim 20, characterized in that it comprises an additional step according to which: - an order is encapsulated in the application command for sending the command (PERFORMCARDAPDU). 22 - Method according to claim 20, characterized in that it comprises the additional steps according to which: by sending said application command

(PERFORMCARDAPDU) for sending an order, from the first portable object (Cl) to said terminal (T) by means of the management device (DSG), the sending of the encapsulated command from said terminal is triggered to said second portable object (C2), and, the execution of said command is triggered in said second object (C2).

23 - Method according to claim 20, characterized in that it comprises an additional step according to which: at least one command belonging to a group of protocol management commands is encapsulated.

24 - Method according to the preceding claims 18 and 20, characterized in that the steps of order search and response sending use said application command command sending (PERFORMCARDAPDU).

25 - Method according to the preceding claims 19 and 20, characterized in that the steps of information, selection and periodic scanning of the second portable object (C2) use said application command command sending

(PERFORMCARDAPDU).

26 - Method according to any one of the preceding claims 15 to 25, characterized in that said second portable object (C2) comprises all the data (DATA), including secret data, relating to said at least interactive application.

27 - Method according to any one of the preceding claims 15 to 26, characterized in that said first portable object (C l) is an integrated circuit card.

28 - Method according to any one of claims 15 to 27, characterized in that said second portable object (C2) is an integrated circuit card.