ES2371211T3 - Procedimiento para conectar dinámicamente un ordenador, un servidor de actualización, un producto de programa de ordenador y un sistema. - Google Patents

Abstract

Procedimiento para conectar un ordenador de manera dinámica con una red de ordenadores, tal como Internet, mediante al menos una conexión seleccionable entre un cierto número de conexiones seleccionables, de las cuales al menos una es inalámbrica, que hace uso de una red, y al menos un dispositivo conector seleccionable, entre un número de dispositivos seleccionables, permite una conexión inalámbrica, que puede acoplarse al mismo, en el que las conexiones pueden incluirse en una lista de prioridades, efectuándose el procedimiento en el ordenador y comprendiendo etapas para: - definir al menos un conjunto de conexiones de red por medio de la comprobación de dispositivos conectores disponibles, - definir la conexión disponible con la mayor prioridad como conexión candidata, - si una conexión está activa, interrumpir esta conexión y hacer conexión con la conexión candidata, si es distinta a la conexión activa, - si no está activa ninguna conexión, hacer conexión por medio de la conexión candidata, - repetir estas etapas después de un primer periodo temporal predeterminado, o al ocurrir un suceso predeterminado, tal como el agregado o la eliminación de un dispositivo conector, estando el procedimiento caracterizado por etapas para: - recoger información concerniente al uso de conexiones en el periodo temporal pasado e información de configuración del ordenador, para transferir la información recogida a un servidor.

Description

Procedimiento para conectar dinámicamente un ordenador, un servidor de actualización, un producto de programa de ordenador y un sistema

La presente invención se refiere a un procedimiento para conectar un ordenador, un servidor de actualización, software y un sistema, de manera dinámica.

Se conocen muchos sistemas y procedimientos para conectar un ordenador con una red de ordenadores tal como Internet. Los ordenadores pueden conectarse mediante redes cableadas, tales como redes de telefonía y datos, y esto es posible mediante redes móviles. Ambas formas tienen ventajas e inconvenientes que se compensan entre sí, tales como la velocidad de transporte de datos, la fiabilidad del servicio, el coste y la conveniencia de uso. Para conexiones cableadas es necesario que se tienda una conexión física por medio de cables, teniendo estas conexiones una velocidad relativamente alta a bajo coste. Para conexiones móviles ocurre que es posible la flexibilidad porque los cables son innecesarios. Este procedimiento de conexión, sin embargo, generalmente tiene una velocidad de transporte más lenta y generalmente tiene el inconveniente adicional de un coste relativamente alto. En la práctica, tales inconvenientes están más que compensados por las ventajas, tales como la flexibilidad, por lo cual las conexiones móviles son muy usadas.

Para el usuario hay una selección de una gran variedad de opciones de conexión móvil, tanto con respecto a la selección de dispositivos de conexión, tales como teléfonos móviles con módems, tarjetas de datos que pueden acoplarse al ordenador, módems, tarjetas de red y equipos de WiFi, como con respecto a las tecnologías de redes móviles, tales como GSM, UMTS, GPRS, WiFi, CSD y EDGE. Cada uno de estos dispositivos de conexión y tecnologías de red requiere la configuración de valores fijados en el software de conexión, ya sea que esto forme parte del sistema operativo del ordenador personal o de más software de red o específico del equipo.

Además, cada vez que es necesaria otra conexión, esta conexión ha de arrancarse. Se conoce software de conexión con el cual pueden compilarse los perfiles para tales conexiones, en los cuales pueden almacenarse todos los datos requeridos para arrancar la conexión. Cuando debe usarse la conexión, puede instruirse entonces al software para configurar la conexión en base al perfil. La confección de la conexión requiere, para este fin, acciones por parte del usuario del ordenador. Esto es especialmente poco práctico en un entorno cambiante, tal como durante el viaje, donde debe escogerse frecuentemente una nueva conexión porque se ha perdido una conexión existente. La provisión de redes puede cambiar incluso cuando el ordenador está estático. También puede ser el caso de que se esté usando una conexión que es lenta o cara mientras está disponible una mejor alternativa, sin que un usuario tenga conciencia de ello.

Del documento WO 2004 / 031488, se conoce software inteligente de gestión de conexiones para dispositivos portátiles que es capaz de conmutar conexiones en base a criterios de selección. En este documento, se revela que los criterios de selección pueden descargarse desde un servidor de modo tal que no se requiera al usuario ingresar sus propios criterios de selección, o que una compañía pueda mantener algún nivel de control sobre su base de usuarios con respecto a las conexiones usadas.

El documento US2004 / 0153545 revela un procedimiento para gestionar el ancho de banda de red, donde agentes en ordenadores en un sistema distribuido comunican estados de cuencas monitorizadas a un módulo de control en un servidor de control.

A fin de obviar tales inconvenientes, la presente invención proporciona un procedimiento según la reivindicación 1.

Un procedimiento según la presente invención brinda la ventaja de que se usa automáticamente la conexión más deseable en cada caso, en base a una prioridad. Si la velocidad de conexión es importante, se escoge la conexión con la mayor velocidad posible, en base a las prioridades. Por ejemplo, si es posible una conexión de WiFi mientras ya está presente una conexión mediante una red GSM, se detendrá la conexión relativamente lenta del GSM y se configurará la red relativamente rápida WiFi. Optativamente, puede preguntarse aquí al usuario si encuentra esto deseable, pero el usuario no tiene que ingresar ninguna configuración para la conexión, ni pensar acerca de las conexiones, ya que esto está fijado en las prioridades. Estas configuraciones de prioridad pueden modificarse según cambian los deseos de conexión del usuario del ordenador, tras lo cual la conexión se efectúa en base a las configuraciones de prioridad modificadas.

Las conexiones se definen como un conjunto de datos que comprende parámetros del dispositivo conector y de la red con la cual se lleva a cabo la conexión.

En una primera realización preferida, la etapa en el procedimiento para definir el conjunto de conexiones de red disponibles comprende etapas para detectar dispositivos conectores. Por ello se hace posible, con el fin de definir las conexiones de red disponibles, tener en cuenta el hecho de que un dispositivo es detectable y, por tanto, adecuado para su uso.

50 E06075583 04-10-2011

En una realización preferida adicional, el procedimiento comprende etapas para obtener datos con respecto a los dispositivos conectores. Una ventaja de ello es que los datos relacionados con las capacidades del dispositivo están disponibles para el uso del mismo.

El conjunto de las conexiones disponibles se define preferiblemente en base a los dispositivos conectores disponibles. Una ventaja de ello es que las funcionalidades de los dispositivos conectores pueden usarse para definir el conjunto de conexiones que pueden hacerse al dispositivo conector. Los ejemplos de esto son que puede hacerse una conexión de CSD y una conexión de GPRS con un Nokia™ 6230 y que puede hacerse una conexión de GPRS y una conexión de UMTS con una tarjeta de datos de Vodafone™. Si se detectan ambos dispositivos conectores, puede definirse en cualquier caso una conexión de CSD, de GPRS y de UMTS.

En una realización preferida adicional, el procedimiento comprende etapas para instalar dispositivos conectores. Esta instalación tiene la ventaja de que al usuario puede bastarle el acoplamiento de un nuevo dispositivo conector, tras lo cual todos los datos para llevar a cabo las etapas según la invención con respecto al dispositivo pueden llevarse a cabo automáticamente sin que el usuario tenga que instalar o configurar dispositivos al nivel, por ejemplo, del sistema operativo del ordenador, ya sea este un ordenador personal, una agenda electrónica u otro dispositivo que comprenda un ordenador.

