FR3015718A1 - Procede de test et de mise a jour du systeme d'un terminal par un module d'identite de souscripteur et dispositifs associes - Google Patents

Abstract

La présente invention concerne un procédé de mise à jour des fonctionnalités du système d'exploitation d'un terminal requises pour le bon fonctionnement d'applications embarquées au sein d'un module d'identité de souscripteur après d'un opérateur de réseau de télécommunications. Le module d'identité de souscripteur teste les commandes. Si certaines commandes sont non fonctionnelles, le module d'identité de souscripteur envoie des informations sur le logiciel installé sur le terminal et sur les commandes non fonctionnelles à un serveur distant. Celui-ci analyse ces informations et fournit une unité de mise à jour du logiciel du terminal au besoin. Cette unité de mise à jour est reçue par le module d'identité de souscripteur qui déclenche la mise à jour du terminal. Les applications nécessitant ces commandes sont ainsi rendues opérationnelles.

Description

15 7 1 8 1 La présente invention concerne le domaine des télécommunications. Elle est notamment relative à un procédé de mise à jour des fonctionnalités du système d'exploitation d'un terminal requises pour le bon fonctionnement d'applications embarquées au sein d'un module d'identité de souscripteur après d'un opérateur de réseau de télécommunications.

Un module d'identité de souscripteur est un composant électronique destiné à stocker de manière sécurisée l'identité internationale d'un abonné à un réseau de téléphonie mobile. Ce module d'identité de souscripteur peut prendre la forme d'une carte à puce dédiée appelée UICC (Universal Integrated Circuit Card en anglais), intégrant une application SIM et/ou USIM (Universal Subscriber Identity Module en anglais) dans le cadre du réseau UMTS (Universal Mobile Telecommunications System en anglais). Il peut également s'agir d'un module d'identité de souscripteur embarqué, directement intégré au sein du terminal de communication. Ce composant peut, par exemple, être soudé sur la carte mère du terminal, indépendamment du processeur principal. Il est alors dénommé eU ICC (embedded Universal Integrated Circuit Card en anglais). Un module d'identité de souscripteur répond généralement à la norme ISO/IEC 7816, aux normes Critères Communs, au standard GlobalPlatform Card Specification v 2.2.1, et/ou au standard ETSI TS 103 383 v12.0.0. Ce module d'identité de souscripteur peut héberger des applications, parfois dénommées applets, pouvant s'exécuter en son sein et communiquer avec le terminal contenant le module d'identité de souscripteur et/ou à travers celui-ci avec des services distants.

Les terminaux de communication dont il est question sont typiquement des terminaux de téléphonie mobile. Toutefois, les terminaux de communication intégrant un tel module d'identité de souscripteur sont aujourd'hui beaucoup plus divers. Il peut s'agir d'une tablette ou d'un ordinateur intégrant la capacité de connexion à un réseau de téléphonie mobile ou encore tout dispositif de traitement de l'information, par exemple dans le cadre d'un système de communication de machine à machine M2M (Machine to Machine en anglais).

En effet, de tels dispositifs sont dotés d'une unité de téléphonie mobile leur permettant de communiquer avec d'autres dispositifs, typiquement des serveurs distants, ou d'autres dispositifs M2M. Par exemple, les automobiles peuvent aujourd'hui être dotées de tels dispositifs permettant de donner automatiquement l'alerte en cas de détection d'un accident.

Les modules d'identité de souscripteur sont typiquement gérés par les opérateurs de réseaux de télécommunication. Leurs capacités de calcul augmentent régulièrement. Les opérateurs hébergent au sein de ces modules d'identité de souscripteur un nombre toujours plus grand d'applications. Ces applications peuvent être des applications de gestion de l'abonné, des applications bancaires ou encore des applications de surveillance du réseau qui permettent à l'opérateur de recueillir des données de couverture de son réseau par exemple.

Certaines applications peuvent fonctionner de manière autonome au sein du module d'identité de souscripteur. D'autres requièrent au contraire la coopération du terminal pour leur fonctionnement. Cette coopération prend typiquement la forme d'échanges de messages APDU (Application Protocol Data Unit en anglais) entre l'application mise en oeuvre dans le module d'identité de souscripteur et des unités logicielles exécutées sur le terminal. Les unités logicielles ainsi sollicitées sur le terminal par le module d'identité de souscripteur sont situées sur l'une quelconque des couches logicielles du système mis en oeuvre par le terminal.

