Método, sistema, servidor y terminal de procesamiento de mensaje.

Un método para procesar un mensaje, aplicable a una sesión de Sincronización de Datos

, DS, que comprende: recibir, por un terminal, un mensaje de notificación de demanda de establecimiento de una sesión enviado por un servidor, en donde el mensaje de notificación incluye información de gestión de sesión relativa a la sesión; adquirir, por el terminal, la información de gestión de sesión relativa a la sesión en el mensaje de notificación y confirmar, por el terminal, el mensaje de notificación en función de la información de gestión de sesión, generar un mensaje de respuesta que incluya información de error del mensaje de notificación en función de un resultado de confirmación y enviar el mensaje de respuesta al servidor bajo la forma de un mensaje de sesión de DS, para dar instrucciones al servidor con el fin de modificar el mensaje de notificación en consecuencia de acuerdo con un tipo de error de la información de error y reenviar un mensaje de notificación modificado, en donde la información de gestión de sesión comprende información de identificador del servidor, información de autenticación e información de indicación de la sesión, en donde la información de indicación de la sesión comprende al menos una de: información de indicación de interfaz de usuario, información de objetivo, información de importancia, información de temporización, información de operación e información de política de respuesta de la sesión.

Tipo: Patente Europea. Resumen de patente/invención. Número de Solicitud: E13179032.

Solicitante: HUAWEI TECHNOLOGIES CO., LTD..

Inventor/es: TIAN,LINYI, LI,KEPENG, CHAI,XIAOQIAN, YE,FUJUN.

Fecha de Publicación: .

Clasificación Internacional de Patentes:

  • SECCION H — ELECTRICIDAD > TECNICA DE LAS COMUNICACIONES ELECTRICAS > TRANSMISION DE INFORMACION DIGITAL, p. ej. COMUNICACION... > Disposiciones, aparatos, circuitos o sistemas no... > H04L29/06 (caracterizadas por un protocolo)
  • SECCION H — ELECTRICIDAD > TECNICA DE LAS COMUNICACIONES ELECTRICAS > TRANSMISION DE INFORMACION DIGITAL, p. ej. COMUNICACION... > Disposiciones, aparatos, circuitos o sistemas no... > H04L29/08 (Procedimiento de control de la transmisión, p. ej. procedimiento de control del nivel del enlace)
  • SECCION H — ELECTRICIDAD > TECNICA DE LAS COMUNICACIONES ELECTRICAS > REDES DE COMUNICACION INALAMBRICAS > Servicios o recursos especialmente adaptados para... > H04W4/14 (Servicios de mensaje corto, p. ej. SMS o USSD [Servicio de Datos Suplementarios sin Estructurar (Unstructured Supplementary Service Data)])
  • SECCION H — ELECTRICIDAD > TECNICA DE LAS COMUNICACIONES ELECTRICAS > REDES DE COMUNICACION INALAMBRICAS > Gestión de datos de red > H04W8/24 (Transferencia de datos del terminal)
  • SECCION H — ELECTRICIDAD > TECNICA DE LAS COMUNICACIONES ELECTRICAS > REDES DE COMUNICACION INALAMBRICAS > H04W4/00 (Servicios o recursos especialmente adaptados para las redes de comunicación inalámbricas)
  • SECCION H — ELECTRICIDAD > TECNICA DE LAS COMUNICACIONES ELECTRICAS > REDES DE COMUNICACION INALAMBRICAS > Protocolos de red inalámbrica o adaptación del... > H04W80/10 (adaptado para la gestión de sesión, p. ej. SIP [Session Initiation Protocol])
  • SECCION H — ELECTRICIDAD > TECNICA DE LAS COMUNICACIONES ELECTRICAS > REDES DE COMUNICACION INALAMBRICAS > Protocolos de red inalámbrica o adaptación del... > H04W80/12 (Protocolos de capa de aplicación, p. ej. WAP)
google+ twitter facebookPin it
Ilustración 1 de Método, sistema, servidor y terminal de procesamiento de mensaje.
Ilustración 2 de Método, sistema, servidor y terminal de procesamiento de mensaje.
Ilustración 3 de Método, sistema, servidor y terminal de procesamiento de mensaje.
Ilustración 4 de Método, sistema, servidor y terminal de procesamiento de mensaje.
Ilustración 5 de Método, sistema, servidor y terminal de procesamiento de mensaje.
Método, sistema, servidor y terminal de procesamiento de mensaje.

Texto extraído del PDF original:

DESCRIPCIÓN

Método, sistema, servidor y terminal de procesamiento de mensaje

Campo de la tecnología

La presente invención se refiere a una tecnología de comunicación y más en particular, a un método, un sistema, un servidor y un terminal para procesamiento de mensaje.

Antecedentes de la invención

Una tecnología de Gestión de Dispositivo (DM) se refiere a que un servidor realiza operaciones de gestión, tales como configuración de parámetro, actualización de firmware, descarga de software, instalación y supresión, diagnosis de fallos y reparación y la supervisión del terminal, en un terminal en un modo de tecnología denominada ‘a través del aire’ (OTA). Una tecnología de Sincronización de Datos (DS) se refiere a que los datos se sincronizan entre un dispositivo móvil y un servidor de red y los datos sincronizados incluyen una agenda telefónica, una agenda de direcciones, una agenda-calendario, mensajes cortos, correos electrónicos, etc.

En la tecnología de DM o de tecnología de DS anteriores, se proporciona un mecanismo de notificación, mediante el que el servidor proporciona un mensaje de notificación al dispositivo de terminal y el dispositivo de terminal inicia una conexión de sesión con el servidor en función de un identificador (ID) de sesión, un ID de servidor y otra información en la notificación. El mensaje de notificación se entrega en un modo de mensaje corto o un modo de mensaje instantáneo, denominado pushing. La especificación de DM proporciona un mecanismo para el servidor de DM para gestionar el dispositivo de terminal y haciendo referencia a la Figura 1, el flujo de gestión de sesión incluye las etapas siguientes.

En la etapa 101, un servidor DS o DM proporciona un mensaje de notificación para demandar una conexión de sesión.

En la etapa 102, después de que un terminal reciba el mensaje de notificación, un usuario confirma directamente si conectar, o no, la sesión y si el resultado de la confirmación es conectar la sesión, el procedimiento prosigue con la etapa 103, de no ser así el terminal no realiza ningún procesamiento.

En la etapa 103, el terminal inicia la conexión de sesión y envía un paquete de inicialización al servidor para realizar el flujo de sesión.

En la etapa 104, después de recibir el paquete de inicialización para iniciar la conexión de sesión enviada por el terminal, el servidor envía el paquete de inicialización al terminal para realizar la operación de sesión.

En la etapa 105, el terminal y el servidor realizan el flujo de sesión subsiguiente.

Sobre la base de la técnica anterior antes citada, el inventor encuentra que pueden producirse algunos problemas durante el proceso operativo práctico en el proceso de la invención: después de recibir el mensaje de notificación desde el servidor, el terminal carece de un mecanismo de respuesta, de modo que el servidor no puede obtener la realimentación informativa del terminal y envía, de forma continua y repetida, el mensaje de notificación, lo que incrementa la carga de trabajo de procesamiento del servidor y aumenta el recurso de red ocupado.

El documento US 2007/0027971 A1 da a conocer una red de gestión de dispositivo con notificaciones que comprenden múltiples solicitudes de elección. Al cliente de la notificación, en un dispositivo móvil, se le envía un mensaje de notificación por un servidor de DM para indicar la necesidad de realizar una tarea de gestión de dispositivo en el dispositivo móvil. En respuesta a este mensaje, el cliente de notificación visualiza el mensaje recibido, que podría ser un mensaje de múltiple elección. La respuesta del usuario es también solicitada. Cuando responde el usuario, la respuesta del usuario se comunica de nuevo al servidor de DM o a otro servidor. La respuesta del usuario puede comunicarse a través de uno de los medios de comunicación disponibles, tal como SMS, una sesión de DM a través de un protocolo OMA DM, etc. En general, si se visualiza un mensaje de elección múltiple por el cliente de notificación, la selección del usuario se comunica al servidor de DM.

El documento WO 2005/004395 A1 da a conocer la forma de especificación de nodos de gestión en un sistema de gestión de dispositivo. Este documento se refiere a un método para especificar información en un nodo de gestión utilizado para la gestión de dispositivo en un sistema que comprende un primer dispositivo y un segundo dispositivo que gestiona el primer dispositivo. En conformidad con el método, al menos un elemento de información de nodo de gestión, especificado por un primer dispositivo, se transmite desde el primer dispositivo a un segundo dispositivo como una respuesta a al menos un elemento de información en un nodo de gestión utilizado para la gestión de dispositivo que se especifica en el primer dispositivo.

El documento US 2006/0133335 A1 da a conocer un método para establecer una sesión instantánea denominada push

en un sistema de comunicación. El método incluye la recepción de una invitación de sesión que tiene una descripción de un protocolo push a través de un protocolo de transporte para establecer una sesión push. El método incluye también el establecimiento de un soporte de transporte en conformidad con el protocolo de transporte. El método incluye, además, la utilización del soporte de transporte para una sesión push en conformidad con el protocolo push. Una pasarela push está configurada para recibir una presentación para iniciar una operación push hacia el dispositivo de comunicación y para transmitir, sobre la base de la presentación, la invitación de sesión que incluye la descripción del dispositivo de comunicación. Un dispositivo de comunicación está configurado para realizar el método.