El procedimiento comprende preferiblemente etapas para exhibir el conjunto de conexiones de red disponibles en una lista de una interfaz de usuario. El usuario tiene aquí la ventaja de que sólo se exhiben las conexiones en base a las posibilidades de los dispositivos conectores detectados. Esto es ventajoso porque, en base a un cierto número de dispositivos y redes y a los parámetros de los mismos, puede definirse un enorme número de distintas conexiones de red, en base a lo cual el usuario tiene luego que dar sus prioridades. Una definición de conexión requiere una cierta cantidad de datos relacionados, entre otros, con el dispositivo conector, la red, el operador y / o un proveedor de servicios. En particular, cuando una gran parte de estas conexiones no está disponible debido a la ausencia de la red y / o el dispositivo conector que puede conectarse a una red, y / o los parámetros dependientes del operador o proveedor de servicios, se exhibirán entonces normalmente las conexiones que, sin embargo, sí tienen datos disponibles según procedimientos de la técnica anterior, pero no en el procedimiento según la invención, por lo cual sólo se necesita compilar una lista breve de prioridades en cada caso, en base a la disponibilidad.

En una realización preferida adicional, las conexiones pueden categorizarse en base a una propiedad de poder funcionar bajo un régimen de conexión flexible, tal como el protocolo IP móvil, que comprende etapas para:

-

cambiar de régimen si la conexión candidata requiere un régimen distinto al de la conexión existente,

-

conectarse con conexiones de red bajo el régimen flexible si la candidata puede funcionar bajo un régimen de conexión flexible,

-

conectarse bajo un régimen normal si la candidata no puede funcionar bajo un régimen de conexión flexible.

Esta realización tiene la ventaja adicional de que el cambio de conexión puede llevarse a cabo sin que sean perturbadas aplicaciones que estén haciendo uso de la conexión. Preguntar al usuario si la conexión puede cambiarse es, por tanto, menos importante, por ejemplo, que cuando el cambio de conexión puede influir sobre aplicaciones del usuario operativas en el ordenador.

Una realización adicional comprende etapas para cambiar de conexión dentro del tiempo de repetición predeterminado dentro de la categoría de conexiones capaces de funcionar bajo el régimen flexible, que comprenden las etapas para:

-

determinar un conjunto de conexiones que funcionan bajo el régimen flexible y que están disponibles, mediante la comprobación de disponibilidad,

-

determinar la conexión disponible con la prioridad más alta como candidata flexible,

-

cambiar de conexión desde la conexión existente a la candidata flexible,

-

repetir estas etapas después de un segundo periodo temporal predeterminado o impedir un suceso predeterminado.

Esta realización, por ejemplo, tiene la ventaja adicional de que es posible cambiar de conexión con relativa frecuencia, por ejemplo, en condiciones donde las redes tienen un alcance pequeño. Si el viaje está teniendo lugar en una vecindad con muchos puntos calientes de WiFi, y estos tiene una alta prioridad debido a la velocidad de transporte de datos, porque tienen un pequeño alcance en comparación con una red telefónica inalámbrica, el ordenador portátil puede entonces salir del alcance de un punto caliente, pero luego tener aún una conexión temporal mediante una red telefónica. Todos estos cambios son realizados por el software que realiza el procedimiento, sin que esto interrumpa al usuario en su trabajo con el ordenador.

50 E06075583 04-10-2011

Una realización adicional comprende etapas para descargar desde un servidor de actualización datos relacionados con las conexiones, los dispositivos conectores, las redes, los módulos de servicio y / o una interfaz de usuario, en donde estos datos se transfieren en un formato estandarizado, tal como un formato de XML. Una ventaja de ello es que el lenguaje de la interfaz gráfica de usuario del software, por ejemplo, puede cambiarse sin tener que hacer una nueva versión de la configuración de software. Además, el servidor puede usarse para proporcionar servicios adicionales a los usuarios del sistema, según la presente invención.

Un aspecto adicional de esta realización es que se añaden nuevos datos relacionados con nuevos dispositivos conectores, por lo cual el usuario puede aplicar continuamente cualquier nuevo dispositivo deseado para sus conexiones, sin problemas. Esto es importante porque los fabricantes de tales dispositivos y redes están continuamente produciendo nuevos modelos y tecnología con el fin de mejorar su posición competitiva. Un objeto de este aspecto es que los datos de definiciones referidos a estructuras de almacenamiento también sigan siendo utilizables después de modificaciones al sistema y / o al dispositivo conector. El dispositivo conector en el cual esta realización es especialmente importante comprende un teléfono móvil o un módulo con la funcionalidad de un teléfono móvil, pero también puede ser un controlador de disco o un monitor o un dispositivo según lo definido en el contexto del llamado Equipo de Desarrollo de Controlador de Windows (WDDK). Por ejemplo, se hace uso para esta realización de una API tal como la API configurada que puede usarse con el WDDK. Los datos de esta realización se almacenan en un paquete y comprenden un manifiesto. Este manifiesto comprende un conjunto de datos que comprende definiciones de dispositivo, ficheros referidos a una configuración de dispositivo e instrucciones para procesar los elementos de configuración del dispositivo, los dispositivos individuales. Ventajas adicionales de esta realización se describen con referencia a la Fig. 15.

La transferencia de datos se lleva a cabo preferiblemente en base a un visor sumamente condensado de los datos de configuración del ordenador. La transferencia de datos puede abreviarse considerablemente por ello. Un ejemplo de ello es que se hace uso de una refundición de los datos de configuración, en base a lo cual el servidor sabe qué software, con qué configuraciones, está presente en el ordenador en el cual se realiza el procedimiento según la presente invención.

Se recomienda adicionalmente que los datos para transmisión se codifiquen, preservando por ello la confidencialidad de los datos.

En una realización preferida adicional de la presente invención, se proporcionan etapas para seleccionar una conexión bajo condiciones de itinerancia, en donde puede asignarse una prioridad a parámetros de conexiones. Un usuario del procedimiento puede determinar por ello las condiciones en las cuales se hace una conexión, sin tener siempre que ingresar datos con este fin.

Un aspecto adicional de la presente invención se refiere a un servidor de actualización según la reivindicación 18.

Una ventaja de tal realización es que puede llevarse a cabo un procedimiento según lo descrito en lo precedente, donde los datos pueden almacenarse centralmente y / o procesarse en el servidor de actualización. Una parte del procedimiento puede también llevarse a cabo en el servidor, sujeta a los requisitos, por ejemplo, del dispositivo cliente.

Un aspecto adicional de la presente invención se refiere a un producto de programa de ordenador según la reivindicación 19.

Tal software tiene, entre otras, ventajas como las ya indicadas en lo precedente, con referencia al procedimiento.

Un aspecto adicional de la presente invención se refiere a un sistema para actualizar datos de conexión en un ordenador cliente, según la reivindicación 20.

Ventajas, características y detalles adicionales de la presente invención se describirán en base a las realizaciones según la presente invención, con referencia a las figuras adjuntas, en las cuales:

-

la Fig. 1 es una representación esquemática de una realización según la presente invención,

-

las Figs. 2 a 14 son diagramas de flujo de realizaciones adicionales según la presente invención,

-

la Fig. 15 es una representación esquemática de una realización adicional según la presente invención.

Una primera realización preferida según la presente invención (Fig. 1) se refiere a un sistema 1 de conexión que comprende un llamado motor 2-14 y una interfaz gráfica 15-21 de usuario. El motor comprende un cierto número de módulos de software que pueden cargarse en una memoria del ordenador (no mostrado) y que funcionan en una unidad central de procesamiento del ordenador. El software está dotado de datos desde un servidor 30 de actualización acoplado con Internet. Los módulos 6 a 8 del software permiten adicionalmente que el ordenador se conecte con redes que permiten un acoplamiento con Internet por medio de descripciones de hardware en el módulo 3, mediante el correspondiente hardware, tal como un teléfono móvil o un dispositivo de WLAN. Con este fin, los datos concernientes

55 E06075583 04-10-2011

a los parámetros técnicos de la red se almacenan en el módulo 4, los datos concernientes a los dispositivos conectores en el módulo 3, los datos concernientes a las conexiones en el módulo 5 y los datos concernientes a los posibles mensajes en el módulo 2.