Par la suite, nous utilisons le terme « logiciel embarqué sur le terminal » pour désigner l'ensemble des programmes informatiques mis en oeuvre par le terminal. Il peut s'agir d'une unité de type micro-logiciel (firmware en anglais), 3015 718 3 c'est-à-dire d'un ensemble d'instructions et de structures de données intégrées dans un composant électronique pour qu'il puisse fonctionner ou d'une unité de type logiciel composée d'un ensemble d'au moins un programme et de données pour le rendre opérationnel. Ainsi, le logiciel embarqué sur le terminal désigne 5 le système d'exploitation du terminal, ses librairies, les éventuelles applications pouvant être installées « au-dessus » de ce système d'exploitation, et/ou les pilotes informatiques (drivers en anglais). Par exemple, une application de surveillance de réseau du module 10 d'identité de souscripteur peut collaborer avec les unités de gestion de l'interface radio du terminal pour acquérir les informations de puissance de signal associées aux cellules traversées. Ces informations sont transmises par le module d'identité de souscripteur à l'opérateur qui les analyse et peut ainsi surveiller le niveau de couverture de son réseau de télécommunications. 15 La communication entre le module d'identité de souscripteur et le terminal est couverte par des normes et des standards, en particulier la norme ISO/IEC 7816-4 dans laquelle sont définis les messages ou commandes de type APDU. Sur cette base, la norme GSM 11.14 définit un ensemble de 20 commandes proactives STK (Sim ToolKit en anglais) qui désignent les actions contrôlées par le module d'identité de souscripteur et exécutées par le terminal. Cette norme a été remplacée par la norme 3GPP 31.111 (3rd Generation Partnership Project en anglais) dans les réseaux de troisième génération. Logiquement, les applications développées pour être exécutées sur le module 25 d'identité de souscripteur utilisent ces commandes STK pour leurs interactions avec le terminal. La configuration des systèmes des terminaux varie selon les constructeurs. Or il se trouve que les constructeurs de terminaux 30 n'implémentent pas systématiquement l'ensemble des commandes définies dans les standards. De ce fait, les applications utilisant de telles commandes non implémentées sont non fonctionnelles dans de tels terminaux. L'opérateur ne peut donc pas déployer une application impliquant une interaction avec le terminal en étant sûr qu'elle fonctionne sur un ensemble de terminaux dont les configurations peuvent varier. Il est également possible que des commandes soient implémentées par une unité logicielle du terminal, mais que la version mise en oeuvre par le terminal soit incompatible avec celle attendue par le module d'identité de souscripteur. La présente invention a pour but de résoudre les inconvénients précités. Il est proposé un procédé de test et de mise à jour du terminal. Le module d'identité de souscripteur teste les commandes, par exemple les commandes STK utilisées par les applications hébergées au sein de ce module d'identité de souscripteur. Il s'agit de tester soit toutes les commandes mises en oeuvre par le module, soit uniquement une liste de commandes préalablement déterminée et enregistrée dans une mémoire non volatile du module d'identité de souscripteur. Si certaines commandes sont non fonctionnelles, par exemple parce qu'elles ne sont pas implémentées par le terminal, ou que le terminal ne dispose pas de l'interface correspondante, ou qu'il y a une incompatibilité entre la version de la commande générée par le module et la version attendue par le terminal, le module d'identité de souscripteur envoie des informations sur le logiciel installé sur le terminal et sur les commandes non fonctionnelles à un serveur distant. Celui-ci analyse ces informations et fournit une unité de mise à jour du logiciel du terminal au besoin. Cette unité de mise à jour, par la suite dénommée « mise à jour » est reçue par le module d'identité de souscripteur qui déclenche la mise à jour du terminal. Cette mise à jour apporte par exemple le support des commandes STK préalablement non fonctionnelles. Les applications nécessitant ces commandes sont ainsi rendues opérationnelles. L'invention concerne un procédé de mise à jour des fonctionnalités du logiciel embarqué par un terminal de communication contenant un module d'identité de souscripteur hébergeant au moins une application nécessitant pour son exécution au moins une commande implémentée par ledit terminal, caractérisé en ce qu'il comprend par le module d'identité de souscripteur : une étape de test des commandes nécessaires à l'exécution de la au moins une application hébergée par ledit module d'identité de souscripteur ; et dans le cas où au moins une de ces commandes est manquante dans une version requise par les applications hébergées : une étape d'obtention d'une unité de mise à jour du logiciel embarqué par le terminal ; et en réponse à l'étape d'obtention, une étape de déclenchement de la mise à jour du logiciel embarqué par le terminal, ladite mise à jour étant faite par le terminal par l'installation (5.10) de ladite unité de mise à jour.

Selon un mode particulier de réalisation de l'invention, lesdites commandes sont des commandes proactives STK. Selon un mode particulier de réalisation de l'invention, ladite étape de test est déclenchée par le démarrage du terminal.

