ES2341363T3 - Descarga de datos iniciada por los objetos comunicantes portatiles durante una campaña. - Google Patents

Abstract

Procedimiento para descargar para descargar datos de contenido (Dc) puestos a disposición en un medio servidor (SAC, BD) hacia objetos comunicantes portátiles (C1-CN) a través de una red de radiocomunicaciones (RR) durante una campaña de descarga de datos (TCA), que comprende una iniciación en un objeto comunicante portátil (Cn) de una descarga de datos hacia dicho objeto por un envió (P5) de una solicitud de disponibilidad de contenido hacia el medio servidor de que por lo menos un elemento de activación de envió de solicitud satisface (P2) una regla memorizada en el objeto comunicante portátil, caracterizado porque comprende en el objeto comunicante portátil etapas de: determinar (P7-P8) si datos de contenido están disponibles comparando (P7) datos (Drq) que caracterizan el objeto comunicante portátil con descripciones de contenido (Ddcv) que se asocian a los datos de contenido (Dc) memorizados en el medio servidor y enviados por el medio servidor como respuesta a la solicitud de disponibilidad de contenido, y enviar (P11) identificadores de contenido (Idc) relativos a los datos de contenido disponibles determinados (Dc) para que el medio servidor transmita (P12) dichos datos de contenido disponibles determinados al objeto comunicante portátil.

Description

Descarga de datos iniciada por los objetos comunicantes portátiles durante una campaña.

La presente invención concierne la descarga de datos desde un servidor hasta objetos comunicantes portátiles a través de una red de radiocomunicación durante una campaña de descarga. En particular, tiene relación con una descarga de datos iniciada por los objetos comunicantes portátiles. Los objetos comunicantes son tarjetas chip, como las tarjetas UICC (Universal Integrated Circuito(s) Card) provistas de la aplicación USIM (Universal Subscriber Identity Module), asociadas a los terminales móviles de la red de radiocomunicaciones que es por ejemplo del tipo GPRS (General Packet Radio Service) o UMTS (Universal Mobile Telecommunications System).

El servidor de descarga de datos, igualmente llamado plataforma de administración de tarjetas OTA (Over The Air), comprende un software que permite al operador que rige la red de radiocomunicaciones conservar el control de las tarjetas chip en los terminales móviles y modificar su contenido. Estas operaciones por iniciativa del operador (modo push) conciernen por ejemplo la descarga de un fichero en tarjetas predeterminadas del parque regido por el operador, o la descarga o el borrado de una aplicación determinada, o bien la modificación de datos de un fichero o de una aplicación determinada en tarjetas regidas por el operador.

La invención se interesa más particularmente a una campaña de descarga maciza de datos de las tarjetas de usuario, aún cuando el servidor de descarga de datos OTA puede realizar una descarga unitaria en una tarjeta de usuario.

Según un primer ejemplo, una descarga sólo es relativa a un fichero personal que está destinado a usuarios ambulantes que se encuentran frecuentemente en el extranjero y que contiene una decena de identificadores de redes preferidas regidos por operadores con los que el operador de la red que rige las tarjetas ha efectuado un contrato. El fichero de identificadores de redes preferidas es único y puede descargarse en numerosas tarjetas de usuario predeterminadas de manera a que los usuarios de dichas tarjetas puedan utilizarlo cuando están en el extranjero.

Para este primer ejemplo, el operador dispone actualmente de dos posibilidades para descargar este fichero desde el servidor OTA. Según una primera posibilidad, el operador decide descargar el fichero de manera unitaria, siguiendo la corriente, la primera vez que un usuario interesado está en itinerancia (roaming), y así sucesivamente para todos los usuarios unos tras otros, que están en itinerancia. Según una segunda posibilidad, dicha en modo de campaña, el servidor envía el fichero de los identificadores de redes preferidas en una sola campaña hacia las tarjetas cuyos usuarios hubieran suscrito una opción de itinerancia.

En modo campaña el número de usuarios objetivo puede alcanzar varios centenares de miles o millones.

Según un segundo ejemplo, una descarga concierne una aplicación que facilita la gestión del directorio de los números telefónicos en las tarjetas. Esta aplicación permite a un usuario salvaguardar todo su directorio en un servidor predeterminado regido por el operador cada vez que el usuario registra un nuevo número telefónico en su tarjeta.

Según este segundo ejemplo, se proponen tres posibilidades. A raíz de una publicidad presentada en la televisión, el usuario llama durante el día al centro de llamada del operador para solicitar descargar la aplicación en su tarjeta. Esta operación es una operación unitaria que activa en el servidor OTA el operador en modo "Asistencia Cliente" (Customer Care). Según una segunda posibilidad, el usuario toma la iniciativa de encargar descargas consultando él mismo desde su terminal portátil el sitio Web del operador de manera a activar la descarga de la aplicación en la tarjeta. Esta descarga es igualmente una operación unitaria solicitada en el servidor OTA por el usuario en modo dicho "Auto-Asistencia" (Self Care). Según una tercera posibilidad, el operador activa una operación de descarga en modo campaña en más de un millón de usuarios objetivo con el fin de que el servidor OTA administre la descarga de la aplicación en el millón de tarjetas.

Para todas las descargas anteriores desde el servidor de descarga OTA, el establecimiento de una canal de comunicación entre el servidor y una tarjeta durante una campaña de descarga es decidido por el operador e iniciado en el servidor. Estas descargas funcionan en "modo push".

