ES2717111T3 - Procedimiento, dispositivo y sistema para la ejecución retardada, controlada por reglas, de descargas de software - Google Patents

Description

DESCRIPCIÓN

Procedimiento, dispositivo y sistema para la ejecución retardada, controlada por reglas, de descargas de software La invención se refiere a procedimientos para la transmisión de módulos de software a terminales de abonado de un sistema de radiocomunicación.

El desarrollo y el uso de un nuevo estándar de transmisión en redes de telecomunicación móvil requieren un gran esfuerzo para conseguir una acción conjunta sin complicaciones de los distintos componentes. Según el estado actual, esto se consigue mediante estandarizaciones complejas, como por ejemplo para los estándares de telefonía móvil GSM (“Global System for Mobile Communications" / Sistema Global para Comunicaciones Móviles) o UMTS (“Universal Mobile Telecommunication System" / Sistema de Telecomunicación Móvil Universal), y mediante extensos ensayos de los distintos componentes, observándose especialmente la interacción entre los terminales móviles y los elementos de red en la llamada red de acceso radio, en inglés “Radio Access Network (RAN)". Los terminales según el estado actual de la técnica, sin embargo, están limitados, en cuanto al uso de radiotecnologías, a una selección exactamente definida de llamadas tecnologías de acceso radio, en inglés “Radio Access Technologies (RAT)", ya que cualquier radiotecnología requiere el uso de un hardware específico. Al contrario de ello, los terminales reconfigurables conocidos también como radio definida por software, pueden utilizar, por medio de un transceptor programable vía software, una nueva radiotecnología no soportada hasta entonces, según la que el transceptor se configura de manera correspondiente mediante el intercambio de software. De esta manera, nuevas técnicas de radio y estándares pueden hacerse utilizables mediante una simple descarga de software al terminal, es decir que incluso terminales que ya soportan un estándar de radio pueden adaptarse durante el funcionamiento en marcha, de tal forma que puedan utilizar una nueva radiotecnología.

Una utilización flexible de terminales reconfigurables requiere un mecanismo seguro y fiable para la descarga del software requerido respectivamente, el llamado “software download", a través de la interfaz de aire al terminal. Un mecanismo de descarga de software de este tipo hace posibles no sólo la carga de software para una nueva radiotecnología no soportada hasta entonces, sino además también las llamadas actualizaciones de software y correcciones de errores así como la carga de software de aplicaciones. Generalmente, la carga de software nuevo, por ejemplo, software para soportar nuevas radiotecnologías o nuevas aplicaciones, es impulsada por el usuario o el terminal. Sin embargo, también hay escenarios en los que el fabricante de los terminales o un proveedor de software mismos inicien una descarga de software, por ejemplo en forma de actualizaciones de software suscritas, correcciones de errores urgentes o actualizaciones de firmware.

Sin embargo, el usuario o su terminal pueden encontrarse en una situación en la que una descarga de software iniciada desde fuera resulte desventajosa o imposible desde el punto de vista del usuario de los servicios activados actualmente en el terminal o de la conexión de red. Ejemplos de este tipo de situaciones son que el terminal está apagado, que el ancho de banda disponible de la conexión de red actual es demasiado pequeño, que las nuevas prestaciones contenidas en la actualización de software no funcionan en el entorno de red actual, que el usuario no desea utilizar actualmente nuevas prestaciones contenidas en la actualización de software, que la nueva radiotecnología ofrecida no puede aplicarse en la red de suministro actual o en la situación actual, por ejemplo durante un viaje en un país que no soporta dicha radiotecnología, que una descarga de software sería muy costosa en la situación actual, o que perjudicaría de manera intolerable la prestación de un servicio importante para el usuario.

Un procedimiento posible para evitar descargas de software iniciadas desde fuera consiste en realizar antes de la descarga una negociación con el usuario o con su terminal, en cuanto a la necesidad de la descarga. Las desventajas de este procedimiento consisten en que esto funciona sólo en el estado encendido y con una conexión de red perfecta. Sin embargo, si el usuario se encuentra en ese momento en una red ajena, las negociaciones frecuentes entre proveedores de software y el terminal pueden causar de manera desventajosa considerables costes. Además, el aplazamiento de una descarga a un momento posterior más favorable sólo es posible de manera sencilla si el proveedor de software facilita un procedimiento adecuado para ello.