Selon un mode particulier de réalisation de l'invention, ladite étape de test est déclenchée par l'insertion dans le terminal d'un nouveau module d'identité de souscripteur ou par l'insertion dans le terminal d'une carte mémoire ou en réponse à une requête émise par un serveur distant ou par l'utilisateur, à destination du module d'identité de souscripteur. Selon un mode particulier de réalisation de l'invention, ladite étape de déclenchement de la mise à jour du logiciel embarqué par le terminal déclenche la mise à jour par le terminal de l'une des couches dudit logiciel. Selon un mode particulier de réalisation de l'invention, l'étape d'obtention d'une unité de mise à jour comprend : une étape d'envoi d'une requête à un serveur distant, ladite requête comprenant au moins des résultats du test de la mise en oeuvre par le terminal des commandes nécessaires à l'exécution des applications hébergées par le module d'identité de souscripteur ; et une étape de réception de ladite unité de mise à jour transmise par ledit serveur distant.

Selon un mode particulier de réalisation de l'invention, lesdits résultats du test de la mise en oeuvre des commandes comprennent un statut obtenu en réponse au test. Selon un mode particulier de réalisation de l'invention, le procédé comporte en outre : une étape d'obtention d'informations de configuration du terminal ; et où la requête à un serveur distant comprend également ces informations obtenues. Selon un mode particulier de réalisation de l'invention, ladite unité de mise à jour est contenue dans une mémoire non volatile accessible par ledit module d'identité de souscripteur. 15 Selon un mode particulier de réalisation de l'invention, ladite mémoire non volatile est contenue dans une carte mémoire insérée dans le terminal. Selon un mode particulier de réalisation de l'invention, ladite mémoire non volatile est contenue dans une borne locale accessible par une 20 communication radio en champ proche. Selon un mode particulier de réalisation de l'invention, le procédé comporte en outre : une étape de vérification de l'intégrité de l'unité de mise à jour obtenue. 25 L'invention concerne également un module d'identité de souscripteur comportant pour la mise à jour des fonctionnalités du logiciel embarqué par un terminal de communication contenant ledit module d'identité de souscripteur: au moins une application nécessitant pour son exécution au moins une 30 commande implémentée par ledit terminal, qui comprend : des moyens de test de la mise en oeuvre par le terminal des commandes nécessaires à l'exécution des applications hébergées par le module d'identité de souscripteur ; des 10 moyens d'obtention d'une unité de mise à jour du logiciel embarqué par le terminal ; et des moyens de déclenchement de la mise à jour du logiciel embarqué par le terminal, ladite mise à jour étant faite par le terminal par l'installation de ladite unité de mise à jour.

L'invention concerne également un terminal de communication caractérisé en ce qu'il comporte un module d'identité de souscripteur selon l'invention.

L'invention concerne également un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'invention lorsque ledit programme est exécuté sur un ordinateur.

L'invention concerne également un moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'invention.

Dans un mode particulier de réalisation, les différentes étapes du procédé précité sont déterminées par des instructions de programmes d'ordinateurs.

En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre par un microprocesseur, ce programme comprenant des instructions adaptées à la mise en oeuvre des étapes du procédé tel que mentionné ci-dessus.

Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un microprocesseur, et comprenant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un moyen de stockage, tel qu'une ROM, par exemple une ROM de microcircuit, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou encore une mémoire flash. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur une plateforme de stockage d'un réseau de type Internet.

Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Le support d'informations et le programme d'ordinateur précités présentent des caractéristiques et avantages analogues au procédé qu'ils mettent en oeuvre. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après.

Aux dessins annexés, donnés à titre d'exemples non limitatifs : - la Figure 1 décrit l'architecture d'un module d'identité de souscripteur selon un exemple de réalisation de l'invention ; - la Figure 2 décrit un exemple de carte UICC ; - la Figure 3 décrit un exemple d'architecture logicielle d'un terminal ; - la Figure 4 décrit les interactions générales entre le terminal et un 5 module d'identité de souscripteur dans un exemple de réalisation de l'invention ; - la Figure 5 décrit les différentes étapes du procédé de test et de mise à jour selon un exemple de réalisation de l'invention. 10 L'invention propose une solution technique visant à identifier les commandes, ou plus généralement les unités logicielles manquantes sur un terminal pour permettre la bonne exécution d'une ou plusieurs applications embarquées au sein d'un module d'identité de souscripteur sur le terminal. Elle vise également à installer sur ce terminal ces commandes ou ces unités 15 manquantes. Elle permet donc une mise à jour du logiciel embarqué sur le terminal du terminal. Un exemple d'application embarquée au sein d'un module d'identité de souscripteur est proposé par la suite. Un opérateur de télécommunications peut 20 vouloir accéder aux mesures de puissance faites par un terminal pour obtenir des données relatives à la couverture de son réseau de télécommunications. Pour cela, le réseau par exemple de type 2G, 3G ou LTE est constitué d'un grand nombre de cellules qui fournissent une puissance dont la valeur peut varier au cours du temps. En effet, en zone urbaine, il existe des zones de 25 couvertures dans lesquelles il n'est pas possible de passer d'appel, et d'autres zones dans lesquelles la réception est excellente. La qualité de ce maillage peut dépendre la technologie 2G, 3G ou LTE utilisée. A proximité de certaines cellules, l'operateur pourrait détecter un nombre important de communications interrompues et de pertes de la connectivité avec des terminaux mobiles. 30 Puisque les communications interrompues et de pertes de la connectivité avec des terminaux mobiles génèrent une augmentation du trafic, ceci risque d'engendrer un encombrement du réseau. 3 0 15 7 1 8 10 Pour optimiser son réseau de télécommunication, l'opérateur peut changer les caractéristiques des cellules, par exemple augmenter leur puissance, mais aussi en ajouter de nouvelles. Pour obtenir de telles mesures de puissance, il peut soit envoyer des techniciens avec des appareils de mesures, soit utiliser les nombreux téléphones de ses abonnés pour faire automatiquement des mesures. Pour mettre en oeuvre cette dernière solution, l'opérateur installe une application sur chacune des cartes UICC dont il est le propriétaire. Cette application demande les valeurs des mesures de puissance au terminal, fait une synthèse et transmet ces données à un serveur distant de l'opérateur. Ainsi, si une station de base a un problème ou s'il y a des perturbations, l'operateur peut en avoir connaissance en temps réel.