Según una primera realización del modo push la descarga se hace por el envió de una serie de mensajes cortos SMS, formateados por el servidor de descarga en función de un protocolo conocido hacia una tarjeta, y seguidamente enviados a la tarjeta a través de una red de radiocomunicaciones de tipo GSM del operador. Esta realización se describe en la solicitud de patente francesa 0410225 registrada el 27 de septiembre de 2004 por el solicitante y no publicada, llamada "Campaña de descarga de datos en objetos comunicantes portátiles". El establecimiento de la comunicación del modo push que requiere la utilización de la tecnología SMS, es un inconveniente para las redes cuyas infraestructuras no aceptan los mensajes cortos o para los cuales los mensajes cortos no satisfacen las normas necesarias para una actualización a distancia, por ejemplo de tarjetas en redes CDMA (Code División Múltiple Access). Otro inconveniente radica en la indisponibilidad de las tarjetas cuyos terminales están apagados o fuera de cobertura de la red de radiocomunicaciones durante la campaña.

Para solucionar estos inconvenientes, una segunda realización ilustrada en la figura 1 y en relación con la invención, consiste en efectuar la descarga desde la parte fija de una re de radiocomunicaciones de nueva generación de tipo GPRS o UMTS a través de un canal de datos tipo IP (Internet Protocol).

Un servidor de descarga ST inicia una campaña, en la etapa S1, para descargar datos D hacia numerosas tarjetas mediante el envió, en la etapa S2, de un mensaje corto dicho "SMS de push" destinado a las tarjetas. El mensaje SMS contiene un identificador Idap de la aplicación concernida por la campaña y opcionalmente la dirección AdsT del servidor de descarga ST. En cuanto una tarjeta C ha recibido el mensaje SMS, abre, a las etapas S3 a S6, un canal de comunicación con el terminal portátil T que acogió la tarjeta, y una pasarela P del tipo GGSN (Gateway GPRS Support Node) de una red de datos. En la etapa S3, la tarjeta envía una solicitud RQ al terminal T para abrir un canal de comunicación. El terminal T transmite, en la etapa S4, una solicitud para establecer una conexión de tipo IP a la pasarela P de la red de radiocomunicaciones. En la etapa S5, la pasarela P transmite al terminal T una respuesta RP indicando que la conexión IP está establecida. En la etapa S6 el terminal transmite a la tarjeta una respuesta indicando que el canal de comunicación está abierto. De este modo, en la etapa S1, la tarjeta abre una sesión para comunicar directamente con el servidor de descarga ST que descarga, en la etapa S8, el contenido D definido en la campaña hacia la tarjeta C. Ésta última actualiza una aplicación AP concernida por la descarga en la etapa S9 y envía en respuesta, a la etapa S10, el resultado de la descarga al servidor ST. Al final de la descarga en la etapa S11, el servidor ST cierra la sesión por ejemplo, mediante el envío de una solicitud de cierre de sesión. Cuando recibe la solicitud de cierre de sesión, la tarjeta cierra su canal de comunicación con el terminal y la pasarela P en las etapas S12 a S15 análogas a las etapas S3 a S6.

El modo push implica algunas obligaciones o limitaciones vinculadas a la disponibilidad de las tarjetas en la red de radiocomunicaciones. Las solicitudes de descarga para todas las tarjetas indisponibles en el momento preciso de la ejecución de la campaña se hacen fracasar y se tratan ulteriormente por un mecanismo de nueva prueba. Al final de la campaña, no se han alcanzado todas las tarjetas, puesto que ciertas tarjetas no están conectadas a la red durante el periodo de nueva prueba.

Durante una descarga en modo campaña, el cambio muy frecuente de afectación de una parte de las tarjetas no es considerado en la gestión por el servidor de una lista de tarjetas objetivo. En efecto, en el transcurso de la campaña de descarga, nuevos abonados y por tanto nuevas tarjetas aparecen en la red, los abonados existentes cambian de tarjeta y las tarjetas inutilizadas o utilizadas en otras redes desaparecen de la red. Por consiguiente, como la campaña se extiende desde varios días hasta varias meses, la lista de las tarjetas objetivo no se reactualiza durante todo el periodo de la campaña.

Además, una campaña de descarga se efectúa a menudo de manera masiva (varios millones de tarjetas) durante un periodo relativamente corto que puede durar de varios días a varios meses y conduce de ese modo a un pico de tráfico en la red de radiocomunicaciones. Durante este periodo, la red es muy solicitada y necesita una infraestructura bien dimensionada, capaz de soportar una sobrecarga temporal. La gestión de las nuevas pruebas sin saber si el terminal portátil que tiene la tarjeta está de nuevo bajo la cobertura de la red aumenta aún más la sobrecarga de la red.

El documento WO 2005/0504401 describe un procedimiento de descarga de datos tal y como se describe en el preámbulo de la reivindicación 1. Este procedimiento comprende el envió de una solicitud de descarga desde un teléfono portátil, esta solicitud identifica la versión del software presente en el teléfono, así como las partes del software que se han corrompido en el teléfono. Las partes del software corrompidas se transmiten entonces al teléfono, así como las partes del software que deben actualizarse.

El documento US-6577614 describe un sistema de telecomunicaciones de tipo CDMA en el que se transmiten parámetros actualizados desde un servidor hasta un terminal portátil vía OTA. El usuario del terminal portátil decide con el operador de red las actualizaciones que deben descargarse.

La presente invención concierne un procedimiento conforme a la reivindicación 1.

La invención presenta una mejor distribución en la carga de la red, las comunicaciones entre los objetos comunicantes portátiles y el medio servidor durante la campaña de descarga que se efectúa a merced de los elementos de activación de envió de solicitud en los objetos comunicantes, como eventos predeterminados en cada uno de los objetos comunicantes independientemente de los eventos predeterminados en los otros objetos comunicantes, y no de una manera sistemática.

La invención también es ventajosa por una reducción significativa de los riesgos de fracaso de las operaciones de actualización de los objetos comunicantes portátiles puesto que éstos últimos inician la descarga solamente cuando todos ellos son la cobertura de la red de radiocomunicaciones.