El documento US 2003/0204640 A1 da a conocer un método y un dispositivo para la gestión de intercambio de datos en árbol operativo. Un árbol de gestión o nodos dispuestos de forma jerárquica en arborescencia, respectivamente, se utiliza para gestionar, contener y mapear información de un dispositivo gestionable en conformidad con la norma de protocolo DM SyncML. Un servidor de gestión puede demandar de dicho dispositivo, por medio de una orden GET, la información contenida en un determinado nodo del servidor del árbol de gestión. El dispositivo gestionable responde transmitiendo la información demandada del árbol de gestión. El concepto inventivo proporciona métodos que permiten una demanda de información no solamente desde un nodo único, sino desde una pluralidad de nodos al mismo tiempo.

Sumario de la invención

En consecuencia, en las formas de realización de la presente invención, mediante la expansión de un mensaje de notificación de DS, se puede transmitir más información de gestión de sesión en el mensaje de notificación de DS, un terminal de DS analiza y determina el mensaje de notificación y envía un mensaje de respuesta a un servidor de DS en función de un resultado de análisis y determinación, de modo que el servidor de DS realice, además, el procesamiento en función de la información reenviada desde el terminal de DS.

Las formas de realización de la presente invención dan a conocer un método que incluye las etapas siguientes.

Un mensaje de notificación para demandar el establecimiento de una sesión, enviado por un servidor, es recibido por un terminal y el mensaje de notificación transmite información de gestión de sesión relativa a la sesión.

La información de gestión de sesión relativa a la sesión, en el mensaje de notificación, se adquiere por el terminal y el mensaje de notificación es confirmado por el terminal en función de la información de gestión de sesión, se genera un mensaje de respuesta que transmite información de error del mensaje de notificación en función de un resultado de confirmación, y enviándose al servidor el mensaje de respuesta en la forma de mensaje de sesión de DS. El mensaje de notificación, en correspondencia, en función de un tipo de error de la información de error se modifica y se reenvía un mensaje de notificación modificado por el servidor. La información de gestión de sesión comprende información del identificador del servidor, información de autenticación e información de indicación de la sesión, en donde la información de indicación de la sesión comprende al menos una de entre: información de indicación de interfaz de usuario, información de objetivo, información de importancia, información de temporización, información de operación e información de política de respuesta de la sesión.

Las formas de realización de la presente invención dan a conocer, además, un terminal de DS que incluye: un módulo de recepción de mensaje de notificación, adaptado para recibir un mensaje de notificación enviado por un servidor, en donde el mensaje de notificación transmite información de gestión de sesión; un módulo de determinación de sesión, adaptado para adquirir la información de gestión de sesión y para confirmar el mensaje de notificación en función de la información de gestión de sesión y la información de gestión de sesión comprende información del identificador del servidor, información de autenticación e información de indicación de la sesión, en donde la información de indicación de la sesión comprende al menos una de entre: información de indicación de interfaz de usuario, información de objetivo, información de importancia, información de temporización, información de operación e información de política de respuesta de la sesión; un módulo de generación de mensaje de respuesta, adaptado para generar un mensaje de respuesta en función de un resultado de confirmación del módulo de determinación de sesión que transmite información de error del mensaje de notificación; y un módulo de transcepción de mensajes, adaptado para enviar el mensaje de respuesta generado por el módulo de generación de mensaje de respuesta al servidor, en la forma de mensaje de sesión de DS, para dar instrucciones al servidor con el fin de modificar el mensaje de notificación en consecuencia en función de un tipo de error de la información de error, y reenviar un mensaje de notificación modificado.

Las formas de realización de la presente invención dan a conocer, además, un servidor de DS, que incluye: un módulo de iniciación de mensaje de notificación de sesión, adaptado para enviar un mensaje de notificación para demandar el establecimiento de una sesión para un terminal de DS, en donde el mensaje de notificación transmite información de gestión de sesión relativa a la sesión y la información de gestión de sesión comprende información del identificador del servidor, información de autenticación e información de indicación de la sesión, en donde la información de indicación de la sesión comprende al menos una de entre: información de indicación de interfaz de usuario, información de objetivo, información de importancia, información de temporización, información de operación e información de política de respuesta de la sesión; un módulo de recepción de mensaje de respuesta, adaptado para recibir un mensaje de respuesta reenviado desde el terminal de DS; y un módulo de procesamiento, adaptado para realizar un procesamiento correspondiente en función del contenido transmitido en un mensaje de respuesta, en donde el mensaje de respuesta, recibido por el módulo de recepción de mensaje de respuesta, transmite información de error del mensaje de notificación en la forma de un mensaje de sesión de DS, y la información de error del mensaje de notificación comprende una de la información que indica que el identificador del servidor es incorrecto; el formato del mensaje de notificación es incorrecto; existe un fallo en la autenticación Digest; y la información de versión es incorrecta; y la información de versión es incorrecta; y el módulo de procesamiento está adaptado, además, para modificar, en correspondencia, el mensaje de notificación en función de un tipo de error en la información de error del mensaje de notificación y para reenviar el mensaje de notificación modificado.

Puede deducirse de las soluciones técnicas antes citadas que en el método, después de recibirse el mensaje de notificación para demandar la conexión de sesión proporcionada por el servidor de DS o de DM, en función de los resultados del análisis, la determinación y la autenticación de la forma y el contenido del mensaje, el mensaje de respuesta se envía al servidor de DS o de DM, de modo que el servidor pueda determinar los problemas de la notificación enviada en función de la información reenvía desde el terminal de DS o de DM, con el fin de realizar el procesamiento adicional. Por lo tanto, al servidor de DS o de DM puede impedirse el envío ‘a ciegas’ y de forma repetida del mensaje de notificación cuando no se informa de que se establece una conexión de sesión por el terminal de DS o de DM. Además, el terminal conoce la importancia y la finalidad de la sesión por anticipado, con el fin de decidir si realizar, o no, la sesión y para notificar al servidor por intermedio del mensaje de respuesta cuando se rechaza la sesión, impidiendo así que el servidor envíe repetidamente el mensaje de notificación.

Breve descripción de los dibujos

La Figura 1 es un diagrama de flujo de gestión de sesión en la técnica anterior, en donde un terminal de DS o de DM recibe un mensaje de notificación enviado por un servidor de notificación y procesa el mensaje de notificación; La Figura 2 es una vista estructural esquemática de un sistema para procesar un mensaje proporcionado en una forma de realización de la presente invención; La Figura 3 es un diagrama de flujo de un método para procesar un mensaje realizado sobre la base del sistema de la Figura 2, dado a conocer en una forma de realización de la presente invención; La Figura 4 es un diagrama de flujo de señalización de envío de un mensaje de respuesta al servidor de notificación por un cliente de notificación en el terminal de DS o de DM, dado a conocer en una forma de realización de la presente invención; La Figura 5 es un diagrama de flujo de señalización de envío del mensaje de respuesta al servidor de DS o de DM por un cliente de DS o de DM en el terminal de DS o de DM dado a conocer en una forma de realización de la presente invención y La Figura 6 es un diagrama de flujo de señalización de envío del mensaje de respuesta al servidor de DS o de DM por intermedio de un mensaje de tipo Push de protocolo de iniciación de sesión (SIP) dado a conocer en una forma de realización de la presente invención.

Descripción detallada de la invención

Formas de realización de la presente invención dan a conocer un método para procesar un mensaje, que es aplicable a una sesión de DS o de DM. En el método, después de que se reciba un mensaje de notificación para la demanda de una conexión de sesión, que se entrega por un servidor de DS o de DM, en función de los resultados del análisis, la determinación y la autenticación de una forma y contenido del mensaje, se envía un mensaje de respuesta al servidor de DS o de DM, de modo que el servidor pueda determinar los problemas de la notificación enviada en función de la información reenviada desde el terminal de DS o de DM, para realizar el procesamiento adicional, con lo que se impide que el servidor de DS o de DM envíe, a ciegas y de forma repetida, el mensaje de notificación cuando no se informa de que se establece una conexión de sesión por el terminal de DS o de DM. Además, el terminal conoce la importancia y la finalidad de la sesión por anticipado, con el fin de decidir si realizar, o no, la sesión, y notificar al servidor, por intermedio del mensaje de respuesta, cuando se rechaza la sesión, con lo que se impide que el servidor envíe repetidamente el mensaje de notificación.

Con el fin de realizar el método, las formas de realización de la presente invención dan a conocer un sistema para procesar un mensaje. Según se ilustra en la Figura 2, se representa una vista estructural esquemática del sistema según la presente invención, que incluye un terminal 100 y un lado del servidor. El terminal incluye, principalmente un cliente de DS o de DM 101 (que puede ser un cliente de DM, un cliente de DS o puede incluir los clientes de DM y de DS y la descripción es la misma en adelante) y un cliente de notificación 102. El lado del servidor incluye principalmente un servidor de DS o de DM 200 y un servidor de notificación 300.

En las formas de realización de la presente invención, el cliente de DS o de DM 101 interacciona con el servidor de DS o de DM 200 mediante un protocolo DS o DM y el cliente de DS o de DM 101 incluye un módulo de transcepción de mensaje 1011, un módulo de determinación de sesión 1012 y un módulo de generación de mensaje de respuesta 1013.

El módulo de transcepción de mensaje 1011 está adaptado para recibir un mensaje de sesión de DS o de DM enviado por el servidor de DS o de DM y para enviar el mensaje de sesión de DS o de DM generado por el módulo de generación de mensaje de respuesta 1013 al servidor de DS o de DM 200.

