ES2368211T3

ES2368211T3 - Un procedimiento de sincronización iniciado por servidor en un sistema de sincronización donde el mensaje de solicitud del servidor tiene un tamaño máximo.

Info

Publication number: ES2368211T3
Application number: ES02767509T
Authority: ES
Inventors: Jerry Lahti; Mikko Sahinoja; Gaurav Mittal
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2001-10-09
Filing date: 2002-10-08
Publication date: 2011-11-15
Anticipated expiration: 2022-10-08
Also published as: CN1565101A; US20030101329A1; JP2005505990A; RU2298287C2; RU2004114237A; EP1435149A1; EP1435149B1; ZA200402747B; KR20040041677A; WO2003032569A1; US7155521B2; US20060004922A1; KR100737996B1; TWI270283B; CN1326346C; ATE521155T1; MY135261A; JP4091544B2

Abstract

Un procedimiento de inicio de una sesión en un sistema de sincronización que comprende al menos un dispositivo electrónico que actúa como un dispositivo cliente, y que comprende medios de comunicación, al menos un servidor de sincronización y una red de comunicación que proporciona un servicio de transmisión de mensajes, en el cual el servidor de sincronización está configurado para determinar (401), para una solicitud que indica la necesidad de iniciar una sesión, y a transmitir al dispositivo cliente, un identificador del servidor de sincronización, un identificador de versión y un identificador de la sesión solicitada, comprendiendo el procedimiento: determinar (402) en el servidor de sincronización el tamaño máximo para un mensaje que ha de enviarse desde el servidor de sincronización al dispositivo cliente para la solicitud, determinar (402) instrucciones de codificación, por las cuales al menos uno de los identificadores pueda codificarse en una secuencia de bits que requiera significativamente menos bits que su presentación en ASCII, en el servidor de sincronización, e instrucciones de descodificación, por medio de las cuales se obtenga el identificador original a partir de la secuencia de bits, en el dispositivo cliente, en respuesta a la necesidad de transmitir la solicitud que indica la necesidad de iniciar una sesión a al menos un dispositivo cliente, formar (405) un mensaje, siendo este mensaje más corto que, o tan largo como, dicho tamaño máximo, y comprendiendo al menos dichos identificadores, al menos uno de los cuales se presenta como una secuencia de bits definida según las instrucciones de codificación, transmitir (406) el mensaje al dispositivo cliente usando dicho servicio de transmisión de mensajes, formar (408) un mensaje de inicialización de sesión en base a la información incluida en el mensaje recibido, estando al menos parte de dicha información definida, a partir de la secuencia de bits recibida, por medio de dichas instrucciones de descodificación, y transmitir (409) el mensaje de inicialización de sesión desde el dispositivo cliente al servidor de sincronización.

Description

Un procedimiento de sincronización iniciado por servidor en un sistema de sincronización donde el mensaje de solicitud del servidor tiene un tamaño máximo.

Antecedentes de la invención

La invención se refiere a la disposición de una sesión entre un servidor de sincronización y un dispositivo cliente y, en particular, a iniciar una sesión por iniciativa de un servidor de sincronización.

Los datos de terminales portátiles, tales como teléfonos móviles, pueden sincronizarse con aplicaciones en red, aplicaciones de ordenador de sobremesa u otras bases de datos del sistema de telecomunicación. En particular, los datos de aplicaciones de calendario y de correo electrónico están habitualmente sincronizados. Anteriormente, la sincronización se ha basado en el uso de distintos protocolos específicos del fabricante, que son incompatibles. Esto limita el uso de terminales o tipos de datos a usar y a menudo causa dificultades al usuario. En la comunicación móvil, en particular, es importante que los datos puedan extraerse y actualizarse independientemente del terminal y aplicación usados. Para mejorar la sincronización de datos de aplicación, se ha desarrollado un SyncML (Lenguaje de Marcado de Sincronización), que se basa en el lenguaje XML (Lenguaje de Marcado Extensible). Usando un protocolo de sincronización de SyncML, que emplea mensajes de SyncML, los datos de cualquier aplicación pueden sincronizarse entre terminales en red de cualquier clase.

La Figura 1 ilustra un ejemplo de sincronización donde una estación móvil MS actúa como un dispositivo cliente de SyncML y un servidor S de red actúa como un servidor de SyncML. El servicio de sincronización de SyncML comprende inicializar primero una sesión de sincronización (Inicialización de Sesión de SyncML) durante la cual, por ejemplo, se selecciona la base de datos a sincronizar. Una MS agente cliente envía al servidor S un mensaje de SyncML (Modificaciones de Cliente) que comprende al menos los datos que han de sincronizarse en la estación móvil MS y que han cambiado desde la última sincronización. El servidor S sincroniza los conjuntos de datos, es decir, analiza los cambios hechos en los conjuntos de datos y armoniza los datos (hace las modificaciones, reemplazos, borrados y agregados necesarios). Después de esto, el servidor S envía las modificaciones del servidor de vuelta al dispositivo cliente TE, que hace los cambios necesarios en su base de datos.

Otros tipos de datos también pueden sincronizarse por medio del SyncML, por lo cual una nueva configuración vinculada a la sincronización, por ejemplo, puede sincronizarse con el dispositivo cliente. En general, la gestión de dispositivos se refiere a procedimientos por los cuales un tercero puede cambiar la configuración de un dispositivo, p. ej., cambiar configuraciones o incluso un protocolo usado por el dispositivo. Además de las configuraciones vinculadas sólo al dispositivo, también es posible enviar datos específicos del usuario, tales como perfiles de usuario, logotipos, tonos de llamada y menús, por medio de los cuales el usuario pueda personalizar las configuraciones del dispositivo, o bien las adaptaciones son hechas automáticamente en la gestión de dispositivos. Las características que han sido definidas en el estándar del SyncML pueden utilizarse con respecto al concepto de gestión de dispositivos. Un servidor de sincronización puede actuar como un servidor de gestión de dispositivos y un dispositivo cliente como un dispositivo a gestionar (Cliente de Gestión de Dispositivos).

La Figura 2 ilustra la gestión de dispositivos (Sesión de Gestión de Cliente) según un mensaje de un protocolo de sincronización. En un menaje de inicialización de sesión, un dispositivo cliente (MS) transmite a un servidor S de sincronización, que efectúa la gestión de dispositivos, información sobre sí mismo (la misma información que en la sincronización) al servidor, en respuesta a lo cual el servidor transmite información propia y comandos de gestión de dispositivos (Operaciones de Gestión de Servidor). El dispositivo cliente responde con información de estado, después de lo cual el servidor puede terminar la sesión o transmitir más comandos de gestión de dispositivos. Si el servidor transmite más comandos de gestión, el dispositivo cliente debería responder a esto con información de estado. Después de recibir información de estado, el servidor siempre puede terminar la sesión o continuarla transmitiendo más comandos de gestión de dispositivos. El protocolo de gestión de dispositivos también puede funcionar de tal manera que las consultas concernientes a lo que al usuario le guste actualizar se transmitan primero al usuario, y la información sobre las elecciones del usuario se transmita el servidor. Después de esto, el servidor puede transmitir las actualizaciones / operaciones requeridas por el usuario en el próximo paquete.

