Brevet FR2892837A1 — publié le 20070504

Téléchargement de données dans des objets communicants portables présents dans un réseau de radiocommunications pendant une campagne La présente invention concerne le téléchargement de données depuis un serveur de campagne dans des objets communicants portables à travers un réseau de radiocommunications pendant une campagne de téléchargement. En particulier, elle a trait à un téléchargement de données lorsque les objets communicants portables ciblés par la campagne sont réputés présents dans le réseau de radiocommunications. Les objets communicants portables sont des cartes à puce, telles que des cartes MMC (Mufti-Media Card), SD (Secure Digital) et 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 est un mobile du type GSM ou GPRS, ou d'une application USIM (Universal Subscriber Identity Module), RUIM (Removable User Identity Module) ou ISIM (IP Subscriber Identity Module), associées à des terminaux mobiles 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 Telecommunications System) ou UTRAN (UMTS Terrestrial Radio Access Network), ou de la troisième génération (3GPP2) du type CDMA 2000. Le serveur de campagne pour télécharger des 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 conserver le contrôle des cartes à puce dans les terminaux mobiles et de modifier leur contenu. Ces opérations à l'initiative de l'opérateur (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 l'opérateur. L'invention s'intéresse plus particulièrement à une campagne de téléchargement massif de données des cartes d'usager, bien que le serveur de campagne puisse opérer un téléchargement unitaire dans une carte d'usager. Selon un premier exemple, un téléchargement est relatif à un unique fichier personnel qui est destiné à des usagers itinérants se trouvant fréquemment à l'étranger et qui contient plus d'une dizaine d'identificateurs de réseaux préférés gérés par des opérateurs avec lesquels l'opérateur du réseau gérant les cartes a contracté. Le fichier d'identificateurs de réseaux préférés est unique et a vocation à être téléchargé dans de nombreuses cartes d'usager prédéterminées de manière à ce que les cartes des usagers soient connectées préférablement à ces réseaux lorsque les usagers sont à l'étranger. Pour ce premier exemple, l'opérateur a actuellement deux possibilités pour télécharger ce fichier depuis le serveur de campagne. Selon une première possibilité, l'opérateur décide de télécharger le fichier de manière unitaire, au fil de l'eau, la première fois qu'un usager intéressé est en itinérance (roaming), et ainsi de suite pour tous les usagers les uns après les autres, qui sont en itinérance. Selon une deuxième possibilité, dit en mode de campagne, le serveur envoie le fichier des identificateurs de réseaux préférés au cours d'une seule campagne vers les cartes dont les usagers ont souscrit à une option d'itinérance. En mode campagne, le nombre d'usagers ciblés peut atteindre plusieurs centaines de milliers ou millions. Selon un deuxième exemple, un téléchargement concerne une application facilitant la gestion du répertoire des numéros téléphoniques dans les cartes. Cette application permet à un usager de sauvegarder tout son répertoire dans un serveur prédéterminé géré par l'opérateur et la sauvegarde est mise à jour chaque fois que l'usager enregistre un nouveau numéro téléphonique dans sa carte. Selon ce deuxième exemple, trois possibilités sont offertes. Suite à une publicité présentée à la télévision, l'usager appelle pendant la journée le centre d'appel de l'opérateur pour demander de télécharger l'application dans sa carte. Cette opération est une opération unitaire déclenchée dans le serveur de campagne par l'opérateur en mode d"'Assistance Client" (Customer Care). Selon une deuxième possibilité, l'usager prend l'initiative de commander des téléchargements en consultant lui-même depuis son terminal mobile le site de l'opérateur de manière à déclencher le téléchargement de l'application dans la carte. Ce téléchargement est également une opération unitaire commandée dans le serveur de campagne par l'usager en mode dit "Auto- Assistance" (Self Care). Selon une troisième possibilité, l'opérateur déclenche une opération de téléchargement en mode campagne sur quelques milliers d'usagers ciblés afin que le serveur OTA administre le téléchargement de l'application dans toutes ces cartes. Pour tous les téléchargements ci-dessus depuis le serveur de campagne, l'établissement d'un canal de communication entre le serveur et une carte pendant une campagne de téléchargement est décidé par l'opérateur et initié dans le serveur. Ces téléchargements fonctionnent en "mode push". Selon une première réalisation du mode push, le téléchargement se fait par l'envoi d'une série de messages courts SMS, formatés par le serveur de campagne en fonction d'un protocole connu vers une carte, puis envoyés à la carte à travers un réseau de radiocommunications de type GSM de l'opérateur. Cette réalisation est décrite dans la demande de brevet français 0410225 déposée le 27 septembre 2004 par le demandeur et non publiée, intitulée "Campagne de téléchargement de données dans des objets communicants portables". L'établissement de la communication du mode push qui requiert l'utilisation de la technologie SMS, est un inconvénient pour les réseaux 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 CDMA (Code Division Multiple Access). Un autre inconvénient est l'indisponibilité des cartes dont les terminaux sont éteints ou hors de la couverture du réseau de radiocommunications pendant la campagne, ce qui nécessite de nombreux essais ultérieurs. Pour remédier à ces inconvénients, une deuxième réalisation consiste en un téléchargement depuis un réseau de radiocommunications de nouvelle génération de type GPRS ou UMTS à travers un canal de données type IP (Internet Protocol). Un serveur de campagne initie une campagne pour télécharger des données vers de nombreuses cartes à puce par l'envoi d'un message court dit "SMS de push" à destination des cartes. Dès qu'une carte Cn a reçu le message SMS, elle ouvre un canal de communication par l'intermédiaire d'un terminal mobile accueillant la carte et une passerelle de type GGSN (Gateway GPRS Support Node) d'un réseau de données afin d'ouvrir une session pour communiquer directement avec le serveur de campagne et de recevoir les données concernées par la campagne. Une campagne de téléchargement s'effectue souvent de façon massive (quelques millions de cartes) sur une durée relativement courte pouvant aller de quelques jours à quelques mois et conduit ainsi à un pic de trafic sur le réseau de radiocommunications. Pendant cette période, le réseau est fortement sollicité, ce qui nécessite une infrastructure bien dimensionnée, capable de supporter une surcharge temporaire. La gestion des nouveaux essais sans savoir si le terminal mobile portant la carte est à nouveau sous la couverture du réseau accroît encore la surcharge du réseau. Les inconvénients précités sont remédiés par une troisième réalisation décrite dans la demande de brevet français 0552365 déposée le 28 juillet 2005 par le demandeur et non publiée. Cette troisième réalisation renverse le mode push actuel en un mode d'interrogation par la carte qui initie pendant une campagne de téléchargement une communication avec un serveur de campagne afin d'obtenir un contenu mis à disposition par l'opérateur du réseau de radiocommunications. L'invention a pour objectif de remédier aux inconvénients précités par un téléchargement de données vers au moins un objet communicant, tel qu'une carte, ciblé par la campagne quand ce dernier est réputé présent dans le réseau de radiocommunications pendant une durée telle que le serveur de campagne puisse exécuter un téléchargement des données prévues dans l'objet communicant. Ceci a pour avantage, entre autres, de supprimer la gestion des ré-essais par le serveur de téléchargement et d'éviter un pic de trafic sur le réseau de radiocommunications dû à la campagne. Pour atteindre cet objectif, un procédé pour télécharger des données mises à disposition dans un serveur de campagne vers des objets communicants portables à travers un réseau de radiocommunications pendant une campagne de téléchargement de données, est caractérisé en ce qu'il comprend les étapes de : transmettre des règles de campagne relatives à la campagne depuis le serveur de campagne à un serveur de présence, et notifier par le serveur de présence au serveur de campagne qu'un évènement relatif à la présence d'au moins un objet communicant dans le réseau de radiocommunications satisfait à une règle de campagne transmise afin d'initier un téléchargement des données depuis le serveur de campagne vers l'objet communicant présent. L'invention peut davantage optimiser les campagnes massives lancées depuis un serveur de campagne grâce à la transmission de règles de campagne dans le serveur de présence connecté au réseau de radiocommunications. Une règle de campagne peut inclure au moins un identificateur d'un objet communicant ciblé par la campagne et au moins une condition de présence de l'objet communicant dans le réseau de radiocommunications. La règle de campagne identifie ainsi d'une manière non ambiguë un évènement de présence d'un objet communicant, tel qu'une carte à puce, ciblé par la campagne dans le réseau de radiocommunications. Cet évènement de présence indique au serveur de campagne que l'objet communicant est disponible dans le réseau de radiocommunications pendant une durée prédéterminée suffisante de connexion de l'objet communicant au réseau de radiocommunications pour recevoir les données à télécharger prévues par la campagne. Selon une autre caractéristique du procédé de l'invention, après transmission des règles de campagne par le serveur de campagne vers le serveur de présence, le serveur de présence combine chaque règle de campagne relative à un objet communicant ciblé avec des règles de présence relatives à au moins une plage horaire d'accessibilité dudit objet communicant ciblé afin qu'un évènement relatif à la présence de l'objet communicant ciblé dans le réseau de radiocommunications satisfasse à la fois aux règles de campagne et présence combinées. Lorsque la campagne est détectée terminée, les règles de campagne peuvent être supprimées dans le serveur de présence. L'invention a aussi pour objet un système pour télécharger des données mises à disposition dans un serveur de campagne vers des objets communicants portables à travers un réseau de radiocommunications pendant une campagne de téléchargement de données. Le système est caractérisé en ce qu'il comprend : un moyen dans le serveur de campagne pour transmettre des règles de campagne relatives à la campagne à un serveur de présence, et un moyen dans le serveur de présence pour notifier au serveur de campagne qu'un évènement relatif à la présence d'au moins un objet communicant dans le réseau de radiocommunications satisfait à une règle de campagne transmise afin d'initier un téléchargement des données depuis le serveur de campagne vers l'objet communicant présent. Les objets communicants peuvent être des cartes à puce d'usager amovibles de terminaux mobiles, ou bien des terminaux mobiles. Selon une réalisation préférée, le réseau de radiocommunications est un réseau à accès multiple à répartition par codes CDMA par exemple UMTS ou UTRAN. Selon une autre réalisation, le réseau de radiocommunications est un réseau GSM adossé à un réseau GPRS. L'invention peut ne pas recourir à une infrastructure comportant un serveur de messages courts. Le système de l'invention peut comprendre un réseau par paquets sans utiliser des messages courts. Enfin, l'invention se rapporte à un programme informatique apte à être mis en oeuvre dans un système pour télécharger des données mises à disposition dans un serveur de campagne vers des objets communicants portables à travers un réseau de radiocommunications pendant une campagne de téléchargement de données. Le programme comprend des instructions qui, lorsque le programme est exécuté dans ledit système, c'est-à-dire pour partie dans le serveur de campagne et pour partie dans le serveur de présence, 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 préférées de l'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 des objets communicants portables, un serveur de campagne géré par un opérateur réseau et un serveur de présence pour la mise en oeuvre du procédé de téléchargement selon l'invention ; -la figure 2 est un bloc-diagramme schématique plus détaillé relatif à la figure 1 ; et - la figure 3 est un algorithme du procédé de téléchargement selon l'invention. Dans la figure 1 sont représentés des moyens principaux pour télécharger des données dans des objets communicants portables, tels que des cartes à puce d'usager amovibles Cl à CN qui sont associées respectivement à des terminaux radio mobiles T1 à TN, rattachés a un réseau de radiocommunications cellulaire numérique RR. La carte à puce Cn associée au terminal mobile Tn, avec l'indice n tel que 1 Un serveur de campagne SC selon l'invention est en général géré par l'opérateur du réseau RR et constitue une plateforme OTA (Over The Air) comportant des données à télécharger vers les cartes à puce ciblées par une campagne de téléchargement. Un serveur de présence SP détecte dans le réseau de radiocommunications RR la présence de cartes à puce ciblées par la campagne de téléchargement selon des règles de campagne RGC préparées et transmises au serveur SP par le serveur de campagne SC. Les règles de campagne RGC sont décrites plus en détail en référence à la figure 2. Le serveur de campagne SC et le serveur de présence SP communiquent entre eux par un premier canal de données d'un réseau de paquets RP de type internet ou intranet. Selon un premier cas, les deux serveurs SC, SP sont localisés chez le même opérateur, réduisant ainsi des problèmes d'adressage IP et de résolution de nom. Selon un deuxième cas, les deux serveurs sont localisés chez des opérateurs distincts et communiquent alors par une connexion sécurisée entre les deux serveurs. Le serveur de campagne SC communique avec les cartes à puce Cl à CN associées aux terminaux T1 à TN par un deuxième canal de données CD ouvert 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. Ce deuxième canal de données CD ne traverse pas le serveur de présence SP. La passerelle de communication peut comporter une passerelle d'accès pour communiquer avec le serveur SC à travers le réseau de paquets RP à haut débit, tel que l'internet, ou tel qu'un réseau intranet propre à l'opérateur du réseau RR. Une autre passerelle d'accès de la passerelle de communication communique avec au moins un commutateur du réseau de radiocommunications, à travers bien souvent un réseau d'accès tel qu'un réseau de paquets de type X.25. Selon une réalisation particulière, la passerelle de communication échange avec les terminaux radio mobiles T1 à TN des messages qui encapsulent des paquets IP (Internet Protocol) transmis vers et par le serveur SC à travers les réseaux RR et RP. Selon la réalisation illustrée à la figure 1, lors du lancement d'une campagne, le serveur de campagne SC transmet une requête de présence RQP comportant des règles de campagne RGC au serveur de présence SP via le réseau de paquets RP. Dès qu'une règle de campagne RGC appliquée à une carte à puce Cn est satisfaite dans le serveur de présence SP, ce dernier transmet une notification de présence NP comportant un identificateur IDCn de la carte Cn au serveur de campagne SC afin que ce dernier télécharge des données D dans la carte à puce Cn. Les différentes étapes du procédé sont plus détaillées en référence à la description de la figure 3. Dans la figure 2, on a représenté le serveur de campagne SC, le serveur de présence SP, le terminal Tn et la carte à puce Cn sous forme de blocs fonctionnels dont la plupart assurent des fonctions ayant un lien avec l'invention et peuvent correspondre à des modules logiciels et/ou matériels. Le serveur de campagne SC comprend un gestionnaire de campagne GEC qui gère diverses opérations au cours du téléchargement et une interface de communication ICC pour transmettre et recevoir des paquets IP à travers le réseau de paquets RP. Le gestionnaire de campagne GEC prépare en particulier les règles de campagne RGC relatives à une ou des campagnes de téléchargement à transmettre au serveur de présence. Une règle de campagne RGC est liée à une identification non ambiguë d'un évènement de présence d'une carte à puce Cn ciblée par la campagne dans le réseau de radiocommunications RR, ce qui signifie que la carte Cn est disponible dans le réseau pendant un temps suffisant pour recevoir un téléchargement complet de données D depuis le serveur de campagne SC. La règle de campagne RGC inclut au moins un identificateur IDCn d'une carte à puce ciblée Cn par une campagne, tel qu'un numéro de série de la carte ou une identité internationale IMSI (International Mobile Subscriber Identity) de l'usager de la carte, et au moins une condition de présence. Par exemple, la condition de présence de la carte à puce Cn dans le réseau de radiocommunications RR est une connexion de la carte à puce comportant l'identificateur IDCn au réseau de radiocommunications RR pendant une durée prédéterminée, typiquement plus de cinq minutes. Un événement de présence EP de la carte à puce ciblée est détecté par le serveur de présence SP dès que la condition de présence incluse dans la règle de campagne transmise depuis le serveur de campagne vers le serveur de présence est satisfaite. En général, une règle de campagne RGC inclut les identificateurs de nombreuses cartes à puce ciblées par une campagne et une ou plusieurs conditions de présence. Selon un autre exemple, une condition de présence est une localisation des terminaux supportant les cartes à puce dans une zone de localisation dans le réseau RR. Le serveur de campagne SC est lié à une base de données BD incluant divers paramètres et caractéristiques des cartes gérées par l'opérateur de réseau de radiocommunications RR. Ces paramètres et caractéristiques sont entre autres nécessaires à la préparation des règles de campagne RGC. Chaque carte à puce Cn est associée à une table TCn dans la base de données BD. La table TCn comprend notamment des caractéristiques initiales qui sont liées à l'identité de la carte Cn et au type de la carte et qui sont enregistrées dans la base de données BD dès la mise en service de la carte. Ces caractéristiques initiales sont notamment un numéro de série de la carte, l'identité internationale IMSI (International Mobile Subscriber Identity) de l'usager de la carte et le numéro téléphonique de l'usager mobile MSISDN (Mobile Station ISDN Number). Le type de la carte Cn est défini notamment par un identificateur du type du processeur inclus dans la carte, l'identificateur du fabricant de la carte, un nombre de bits par mot traité par le processeur, des caractéristiques du système d'exploitation et de la machine virtuelle implémentée dans la carte, etc. D'autres caractéristiques propres à l'utilisation de la carte et notamment de l'usager de la carte peuvent être également enregistrées dans la table TCn associée à la carte Cn lors de la mise en service de la carte, et peuvent être modifiées lors de l'utilisation de la carte. Ces autres caractéristiques concernent notamment le profil d'abonnement de l'usager de la carte Cn, des données pouvant être modifiées par l'usager ou par l'opérateur gérant la carte telles qu'un répertoire de numéros téléphoniques et d'adresses e-mail, et par exemple un fichier d'identificateurs de réseaux de radiocommunications préférés PPLMN (Preferred Public Land Mobile Network). Ces réseaux identifiés dans le fichier PPLMN sont gérés par des opérateurs avec lesquels l'opérateur du réseau RR auquel est rattachée la carte Cn a passé des accords pour que l'usager de la carte Cn communique à travers ces réseaux lorsque l'usager est en déplacement sur des territoires couverts par ces réseaux. La table TCn peut contenir également un ou plusieurs identificateurs d'applications IAP qui ont été chargées lors de la mise en service de la carte à puce Cn et/ou ont été téléchargées ultérieurement à sa mise en service. Par exemple une application consiste à modifier le fichier d'identificateurs de réseaux préférés PPLMN. Selon un autre exemple, l'application consiste à effacer ou télécharger une application dans la carte Cn par exemple pour faciliter la gestion du répertoire des numéros téléphoniques dans la carte Cn en permettant à l'usager, chaque fois qu'il enregistre un nouveau numéro téléphonique dans la carte, de sauvegarder tout son répertoire dans un serveur spécifique géré par l'opérateur afin que l'usager puisse retrouver son répertoire sauvegardé lorsqu'il perd la carte Cn ou lorsqu'il change de carte. Une autre application peut servir à modifier des paramètres dans une application déjà téléchargée dans la carte Cn ; par exemple les paramètres à modifier sont une actualisation de tarifs de rechargement et d'unités de communication lorsque l'usager est abonné à un compte prépayé, ou la mise à jour d'un nom publicitaire de l'opérateur ou de l'un de ses services. La base de données BD, ou en variante le serveur SC, contient également une ou plusieurs tables de campagne TCA respectivement attribuées à des campagnes. Chaque table de campagne TCA inclut un ou plusieurs contenus Ct à télécharger vers les cartes. Chaque contenu Ct contient des données D à télécharger. Les données sont par exemple des données de mise à jour d'une application, ou un message publicitaire. Chaque contenu Ct contient également un descriptif DSD des données D tel que l'identificateur IAP de l'application concernée par le téléchargement ou la liste des identificateurs de cartes à puce ciblées par la campagne de téléchargement TCA. La base de données BD peut être incorporée au serveur de campagne SC, ou être indépendante sous la forme d'un serveur de gestion de base de données qui est relié au serveur SC par un réseau de paquets tel que le réseau RP, c'est-à-dire via l'internet ou via un réseau intranet propre à l'opérateur du réseau RR. Le serveur de présence SP comprend un gestionnaire de présence GEP qui gère diverses opérations relatives à la détection d'événements de présence de cartes à puce dans le réseau de radiocommunications RR et satisfaisant à une ou plusieurs règles de campagne RGC. Le serveur de présence comporte dans le gestionnaire de présence des règles de présence RGP programmées par des usagers abonnés à un service présence et reposant sur des plages horaires d'accessibilité de terminaux des usagers. Un usager abonné à un service présence programme selon ses activités des plages horaires d'appel de ses terminaux pendant lesquelles un autre usager peut l'appeler. Par exemple, l'usager abonné programme les plages horaires d'accessibilité de trois terminaux : un téléphone fixe de bureau sur lequel il souhaite être appelé entre 8 h et 14 h, un terminal mobile ou une messagerie électronique sur lequel il souhaite être contacté entre 14 h et 19 h et un téléphone fixe de domicile sur lequel il souhaite être appelé après 19 h et avant 8 h. Dès qu'un deuxième usager appelle l'usager abonné sur son téléphone fixe de domicile en plein après-midi, le serveur de présence en est informé et soit renvoie l'appel selon la programmation des plages horaires d'appel par l'usager abonné par exemple vers le terminal mobile de celui-ci, soit émet un message destiné au deuxième usager lui indiquant les modalités telles que l'adresse du terminal et la plage horaire d'accessibilité de celui-ci. L'usager abonné peut transmettre via son terminal mobile, ou un autre dispositif de communication, un message M comportant les règles de présence RGP au serveur de présence SP. Le serveur de présence comprend également une interface de communication ICP pour transmettre et recevoir des paquets IP à travers le réseau de paquets RP, et recevoir des messages M pouvant être de type IP transmis par un élément de contrôle du réseau de radiocommunications RR pour indiquer qu'une carte à puce Cn comportant l'identificateur IDCn est connectée au réseau. Le terminal Tn contient un lecteur LT qui est associé à un port d'entrée/sortie PES de la carte à puce Cn avec ou sans contact électrique. Outre le lecteur de carte LT, le terminal comprend un processeur PT, des mémoires MT, un afficheur AT tel qu'un écran connecté ou intégré au terminal et associé notamment à un clavier connecté ou intégré au terminal, et une interface réseau IR. Les différents éléments du terminal sont reliés entre eux par un bus bidirectionnel BT. La carte à puce Cn comprend principalement sous forme intégrée un ou plusieurs microprocesseurs PC et trois mémoires M1 à M3. La mémoire M1 est une mémoire non réinscriptible du type ROM ou Flash incluant le système d'exploitation de la carte. La mémoire M2 est une mémoire non volatile du type EEPROM ou Flash pour notamment mémoriser des clés, des numéros d'identité et d'autres paramètres du profil de l'utilisateur possédant la carte, comme un code PIN et autres données de sécurité. La mémoire M3 est du type RAM ou SRAM servant plus particulièrement au traitement de données. La carte Cn échange des commandes, ou requêtes, et des réponses avec le terminal Tn à 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. En référence à la figure 3, le procédé de téléchargement selon l'invention comprend des étapes El à E5. L'étape El comporte principalement deux étapes initiales E10 et E11. A l'étape initiale E10, le terminal Tn d'un usager abonné au service présence envoie un message M comportant les règles de présence RGP relatives aux plages horaires d'accessibilité pour appeler des terminaux de l'usager abonné. Ces règles RGP peuvent être transmises via un autre dispositif de communication. A l'étapeinitiale E11, l'opérateur du réseau de radiocommunications RR met à disposition un ou plusieurs contenus Ct dans la base de données BD dont les données D doivent être téléchargées pendant une campagne TCA d'opérations communes de téléchargement de données du serveur de campagne SC sur un ensemble de cartes spécifiées selon les descriptifs de données DSD. Le gestionnaire de campagne GEC dans le serveur de campagne traduit les descriptifs DSD liés à la campagne TCA en des identificateurs des cartes à puce ciblées par la campagne TCA et les associe à des conditions de présence pour obtenir des règles de campagne RGC compréhensibles par le serveur de présence SP. En effet, un descriptif d'une campagne de téléchargement requérant la mise à jour d'une application dans des cartes peut ne comporter que l'identificateur IAP de l'application. Le serveur de présence n'étant pas relié à la base de données BD du serveur de campagne, ignore le contenu des cartes à puce qui sont réputées présentes dans le réseau de radiocommunications. L'étape E2 est relative à la transmission des règles RGC de la campagne TCA depuis l'interface de communication ICC du serveur de campagne SC vers l'interface de communication ICP du serveur de présence SP par l'intermédiaire du premier canal de données et comprend les étapes E20 à E25. A l'étape E20 lors de l'initiation de la campagne TCA, le serveur de campagne SC qui a préparé les règles de campagne RGC relatives à la campagne TCA, transmet au serveur de présence SP une requête de présence RQP comportant une règle de campagne RGC. A la réception de la requête RQP, le serveur de présence peut retourner un acquittement AQ1 à l'étape E21. Le serveur de campagne transmet autant de requêtes RQP qu'il y a de règles de campagne. En variante, le serveur de campagne transmet une seule requête de présence comportant une liste des règles de campagne. Après réception de toutes les règles de campagne RGC, le gestionnaire de présence GEP les mémorise dans le serveur de présence SP, à l'étape E22, en les combinant avec les règles de présence RGP déjà mémorisées et relatives aux plages horaires d'accessibilité des terminaux des usagers possédant une carte à puce ciblée par la campagne TCA. Ainsi si une carte à puce Cn satisfait à une règle de campagne RGC mais ne satisfait pas à une règle de présence RGP relative à la plage horaire d'accessibilité du terminal Tn, l'événement de présence EP associé ne sera pas déclenché. Par exemple une règle de campagne comprend la condition suivante : une carte à puce Cn comportant un identificateur IDCn est connectée au réseau de radiocommunications RR depuis plus de cinq minutes. Si à 11 h 55 mn la carte à puce Cn ciblée par la campagne se connecte au reseau de radiocommunications RR et qu'une règle de présence RGP indique qu'à 12 h l'usager de ladite carte à puce va déconnecter du réseau RR le terminal Tn comportant la carte, l'événement de présence EP n'est pas déclenché et le gestionnaire de présence GEP ne le détecte pas. A l'étape E23, le serveur de présence SP transmet optionnellement au serveur de campagne SC une notification NP1 indiquant, entre autres, que les règles de campagne transmises ont été mémorisées correctement. Le serveur de campagne peut retourner un acquittement AQ2 au serveur de présence, à l'étape E24. A l'étape E25, le serveur de campagne SC attend une nouvelle notification de présence NP2 comportant des données de présence DP correspondant par exemple aux identificateurs des cartes à puce qui viennent de se connecter sur le réseau de radiocommunications RR et qui respectent les règles RGC et RGP. En variante, la première notification NP1 peut inclure des données de présence DP indiquant au serveur de campagne SC les cartes à puce déjà présentes dans le réseau de radiocommunications RR au lancement de la campagne TCA et respectant les règles de campagne et de présence. Dans cette variante, le procédé se poursuit par l'étape E4 pour chaque carte à puce respectant lesdites règles. L'étape E3 correspond à la détection d'un événement de présence EP par le serveur de présence SP, l'événement EP correspondant à la connexion d'une carte à puce Cn au réseau de radiocommunications RR et la carte Cn respectant les règles de campagne RGC et les règles de présence RGP si ces dernières sont mémorisées dans le serveur de présence et correspondent à la carte. A l'étape E30, au moins la carte à puce Cn se connecte au réseau RR et la connexion de la carte à puce Cn est détectée par un dispositif de contrôle inclus dans le réseau de radiocommunications RR. Le dispositif de contrôle peut être l'enregistreur de localisation nominale HLR (Home Location Register) du réseau RR. Le dispositif de contrôle transmet, à l'étape E31, au serveur de présence SP un message M1 comportant l'identificateur IDCn de la carte Cn connectée et des données de connexion DCO relatives à la connexion de la carte. Une donnée de connexion DCO indique par exemple l'instant de connexion de la carte. Le message M1 peut être transmis au serveur de présence SP selon une périodicité prédéfinie. A la réception du message M1, le gestionnaire de présence GEP du serveur de présence SP fait correspondre, à l'étape E32, l'identificateur IDCn de la carte Cn et les données de connexion DCO aux règles de campagne RGC combinées aux règles de présence RGP désignées par l'identificateur de carte IDCn. Si les règles de campagne et de présence applicables à la carte Cn ainsi identifiée par l'identificateur IDCn sont respectées par les données DCO, un évènement de présence EP est considéré détecté par le gestionnaire GEP à l'étape E33. Le serveur de présence SP transmet au serveur de campagne SC, à l'étape E34, une notification de présence NP2 comportant des données de présence DP relatives à la carte à puce Cn respectant les règles RGC et RGP. Le serveur de campagne peut retourner un acquittement AQ3 au serveur de présence, puis procède au téléchargement des données D dans la carte à puce Cn à l'étape E4. Dans le cas où au moins l'une des règles combinées RGC et RGP applicables à la carte Cn n'est pas respectée, le serveur de campagne SC n'est pas sollicité par une notification NP2. Le serveur de présence SP attend la satisfaction de règles de campagne et de présence par la carte Cn ou toute autre carte et le procédé passe de l'étape E33 à l'étape de connexion E30. L'étape E4 initiée par la détection de l'événement de présence EP concerne le téléchargement des données D par le serveur de campagne SC dans la carte à puce Cn qui respecte au moins une règle de campagne RGC via le deuxième canal de données CD ne traversant pas le serveur de présence SP. A l'étape E40, le serveur de campagne transmet un message tel qu'un SMS à la carte à puce pour initier l'ouverture du deuxième canal de données CD. Le message SMS contient une adresse du serveur de campagne SC. Dès que la carte a reçu le message SMS, elle ouvre, à l'étape E41, par l'intermédiaire du terminal Tn le canal de données CD de type IP entre le terminal Tn et la passerelle entre les réseaux RR et RP afin d'ouvrir une session pour communiquer directement avec le serveur de campagne SC. A l'étape E42, le serveur de campagne SC télécharge les données D définies dans la campagne TCA dans la carte Cn, qui les traite à l'étape E43. Par exemple la carte met à jour une application concernée par le téléchargement. Après traitement des données D, la carte transmet à l'étape E43, le résultat R du téléchargement au serveur de campagne SC. En fin de téléchargement, le serveur SC ferme la session, par exemple par l'envoi d'une requête de fermeture de session à la carte Cn. A la réception de la requête de fermeture de session, la carte et/ou le serveur de campagne SC libèrent le canal de communication CD entre le terminal Tn et la passerelle. En variante, le serveur de campagne se connecte directement à la carte par une connexion de type IP via un port prédéfini du terminal Tn quand celui-ci est par exemple un ordinateur personnel offrant déjà une connexion internet ou intranet. L'étape E5 correspond à la fin de la campagne TCA une fois que toutes les cartes à puce ciblées ont été traitées. A l'étape E50, le serveur de campagne vérifie si toutes les cartes à puce ciblées par la campagne TCA ont été traitées. Si des cartes n'ont pas encore été traitées, le serveur de campagne attend d'autres notifications de présence NP2 provenant du serveur de présence à l'étape E25. Si toutes les cartes ciblées par la campagne ont été traitées, la campagne TCA est terminée et le serveur de campagne transmet à l'étape E51 une requête de suppression de règle de campagne RQS. A la réception de la requête RQS, le serveur de présence SP supprime toutes les règles RGC relatives à la campagne TCA, à l'étape E52. En variante, les règles de campagne relatives à des cartes à puce déjà traitées peuvent être supprimées alors que la campagne TCA n'est pas terminée. L'invention n'est pas limitée à un téléchargement de données dans des cartes à puce du type UICC. Une carte à puce dans laquelle des données sont à télécharger peut être également une carte incluse dans un ordinateur portable relié à un terminal mobile, ou une carte de paiement, une carte de porte-monnaie électronique ou toute autre carte additionnelle liée à un terminal mobile. 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 s'applique également à des terminaux mobiles visés par une campagne pour lesquels les données à télécharger peuvent concerner un jeu à enregistrer dans la mémoire non volatile de type EEPROM des terminaux mobiles. L'invention décrite ici concerne un procédé et un système pour télécharger des données mises à disposition dans un serveur de campagne vers des objets communicants portables. Selon une implémentation préférée, les étapes du procédé de l'invention sont déterminées par les instructions d'un programme informatique incorporé dans le système et en particulier pour partie dans le serveur de campagne et pour partie dans un serveur de présence. 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 l'invention. En conséquence, l'invention s'applique également à un programme, notamment un programme sur ou dans un support d'informations, adapté à mettre en oeuvre l'invention. REVENDICATIONS 1 - Procédé pour télécharger des données (D) mises à disposition dans un serveur de campagne (SC, BD) vers des objets communicants portables (Cl -CN) à travers un réseau de radiocommunications (RR) pendant une campagne de téléchargement de données, caractérisé en ce qu'il comprend les étapes de : transmettre (E2, E20) des règles de campagne relatives à la campagne depuis le serveur de campagne à un serveur de présence (SP), et notifier (E3, E34) par le serveur de présence au serveur de campagne qu'un évènement (EP) relatif à la présence d'au moins un objet communicant (Cn) dans le réseau de radiocommunications satisfait à une règle de campagne transmise afin d'initier (E4) un téléchargement des données depuis le serveur de campagne vers l'objet communicant présent. 2 - Procédé conforme à la revendication 1, selon lequel une règle de campagne inclut au moins un identificateur (IDCn) d'un objet communicant (Cn) ciblé par la campagne et au moins une condition de présence de l'objet communicant dans le réseau de radiocommunications (RR). 3 - Procédé conforme à la revendication 1 ou 2, selon lequel une condition de présence de l'objet communicant dans le réseau de radiocommunications est une connexion de l'objet communicant (Cn) au réseau de radiocommunications (RR) pendant une durée prédéterminée. 4 - Procédé conforme à l'une quelconque des revendications 1 à 3, selon lequel après transmission (E20) des règles de campagne (RGC) par le serveur de campagne (SC) vers le serveur de présence (SP), le serveur de présence combine (E22) chaque règle de campagne relative à un objet communicant ciblé (Cn) avec des règles de présence (RGP) relatives à au moins une plage horaire d'accessibilité dudit objet communicant ciblé afin qu'un évènement (EP) relatif à la présence de l'objet communicant ciblé dans le réseau de radiocommunications satisfasse à la fois aux règles de campagne et présence combinées. 5 - Procédé conforme à l'une quelconque des revendications 1 à 4, selon lequel lorsque la campagne est terminée (E50), les règles de campagne (RGC) sont supprimées (E52) dans le serveur de présence (SP). 6 - Procédé conforme à l'une quelconque des revendications 1 à 5, selon lequel lesdites données (D) sont téléchargées par le serveur de campagne (SC) dans l'objet communicant présent (Cn) via un canal de données (CD) ne traversant pas le serveur de présence (SP). 7 - Système pour télécharger des données (D) mises à disposition dans un serveur de campagne (SC, BD) vers des objets communicants portables (Cl -CN) à travers un réseau de radiocommunications (RR) pendant une campagne de téléchargement de données, caractérisé en ce qu'il comprend : un moyen (ICC) dans le serveur de campagne pour transmettre des règles de campagne relatives à la campagne à un serveur de présence (SP), et un moyen (GEP, ICP) dans le serveur de présence pour notifier au serveur de campagne qu'un évènement (EP) relatif à la présence d'au moins un objet communicant (Cn) dans le réseau de radiocommunications satisfait à une règle de campagne transmise afin d'initier un téléchargement des données depuis le serveur de campagne vers l'objet communicant présent. 8 - Système conforme à la revendication 7, caractérisé en ce que les objets communicants sont des cartes à puce d'usager (Cl - CN) amovibles de terminaux mobiles (T1 - TN). 9 - Système conforme à la revendication 7, caractérisé en ce que les objets communicants sont des terminaux mobiles (T1 - TN). 10 - Système conforme à l'une quelconque des revendications 7 à 9, caractérisé en ce que le réseau de radiocommunications est un réseau à accès multiple à répartition par codes CDMA. 11 - Programme apte à être mis en oeuvre dans un système pour télécharger des données (D) mises à disposition dans un serveur de campagne (SC, BD) vers des objets communicants portables (Cl - CN) à travers un réseau de radiocommunications (RR) pendant une campagne de téléchargement de données, caractérisé en ce qu'il comprend des instructions qui, lorsque le programme est exécuté dans ledit système, réalisent les étapes suivantes : transmettre (E2, E20) des règles de campagne relatives à la campagne depuis le serveur de campagne à un serveur de présence (SP), et notifier (E3, E34) par le serveur de présence au serveur de campagne qu'un évènement (EP) relatif à laprésence d'au moins un objet communicant (Cn) dans le réseau de radiocommunications satisfait à une règle de campagne transmise afin d'initier (E4) un téléchargement des données depuis le serveur de campagne vers l'objet communicant présent.