En los escenarios realizados en la actualidad, las descargas de software a terminales de telecomunicación móvil son iniciadas únicamente por los usuarios. Habitualmente, el software, tratándose por ejemplo de juegos, se descarga de una página web por medio de un “Hypertext Transport Protocol (HTTP)" (protocolo de transporte de hipertexto), para lo cual, la información necesaria para ello (“Uniform Resource Locator, URL" / localizador uniforme de recursos) ha sido determinada por el abonado mismo o bien a través de la página web por medio de un navegador basado en el “Wireless Application Protocol (WAP)" (protocolo de aplicaciones inalámbricas), o bien, le ha sido enviada por el “Short Message Service (SMS)" (servicio de mensajes cortos) por un proveedor, por ejemplo en el marco de una suscripción a un canal de información sobre nuevos juegos. Otros contenidos tales como tonos de llamada, logotipos de pantalla, salvapantallas o mensajes gráficos igualmente pueden cargarse a través de un mecanismo de este tipo. La transmisión de datos basada en HTTP puede efectuarse tanto mediante conmutación de circuitos como mediante conmutación de paquetes, como por ejemplo en el GPRS (“General Packet Radio Service" / servicio general de paquetes vía radio). Para ello, se envía al terminal por SMS o por medio de un mecanismo Wap-Push una notificación relativa a la disponibilidad de nuevo software, conteniendo dicha notificación información sobre el software así como una URL a través de la que puede descargarse el software.

Algo similar es válido también para el llamado “Multimedia Messaging Service (MMS)” (servicio de mensajes multimedia). Al contrario del SMS, sin embargo, un MMS no se transmite al terminal por el mecanismo “Push”, sino que al terminal se envía sólo una llamada indicación de MMS que entre otras contiene una URL. A su vez, el usuario decide si desea cargar el MMS a su terminal o no. Si un MMS no es recogido por el abonado en el plazo de cierto tiempo, vuelve a ser borrado por el “Multimedia Messaging Services Center (MMSC)” (centro de servicios de mensajes multimedia) o se desplaza a una memoria permanente (“Permanente Store”) y se almacena durante un período de tiempo más largo. En este caso, por tanto, el usuario tiene la posibilidad de rechazar la recepción de un MMS por no recogida o al menos aplazar la descarga a un momento más favorable para él.

Estado de la técnica adicional figura en el documento US6023620A que da a conocer un procedimiento para el control de una descarga de software a un teléfono móvil. El procedimiento comprende los pasos de la transmisión de un primer mensaje SMS al teléfono móvil, conteniendo el mensaje un comando para el teléfono móvil de prepararse a una recepción de software, la transmisión de un segundo mensaje SMS por el teléfono móvil, conteniendo el mensaje una confirmación como reacción al primer mensaje, la transmisión del software al teléfono móvil, la recepción del software por el teléfono móvil, y la carga del software transmitido a una memoria inactiva del teléfono móvil.

Estado de la técnica adicional figura en el documento US5896566A que da a conocer un procedimiento para señalar a aparatos móviles la disponibilidad de software actualizado.

La invención tiene el objetivo de proporcionar un procedimiento así como dispositivos de un sistema de radiocomunicación que hagan posible un control flexible de descargas de software a terminales de abonados. Este objetivo se consigue según la invención mediante las características de las reivindicaciones independientes.

Las reivindicaciones independientes correspondientes se refieren a realizaciones ventajosas de la invención.

La invención hace posible de manera ventajosa una ejecución retardada, controlada por reglas, de descargas de software, descritas al principio, a un terminal de abonado. Según una forma de realización, un dispositivo asignado al abonado o al terminal de abonado está realizado en el sentido de un buzón de descarga de software con una funcionalidad, comparable a un contestador automático, en el sistema de radiocomunicación. Dicho dispositivo es direccionado por un proveedor de software en lugar del terminal de abonado. En función de reglas en el dispositivo, que pueden ser modificadas por el abonado y/o el terminal de abonado, un módulo de software es transmitido al terminal de abonado o bien inmediatamente o bien en un momento posterior. En caso de una transmisión en un momento posterior, según otra forma de realización, el módulo de software en primer lugar se almacena de forma intermedia en un dispositivo de memoria.

De manera ventajosa, mediante las características según la invención, la transmisión de módulos de software a un terminal de abonado puede ser controlada de tal forma que se consiga una relación a ser posible óptima entre el precio y la disponibilidad de software para el abonado. Esto puede realizarse por ejemplo de tal manera que una descarga de software al terminal de abonado principalmente se efectúa cuando el coste de conexión es especialmente bajo.

A continuación, la invención se describe en detalle con la ayuda de ejemplos de realización representados en el dibujo. Muestran

la FIGURA 1 una representación para explicar la operación según la invención de un buzón de descarga de software por el operador de red, y

la FIGURA 2 una representación para explicar la operación según la invención de un buzón de descarga de software por el fabricante del terminal.

Una parte esencial de la invención consiste en la introducción de un dispositivo que en lo sucesivo se designa como buzón de descarga de software y que en representación de un terminal reconfigurable funciona como destinatario para actualizaciones de software iniciadas por el fabricante del terminal o el proveedor de servicios. Su función es básicamente comparable a un buzón de voz tal como lo ofrecen en la actualidad los operadores de telefonía móvil. Al contrario de un buzón de voz, sin embargo, el buzón de descarga de software puede configurarse de manera mucho más flexible. Esto se realiza a través de llamadas políticas (“policies”) que generalmente se formulan mediante bloques de reglas que el usuario puede generar, modificar y borrar a través de su terminal móvil. Dichas políticas controlan el comportamiento del buzón de descarga de software para rechazar inmediatamente una actualización de software iniciada por el fabricante del terminal o el proveedor de servicios, porque se clasificó como indeseable o irrelevante, o para aceptarla y o bien transmitirla inmediatamente al terminal o bien almacenarla de forma intermedia para un ajuste posterior al terminal.

El mecanismo de decisión en que se basa este comportamiento se refiere además de a información estadística también a la situación actual en la que se encuentran el terminal o el usuario. Por ejemplo, una estancia fuera de la red base (“Home Network”), es decir, en el caso de “roaming”, en otra red de telefonía móvil o en otro país, puede conducir a que con vistas a los costes originados para el usuario en estos casos, sólo descargas muy determinadas sean transmitidas al terminal, mientras que todas las descargas clasificadas como menos importantes se realicen sólo posteriormente, cuando el terminal regrese a la red base.

Un aspecto importante de la presente invención consiste además en el almacenamiento intermedio eficiente de software en el buzón de descarga de software para el caso de que una descarga deba aplazarse a un momento posterior más favorable. Para realizar el almacenamiento de manera eficiente, el mecanismo para el almacenamiento intermedio se realiza de tal forma que a ser posible se evite un almacenamiento múltiple del mismo módulo de software para diferentes usuarios. Esto se puede conseguir por ejemplo almacenando en el buzón de descarga de software sólo la notificación de actualización de software, mientras los módulos de software correspondientes son mantenidos disponibles o bien por el proveedor de software, es decir por el fabricante de terminales o un proveedor de servicios, para su descarga posterior, o bien son almacenados de forma intermedia por el operador de la red de telefonía móvil en un dispositivo de memoria que en lo sucesivo se designa como repositorio de software que es administrado por un servidor de descarga de software del operador. Durante un posterior ajuste de actualizaciones de software al terminal, el buzón de descarga de software ordena al servidor de descarga de software efectuar la actualización.

Además del soporte de procesos de descarga de software son posibles diversos otros usos del buzón de descarga de software. Una aplicación interesante consiste en el almacenamiento intermedio de servicios de banda ancha abonados como por ejemplo adelantos de nuevos lanzamientos musicales, de nuevas películas de vídeo o de cine, o de nuevos juegos de ordenador, o en el almacenamiento intermedio de mensajes instantáneos con anexos, cuya transmisión requiere un gran ancho de banda. Un almacenamiento intermedio de este tipo se produce de manera similar ya para el MMS descrito al principio, pero en este caso, el abonado no tiene ninguna posibilidad de o bien volver a eliminar inmediatamente determinados mensajes, o bien transferirlos inmediatamente al terminal. El uso del buzón de descarga de software para este fin permite un manejo de los datos mencionados, configurable de forma flexible y específico para situaciones determinadas.

La configurabilidad flexible se consigue usando llamadas políticas que se componen de bloques de reglas. El abonado puede generar, modificar y borrar políticas o bien a través de su terminal reconfigurable, o bien a través de un mecanismo basado en la Web. Las políticas son válidas respectivamente para determinados tipos de uso. Una política puede estar caracterizada por el papel del usuario, por ejemplo uso profesional o particular, así como por el lugar de estancia, es decir, en la red de telefonía móvil del operador propio, en la red de otro operador nacional o en la red de un operador extranjero, y por la situación actual del usuario, es decir, por ejemplo, en la calle, en una reunión o durmiendo. Dicho de manera general, una política correspondiente se define para un contexto determinado. Dentro de una política hay diferentes tipos de datos como por ejemplo una actualización de software, una corrección de error importante o un mensaje instantáneo importante, existen respectivamente reglas que establecen cómo se debe proceder con los datos en el contexto asociado a la política. Para mantener reducido el número de políticas y reglas que han de ser definidas se pueden especificar también contextos y reglas genéricos, por ejemplo, el contexto “de viaje en cualquier papel” o una regla válida para “cualquier transmisión de datos, cuyo volumen de datos exceda un límite dado”, así como contextos y reglas excluyentes, por ejemplo el contexto “no durmiendo” o una regla válida para “todos los datos salvo correcciones de error importantes”.

Las diferentes políticas opcionalmente además pueden priorizarse o ponerse en un orden para poder resolver conflictos entre políticas contradictorias.

Entre las acciones posibles que pueden activarse al coincidir una regla de política determinada, opcionalmente, además de las acciones base mencionadas ya del “rechazo de los datos”, del “almacenamiento intermedio de los datos” y de la “transmisión de los datos al terminal”, pueden figurar también acciones como la “actualización automática de paquetes de software adicionales por el buzón de descarga de software”.

Además de políticas que describen el tratamiento de datos entrantes por el buzón de descarga de software, también existen aquellas que regulan el ajuste al terminal de módulos o datos inicialmente almacenados de forma intermedia en el buzón o en el repositorio de software del servidor de descarga de software que opera el buzón. Estas políticas se comprueban con cualquier cambio de la situación del usuario o del contexto del terminal. Para ello, la información de contexto es transmitida regularmente del terminal al buzón de descarga de software. Además, del contexto de usuario también pueden comunicarse por ejemplo resultados de monitor actuales de estándares de radio para hacer que el buzón de descarga de software sea capaz de valor si una actualización de software merece la pena o es necesaria actualmente para una radiotecnología determinada. Esto, generalmente, sólo será el caso si la radiotecnología correspondiente está disponible en la red actual y si por tanto entra en consideración la utilización del estándar de radio en un futuro próximo. Si durante esta comprobación se detecta que existe una situación adecuada para una sincronización de determinados datos entre el buzón de descarga de software y el terminal, el usuario o bien puede seleccionar de forma interactiva qué descargas se realicen realmente, o bien, el proceso de sincronización completo se ejecuta automáticamente. Si y en qué medida el proceso de sincronización se ejecuta de forma interactiva igualmente está establecido en el marco de las políticas correspondientes.

Condiciones adecuadas para una descarga son por ejemplo que los costes de la descarga son inferiores a un límite predefinido, que la conexión presenta un ancho de banda suficientemente grande (por ejemplo, en un “hot spot" (punto caliente) o en el marco de una conexión a red fija), o que en la actualidad no están activos servicios en los que pudiese interferir la descarga. Generalmente, el ajuste debería realizarse en el momento adecuado más temprano posible, es decir, por ejemplo directamente después del primer encendido del terminal en la red base, para evitar errores o costes como consecuencia de la ejecución retrasada por ejemplo de correcciones de error. Un ajuste a los contenidos almacenados en el buzón de descarga de software también puede ser iniciado de forma activa por el terminal o el abonado mismo, cuando el terminal o el abonado considere adecuada la situación actual.

A continuación, se describen dos ejemplos de realización posibles de la invención:

1. Buzón de descarga de software operado por el operador de red base

Este ejemplo de realización o escenario está basado en la suposición de que los operadores de red han enriquecido su infraestructura de red con elementos que soportan la descarga de software.

La FIGURA 1 muestra una arquitectura posible para este escenario, estando en el centro de dicha arquitectura un servidor de descarga de software 13 que por medio de un repositorio de software 11 puede intercambiar de forma intermedia paquetes de software y otros datos. Para cada usuario Usuario A, Usuario B, Usuario C, el operador de red opera un buzón de descarga de software 10A, 10B, 10C que para la realización de la funcionalidad descrita anteriormente interacciona con el servidor de descarga de software 13. A través de sus terminales 16, 18 y 19, los usuarios Usuario A, Usuario B, Usuario C pueden controlar la función de su respectivo buzón de descarga de software 10A, 10B, 10C, cuando tienen conexión a la red. En la figura 1, este es el caso para los usuarios Usuario A y Usuario B, estando representada, para mayor claridad, sólo para el Usuario A la conexión Control al buzón de descarga de software. El usuario Usuario C, en cambio, no tiene actualmente conexión a red; su buzón de descarga de software actúa por él de forma autónoma según las políticas configuradas por el Usuario C.

La FIGURA 1 muestra que actualizaciones de software son iniciados por fabricantes de terminales 12 o proveedores de servicios 14 y tramitados a través del servidor de descarga de software 13 del operador de red base. Este servidor 13 detecta, mediante la interacción con el buzón de descarga de software 10A, 10B, 10C de los usuarios afectados por la actualización de software correspondiente, qué acciones deben realizarse. Descargas pueden realizarse tanto para terminales abonados en la red propia del operador, por ejemplo el terminal 16 del usuario Usuario A, como para aquellos que están abonados en una red de otro operador, por ejemplo el terminal 18 del usuario Usuario B, si las políticas definidas del usuario correspondiente lo permiten. Para terminales que actualmente no están conectados a una red o que están apagados, como por ejemplo el terminal 19, se realiza un ajuste al buzón de descarga de software 10C en cuanto vuelva a existir una conexión de red adecuada.

La ventaja de este escenario consiste en que el buzón de descarga de software 10A, 10B, 10C correspondiente está integrado estrechamente en la red del operador de telefonía móvil y, por tanto, puede ser aprovisionado por este de información acerca del estado del terminal.

2. Buzón de descarga de software, operado por el fabricante del terminal

En este segundo ejemplo de realización o escenario se supone, al igual que en el escenario anterior, que los operadores de red han enriquecido su infraestructura de red con elementos que soportan la descarga de software. Sin embargo, el buzón de descarga de software 10A, 10B, 10C de un usuario Usuario A, Usuario B, Usuario C no es operado por el operador de red, sino por el fabricante de terminal correspondiente, a través de un servidor de descarga de software 23 propio que accede a un repositorio de software 21. Por lo demás, la funcionalidad de los distintos elementos de la arquitectura representada en la figura 2 corresponde sustancialmente a la descripción relativa a la arquitectura de la figura 1. Aquí, sin embargo, el usuario correspondiente no está vinculado a un operador de red determinado.

Este escenario ofrece la ventaja de que los fabricantes de terminales que generalmente inician las actualizaciones de software críticas son responsables de la operación del buzón de descarga de software 10A, 10B, 10C de un usuario y de que para este caso especial se puede optimizar la transferencia de software al repositorio de software 11A, 11B.

Las ventajas principales de la invención descrita en el apartado anterior consisten en los siguientes puntos:

1) Mediante el uso de un buzón de descarga de software, el abonado puede conseguir un claro ahorro de coste, ya que descargas de software al terminal se efectúan siempre cuando la conexión para ello resulta especialmente económica. Las descargas caras del buzón de descarga de software se aplazan a un momento posterior, las descargas de software innecesario se evitan por completo. Esto se nota especialmente en estancias en el extranjero donde las tasas en la red ajena deben ser costeadas en todo caso por el abonado.

2) Con la ayuda del buzón de descarga de software se puede evitar que se pierdan descargas de software importantes. Cuando el terminal no está localizable o incluso está apagado durante un tiempo prolongado, existe el riesgo de que se pierdan correcciones de error importantes por parte del fabricante del terminal. El buzón de descarga de software puede almacenar de forma intermedia el software o la notificación de actualización y ponerla en marcha automáticamente en un momento adecuado sin que tenga que entrar en acción el abonado mismo.