Según una primera realización de la invención, cuando uno de los dispositivos es el objeto comunicante portátil, cuando se reciben los datos de contenido procedentes del medio servidor, el objeto comunicante portátil trata los datos de contenido recibidos y envía una notificación al medio servidor.

Otra ventaja de la invención radica en liberarse de la gestión de las listas de objetos comunicantes en el medio servidor, la descarga de datos de contenido se efectúa en características funcionales y estructurales de los objetos comunicantes; por ejemplo, se descargan datos hacia todos los objetos comunicantes portátiles que tienen un perfil específico o hacia todos los objetos comunicantes que tienen el suficiente espacio en la memoria para acoger una nueva aplicación.

Otro objetivo de la invención consiste en un sistema para descargar datos de contenido puestos a disposición en un medio servidor hacía objetos comunicantes portátiles a través de una red de radiocomunicaciones durante una campaña de descarga de datos. El sistema de comunicación se caracteriza por comprender en cada objeto comunicante portátil un medio para iniciar una descarga de datos hacia dicho objeto mediante un envío de una solicitud de disponibilidad de contenido hacia el medio servidor en cuanto por lo menos un elemento de activación de envío de solicitud satisface una regla memorizada en el objeto comunicante portátil para determinar si están disponibles datos de contenido para el objeto comunicante portátil para transmitírselos.

Los objetos comunicantes pueden ser tarjetas chip de usuario amovibles de terminales móviles, o bien terminales móviles.

Según una realización preferida, el sistema comprende una red de accesos múltiple con distribución de códigos CDMA, por ejemplo UMTS o UTRAN. Según otra realización, el sistema comprende una red GSM adosada a una red GPRS.

La invención puede no recurría a una infraestructura que comprende un servidor de mensajes cortos. El sistema de la invención puede comprender una red por paquetes sin utilizar mensajes cortos.

Por último, la invención se refiere a un programa en condiciones de ser aplicado en el sistema de comunicación para descargar datos de contenido puestos a disposición en un medio servidor hacia objetos comunicantes portátiles a través de una red de radiocomunicaciones durante una campaña de descarga de datos. El programa comprende instrucciones para iniciar mediante un objeto comunicante portátil una descarga de datos hacia dicho objeto por un envió de una solicitud de disponibilidad de contenido hacia el medio servidor en cuanto por lo menos un elemento de activación de envió de solicitud satisface una regla memorizada en el objeto comunicante portátil, y las instrucciones para determinar en uno de los dispositivos que comprenden el medio servidor y el objeto comunicante portátil si se encuentran disponibles datos de contenido para el objeto comunicante portátil con el fin de transmitírselos.

Otras características y ventajas de la presente invención aparecerán más claramente cuando se lea la siguiente descripción de varias realizaciones preferidas de la invención, que se dan a título de ejemplos no limitativos, en referencia a los dibujos en anexo correspondientes, en los que:

La figura 1, es un algoritmo de un procedimiento de descarga de datos según la técnica anterior, iniciado por5 un servidor de descargar de tarjeta hacia una tarjeta chip, con intercambio de solicitudes y respuestas entre el servidor de descarga y la tarjeta chip;

La figura 2 es un bloque-diagrama esquemático de un sistema de comunicación que une objetos comunicantes portátiles y un servidor de administración de objeto comunicante regido por un operador de red, para la aplicación del procedimiento de descarga según el invento;

La figura 3 es un bloque-diagrama esquemático más detallado relativo a la figura 2;

La figura 4 es un algoritmo de una primera realización del procedimiento de descarga según la invención, con intercambio de solicitudes y respuestas entre el servidor de administración y el objeto comunicante portátil; y

La figura 5 es un algoritmo de una segunda realización del procedimiento de descarga según el invento, con intercambio de solicitudes y respuestas entre el servidor de administración y el objeto comunicante portátil.

En la figura 2 se representan medios principales para descargar datos en objetos comunicantes portátiles, tales como tarjetas chip de usuario amovibles C1 a CN, que están asociadas respectivamente a terminales radio portátiles T1 a TN, vinculados a una red de radiocomunicaciones celulares digital RR. La tarjeta chip Cn asociada al terminal portátil Tn, con el índice n tal como 1 \leq n \leq N, es del tipo UICC (Universal Integrated Circuit(s) Card). La tarjeta chip está provista por ejemplo de una aplicación SIM (Subscriber Identity Module) cuando la red RR es del tipo GSM, o de una aplicación USIM (Universal Subscriber Identity Module) cuando la red RR tiene accesos múltiples con distribución de códigos CDMA (Coded División Múltiple Access) de la tercera generación (3GPP) del tipo UMTS (Universal Mobile Telecommunications system) o UTRAN (UMTS Terrestrial Radio Access Network).

Un servidor de administración de tarjeta SAC según la invención es regido por el operador de la red RR y constituido por una plataforma OTA (Over The Air). Según la realización ilustrada en la figura 2 a la que nos referimos a continuación, las tarjetas C1 a CN asociadas a los terminales móviles respectivos T1 a TN transmiten solicitudes de disponibilidad de contenido Rq que pueden ir acompañadas de datos Drq asociados hacia el servidor SAC y reciben datos de contenido Dc transmitidos por el servidor SAC, a través de una pasarela de comunicación PA.

La pasarela comprende una pasarela de acceso para comunicar con el servidor SAC a través de una red de paquetes RP de gran velocidad, tal como Internet, o una red intranet propia al operador de la red RR. Otra pasarela de acceso de la pasarela de comunicación PA comunica por lo menos con un conmutador del servicio portátil, a través muy a menudo de una red de acceso, tal como una red de paquetes de tipo X, 25 o una red RNIS (Red Digital de Integración de Servicio) o ATM (Asynchronous Transfert Mode). Las solicitudes de disponibilidad de contenido Rq y los datos Drq asociados se transportan en mensajes M por un terminal portátil Tn destinados al servidor SAC y están formateados en la pasarela PA en paquetes IP (Internet Protocol) transmitidos hacia el servidor SAC; al contrario, datos de contenido De se transmiten en paquetes IP por el servidor SAC destinados al terminal portátil Tn y se transmiten por la pasarela PA en forma de mensajes M hacia el terminal Tn.

