Transmission de données entre un serveur et un objet communicant

La présente invention concerne une transmission de données entre un serveur et un objet communicant, la transmission étant initiée par le serveur sans l'émission d'un message court de type SMS (Short

Message Service) .

Un objet communicant peut être portable comme une carte à puce MMC (Multi -Media Card) , ou SD

(Secure Digital) ou UICC (Universal Integrated

Circuit (s) Card) . La carte à puce UICC est par exemple une carte munie d'une application SIM (Subscriber Identity Module) lorsque le terminal accueillant la carte est un mobile relié à un réseau du type GSM/GPRS (Global System for Mobile communications / General Packet Radio Service) , ou d'une application USIM (Universal Subscriber Identity Module) , RUIM (Removable User Identity Module) ou

ISIM (IP Subscriber Identity Module) , lorsque le terminal accueillant la carte est un mobile fonctionnant en accès multiple à répartition par codes CDMA (Coded Division Multiple Access) de la troisième génération (3GPP) du type UMTS (Universal Mobile Télécommunications System) ou UTRAN (UMTS Terrestrial Radio Access Network) , ou de la troisième génération (3GPP2) du type CDMA 2000.

Le serveur de téléchargement de données, également appelé plateforme d'administration de cartes OTA (Over The Air) , comprend un logiciel qui permet à l'opérateur gérant le réseau de radiocommunications de gérer les cartes à puce dans les terminaux mobiles et de modifier leur contenu.

Ces opérations à l'initiative de l'opérateur, dit en mode push, concernent par exemple le téléchargement d'un fichier dans des cartes prédéterminées du parc géré par l'opérateur, ou le téléchargement ou l'effacement d'une application déterminée, ou bien la modification de données d'un fichier ou d'une application déterminée dans des cartes gérées par 1 ' opérateur.

Actuellement pour effectuer une opération en mode push initiée par un opérateur d'un réseau de radiocommunications pour mobiles, le serveur de téléchargement de données géré par l'opérateur doit transmettre un message court appelé communément "SMS de push" pour demander à chaque carte à puce ciblée par l'opération d'ouvrir un canal de communication de type IP (Internet Protocol) entre la carte et le serveur.

La technologie SMS exigée pour l'établissement de la communication en mode push est un inconvénient pour les réseaux de radiocommunications dont les infrastructures ne supportent pas les messages courts ou pour lesquels les messages courts ne satisfont pas aux normes nécessaires à une mise à jour distante de cartes par exemple dans des réseaux de radiocommunications CDMA. De plus, la technologie SMS est basée sur un protocole de communication asynchrone, elle nécessite de nombreux essais et engendre parfois une perte de message et des délais de téléchargement importants. Si des cartes à puce sont indisponibles dans des mobiles hors tension ou hors de la couverture du réseau de radiocommunications, de nombreux envois de messages courts ultérieurs infructueux surchargent inutilement le réseau.

Des solutions théoriques d'établissement de canal de communication sans transmission de SMS de push remédient aux inconvénients précités. Une première solution est décrite dans la demande de brevet français 0552365 déposée le 28 juillet 2005 par le demandeur et non publiée. La première solution renverse le mode push actuel en un mode d'interrogation par la carte qui initie périodiquement une communication avec un serveur de campagne afin d'obtenir un éventuel contenu mis à disposition par l'opérateur du réseau de radiocommunications lors d'une campagne de téléchargement . Une deuxième solution concerne la spécification GPRS dans laquelle théoriquement une plateforme OTA peut ouvrir un canal de communication vers une carte à puce. En pratique, la plateforme doit connaître les adresses de toutes les cartes à puce gérées par la plateforme ce qui est coûteux et difficilement réalisable si l'on tient compte de l'adressage dynamique des cartes. De plus du point de vue de la sécurité, toute entité extérieure à la carte à puce et connaissant l'adresse d'accès de la carte peut ouvrir un canal de communication avec la carte favorisant des attaques extérieures. Il est donc préférable dans ce cas que la carte contrôle l'ouverture du canal de communication.

