ES2436792T3 - Método, sistema, servidor y terminal de procesamiento de mensaje - Google Patents

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

Info

Publication number
ES2436792T3
ES2436792T3 ES08757707.8T ES08757707T ES2436792T3 ES 2436792 T3 ES2436792 T3 ES 2436792T3 ES 08757707 T ES08757707 T ES 08757707T ES 2436792 T3 ES2436792 T3 ES 2436792T3
Authority
ES
Spain
Prior art keywords
message
session
information
notification
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES08757707.8T
Other languages
English (en)
Inventor
Kepeng Li
Xiaoqian Chai
Linyi Tian
Fujun Ye
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Application granted granted Critical
Publication of ES2436792T3 publication Critical patent/ES2436792T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/12—Application layer protocols, e.g. WAP [Wireless Application Protocol]

Abstract

Un método para procesar un mensaje, aplicable a una sesión de Sincronización de Datos, DS o de Gestión deDispositivo, DM, que comprende: recibir, por un terminal, un mensaje de notificación de demanda de establecimiento de una sesión enviado por unservidor, 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 yconfirmar, por el terminal, el mensaje de notificación en función de la información de gestión de sesión, generar unmensaje de respuesta que incluya información de error del mensaje de notificación en función de un resultado deconfirmación y enviar el mensaje de respuesta al servidor bajo la forma de un mensaje de sesión de DS o DM, endonde la información de gestión de sesión comprende información de identificador del servidor, información deautenticación e información de indicación de la sesión, en donde la información de indicación de la sesióncomprende al menos una de: información de indicación de interfaz de usuario, información de objetivo, informaciónde importancia, información de temporización, información de operación e información de política de respuesta de lasesión; modificar, por el servidor, el mensaje de notificación en consecuencia en conformidad con un tipo de error de lainformación de error y reenviar un mensaje de notificación modificado.

Description

Método, sistema, servidor y terminal de procesamiento de mensaje
5 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
15 ‘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
25 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 35 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
45 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
55 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.
65 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. Este método establece una sesión 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. Esto da lugar a un proceso de gestión eficiente, con ahorro de costes y 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 o de DM, se puede transmitir más información de gestión de sesión en el mensaje de notificación de DS o de DM, un terminal de DS o DM analiza y determina el mensaje de notificación y envía un mensaje de respuesta a un servidor de DS o de DM en función de un resultado de análisis y determinación, de modo que el servidor de DS o de DM realice, además, el procesamiento en función de la información reenviada desde el terminal de DS o DM.
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 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 y el mensaje de notificación es confirmado 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, enviándose al servidor el mensaje de respuesta en la forma de mensaje de sesión de DS o de DM. 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 o de DM 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 el mensaje de respuesta;
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 o de DM, de modo que el servidor modifique el mensaje de notificación en correspondencia en función de un tipo de error de la información de error y reenvía 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 o de DM, 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 o de DM, 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 o de DM 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 transmite información de error del mensaje de notificación en la forma de un mensaje de sesión de DS o de DM;
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 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íficolongitud servidor proveedor
específicoproveedor
Servidor-URI
Tabla 1
5 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>; 10 <not-specified>::= “00”; el campo representa “no especificado”,
<response> ::= “01”; el campo representa “respuesta”,
15 <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”, 20 <not-specified> ::= “00”; el campo representa “no especificado”,
<low> ::= “01”; el campo representa “bajo”
25 <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” 30 <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”
35 <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
40 “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.
45 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
50 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
5 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.
10 <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
15 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.
20 <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.
25 <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. 30
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 35 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 40 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 45 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
50 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.
notificación-cabecera notificación-cuerpo
versión iniciador Identificador-Identificador-específicolongitud servidor proveedor
específicoproveedor
Servidor-URI
Tabla 3
5 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”,
10 <MOI>::= <MOI-length> <MOI>; el campo representa “información del primer MOI”,
<MOI-length>::= 8*BIT; el campo representa “longitud de MOI”,
15 <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.
20 <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
25 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.
30 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
35 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.
40 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 45 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 50 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
5 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
15 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.
25 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 35 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 45 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íficoversió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”,
5 <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. <status10 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
15 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.
20 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.
25 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 30 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 35 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
40 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 45 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 una tercera forma de realización, a modo de 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 esta forma de realización, 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 esta forma de realización, se indica en la Tabla 6 como sigue.
notificación-cabecera notificación-cuerpo
específico
versión
proveedor
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.
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. 15 MESSAGE sip:user@domain.com SIP/2.0 Via:SIP/2.0/TCP serverpc.domain.com;branch=z9hG4bk776sgdkse; 20 Max-Forwards: 70 Desde: sip:server@domain.com;tag=49583 Para: sip:user@domain.com 25 Call-ID: asd88asd77@1.2.3.4 CSeq: 1 MESSAGE 30 Content-Type: application/vnd.syncml.dm.notification Content-Length: (…) [--¡El mensaje de notificación va aquí!--] 35
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:
40 SIP/2.0 200 OK Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bk123dsghds; 45 Via: SIP/2.0/TCP senderpc.domain.com;branch=z9hG4bk776sgdkse; Desde: sip:server@domain.com:tag=49394 Para: sip:user@domain.com 50 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í!--] 10 El contenido y el formato del mensaje de respuesta de la notificación se ilustran en la Tabla 8 como sigue.
Tabla 8: Contenido del mensaje de respuesta
15 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 la forma de realización 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.
20 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
25 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.
30 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.
35 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” 40 <Data>1226</Data>: el campo representa “tipo de alerta 1226 que representa la alerta genérica”
<Item>: el campo representa “elemento de datos”,
45 <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”, 50 </Type>
<Format xmlns=”syncml:metinf”>b64</Format>: el campo representa “formato de los datos” <Data>,
55 </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.