Las funciones referidas a la itinerancia son llevadas a cabo por el módulo 9 (administrador de itinerancia) que, en el caso de una situación de itinerancia, hace uso de una red móvil en base a los deseos del usuario, y hace conexión automática (fig. 13, 14) con la red mejor adecuada a los deseos del usuario. La itinerancia es importante, por ejemplo, porque los costes y las características específicas de las redes pueden diferir entre sí. El módulo 10 (administrador de conexión) proporciona el registro o la gestión (fig. 3 a 5) de las conexiones que el sistema puede hacer. El módulo 11 (actualizador) garantiza que todos los datos del sistema referidos a la interfaz gráfica de usuario y a los módulos 2 a 4 estén actualizados, por ejemplo, realizando una comprobación de actualización (fig. 6, 7) cada vez que el sistema hace conexión con Internet. Un módulo adicional (administrador de dispositivos, no mostrado) proporciona el registro de datos referidos a los dispositivos conectores (fig. 8 a 12). La exhibición de los módulos es llevada a cabo por el software de la interfaz gráfica de usuario, por medio de los módulos 18 a 21 de exhibición.

Los módulos 2 a 5 también se denominan contenedores de elementos, y los datos se almacenan en los mismos en una estructura determinada, en donde múltiples elementos pueden almacenarse en un contenedor de elementos. Un conjunto de atributos de cada elemento puede almacenarse luego. Un formato estandarizado, tal como el XML, se aplica preferiblemente para la estructura.

Los módulos 6 a 8 son comunicadores de dispositivos. Estos módulos están adaptados, mientras hacen uso de los datos referidos a los dispositivos conectores, para hacer contacto con redes con las cuales puede hacer contacto un dispositivo conector. Aquí, un teléfono del GSM, por ejemplo, puede hacer contacto con una red GSM haciendo uso de un protocolo usado por la red. Un dispositivo de WiFi también puede hacer contacto con un punto caliente o estación base de WiFi. Otras posibilidades son tarjetas de red LAN o dispositivos de red Bluetooth. Nuevas formas de red estarán tal vez disponibles en el futuro próximo, con las cuales pueda hacerse conexión de manera dinámica, como según la presente invención. También se dispondrá de dispositivos que puedan hacer conexión con distintas redes. La invención es muy apropiada para conectar ordenadores desplazables de manera sencilla con Internet, aunque el sistema puede asimismo hacer uso de ubicaciones donde esté disponible una conexión fija rápida. El software para hacer una conexión de red del sistema operativo del ordenador puede usarse en este caso, pero también el sistema según la presente invención, con la ventaja de que, después de la desconexión de la conexión de LAN, se hace uso automáticamente de una conexión móvil disponible.

Si se hace contacto con el software según la presente invención, también se hace contacto con el servidor 30 de actualización, por lo cual el software puede actualizarse por medio de datos almacenados en una estructura estandarizada, tal como el XML. El uso de tal contacto con los servicios adicionales del servidor también puede llevarse a cabo en el ordenador, o descargarse al ordenador. Tales servicios pueden ser un servicio de mensajes, la actualización de los idiomas de la interfaz gráfica de usuario, por medio de datos de idiomas almacenados en una estructura estandarizada tal como el XML, la gestión de certificados, los servicios de intercambio de música, la gestión de contactos, etc. Tales servicios son realizados en el ordenador por medio de módulos adicionales. Tales módulos adicionales se cargan en el ordenador por medio del módulo 11 de actualización y se exhiben en la interfaz gráfica de usuario por medio de los módulos 18 a 21 de visualización.

El módulo 12 de control está adaptado para dar soporte a los procesos anteriormente descritos y al almacenamiento de los datos en un banco de datos. El módulo 13 de licencias está adaptado para determinar si el usuario del ordenador tiene el derecho de usar módulos específicos, por medio de un tipo de gestión de licencias. El módulo 14 de idiomas está adaptado para proporcionar al sistema, de manera flexible, datos referidos a los idiomas que pueden exhibirse en la interfaz gráfica de usuario. Estos datos se almacenan y se transportan en un formato estandarizado. La interfaz gráfica de usuario puede, por tanto, dotarse en marcha de un nuevo idioma, mientras que el software anterior tenía que ser reemplazado por completo por una nueva versión o una denominada nueva “configuración”. Si un usuario desea un nuevo idioma, el actualizador puede cargar los datos requeridos desde el servidor 30 de actualización.

El funcionamiento básico de la interfaz gráfica de usuario se basa en los módulos 15 a 17, en donde el módulo 15 es la capa de soporte de presentación, el módulo 16 comprende los componentes de la interfaz gráfica de usuario y el módulo 17 comprende los componentes de marco de la interfaz gráfica de usuario.

La Figura 2 muestra una realización de la conexión dinámica del ordenador con Internet. El procedimiento comienza en la etapa 31, tras lo cual, en la etapa 32 se determina qué modalidad operativa es seleccionada por el usuario del ordenador. Éste último tiene la posibilidad de elegir entre la conexión manual 33 o la conexión automática 34. También es posible saltarse esta elección si un usuario quiere una conexión automática desde entonces en adelante. Si se escoge la conexión manual, el procedimiento continúa en la etapa 34, en la cual un usuario selecciona una conexión con la cual conectarse.

Si se selecciona la modalidad automática, el procedimiento continúa en la etapa 37, donde, en orden de prioridad de

55 E06075583 04-10-2011

las conexiones, se hace una comprobación en cuanto a si está disponible una primera conexión. En la etapa 38 se determina luego si el usuario desea o no usar el protocolo IP móvil. Esto también puede tener lugar automáticamente, por ejemplo, si se conoce un valor por omisión. Si es este el caso, se determina en la etapa 40 si esta conexión es o no adecuada para el protocolo IP móvil, o si este protocolo se permite o no en esta conexión. Si es este el caso, la conexión se coloca en una lista del protocolo IP móvil en la etapa 41. Si se determina en la etapa 40 que el protocolo IP móvil no está permitido, la conexión se coloca en una lista de conexiones normales en la etapa 39. Se determina entonces, en la etapa 42, si ha de comprobarse o no otra conexión y, si es así, el procedimiento vuelve a la etapa 37.

Si se determina en la etapa 42 que se han comprobado todas las conexiones, se compila una lista de disponibilidad de las conexiones en la etapa 43, en la cual se colocan todas las conexiones de las listas del párrafo anterior. Se determina una candidata en la etapa 44. Esta candidata es la conexión con la mayor prioridad que está disponible para efectuar una conexión en la lista de disponibilidad. Se determina en la etapa 45 si una conexión ya está o no activa. Si no es este el caso, el procedimiento continúa en la etapa 46 y, si es este el caso, el procedimiento continúa en la etapa

49.

En la etapa 46 se determina si la conexión candidata está en la lista del protocolo IP móvil, tras lo cual el procedimiento continúa en la etapa 48 si la candidata está en la lista del protocolo IP móvil, y en la etapa 47 si la candidata está en la lista normal.

En la etapa 63, a continuación de 47, se hace una comprobación en cuanto a si la conexión con la mayor prioridad en la lista normal está o no disponible aún y, si es así, se hace un intento de establecer esta conexión en la etapa 64. En la etapa 65 se hace una comprobación en cuanto a si la conexión ha sido establecida exitosamente o no. Si no es así, se determina en la etapa 66 si hay o no aún otras conexiones en la lista normal, y el procedimiento vuelve a la etapa 63. Si se determina en la etapa 65 que se ha establecido exitosamente una conexión, en la etapa 51 el procedimiento ingresa a un estado de espera de una longitud predeterminada, tal como, por ejemplo, de cinco segundos. Esta, sin embargo, puede ser cualquier duración temporal deseada que se considere óptima, en donde, por ejemplo, el uso de fuentes del sistema y el riesgo de no tener una conexión se equilibran entre sí. Es asimismo posible permitir que el tiempo de espera sea interrumpido por un suceso tal como la pérdida de una conexión o la disponibilidad de una conexión de mayor prioridad, tras lo cual el sistema ejecutará nuevamente el procedimiento, o una parte del mismo. Es posible volver a la etapa 31, aunque es asimismo posible volver, por ejemplo, a la etapa 45.