Selon une troisième solution, la carte à puce comprend des applications dédiées à l'ouverture d'un canal de communication pour y détecter une éventuelle demande de connexion provenant de la plateforme OTA. La plateforme OTA doit alors connaître l'adresse IP de la carte, ce qui n'est pas possible a priori dans le cas d'un adressage dynamique. En outre, la carte

doit ouvrir, dès le début de la surveillance de demande de connexion, autant de canaux de communication différents que de protocoles de communication à gérer. Il n'est pas ensuite possible d'ouvrir plus de canaux de communication que ceux initialement prévus par la carte ni d'utiliser des protocoles de communication différents de ceux pour lesquels la carte a ouvert initialement un canal.

L'invention a pour objectif de remédier aux inconvénients précités et plus particulièrement de transmettre des données entre au moins un objet communicant, tel qu'une carte à puce, et ,un serveur tel qu'une plateforme d'administration de carte, à l'initiative du serveur sans transmission d'un SMS de push, tout en assurant une disponibilité préalable de l'objet communicant à recevoir des données à transmettre via un canal de communication ouvert par l'objet communicant.

Pour atteindre cet objectif, un procédé pour transmettre des données entre un premier moyen serveur et au moins un objet communicant à travers un réseau de communications, est caractérisé en ce qu'il comprend des étapes de : ouvrir un premier canal de données depuis l'objet communicant vers un deuxième moyen serveur après un attachement de l'objet communicant au réseau de communications, transmettre des paramètres de connexion depuis le premier moyen serveur à travers le deuxième moyen serveur et le premier canal de données vers l'objet communicant, et ouvrir un deuxième canal de données depuis l'objet communicant vers le premier moyen serveur en

fonction des paramètres de connexion, afin de transmettre les données entre le premier moyen serveur et l'objet communicant à travers le deuxième canal de données .

La transmission de données de l'invention est ainsi avantageusement initiée depuis un premier moyen serveur de téléchargement dans le réseau de communications qui ne supporte pas la technologie SMS.

L'ouverture du premier canal de données par l'objet communicant vers le deuxième moyen serveur a pour avantage d'indiquer aux premier et deuxième moyens serveurs que l'objet communicant est attaché au réseau de communications et est donc prêt pour une transmission de données, afin de diminuer le nombre d'essais et ainsi d'optimiser la durée d'une campagne de téléchargement.

En outre, le deuxième canal de données est ouvert en dépendance des paramètres de connexion relatifs au premier moyen serveur retransmis par le deuxième moyen serveur. Cette dépendance facilite l'ouverture de toute session applicative selon n'importe quel type de protocole de communication, contrairement à la technique antérieure où l'objet communicant doit ouvrir, dès son attachement au réseau, autant de canaux de communication différents que de protocoles de communication à gérer par 1 ' obj et communicant . Lors de l'ouverture du premier canal de données, l'objet communicant transmet au deuxième moyen serveur un identificateur et une adresse de l'objet communicant afin que le deuxième moyen serveur apparie l'identificateur à l'adresse pour enregistrer l'ouverture du premier canal de données. L'adresse de

l'objet communicant peut ne pas être transmise si elle est déjà connue du deuxième moyen serveur.

L'invention a aussi pour objet un système pour transmettre des données entre un premier moyen serveur et au moins un objet communicant à travers un réseau de communications. Le système est caractérisé en ce qu'il comprend : un moyen dans l'objet communicant pour ouvrir un premier canal de données vers un deuxième moyen serveur après un attachement de l'objet communicant au réseau de communications, un moyen dans le deuxième moyen serveur pour retransmettre des paramètres de connexion depuis le premier moyen serveur à travers le premier canal de données vers l'objet communicant, et un moyen dans l'objet communicant pour ouvrir un deuxième canal de données vers le premier moyen serveur en fonction des paramètres de connexion, afin de transmettre les données entre le premier moyen serveur et l'objet communicant à travers le deuxième canal de données .

Le système de 1 ' invention ne nécessite pas de modification matérielle coûteuse dans les infrastructures actuelles du réseau. De plus, le système de l'invention facilite le déploiement du premier moyen serveur en tant que plateforme de téléchargement OTA dans le réseau ce qui ne requiert plus obligatoirement l'intégration d'équipement à technologie SMS.