3) Mediante el uso de un buzón de descarga de software se puede reducir o incluso evitar totalmente la merma de servicios activos por descargas. Con la ayuda de un bloque adecuado de reglas junto a información acerca de los servicios activos actualmente en el terminal, las descargas de software, teniendo en consideración su volumen de datos y su importancia, pueden o bien ejecutarse de la manera planeada, o bien, aplazarse a un momento posterior, si el perjuicio para los servicios activos ha de considerarse como más grave que el aplazamiento de la descarga de software.

4) El buzón de descarga de software puede priorizar la descarga de software o información importantes, mientras que software menos importante se descarga en un momento posterior o no se descarga. Se aplican criterios y reglas específicos para el abonado que pueden tener en consideración entre otros factores también el lugar de estancia actual así como la situación en la que el abonado se encuentra actualmente.

5) El buzón de descarga de software puede seleccionar para la sincronización con el terminal respectivamente la conexión más adecuada para determinadas descargas y de esta manera garantizar una relación óptima entre el precio y la disponibilidad de software. También para ello, como se ha explicado anteriormente, se pueden tener en consideración criterios y reglas específicos para el abonado.

Claims (16)

REIVINDICACIONES

1. Procedimiento para la transmisión de al menos un módulo de software a un terminal de abonado (16, 18, 19) de un sistema de radiocomunicación, en el que la transmisión del al menos un módulo de software al terminal de abonado (16, 18, 19) es controlada en cuanto al tiempo de tal forma que el al menos un módulo de software es transmitido, inmediatamente o en un momento posterior, al terminal de abonado (1618, 19) en función de al menos una regla almacenada que puede ser modificada por un usuario (Usuario A, Usuario B, Usuario C) y/o por el terminal de abonado (16, 18, 19).