Cet exemple nécessite donc la mise en oeuvre d'une application par un module d'identité de souscripteur qui interagit avec le terminal qui dispose de fonctionnalités complémentaires, en l'occurrence des moyens d'évaluation de la puissance de cellules. Or, les terminaux n'implémentent pas nécessairement les fonctionnalités nécessaires à la mise en oeuvre d'une telle application. D'autres fonctionnalités qui ne sont pas systématiquement implémentées dans les terminaux sont par exemple les commandes BIP (Bearer lndependant Protocol en anglais) permettant d'ouvrir des communications de données fondées sur le protocole de transport CAT TP (Card Application Toolkit Transport Protocol), par exemple défini par la norme ETSI TS 102 127 v6.12.0 ou l'amendement B développé par GlobalPlatform (GlobalPlatform Card Specification v 2.2, Amendment B v1.1.1).

D'une manière générale, l'invention fonctionne de la manière suivante. Des applications sont préinstallées au sein du module d'identité de souscripteur. Lors du démarrage du terminal, ces applications interagissent avec le terminal. Ces interactions utilisent typiquement le protocole de communication APDU défini par la norme ISO/SEC 7816-4. Cette interaction consiste typiquement en une phase de test de tout ou partie des commandes utilisées par les applications embarquées au sein du module d'identité de souscripteur. Les applications embarquées sont parfois dénommées « applets ». Cette phase de test permet d'obtenir un statut associé à chaque commande testée. La commande peut être opérationnelle, manquante, ou présente dans le terminal mais pas sous la forme requise par l'application du module d'identité de souscripteur. Ce dernier cas peut se produire, par exemple, lorsque le terminal possède bien l'unité logicielle requise mais pas dans la version attendue par l'application du module. En effet, la commande peut avoir été mise à jour dans une nouvelle version intégrant un comportement requis par l'application embarquée qui n'était pas implémenté dans les versions précédentes.

Avantageusement, lors de ces tests initiaux, le module d'identité de souscripteur obtient également, en réponse à une requête, des informations relatives au logiciel embarqué sur le terminal. Ces informations contiennent typiquement le type de système d'exploitation, par exemple Android (marque déposée) ou iOS ainsi que la version du système. Elles peuvent également contenir une liste d'unités logicielles, tel qu'un ensemble de librairies, présentes avec leur numéro de version. Elles peuvent également contenir d'autres informations selon les cas. Ces informations sont transmises par une unité du terminal et reçues par une application embarquée du module d'identité de souscripteur. L'application embarquée est une application dédiée à la mise à jour du système du terminal. L'unité du terminal peut être un programme informatique dédié appartenant à la « couche système » du système du terminal, ou encore une application logicielle de plus haut niveau.

Lorsque le module d'identité de souscripteur reçoit les informations demandées, celles-ci sont envoyées à un serveur distant. Les informations envoyées comportent typiquement au moins les résultats du test des commandes utilisées par les applications embarquées sur le module d'identité de souscripteur. Avantageusement, elles contiennent également les informations obtenues qui concernent le logiciel embarqué sur le terminal.

Le serveur distant analyse les données reçues pour identifier les fonctionnalités manquantes ou devant être mises à jour sur le terminal afin que les applications embarquées sur le module d'identité de souscripteur puissent fonctionner correctement. Par exemple, le serveur distant peut contenir une table d'association contenant pour chaque application embarquée les configurations minimales requises pour un fonctionnement correct de l'application pour différents systèmes d'exploitation. Cette connaissance peut être volumineuse et, de plus, elle évolue dans le temps. Il est donc particulièrement avantageux qu'elle soit regroupée sur le serveur distant où elle est centralisée et peut être mise à jour facilement pour suivre l'évolution des terminaux. Le serveur distant prépare alors le ou les modules manquants, par exemple sous la forme d'une mise à jour du système du terminal. Cette mise à jour est envoyée au module d'identité de souscripteur en réponse à son message contenant les informations sur le logiciel embarqué sur le terminal. Cette mise à jour peut prendre la forme d'une unité logicielle de mise à jour (patch en anglais), de librairies système, ou encore d'une application logicielle pouvant être exécutée par le système d'exploitation du terminal.