Los mensajes M pueden encapsular los paquetes IP que comprenden una solicitud Rq y datos Drq. La pasarela PA extrae los paquetes IP de los mensajes M transmitidos por el terminal Tn para transmitirlos al servidor SAC. Al contrario, los paquetes IP que proceden del servidor SAC están encapsulados en mensajes M para ser transmitidos por vía radio al terminal Tn.

Como variante, la pasarela de comunicación PA está vinculada directamente o se incorpora a un conmutador del servicio portátil en la red RR.

Según otra realización, la pasarela de comunicación PA es una red de acceso de tipo red de conmutación por paquetes con gestión de la movilidad y acceso por vía radio GPRS (General Packet Radio Servive), si la red de radiocomunicaciones RR es del tipo GSM. Un nudo de servicio SGSN (Serving GPRS Support Node) de la red GPRS está vinculado a por lo menos un controlador de estación de base de la red RR. Un nudo pasarela GGSN (Gateway GPRS Support Node) de la red GPRS está vinculado a la red de paquetes RP que comunican con el servidor SAC. El interés de esta realización consiste en transmitir mensajes en forma de paquetes a velocidades muy elevadas.

Según todavía otra realización, la pasarela de comunicación PA sirve para intercambiar mensajes entre los terminales radio portátiles y el servidor SAC a través de las redes RR y RP según un enlace por paquetes a velocidad elevada de tipo internet.

En la red de radiocomunicaciones RR del tipo UMTS o del tipo GSM adosado a una red GPRS, una solicitud de disponibilidad de contenido Rq asociada a datos Drq y los datos de contenido Dc se intercambian entre un terminal portátil Tn y la tarjeta asociada Cn según el protocolo BIP (Bearer independent Protocol), o por mediación de una aplicación (Midlet) dedicada embarcada en el terminal que comunica con la tarjeta vía un protocolo aplicativo específico, como por ejemplo el protocolo J2ME (Java 2 Mobile Edition). La solicitud de disponibilidad de contenido Rq asociada a datos Drq y los datos de contenido Dc se intercambian, por ejemplo, entre la tarjeta Cn y el servidor SAC según el protocolo de transporte CAT->TP (Card Application ToolkitTransport Protocol) en un enlace UDP/IP (User Datagram Protocol/Internet Protocol).

En referencia a la figura 3, hemos representado el servidor de administración SAC, el terminal Tn y la tarjeta chip Cn en forma de bloques funcionales, cuya mayoría aseguran funciones que tienen un vínculo con la invención y pueden corresponder a módulos de software y/o materiales.

El servidor administrativo SAC comprende un gestor GE que rige diversas operaciones durante la descarga y una interfaz de comunicación IC para transmitir y recibir paquetes IP a través de la red de paquetes RP.

El servidor de administración de tarjeta SAC está vinculado a una base de datos BD que comprende diversos parámetros y características de las tarjetas regidas por el operador de red de radiocomunicaciones RR.

Cada tarjeta chip Cn está asociada a una tabla TCn en la base de datos BD. La tabla TCn comprende, principalmente, características iniciales que están vinculadas a la identidad de la tarjeta Cn y al tipo de la tarjeta y que están registradas en la base de daros BD en cuanto se pone en servicio la tarjeta. Estas características iniciales son, principalmente, un número de serie de la tarjeta, la identidad internacional IMSI (International Mobile Subscriber Identity) del usuario de la tarjeta, y el número telefónico del usuario portátil MSISDN (Mobile Station ISDN Number). El tipo de la tarjeta Cn es definido, en particular, por un identificador del tipo del procesador incluido en la tarjeta, el identificador del fabricante de la tarjeta, un número de bits por palabra tratado por el procesador, características del sistema de explotación y de la máquina virtual implementada en la tarjeta, etc.

Otras características propias a la utilización de la tarjeta y principalmente del terminal del usuario Tn pueden registrarse igualmente en la tabla TCn asociada a la tarjeta Cn en el momento de la puesta en servicio de la tarjeta y pueden modificarse cuando se utiliza la tarjeta. Estas otras características conciernen principalmente el perfil de abono del usuario de la tarjeta Cn, el usuario o el operador que rigen la tarjeta pueden modificar datos, tales como un repertorio de números telefónicos y direcciones e-mail, y por ejemplo un fichero de identificadores de redes de radiocomunicaciones preferidas PPLMN (Preferred Public Land Mobile Network). Estas redes identificadas en el fichero PPLMN las rigen los operadores, con los que el operador de la red RR, al que está vinculada la tarjeta Cn, ha pasado acuerdos para que el usuario de la tarjeta Cn comunique a través de dichas redes, cuando el usuario está en desplazamiento en territorios cubiertos por dichas redes.

La tabla Tn contiene igualmente uno o varios identificadores de aplicaciones IAP que fueron cargadas durante la puesta en servicio de la tarjeta chip Cn y/o fueron descargados ulteriormente a su puesta en servicio. Por ejemplo, una aplicación consiste en modificar el fichero de identificadores de redes preferidos PPLMN. Según otro ejemplo, la aplicación consiste en borrar o descargar una aplicación en la tarjeta Cn, por ejemplo, para facilitar la gestión del repertorio de los números telefónicos en la tarjeta Cn para permitir al usuario, cada vez que registre un nuevo número telefónico en la tarjeta, salvaguardar todo su repertorio en un servidor especifico regido por el operador con el fin de que el usuario pueda encontrar su repertorio salvaguardado cuando pierde la tarjeta Cn o cuando cambia de tarjeta. Otra aplicación puede servir para modificar parámetros en una aplicación ya descargada en la tarjeta Cn; por ejemplo, los parámetros que deben modificarse son una actualización de tarifas de recambio y de unidades de comunicación cuando el usuario está abonado a una cuenta pagada previamente.