Según el protocolo SyncML, un dispositivo cliente inicia habitualmente una sesión de sincronización. Sin embargo, en particular en el contexto de la gestión de dispositivos, hay casos en los cuales el servidor tiene la necesidad de iniciar la sincronización. Para este caso, la especificación del SyncML “Protocolo de Sincronización SyncML, versión 1.0.1”, de mayo de 2001, capítulo 8 (páginas 49 a 50) describe una inicialización de sesión de sincronización causada por un servidor (Sincronización Alertada por Servidor): el servidor puede enviar un mensaje de solicitud (Alerta de Sincronización), en el cual solicita al dispositivo cliente iniciar una sesión de SyncML. Después de esto, el dispositivo cliente comienza la inicialización de la sesión de SyncML transmitiendo un paquete (Paquete de Inicialización de Cliente) convencional. Cuando el dispositivo cliente es una estación móvil, surgen problemas debido a los hechos de que el dispositivo cliente no puede ser localizado cuando la estación móvil está apagada, o que no hay ninguna conexión continua de transmisión de datos entre el terminal y el servidor. Es por esto que es ventajoso usar un servicio que almacene el mensaje cuando se transmite la solicitud. Uno de tales servicios es el SMS (Servicio de Mensajes Breves), que almacena un mensaje de texto en un centro de mensajes de texto y lo envía cuando la estación móvil se conecta con la red y puede ser localizada. Como otros mensajes de SyncML, una solicitud para iniciar una sesión está en formato XML y comprende un campo de cabecera, que está determinado en un elemento [SyncHdr], y una parte de cuerpo, que está determinada en un elemento [SyncBody]:

...

</SyncHdr>

...

</SyncBody>

</SyncML>

La solicitud es relativamente grande y requiere una capacidad mucho mayor que los 140 octetos proporcionados por el mensaje de texto (que es suficiente para codificar 160 caracteres ASCII de 7 bits). La solicitud puede dividirse en varios mensajes de texto, pero es posible que uno de los mensajes de texto desaparezca, que los menajes lleguen en orden incorrecto o que el dispositivo cliente no pueda procesar mensajes de texto concatenados. Si un servicio de capa de transporte es proporcionado por el WAP (Protocolo de Aplicaciones Inalámbricas), por ejemplo, los mensajes de SyncML pueden codificarse en formato binario WBXML (XML Binario Inalámbrico), y se requiere menos capacidad de transmisión de datos. Incluso aunque se usara el WBXML, la solicitud aún requiere varios mensajes de texto.

El documento WO 00/29.998 se refiere a la optimización de procedimientos de sincronización utilizando un registro de cambios para aumentar la eficiencia de la sincronización de información entre un primer dispositivo y un segundo dispositivo. El segundo dispositivo mantiene un valor contador de cambios asociado a una última entrada sincronizada de un registro de cambios, almacenada en el primer dispositivo. El valor contador de cambios almacenado en el segundo dispositivo se actualiza preferiblemente después de que se procesa cada entrada del registro de cambios transferido en el segundo dispositivo, y en respuesta a actualizaciones de bases de datos realizadas en el primer dispositivo. Así, la segunda base de datos puede procesar sólo aquellos cambios de la primera base de datos que tengan lugar después del contador de cambios actualizado.

El documento WO 98/24.018 revela procedimientos para sincronizar bases de datos incompatibles, usando un fichero histórico que contiene registros que representan registros de una de las bases de datos en el momento de una sincronización anterior. Los procedimientos revelados se refieren a la sincronización de bases de datos en caso de un suceso recurrente. Un ejemplo de tal registro recurrente es un suceso que ocurre regularmente durante un periodo de tiempo. Por ejemplo, se revela una técnica que permite la sincronización de un registro recurrente individual (que representa al suceso recurrente) con una base de datos en la cual el mismo suceso recurrente se almacena como una serie de registros individuales.

La Patente Estadounidense 6.000.000 se refiere a la sincronización de datos entre un ordenador de mano y un ordenador personal. El sistema de sincronización se activa por una única pulsación de botón, y permite la sincronización de datos para varias aplicaciones distintas que se ejecutan en el sistema de ordenador de mano y el sistema de ordenador personal. El sistema mantiene una lista de bibliotecas que se usan para sincronizar distintas aplicaciones en el sistema de ordenador personal y el sistema de ordenador de mano. Después de obtener la lista, un administrador de sincronización invoca entonces a cada biblioteca, una por una, y cada biblioteca realiza la sincronización para una aplicación específica.

Breve descripción de la invención

Es por tanto un objetivo de la invención proporcionar un procedimiento y un aparato que implemente el procedimiento, de modo tal que puedan evitarse los problemas precitados. Los objetivos de la invención se logran por un procedimiento, un sistema de sincronización, un servidor de sincronización, un dispositivo electrónico y programas de ordenador, que se caracterizan por lo que se dice en las reivindicaciones independientes. Las realizaciones preferidas de la invención se revelan en las reivindicaciones subordinadas.

La invención se basa en seleccionar sólo la información más esencial, que está además codificada de tal manera que se requiere menos espacio, en comparación con la situación en la cual la información se transmitiría como texto abierto. El

procedimiento comprende configurar un servidor de sincronización para determinar, para una solicitud que indica la necesidad de iniciar una sesión, y a transmitir a la estación móvil, el identificador del servidor de sincronización, el identificador de una versión del protocolo de sincronización que disponga de soporte por parte del servidor de sincronización y el identificador de la sesión de sincronización solicitada. El tamaño máximo del mensaje que ha de 5 enviarse desde el servidor de sincronización a la estación móvil para la solicitud, y las instrucciones de codificación, por las cuales al menos uno de los identificadores puede codificarse en una secuencia de bits que requiere significativamente menos bits que su presentación en ASCII, se determinan en el servidor de sincronización. Las instrucciones de descodificación, por medio de las cuales se obtiene el identificador original a partir de la secuencia de bits, se determinan en la estación móvil. Cuando el fin es transmitir a al menos una estación móvil una solicitud que indica la necesidad de iniciar una sesión, se forma un mensaje, donde este mensaje es más corto que, o tan largo como, dicho tamaño máximo, y comprende al menos dichos identificadores, al menos uno de los cuales se presenta como una secuencia de bits definida según las instrucciones de codificación. El mensaje se transmite a la estación móvil usando un servicio de transmisión de mensajes. La estación móvil forma un mensaje de inicialización de sesión en base a la información incluida en el mensaje recibido, estando al menos parte de la información definida a partir de la secuencia de bits recibida según