2. Procedimiento según la reivindicación 1, en el que al menos partes del terminal de abonado (16, 18, 19) pueden ser reconfiguradas por medio del módulo de software.

3. Procedimiento según las reivindicaciones 1 o 2, en el que la al menos una regla que puede ser modificada por el usuario (Usuario A, Usuario B, Usuario C) y/o por el terminal de abonado (16, 18, 19) indica preferencias del abonado (Usuario A, Usuario B, Usuario C) y/o capacidades del terminal de abonado (16, 18, 19).

4. Procedimiento según una de las reivindicaciones 1 a 3, en el que, antes de la transmisión al terminal de abonado (16, 18, 19), el al menos un módulo de software es almacenado en un dispositivo (10A, 10B, 10C), siendo transmitido el al menos un módulo de software por un proveedor de módulos de software (12, 14) al dispositivo (10A, 10B, 10C).

5. Procedimiento según una de las reivindicaciones 1 a 3, en el que un aviso sobre la presencia del al menos un módulo de software es almacenado en un dispositivo (10A, 10B, 10C) antes de la transmisión del módulo de software al terminal de abonado (16, 18, 19), siendo transmitido el aviso sobre el al menos un módulo de software por un proveedor de módulos de software (12, 14) al dispositivo (10A, 10B, 10C).