El módulo de determinación de sesión 1012 está adaptado para extraer información de gestión de sesión transmitida en el mensaje de notificación, tal como información de versión de mensaje, información de ID de un emisor de mensaje, información de objetivo de la sesión e información de indicación de la sesión, en donde la información de indicación de la sesión incluye, sin limitación, la información del objetivo, la información de la importancia, la información de temporización, la información de operación, la política de respuesta de la sesión e informaciones similares. El módulo de determinación de la sesión 1012 está adaptado, además, para procesar la información extraída, a modo de ejemplo, para determinar si la sesión es importante o no lo es y si la información de versión del mensaje es correcta, o no, en función del objetivo de la sesión, realizar una autenticación denominada Digest en función de la información del ID del remitente y otros procesos del procesamiento y se adapta para determinar la respuesta del mensaje en función de un resultado de procesamiento.

El módulo de determinación de sesión 1012 está adaptado, además, para adquirir información de forma del mensaje, a modo de ejemplo, un formato de mensaje, para analizar el formato de mensaje y para determinar la respuesta del mensaje en función de un resultado del análisis.

El módulo de determinación de sesión 1012 está adaptado, además, para determinar la forma y el contenido del mensaje de respuesta en función de la información de forma del soporte del mensaje de notificación enviado por el lado del servidor y la información adquirida a partir del mensaje de notificación.

El módulo de generación de mensaje de respuesta 1013 está adaptado para generar el mensaje de respuesta en función de una indicación del módulo de determinación de sesión 1012. Conviene señalar que si el mensaje de respuesta está basado en la sesión de DS o de DM, el módulo de generación de mensaje de respuesta 1013 está adaptado para generar el mensaje de sesión de DS o de DM y para enviar el mensaje de sesión de DS o de DM al servidor de DS o de DM 200 por intermedio del módulo de transcepción de mensajes 1011; si el mensaje de respuesta está basado en la no sesión, dicho de otro modo, el mensaje de respuesta se genera sobre la base de la forma del soporte del mensaje de notificación enviado por el servidor de notificación, tal como un mensaje SIP, un servicio de mensajes cortos (SMS), un protocolo push de aplicación inalámbrica (WAP) y un push SIP, estando el módulo de generación de mensaje de respuesta 1013 adaptado para generar el mensaje de respuesta con el formato correspondiente en conformidad con el formato correspondiente del mensaje de respuesta (a modo de ejemplo, el formato del mensaje de respuesta descrito en las formas de realización de la presente invención como sigue) y en función de la forma de soporte del mensaje de notificación enviado por el servidor de notificación del lado del servidor y para enviar el mensaje de respuesta con el formato correspondiente al servidor de notificación 300 por intermedio de un módulo de envío de mensaje de respuesta 1022 descrito a continuación.

En otras ocasiones, el cliente de DS o de DM 101 puede incluir, además, un módulo de establecimiento de política 1014, que está adaptado para memorizar la política de determinación de si responder, o no, al mensaje y el contenido detallado de la política puede obtenerse con referencia a la introducción detallada relativa a la política de las formas de realización del método como sigue.

El módulo de determinación de sesión 1012 está adaptado, además, para determinar si responder, o no, al mensaje para el lado del servidor, en conformidad con la política establecida en el módulo de establecimiento de política 1014.

En las formas de realización de la presente invención, el terminal 100 incluye, además, un cliente de notificación 102, que incluye un módulo de recepción de mensaje de notificación 1021 y un módulo de envío de mensaje de respuesta 1022. El módulo de recepción de mensaje de notificación 1021 está adaptado para recibir el mensaje de notificación enviado por el servidor de notificación. El módulo de envío de mensaje de respuesta 1022 está adaptado para enviar el mensaje de respuesta generado por el módulo de generación de mensaje de respuesta 1012 al servidor de notificación. El mensaje de notificación incluye, sin limitación, el mensaje corto, el mensaje push de OTA y el mensaje push de SIP, etc.

En las formas de realización del sistema de la presente invención, el lado del servidor incluye un servidor de DS o de DM 200 y un servidor de notificación 300. Conviene señalar que la diferenciación es la diferenciación lógica y durante la aplicación práctica, los dos servidores pueden integrarse en un servidor de DS o de DM.

El servidor de DS o de DM 200 puede incluir un módulo de iniciación de mensaje de notificación de sesión 201, un módulo de recepción de mensaje de respuesta 202 y un módulo de procesamiento 203. El módulo de iniciación de mensaje de notificación de sesión 201 está adaptado para demandar al módulo de envío de mensaje notificación 301, en el servidor de notificación 300, para que envíe el mensaje de notificación de sesión al terminal de DS o de DM 100.

El módulo de recepción de mensaje de respuesta 202 está adaptado para recibir el mensaje de respuesta resuelto sobre la base de la no sesión reenviada desde el cliente de notificación 102 y enviado por el módulo de resolución de mensaje de respuesta 303 en el servidor de notificación 300 o para recibir el mensaje de respuesta basado en la sesión que se reenvía desde el cliente de DS o de DM 101. El módulo de procesamiento 203 está adaptado para realizar el procesamiento adicional en función del contenido transmitido en el mensaje de respuesta recibido. A modo de ejemplo, cuando el contenido soportado en el mensaje de respuesta incluye una de la información siguiente que indica que existe un fallo de la autenticación Digest, el ID del servidor es incorrecto, el formato del mensaje es incorrecto y la información de versión es incorrecta, corrigiendo el módulo de procesamiento 203 el error correspondiente. Cuando el contenido soportado en el mensaje de respuesta incluye una de la información que indica que se rechaza la sesión y se recibe satisfactoriamente el mensaje de notificación, el módulo de procesamiento 203 no envía el mensaje de notificación.

Conviene señalar que el módulo de resolución de mensaje de respuesta 303, en el servidor de notificación 300, puede establecerse en el servidor de DS o de DM 200, de modo que el servidor de DS o de DM 200 resuelva el mensaje de respuesta correspondiente.

El servidor de notificación 300 puede incluir un módulo de envío de mensaje de notificación 301, un módulo de recepción de mensaje de respuesta 302 y un módulo de resolución de mensaje de respuesta 303. El módulo de envío de mensaje de notificación 301 está adaptado para enviar el mensaje de notificación al cliente de notificación 102, el módulo de recepción de mensaje de respuesta 302 está adaptado para recibir el mensaje de respuesta reenviado desde el cliente de notificación 102 y para enviar el mensaje de respuesta al módulo de resolución de mensaje de respuesta 303 y el módulo de resolución de mensaje de respuesta 303 está adaptado para resolver el mensaje de notificación recibido por el módulo de recepción de mensaje de respuesta 302 desde el cliente de notificación 102 y para enviar un resultado de resolución al servidor de DS o de DM.

Sobre la base del sistema anteriormente citado, las formas de realización de la presente invención dan a conocer, además, un método para procesar el mensaje, que es aplicable a la sesión de DS o de DM. Según se ilustra en la Figura 3, se representa un diagrama de flujo de la forma de realización del método, que incluye las etapas siguientes.

En la etapa 301, se recibe el mensaje de notificación.

El terminal de DS o de DM recibe el mensaje de notificación de la sesión de DS o de DM enviado por el servidor de notificación en función de la demanda del servidor de DS o de DM. El mensaje de notificación transmite información de gestión de sesión; a modo de ejemplo, la información de gestión de sesión incluye, sin limitación, información del ID del dispositivo de demanda de sesión, información de autenticación e información de indicación de la sesión. La información de indicación incluye, sin limitación, información del objetivo, información de la importancia, información de temporización, información de operación e información de la política de respuesta de la sesión. En las formas de realización de la presente invención, mediante la expansión del mensaje de notificación de DS o de DM, la información de gestión de sesión se incluye, de este modo, en el mensaje de notificación y los formatos de la parte de cuerpo del mensaje de la notificación de DS o de DM son diferentes, por lo que se proporciona una introducción respectivamente como sigue.

El método para la expansión del mensaje de notificación de DS se describe a continuación y el formato de la notificación de DS ampliada se representa en la Tabla 1 como sigue.

notificación-cabecera

notificación-cuerpo

versión

iniciador

Identificador- Identificador-

específico-

longitud

servidor

proveedor

específico-

proveedor

Servidor-

URI

Tabla 1

La descripción de los campos expandidos se proporciona como sigue.

<response-mode>::=<not-specified> / <response> /; el campo representa el “modo de respuesta” <no-response> / <user-decide>; <not-specified>::= “00”; el campo representa “no especificado”, <response> ::= “01”; el campo representa “respuesta”, <no-response>::= “10”; el campo representa “sin respuesta”, <user-decide>::= “11”; el campo representa “el usuario decide” <importance>::= <not-specified> / <low> / <normal> / <high>; el campo representa la “importancia”, <not-specified> ::= “00”; el campo representa “no especificado”, <low> ::= “01”; el campo representa “bajo” <normal>::= “10”; el campo representa “normal”, <high> ::= “11”; el campo representa “alto”, <time-out>::= 5*BIT; el campo representa “periodo de temporización en una unidad de día” <future-use>::= 18*BIT; el campo representa “reservado para extensión” <length-info>::= 8*BIT; el campo representa “longitud de la información de sesión” <info>::= <length-info> *CHAR; el campo representa “información de sesión”, <Op-Code>::= 3*BIT; el campo representa “código de operación”.