15 dichas instrucciones de descodificación. El mensaje de inicialización de sesión se transmite desde la estación móvil al servidor de sincronización. La codificación utiliza la información concerniente a los distintos valores que los distintos campos pueden recibir. La correspondencia entre estos valores y los distintos patrones de bits se almacena en las instrucciones de codificación e instrucciones de descodificación a usar por parte del servidor y el cliente.

Ni la sesión, ni su inicialización, se restringen a las funciones definidas en el SyncML, sino que ha de entenderse, en sentido amplio, que se refieren a una sesión a establecer entre cualquier dispositivo cliente y el servidor de sincronización, y a los mensajes necesarios para establecer la sesión. En un sistema de sincronización, puede establecerse una sesión entre un dispositivo cliente y un servidor de sincronización a fin de sincronizar datos del usuario, o de gestionar el dispositivo.

La solución según la invención brinda la ventaja de que, a solicitud del servidor, también puede iniciarse una sesión en

25 dispositivos que no dan soporte a la recepción de mensajes concatenados. Cuando puede usarse un servicio de transporte de mensajes, tal como el SMS, proporcionado por la red móvil, siempre puede entregarse un mensaje a su destino (cuando el dispositivo está encendido), también en dispositivos que no permiten servicios no solicitados activados por la red. La solución de la invención también ayuda a evitar problemas que resultan de que la red conmutada por paquetes posiblemente entregue mensajes al cliente en un orden que difiere del orden en el cual el servidor los ha transmitido, o incluso que posiblemente se pierdan algunos mensajes. Además, como la transmisión de una solicitud requiere menos espacio, también pueden ahorrarse recursos de transmisión de datos y, como resultado, hay menos costes. Este ahorro puede ser muy significativo en casos donde el servidor tiene que transmitir una solicitud a un gran número de dispositivos clientes.

Breve descripción de los dibujos

35 Se describirá ahora la invención en mayor detalle, con respecto a las realizaciones preferidas, con referencia a los dibujos adjuntos, en los cuales:

la Figura 1 ilustra la sincronización según el protocolo de sincronización del SyncML;

la Figura 2 ilustra la gestión de dispositivos por parte de un servidor;

la Figura 3a ilustra un sistema de sincronización;

la Figura 3b ilustra un servidor de sincronización y un dispositivo cliente;

la Figura 4 ilustra un procedimiento según una realización preferida de la invención;

la Figura 5 muestra posibles elementos de un mensaje a enviar, a fin de iniciar una sesión de gestión de dispositivos; y

la Figura 6 es un diagrama de señalización de una sesión de gestión según una realización preferida de la invención.

Descripción detallada de la invención

45 En lo que sigue, se describe una realización preferida de la invención en un sistema que brinda soporte al estándar SyncML; ha de observarse, sin embargo, que la invención puede aplicarse en cualquier sistema de sincronización.

La Figura 3a ilustra un sistema en red en el cual los datos de las bases de datos pueden sincronizarse entre los servidores S de sincronización y las estaciones móviles MS. En la sincronización, la MS puede actuar como un dispositivo cliente y comprender de esa manera una base de datos a sincronizar. El servidor S puede servir a varios dispositivos clientes MS. También es posible que la estación móvil actúe como un servidor para otro dispositivo. La MS se comunica con el servidor S a través de una red móvil MNW (Red Móvil). También es posible que el S esté implementado en la red móvil MNW. El dispositivo cliente MS, que ha sido adosado a la red MNW, comprende una funcionalidad de estación móvil para comunicarse con la red MNW de manera inalámbrica. En lugar de una estación móvil convencional, la MS también puede ser cualquier dispositivo electrónico que comprenda una funcionalidad de mensajería, tal como un ordenador portátil o un dispositivo de agenda electrónica o, alternativamente, por ejemplo, un dispositivo auxiliar de estos dispositivos, que esté dispuesto en conexión con su dispositivo anfitrión por medio de su funcionalidad de mensajería, de modo que se use un enlace de radio de corto alcance, por ejemplo. En este caso, el dispositivo anfitrión debería ser capaz de deducir, en base a parte de la información codificada en el mensaje, que el mensaje está destinado al dispositivo auxiliar. La red móvil MNW comprende al menos un bloque MB que proporciona un servicio de mensajes. Entre la red móvil MNW y el servidor S también puede haber otras redes, tal como una red de área local LAN. La red móvil MNW puede ser cualquier red inalámbrica conocida, tal como una red que brinde soporte a un servicio del GSM (Sistema Global para Comunicaciones Móviles), una red que brinde soporte a un servicio del GPRS (Servicio General de Radio por Paquetes), una red móvil de tercera generación, tal como una red del UMTS (Sistema Universal de Telecomunicaciones Móviles), una red inalámbrica de área local WLAN o una red privada.

Si la MNW es una red del GSM, el bloque MB que proporciona un servicio de mensajes comprende al menos un centro SMSC de servicios de mensajes breves. Un importante servicio de la capa de transporte en varias redes móviles es el WAP, que comprende una capa del WSP (Protocolo de Sesión Inalámbrico), que puede usarse para proporcionar un servicio de transporte para la capa de aplicación de sincronización en el dispositivo cliente MS y en el servidor S. El WAP da soporte a varias tecnologías de transmisión de nivel inferior, tal como una transmisión basada en el SMS. También pueden usarse los estándares HTTP u OBEX, por ejemplo, y tecnologías de transmisión de capas inferiores a las que den soporte. El servidor S en sí puede comprender una base de datos que ha sincronizado, o bien la base de datos sincronizada por él puede situarse en otro dispositivo; en la Figura 3a, los servidores S y las bases de datos DB están separadas para mayor claridad.

Como se ilustra en la Figura 3b, las estaciones móviles MS y los servidores S comprenden la memoria MEM: SMEM, una interfaz UI de usuario: SUI, medios I/O de Entrada / Salida: SI/O, para disponer la transmisión de datos, y una unidad central CPU de procesamiento: SCPU, que comprende uno o más procesadores. La memoria MEM: SMEM tiene una parte no volátil para almacenar aplicaciones que controlan la unidad central CPU de procesamiento: SCPU, y otros datos a mantener, y una parte volátil a usar para el procesamiento de datos temporales. Los datos de aplicación, que son el objeto de la sincronización, se mantienen en la memoria MEM de la MS (que es, en el ejemplo, una base de datos a sincronizar para la sincronización) y en la memoria de las bases de datos DB.