6. Procedimiento según las reivindicaciones 4 o 5, en el que el dispositivo (10A, 10B, 10C) está dispuesto dentro del sistema de radiocomunicación que aprovisiona al terminal de abonado (16, 18, 19), en la zona de un fabricante del terminal de abonado (16, 18, 19) o en la zona de un proveedor de servicios.

7. Procedimiento según la reivindicación 6, en el que el dispositivo (10A, 10B, 10C) es direccionado en lugar del terminal de abonado (16, 18, 19) por el fabricante del terminal de abonado (16, 18, 19) y/o el proveedor de servicios para la transmisión del módulo de software o del aviso sobre el módulo de software.

8. Procedimiento según una de las reivindicaciones 4 a 7, en el que la regla definida por el abonado (Usuario A, Usuario B, Usuario C) y/o por el terminal de abonado (16, 18, 19) controla el dispositivo (10A, 10B, 10C) de tal forma que la transmisión del módulo de software es rechazada o aceptada, realizándose en caso de una aceptación del módulo de software la transmisión del módulo de software al terminal de abonado (10A, 10B, 10C) inmediatamente o en un momento posterior.

9. Procedimiento según la reivindicación 8, en el que en caso del rechazo de la transmisión del módulo de software por la regla definida se almacena tan sólo un aviso sobre la presencia del módulo de software en el dispositivo (10A, 10B, 10C), y el módulo de software se almacena en un dispositivo de memoria para módulos de software (11, 21) del sistema de radiocomunicación.