Según <response-mode>, el servidor indica al terminal si el mensaje de respuesta requiere enviarse, o no. Si es “respuesta” del modo de respuesta, representa que el terminal requiere reenviar si el mensaje de notificación se recibe satisfactoriamente o no. Si el modo de respuesta es “no especificado”, el terminal puede decidir si enviar, o no, el mensaje de respuesta en conformidad con la política. Si el modo de respuesta es “sin respuesta”, el terminal requiere no enviar el mensaje de respuesta al servidor. Si el modo de respuesta es “el usuario decide”, el terminal solicita al usuario y el usuario decide si responder, o no, con un mensaje de respuesta.

Durante la aplicación práctica, si una capa de transporte del mensaje de notificación soporta la respuesta automática a la información de éxito o fallo operativo, el servidor estable el modo de respuesta para ser “sin respuesta” o “no especificado”. Si la capa de transporte del mensaje de notificación no soporta la respuesta automática al mensaje de respuesta, el servidor establece el modo de respuesta para ser “respuesta” y una capa de aplicación responde con el mensaje de respuesta. La combinación detallada puede determinarse en función de las situaciones y la presente invención no está limitada a dichas maneras operativas.

<importance> está adaptado para mostrar la importancia de la sesión y el terminal decide si la conexión de sesión con el servidor requiere, o no, establecerse en función de la importancia de la sesión. Conviene señalar que la importancia se determina por el servidor y solamente se adapta para la referencia del terminal. El motivo es que la sesión importante para el servidor puede no ser importante para el terminal. El terminal puede determinar si la sesión es importante en función de su estado objetivo tal como cuando el terminal está ocupado o bien, la sesión no es importante para el terminal.

<time-out> está adaptado para designar el periodo de temporización del mensaje de notificación. El mensaje de notificación incluye la información del ID de sesión y el terminal inicia la conexión de sesión con el servidor en función de la información del ID de sesión. El servidor requiere guardar la información, con el fin de cerciorarse de que el servidor conoce la conexión de sesión del terminal. Si en el periodo de temporización de designación, el terminal no inicia la conexión de sesión con el servidor, el servidor no memoriza la información pertinente de la notificación, con el fin de economizar el recurso. El periodo de temporización está en una unidad de día y si es 0, ello indica que no existe ningún límite de tiempo.

<length-info> está adaptado para designar la longitud de <info> utilizando el byte como la unidad. Si es 0, ello indica que la longitud de <info> es 0, es decir, no existe el campo.

<info> está adaptado para mostrar el objetivo de la notificación, a modo de ejemplo, “¿desea actualizar el firmware?”. El terminal de usuario determina si iniciar, o no, la conexión de sesión con el servidor en función de la información que se ha proporcionado.

<Op-Code> es un código de operación indicado por el servidor al terminal. A modo de ejemplo, el servidor demanda al terminal la iniciación de una sesión vacía o demanda al terminal que comunique la información del dispositivo. Si se acepta la sesión, el terminal inicia la sesión correspondiente en función de la indicación de <Op-Code>.

Los valores de <Op-Code> son según se ilustra en la Tabla 2 como sigue.

Valor Significado 000 Al terminal se le demanda iniciar una sesión vacía 001 Al terminal se le demanda comunicar la información de dispositivo completa 010 Al terminal se le demanda comunicar la información de dispositivo actualizada 011 Al terminal se le demanda comunicar la información del dispositivo 100-111 Reservado para extensión

Tabla 2

Cuando el valor es 000, el servidor demanda al cliente que inicie una sesión vacía. Una vez establecida la sesión, el servidor puede adquirir la información de dispositivo del terminal utilizando una orden <Get> o iniciando una operación de sincronización.

Cuando el valor es 001, el servidor demanda al cliente que comunique la información del dispositivo completa. Durante la primera sincronización, el cliente requiere la comunicación de la información del dispositivo completa al servidor. En la sincronización subsiguiente, el cliente solamente requiere la comunicación de la información del dispositivo actualizada para ahorrar el tráfico.

Cuando el valor es 010, el servidor demanda al cliente la comunicación de la información del dispositivo actualizada. El cliente puede comunicar la información del dispositivo actualizada al servidor utilizando una orden <Put> y el cliente debe memorizar un registro de actualización de la información del dispositivo.

Cuando el valor es 011, el servidor demanda al cliente no comunicar la información del dispositivo. Si el servidor no está interesado en la información del dispositivo del cliente, o el servidor considera que la información del dispositivo del cliente es inútil, el servidor puede demandar al cliente no comunicar la información del dispositivo, con el fin de ahorrar el tráfico.

A continuación, el método para la expansión del mensaje de notificación de DM se describe como sigue y el formato de la notificación de DM expandida se representa en la Tabla 3 siguiente.

Tabla 3

La descripción de los campos expandidos se proporciona a continuación.

<num-MOs>::= 4*BIT; el campo representa “el número de MOs”, <future-use>::= 4*BIT; el campo representa “reservado para extensión”, <MOI>::= <MOI-length> <MOI>; el campo representa “información del primer MOI”, <MOI-length>::= 8*BIT; el campo representa “longitud de MOI”, <MOI>::= <MOI-length> *CHAR; el campo representa “información de ID de MO”, <num-MOs> está adaptado para indicar cuántos MOs están implicados en esta sesión, el siguiente MOI-MON está adaptado para mostrar la información del MO en detalle.

<MOI-length> está adaptado para mostrar la longitud del MOI.

<MOI> está adaptado para mostrar la información de ID del MO.

El terminal puede establecer una política determinada y determinar automáticamente si iniciar, o no, la conexión de sesión con el servidor en función de <MOI>, <Importance> u otra información. A modo de ejemplo, si el nivel de importancia es alto, el terminal permite automáticamente la sesión. Si el nivel de importancia es bajo, el terminal rechaza automáticamente la sesión. A modo de ejemplo, si el MOI es “urn:oma:mo:fumo:1.0”, el terminal permite también automáticamente la sesión.

En la etapa 302, se extrae el contenido en el mensaje de notificación.

El terminal de DS o de DM extrae el contenido transmitido en el mensaje de notificación. Conviene señalar que un mensaje de notificación puede soportar una parte del contenido, a modo de ejemplo, la información de indicación de la sesión, incluyendo el valor de la importancia de la sesión y/o la información del objetivo, la información de operación, la información de temporización (periodo de tiempo de la respuesta) de la sesión y la política de respuesta del terminal de DS o de DM proporcionada por el servidor de DS o de DM, etc. Sin embargo, no se requiere que toda la información se transmita en un solo mensaje de notificación. Más concretamente, toda la información puede transmitirse al mismo tiempo.

En la etapa 303, el terminal de DS o de DM confirma la forma y el contenido del mensaje de notificación.

El terminal de DS o de DM confirma la forma y el contenido del mensaje de notificación que incluye, sin limitación, al procesamiento como sigue. El terminal de DS o de DM determina si el formato del mensaje de notificación es correcto, o no, determina si la versión del mensaje coincide o no, determina si el ID del servidor es incorrecto o si el ID del servidor existe. Realiza la autenticación de si el Digest se transmite en función de la información de autenticación y determina la importancia de la sesión en función del valor de importancia adquirido de la sesión o determina la importancia de la sesión en función del objetivo adquirido de la sesión y el estado actual del terminal, tal como si el terminal está ocupado, o no, o si se realiza o no, la misma sesión o visualiza la información de objetivo adquirida de la sesión al usuario y determina la importancia de la sesión en función de si el usuario rechaza la sesión o recibe la sesión. El terminal de DS o de DM determina también si adoptar la política de respuesta del terminal de DS o de DM que se proporciona por el servidor de DS o de DM al terminal de DS o DM.

En la etapa 304, se determina cómo responder en función de la política. Si se inicia la sesión de DS o de DM, el terminal inicia la sesión de DS o de DM o no realiza ningún procesamiento; de no ser así, el procesamiento prosigue con la etapa 306.

La política puede ser la política de respuesta memorizada por el terminal de DS o de DM por anticipado y puede ser también la política de respuesta entregada por el servidor de DS o de DM al terminal de DS o de DM. La política del terminal de DS o de DM incluye, sin limitación, varias situaciones como sigue. 1. Cuando el mensaje de notificación se recibe satisfactoriamente, dicho de otro modo, indica que la versión del mensaje de notificación es correcta, el formato es correcto, el ID del servidor es correcto y la validación de Digest se consigue y cuando la sesión se considera que es relativamente importante y puede ser recibida en función de la información de indicación en la información de gestión de sesión y/o el estado actual del terminal, el mensaje requiere que se responda. 2. Cuando el mensaje de notificación se recibe satisfactoriamente, dicho de otro modo, indica que la versión del mensaje de notificación es correcta, el formato es correcto, el ID del servidor de DS o de DM es correcto y se supera la validación de Digest y cuando se considera que la sesión es relativamente importante, el mensaje requiere que no se responda. 3. Cuando el mensaje de notificación se recibe satisfactoriamente, dicho de otro modo, indica que la versión del mensaje de notificación es correcta, el formato es correcto, el ID del servidor es correcto y se supera la validación de Digest, pero cuando la sesión se considera que no es importante en función de la información de indicación en la información de gestión de sesión y/o el estado actual del terminal y se rechaza la sesión, el mensaje requiere que no se responda. 4. Cuando el mensaje recibido tiene una de las situaciones en que la versión del mensaje de notificación es incorrecta, el formato es incorrecto, el ID del servidor de DS o de DM es incorrecto y no se supera la validación de Digest, pero cuando la sesión se considera que es relativamente importante y puede recibirse en función de la información de indicación en la información de gestión de sesión y/o el estado actual del terminal, el mensaje requiere que se responda. 5. Cuando el mensaje recibido tiene una de las situaciones en que la versión es incorrecta, el formato es incorrecto, el ID del servidor de DS o de DM es incorrecta y no se supera la validación de Digest, pero cuando la sesión se considera que no es importante en función de la información de indicación en la información de gestión de sesión y/o el estado actual del terminal y se rechaza la sesión, el mensaje requiere que se responda. Durante la aplicación práctica, el terminal de DS o de DM solicita al usuario y el usuario decide responder o no hacerlo. Si, en la etapa 303, el terminal determina adoptar la política de respuesta del terminal de DS o de DM que se proporciona por el servidor de DS o de DM al terminal de DS o de DM, el terminal realiza la respuesta correspondiente adoptando la política de respuesta proporcionada por el servidor. Durante la aplicación práctica, se produce un fallo operativo directo y el mensaje requiere su respuesta, por lo que se puede omitir la etapa.