El dispositivo cliente MS comprende un agente cliente CA, que es responsable de las funciones vinculadas con la sesión en el dispositivo cliente. El servidor S comprende una agente servidor SA que gestiona la sesión y un motor SE de sincronización. El CA es implementado preferiblemente por la CPU al ejecutar un código de programa de ordenador almacenado en la memoria MEM, y el SA y el SE son implementados por la SCPU al ejecutar un código de programa de ordenador almacenado en la memoria SMEM. Estos medios pueden también disponerse para implementar una sesión de gestión de dispositivos, o bien la sesión de gestión de dispositivos puede ser gestionada por entidades distintas, que no se muestran en la Figura 3b. Por medio de códigos de programa de ordenador ejecutados en las unidades centrales CPU y SCPU de procesamiento, también se logra que el dispositivo cliente MS y el servidor S de sincronización implementen medios inventivos, cuyas realizaciones se ilustran en las Figuras 4 y 6. Pueden obtenerse programas de ordenador a través de la red y / o almacenarse en medios de memoria, tal como un disquete, un CD-ROM u otro medio de memoria externa, desde el cual pueden cargarse en la memoria MEM o SMEM. También pueden usarse soluciones de hardware o una combinación de hardware y software.

La Figura 4 ilustra un procedimiento según una realización preferida de la invención. La información sobre los identificadores requeridos para una solicitud que indica la necesidad de iniciar una sesión (para sincronizar datos de usuario o para gestión de dispositivos) se establece 401 en el servidor de sincronización. Estos incluyen al menos el identificador de un servidor de sincronización, el identificador de una versión del protocolo de sincronización que disponga de soporte por parte del servidor de sincronización y el identificador de la sesión de sincronización solicitada. Las instrucciones de codificación y el tamaño máximo para los mensajes que se envían para indicar la necesidad de iniciar una sesión se determinan 402 en el servidor S de sincronización. El tamaño máximo puede determinarse según el servicio de transmisión de mensajes usado, p. ej., según el tamaño máximo para un mensaje de texto en el servicio de SMS. La determinación puede llevarse a cabo de modo tal que un valor numérico para el tamaño máximo se fije directamente para el dispositivo, por ejemplo, o bien el dispositivo se disponga para colocar los campos en lugares tales en el mensaje que la longitud del mensaje esté dentro de este tamaño máximo. El tamaño máximo también puede determinarse solicitando esta información a la red, o bien puede entregarse al dispositivo en la sesión de gestión, por ejemplo. El usuario también puede ingresar el tamaño máximo. El sistema de mensajes del dispositivo está dispuesto al menos para notificar a la aplicación que forma el mensaje cuando el tamaño del mensaje es demasiado grande. Las instrucciones de descodificación se determinan 402 en la estación móvil MS que actúa como un dispositivo cliente. Usando las instrucciones de codificación, el S puede codificar al menos uno de los identificadores a transmitir en una secuencia de bits que requiere significativamente menos bits que la presentación en ASCII o la presentación binaria en WBXML del identificador. Usando las instrucciones de codificación, el dispositivo cliente, por su parte, puede definir el identificador original a partir de la secuencia de bits.

Cuando se necesita transmitir 403 una solicitud que indica la necesidad de iniciar una sesión, desde un servidor a al menos un dispositivo cliente, el servidor S define 404, según las instrucciones de codificación, al menos una secuencia de bits para al menos parte de la información requerida en el mensaje. El mensaje requiere al menos los identificadores mencionados más adelante, pero habitualmente también incluye otra información. La información a transmitir se forma 405 en un mensaje. El servidor S también controla 405 que el mensaje no supere el tamaño máximo definido. Si el mensaje parece superar el tamaño máximo, el servidor S puede borrar campos menos importantes del mismo y / o, usando las instrucciones de codificación, codificar más información en una forma que requiera menos espacio. El mensaje se transmite 406 desde el servidor S al dispositivo cliente MS usando el servicio de transmisión de mensajes de la red MNW. Según una realización, puede usarse un servicio del SMS conocido por una persona experta en la técnica para transmitir el mensaje. En el dispositivo cliente MS, la información según las secuencias de bits en el mensaje recibido se define 407 para el mensaje de inicialización, usando las instrucciones de codificación almacenadas en el dispositivo cliente. En base a al menos un identificador obtenido de esta manera, y otra información incluida en el mensaje, la MS forma 408 un mensaje de inicialización de sesión y lo transmite 409 al servidor S de sincronización.