10. Procedimiento según la reivindicación 9, en el que el almacenamiento del módulo de software rechazado en el dispositivo de memoria (11, 21) es controlado por un dispositivo de servidor central (13, 23) del sistema de radiocomunicación asignado al dispositivo de memoria (11,21) y al dispositivo (10A, 10B, 10C), siendo solicitado por el dispositivo (10A, 10B, 10C) la transmisión por el dispositivo de servidor central (13, 23) del módulo de software almacenado, en un momento posterior, al terminal de abonado (16, 18, 19).

11. Procedimiento según una de las reivindicaciones anteriores, en el que por el dispositivo (10A, 10B, 10C) son solicitados módulos de software adicionales en función de la al menos una regla definida.

12. Procedimiento según una de las reivindicaciones anteriores, en el que por medio de la al menos regla se definen valores límite para costes de la transmisión del módulo de software, una capacidad de transmisión y/o un momento de la transmisión.

13. Dispositivo (10A, 10B, 10C) de un sistema de radiocomunicación, con medios para almacenar al menos una regla modificable definida por un abonado (Usuario A, Usuario B, Usuario C) y/o por un terminal de abonado (10A, 10B, 10C) asignado, y para controlar en cuanto al tiempo una transmisión de al menos un módulo de software al terminal de abonado (10A, 10B, 10C) en función de la al menos una regla almacenada, inmediatamente o en un momento posterior.