En la etapa 305, se determina la forma y contenido del mensaje de respuesta y se genera el mensaje de respuesta.

Cuando se determina que el mensaje requiere su respuesta según la etapa 304, en función de los diferentes resultados de análisis y de autenticación en el mensaje en la etapa 303 y las diferentes formas de soporte del mensaje de notificación, la forma y el contenido del mensaje de respuesta se determinan en conformidad con la regla descrita como sigue.

Diferentes formas y contenidos del mensaje de respuesta se determinan, respectivamente, en función de las cuatro situaciones que requieren la respuesta.

En la primera situación (la situación 1 antes citada) si el cliente de notificación en el terminal de DS o de DM puede responder al mensaje en conformidad con la forma de soporte del mensaje de notificación, el cliente de notificación responde con el mensaje al servidor de notificación, con el contenido de que el mensaje de notificación del lado del servidor se recibe de forma satisfactoria. El contenido de los mensajes de respuesta se representan por el código de estado transmitido en el mensaje de respuesta y los detalles pueden obtenerse con referencia a la forma de realización del método como sigue. De no ser así, el cliente de notificación en el terminal de DS o de DM no puede responder al mensaje en función de la forma de soporte del mensaje de notificación o aunque el cliente de notificación pueda responder al mensaje en conformidad con la forma de soporte del mensaje de notificación, el ID para el mensaje de respuesta del servidor de notificación no existe, por lo que no se puede dar respuesta al mensaje. En este caso, el cliente de DS o de DM, en el terminal de DS o de DM, responde con el mensaje, con el contenido en el que se recibe satisfactoriamente el mensaje de notificación del lado del servidor. A modo de ejemplo, el cliente de notificación recibe el mensaje de notificación enviado por el servidor de notificación en la manera de SMS, pero no existe ningún número de respuesta del servidor de notificación, por lo que no se puede responder al mensaje. En el mecanismo de respuesta, el mensaje de notificación se responde convenientemente sin iniciar la sesión de DS o de DM para responder al mensaje.

Más concretamente, puede considerarse que sin importar si el cliente de notificación puede responder, o no, al mensaje, se determina directamente que el cliente de DS o de DM responda con el mensaje.

En la segunda situación (la situación 3 antes citada), similar a la primera situación, si el cliente de notificación en el terminal de DS o de DM puede responder al mensaje, el cliente de notificación responde con el mensaje. De no ser así, el cliente de DS o de DM en el terminal de DS o de DM responde con el mensaje, con el contenido de que se rechaza la sesión. De modo similar, es posible determinar directamente que el cliente de DS o de DM responde con el mensaje con el contenido de que se rechaza la sesión, sin considerar si el cliente de notificación puede responder, o no, con el mensaje.

En la tercera situación (la situación 4 antes citada), cuando el mensaje recibido tiene una de las dos situaciones de que el ID del servidor de DS o de DM es incorrecto y no se supera la validación Digest, el cliente de DS o de DM no puede responder al mensaje puesto que el ID del servidor de DS o de DM es incorrecto o no se supera la validación Digest y el cliente de notificación responde con el mensaje, con el contenido de que el ID del servidor de DS o de DM es incorrecto o no se supera la validación Digest. Cuando el mensaje recibido tiene la situación de que la versión es incorrecta o el formato es incorrecto, de forma similar a la segunda situación, el cliente de notificación del cliente de DS o de DM se selecciona para responder al mensaje, con el contenido de que el mensaje de notificación es incorrecto, más concretamente, el tipo de error es que la versión del mensaje es incorrecta o el formato del mensaje es incorrecto.

En la cuarta situación (la situación 5 antes citada), cuando el mensaje recibido tiene una de las dos situaciones en que el ID del servidor de DS o de DM es incorrecto y no se supera la validación Digest, el cliente de DS o de DM no puede responder al mensaje puesto que el ID del servidor de DS o de DM es incorrecto o no se supera la validación Digest y el cliente de notificación responde con el mensaje, con el contenido de que se rechaza la sesión. Cuando la versión del mensaje recibido es incorrecta o el formato es incorrecto, de forma similar a la segunda notificación, el cliente de notificación o el cliente de DS o de DM se selecciona para responder al mensaje, con el contenido de que se rechaza la sesión. El mensaje de respuesta se genera en función del contenido y de la forma del mensaje de respuesta.

En la etapa 306, el terminal de DS o de DM responde con el mensaje.

Cuando el cliente de notificación en el terminal de DS o de DM, responde con el mensaje, el cliente de notificación empaqueta el mensaje de respuesta para un formato especificado capaz de entenderse por el servidor y envía el mensaje empaquetado al servidor de notificación. El formato detallado puede obtenerse con referencia a la descripción detallada de las etapas pertinentes de la forma de realización del método según la presente invención.

Cuando el cliente de DS o de DM en el terminal de DS o de DM, responde con el mensaje, el cliente de DS o de DM transmite el contenido correspondiente en el mensaje de sesión enviado al servidor de DS o de DM como la respuesta del mensaje de notificación de sesión del servidor y puede obtenerse el método de soporte detallado con referencia a la descripción detallada de las etapas pertinentes de las formas de realización del método según la presente invención.

La iniciación de la sesión de DS o de DM puede utilizarse como una del mensaje de respuesta.

Dos formas de realización se proporcionan como sigue, en una primera forma de realización, el proceso de respuesta se describe con el mensaje a través del cliente de notificación y en una segunda forma de realización, el proceso de respuesta al mensaje a través del cliente de DS o de DM es objeto de descripción.

Haciendo referencia a la Figura 4, un diagrama de flujo de señalización de la primera forma de realización del método según la presente invención se ilustra con la inclusión de las etapas siguientes.

En la etapa 401, el servidor de DS o de DM proporciona la información pertinente de gestión de sesión y demanda al servidor de notificación para proporcionar el mensaje de notificación al terminal de DS o de DM. El servidor de notificación puede ponerse en práctica como un servidor de mensajes cortos, un servidor de tipo OTA PUSH o un servidor SIP PUSH, etc.

El contenido de información de gestión pertinente se describió anteriormente, por lo que aquí no se repite.

En la etapa 402, el servidor de notificación proporciona el mensaje de notificación al terminal de DS o de DM y demanda la conexión de sesión. El mensaje de notificación incluye la finalidad de gestión de sesión, la importancia y otra información y el modo de entrada puede ser en la forma de un mensaje corto y la OTA PUSH, etc.

En la etapa 403, el cliente de notificación, en el terminal, transfiere el mensaje de notificación al cliente de DS o de DM.

En la etapa 404, el cliente de DS o de DM, en el terminal de DS o de DM, extrae el contenido en el mensaje, tal como el ID de servidor de DS o de DM, realiza la autenticación Digest en el mensaje de notificación, analiza el formato del mensaje y determina la importancia de la sesión.

El terminal de DS o de DM determina si el mensaje requiere, o no, una respuesta en conformidad con la política antes citada establecida y memorizada en el terminal de DS o de DM por anticipado. A modo de ejemplo, si el ID del servidor de DS o de DM es incorrecto, no se supera la autenticación Digest o el formato de la notificación es incorrecto, el terminal responde con la información de error correspondiente al servidor como la respuesta del mensaje de notificación.

Si el ID del servidor de DS o de DM es correcto, se supera la autenticación Digest o el formato de la notificación es correcto, el terminal puede responder con la información correspondiente, a modo de ejemplo, la información que indica que el terminal recibe satisfactoriamente el mensaje, al servidor como la respuesta del mensaje de notificación.

En la etapa 405, el cliente de DS o de DM, en el terminal de DS o de DM, genera el código de estado y el mensaje de respuesta con el fin de indicar si el mensaje de notificación se recibe satisfactoriamente.

Si se recibe satisfactoriamente el mensaje, el terminal responde con la información 200 (satisfactoria), si el ID del servidor de DS o de DM es incorrecto, no se supera la autenticación Digest o el formato de la notificación es incorrecto, el terminal responde con el código de error correspondiente al servidor de notificación y la Tabla correspondiente detallada del código de estado se muestra en la Tabla 5.

En la etapa 406, el cliente de DS o de DM transfiere al mensaje de respuesta al cliente de notificación.

Conviene señalar que antes de que el cliente de DS o de DM determine transferir, o no, el mensaje de respuesta al cliente de notificación, es necesario determinar si responder con el mensaje de notificación en función de la forma de soporte del mensaje de notificación y el número de respuesta del servidor de notificación.

En la etapa 407, el cliente de notificación empaqueta el mensaje de respuesta para el formato especificado, según se indica en la Tabla 4 como sigue.

En la etapa 408, el cliente de notificación transfiere el mensaje de respuesta empaquetado al servidor de notificación.