En la etapa 61, después de 48, se activa el subsistema del protocolo IP móvil. En la etapa 62 se activan entonces todas las conexiones en la lista del protocolo IP móvil, tras lo cual el sistema se pone en el estado 51 de espera.

Si se determina en la etapa 45 que ya está activa una conexión, la etapa 49 determina si se está usando o no el protocolo IP móvil. Si no es este el caso, se determina en la etapa 50 si la conexión candidata está o no en la lista normal. Si es este el caso, el procedimiento ingresa al estado 51 de espera, como ya se ha especificado en lo precedente. Si se determina en la etapa 50 que la candidata no está presente en la lista normal, se pide al usuario del ordenador, en la etapa 52, por medio de una pantalla de diálogo, conmutar al protocolo móvil. Si se determina en la etapa 49 que hay una conexión con el protocolo IP móvil, la etapa 56 determina si la conexión candidata forma parte de la lista del protocolo IP móvil. Si no es este el caso, se pide al usuario en la etapa 52 que conmute al protocolo normal.

Si, en la etapa 52, se pide al usuario conmutar, la conmutación se efectúa en la etapa 53 y se realimenta una confirmación al usuario del ordenador por medio de una ventana de diálogo. Si el protocolo móvil estaba en efecto en la etapa 53, la conexión existente se interrumpe en la etapa 54 y se desactiva el protocolo móvil. Si no se escoge una conmutación en la etapa 53, se efectúa una conmutación al estado de espera de la etapa 51. En la etapa 47, el procedimiento continúa luego de la manera descrita en lo precedente. Si el protocolo móvil no estaba en efecto en la etapa 53, la conexión se interrumpe en la etapa 55 y se activa el protocolo IP móvil. El procedimiento continúa entonces en la etapa 48 de la manera descrita en lo precedente.

Si se determina en la etapa 56 que la candidata está en la lista del protocolo IP móvil, las conexiones en la lista del protocolo IP móvil se comprueban en la etapa 57. Esta etapa funciona como una operación de recuperación para las conexiones móviles. Se hace entonces una comprobación en la etapa 58 en cuanto a si la conexión está activada o no. Si no es este el caso, la conexión se activa en la etapa 59 y, si es este el caso, se hace una comprobación en la etapa 60 en cuanto a si hay o no más conexiones disponibles. Si hay más conexiones, el procedimiento vuelve a la etapa 57 y, en otro caso, el procedimiento continúa en la etapa 51, en la cual el procedimiento espera según lo descrito en lo precedente.

Las Figuras 3 a 5 muestran procedimientos del administrador de conexiones o del módulo 5. La Figura 3 muestra una realización para comprobar la disponibilidad de conexiones. Esta módulo puede funcionar en paralelo a, e independientemente de, otros módulos, y la información puede ser usada por otros módulos. El procedimiento se inicia en la etapa 67. En la etapa 68 se recuperan todas las conexiones en una lista. En la etapa 69 se hace una comprobación en cuanto a si la primera conexión está o no acoplada. Si es este el caso, la disponibilidad de la conexión asociada se asigna en la etapa 76 a esta conexión. El procedimiento se continúa luego en la etapa 75.

55 E06075583 04-10-2011

Si se determina en la etapa 69 que la conexión no está acoplada, se determina en la etapa 70 si la conexión es o no regular. Si es este el caso, la disponibilidad y accesibilidad de las redes que corresponden, al menos con respecto al tipo, se determinan en la etapa 77. Si una conexión especifica un portador, también se lleva a cabo una comparación con el portador en la etapa 77. El procedimiento continúa en la etapa 72.

Si se determina en la etapa 70 que la conexión no es regular, la disponibilidad y accesibilidad de las posibles redes de destino se determinan en la etapa 71. La disponibilidad y la accesibilidad de las redes de destino se determinan en la etapa 72. Si estos valores son positivos, se marca una conexión como disponible en la etapa 73. Si estos valores son negativos, se marca una conexión como no disponible. Como se ha indicado, la etapa 75 determina si más conexiones han o no de comprobarse aún. Si es este el caso, el procedimiento vuelve a la etapa 69. En otro caso, el procedimiento se acaba en la etapa 78.

La Figura 4 muestra una realización de un procedimiento para añadir una conexión. El procedimiento se inicia en la etapa 79. En la etapa 80, se presenta al usuario una lista de tipos de conexión, tales como GSM, GPRS, UMTS, CDMA, EV-DO, IXRTT, HSDPA, WLAN o RAS. En la etapa 81, se piden al usuario parámetros específicos para el tipo, tales como el SSID para WLAN o un número telefónico para el CSD. En la etapa 82 se instancia un nuevo objeto de conexión con los parámetros dados y la prioridad deseada. El procedimiento acaba en la etapa 83.

La Figura 5 muestra un procedimiento para eliminar una conexión. Después del inicio 84, un usuario selecciona una conexión en la etapa 85. En la etapa 86 se determina si la conexión está o no activa, después de lo cual, si es este el caso, se exhibe un mensaje de error en la etapa 89. En la etapa 87 se elimina el objeto que representa a la conexión. En la etapa 88 se actualiza entonces la lista de conexiones de modo tal que la conexión eliminada no se exhiba más en la etapa 88. La operación acaba en la etapa 90.

En la figura 6 y 7 se muestra en detalle el procedimiento de interacción con el servidor 30 de actualización. La Figura 6 muestra el funcionamiento del módulo 11 con respecto a la transmisión de información desde el ordenador al servidor 30 de actualización. Después del inicio en 91, la información MSI se recoge en la etapa 92, en el caso de que el ordenador tenga un sistema operativo de Microsoft™. Se valida entonces una refundición del MSI en la etapa 93. Una refundición es una representación breve de una gran cantidad de datos, por lo que sólo es necesario procesar o transmitir una pequeña cantidad de datos, y no obstante se dispone de una precisa visión interna referida a la gran cantidad de datos. Los datos se añaden a un conjunto de datos en la etapa 94.

La información de configuración se recoge en la etapa 95. La configuración de refundición se valida entonces en la etapa 96. Si esto es inválido, los datos se añaden al conjunto de datos en la etapa 97. Si es válido, la información referida al ordenador, tal como aquella acerca del sistema operativo, se recoge en la etapa 98. La configuración de refundición se valida en la etapa 99. Si esto es inválido, los datos se añaden al conjunto de datos en la etapa 100. Si es válido, se recoge información en la etapa 101 concerniente al uso de conexiones en el periodo temporal pasado. La configuración de refundición se valida entonces en la etapa 102. Si esto es inválido, se añade en la etapa 103 al conjunto de datos. Si es válido, el conjunto de datos se convierte en la etapa 104 a un formato de XML, para la transferencia de la información en un formato estandarizado. Los datos en XML se comprimen luego y se codifican en la etapa 105. En la etapa 106 los datos resultantes se envían al servidor 30 de actualización mediante Internet. La operación acaba en la etapa 107.

La Figura 7 muestra una realización del procedimiento del módulo 11 con respecto a la recepción de datos desde el servidor 30 de actualización. El procedimiento se inicia en la etapa 110. En la etapa 111 se determina si una respuesta detectada del servidor es válida o no. Si no este el caso, el procedimiento se acaba en la etapa 118. Si es este el caso, el próximo elemento de la respuesta desde el servidor se procesa en la etapa 112. En la etapa 113 se determina si este próximo elemento se refiere o no a datos de idioma. Si es este el caso, el procedimiento continúa en la etapa 120. En la etapa 114 se determina si este próximo elemento son datos descargables, tales como nuevos módulos de programa, música o ficheros tales como ficheros .xls. En la etapa 115 se determina si este próximo elemento son datos de actualización referidos al sistema 1 o, por ejemplo, la interfaz gráfica de usuario. Si es este el caso, el procedimiento continúa en la etapa 122. En la etapa 116 se determina si este próximo elemento son o no datos del Instalador de Microsoft. Si es este el caso, el procedimiento continúa en la etapa 123.