Comme toute unité logicielle, la mise à jour comprend un coeur qui implémente la ou les fonctions demandées, et des interfaces de programmation, appelées API (Application Programmation Interface en anglais) qui lui permettent de communiquer. Ces interfaces peuvent être destinées à la communication avec des couches dites basses du système d'exploitation, par exemple les couches « micro-programme » ou « système », en particulier lorsque la mise à jour implémente une adaptation des pilotes des protocoles ISO et SWP (Single Wire Protocol an anglais). Elles peuvent également être destinées à la communication avec des couches supérieures, par exemple les couches caractérisant l'ergonomie ou le design fonctionnel (dénommé interface homme machine), et qui favorisent les interactions avec l'utilisateur. Les interfaces peuvent également être destinées à des couches intermédiaires (parfois dénommées couches « système ») permettant de modifier le coeur du système d'exploitation ou de lui rajouter des fonctionnalités. Par exemple, une interface de programmation de l'unité de mise à jour peut correspondre à une fonctionnalité que l'on souhaite ajouter, supprimer ou modifier dans le logiciel embarqué sur le terminal . Cette fonctionnalité est typiquement fournie sous la forme d'une librairie partagée, d'un module noyau ou d'un service. La transmission de la mise à jour par le serveur distant au module d'identité de souscripteur peut être protégée de diverses façons. Selon un premier mode de réalisation, la transmission est protégée contre des erreurs de transmissions par une somme de contrôle, telle qu'un code de redondance cyclique (CRC) qui est vérifié par le module d'identité de souscripteur après réception de la donnée et de la valeur attendue du code de redondance. Selon un autre mode de réalisation, la mise à jour est signée électroniquement par l'opérateur à l'aide d'un certificat numérique. L'authenticité de la signature est alors vérifiée par le module d'identité de souscripteur. Dans encore un autre mode de réalisation, la mise à jour est chiffrée à l'aide d'un certificat numérique et déchiffrée par le module d'identité de souscripteur à l'aide d'une clef cryptographique.

Selon un mode de réalisation alternatif de l'invention, la mise à jour peut être obtenue localement. Par exemple, elle peut être disponible depuis une carte mémoire amovible insérée dans le terminal ou encore depuis une borne locale accessible par une communication radio en champ proche du type NFC (Near field Communication en anglais). Ce cas de figure correspond, par exemple, à un scénario au cours duquel un utilisateur apporte son terminal en boutique, chez son opérateur, pour effectuer la mise à jour. La mise à jour peut également être disponible sur un réseau local accessible au terminal, par exemple dans le cas d'une mise à jour d'une flotte de terminaux au sein d'une entreprise. Le module d'identité de souscripteur doit alors intégrer une unité d'analyse lui permettant de choisir la mise à jour en fonction des caractéristiques techniques du terminal. Toutefois, cette unité reste nettement plus simple que celle permettant au serveur distant d'analyser les informations reçues et de générer une mise-à-jour pour un terminal donné. En effet, la mise à jour disponible localement est générée préalablement et mise à disposition localement du terminal qui le requiert. Par exemple, un technicien en boutique va choisir une carte mémoire amovible contenant la mise à jour correspondant au terminal présenté par le client. Cette unité d'analyse embarquée dans le module d'identité de souscripteur peut donc se contenter de vérifier éventuellement l'intégrité de la mise à jour et vérifier la correspondance avec les fonctionnalités techniques du terminal et de son logiciel embarqué.

Un mode de réalisation particulier de l'invention va maintenant être décrit de façon détaillée en rapport avec les figures 1 à 5. La Figure 1 représente schématiquement un exemple de module d'identité de souscripteur 40 pouvant être utilisé dans la présente invention. Le module d'identité de souscripteur 40 comprend un microprocesseur 10, auquel est associée d'une part une mémoire vive 60 (par exemple du type RAM), au moyen d'un bus de communication 70, et d'autre part une mémoire non volatile 20 (par exemple du type ROM, EEPROM ou Flash), par exemple à travers un bus de communication 50.

Le module d'identité de souscripteur 40, et précisément le microprocesseur 10 qu'il incorpore, peuvent échanger des données avec des dispositifs extérieurs au moyen d'une interface de communication 30.