Les opérateurs virtuels qui ne possèdent pas d'infrastructure SMS peuvent grâce à l'invention lancer des campagnes de mise à jour vers des objets communicants qu'ils gèrent.

L'invention concerne encore un objet communicant adapté à la transmission de données entre un premier moyen serveur et ledit objet communicant à travers un réseau de communications. L'objet communicant est caractérisé en ce qu'il comprend : un moyen pour ouvrir un premier canal de données vers un deuxième moyen serveur après un attachement de l'objet communicant au réseau de communications afin que le premier moyen serveur transmette des paramètres de connexion à travers le deuxième moyen serveur et le premier canal de données vers l'objet communicant, et un moyen pour ouvrir un deuxième canal de données vers le premier moyen serveur en fonction des paramètres de connexion, afin de transmettre les données entre le premier moyen serveur et l'objet communicant à travers le deuxième canal de données.

L'objet communicant peut être constitué par une carte à puce associée à un terminal, par exemple un ordinateur personnel, un mobile ou un assistant personnel communicant PDA, ou être constitué par un terminal .

Enfin, l'invention se rapporte à un programme informatique apte à être mis en œuvre dans un objet communicant adapté à la transmission de données entre un premier moyen serveur et ledit objet communicant à travers un réseau de communications. Le programme comprend des instructions qui, lorsque le programme est exécuté dans ledit objet communicant, réalisent les étapes selon le procédé de l'invention.

D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs

réalisations de 1 ' invention données à titre d'exemples non limitatifs, en référence aux dessins annexés correspondants dans lesquels :

- la figure 1 est un bloc-diagramme schématique d'un système de communication reliant un objet communicant, un serveur d'enregistrement et un serveur de téléchargement géré par un opérateur de réseau, pour la mise en œuvre du procédé de transmission de données selon l'invention ; et - la figure 2 est un algorithme du procédé de transmission de données selon l'invention.

Dans la figure 1 sont représentés des moyens serveurs pour transmettre ou recevoir des données dans ou depuis au moins un objet communicant. Selon un exemple auquel on se référera dans la suite, l'objet communicant est portable et est une carte à puce CP qui est associée à un terminal radio mobile T, par exemple qui est amovible du terminal. La carte à puce CP est du type UICC (Universal Integrated Circuit (s) Card) . La carte à puce CP avec le terminal T est rattachée à un réseau de radiocommunications cellulaire RR du type GSM adossé à un réseau à commutation par paquets avec gestion de la mobilité et accès par voie radio GPRS, ou du type UMTS, ou de la troisième génération (3GPP2) du type CDMA 2000.

Les moyens serveurs sont un serveur de téléchargement ST et un serveur d'enregistrement SR. Le serveur de téléchargement ST est souvent géré par l'opérateur du réseau de radiocommunications RR et constitue une plateforme OTA (Over The Air) pour télécharger des données vers la carte à puce ciblée ou non pendant une campagne de téléchargement de données ou pour un téléchargement de données unitaire. En variante, le serveur ST constitue une

plateforme de gestion d'applications qui sont réparties entre le serveur ST et la carte à puce CP et qui s'échangent des données. Le serveur ST reçoit ainsi des données provenant de la carte à puce CP et réciproquement .

Le serveur d'enregistrement SR enregistre l'ouverture d'un premier canal de données permanent CDl entre lui-même et la carte à puce CP. Cette ouverture du premier canal indique que la carte CP et le terminal T sont attachés au réseau de radiocommunications cellulaire RR. L'ouverture du premier canal de données CDl est initiée par la carte à puce CP dès la mise sous tension du terminal radio mobile T associé à la carte à puce CP et leur attachement au réseau de radiocommunications RR.

Le serveur d'enregistrement SR peut également comprendre une fonction de transmission de données et constituer une plateforme comportant des données à transmettre vers ou à recevoir depuis la carte à puce CP.