En la etapa 120 se inicia la modificación o el agregado de la información de idioma de la interfaz gráfica de usuario, en base a los nuevos datos. En la etapa 124 estos datos se añaden en tiempo real al fichero de idioma para la interfaz gráfica de usuario. En la etapa 125, el procedimiento vuelve a la etapa 114.

En la etapa 121, se inicia el procedimiento de descarga a fin de cargar el fichero proveniente del servidor en el ordenador. Los ficheros se descargan en la etapa 126. En la etapa 127 se determina si se requiere o no una distribución. Si es este el caso, los ficheros se distribuyen a la carpeta de destino en la etapa 128. Si no es este el caso, el procedimiento continúa inmediatamente en la etapa 129, en la cual se determina si se requiere la ejecución o no. Si es este el caso, la ejecución se lleva a cabo en la etapa 130, o bien el procedimiento continúa inmediatamente en la etapa 125, donde esta rutina de descarga se acaba y el procedimiento vuelve a la etapa 115.

55 E06075583 04-10-2011

El proceso de configuración se inicia en la etapa 122. Los elementos de configuración a los cuales se refiere la información se actualizan en la etapa 133. La configuración modificada se da a conocer en la etapa 134. En la etapa 125 el procedimiento vuelve a la etapa 116.

En la etapa 123 se inicia la operación para realizar un parche en base a los datos del MSI. El parche del Instalador de Microsoft se aplica al sistema en la etapa 131. En la etapa 132 se exhibe un aviso de reinicio si el parche lo requiere a fin de funcionar. En la etapa 125, el procedimiento vuelve a la etapa 117.

Estos procedimientos de la figura 6 y 7 brindan, por ejemplo, la ventaja de que el usuario puede actualizar automáticamente su sistema con nuevos idiomas para la interfaz gráfica de usuario, servicios en forma de módulos y datos referidos a redes y dispositivos conectores.

Las Figuras 8 a 12 muestran realizaciones de procedimientos realizados por el administrador de dispositivos conectores. Esto no se muestra en la figura 1, pero forma parte de la conexión 27 entre el módulo 3 del dispositivo conector y los módulos 6 a 8 de red, de manera similar a los módulos 9 a 11 que forman parte de esta capa del sistema

1.

En la figura 8 se muestra un procedimiento para determinar y / o registrar la duración temporal durante la cual está activo un dispositivo o una red. El procedimiento se inicia en la etapa 135. El procedimiento espera una solicitud de activación en la etapa 136. En la etapa 137 se compila una lista de todas las redes visibles mediante los dispositivos conectores activos, para realizar conexiones. Con este fin, se hace una búsqueda de redes en base a los datos conocidos, pero también puede ser el caso de que los dispositivos conectores se crucen con redes en la etapa 138 e informen de esto. El módulo 11 de actualización podrá entonces recuperar del servidor de actualización datos referidos a una tal red, desconocida hasta entonces.

En la etapa 148 se compila una lista de las redes recientemente detectadas. En la etapa 149 se determina si la red existe y si no ha sido reclamada aún. Si la red no ha sido reclamada, se reclama la red para el dispositivo conector en la etapa 150. Si en la etapa 149 se determina que la red ya ha sido efectivamente reclamada, se instancia un nuevo objeto de red en la etapa 152, tras lo cual se rellenan las propiedades de red en la etapa 153. La red se reclama entonces para el dispositivo conector en base a estos nuevos datos. Si se determina en la etapa 151 que hay más redes nuevas, el procedimiento vuelve a la etapa 148. En otro caso, el procedimiento continúa en la etapa 142.

Si en la etapa 138 se determina que no se detecta ninguna nueva red, las propiedades de las redes administradas por el dispositivo conector son actualizadas por el dispositivo conector en la etapa 139. Esto implica datos tales como el nombre, la potencia de señal, el estado actual (p. ej., GPRS) y similares. En la etapa 140 se determina si se envía o no una solicitud de conexión referida a la red. Si es este el caso, se hace una conexión con la red en la etapa 145, con el fin de activar la red. En la etapa 146 se determina si puede llevarse a cabo o no el multiplexado con el dispositivo, por ejemplo, para múltiples conexiones. Si no es este el caso, el procedimiento aguarda la terminación de la conexión en la etapa 147. Sin embargo, si es este el caso, el procedimiento continúa en la etapa 141 a fin de realizar tareas de gestión específicas del dispositivo. Esto puede referirse a cuestiones tales como el registro de la potencia de distintas Redes Inalámbricas de Área Local, si un canal de comunicación de GSM está o no en funcionamiento y / o la recuperación de mensajes de SMS.

En la etapa 142 se determina si se recibe o no una solicitud de comunicación. Si no es este el caso, el procedimiento vuelve a la etapa 137. Sin embargo, si es este el caso, el procedimiento continúa en la etapa 143, donde las redes administradas por el dispositivo conector se dejan indisponibles e inactivas. Se determina luego si es deseable el cierre ordenado en la etapa 144. Si no es este el caso, el procedimiento vuelve a la etapa 136 y, si es este el caso, la operación se acaba en la etapa 154.

La Figura 9 muestra una realización de un procedimiento para observar dispositivos conectores. En esta realización, la información acerca de los dispositivos se lleva en orden de prioridad y se transfiere a los otros módulos que pueden usar esta información. El procedimiento se inicia en la etapa 155. En la etapa 156, los dispositivos conectores disponibles se ordenan por tipo y prioridad. En la etapa 157 se busca contacto con un dispositivo a fin de determinar si el dispositivo está o no disponible en la etapa 158. Si el dispositivo no está disponible, el procedimiento continúa en la etapa 159. Si el dispositivo está disponible, todos los dispositivos con una prioridad inferior se desactivan en la etapa

160. El dispositivo se activa luego en la etapa 161. En la etapa 162 se determina si la activación fue exitosa o no. Si la activación fue exitosa, el procedimiento se acaba en la etapa 163. Si la activación no fue exitosa, el procedimiento continúa en la etapa 159. Este es asimismo el caso si el dispositivo no estaba disponible en la etapa 158. En la etapa 159 se determina si están o no presentes más dispositivos en la lista. Si es este el caso, el procedimiento continúa en la etapa 157. Si no es este el caso, el procedimiento se acaba en la etapa 163.

La Figura 10 muestra una realización de un procedimiento para monitorizar dispositivos conectores. El procedimiento se inicia en la etapa 164. La recuperación de los datos referidos a todos los dispositivos conectores se inicia en la etapa 165. La recuperación del próximo dispositivo se lleva a cabo en la etapa 166. En la etapa 167 se determina si el

55 E06075583 04-10-2011

dispositivo representa hardware o no. Si no es este el caso, el procedimiento continúa en la etapa 168. Si es este el caso, el procedimiento continúa en la etapa 169, en la cual el hardware y los controladores asociados se detectan, por ejemplo, en un fichero de XML. La disponibilidad se actualiza en la etapa 170. En la etapa 168 se determina entonces si hay o no un dispositivo adicional que haya aún que detectar. Si es este el caso, el procedimiento vuelve a la etapa

166. Si no es este el caso, el procedimiento se acaba en la etapa 171.

En la Figura 11 se muestra una realización para añadir un nuevo dispositivo. El procedimiento se inicia en la etapa 172. En la etapa 173 se muestra al usuario una lista con todos los dispositivos conocidos. Se exhibe entonces un aviso con la solicitud para conectar un nuevo dispositivo con el ordenador. El nuevo dispositivo se detecta en la etapa 175. En la etapa 176 se determina si la detección fue exitosa o no. Si no es este el caso, se determina si los controladores han sido instalados o no en la etapa 179. Si no es este el caso, los controladores se instalan en la etapa 178. Si los controladores ya han sido instalados, el procedimiento vuelve a la etapa 174. Si el dispositivo fue detectado en la etapa 176, el procedimiento continúa en la etapa 177, donde el nuevo dispositivo se instala con la mayor prioridad. La operación acaba en la etapa 180.

Se muestra en la figura 12 un procedimiento para eliminar un dispositivo conector. El procedimiento comienza en la figura 181. En la etapa 182 se determina si un dispositivo está activo o no. Si es este el caso, se desactiva en la etapa