La base de datos BD, o en variante el servidor SAC, contiene igualmente una o varias tablas de campaña TCA respectivamente atribuidas a campañas. Cada tabla de campaña TCA incluye uno o varios contenidos Ct que de descargarán en las tarjetas. Cada contenido Ct contiene datos de contenido D a descargar. Los datos de contenido son por ejemplo datos de actualización de una aplicación, o un mensaje publicitario. Cada contenido Ct contiene igualmente una descripción Dddc de los datos Dc y un identificador Idc del contenido Ct.

Cada tabla TCA incluye igualmente informaciones de selección IFs que se compararán sea con los datos Drq enviados por la tarjeta, sea con características de la tarjeta Cn memorizadas en la tabla TCn, para decidir si debe efectuarse o no una descarga. Las informaciones IFs son por ejemplo un identificador IAP de una nueva versión de una aplicación que debe actualizarse en la tarjeta, un umbral de crédito de actualización autorizado o una lista de los números telefónicos MSISDN y de direcciones de las tablas asociadas a las tarjetas que entran en la campaña, que serán supuestas ser las N tarjetas C1 a CN a continuación, y los tramos horarios de la campaña.

La base de datos BD puede incorporarse al servidor de administración de tarjeta SAC, o ser independiente en la forma de un servidor de gestión de base de datos que está vinculado al servidor SAC por una red de paquetes, tal como la red RP, es decir, por mediación de Internet o de una red Intranet propia al operador de la red RR.

El terminal Tn comprende, además del lector de tarjeta LT, principalmente un procesador PT, de las memorias MT, un visualizador AT, tal como una pantalla conectada o integrada al terminal y asociada, principalmente, a un teclado conectado o integrado al terminal, y una interfaz red IR. Los distintos elementos del terminal están vinculados entre sí por un bus bidireccional BT.

La tarjeta chip Cn comprende principalmente un procesador PC, o varios procesadores, y tres memorias M1 a M3. La tarjeta intercambia mandos, o solicitudes, y respuestas con el terminal T, a través de un puerto entrada/salida PES y el lector LT con o sin contacto. Los distintos elementos de la tarjeta están vinculados entre sí por un bus bidireccional BC.

La memoria M1 es del tipo ROM o Flash e incluye el sistema de explotación de la tarjeta.

La memoria M2 es una memoria no volátil por ejemplo EEPROM o Flash para, principalmente, memorizar claves, números de identidad y otros parámetros del perfil del usuario que posee la tarjeta, como un código PIN y otros datos de seguridad. La memoria M32 comprende igualmente aplicaciones AP de la tarjeta.

La memoria M2 comprende reglas de activación RG que rigen la activación de una solicitud de disponibilidad de contenido sobre la base de uno o varios elementos de activación EL. Estos elementos de activación son por ejemplo datos de fecha y hora proporcionados por una base de tiempo diaria, semanal o mensual, y/ indicadores de eventos exteriores tales como el lanzamiento del terminal, la recepción o la emisión de una llamada, o el lanzamiento de una aplicación AP por el usuario, y/o indicadores de control deducidos de un control sobre el entorno de la tarjeta relativo a un cambio de terminal, un paso en itinerancia o un cambio de zona geográfica. Indicadores de control están acoplados a indicadores de eventos con el fin de activar un modo de interrogación por la tarjeta. Las reglas de activación RG pueden modificarse en el transcurso del tiempo por el servidor de administración de tarjeta SAC.

La memoria M2 comprende igualmente los datos Drq que están, sea vinculados a las reglas que activan la solicitud Rq como por ejemplo un cambio de la zona geográfica donde se sitúa el terminal, sea vinculadas a una aplicación AP residente en la tarjeta como por ejemplo un identificador IAP de la versión de la aplicación, sea vinculadas al entorno red/terminal portátil como por ejemplo el tipo de tarjeta.

La memoria M3 es una memoria RAM o SRAM que sirve más particularmente para el tratamiento de los datos.

La tarjeta Cn comprende además, relativamente a la invención, un módulo software llamado agente Ag distribuido en las memoria M1 y M2. Cuando uno o varios elementos de activación EL satisfarán una regla de activación RG, el gente Ag envía la solicitud de disponibilidad de contenido Rq y los datos Drq hacia el servidor SAC y recibe los datos de contenido Dc y los trata. El agente Ag rige igualmente la abertura y cierre de un canal de comunicación entre la tarjeta Cn y el servidor SAC.

Como variante, el agente Ag puede estar distribuido en varios agentes individuales, incluidos respectivamente en ciertas aplicaciones y que presentan cada uno de ellos funcionalidades con relación a la aplicación respectiva equivalente a aquellas del agente general Ag al que nos referiremos a continuación a título de ejemplo.

En referencia a la figura 4, una primera realización del procedimiento de descarga iniciado por la tarjeta Cn según la invención comprende etapas E0 a E154.

En la etapa inicial E0 el operador de la red de radiocomunicaciones RR pone a disposición uno o varios contenidos Ct en la base de datos BD cuyos datos Dc deben descargarse durante una campaña TCS de operación es comunes de descarga de datos del servidor de administración de tarjeta SAC en un conjunto de tarjetas específicas o filtradas según las informaciones de selección IFs.

Después de la puesta a disposición de los contenidos Ct que comprenden cada uno de ellos datos de contenido Dc, un descriptivo Ddc y un identificador de contenido Idc, el gestor GE espera recibir una solicitud de disponibilidad de contenido Rq procedente de una tarjeta chip, en la etapa E1.