Le serveur de téléchargement ST et le serveur d'enregistrement SR communiquent entre eux directement par une liaison filaire ou par un réseau de paquets RP à haut débit, par exemple 1 ' internet ou un intranet. Selon un premier cas, les deux serveurs ST et SR sont localisés dans un unique serveur géré par le même opérateur, réduisant ainsi des contraintes d'adressage. Selon un deuxième cas, les deux serveurs sont localisés chez des opérateurs distincts et communiquent alors par une liaison sécurisée .

Les serveurs SR et ST communiquent avec la carte à puce CP associée au terminal T par des canaux de

données CDl et CD2 ouverts entre le réseau de radiocommunications RR et le réseau de paquets RP par l'intermédiaire par exemple d'une passerelle de communication non représentée sur la figure 1. La passerelle de communication peut comporter une passerelle d'accès pour communiquer avec les serveurs SR et ST à travers le réseau de paquets RP à haut débit. Une autre passerelle d'accès de la passerelle de communication communique avec au moins un commutateur du réseau de radiocommunications RR, à travers bien souvent un réseau d'accès tel qu'un réseau de paquets de type X.25 ou un réseau RNIS (Réseau Numérique à Intégration de Service) ou ATM (Asynchronous Transfert Mode) . Selon une réalisation particulière, la passerelle de communication échange avec le terminal radio mobile T des messages qui encapsulent des paquets IP (Internet Protocol) transmis vers et par les serveurs SR et ST à travers les réseaux RR et RP.

Lorsque le serveur de téléchargement ST désire télécharger ou recevoir des données vers ou depuis la carte à puce CP, il transmet une requête d'initiation de transmission RQ_I incluant des paramètres de connexion PCN au serveur d'enregistrement SR.

Dans le premier canal de données CDl transite une requête de connexion RQ_C depuis le serveur d'enregistrement SR vers la carte à puce CP en réponse à la requête d'initiation de téléchargement RQ__I du serveur ST. A la réception de la requête de connexion RQ_C, la carte CP ouvre un deuxième canal de données CD2 entre le serveur de téléchargement ST et la carte à puce CP selon les paramètres de connexion PCN requis par le serveur de téléchargement ST. Le canal de données CDl est ouvert selon le

protocole de réseau IP (Internet Protocol) et de préférence selon un protocole de transport en mode sans connexion ne garantissant pas l'arrivée de paquet tel que le protocole UDP (User Datagram Protocol) . Ce protocole de transport a l'avantage de consommer peu de ressources sur le serveur d'enregistrement SR et de rester ouvert de manière permanente. En variante, le protocole de transport du canal CDl est un protocole en mode avec connexion garantissant l'arrivée de paquet tel que le protocole TCP (Transport Control Protocol) qui assure le contrôle des erreurs.

A l'ouverture du canal CDl, la carte à puce transmet un message d'enregistrement M_ER au serveur d'enregistrement.

Dès que le terminal T est mis hors tension, la carte CP ferme le canal de données CDl .

Dans le réseau de radiocommunications RR, la carte à puce CP communique avec le terminal radio mobile T selon un protocole SCTP (Socket Card

Transport Protocol) par exemple le protocole BIP

(Bearer Independent Protocol), ou par l'intermédiaire d'une application (Midlet) dédiée embarquée dans le terminal qui communique avec la carte via un protocole applicatif spécifique, comme par exemple le protocole J2ME (Java 2 Mobile Edition) . Dans l'exemple des figures 1 et 2 , le terminal T ne traite pas les paquets IP qui transitent entre les serveurs et la carte à puce CP. Le terminal T est transparent.

De manière plus détaillée dans la figure 1, on a représenté le serveur d'enregistrement SR, le serveur de téléchargement ST, le terminal T et la carte à puce CP sous forme de blocs fonctionnels dont la

plupart assurent des fonctions ayant un lien avec 1 ' invention et peuvent correspondre à des modules logiciels et/ou matériels.

Le serveur de téléchargement ST comprend un gestionnaire de téléchargement GT qui gère diverses opérations au cours du téléchargement et une interface de communication ICT pour transmettre et recevoir des paquets IP à travers le réseau de paquets RP. Les opérations gérées par le gestionnaire GT sont notamment l'établissement de la requête d'initiation de transmission RQ_I transmise au serveur d'enregistrement SR afin d'initier un échange avec la carte à puce CP, et l'envoi vers et/ou la réception depuis la carte à puce CP de données via le deuxième canal de données CD2.