185. En la etapa 183 el dispositivo se marca como no disponible, tras lo cual se elimina en la etapa 184 como instancia u objeto en el módulo de dispositivos conectores 3.

La Figura 13 muestra una realización de un procedimiento para optimizar la selección de una conexión en condiciones de itinerancia. La itinerancia es el uso de una red de telecomunicaciones cuando la red de origen no está disponible.

El procedimiento se inicia en la etapa 190. En la etapa 191 se determina si el procedimiento está activado o no. Si no es este el caso, se activa a solicitud del usuario o, por ejemplo, si la red de origen no está disponible en la etapa 193. En la etapa 192 se detiene el procedimiento si hay una conexión con la red de origen, tras lo cual se aguarda un suceso que haga deseable la reanudación, tal como la pérdida de la red de origen.

Si ocurre la reanudación, o se determina en la etapa 192 que no hay ninguna razón para detenerse, se procesa una lista inmediata de escaneo en la etapa 195. Se procesa luego una lista demorada de escaneo en la etapa 196. Se lleva luego a cabo un cambio de red en la etapa 197. Se realiza luego la operación de limpieza en la cual los dispositivos son reiniciados en la etapa 198. Esta operación de limpieza cumple con el fin de abordar los bucles o caídas.

En la etapa 202 comienza la operación para el escaneo de dispositivos en la lista inmediata de escaneo, con el escaneo del primer dispositivo, o el próximo, en esta lista. En la etapa 203 se envía una solicitud al dispositivo para buscar redes con las cuales hacer contacto. En la etapa 204 el dispositivo se marca como que está buscando redes. Si se determina en la etapa 205 que hay más dispositivos en la lista de escaneo, el procedimiento vuelve a la etapa 202, y se acaba en caso contrario en la etapa 201.

En la etapa 206 comienza la operación para la lista demorada de escaneo, con el siguiente dispositivo en la lista de escaneo. En la etapa 207 se determina si ha transcurrido o no un retardo desde la colocación del dispositivo en esta lista. Si no es este el caso, el procedimiento continúa en la etapa 206. Sin embargo, si es este el caso, el procedimiento continúa en la etapa 208. En la etapa 208, el dispositivo es instruido para escanear en busca de redes con las cuales hacer contacto. En la etapa 209 el dispositivo se marca como ocupado en el escaneo. Si en la etapa 210 se determina que están presentes más dispositivos en la lista, el procedimiento entonces continúa en la etapa 206. Si no es este el caso, el proceso se acaba en la etapa 201.

La operación para procesar los cambios de redes comienza en la etapa 211. En esta etapa se determina si la red de origen está o no disponible. Si es este el caso, el procedimiento se acaba en la etapa 201, ya que no hay ninguna condición de itinerancia. Si la red de origen no está presente, se recuperan todas las redes disponibles en la etapa 212. Estas redes se comparan en la etapa 213 con las redes presentes en una base de datos de itinerancia. A cada red se asigna una prioridad en la etapa 214, en base a criterios tales como el precio, la velocidad o el tipo. En la etapa 215 se determina si una o más de las redes corresponde(n) o no a la base de datos. Si no es este el caso, se acaba el procedimiento. Sin embargo, si hay correspondencia, se activa la red que tenga la mayor prioridad en la etapa 220. El dispositivo conector se marca como ocupado con el traspaso en la etapa 221. El procedimiento se acaba entonces en la etapa 201.

En la etapa 216 el procedimiento de limpieza comienza con el procesamiento del siguiente dispositivo. En la etapa 217 se determina si el dispositivo está o no ocupado y si ha transcurrido un tiempo predeterminado. Si es este el caso, la modalidad del dispositivo se reinicia al estado normal en la etapa 218. En la etapa 219 se determina entonces si hay o no más dispositivos. Si es este el caso, el procedimiento vuelve a la etapa 216. Si no hay más dispositivos, este procedimiento acaba en la etapa 201.

Después del procedimiento 198, se determina, por medio de un retardo temporal durante la etapa 200, si es posible o no cerrar ordenadamente. Si se determina que no es posible el cierre ordenado, el procedimiento continúa en la etapa

55 E06075583 04-10-2011

191 y, en otro caso, el procedimiento se acaba en la etapa 201.

Durante el proceso de la figura anterior, puede ocurrir un cierto número de sucesos que son abordados por medio de los siguientes gestores de sucesos.

El gestor indicado con A comienza en la etapa 222 con el suceso ‘dispositivo activado’. En la etapa 223 se determina si está implicado o no un dispositivo del GSM. Si está implicado un dispositivo del GSM, el procedimiento continúa en la etapa 224, con la colocación ordenada del dispositivo en la lista demorada de escaneo. Después el gestor es finalizado luego.

El gestor indicado con B comienza con el suceso ‘red disponible’ 226. En la etapa 227 se determina si la red es o no del tipo GSM. Si la red no es del tipo GSM, el procedimiento se acaba en la etapa 225. Sin embargo, si la red es del tipo GSM, el procedimiento continúa en la etapa 228. En la etapa 228 se determina si la red es o no la red de origen, en cuyo caso se determina en 229 que el escaneo ya no es necesario y el dispositivo que facilitó la red se elimina de la lista de escaneo y se acaba el gestor. Si la red no es la red de origen, el procedimiento continúa en la etapa 230 con la determinación de si el dispositivo está ocupado en escaneo o en conmutación. Si este el caso, el dispositivo es conmutado de nuevo a la modalidad normal en la etapa 231. Si se determina en la etapa 230 que el dispositivo no está ocupado en escaneo ni conmutación, se coloca el dispositivo que facilitó la red en la lista inmediata de escaneo. El gestor se acaba luego en la etapa 225.

El gestor indicado con C es activado por el suceso ‘dispositivo se desactiva’. En la etapa 234 se determina si el dispositivo es o no un dispositivo del GSM. Si no es este el caso, el procedimiento se acaba en la etapa 225. Si el dispositivo es un dispositivo del GSM, el dispositivo es eliminado de las listas de escaneo en la etapa 235.

El gestor indicado con D es activado por el suceso ‘red no disponible’ 236. En la etapa 237 se determina si la red es o no del tipo GSM. Si no es este el caso, el procedimiento se acaba en la etapa 225. Si la red es del tipo GSM, el procedimiento continúa en la etapa 238, con la determinación de si la red es o no la red de origen. Si no es este el caso, el procedimiento se acaba en la etapa 225. Si se determina en la etapa 238 que la red es la red de origen, el dispositivo se coloca en la lista inmediata de escaneo en la etapa 239. En la etapa 240 el dispositivo se reinicia entonces en la modalidad normal. El procedimiento se acaba en la etapa 225.

El gestor indicado con E es activado por medio del suceso ‘gestor de conexión iniciado’ 241. En la etapa 242, el procedimiento de la figura 13 es detenido durante un tiempo predeterminado. El gestor se acaba entonces en la etapa

225. La segunda parte de este gestor es activada por medio del suceso ‘gestor de conexión detenido’ 243. El procedimiento de la figura 13 se reanuda entonces en la etapa 244. El gestor acaba en la etapa 225.

La Figura 15 muestra de manera esquemática una arquitectura según una realización adicional de la presente invención. Dado un conjunto de funciones y propiedades de un dispositivo, es posible, según la realización, llevar a cabo funciones en este dispositivo sin conocer los detalles y requisitos específicos para cada dispositivo. Es deseable, en términos generales, conocer qué parámetros, tales como las opciones de soporte y los subdispositivos de soporte, comprende un dispositivo, independientemente del origen de un dispositivo. A fin de lograr esto, se define una abstracción de un dispositivo, además de un conjunto de operaciones que pueden efectuarse sobre este dispositivo abstracto. Las funcionalidades requeridas para dar soporte a tal definición de dispositivo (operaciones y parámetros) se delegan a una capa específica dentro del módulo de esta realización. Este enfoque hace posible combinar la funcionalidad de las capas en un nivel inferior y ofrecer la funcionalidad combinada de las mismas en una forma más abstracta, en capas a un nivel superior. La repetición de este proceso de abstracción da como resultado una API que puede acceder a un dispositivo como una caja negra sobre la cual pueden realizarse operaciones específicas, sin que el usuario del módulo tenga conocimiento de los complejos trasfondos referidos a la instalación de un dispositivo o referidos a las características especiales de un dispositivo específico.