La sesión puede usarse para funciones de gestión de dispositivos, por lo cual el funcionamiento de la aplicación (CA) de sincronización del dispositivo cliente MS puede adaptarse por iniciativa de la red. Por ejemplo, si la dirección del servidor de sincronización (identificador URI) ha cambiado, es importante dar a conocer esto a todo dispositivo que se sincronice con este servidor. En el SyncML, esta solicitud, transmitida por el servidor a fin de iniciar una sesión de gestión de dispositivos, puede llamarse [Paquete #0: Alerta de Gestión a Cliente], porque el paquete de inicialización a transmitir para la inicialización en base a la solicitud es [Paquete #1: Inicialización de Cliente]. También es posible usar la sesión para la personalización realizada por el mismo usuario. El usuario puede adaptar las configuraciones a través de una interfaz de la WWW, por ejemplo, y, por iniciativa del servidor S de sincronización, estos cambios pueden transferirse al dispositivo cliente MS durante la sesión.

La Figura 5 ilustra posibles elementos de un mensaje formado (405) a fin de iniciar una sesión de gestión de dispositivos. Según una realización preferida, se aplica un servicio de mensajes no solicitados del protocolo WSP, usando mensajes del SMS, por lo cual el mensaje comprende un campo de cabecera del WSP. El campo de cabecera del WSP debe ser lo bastante breve (preferiblemente, de menos de 30 octetos), de modo que haya suficiente espacio para los campos de información destinada para el nivel de aplicación efectiva (CA) que procesa el mensaje. Ha de observarse que, además del campo del WSP, el mensaje también puede comprender otros campos de cabecera, tales como campos de cabecera del WDP (Protocolo Inalámbrico de Datagramas). En este caso, sin embargo, la proporción de los campos de información del SyncML disminuye. Según una realización, el mensaje también puede proporcionar una indicación de la aplicación a la cual debería dirigirse el contenido del mensaje. En base a la indicación, la MS puede dirigir los campos de información del mensaje a la entidad de aplicación correcta, p. ej., una solicitud para iniciar una sesión de gestión a un agente cliente CA. La indicación puede incluirse en el campo de cabecera del WSP o del WDP del mensaje. Un dispositivo que dé soporte al protocolo WAP reconoce fácilmente la información proveniente del mensaje, pero a un dispositivo no de WAP debe proporcionarse una ubicación predeterminada, desde la cual ha de extraerse la indicación de la aplicación. Esta ubicación puede determinarse usando una ubicación predeterminada a partir del comienzo del mensaje (desplazamiento) o de modo tal que la indicación siempre ocurra después de un cierto carácter en el campo de cabecera. Por ejemplo, en el campo de cabecera del WSP la indicación puede estar en el identificador ‘Identificador de Aplicación’ (x-wap-application-id), y el campo MIME también puede utilizarse en lugar del campo ‘Identificador de Aplicación’, o para especificar la información en el campo ‘Identificador de aplicación’.

En lo que sigue, se describen campos que pueden usarse en el mensaje.

Versión (VER). Contiene la versión del mensaje a usar y por tanto también la versión del protocolo, de modo que el dispositivo cliente pueda comprobar si el servidor S da soporte a la misma versión. El identificador de versión, alternativamente, puede indicar sólo la versión del mensaje o la versión del protocolo. El dispositivo cliente no necesita iniciar (408, 409) la sesión si da soporte a una versión distinta. El identificador de versión puede codificarse, según las instrucciones de codificación fijadas en el servidor S, en una secuencia de bits más breve, por ejemplo, de modo tal que se usen los primeros 10 bits después del campo de cabecera del WSP: el último número se refiere a los números de versión más pequeños, el anteúltimo se refiere a las unidades, el anterior al anteúltimo se refiere a las decenas y el anterior a este se refiere a las centenas, en cuyo caso la mayor versión posible es ‘102.3’ y la versión ‘1.0’ se codifica en una secuencia de bits ‘0000001010’. Como se ha afirmado anteriormente, la MS comprende instrucciones de descodificación para determinar (407) el identificador original a partir de la secuencia de bits.

Estas instrucciones de codificación pueden implementarse en el dispositivo como una tabla de correspondencia que ilustra qué secuencia de bits corresponde a qué número de versión. Alternativamente, esta tabla puede establecerse algorítmicamente para el dispositivo, de modo tal que sus elementos puedan producirse de manera programada sin necesidad de almacenar la tabla entera en la memoria del dispositivo. La tabla de correspondencia puede codificarse, por ejemplo, así:

0000001010: Versión 1.0

0000001011: Versión 1.1

...
...

1111111111: Versión 102.3

Identificador de Sesión (SID). Este campo determina el identificador de sesión, de modo tal que la misma sesión no se lleve a cabo más de una vez. Para este identificador, pueden usarse 16 bits después del identificador de versión, por ejemplo. Por ejemplo, si el dispositivo cliente está apagado, el servidor S puede enviar varios mensajes, por medio de los 5 cuales el servidor intenta establecer una sesión de gestión específica. En base al identificador SID, el dispositivo cliente puede deducir que debería iniciar sólo una conexión y no establecer una conexión según cada mensaje obtenido. El servidor S puede también priorizar sesiones de gestión de dispositivos por medio del campo SID, por ejemplo, definiendo un identificador SID específico para operaciones de gestión de dispositivos menos importantes. Cuando el dispositivo cliente configura una conexión para establecer una sesión, el servidor S puede impedir que se establezca la sesión, si

10 tiene dispositivos clientes más urgentes para servir. Esto puede disponerse de modo tal que el servidor S almacene en su memoria la información de que la sesión correspondiente al identificador SID transmitido es menos importante. Esto puede disponerse, alternativamente, de modo tal que los identificadores SID seleccionados a partir de un grupo específico, por ejemplo, sean menos importantes, lo que hace posible evitar el almacenamiento de información.

Modalidad de Interacción de Usuario (UI). Mediante este identificador, el servidor puede recomendar si la sesión

15 debería llevarse a cabo en segundo plano, o si el usuario debería ser informado acerca de la sesión. Este campo puede codificarse con dos bits, según la siguiente tabla de correspondencia, por ejemplo:

00: el servidor no tiene ninguna recomendación

01: ejecución recomendada en segundo plano (no mostrado al usuario)

10: mostrar identificador informativo al usuario

11: pedir permiso al usuario

Iniciativa de la Acción de Gestión (Init). Mediante este identificador, el servidor S puede comunicarse con el dispositivo cliente, ya sea que él mismo haya causado la sesión de gestión o que el dispositivo cliente (su usuario) la haya causado.

20 Esta información puede formar una base para la facturación y, así, el usuario del dispositivo cliente también puede ser facturado por la solicitud transmitida por el servidor, si el usuario la ha causado, es decir, la ha pedido. La información puede codificarse con dos bits según la siguiente tabla de correspondencia, por ejemplo:

01: iniciativa del cliente

10: iniciativa del servidor

Uso futuro de la Gestión de Dispositivos (Fut). En este campo, puede transferirse información posible que ha de

25 definirse más tarde, desde el servidor S al dispositivo cliente MS, para la sesión de gestión. Por ejemplo, pueden reservarse 30 bits de espacio. Un posible ejemplo de información a transferir en este campo es un momento en el cual el dispositivo cliente debería establecer una sesión con el servidor S de sincronización. La MS puede transmitir el mensaje

(409) de inicialización en el momento fijado por el servidor, y el servidor S, por ejemplo, puede equilibrar su carga fijando que los distintos dispositivos clientes establezcan una conexión a distintas horas.

30 Longitud del Secreto Compartido de Autenticación de Activador (Tlen). Este campo indica la longitud del campo TASS (Secreto Compartido de Autenticación de Activador).

Longitud del Origen (Ulen). Este campo indica la longitud del identificador (URI) del servidor S. Usando este campo y el campo Tlen, puede disponerse el mayor espacio posible para el campo URI. Si se usaran sólo campos de longitudes específicas, a menudo habría espacio sin usar al final del campo TASS.

35 Secreto Compartido de Autenticación de Activador (TASS). El campo TASS contiene un secreto compartido, por lo cual se impiden ataques de DoS (Denegación de Servicio). Este campo también puede usarse para determinar el identificador del servidor.

URI de Origen del Servidor de Gestión (URI de Origen). El campo contiene el identificador URI del servidor, p. ej., ‘http://www.syncml.org/mgmt-server’. En ciertos casos, este campo también puede abreviarse eliminando el identificador de protocolo, por ejemplo, o bien, en lugar de la dirección del servidor, transmitiendo sólo el identificador más breve en el campo. Alternativamente, el campo TASS puede usarse para transmitir el identificador del servidor.

Proveedor (Proveedor). Este campo es optativo y puede incluir información específica del fabricante, tanto como el mensaje pueda admitir después de los campos precedentes.

En los campos precitados los campos de información está planeada de modo tal que se necesite tan poco espacio como sea posible. Si todos los campos se transmitieran como texto en formato XML, se necesitarían alrededor de 400 caracteres, es decir, miles de bits. Un campo ocupa al menos unos pocos caracteres, es decir, docenas de bits. Cuando al menos algunos de los campos utilizan los procedimientos de codificación precitados, cada uno de los cuales se obtiene a partir del conocimiento concerniente a los distintos valores que cada campo puede tomar, es posible ahorrar espacio de manera significativa, y hacer (borrando adicionalmente campos menos importantes, si es necesario) que la información quepa en un mensaje del SMS. El Apéndice 1, que es parte de la especificación, muestra otro ejemplo de campos de mensaje, en lo que respecta sólo a los campos de información de SyncML.

La Figura 6 muestra un diagrama de señalización de una sesión de gestión de dispositivos, que se inicia a pedido del servidor (S) de sincronización. Cuando el servidor y el dispositivo cliente (MS) pueden comunicarse 601 (al menos de modo tal que la MS sea capaz de recibir mensajes; también se han llevado a cabo las etapas 401 a 402 de la Figura 4), el servidor recibe 602 un comando para iniciar una sesión de gestión desde el usuario del servidor, desde fuera del servidor

o en base a una configuración predeterminada. En respuesta, el servidor reúne los datos necesarios, lleva a cabo los cambios según las instrucciones de codificación y transmite 603 un mensaje según la solicitud [Paquete #0: Alerta de Gestión a Cliente] al dispositivo cliente. En base a esto, el dispositivo cliente y el servidor pueden establecer una sesión 604 de gestión. El servidor S puede transmitir comandos de gestión al dispositivo cliente, y el dispositivo cliente altera su configuración en base a estos comandos de gestión. Después de que se completa 605 la sesión de gestión, el resultado puede presentarse 606 para el usuario del servidor.

La sesión puede usarse para sincronizar datos convencionales de usuario, p. ej., para actualizar marcas de calendario de la estación móvil y la aplicación de calendario de la red. En este caso, una iniciativa para iniciar la sincronización (403) puede tener lugar, por ejemplo, cuando se añada una nueva marca importante de calendario, que necesita ser entregada a la estación móvil tan pronto como sea posible, al calendario de red. Como el mensaje formado para la sesión de gestión de dispositivos, e ilustrado en la Figura 4, el mensaje que se forma a fin de solicitar una sesión de SyncML comprende varios campos correspondientes. Al menos los campos marcados con una estrella, Versión (VER*), Identificador de Sesión (SID*), Origen y URI del Servidor de Gestión (URI*), también son requeridos en el mensaje a formar para la solicitud de iniciar la sincronización. La información de al menos los campos (UI), (VER*) e (Init) puede convertirse en una secuencia breve de bits, de la manera descrita anteriormente. El mensaje también puede incluir información sobre la sesión de sincronización que el servidor requiere. Tal información incluye, en particular, una indicación del tipo de sincronización requerido por el servidor S (p. ej., Doble Vía, Sincronización de Vía Única desde el servidor solamente, Vía Única desde el cliente solamente, Sincronización de Refresco desde el servidor solamente). Esta información también puede codificarse (404) y descodificarse (407) utilizando una tabla de correspondencia prealmacenada (402), por lo cual puede guardarse el número de bits requeridos. También puede ser útil transmitir el identificador (URI) de la base de datos (que el servidor necesita para sincronizarse) en el mensaje. Después de que el dispositivo cliente MS de SyncML recibe el mensaje, puede transmitir (409) un paquete de inicialización de sesión de sincronización (Paquete de Inicialización de Sincronización desde Cliente) según la información incluida en el mensaje, y puede inicializarse la sesión de sincronización. Para una descripción más específica de la sesión de sincronización del protocolo SyncML y de la información requerida para ella, se incorpora la especificación del SyncML “Protocolo de Sincronización SyncML, versión 1.0.1”, de mayo de 2001, en la aplicación como una referencia. Así, pueden lograrse las mismas ventajas cuando tanto una sesión de gestión como una sesión de sincronización de datos de usuario se inician a pedido del servidor de sincronización.

También es posible que dicho mensaje se forme 405 en algún lugar distinto al servidor S que transmite la solicitud. Una situación como esta puede ocurrir, por ejemplo, cuando un dispositivo cliente se comunica con una pasarela del WAP por medio de una pila del WAP, y se usa un protocolo HTTP entre la pasarela del WAP y el servidor S. La pasarela del WAP, por ejemplo, puede condensar entonces la solicitud transmitida por el servidor de la manera descrita anteriormente (usando instrucciones de codificación), de modo que pueda transmitirse en un mensaje al dispositivo cliente MS.

Es obvio para una persona experta en la técnica que, según se desarrolla la tecnología, la idea básica de la invención puede implementarse en una gran variedad de formas. También ha de observarse que los mensajes no se restringen a mensajes del servicio del SMS, sino que también pueden usarse otros tipos de servicios de transmisión de mensajes, tal como un servicio MMS (Servicio de Mensajería Multimedios). La invención y las realizaciones de la misma, por tanto, no se restringen a los ejemplos descritos anteriormente, sino que pueden modificarse dentro del alcance de las reivindicaciones.

Apéndice 1. Ejemplo de información incluida en un mensaje REIVINDICACIONES

Valor hexadecimal: Contenido Descripción

‘0000001010’: Versión ‘1.0’

‘0000000000000001’: Identificador de sesión SID = ‘1’

‘01’: UI = ‘01’

‘00’: Init = ‘00’

‘000000000000000000000000000’: Uso futuro

‘1000’: Longitud de TASS = ‘8’

‘0000100010’: Longitud de URI = ‘34’

30, 30, 4A, 31, 59, 32, 55, 79: ‘00J1Y2Uy’ TASS

68, 74, 74, 70, 3A, 2F, 2F, 77, 77, 77, 2E, 6D, 6E, 67, 6D, 74, 73, 65, 72, 76, 65, 72, 2E, 63, 6F, 6D, 2F, 6D, 61, 6E, 61, 67, 65, 2F: ‘http://www.mngmtserver.com/manage/’ URI

Claims

Reivindicaciones

1. Un procedimiento de inicio de una sesión en un sistema de sincronización que comprende al menos un dispositivo electrónico que actúa como un dispositivo cliente, y que comprende medios de comunicación, al menos un servidor de sincronización y una red de comunicación que proporciona un servicio de transmisión de mensajes, en el cual

el servidor de sincronización está configurado para determinar (401), para una solicitud que indica la necesidad de iniciar una sesión, y a transmitir al dispositivo cliente, un identificador del servidor de sincronización, un identificador de versión y un identificador de la sesión solicitada, comprendiendo el procedimiento:

determinar (402) en el servidor de sincronización el tamaño máximo para un mensaje que ha de enviarse desde el servidor de sincronización al dispositivo cliente para la solicitud,

determinar (402) instrucciones de codificación, por las cuales al menos uno de los identificadores pueda codificarse en una secuencia de bits que requiera significativamente menos bits que su presentación en ASCII, en el servidor de sincronización, e instrucciones de descodificación, por medio de las cuales se obtenga el identificador original a partir de la secuencia de bits, en el dispositivo cliente,

en respuesta a la necesidad de transmitir la solicitud que indica la necesidad de iniciar una sesión a al menos un dispositivo cliente, formar (405) un mensaje, siendo este mensaje más corto que, o tan largo como, dicho tamaño máximo, y comprendiendo al menos dichos identificadores, al menos uno de los cuales se presenta como una secuencia de bits definida según las instrucciones de codificación,

transmitir (406) el mensaje al dispositivo cliente usando dicho servicio de transmisión de mensajes,

formar (408) un mensaje de inicialización de sesión en base a la información incluida en el mensaje recibido, estando al menos parte de dicha información definida, a partir de la secuencia de bits recibida, por medio de dichas instrucciones de descodificación, y

transmitir (409) el mensaje de inicialización de sesión desde el dispositivo cliente al servidor de sincronización.
2.

Un procedimiento según la reivindicación 1, en el cual

un servicio de capa de transporte en el sistema de sincronización está configurado usando un protocolo de aplicaciones inalámbricas, por lo cual el mensaje comprende adicionalmente campos de cabecera del protocolo de sesión inalámbrica.
3.

Un procedimiento según la reivindicación 2, en el cual

el mensaje también indica una aplicación a la cual debería dirigirse el contenido del mensaje, estando la indicación definida al fijar la información sobre la aplicación en una ubicación predeterminada, como desde el comienzo del mensaje,

o después de un carácter predeterminado, y el contenido del mensaje se dirige en el dispositivo cliente a la aplicación indicada por el mensaje.
4.

Un procedimiento según cualquiera de las reivindicaciones precedentes, en el cual el servicio de transmisión de mensajes es el servicio de mensajes breves.
5.

Un procedimiento según la reivindicación 1, en el cual el identificador del servidor de sincronización está determinado en el campo que contiene un secreto compartido.
6.

Un procedimiento según la reivindicación 1, en el cual

el servidor de sincronización también está configurado para determinar una secuencia de bits en el mensaje, que indica si el cliente o el servidor ha causado el mensaje.
7.

Un procedimiento según la reivindicación 1, en el cual las instrucciones de codificación y las instrucciones de descodificación comprenden una o más tablas de correspondencia.
8.

Un procedimiento según la reivindicación 1, en el cual

la sesión es inicializada para sincronizar un conjunto de datos incluido en el dispositivo cliente y en al menos una base de datos.
9.

Un procedimiento según la reivindicación 1, en el cual

el servidor de sincronización transmite una solicitud para iniciar una sesión de gestión de dispositivos, y

la sesión de gestión se inicializa entre el servidor y el dispositivo cliente.
10. Un sistema de sincronización que comprende al menos un dispositivo electrónico que actúa como un dispositivo cliente y que comprende medios de comunicación, al menos un servidor de sincronización y una red de comunicación que proporciona un servicio de transmisión de mensajes, sistema de sincronización en el cual:

el servidor de sincronización está configurado para determinar (401), para una solicitud que indica la necesidad de iniciar una sesión, y a transmitir al dispositivo cliente, un identificador del servidor de sincronización, un identificador de versión y un identificador de la sesión solicitada,

el servidor de sincronización está configurado para determinar (402) el tamaño máximo para un mensaje que ha de enviarse desde el servidor de sincronización al dispositivo cliente para la solicitud,

se determinan (402) instrucciones de codificación, por las cuales al menos uno de los identificadores puede codificarse en una secuencia de bits que requiere significativamente menos bits que su presentación en ASCII, en el servidor de sincronización, y se determinan (402) instrucciones de descodificación, por medio de las cuales se obtiene el identificador original a partir de la secuencia de bits, en el dispositivo cliente,

en respuesta a la necesidad de transmitir la solicitud que indica la necesidad de iniciar una sesión a al menos un dispositivo cliente, el servidor de sincronización está configurado para formar (405) un mensaje, siendo este mensaje más corto que, o tan largo como, dicho tamaño máximo, y comprendiendo al menos dichos identificadores, al menos uno de los cuales se presenta como una secuencia de bits definida según las instrucciones de codificación,

el servidor de sincronización está configurado para transmitir (406) el mensaje al dispositivo cliente utilizando el servicio de transmisión de mensajes,

el dispositivo cliente está configurado para formar (408) un mensaje de inicialización de sesión en base a la información incluida en el mensaje recibido, estando al menos parte de la información definida a partir de la secuencia de bits recibida por medio de dichas instrucciones de descodificación, y

el dispositivo cliente está configurado para transmitir (409) el mensaje de inicialización de sesión al servidor de sincronización.
11. Un servidor de sincronización,

estando tal servidor de sincronización configurado para determinar (401), para una solicitud que indica la necesidad de iniciar una sesión, y a transmitir a al menos un dispositivo cliente, un identificador del servidor de sincronización, un identificador de versión y un identificador de la sesión solicitada,

el servidor de sincronización está configurado para determinar (402) el tamaño máximo para un mensaje que ha de enviarse desde el servidor de sincronización al dispositivo cliente para la solicitud,

servidor de sincronización en el cual se determinan (402) instrucciones de codificación, por las cuales al menos uno de los identificadores puede codificarse en una secuencia de bits que requiere significativamente menos bits que su presentación en ASCII,

servidor de sincronización que, en respuesta a la necesidad de transmitir la solicitud que indica la necesidad de iniciar una sesión a al menos un dispositivo cliente, está configurado para formar (405) un mensaje, siendo tal mensaje más corto que, o tan largo como, dicho tamaño máximo, y comprendiendo al menos dichos identificadores, al menos uno de los cuales se presenta como una secuencia de bits definida según las instrucciones de codificación, y

servidor de sincronización que está configurado para transmitir (406) el mensaje a al menos un dispositivo cliente utilizando el servicio de transmisión de mensajes.
12.

Un servidor de sincronización según la reivindicación 11, en el cual un servicio de capa de transporte está configurado usando un protocolo de aplicaciones inalámbricas, por lo cual el mensaje comprende adicionalmente campos de cabecera del protocolo de sesión inalámbrica.
13.

Un servidor de sincronización según la reivindicación 11, en el cual el mensaje también indica una aplicación a la cual debería dirigirse el contenido del mensaje, estando el servidor de sincronización configurado para definir la indicación fijando la información sobre la aplicación en una ubicación predeterminada, como a partir del comienzo del mensaje, o después de un carácter predeterminado.
14.

Un servidor de sincronización según cualquiera de las reivindicaciones 11 a 13, en el cual el servicio de transmisión de

mensajes es un servicio de mensajes breves.
15.

Un servidor de sincronización según la reivindicación 11, en donde el servidor de sincronización está configurado para determinar el identificador del servidor de sincronización en el campo que contiene un secreto compartido.
16.

Un servidor de sincronización según la reivindicación 11, en donde el servidor de sincronización también está configurado para determinar una secuencia de bits en el mensaje, que indica si el cliente o el servidor ha causado el mensaje.
17.

Un servidor de sincronización según la reivindicación 11, en el cual las instrucciones de codificación comprenden una

o más tablas de correspondencia.
18.

Un servidor de sincronización según la reivindicación 11, en donde el servidor de sincronización está configurado para inicializar la sesión a fin de sincronizar un conjunto de datos incluidos en el dispositivo cliente y al menos una base de datos.
19.

Un servidor de sincronización según la reivindicación 11, en donde el servidor de sincronización está configurado para transmitir una solicitud a fin de iniciar una sesión de gestión de dispositivos, y

el servidor de sincronización está configurado para inicializar la sesión de gestión entre el servidor y el dispositivo cliente.
20.

Un dispositivo electrónico que comprende

medios para recibir y transmitir mensajes,

medios para comunicarse con un servidor, servidor para el cual dicho dispositivo electrónico actúa como un dispositivo cliente,

medios para almacenar (402) instrucciones de descodificación, por medio de las cuales la información original es obtenible a partir de una secuencia de bits codificada por el servidor,

medios para convertir (407) al menos una secuencia de bits, incluida en un mensaje más corto que, o tan largo como, un tamaño máximo, y recibida desde el servidor, en la información original, en base a las instrucciones de descodificación, indicando la secuencia de bits recibida al menos uno de los siguientes identificadores: un identificador del servidor, un identificador de versión y un identificador de una sesión solicitada,

medios para formar (408) un mensaje de inicialización para una sesión entre el servidor y dicho dispositivo, en base a la información indicada por el mensaje recibido desde el servidor, estando al menos parte de la información definida a partir de la secuencia de bits recibida, por medio de dichas instrucciones de descodificación,

medios para enviar (409) el mensaje de inicialización para la sesión al servidor, y

medios para alterar la configuración de dicho dispositivo según comandos recibidos desde el servidor durante la sesión.
21.

Un dispositivo electrónico según la reivindicación 20, en el cual un servicio de capa de transporte está configurado usando un protocolo de aplicaciones inalámbricas, por lo cual el mensaje comprende adicionalmente campos de cabecera del protocolo de sesiones inalámbricas.
22.

Un dispositivo electrónico según la reivindicación 20, en el cual el mensaje también indica una aplicación a la cual debería dirigirse el contenido del mensaje, estando la indicación definida por información sobre la aplicación en una ubicación predeterminada, como desde el comienzo del mensaje, o después de un carácter predeterminado, y

el dispositivo electrónico está configurado para dirigir el contenido del mensaje a la aplicación indicada por el mensaje.
23.

Un dispositivo electrónico según la reivindicación 20, en donde el dispositivo electrónico está configurado para comunicarse con el servidor por el servicio de mensajes breves.
24.

Un dispositivo electrónico según la reivindicación 20, en donde el dispositivo electrónico está configurado para determinar el identificador del servidor a partir del campo que contiene un secreto compartido.
25.

Un dispositivo electrónico según la reivindicación 20, en el cual las instrucciones de descodificación comprenden una o más tablas de correspondencia.
26.

Un dispositivo electrónico según la reivindicación 20, en el cual el servidor es un servidor de gestión de dispositivos y la sesión es una sesión de gestión de dispositivos.
27.

Un dispositivo electrónico según la reivindicación 20, en el cual el servidor es un servidor de sincronización y la sesión

es una sesión de sincronización.
28.

Un programa de ordenador cargable en la memoria de un servidor de sincronización, comprendiendo dicho producto de programa un código de programa de ordenador que, cuando es ejecutado en el procesador del servidor de sincronización, causa que el servidor de sincronización:

determine (401), para una solicitud que indica la necesidad de iniciar una sesión, y a transmitir a al menos un dispositivo cliente, un identificador del servidor de sincronización, un identificador de una versión del protocolo de sincronización que disponga de soporte por parte del servidor de sincronización y un identificador de la sesión solicitada,

determine (402) el tamaño máximo para un mensaje que ha de enviarse desde el servidor de sincronización al dispositivo cliente para la solicitud,

establezca (402) instrucciones de codificación, por las cuales pueda codificar al menos uno de los identificadores en una secuencia de bits que requiera significativamente menos bits que su presentación en ASCII,

en respuesta a la necesidad de transmitir la solicitud que indica la necesidad de iniciar una sesión a al menos un dispositivo cliente, forme (405) un mensaje, siendo dicho mensaje más corto que, o tan largo como, dicho tamaño máximo, y comprendiendo al menos dichos identificadores, al menos uno de los cuales se presenta como una secuencia de bits definida según las instrucciones de codificación, y

transmita (406) el mensaje a al menos un dispositivo cliente utilizando el servicio de transmisión de mensajes.
29. Un programa de ordenador cargable en la memoria de un dispositivo electrónico, comprendiendo dicho programa de ordenador un código de programa que, al ser ejecutado en el procesador del dispositivo electrónico, causa que el dispositivo electrónico:

establezca (402) instrucciones de descodificación, por medio de las cuales sea obtenible la información original a partir de una secuencia de bits codificada por un servidor,

convierta (407) al menos una secuencia de bits incluida en un mensaje más corto que, o tan largo como, un tamaño máximo, y recibida desde el servidor, en la información original, en base a las instrucciones de descodificación, indicando la secuencia de bits recibida al menos uno de los siguientes identificadores: un identificador del servidor, un identificador de versión y un identificador de la sesión solicitada,

forme (408) un mensaje de inicialización para una sesión entre el servidor y dicho dispositivo, en base a la información indicada por el mensaje recibido desde el servidor, estando al menos parte de la información definida a partir de la secuencia de bits recibida, por medio de dichas instrucciones de descodificación,

transmita (409) el mensaje de inicialización para la sesión al servidor, y

altere la configuración del dispositivo según comandos recibidos desde el servidor durante la sesión.