En la etapa E2, uno o varios elementos de activación EL que satisfacen una regla RG memorizada en la tarjeta Cn son detectados por el agente Ag de la tarjetea Cn, como por ejemplo el lanzamiento del terminal Tn o un tiempo predeterminado pasado. De este modo, en las etapas E3 a E4, el agente Ag abre un canal de comunicación CDC con el servidor SAC a través de la red de radiocomunicaciones RR y la red de paquetes RP. La abertura del canal CDC entre la tarjeta Cn y el servidor SAC comprende etapas análogas a las etapas S3 a S6 descritas anteriormente en referencia a la figura 1.

En la etapa E5, el agente Ag forma una solicitud de disponibilidad de contenido Rq y la asocia a datos Drq. El agente puede mutualizar las solicitudes de disponibilidad de contenido de varias aplicaciones de la tarjeta Cn en una sola solicitud Rq incluyendo en los datos Drq una lista de parámetros relativos a las aplicaciones concernidas. El gente Ag de la tarjeta Cn encarga el envió de la solicitud Rq y de datos Drq en forma de un mensaje M desde la interfaz red IR del terminal Tn. La solicitud Rq y los datos Drq se extraen a continuación del mensaje M y se transmiten por medio de la pasarela PA hacia el servidor SAC.

En la etapa E6, la interfaz de comunicación IC del servidor SAC recibe la solicitud Rq y los datos Drq. El gestor GE del servidor SAC determina si datos de contenido Dc de uno o varios contenidos Ct están disponibles para la tarjeta chip Cn por un análisis de artos Drq en función de las informaciones de selección IFs y/o de las descripciones de contenido Ddc de cada contenido Ct. En la etapa E7, le gestor GE compara los datos Drq recibidos con las informaciones de selección IFs y/o con las descripciones de contenido Ddc memorizadas en la tabla TCA. Si la tarjeta Cn no pone a disposición ningún dato de contenido Dc, es decir, por ejemplo si las informaciones IFs no comprenden la identidad IMSI de la tarjeta entre las identidades IMSi de las tarjetas seleccionadas para la campaña de descarga, entonces el gestor GE transmite por mediación de la interfaz IC, de la etapa E8, una respuesta RPN a la tarjeta Cn indicando que está no tiene a su disposición ningún dato Dc.

Cuando recibe la respuesta RPN, el agente Ag en la tarjeta Cn cierra el canal de comunicación CDC con el servidor SAC en las etapas E9 y E10. El cierre del canal CDC entre la tarjeta Cn y el servidor SAC comprende etapas análogas a las etapas S12 a S15 descritas anteriormente en referencia a la figura 1.

En el caso contrario, si datos Drq corresponden a informaciones IFs y/o a la descripción Ddc de un contenido Ct puesto a disposición en la etapa E7, entonces el gestor GE transmite a la etapa E11 todo o parte de los datos de contenido Dc del contenido Ct. Estos datos Dc se transmiten por la interfaz de comunicación IC del servidor SAC en paquetes IP destinados al terminal portátil Tn acoplado a la tarjeta Cn y se envían por la pasarela PA en forma de uno o varios mensajes M hacia el terminal Tn.

En cuanto se reciben estos datos Dc, el agente Ag en la tarjeta Cn trata los datos Dc recibidos para cada aplicación concernida en la etapa E12. Según un primer ejemplo, el agente Ag actualiza la o las aplicaciones AP vinculadas a los elementos de activación detectados en la etapa E2. Según otro ejemplo, los datos Dc son datos publicitarios que se visualizaran en el visualizador AT del terminal Tn.

Luego, en las etapas E14 y E15 el canal de comunicación CDC entre la tarjeta y el servidor SAC se cierra de la misma manera que en las etapas E9 y E10.

En la etapa E12, una notificación NFT puede enviar al servidor SAC la tarjeta Cn antes del cierre E14-E15 del canal CDC. La notificación NTF evita que el contenido sea enviado una segunda vez a la tarjeta Cn. Así, en la recepción de la notificación NTF en la etapa E11, el servidor SAC confirma por modificación en la base de datos BD en la etapa E13 que el contenido puesto a disposición ya fue descargado en la tarjeta Cn.

Una aplicación concreta del procedimiento de la invención es la actualización de un portal de servicio del usuario de la tarjeta Cn. El operador de la red RR desea efectuar una actualización en un conjunto de tarjetas, pero cada usuario sólo dispone de un crédito de actualización limitado de su portal. El operador pone a disposición en el servidor SAC, como descripción de contenido Ddc relativo al contenido Ct una información que describe el portal objetivo, por ejemplo, el número de versión del portal y como informaciones de selección IFs elementos de activación relativos a la validación de la descarga, por ejemplo, un crédito de actualización suficiente.

La solicitud de disponibilidad de contenido Rq enviada por la tarjeta Cn va acompañada de los datos Drq que comprenden la versión corriente del portal, así como el número de actualizaciones todavía autorizadas para esta
tarjeta.

En cuanto se recibe la solicitud Rq y los datos Drq, el gestor GE del servidor SAC comprueba en primer lugar si existe una verdadera necesidad de actualización del portal incluso en la descripción Ddc y el número de versión del portal incluido en los datos recibidos Drq. Luego, el gestor comprueba si el usuario de la tarjeta Cn aún tiene la posibilidad de actualizar su portal comprobando el número de actualizaciones aún autorizado comprendido en los datos recibidos Drq en función de las informaciones IFs.

Si el número de actualizaciones autorizado es igual al crédito de actualización de las informaciones IFs, entonces el servidor SAC decremento el crédito de actualización y envía los datos de actualización del portal de servicio a la tarjeta Cn que decrementa el número de actualizaciones.

Según otro ejemplo, una aplicación concierne la televisión de peaje en terminal portátil para la cual el agente actualiza derechos de acceso a programas audiovisuales para el usuario de la tarjeta.