Claims (32)

  1. REIVINDICACIONES
    1. Un método para procesar un mensaje, aplicable a una sesión de Sincronización de Datos, DS o de Gestión de Dispositivo, DM, 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 o DM, 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;
    modificar, por el servidor, el mensaje de notificación en consecuencia en conformidad con un tipo de error de la información de error y reenviar un mensaje de notificación modificado.
  2. 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. 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. 4. Un terminal de Sincronización de Datos, DS o de Gestión de Dispositivo, DM, (100), cuyo terminal está caracterizado por cuanto 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), en donde el mensaje de respuesta incluye información de error del mensaje de notificación y
    un módulo de transcepción del mensaje (1011), adaptado para enviar el mensaje de respuesta generado por el módulo de generación de mensaje de respuesta (1013), al servidor en forma de mensaje de sesión de DS o DM, de modo que el servidor modifique el mensaje de modificación en consecuencia en función de un tipo de error de la información de error y reenvía un mensaje de notificación modificado.
  5. 5.
    El terminal DS o DM (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. 6.
    El terminal DS o DM (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. 7.
    Un servidor de Sincronización de Datos, DS o de Gestión de Dispositivo (DM) (200) caracterizado por cuanto 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 o DM (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 o DM (100);
    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, incluye información de error de mensaje de modificación en la forma de un mensaje de sesión de DS o DM 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
  8. 101. Paquete nº 0: Entregar el mensaje de notificación y demandar la conexiónde sesión
  9. 102. El usuario realiza la
    confirmación 103. Paquete nº 1: Iniciar la conexión de sesión e iniciar el paquete de inicialización para el servidor
  10. 104. Paquete nº 2: Enviar el paquete de
    inicialización al cliente y realizar la operación de sesión
  11. 105. Operación de sesión subsiguiente
    Figura 1
    Terminal
    Cliente DS o DM
    Protocolo Módulo recepción mensaje respuesta Módulo procesamiento
    Módulo transcepción mensaje
    Módulo generaciónmensaje respuesta Módulo establecimiento política Módulo SyncML Terminal Módulo iniciación mensaje notificación sesión
    determinación
    sesión
    SMS, WAP y PUSH, etc. Módulo recepción
    Módulo envíomensaje notificación mensaje notificación
    SMS, WAP y PUSH, etc.Módulo envío mensaje respuesta Módulo Módulo
    recepción resolución mensaje mensajerespuesta respuesta Cliente de notificación Servidor 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
  12. 402. Entregar el mensaje de notificación y demandar la403. Transferir el conexión de sesión
    contenido del mensaje
  13. 404.
    Autenticar, analizar y determinar el formato
  14. 405.
    Generar el código de estado y el mensaje de respuesta
  15. 406. Transferir el mensaje de respuesta 407. Empaquetar el mensaje de respuesta
    para el formato especificado
  16. 408. Transferir el
    mensaje de respuesta empaquetado
    Figura 4
  17. 401. Proporcionar el mensaje pertinente de
    gestión de sesión
  18. 409.
    Realizar el procesamientosubsiguiente en función del mensaje de respuesta
  19. 410.
    Transferir el resultado
    Servidor de Servidor
    Cliente DS Cliente deUsuario notificación DS o DM
    o DM notificación
  20. 502. Entregar el mensaje 501.
    de notificación y Proporcionar el demandar la conexión mensaje503. Transferir el de sesión pertinente decontenido del gestión demensaje sesión
  21. 504.
    Autenticar, analizar y determinar el formato
  22. 505.
    Determinar la respuesta al mensaje en la manera de sesión de DS o DM
  23. 506. Solicitar al usuario que realice Flujo
    la confirmación opcio nal
  24. 507. El usuario rechaza la sesión
  25. 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
  26. 601. Transferir la
  27. 602. Entregar el mensaje de
    demanda
    notificación en la manera
    notificación
    SIP push
  28. 603. Mensaje de notificación
  29. 604. Autenticar, analizar y determinar
  30. 605. Enviar el mensaje de respuesta en la manera SIP
  31. 606. Reenviar el
    mensaje de respuesta
  32. 607. Enviar el mensaje de respuesta de rechazo de la sesión iniciando la sesión DS o DM
    Figura 6
ES08757707.8T 2007-07-24 2008-06-13 Método, sistema, servidor y terminal de procesamiento de mensaje Active ES2436792T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN2007100752893A CN101355524B (zh) 2007-07-24 2007-07-24 一种消息处理方法、系统、服务器和终端
CN200710075289 2007-07-24
PCT/CN2008/071296 WO2009012677A1 (fr) 2007-07-24 2008-06-13 Procédé, système, serveur et terminal de traitement de message

Publications (1)

Publication Number Publication Date
ES2436792T3 true ES2436792T3 (es) 2014-01-07

Family

ID=40281001

Family Applications (2)

Application Number Title Priority Date Filing Date
ES08757707.8T Active ES2436792T3 (es) 2007-07-24 2008-06-13 Método, sistema, servidor y terminal de procesamiento de mensaje
ES13179032.1T Active ES2552999T3 (es) 2007-07-24 2008-06-13 Método, sistema, servidor y terminal de procesamiento de mensaje

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES13179032.1T Active ES2552999T3 (es) 2007-07-24 2008-06-13 Método, sistema, servidor y terminal de procesamiento de mensaje

Country Status (7)

Country Link
US (2) US8019877B2 (es)
EP (2) EP2661052B1 (es)
JP (2) JP2010519812A (es)
KR (1) KR101031828B1 (es)
CN (1) CN101355524B (es)
ES (2) ES2436792T3 (es)
WO (2) WO2009012677A1 (es)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101340286B (zh) * 2007-05-30 2011-03-30 华为技术有限公司 会话连接发起方法及设备
CN102308532B (zh) * 2009-05-21 2013-10-09 华为终端有限公司 点到多点推送消息处理方法、系统及服务器
US20110055076A1 (en) * 2009-08-25 2011-03-03 Greg Trifiletti Response to alert message
US20110295947A1 (en) * 2010-06-01 2011-12-01 Htc Corporation Communication apparatus and method thereof
CN101909282B (zh) * 2010-08-20 2014-11-05 中兴通讯股份有限公司 终端操作的触发方法、装置及系统
US8799378B2 (en) * 2010-12-17 2014-08-05 Microsoft Corporation Non-greedy consumption by execution blocks in dataflow networks
CN102571704B (zh) * 2010-12-24 2015-05-27 华为终端有限公司 管理会话的发起和通知方法、被管理终端及管理服务器
CN102651860B (zh) * 2011-02-24 2014-12-31 华为终端有限公司 一种设备管理方法及装置
CN102130910B (zh) 2011-02-28 2015-04-29 华为技术有限公司 Tcp代理插入和卸载方法及业务网关设备
US8554855B1 (en) * 2011-06-14 2013-10-08 Urban Airship, Inc. Push notification delivery system
US8731523B1 (en) 2011-06-14 2014-05-20 Urban Airship, Inc. Push notification delivery system with feedback analysis
US9531827B1 (en) 2011-06-14 2016-12-27 Urban Airship, Inc. Push notification delivery system with feedback analysis
US20130091198A1 (en) * 2011-10-05 2013-04-11 Htc Corporation Method of Reducing Message Transmission between DM Client and DM Server and Related Communication Device
CN103037322A (zh) * 2011-10-05 2013-04-10 宏达国际电子股份有限公司 减少客户端及服务器间讯息传输的方法及其通信装置
KR101956634B1 (ko) 2012-01-03 2019-03-11 삼성전자 주식회사 행동 정보 알림 서비스 시스템 및 행동 정보 알림 서비스 방법
US9075953B2 (en) 2012-07-31 2015-07-07 At&T Intellectual Property I, L.P. Method and apparatus for providing notification of detected error conditions in a network
US9762465B2 (en) 2012-08-20 2017-09-12 Lg Electronics Inc. Method and apparatus for transmitting a response to a command in wireless communication system
US8924443B2 (en) * 2012-10-05 2014-12-30 Gary Robin Maze Document management systems and methods
CN103873538A (zh) * 2012-12-18 2014-06-18 中兴通讯股份有限公司 基于dm协议的服务端与终端的通信方法及系统
WO2014160715A1 (en) * 2013-03-26 2014-10-02 Jvl Ventures, Llc Systems, methods, and computer program products for managing access control
US9053165B2 (en) * 2013-07-08 2015-06-09 Dropbox, Inc. Structured content item synchronization
US10171579B2 (en) 2014-04-08 2019-01-01 Dropbox, Inc. Managing presence among devices accessing shared and synchronized content
US10270871B2 (en) 2014-04-08 2019-04-23 Dropbox, Inc. Browser display of native application presence and interaction data
US10091287B2 (en) 2014-04-08 2018-10-02 Dropbox, Inc. Determining presence in an application accessing shared and synchronized content
US9998555B2 (en) 2014-04-08 2018-06-12 Dropbox, Inc. Displaying presence in an application accessing shared and synchronized content
US9846528B2 (en) 2015-03-02 2017-12-19 Dropbox, Inc. Native application collaboration
CN106161580A (zh) * 2015-04-28 2016-11-23 中兴通讯股份有限公司 一种连接状态控制方法、装置及系统
CN105245534A (zh) * 2015-10-22 2016-01-13 中国移动通信集团江苏有限公司 一种呼叫结果反馈方法、服务器、终端、系统
CN106656729B (zh) 2015-10-30 2019-11-22 阿里巴巴集团控股有限公司 一种发送信息的方法及装置
US10248933B2 (en) 2015-12-29 2019-04-02 Dropbox, Inc. Content item activity feed for presenting events associated with content items
US10620811B2 (en) 2015-12-30 2020-04-14 Dropbox, Inc. Native application collaboration
US10382502B2 (en) 2016-04-04 2019-08-13 Dropbox, Inc. Change comments for synchronized content items
WO2019024102A1 (zh) 2017-08-04 2019-02-07 华为技术有限公司 无线通信中的会话处理方法及终端设备
CN111083127B (zh) * 2019-12-05 2021-11-09 达闼机器人有限公司 会话管理方法、电子设备及计算机可读存储介质
CN112231566B (zh) * 2020-10-16 2023-11-28 成都知道创宇信息技术有限公司 信息推送方法、装置、系统和可读存储介质
CN112737922B (zh) * 2020-12-23 2023-04-14 江苏苏宁云计算有限公司 通讯方法、装置、计算机设备和存储介质
CN112866361A (zh) * 2021-01-06 2021-05-28 戴振卿 一种工业数据的安全传输方法
CN112925779A (zh) * 2021-03-02 2021-06-08 重庆度小满优扬科技有限公司 一种报文回执修改方法及装置
CN113098726B (zh) 2021-06-10 2021-09-03 深圳艾灵网络有限公司 网络切片方法、设备及存储介质

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9826158D0 (en) 1998-11-27 1999-01-20 British Telecomm Anounced session control
US6882659B1 (en) * 1999-09-20 2005-04-19 Telefonaktiebolaget Lm Ericsson (Publ) Wide area network synchronization
JP2001169341A (ja) * 1999-09-29 2001-06-22 Fujitsu Ltd 移動通信サービス提供システム、移動通信サービス提供方法、認証装置、およびホームエージェント装置
JP4076701B2 (ja) * 2000-04-14 2008-04-16 富士通株式会社 ノード装置
US7765316B1 (en) * 2000-10-10 2010-07-27 Intel Corporation Scheduling the uploading of information from a client to a server
JP2002133306A (ja) * 2000-10-20 2002-05-10 Canon Inc 情報処理装置、情報処理システム、情報処理方法、及び記憶媒体
JP3944229B2 (ja) * 2000-12-28 2007-07-11 フューチャーアーキテクト株式会社 フレームワークシステム
EP1388792A1 (en) * 2001-09-05 2004-02-11 Matsushita Electric Industrial Co., Ltd. Synchronization message processing method
US7155521B2 (en) * 2001-10-09 2006-12-26 Nokia Corporation Starting a session in a synchronization system
ATE385094T1 (de) * 2002-04-30 2008-02-15 Nokia Corp Verfahren und einrichtung zur verwaltung des baumdatenaustauschs
EP1639487A4 (en) * 2003-06-27 2008-06-18 Akonix Systems Inc CONTEXTSENSITIVE TRANSFER WITH ACTIVE LISTENING AND ACTIVE ALARMS
FI116958B (fi) 2003-07-01 2006-04-13 Nokia Corp Hallintasolmujen määrittäminen laitteenhallintajärjestelmässä
CN1926847A (zh) * 2004-01-15 2007-03-07 诺基亚公司 用于为移动台更新与安全有关的参数的技术
US7889869B2 (en) * 2004-08-20 2011-02-15 Nokia Corporation Methods and apparatus to integrate mobile communications device management with web browsing
SE528373C2 (sv) * 2004-08-25 2006-10-31 Smarttrust Ab Förfarande och system för apparathantering
FI20041634A0 (fi) * 2004-12-20 2004-12-20 Nokia Corp Tarjontaistunnon muodostaminen kommunikaatiojärjestelmässä
JP4432814B2 (ja) * 2005-03-25 2010-03-17 ヤマハ株式会社 演奏データ通信管理システム及び演奏データ通信管理装置
US7734737B2 (en) * 2005-05-26 2010-06-08 Nokia Corporation Device management with configuration information
KR100941540B1 (ko) * 2005-06-02 2010-02-10 엘지전자 주식회사 장치관리 시스템 및 그 시스템에서의 설정-값 세팅 방법
US20070027971A1 (en) * 2005-07-26 2007-02-01 Sunil Marolia Device management network with notifications comprising multiple choice prompts
US20070093243A1 (en) * 2005-10-25 2007-04-26 Vivek Kapadekar Device management system
RU2447586C2 (ru) * 2005-12-02 2012-04-10 Эл Джи Электроникс Инк. Способ управления устройством с использованием широковещательного канала
US8437751B2 (en) * 2006-04-25 2013-05-07 Core Wireless Licensing S.A.R.L. Method, apparatus and computer program product for providing confirmed over-the-air terminal configuration
US7721003B2 (en) * 2007-02-02 2010-05-18 International Business Machines Corporation System and method to synchronize OSGi bundle inventories between an OSGi bundle server and a client
US9462060B2 (en) * 2007-04-23 2016-10-04 Alcatel Lucent System and method for sending notification message to a mobile station using session initiation protocol (SIP)

Also Published As

Publication number Publication date
US8019877B2 (en) 2011-09-13
JP2010519812A (ja) 2010-06-03
WO2009012677A1 (fr) 2009-01-29
EP2091210A1 (en) 2009-08-19
EP2661052B1 (en) 2015-08-12
CN101355524A (zh) 2009-01-28
JP5249405B2 (ja) 2013-07-31
US20110296042A1 (en) 2011-12-01
EP2091210A4 (en) 2010-09-01
KR101031828B1 (ko) 2011-04-29
US8341274B2 (en) 2012-12-25
JP2012085346A (ja) 2012-04-26
WO2009012730A1 (fr) 2009-01-29
EP2091210B1 (en) 2013-09-04
US20090265471A1 (en) 2009-10-22
CN101355524B (zh) 2013-10-09
ES2552999T3 (es) 2015-12-03
EP2661052A1 (en) 2013-11-06
KR20090086447A (ko) 2009-08-12

Similar Documents

Publication Publication Date Title
ES2436792T3 (es) Método, sistema, servidor y terminal de procesamiento de mensaje
US10609015B2 (en) Method and apparatus of providing messaging service and callback feature to mobile stations
ES2423509T3 (es) Un terminal, un servidor y un método para gestionar dicho terminal y un método para comunicar la información de capacidad relativa a este terminal
US20190068656A1 (en) System and Method for Determining Trust for SIP Messages
US9648052B2 (en) Real-time communications gateway
US9942281B2 (en) Group communication in communication system
CN101536559A (zh) 用于在融合ip消息业务中管理消息线程的方法和系统
JP2007052784A (ja) セッション開始プロトコルでシステムメッセージ転送方法
CN109040986B (zh) 利用直径委托代理传送短消息服务（sms）消息的方法、系统和计算机可读介质
US9769875B1 (en) Multimedia messaging proxy for non-compliant communication devices
WO2017084619A1 (zh) 一种短消息传输方法和装置、及系统
KR20080090250A (ko) 이종 메시지의 상호 연동을 통한 메시지 전송 방법