Como se ha descrito en lo precedente, el módulo comprende una pluralidad de capas, en donde cada capa proporciona funcionalidad que, cuando se añade al conjunto total, puede ser usada por otras capas dentro del módulo. Como se muestra en la figura 15, la API del módulo 250 permite el acceso a prácticamente todas las unidades que definen el módulo. Según el nivel de detalle requerido por el invocador de la API, puede obtenerse el acceso a submódulos de distintos niveles superiores o inferiores dentro del módulo 250.

El módulo 250 comprende los paquetes 257, 258, 259, 260, que están realizados como ficheros físicos que comprenden definiciones de dispositivos y datos de ficheros ordenados en un formato predeterminado. Un tal paquete comprende una cabecera que define el contenido del paquete, un manifiesto que comprende las definiciones del dispositivo y una tabla de búsqueda basada en el manifiesto, que comprende entradas para cada fichero, además de los datos de ficheros que comprenden los datos efectivos definidos en el manifiesto y la tabla de búsqueda.

El módulo 250 comprende adicionalmente un administrador 256 de ficheros para gestionar el contenido de los paquetes. El administrador de ficheros brinda acceso al contenido de los paquetes, tales como los datos de manifiestos y los datos de ficheros. El administrador de ficheros es además responsable de realizar operaciones de ficheros para el

55 E06075583 04-10-2011

paquete, tales como extraer ficheros y verificar el contenido de los datos de ficheros. El administrador de ficheros realiza las siguientes funciones: proporcionar acceso al manifiesto, validar un paquete según el manifiesto, extraer ficheros del paquete, realizar operaciones de ficheros tales como copiar y verificar ficheros, gestionar los ficheros extraídos y la limpieza de tales ficheros, determinar referencias del administrador de ficheros según se definen dentro del manifiesto y / o ayudar en la creación de un paquete.

El módulo 250 comprende adicionalmente un administrador 255 de paquetes para agrupar todos los paquetes disponibles y gestionar una base de datos interna con fines de referencia. Con respecto a un dispositivo conector específico, tal como un teléfono móvil, el administrador 255 de paquetes es capaz de proporcionar información concerniente al paquete en el cual está definido el dispositivo. La funcionalidad proporcionada por el administrador de ficheros a la API del módulo hace posible obtener acceso al contenido de paquetes individuales. El administrador de paquetes es asimismo responsable de gestionar el agregado de nuevos paquetes y la eliminación de paquetes existentes como resultado de las solicitudes recibidas. El administrador de paquetes ha de ser llamado adicionalmente a fin de crear nuevos paquetes. El administrador de paquetes llamará a otros componentes, tales como el administrador de ficheros, a fin de cumplir la tarea de crear nuevos paquetes. Las responsabilidades del administrador de paquetes incluyen: permitir la enumeración de todos los paquetes disponibles, crear, eliminar y añadir paquetes, resolver referencias de dispositivos con respecto a paquetes específicos y monitorizar el uso de paquetes.

El módulo 250 comprende adicionalmente un administrador 252 de dispositivos para visualizar todos los dispositivos conectores definidos, por medio del uso de la base de datos del módulo. El administrador de paquetes proporciona la opción de recuperar las propiedades de un dispositivo y hace posible que se realicen funciones sobre dispositivos, tales como la instalación de los mismos, la detección de los mismos y la eliminación de los mismos. Las responsabilidades del administrador de dispositivos son: permitir la enumeración de, y obtener acceso a, todos los dispositivos definidos, permitir el acceso a los paquetes asociados a los dispositivos, por medio del administrador de paquetes, haciendo posible que se realicen operaciones sobre los dispositivos, y haciendo posible obtener acceso a las propiedades de los dispositivos.

El módulo 250 comprende adicionalmente un motor 253 de ejecución que forma parte del administrador 252 de dispositivos. El motor de ejecución es responsable de ejecutar secuencias para operaciones específicas definidas en un paquete de dispositivos. La funcionalidad de este módulo no es directamente accesible por medio de la API del módulo, aunque se obtiene acceso indirecto por medio de una solicitud para que el administrador de dispositivos realice una operación sobre un dispositivo.

El módulo 250 comprende adicionalmente un virtualizador 254 para configurar la API. Para algunas aplicaciones, tales como la instalación, detección y eliminación de dispositivos, se requiere una API de win32 específica, la denominada API de configuración. Esta API hace posible obtener acceso al administrador de dispositivos y hace posible gestionar y enumerar todos los dispositivos instalados en un ordenador de Windows. Distintas sesiones de Windows dan soporte a distintos conjuntos de funcionalidades de la API de configuración, para cuyo fin se ha desarrollado una capa de virtualización según la presente realización. Esta capa determina automáticamente qué funcionalidad específica de la API de configuración dispone de soporte en el ordenador actual de Windows, y proporciona la funcionalidad deseada sin que el usuario tenga que tener conocimientos a este fin. Dentro del concepto inventivo, tal procedimiento puede realizarse asimismo bajo otro sistema operativo.

Un ejemplo de la realización descrita en lo precedente se refiere a pedir a un módem que informe sobre las redes de GSM visibles. El comando ‘AT+COPS?’, por ejemplo, se envía con este fin al módem. Después de un tiempo (el módem necesita este tiempo para buscar las redes visibles), se envía una respuesta con una estructura estandarizada. Para algunos tipos de teléfono es necesario un comando distinto a fin de recuperar la lista de redes, o bien la respuesta tiene una estructura diferenciada. Un problema aquí es que ha de accederse a los distintos teléfonos o dispositivos de comunicación que pueden usarse como dispositivo conector de distintas maneras.

La Figura 16 muestra esquemáticamente la comunicación entre el ordenador y el teléfono. El módulo M del GSM envía una solicitud 261 a la API A del DMM (Módulo de Gestión de Dominios) por medio de una instrucción 262 de búsqueda de red, que es la ‘AT+COPS?’ estándar. Esto es convertido en la API del DMM en la instrucción no estándar ‘AT+COPS123?’ 263 que es inteligible para el dispositivo. El dispositivo D lleva entonces a cabo la instrucción en la etapa 264 e informa de los resultados en su propio formato en la etapa 265 a la API A. Esta recibe los datos / resultados específicos del dispositivo y los convierte en la etapa 266 a un formato genérico. En la etapa 267, la API informa los resultados formateados al módulo de GSM, que procesa las redes halladas en la etapa 268. De esta manera, una pluralidad de instrucciones generales puede ser procesada por distintos dispositivos que requieren instrucciones específicas del dispositivo para este fin.

La técnica anterior resuelve el problema de hacer que el ordenador tome contacto con el teléfono por medio de software, incluyendo todas las posibles variaciones en el software. Esta es una solución estática, en la cual cualquier cambio requiere modificación del software.

Según la presente realización, este problema se resuelve definiendo una capa intermedia abstracta que traduce el comando ‘buscar red’, en base a tablas dinámicas de traducción, en el comando requerido para el dispositivo con el cual está teniendo lugar la comunicación en ese momento. La respuesta que el dispositivo envía de vuelta es asimismo traducida, en donde esta respuesta es convertida por la capa intermedia, a partir de un formato específico del

5 dispositivo, en un formato genérico, por lo cual son innecesarias las excepciones específicas del dispositivo en el software según la técnica anterior. Proporcionar un módulo de traducción por dispositivo es mucho más sencillo de implementar y de gestionar, en particular, en un número muy grande de ordenadores geográficamente remotos, que modificar la versión configurada del software de comunicación.

La presente invención se describe en detalle en base a las realizaciones preferidas. Estas no son limitativas para el

10 objetivo de la protección, y los distintos aspectos pueden variar entre sí dentro del contexto del texto. Los derechos solicitados están definidos por las reivindicaciones adjuntas.