En la etapa 409, el servidor de notificación realiza el procesamiento subsiguiente en función del mensaje de respuesta.

Si el código de estado, reenviado desde el terminal, indica que el mensaje se recibe satisfactoriamente, el servidor de notificación no reenvía el mensaje de notificación. Si el código de estado, reenviado desde el terminal, es el código de error, el servidor regenera el mensaje de notificación en función de la situación del fallo ocurrido y reenvía el mensaje de notificación al terminal. A modo de ejemplo, si el formato es incorrecto, el servidor comprueba el formato del mensaje. Si el Digest es incorrecto, la información de autenticación se readquiere para generar el Digest.

En la etapa 410, el servidor de notificación envía un resultado del procesamiento al servidor de DS o de DM.

Puede deducirse de la forma de realización anterior que mediante análisis, determinación y autenticación de la forma y del contenido del mensaje de notificación, puede determinarse los problemas en el mensaje, tales como el problema del formato, el problema del ID del servidor de DS o de DM, el problema de que no se supera la autenticación y el problema de que la versión es incorrecta o la sesión iniciada por el servidor no es importante. A continuación, los problemas se transmiten en el mensaje de respuesta enviado al servidor, de modo que el servidor conozca si el mensaje de notificación se recibe satisfactoriamente, con el fin de no enviar el mensaje de notificación; o el servidor corrige la información pertinente cuando conoce que los problemas del formato, de la versión y del ID del servidor existen en el mensaje, con el fin de enviar el mensaje de notificación actualizado, a su debido tiempo, para realizar la sesión o el servidor no reenvía, a ciegas, el mensaje de sesión después de conocer la información de que el terminal rechaza la sesión.

Conviene señalar que en la etapa 505, el terminal de DS o de DM selecciona la forma de soporte en función de la forma de soporte de la notificación cuando se entrega, con el fin de soportar el mensaje de respuesta. Además, con el fin de permitir al servidor conocer mejor el mensaje de respuesta, en la presente invención, el formato del mensaje de respuesta se diseña, según se ilustra en la Tabla 4 como sigue.

notificación-cabecera

notificación-cuerpo

específico-

versión

proveedor

Tabla 4: El formato del mensaje de respuesta de la notificación Algunos campos tales como <version> y <sessionid> tienen el mismo significado que en el mensaje de notificación. La descripción de otros campos se proporciona como sigue.

<status-code>::= 4*BIT: el campo representa “código de estado”, <length-authname>::= 8*BIT: el campo representa “longitud del nombre de autenticación”, <authname>::= <length-authname>*CHAR: el campo representa “nombre de autenticación”, <status-code> se utiliza el servidor de DS o de DM que realiza la autenticación del terminal de DS o de DM. <status- code> está adaptado para mostrar el código de estado del mensaje de notificación recibido por el terminal, tal como satisfactorio y en fallo operativo. Los códigos de estado posibles son según se ilustra en la Tabla 5 como sigue.

Código de estado Significado 0000 El terminal recibe satisfactoriamente el mensaje 0001 No se supera la autenticación Digest 0010 La versión no está adaptada 0011 El formato es error 0100 El ID del servidor no existe 0101 No especificado es error 0111 El terminal rechaza la sesión 0110-1111 Reservado para extensión

Tabla 5

Conviene señalar que el establecimiento del formato o la Tabla se proporciona a modo de ejemplo y en la presente invención, no se excluyen otros establecimientos similares, por lo que la presente invención no está limitada en este sentido.

Además, con el fin de permitir al servidor entender adecuadamente que el mensaje enviado por el terminal es el mensaje de respuesta de la notificación, el tipo de contenido del mensaje de respuesta puede definirse como siendo: application/vnd.syncml.dm.response application/vnd.syncml.ds.response.

El servidor puede conocer la situación de recibir el mensaje por el terminal en función de la información de código de estado recibida.

Si el terminal de DS o de DM no puede responder con el mensaje de notificación debido a la forma de soporte u otros motivos, a modo de ejemplo, el número de respuesta del servidor de notificación no puede adquirirse o el servidor de notificación proporciona el mensaje de notificación por intermedio de WAP PUSH, el terminal no puede responder al mensaje de notificación en el modo WAP PUSH; en este caso, el terminal puede responder al mensaje al servidor en la manera de sesión de DS o de DM; a modo de ejemplo, el terminal puede responder la información de error correspondiente del servidor de notificación o la información que indica que se rechaza la sesión. Conviene señalar que si el terminal de DS o de DM no supera la autenticación Digest del mensaje de notificación, o la información del ID del servidor de DS o de DM se encuentra que es incorrecta, el terminal no inicia la sesión de DS o de DM para comunicar la información de error correspondiente puesto que el servidor no puede ser objeto de confianza. Si el formato de la notificación es incorrecto, la versión no es coincidente y existen otros errores, el terminal puede comunicar la información de error en la manera de sesión de DS o de DM. Cuando el mensaje se responde al servidor en la manera de sesión de DS o de DM, Alert Type requiere que se defina en el protocolo para comunicar la información especificada, a modo de ejemplo, org.openmobilealliance.dm.notification-error indica el código de error pertinente en <Data>.

La situación detallada puede obtenerse con referencia a la Figura 5, un diagrama de flujo de señalización de respuesta con el mensaje por intermedio del cliente de DS o de DM, según la segunda forma de realización del método de la presente invención y el proceso detallado se muestra como sigue.

Las etapas se describen como sigue.

En la etapa 501, el servidor de DS o de DM proporciona la información pertinente de gestión de sesión y demanda al servidor de notificación que proporcione el mensaje de notificación al terminal de DS o de DM. El servidor de notificación puede ponerse en práctica como el servidor de mensajes cortos, el servidor OTA PUSH o el servidor SIP PUSH, etc.

El contenido de información de gestión pertinente se describió anteriormente, por lo que aquí no se repite.

En la etapa 502, el servidor de notificación proporciona el mensaje de notificación al terminal de DS o de DM y demanda la conexión de sesión. El mensaje de notificación incluye el objetivo de gestión de sesión, la importancia y otra información la manera de entrega puede ser en la forma de mensaje corto y OTA PUSH, etc.

En la etapa 503, el cliente de notificación, en el terminal, transfiere el mensaje de notificación al cliente de DS o de DM.

En la etapa 504, el cliente de DS o de DM, en el terminal de DS o de DM, extrae el contenido en el mensaje, tal como el ID del servidor de DS o de DM, realiza la autenticación Digest del mensaje de notificación, analiza el formato del mensaje y determina la importancia de la sesión, etc.

El terminal de DS o de DM determina si el mensaje requiere responderse en conformidad con la política antes citada que se establece y memoriza en el terminal de DS o de DM por anticipado. A modo de ejemplo, si el formato de la notificación es incorrecto y la información de la versión es incorrecta, el terminal responde con la información de error correspondiente al servidor de DS o de DM.

Si el ID del servidor de DS o de DM es correcto, se supera la autenticación Digest, el formato de la notificación es correcto y la versión es correcta, el terminal puede responder con la información correspondiente, a modo de ejemplo, la información que indica que el terminal recibe satisfactoriamente el mensaje, al servidor de DS o de DM.

Si el terminal considera que la importancia de la sesión no satisface la política establecida, el terminal envía el mensaje de respuesta de rechazo de la sesión al servidor de DS o de DM.

En la etapa 506, cuando el cliente de DS o de DM determina que el mensaje requiere responderse en conformidad con la política correspondiente, confirmando la forma de soporte del mensaje de notificación, el número de respuesta del servidor de notificación y otra información, el cliente de DS o de DM determina no responder en la forma de notificación o el cliente de DS o de DM selecciona directamente responder con el mensaje en la manera de sesión de DS o de DM. El contenido del mensaje de respuesta incluye que el formato del mensaje es incorrecto, la versión del mensaje es incorrecta, el mensaje de notificación se recibe satisfactoriamente o se rechaza la sesión.

De modo opcional, el cliente de DS o de DM puede visualizar la información pertinente en el mensaje de notificación para el usuario y demanda al usuario que confirme si se rechaza, o no, la sesión por una interfaz de usuario (UI).

En la etapa 507, el usuario determina rechazar la sesión mediante una interfaz de entrada.

En la etapa 508, el terminal de DS o de DM inicia la conexión de sesión al servidor de DS o de DM y envía el mensaje de respuesta de rechazo de la sesión.

De modo opcional, si el terminal acepta la sesión, el terminal inicia la operación de sesión correspondiente en función de la indicación en el mensaje de notificación, a modo de ejemplo, el terminal inicia una sesión vacía o comunica la información del dispositivo.

En la etapa 508, el terminal de DS o de DM requiere iniciar una sesión especial para notificar al servidor que el terminal rechaza la sesión. Un Alert type requiere que se defina para notificar al servidor la utilización del mensaje y el tipo puede definirse como: org.openmobilealliance.dm.refuse-session.

La realización, a modo de ejemplo, del mensaje es como sigue.

<Alert>; el campo representa “orden de alerta” <CmdID>1</CmdID>; el campo representa “ID de número de secuencia de la orden” <Data>1226</Data>; el campo representa “tipo de alerta 1226 que representa la alerta genérica” <Item>: el campo representa “elemento de datos”, <Meta>: el campo representa “información de descripción del elemento de datos”, <Type xmlns=”syncml:metinf”>; el campo representa “tipo de elemento de datos” org.openmobilealliance.dm.refuse-session: el campo representa “la sesión es rechazada”, </Type> <Format xmlns=”syncml:metinf”>b64</Format>: formato de datos de <Data>, </Meta> <Data>abc… </Data>: el campo representa “contenido de datos”, </Item> </Alert> O bien, un tipo de alerta se expande por separado, a modo de ejemplo, Alert 1220, que se adapta para comunicar la información que indica que la sesión es rechazada al servidor.