Según una variante referente a las etapas E5 a E7 de la primera realización del procedimiento de la invención, el análisis y la comparación con las etapas E6 y E7 ya no se efectúan en función de las características de la tarjeta incluidas en la tabla TCn memorizada en la base de datos BD.

De este modo, en la etapa E5, el agente Ag forma una solicitud de disponibilidad de contenido Rq sin asociar a ello datos Drq y encarga el envió de la solicitud Rq desde la interfaz red IR del terminal Tn hacia el servidor SAC.

En las etapas E6 y E7, la interfaz de comunicación IC del servidor SAC recibe la solicitud Rq. El gestor GE del servidor SAC determina si datos de contenido Dc de uno o varios contenidos Ct están disponibles para la tarjeta chip Cn efectuando una búsqueda de las características de la tarjeta Cn memorizados en la tabla TCn en función de las informaciones de selección IFs y/o de las descripciones de contenido Ddc de los contenidos Ct.

La figura 5 ilustra una segunda realización del procedimiento de descarga de datos de la invención. El algoritmo representado en la figura 5 comprende las etapas P0 a P15. En esta segunda realización, el servidor SAC no está conectado a una base de datos y comprende, aparte el gestor GE y la interfaz de comunicación IC, una memoria que contiene las tablas de campañas TCA. Cada tabla de campaña TCA comprende uno o varios contenidos Ct cada uno de ellos incluye datos de contenido Dc, una descripción de contendido Ddc y un identificador de contenido Idc.

Las etapas P0 a P4 son idénticas a las etapas E0 a E4 referenciadas en la figura 3.

En la etapa P5, el agente Ag hace una solicitud de disponibilidad de contenido Rq y encarga el envío de la solicitud Rq en forma de un mensaje M desde la interfaz red IR del terminal Tn. La solicitud Rq y los datos Drq se extraen seguidamente del mensaje M y se transmiten por medio de la pasarela PA hacia el servidor SAC.

En la etapa P6, en respuesta a la solicitud Rq, el servidor envía los pares (Ddc, Idc) de todos los contenidos Ct que se ponen en disposición en la etapa E0.

Cuando se reciben los pares (Ddc, Idc), el agente Ag analiza en la etapa P7 las descripciones Ddc enviadas en función del contenido de la tarjeta, por ejemplo en función de los datos Drq memorizados en la memoria M2 o en función de las características o de los identificadores IAP de las aplicaciones implementadas en la tarjeta Cn. El agente Ag determina de este modo si deben descargarse en la etapa P8 datos de contenido.

En el supuesto que no debiera descargarse ningún dato de contenido, el Agente Ag en la tarjeta Cn cierra el canal de comunicación CDC con el servidor SAC en las etapas P9 y PIO del mismo modo que en las etapas E9 y E10 en referencia a la fig. 4.

En caso contrario a la etapa P8, si deben descargarse datos Dc, entonces el agente Ag envía al servidor SAC el o los identificadores Idc relativos respectivamente a uno o varios contenidos Ct que incluyen los datos requeridos Dc, en la etapa P11.

En la etapa P12, el gestor GE del servidor SAC envía los datos Dc relativos a los identificadores Idc recibidos.

Cuando se reciben estos datos Dc, el agente Ag en la tarjeta Cn trata los datos DSc recibidos para cada aplicación concernida en la etapa P13. Una notificación NTF puede enviarse al final del tratamiento al servidor SAC indicándole el resultado del tratamiento.

Seguidamente, en las etapas P14 y P15 el canal de comunicación CVDC entre la tarjeta y el servidor SAC está cerrado de la misma manera que en las etapas P9 y P10.

Según una variante relativa a las realizaciones precedentes del procedimiento de la invención, el agente Ag no efectúa directamente la distribución de los datos Dc para las aplicaciones implementadas en la tarjeta Cn, en las etapas E12 y P13. El servidor SAC envía entonces sucesivamente a la tarjeta datos de contenido Dc relativos respectivamente a las aplicaciones concernidas. En la práctica, para cada aplicación concernida, el servidor SAC envía un mando de tratamiento de los datos de contenido como respuesta a una notificación de acuse de recibo AQ del tratamiento de datos Dc para la aplicación anterior, transmitida por la tarjeta Cn.

Cuando una aplicación se distribuye entre la tarjeta y el terminal portátil, la parte de la aplicación dicha Midlet en el terminal portátil interroga periódicamente al agente individual relativo a la aplicación en la tarjeta con el fin de detecta un elemento de activación EL. Si se detecta este elemento de activación la Midlet abre el canal de comunicación en la etapa E3, P3 con el servidor SAC, luego envía por lo menos la solicitud Rq expedida por el agente. Ulteriormente a la etapa E11, P12, los datos Dc transmitidos por el servidor son recibidos por la Midlet en el terminal que los retransmite al agente en la tarjeta.

Para las realizaciones anteriores y sus variantes, los intercambios de datos Dc, de las notificaciones NTF, de los pares (Ddc, Idc), de los identificadores Idc y de los acuses de recibo AQ entre la tarjeta y el servidor pueden asegurarse. Estos intercambios asegurados se efectúan por una autentificación entre la tarjeta Cn y el servidor SAC y/o por un cifrado de los distintos datos intercambios.

La invención no está limitada a una descarga de datos en tarjetas chip del tipo UICC. Una tarjeta chip en la que se descargarán datos puede ser también una tarjeta incluida en un ordenador portátil conectada a un terminal portátil, o una tarjeta de pago, una tarjeta de monedero electrónico o cualquier otra tarjeta adicional incluida en un terminal portátil. Según otras variantes, la invención se aplica a otros objetos electrónicos comunicantes portátiles, tales como asistentes digitales personales comunicantes PDA. La invención se aplica incluso a terminales móviles puestos en mira por una campaña para los cuales los datos que deben descargarse pueden concernir un juego a registrar en la memoria no volátil de tipo EEPROM de los terminales móviles.