14. Dispositivo (10A, 10B, 10C) según la reivindicación 13, con medios para la recepción del al menos un módulo de software o de un aviso sobre la presencia del al menos un módulo de software de un proveedor de módulos de software (12, 24).

15. Dispositivo (10A, 10B, 10C) según las reivindicaciones 13 o 14, que a través de un dispositivo de servidor central (13, 23) está conectado a un dispositivo de memoria (11,21) para almacenar el al menos un módulo de software.

16. Sistema de radiocomunicación, con al menos un dispositivo (10A, 10B, 10C) asignado a un terminal de abonado (16, 18, 19) para almacenar al menos una regla modificable definida por un abonado (Usuario A, Usuario B, Usuario C) y/o por un terminal de abonado (10A, 10B, 10C) asignado, y para controlar en cuanto al tiempo una transmisión de al menos un módulo de software, recibido del proveedor de módulos de software (12, 24), al terminal de abonado (10A, 10B, 10C) en función de la al menos una regla almacenada, inmediatamente o en un momento posterior, con un dispositivo de memoria (11, 21) para almacenar el al menos un módulo de software recibido, y con un dispositivo de servidor (13, 23) para controlar el almacenamiento del al menos un módulo de software recibido en el dispositivo de memoria (11, 21) y para transmitir el módulo de software almacenado al dispositivo (10A, 10B, 10C) para la transmisión al terminal de abonado (10A, 10B, 10C).