On a schématiquement représenté sur la Figure 1 la transmission d'une donnée d'entrée X reçue d'un dispositif extérieur (non représenté) et transmise de l'interface de communication 30 au microprocesseur 10. De manière similaire, on a représenté la transmission d'une donnée de sortie Y du microprocesseur 10 vers l'interface de communication 30 à destination d'un dispositif extérieur. Cette donnée de sortie Y est issue d'un traitement de données par le microprocesseur 10, généralement sur la donnée d'entrée X à l'aide d'une donnée secrète 80 interne au système, par exemple une clé privée. Bien que, pour l'illustration, les données d'entrée et les données de sortie figurent sur deux flèches différentes, les moyens physiques qui permettent la communication entre le microprocesseur 10 et l'interface 30 pourront être réalisés par des moyens uniques, par exemple un port de communication série ou un bus. Le microprocesseur 10 est apte à exécuter un logiciel (ou programme d'ordinateur) qui permet au module d'identité de souscripteur 40 d'exécuter un procédé conforme à l'invention dont des exemples sont donnés dans la suite. Le logiciel est composé d'une série d'instructions de commande du microprocesseur 10 qui sont par exemple stockées dans la mémoire 20. En variante, l'ensemble microprocesseur 10 - mémoire non-volatile 20 - mémoire vive 60 peut être remplacé par un circuit à application spécifique qui comprend alors des moyens de mise en oeuvre des différentes étapes du procédé de traitement de données. La Figure 2 représente une carte à microcircuit qui constitue un exemple d'implémentation du module d'identité de souscripteur selon un exemple de réalisation de l'invention tel que représenté à la Figure 1. Cette carte est typiquement une carte UICC utilisée dans un téléphone mobile. L'interface de communication 30 est dans ce cas réalisée au moyen des contacts de la carte à microcircuit. La carte à microcircuit incorpore un microprocesseur 10, une mémoire vive 60 et une mémoire non volatile 20 comme cela est représenté sur la Figure 1.

Cette carte à microcircuit est par exemple conforme à la norme ISO/IEC 7816 et munie d'un microcontrôleur sécurisé qui regroupe le microprocesseur (ou CPU) 20 et la mémoire vive 60.

Il peut également s'agir d'un circuit embarqué, dénommé eUICC qui est, par exemple soudé au téléphone mobile. La Figure 3 illustre la structure du logiciel embarqué sur le terminal 3.1 dans un exemple de réalisation de l'invention. Le procédé de mise à jour consiste typiquement à mettre à jour l'un des composants de ce logiciel. Ce logiciel comprend typiquement un système basé sur UNIX tel que le système Android (marque déposée) développé par la société Google (marque déposée). Le logiciel comporte une couche applicative 3.2 comportant un ensemble d'applications 3.3, 3.4 et 3.5. Parmi ces applications on peut trouver, par exemple, une application pour le suivi d'appel (call tracker en anglais) ou une application de gestion des messages courts (SMS dispatch en anglais). Ces applications utilisent les services d'un environnement applicatif, comportant typiquement une unité de téléphonie 3.6, par exemple localisée dans un répertoire « /java/android/telephony » du système Android. Cette unité de téléphonie comporte elle-même une unité d'interface radio 3.7 RIL (Radio Interface layer en anglais) , par exemple localisée dans le répertoire « /java/android/telephony/gsm » du système Android.

Cet environnement applicatif utilise des librairies système UNIX telles que le démon de gestion radio 3.8 nommé RILD (Radio Interface Layer Daemon en anglais) dans Android. La couche RIL (Radio Interface Layer en anglais) fournit une couche abstraite entre les services de téléphonie et la couche matérielle radio caractérisée par une interface de communication dénommée modem (baseband en anglais). Un démon est un processus système qui s'exécute en arrière-plan, à la différence des processus s'exécutant sous le contrôle d'un utilisateur. Ce démon utilise une unité de gestion radio 3.9 fournie par le fabricant du terminal. Cette unité de gestion radio fournie par le fabricant utilise des services du noyau UNIX tels que la pile de communication IP (Internet Protocol en anglais) 3.10 et le pilote de communication point à point PPP (Point to Point Protocol en anglais) 3.11. Il peut également faire des appels directs à la couche de gestion 3.12 du modem.

La Figure 4 illustre l'architecture haut-niveau d'un exemple de réalisation de l'invention. La Figure 4 illustre un terminal 4.1 disposant d'un module d'identité de souscripteur 4.2 constitué d'une carte UICC. Le terminal dispose d'un système d'exploitation 4.3 et d'une unité cliente du module d'identité de souscripteur 4.4. Le module d'identité de souscripteur dispose d'une application de gestion de l'identité de l'abonné, par exemple une application « USIM 3.1 » référencée 4.5, et d'une une application de mise à jour 4.9.

L'unité cliente 4.4 est le pendant de l'application de mise à jour 4.9. Ce peut être un programme informatique propre au système d'exploitation du terminal (« processus système »), ou une application de plus haut niveau, par exemple une application Android ou iOS (marque déposée). L'unité cliente 4.4 peut également être disponible sous la forme d'un démon ou d'un service qui se lance au démarrage du terminal et possède les droits nécessaires pour communiquer avec l'application de mise à jour du module d'identité de souscripteur. L'unité cliente 4.4 du terminal possède également les capacités de lancer une mise à jour du système d'exploitation du terminal, en réception à une notification de la disponibilité d'une mise à jour transmise par l'application de mise à jour 4.9 du module d'identité de souscripteur.

Lors d'un fonctionnement de mise à jour, l'application de mise à jour obtient une mise à jour typiquement depuis un serveur distant, ou encore localement. L'application de mise à jour transmet une requête de mise à jour 4.8 à l'unité cliente 4.4. Cette dernière émet alors une requête de mise à jour 4.7 auprès du système d'exploitation 4.3. L'unité cliente charge la mise à jour et lance le processus de mise à jour.. Les nouvelles commandes apportées par la mise à jour peuvent ensuite être utilisées lors d'échanges 4.6 entre l'application USIM 4.5 et le système d'exploitation 4.3 du terminal.

La Figure 5 illustre les différentes étapes du procédé de mise à jour dans un exemple de réalisation de l'invention. Lors d'une première étape 5.1, un test de mise à jour est déclenché. Ce test peut être par exemple déclenché au démarrage du terminal, lorsqu'un nouveau module d'identité de souscripteur est inséré dans le terminal, lorsqu'une carte mémoire est insérée dans le terminal, en réponse à une requête émise par un serveur distant ou en réponse à une requête de l'utilisateur du terminal.

Lors d'une étape 5.2, l'application de mise à jour teste tout ou partie des commandes requises par les applications embarquées dans le module d'identité de souscripteur. Le test d'une commande s'effectue typiquement par l'appel de la commande et l'analyse d'un code de retour indiquant un statut d'exécution. Lors d'une étape 5.3, l'application de mise à jour vérifie le résultat des tests. Si toutes les commandes testées ont retournées les valeurs attendues, cela signifie que le terminal implémente l'ensemble des fonctionnalités requises par les applications du module d'identité de souscripteur. Dans le cas contraire, si certaines commandes sont manquantes ou qu'elles n'ont pas le comportement attendu, par exemple car l'unité les implémentant n'est pas présente dans la version requise, une mise à jour est déclenchée. Dans ce cas, lors d'une étape 5.4, l'application de mise à jour du module d'identité de souscripteur envoie une requête d'identification au système d'exploitation qui lui répond avec des informations relatives au type de terminal et au système d'exploitation de ce dernier. Typiquement ces informations contiennent également la version du système d'exploitation ainsi que des informations et numéros de versions des librairies, modules et/ou applications installées. Alternativement, l'étape 5.4 peut être intégrée à l'étape de test ou effectuée préalablement à celle-ci de manière systématique.

Lors d'une étape 5.5, l'application de mise à jour envoie à un serveur distant une requête d'analyse de la mise à jour nécessaire. Avantageusement cette requête contient les informations relatives au type de terminal, au type de système d'exploitation et à sa version ainsi que la liste des unités, librairies et applications installées. La requête contient également les statuts retournés par les commandes non implémentées ou qui ne sont pas présentes dans une bonne version. Lors d'une étape 5.6, le serveur distant analyse la requête et détermine en fonction de ces informations la mise à jour nécessaire pour le bon fonctionnement des applications embarquées dans le module d'identité de souscripteur. Le serveur sélectionne ou génère une mise à jour destinée à être installée par le système d'exploitation du terminal. Lors de l'étape 5.7, la mise à jour est envoyée par le serveur distant au module d'identité de souscripteur. Ce dernier en vérifie avantageusement l'intégrité, par exemple par la vérification d'une somme de contrôle telle qu'un CRC (Cyclic Redondancy Code en anglais) ou par la vérification d'une signature électronique lors d'une étape 5.8. Le fait que la mise à jour soit reçue par le module d'identité de souscripteur permet à ce dernier, et donc à l'opérateur qui le contrôle, de maîtriser la configuration logicielle du terminal en ce qui concerne les fonctionnalités clés nécessaires au module.

Lors d'une étape 5.9, l'application de mise à jour 4.9 (Figure 4) du module d'identité de souscripteur déclenche la mise à jour du logiciel embarqué sur le terminal par l'envoi d'une requête de mise à jour au système. Cette requête contient la mise à jour. Alternativement cette requête contient un pointeur vers l'adresse de la mémoire non volatile dans laquelle est enregistrée la mise à jour. Alternativement, la mise à jour est déclenchée par l'enregistrement de la mise à jour dans une zone mémoire connue du système d'exploitation. Ce dernier vérifiant périodiquement la disponibilité d'une mise à jour dans cette zone mémoire et effectuant alors automatiquement la mise à jour. Alternativement, la vérification de la mise à jour peut être le résultat d'une action de l'utilisateur du terminal ou être programmée. La mise à jour peut ne concerner qu'une des couches du logiciel embarqué sur le terminal. Lors d'une étape 5.10, le système d'exploitation procède à la mise à jour du logiciel embarqué sur le terminal par l'installation de la mise à jour. Si nécessaire un redémarrage du système est opéré. Lors de l'étape 5.11, les applications embarquées dans le module d'identité de souscripteur peuvent communiquer avec le terminal en utilisant les 25 commandes mises à jour. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

30 Bien que la présente invention ait été décrite ci-dessus en référence à des modes de réalisation spécifiques, la présente invention n'est pas limitée aux modes de réalisation spécifiques, et les modifications qui se trouvent dans le champ d'application de la présente invention seront évidentes pour une personne versée dans l'art.5

Claims (16)

1. REVENDICATIONS1. Procédé de mise à jour des fonctionnalités du logiciel embarqué (3.1) par un terminal de communication (4.1) contenant un module d'identité de souscripteur (4.2) hébergeant au moins une application nécessitant pour son exécution au moins une commande implémentée par ledit terminal, caractérisé en ce qu'il comprend par le module d'identité de souscripteur (4.2): une étape (5.2) de test (4.1) des commandes nécessaires à l'exécution de la au moins une application hébergée par ledit module d'identité de souscripteur ; dans le cas où au moins une de ces commandes est manquante dans une version requise par les applications hébergées : une étape d'obtention (5.7) d'une unité de mise à jour du logiciel embarqué (3.1) par le terminal ; et en réponse à l'étape d'obtention, une étape de déclenchement (5.9) de la mise à jour du logiciel embarqué par le terminal, ladite mise à jour étant faite par le terminal par l'installation (5.10) de ladite unité de mise à jour.
2. 2. Procédé selon la revendication 1, caractérisé en ce que lesdites commandes sont des commandes proactives STK.
3. 3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que ladite étape de test est déclenchée par le démarrage du terminal.
4. 4. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que ladite étape de test est déclenchée par l'insertion dans le terminal d'un nouveau module d'identité de souscripteur ou par l'insertion dans le terminal d'une carte mémoire ou en réponse à une requête émise par un serveur distant ou par l'utilisateur, à destination du module d'identité de souscripteur.
5. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ladite étape de déclenchement de la mise à jour du logiciel embarqué par le terminal déclenche la mise à jour par le terminal de l'une des couches dudit logiciel.
6. 6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que l'étape d'obtention d'une unité de mise à jour comprend : une étape d'envoi d'une requête (5.5) à un serveur distant, ladite requête comprenant au moins des résultats du test de la mise en oeuvre par le terminal des commandes nécessaires à l'exécution des applications hébergées par le module d'identité de souscripteur ; et une étape (5.7) de réception de ladite unité de mise à jour transmise par ledit serveur distant.
7. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que lesdits résultats du test de la mise en oeuvre des commandes comprennent un statut obtenu en réponse au test.
8. 8. Procédé selon l'une quelconque des revendications 6 ou 7, caractérisé en ce qu'il comporte en outre : une étape (5.4) d'obtention d'informations de configuration du terminal ; et où la requête à un serveur distant comprend également ces informations obtenues.
9. 9. Procédé selon la revendication 1, caractérisé en ce que ladite unité de mise à jour est contenue dans une mémoire non volatile accessible par ledit module d'identité de souscripteur.
10. 10. Procédé selon la revendication 9, caractérisé en ce que ladite mémoire non volatile est contenue dans une carte mémoire insérée dans le terminal.
11. 11. Procédé selon la revendication 9, caractérisé en ce que ladite mémoire non volatile est contenue dans une borne locale accessible par une communication radio en champ proche.
12. 12. Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce qu'il comporte en outre : une étape de vérification de l'intégrité de l'unité de mise à jour obtenue.
13. 13. Module d'identité de souscripteur comportant pour la mise à jour des fonctionnalités du logiciel embarqué par un terminal de communication contenant ledit module d'identité de souscripteur: au moins une application nécessitant pour son exécution au moins une commande implémentée par ledit terminal, caractérisé en ce qu'il comprend : des moyens de test de la mise en oeuvre par le terminal des commandes nécessaires à l'exécution des applications hébergées par le module d'identité de souscripteur ; des moyens d'obtention d'une unité de mise à jour du logiciel embarqué par le terminal ; et des moyens de déclenchement de la mise à jour du logiciel embarqué par le terminal, ladite mise à jour étant faite par le terminal par l'installation de ladite unité de mise à jour.
14. 14. Terminal de communication caractérisé en ce qu'il comporte un module d'identité de souscripteur selon la revendication 13.
15. 15. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 12 lorsque ledit programme est exécuté sur un ordinateur.
16. 16. Moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 12.