La invención descrita aquí concierne un procedimiento y un sistema para descargar datos de contenidos puestos a disposición en un medio servidor hacia objetos comunicantes portátiles. Según una implementación preferida, las etapas del procedimiento de la invención se determinan por las instrucciones de un programa incorporado en el sistema y en particular para parte en el medio servidor y por parte en los objetos comunicantes portátiles. El programa comprende instrucciones de programa que, cuando dicho programa está cargado y es ejecutado en el sistema cuyo funcionamiento es entonces ordenado por la ejecución del programa, realizan las etapas del procedimiento según la invención.

Por consiguiente, la invención se aplica igualmente a un programa, principalmente, un programa sobre o en un soporte de informaciones, adaptado a aplicar la invención.

Claims (8)

1. Procedimiento para descargar para descargar datos de contenido (Dc) puestos a disposición en un medio servidor (SAC, BD) hacia objetos comunicantes portátiles (C1-CN) a través de una red de radiocomunicaciones (RR) durante una campaña de descarga de datos (TCA), que comprende una iniciación en un objeto comunicante portátil (Cn) de una descarga de datos hacia dicho objeto por un envió (P5) de una solicitud de disponibilidad de contenido hacia el medio servidor de que por lo menos un elemento de activación de envió de solicitud satisface (P2) una regla memorizada en el objeto comunicante portátil, caracterizado porque comprende en el objeto comunicante portátil etapas de:

determinar (P7-P8) si datos de contenido están disponibles comparando (P7) datos (Drq) que caracterizan el objeto comunicante portátil con descripciones de contenido (Ddcv) que se asocian a los datos de contenido (Dc) memorizados en el medio servidor y enviados por el medio servidor como respuesta a la solicitud de disponibilidad de contenido, y enviar (P11) identificadores de contenido (Idc) relativos a los datos de contenido disponibles determinados (Dc) para que el medio servidor transmita (P12) dichos datos de contenido disponibles determinados al objeto comunicante portátil.

\vskip1.000000\baselineskip

2. Procedimiento conforme a la reivindicación 1, según el cual cuando se reciben datos de contenido (Dc) procedentes del medio servidor (SAC, BD), el objeto comunicante portátil trata (P13) los datos de contenido recibidos y envía una notificación (NTF) al medio servidor.

3. Procedimiento conforme a la reivindicación 1 ó 2 según la cual el medio servidor (SAC, BD) envía sucesivamente para cada una de las aplicaciones implementadas en el objeto comunicante portátil (Cn) un pedido de tratamiento de datos de contenido en respuesta a una notificación de acuse de recibo (AQ) del tratamiento de datos (Dc) para la aplicación precedente, transmitida por el objeto comunicante portátil.

4. Sistema para descargar datos de contenido (Dc) puestos a disposición en un medio servidor (SAC, BD) hacia objetos comunicantes portátiles (C1-CN) a través de una red de radiocomunicaciones (RR) durante una campaña de descarga de datos (TCA), y comprendiendo en cada objeto comunicante portátil (Cn) un medio (Ag) para iniciar una descarga de datos hacia dicho objeto mediante un envió de una solicitud de disponibilidad de contenido hacia el medio servidor en cuanto por lo menos un elemento de activación de envió de solicitud satisface una regla memorizada en el objeto comunicante portátil, caracterizado porque comprende en cada objeto comunicante portátil (Cn):

un medio (Ag) para determinar si datos de contenido están disponibles comparando datos (Drq) que caracterizan el objeto comunicante portátil con descripciones de contenido (Ddc) que están asociados con los datos de contenido (Dc) memorizados en el medio servidor y enviados por el medio servidor como respuesta a la solicitud de disponibilidad de contenido.

5. Sistema conforme a la reivindicación 4, caracterizado por que los objetos comunicantes son tarjetas chip de usuario (C1-CN) amovibles de terminales móviles (T1-TN).

6. Sistema conforme a la reivindicación 4, caracterizado por que los objetos comunicantes son terminales móviles (T1-TN).

7. Sistema conforme a cualquiera de las reivindicaciones 4 a 6 caracterizado por que la red de radiocomunicaciones es una red de acceso múltiple con distribución por códigos CDMA.

8. Programa en condiciones de ser aplicado en un sistema de comunicación para descargar datos de contenido (Dc) puestos a disposición en un medio servidor (SAC, BD) hacia objetos comunicantes portátiles (C1-CN) a través de una red de radiocomunicaciones (RR) durante una campaña de descarga de datos (TCA), el programa comprende en objeto comunicante portátil instrucciones para iniciar mediante un objeto comunicante portátil (Cn) una descarga de datos hacia dicho objeto por un envío (P5) de una solicitud de disponibilidad de contenido hacia el medio servidor en cuanto por lo menos un elemento de activación de envió de solicitud satisface (P2) una regla (RG) memorizada en un medio para enviar (P11) identificadores de contenido (Idc) relativos a los datos de contenido disponibles determinados (Dc) para que el medio servidor transmita (P12) dichos datos de contenido disponibles determinados al objeto comunicante portátil. El objeto comunicante portátil, se caracteriza por que el programa comprende instrucciones para determinar (P7-P8) si datos de contenido están disponibles al comparar (P7) datos (Drq) que caracterizan el objeto comunicante portátil con descripciones de contenido (Ddc) que están asociadas a los datos de contenido (Dc) memorizados en el medio servidor y enviados por el medio servidor como respuesta a la solicitud de disponibilidad de contenido y enviar (P11) identificadores de contenido (Idc) relativos a los datos de contenido disponibles determinados (Dc) para que el medio servidor transmita (P12) dichos datos de contenido disponibles determinados con el objeto comunicante portátil.