Une base de données BD peut être incorporée au serveur de téléchargement ST, ou être indépendante sous la forme d'un serveur de gestion de base de données qui est relié au serveur ST par un réseau de paquets tel que le réseau RP, c'est-à-dire via 1 ' internet ou via un réseau intranet propre à l'opérateur du réseau RR. La base de données BD comprend des données D à télécharger et divers paramètres et caractéristiques des cartes, y compris la carte CP, gérées par l'opérateur du réseau de radiocommunications cellulaire RR. La base de données comprend un identificateur fixe ID_CP de la carte à puce qui est par exemple un numéro de série de la carte et/ou l'identité internationale IMSI

(International Mobile Subscriber Identity) de l'usager de la carte et/ou le numéro de téléphone

MSISDN (Mobile Station ISDN Number) de l'usager du terminal T.

Le serveur d'enregistrement SR comprend un gestionnaire GR qui gère l'enregistrement de l'ouverture du premier canal de données CDl entre la carte à puce CP et le serveur d'enregistrement SR. L'enregistrement consiste, par exemple, en 1 ' appariement d'une adresse AD_CP de la carte à puce CP à l'identificateur fixe ID_CP de la carte à puce. Cet appariement est enregistré dans une mémoire MR du serveur d'enregistrement SR. D'autres cartes à puce selon l'invention sont enregistrées auprès du serveur d'enregistrement dès la mise sous tension des terminaux associés à ces cartes et de l'ouverture d'un premier canal de données respectif.

Selon une première réalisation, le serveur d'enregistrement ne connaît pas l'adresse AD_CP de la carte à puce CP. Celle-ci est une adresse de type IP allouée dynamiquement à la carte par le réseau RR à chaque attachement du terminal T au réseau. En variante, l'adresse AD_CP est une adresse fixe dédiée à la carte CP et inconnue du serveur SR tant que la carte n'a pas ouvert pour la première fois le canal CDl.

Selon une deuxième réalisation, le serveur d'enregistrement connaît déjà l'adresse AD_CP de type IP assignée dynamiquement à la carte CP. Le serveur

SR peut être un serveur de l'opérateur du réseau de radiocommunications RR gérant la carte à puce CP et l'assignation de son adresse AD_CP . En variante, l'adresse AD_CP est construite dynamiquement en fonction d'un code, par exemple dépendant d'identificateurs du constructeur de la carte à puce, de l'opérateur du réseau RR et de l'usager de la carte. Le serveur d'enregistrement SR comprend dans la mémoire MR un algorithme de codage de l'adresse AD CP de la carte à puce CP.

Selon une troisième réalisation, le serveur d'enregistrement connaît l'adresse AD_CP de la carte à puce qui est une adresse fixe associée à l'identificateur ID_CP de la carte. Le serveur d'enregistrement SR comporte également une interface de communication ICR afin d'échanger des messages, des requêtes et réponses avec le serveur de téléchargement ST et la carte a puce CP .

Le terminal T comprend une interface réseau IRT, un processeur PT, des mémoires MT, un lecteur de carte LT et optionnellement un afficheur AT tel qu'un écran connecté ou intégré au terminal et associé notamment à un clavier connecté ou intégré au terminal. Les différents éléments du terminal sont reliés entre eux par un bus bidirectionnel BT.

La carte à puce CP comprend principalement un processeur PC, ou plusieurs processeurs, et trois mémoires Ml à M3. La carte échange des commandes, ou requêtes, et des réponses avec le terminal T à travers un port d'entrée/sortie PES et le lecteur LT avec ou sans contact. Les différents éléments de la carte sont reliés entre eux par un bus bidirectionnel

BC.

La mémoire Ml est du type ROM ou Flash et inclut le système d'exploitation de la carte.