La realización, a modo de ejemplo, del mensaje es como sigue.

<Alert>: el campo representa “orden de notificación”, <CmdID>1</CmdID> <Data>1220</Data>: el campo representa “tipo de notificación, que representa que el terminal rechaza la sesión”, <Item> … </Item> </Alert> Además, la información que indica que el formato de mensaje incorrecto, la versión del mensaje es incorrecta y el mensaje de notificación se recibe satisfactoriamente puede transmitirse en el elemento de Alert en el mensaje.

Con el fin de ahorrar el tráfico, después de recibir el mensaje de respuesta de rechazo de la sesión, el servidor de DS o de DM puede no responder con el mensaje.

Según la descripción de la forma de realización antes citada, puede deducirse que el terminal de DS o de DM conoce si la sesión iniciada por el servidor de DS o de DM es, o no, importante por anticipado mediante el mensaje de notificación, aún cuando el mensaje de notificación entregado por el servidor indique que la sesión es importante, el terminal determina si la sesión es, o no, importante en función de su estado operativo. Cuando se determina que la sesión no es importante, el terminal envía directamente la información de respuesta de rechazo de la sesión al servidor, impidiendo así que el servidor de DS o de DM envíe repetidamente el mensaje de notificación antes de informarse de que el terminal inicia la sesión y evita desperdiciar el recurso de la red y de procesamiento del servidor. Por lo tanto, el terminal conoce el objetivo y la importancia de la sesión por anticipado, por lo que se evita la situación de que la sesión en curso se rechaza cuando se detecta que la importancia de la sesión no cumple el requisito, evitando de este modo el desperdicio de los recursos de procesamiento del terminal y los recursos de transmisión de la red.

En un ejemplo, el agente SIP push que sirve como el servidor de notificación, envía el mensaje de notificación, el método para procesar el mensaje aplicable a la sesión de DS o de DM, según la presente invención que se describe con más detalle, de modo que los expertos en esta técnica puedan entender la solución de la presente invención con mayor claridad. En este ejemplo, un agente remitente de SIP push es el servidor de notificación y un agente receptor de SIP push es el cliente de notificación. El contenido de push incluye el mensaje de notificación. El proceso detallado puede obtenerse con referencia a la Figura 6, que incluye las etapas siguientes.

En la etapa 601, el servidor de DS o de DM transfiere la demanda de notificación al agente remitente SIP push y demanda el envío del mensaje de notificación.

En la etapa 602, el servidor del agente remitente SIP push entrega el contenido de la notificación al terminal de DS o de DM.

El servidor del agente remitente SIP push entrega el mensaje de notificación al agente receptor SIP push (es decir, el cliente de notificación) en el terminal de DS o de DM utilizando un protocolo SIP push.

El contenido del Digest y de la cabecera de mensaje de la notificación, en este ejemplo, se indica en la Tabla 6 como sigue.

Tabla 6

El contenido del cuerpo de la parte de cuerpo del mensaje de la notificación se ilustra en la Tabla 7 como sigue.

específico-

proveedor

‘la sesión es información de recogida

cantidad señal’

Tabla 7

El contenido de la notificación se entrega utilizando el método MESSAGE en el SIP y la realización, a modo de ejemplo, del mensaje SIP se proporciona como sigue.

MESSAGE sip:user@domain.com SIP/2.0 Via:SIP/2.0/TCP serverpc.domain.com;branch=z9hG4bk776sgdkse; Max-Forwards: 70 Desde: sip:server@domain.com;tag=49583 Para: sip:user@domain.com Call-ID: asd88asd77@1.2.3.4 CSeq: 1 MESSAGE Content-Type: application/vnd.syncml.dm.notification Content-Length: (…) [--¡El mensaje de notificación va aquí!--] En la etapa 603, el agente receptor SIP push envía el mensaje de notificación al cliente de DS o de DM.

El terminal de DS o de DM proporciona la respuesta para el contenido Push utilizando el SIP y la realización a modo de ejemplo del mensaje se proporciona como sigue: SIP/2.0 200 OK Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bk123dsghds; Via: SIP/2.0/TCP senderpc.domain.com;branch=z9hG4bk776sgdkse; Desde: sip:server@domain.com:tag=49394 Para: sip:user@domain.com Call-ID: asd88asd77@1.2.3.4 CSeq: 1 MESSAGE Content-Type: application/vnd.syncml.dm.response Content-Lenght: (…) [--¡El mensaje de respuesta de notificación va aquí!--] El contenido y el formato del mensaje de respuesta de la notificación se ilustran en la Tabla 8 como sigue.

versión

específico-

proveedor

La versión es 1.3.

Tabla 8: Contenido del mensaje de respuesta En la etapa 604, cliente de DS o de DM realiza la autenticación, el análisis y la determinación en función del contenido del mensaje de notificación, el proceso detallado es el mismo que el ejemplo del método y el cliente de DS o de DM determina la forma y el contenido del mensaje de respuesta en función del resultado de la autenticación, análisis y determinación y de la política correspondiente.

A modo de ejemplo, si se determina responder con el mensaje por el agente receptor SIP push en función del proceso anterior, el procedimiento prosigue con la etapa 605. Si el terminal de DS o de DM encuentra que la importancia de la sesión es baja en función de la política establecida y conoce que la sesión es la diagnosis desde el MOI y no se requiere el tipo de sesión, el terminal de DS o de DM no desea una perturbación operativa y rechaza automáticamente la sesión, y el procedimiento prosigue con la etapa 607.

En la etapa 605, el agente receptor SIP push envía el mensaje de respuesta al agente emisor SIP push en el servidor de agente emisor SIP push en la forma SIP.

En la etapa 606, el servidor de agente remitente SIP push envía el mensaje de respuesta al servidor de DS o de DM.

En la etapa 607, el cliente de DS o de DM inicia la sesión de DS o de DM para el servidor de DS o de DM y envía el mensaje de respuesta para rechazar la sesión.

La realización, a modo de ejemplo, del contenido del mensaje de rechazo de la sesión se proporciona como sigue.

<Alert>; el campo representa “orden de alerta”, <CmdID>1</CmdID>: el campo representa “ID de número de secuencia de la orden”, <CmdID>1</CmdID>: el campo representa “ID de número de secuencia de la orden”, <Data>1226</Data>: el campo representa “tipo de alerta 1226 que representa la alerta genérica”, <Item>; el campo representa “elemento de datos”, <Meta>; el campo representa “información de descripción del elemento de datos”, <Type xmlns=”syncml:metinf”>: el campo representa “tipo de elemento de datos” org.openmobilealliance.dm.refuse-session: el campo representa “el terminal rechaza la sesión”, </Type> <Format xmlns=”syncml:metinf”>b64</Format>: el campo representa “formato de los datos” <Data>, </Meta> <Data> abc… </Data>: el campo representa “contenido de datos”, </Item> </Alert> Puede deducirse de la forma de realización anterior que, mediante el análisis, determinación y autenticación de la forma y del contenido del mensaje notificación, los errores en el mensaje pueden determinarse, tales como el error de formato, el error de ID del servidor de DS o de DM, el error de que no se supera la autenticación y el error de que la versión es incorrecta o la sesión iniciada por el servidor no es importante. A continuación, los problemas se transmiten en el mensaje de respuesta enviado al servidor, de modo que el servidor conozca si el mensaje de notificación se recibe satisfactoriamente o no, con el fin de no enviar el mensaje de notificación; o el servidor corrige la información pertinente cuando se conoce el error de formato, la versión y el ID del servidor existen en el mensaje, con el fin de enviar el mensaje de notificación actualizado, a su debido tiempo, para realizar la sesión o el servidor no reenvía, a ciegas, el mensaje de sesión después de conocer la información de que el terminal rechaza la sesión. Además, el terminal de DS o de DM conoce, por anticipado, si la sesión iniciada por el servidor de DS o de DM es importante, o no, mediante el mensaje de notificación, aún cuando el mensaje de notificación entregado por el servidor indique la sesión es importante, el terminal determina si la sesión es importante o no, en función de su estado operativo. Cuando se determina que la sesión no es importante, el terminal envía directamente la información de respuesta de rechazar la sesión al servidor, con lo que se impide que el servidor de DS o de DM envíe repetidamente el mensaje de notificación antes de recibir la inicialización de sesión desde el terminal y evitando así el desperdicio del recurso de la red y del procesamiento del servidor. Ahora bien, el terminal conoce el objetivo y la importancia de la sesión por anticipado, de modo que se evita la situación de que la sesión en curso se rechace cuando se detecte que la importancia de la sesión no cumple el requisito, con lo que se impide el desperdicio de los recursos de procesamiento del terminal y de los recursos de transmisión de la red.

Según la descripción del modo de puesta en práctica antes citado, los expertos en esta técnica pueden conocer claramente que la presente invención puede realizarse utilizando el software y la plataforma de hardware universal necesaria y más concretamente, puede realizarse utilizando el hardware, pero en la mayoría de las situaciones, la anterior es mucho más preferida. Sobre la base de este conocimiento, la solución técnica de la presente invención es prácticamente, o las partes que contribuyen a la técnica anterior pueden realizarse, en la forma de producto informático. El producto informático de ordenador se memoriza en un medio de almacenamiento legible, tal como un disco flexible, un disco duro o un disco óptico del ordenador e incluye varias instrucciones para permitir a un dispositivo de ordenador (un ordenador personal, un servidor o un dispositivo de red) realizar el método según cada forma de realización de la presente invención.