45 E06075583 04-10-2011

Claims (20)

1. REIVINDICACIONES

   1. Procedimiento para conectar un ordenador de manera dinámica con una red de ordenadores, tal como Internet, mediante al menos una conexión seleccionable entre un cierto número de conexiones seleccionables, de las cuales al menos una es inalámbrica, que hace uso de una red, y al menos un dispositivo conector seleccionable, entre un número de dispositivos seleccionables, permite una conexión inalámbrica, que puede acoplarse al mismo, en el que las conexiones pueden incluirse en una lista de prioridades, efectuándose el procedimiento en el ordenador y comprendiendo etapas para:

   -

   definir al menos un conjunto de conexiones de red por medio de la comprobación de dispositivos conectores disponibles,

   -

   definir la conexión disponible con la mayor prioridad como conexión candidata,

   -

   si una conexión está activa, interrumpir esta conexión y hacer conexión con la conexión candidata, si es distinta a la conexión activa,

   -

   si no está activa ninguna conexión, hacer conexión por medio de la conexión candidata,

   -

   repetir estas etapas después de un primer periodo temporal predeterminado, o al ocurrir un suceso predeterminado, tal como el agregado o la eliminación de un dispositivo conector, estando el procedimiento caracterizado por etapas para:

   -

   recoger información concerniente al uso de conexiones en el periodo temporal pasado e información de configuración del ordenador, para transferir la información recogida a un servidor.

2. 2.

   Procedimiento según la reivindicación 1, que comprende etapas para descargar desde un servidor de actualización datos referidos a dispositivos de conexión, redes, módulos de servicio y / o una interfaz de usuario, en el que estos datos se transfieren en un formato estandarizado, tal como un formato de XML.

3. 3.

   Procedimiento según la reivindicación 1 o 2, que comprende etapas para recoger datos referidos a datos de instalación con respecto a software en el ordenador para llevar a cabo el procedimiento, hardware y / o sistema operativo del ordenador, y convertir esta información a un formato estandarizado de datos tal como el XML, para la transferencia de los mismos como una solicitud de datos al servidor de actualización.

4. 4.

   Procedimiento según una o más de las reivindicaciones precedentes, que comprende etapas de convertir los datos enviados al servidor de actualización en una clave de configuración.

5. 5.

   Procedimiento según una o más de las reivindicaciones precedentes, que comprende etapas para codificar los datos para su transmisión.

6. 6.

   Procedimiento según una o más de las reivindicaciones precedentes, que comprende etapas para seleccionar una conexión en condiciones de itinerancia, en el que puede asignarse una prioridad a parámetros de conexiones.

7. 7.

   Procedimiento según una o más de las reivindicaciones precedentes, en el cual la etapa para definir el conjunto de conexiones de red disponibles comprende etapas (157) para detectar dispositivos conectores.

8. 8.

   Procedimiento según una o más de las reivindicaciones precedentes, que comprende etapas (164) para obtener datos referidos a los dispositivos conectores.

9. 9.

   Procedimiento según una o más de las reivindicaciones precedentes, en el cual el conjunto de las conexiones disponibles se define en base a dispositivos conectores disponibles.

10. 10.

    Procedimiento según una o más de las reivindicaciones precedentes, que comprende etapas (178) para instalar dispositivos conectores.

11. 11.

    Procedimiento según una o más de las reivindicaciones precedentes, que comprende etapas para exhibir el conjunto de conexiones de red disponibles en una lista de una interfaz de usuario.

12. 12.

    Procedimiento según una o más de las reivindicaciones precedentes, en el cual las conexiones pueden categorizarse en base a una propiedad de ser capaces de funcionar bajo un régimen de conexión flexible, tal como un protocolo IP móvil, que comprende etapas para:

    -

    cambiar el régimen si la conexión candidata requiere un régimen distinto al de la conexión existente,

    -

    conectarse con conexiones de red bajo el régimen flexible si la candidata puede funcionar bajo un régimen de conexión flexible,

    45 E06075583 04-10-2011

    -

    conectarse bajo un régimen normal si la candidata no funciona bajo un régimen de conexión flexible.

13. 13. Procedimiento según una o más de las reivindicaciones precedentes, que comprende etapas para cambiar de conexión, dentro del tiempo de repetición predeterminado, dentro de la categoría de conexiones capaces de funcionar bajo el régimen flexible, que comprende etapas para:

    -

    determinar un conjunto de conexiones que funcionan bajo el régimen flexible, por medio de comprobaciones de accesibilidad,

    -

    determinar la conexión disponible con la mayor prioridad como candidata flexible,

    -

    cambiar la conexión desde la conexión existente a la candidata flexible,

    -

    repetir estas etapas después de un segundo periodo temporal predeterminado, o un suceso predeterminado.

14. 14.

    Procedimiento según una o más de las reivindicaciones precedentes, en el cual las conexiones comprenden conexiones inalámbricas tales como WiFi, GSM, GPRS, UMTS, DECT, CSD y / o EDGE.

15. 15.

    Procedimiento según una o más de las reivindicaciones precedentes, que comprende etapas para observar si está disponible una conexión, en el cual las disponibilidades de las conexiones de la lista de prioridades se comprueban sucesivamente en cuanto a la disponibilidad de las mismas, y la disponibilidad de las redes usadas para la conexión.

16. 16.

    Procedimiento según la reivindicación 15, que comprende etapas para:

    -

    determinar si la red de origen está disponible,

    -

    determinar qué redes están disponibles si la red de origen no está disponible,

    -

    conectarse con una segunda red en base a prioridades predeterminadas con respecto a parámetros de las conexiones a establecer, tales como velocidad de conexión, costes de conexión o red de conexión.

17. 17.

    Procedimiento según una o más de las reivindicaciones precedentes, que comprende etapas para tener en cuenta datos de prioridad referidos a dispositivos conectores.

18. 18.

    Servidor de actualización para actualizar datos referidos a un administrador de conexiones que funciona en un ordenador para conectar el ordenador, de manera dinámica, con una red de ordenadores tal como Internet, mediante al menos una conexión seleccionable conocida, que es seleccionable entre un número de conexiones seleccionables, de las cuales al menos una es inalámbrica, que hace uso de una red y al menos un dispositivo conector seleccionable conocido, que es seleccionable entre un número de dispositivos seleccionables, al menos uno de los cuales permite una conexión inalámbrica, en el que las conexiones conocidas pueden incluirse en una lista de prioridades, que comprende:

    -

    medios de almacenamiento de datos para almacenar en medios de almacenamiento los datos referidos al menos a conexiones, dispositivos conectores, redes y / o mensajes,

    -

    medios de recepción de solicitudes, para recibir una solicitud referida a datos almacenados,

    -

    medios de procesamiento de solicitudes, para procesar las solicitudes,

    -

    medios de transmisión de datos para transmitir datos almacenados a un cliente de conexión, en base a la solicitud, caracterizado por:

    -

    medios de recepción y procesamiento de datos para recibir desde el ordenador información recogida en el ordenador, concerniente al uso de conexiones en el periodo temporal pasado, e información de configuración del ordenador, y para procesar esta información recibida.

19. 19.

    Producto de programa de ordenador que comprende instrucciones que, cuando se ejecutan en un ordenador, realizan las etapas de procedimiento según las reivindicaciones 1 a 17.

20. 20.

    Sistema para actualizar datos de conexión en un ordenador cliente, que comprende:

    -

    un servidor de actualización según la reivindicación 18,

    -

    un número de clientes de conexión para conectar un ordenador con una red de ordenadores, tal como Internet, mediante al menos una conexión seleccionable y definible, que hace uso de una red, y al menos un dispositivo conector seleccionable, en el que las conexiones definidas pueden incluirse en una lista de prioridades, en el que cada cliente de conexión está adaptado para realizar las etapas de procedimiento según una o más de las

    reivindicaciones 1 a 17, y / o en el que el cliente de conexión hace uso de un producto de programa de ordenador según la reivindicación 19.