La mémoire M2 est une mémoire non volatile par exemple EEPROM ou Flash pour notamment mémoriser des clés, des numéros d'identité et d'autres paramètres du profil de l'usager possédant la carte, comme un code PIN et autres données de sécurité . La mémoire M2 comprend également l'identificateur fixe ID_CP de la

carte à puce, des applications de la carte et une adresse AD_SR du serveur d'enregistrement SR.

La mémoire M3 est une mémoire RAM ou SRAM servant plus particulièrement au traitement de données .

La carte CP comprend, en outre relativement a

1 ' invention, un premier module logiciel appelé agent

(applet) de veille AV réparti dans les mémoires Ml et

M2. Lorsque le terminal est mis sous tension, l'agent de veille AV ouvre le premier canal de données CDl entre la carte à puce CP associé au terminal et le serveur d'enregistrement SR.

D'autres modules logiciels sont appelés agents d'application APl et AP2 et sont dédiés à des protocoles de transport respectifs distincts tels que les protocoles CAT-TP (Card Application Toolkit - Transport Protocol) , FTP (File Transfer Protocol) et HTTP (HyperText Transfer Protocol) . Lorsque la carte reçoit la requête de connexion RQ_C incluant les paramètres de connexion PCN du serveur de téléchargement ST, un agent d'application, par exemple l'agent APl, est sélectionné en fonction desdits paramètres de connexion pour ouvrir le canal de données CD2 afin de transférer directement les données D entre le serveur de téléchargement ST et la carte à puce CP.

En référence à la figure 2, le procédé de 1 ' invention est mis en œuvre dans un réseau existant RR de type GSM/GPRS comportant un allocateur dynamique d'adresses de cartes à puce et dans un réseau de paquets RP, et comprend des étapes principales El à E3.

L'étape principale El concerne l'ouverture du premier canal de données permanent CDl et comprend

des étapes ElO à E14. Après un attachement du terminal T associé à la carte à puce CP au réseau RR à l'étape ElO, par exemple suite à une mise sous tension ou sous couverture de réseau du terminal T ou à une connexion de la carte au terminal, le terminal T associé à la carte à puce CP s'attache au réseau RR et l'agent de veille AV de la carte à puce lit l'adresse AD_SR du serveur d'enregistrement dans la mémoire M2 afin d'ouvrir le canal de données CDl et d'établir une connexion permanente via le canal de données CDl entre la carte et le serveur d'enregistrement SR, à l'étape EIl. A l'étape E12 après l'ouverture du canal de données CDl, l'agent de veille AV transmet au serveur SR un message d'enregistrement M_ER incluant l'identificateur fixe ID_CP de la carte à puce CP afin que le serveur SR enregistre un appariement de l'identificateur à une adresse AD_CP de l'objet communicant portable connue du serveur. Dans la réalisation où le serveur SR ne connaît pas la nouvelle adresse AD_CP allouée dynamiquement à la carte CP par le réseau RR, le message d'enregistrement M_ER comprend outre l'identificateur fixe ID_CP également l'adresse AD_CP afin que le serveur SR enregistre un appariement de l'adresse inconnue à l'identificateur.

A l'étape E13, le serveur d'enregistrement enregistre dans la mémoire MR l'ouverture du canal de données CDl sous la forme de 1 ' appariement de l'adresse AD_CP à l'identificateur ID_CP de la carte à puce.

En variante, lorsque le serveur SR connaît l'adresse de la carte, les étapes E12 et E13 sont optionnelles .

A l'étape E14, l'agent de veille AV de la carte à puce attend la réception d'une requête de connexion RQ_C transmise via le canal CDl .

L'étape principale E2 concerne un téléchargement de données depuis le serveur de téléchargement ST et comprend des étapes E20 à E29.

A l'étape E20, l'opérateur du réseau de radiocommunications RR souhaite télécharger des données D dans la carte à puce CP depuis le serveur de téléchargement ST. A l'étape E21, le gestionnaire GT du serveur de téléchargement ST forme une requête d'initiation de transmission RQ_I et la transmet via l'interface ICT au serveur d'enregistrement SR. La requête d'initiation de transmission RQ_I inclut notamment l'adresse AD_ST du serveur ST, 1 ' identificateur ID_CP de la carte à puce CP et des paramètres de connexion PCN relatifs au serveur de téléchargement ST comme ceux relatifs au protocole de transport CAT-TP sur un lien TCP/IP.