Será evidente para los expertos en esta técnica que se pueden realizar varias modificaciones y variaciones a la estructura de la presente invención sin desviarse por ello del alcance de protección de la invención. En vista de lo que antecede, está previsto que la presente invención cubra las modificaciones y variaciones de esta invención a condición de que caigan dentro del alcance de protección de las siguientes reivindicaciones y sus equivalentes.

REIVINDICACIONES

1.

Un método para procesar un mensaje, aplicable a una sesión de Sincronización de Datos, DS, que comprende: recibir, por un terminal, un mensaje de notificación de demanda de establecimiento de una sesión enviado por un servidor, en donde el mensaje de notificación incluye información de gestión de sesión relativa a la sesión; adquirir, por el terminal, la información de gestión de sesión relativa a la sesión en el mensaje de notificación y confirmar, por el terminal, el mensaje de notificación en función de la información de gestión de sesión, generar un mensaje de respuesta que incluya información de error del mensaje de notificación en función de un resultado de confirmación y enviar el mensaje de respuesta al servidor bajo la forma de un mensaje de sesión de DS, para dar instrucciones al servidor con el fin de modificar el mensaje de notificación en consecuencia de acuerdo con un tipo de error de la información de error y reenviar un mensaje de notificación modificado, en donde la información de gestión de sesión comprende información de identificador del servidor, información de autenticación e información de indicación de la sesión, en donde la información de indicación de la sesión comprende al menos una de: información de indicación de interfaz de usuario, información de objetivo, información de importancia, información de temporización, información de operación e información de política de respuesta de la sesión.

2.

El método según la reivindicación 1, en donde antes de generar el mensaje de respuesta en función del resultado de confirmación, el método comprende, además: determinar, por el terminal, si se requiere responder con el mensaje de notificación y generar, por el terminal, el mensaje de respuesta en función del resultado de confirmación si el mensaje de notificación requiere su respuesta.

3.

El método según la reivindicación 1, en donde la información de error del mensaje de notificación comprende una de la información que indica que: la información de identificador del servidor, en el mensaje de notificación, es incorrecta o no existe; el formato del mensaje de notificación es incorrecto; la autenticación sobre la información de autenticación del mensaje de notificación, en el mensaje de notificación, presenta un fallo operativo y el mensaje de notificación excede un periodo de validez.

4.

Un terminal de Sincronización de Datos, DS, (100), que comprende: un módulo de recepción de mensaje de notificación (1021), adaptado para recibir un mensaje de notificación enviado por un servidor, en donde el mensaje de notificación incluye información de gestión de sesión; un módulo de determinación de sesión (1012), adaptado para adquirir la información de gestión de sesión y para confirmar el mensaje de notificación en función de la información de gestión de sesión y la información de gestión de sesión comprende información de identificador del servidor, información de autenticación e información de indicación de la sesión, en donde la información de indicación de la sesión comprende al menos una de entre: información de indicación de interfaz de usuario, información de objetivo, información de importancia, información de temporización, información de operación e información de política de respuesta de la sesión; un módulo de generación de mensaje de respuesta (1013), adaptado para generar un mensaje de respuesta que incluye información de error del mensaje de notificación en función de un resultado de confirmación del módulo de determinación de sesión (1012); y un módulo de transcepción de mensajes (1011), adaptado para enviar el mensaje de respuesta generado por el módulo de generación de mensaje de respuesta (1013) al servidor, en la forma de mensaje de sesión de DS, para dar instrucciones al servidor con el fin de modificar el mensaje de notificación en consecuencia en función de un tipo de error de la información de error, y reenviar un mensaje de notificación modificado.

5.

El terminal DS (100) según la reivindicación 4, en donde el módulo de determinación de sesión (1012) está adaptado, además, para confirmar si la información de identificador del servidor es correcta en función de la información de identificador del servidor en la información de gestión de sesión, para efectuar la autenticación de información de autenticación en el mensaje de notificación en función de la información de identificador correcta del servidor y determinar una importancia de la sesión en función de la información de indicación de la sesión en la información de gestión de sesión.

6.

El terminal DS (100) según la reivindicación 5, en donde el módulo de generación de mensaje de respuesta (1013) está adaptado, además, para incluir la información de error de identificador del servidor y/o información de fallo de autenticación confirmada por el módulo de determinación de sesión (1012) en el mensaje de respuesta generado o soportar información de rechazo de la sesión confirmada por el módulo de determinación de sesión (1012) en función de la información de indicación de la sesión en el mensaje de respuesta generado.

7.

Un servidor de Sincronización de Datos, DS (200) que comprende: un módulo de iniciación de mensaje de notificación de sesión (201), adaptado para enviar un mensaje de notificación para la demanda de establecimiento de una sesión a un terminal de DS (100) en donde el mensaje de notificación incluye información de gestión de sesión relativa a la sesión y la información de gestión de sesión comprende información del identificador del servidor, información de autenticación e información de indicación de la sesión, en donde la información de indicación de la sesión comprende al menos una de entre: información de indicación de interfaz de usuario, información de objetivo, información de importancia, información de temporización, información de operación e información de política de respuesta de la sesión; un módulo de recepción de mensaje de respuesta (202), adaptado para recibir un mensaje de respuesta reenviado desde el terminal de DS (100); y un módulo de procesamiento (203), adaptado para realizar un procesamiento correspondiente en función del contenido transmitido en el mensaje de respuesta; en donde el mensaje de respuesta, recibido por el módulo de recepción de mensaje de respuesta (202), transmite información de error del mensaje de notificación en la forma de un mensaje de sesión de DS, en donde la información de error del mensaje de notificación comprende una de la información siguiente que indica que el identificador del servidor es incorrecto, el formato del mensaje de notificación es incorrecto, existe un fallo en la autenticación Digest y la información de versión es incorrecta; y el módulo de procesamiento (203) está adaptado, además, para modificar, en correspondencia, el mensaje de notificación en función de un tipo de error en la información de error del mensaje de notificación y reenviar el mensaje de notificación modificado.

Usuario

Cliente DS o DM

Servidor DS o DM

101. Paquete nº 0: Entregar el mensaje

de notificación y demandar la conexión

de sesión

102. El usuario

realiza la

103. Paquete nº 1: Iniciar la conexión de

confirmación

sesión e iniciar el paquete de inicialización para el servidor

104. Paquete nº 2: Enviar el paquete de

inicialización al cliente y realizar la

operación de sesión

105. Operación de sesión subsiguiente

Figura 1

Terminal

Módulo recepción

Módulo

mensaje respuesta

procesa-

miento

Cliente DS o DM

Protocolo

SyncML

Módulo

Módulo iniciación

establecimiento

mensaje notificación

Módulo

Módulo

política

sesión

trans-

generación

Terminal

cepción

mensaje

mensaje

respuesta

Módulo

determinación

sesión

SMS, WAP y

Módulo recepción

PUSH, etc.

Módulo envío

mensaje notificación

mensaje notificación

Módulo envío

SMS, WAP y

mensaje respuesta

PUSH, etc.

Módulo

Módulo

recepción

resolución

mensaje

mensaje

respuesta

respuesta

Servidor notificación

Cliente de notificación

Figura 2

Recibir el mensaje de notificación

Extraer el contenido del mensaje de

notificación

Confirmar la forma y

el contenido del mensaje

Determinar si el mensaje requiere

responderse, o no, en conformidad

con la política

Determinar la forma y el contenido del mensaje de

respuesta y generar el mensaje de respuesta

Responder al mensaje

Figura 3

Cliente DS o

Cliente de

Servidor de

Servidor DS

DM

notificación

notificación

o DM

401.

402. Entregar el mensaje de

Proporcionar el

notificación y demandar la

403. Transferir el

mensaje

conexión de sesión

contenido del

pertinente de

mensaje

gestión de

sesión

404. Autenticar, analizar y

determinar el formato

405. Generar el código de estado y el

mensaje de respuesta

406. Transferir

el mensaje de

respuesta

407. Empaquetar el

mensaje de respuesta

para el formato

especificado

408. Transferir el

mensaje de respuesta

409. Realizar el

empaquetado

procesamiento

subsiguiente en función

del mensaje de respuesta

410. Transferir

el resultado

Figura 4

Cliente DS

Cliente de

Servidor de

Servidor

Usuario

o DM

notificación

notificación

DS o DM

502. Entregar el mensaje

501.

de notificación y

Proporcionar el

demandar la conexión

503. Transferir el

mensaje

contenido del

de sesión

pertinente de

mensaje

gestión de

sesión

504. Autenticar, analizar y

determinar el formato

505. Determinar la respuesta al

mensaje en la manera de sesión de

DS o DM

506. Solicitar al

usuario que realice Flujo

la confirmación

opcio

nal

507. El usuario

rechaza la sesión

508. Iniciar la conexión de sesión y enviar el

mensaje de respuesta de rechazo de la sesión

Figura 5

Servidor

Agente emisor

Agente receptor

Cliente DM

DS o DM

SIP push

SIP push

601. Transferir la

602. Entregar el mensaje de

demanda

notificación en la manera

notificación

SIP push

603. Mensaje de

notificación

604. Autenticar,

analizar y determinar

605. Enviar el mensaje de

respuesta en la manera SIP

606. Reenviar el

mensaje de

respuesta

607. Enviar el mensaje de respuesta de rechazo de la

sesión iniciando la sesión DS o DM

Figura 6