A l'étape E22, le serveur d'enregistrement SR reçoit la requête d'initiation RQ_I et la traite. En fonction de l'identificateur ID_CP de la carte à puce transmis, le gestionnaire d'enregistrement GR lit dans la mémoire MR l'adresse AD_CP associée à l'identificateur ID_CP afin de transmettre à l'étape E23 une requête de connexion RQ_C contenant l'adresse AD_ST du serveur ST, les paramètres de connexion PCN et optionnellement l'adresse AD_CP à la carte à puce CP via le canal ouvert CDl.

Dès que la carte CP a reçu la requête de connexion RQ_C, l'agent de veille AV la traite et extrait de celle-ci l'adresse AD_ST du serveur de téléchargement et les paramètres de connexion PCN pour les communiquer à l'agent d'application APl

dédié au protocole de transport CAT_TP . L'agent d'application APl ouvre, à l'étape E25, le deuxième canal de données CD2 en fonction des paramètres de connexion PCN transmis afin que la carte CP communique avec le serveur de téléchargement ST via le terminal T, sans recourir au serveur intermédiaire SR.

A l'étape E26, le gestionnaire de téléchargement GT du serveur ST télécharge via 1 ' interface de communication ICT et à travers le canal CD2 , les données D dans la carte CP, qui les traite à l'étape E27. Par exemple la carte met à jour une application concernée par le téléchargement. Optionnellement , après traitement des données D, la carte transmet à l'étape E28, le résultat R du téléchargement au serveur ST. De préférence, en fin de téléchargement, à l'étape E29, la carte et/ou le serveur ST libèrent le canal de données CD2.

En variante de l'étape principale E2 , une application du serveur de téléchargement est adaptée pour recevoir des données fournies par la carte à puce CP. Le serveur de téléchargement ST transmet au serveur SR une requête RQ_I contenant outre les paramètres PCN et les adresses AD_ST et AD_CP, un identificateur des données requise par l'application du serveur ST .

Le serveur d'enregistrement SR reçoit la requête RQ_I , la traite et transmet à la carte à puce une requête de connexion RQ_C contenant outre les paramètres PCN et les adresses AD_ST et AD_CP, 1 ' identificateur des données requises via le canal ouvert CDl .

Dès que la carte CP a reçu la requête de connexion RQ C, elle ouvre le deuxième canal de

données CD2 en fonction des paramètres de connexion PCN transmis afin de communiquer avec le serveur de téléchargement ST via le terminal T, sans recourir au serveur intermédiaire SR. La carte à puce transmet à travers le canal CD2 les données requises au serveur de téléchargement qui les traite.

Tant que le canal de données CDl est ouvert, d'autres serveurs de téléchargement peuvent initier un téléchargement via le serveur d'enregistrement SR. Ainsi après téléchargement des données D depuis le serveur de téléchargement ST, ou simultanément, un deuxième serveur de téléchargement, appelé ci -après troisième serveur, peut également échanger des données avec la carte à puce CP de manière analogue à l'étape principale E2 et sa variante. Le procédé de l'invention comprend alors, en outre après l'ouverture EIl du premier canal de données CDl, des étapes de : transmettre des deuxièmes paramètres de connexion depuis le troisième serveur à travers le serveur d'enregistrement SR et le canal de données CDl vers la carte à puce CP via le terminal T, ouvrir un troisième canal de données depuis la carte à puce vers le troisième serveur en fonction des deuxièmes paramètres de connexion, afin de transmettre des données entre le troisième serveur et la carte à puce à travers le troisième canal de données, et fermer le troisième canal de données lorsque la transmission des données est terminée.

Les deuxièmes paramètres de connexion transmis par le troisième serveur constituant le deuxième serveur de téléchargement peuvent être différents des paramètres de connexion du serveur ST et être

relatifs par exemple à un échange de données selon le protocole de transport FTP sur un lien TCP/IP ou UDP/IP. Dans ce cas, l'agent de veille AV fait appel a un autre agent d'application, par exemple l'agent AP2 dédié au protocole de transport FTP. L'agent AP2 ouvre le troisième canal de données autre que les canaux CDl et CD2 , selon les deuxièmes paramètres de connexion transmis par le troisième serveur.

Le serveur d'enregistrement SR peut également échanger des données avec la carte à puce CP de manière analogue au téléchargement de données depuis des serveurs de téléchargement. Dans ce cas, seules les étapes E23 à E29 sont exécutées. Un canal de données autre que le canal CDl est ouvert en fonction de paramètres de connexion envoyés par le serveur SR dans la requête de connexion RQ_C .

Tant que la carte à puce est présente dans le réseau RR et donc attachée à celui-ci, le canal de données CDl est ouvert afin de traiter toute requête de connexion RQ_C liées à l'initiation d'une transmission .

L'étape principale E3 concerne la fermeture du canal CDl, lorsque le terminal T et la carte CP sont détachés du réseau RR à l'étape E30 par exemple suite à une mise hors tension ou hors couverture du terminal T ou à une déconnexion de la carte et du terminal . La carte à puce ferme le premier canal de données CDl à l'étape E31. L'enregistrement de l'identificateur ID_CP associé à l'adresse AD_CP est supprimé dans la mémoire MR du serveur d'enregistrement SR par le gestionnaire d'enregistrement GR.

L'invention n'est pas limitée à une transmission de données entre un serveur et des cartes à puce du type UICC. Une carte à puce avec laquelle des données sont à échanger peut être également une carte incluse dans un ordinateur portable relié à un terminal mobile, une carte de paiement, une carte de porte- monnaie électronique, une carte de santé, un passeport électronique, ou toute autre carte additionnelle liée à un terminal mobile. Par exemple, l'invention s'applique à des cartes de paiement visées par une campagne de téléchargement pour lesquelles les données à télécharger peuvent concerner un changement de nom de la banque délivrant lesdites cartes dans la mémoire non volatile de type EEPROM des cartes.

Selon d'autres variantes, l'invention s'applique à d'autres objets électroniques communicants portables, tels que des assistants numériques personnels communicants PDA.

L'invention peut également servir à donner à la carte à puce un accès local par liaison filaire telle que par bus USB (Universal Sériai Bus) ou par liaison sans fil à courte portée du type Bluetooth, infrarouge, selon une norme IEEE 802. xx, ou satisfaisant le label WiFi (Wireless Fidelity) et WIMAX (World wide Interoperability Microwave Access) , pour qu'une entité locale initie un téléchargement de données dans la carte à puce. L'entité locale peut être par exemple un ordinateur personnel (PC) connecté à un lecteur de carte à puce associé avec ou sans contact à la carte.

Le système de transmission de 1 ' invention peut également être implémenté dans un réseau de

radiocommunications comportant une infrastructure de gestion de messages courts sans en modifier le procédé de l'invention.

L'invention décrite ici concerne un procédé et un système pour transmettre des données entre un serveur de téléchargement et un ou des objets communicants portables, ainsi qu'un objet communicant adapté à transmettre et recevoir des données vers ou depuis un premier moyen serveur à travers un réseau de communications. Selon une implémentation, les étapes du procédé de 1 ' invention peuvent être déterminées par les instructions d'un programme informatique incorporé dans l'objet communicant et comportant des instructions qui, lorsque le programme est exécuté dans ledit objet communicant, réalisent les étapes selon le procédé de l'invention. Selon une autre implémentation, les étapes du procédé de 1 ' invention peuvent être déterminées par les instructions d'un programme informatique incorporé dans le système et en particulier pour partie dans le serveur de téléchargement et pour partie dans le serveur d'enregistrement. Le programme comporte des instructions de programme qui, lorsque ledit programme est chargé et exécuté dans le système dont le fonctionnement est alors commandé par l'exécution du programme, réalisent les étapes du procédé selon 1 ' invention.

En conséquence, l'invention s'applique également à un programme d'ordinateur, notamment un programme sur ou dans un support d'informations, adapté à mettre en œuvre l'invention.