ES2403188T3 - Recuperación de mensajes instantáneos fuera de línea - Google Patents
Recuperación de mensajes instantáneos fuera de líneaInfo
- Publication number
- ES2403188T3 ES2403188T3 ES06809590T ES06809590T ES2403188T3 ES 2403188 T3 ES2403188 T3 ES 2403188T3 ES 06809590 T ES06809590 T ES 06809590T ES 06809590 T ES06809590 T ES 06809590T ES 2403188 T3 ES2403188 T3 ES 2403188T3
- Authority
- ES
- Spain
- Prior art keywords
- message
- messages
- user
- session
- stored
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
- H04L12/1831—Tracking arrangements for later retrieval, e.g. recording contents, participants activities or behavior, network status
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/224—Monitoring or handling of messages providing notification on incoming messages, e.g. pushed notifications of received messages
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Telephonic Communication Services (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Un dispositivo terminal (10) que comprende: medios (11) para recibir un resumen de mensajes pendientes de recuperar por un usuario, cada mensaje asociado con un identificador único; medios (12) para seleccionar al menos uno de los mensajes a recuperar, basándose en el resumen de mensajes; medios (13) para determinar un identificador válido para recuperar el al menos un mensaje basándose en el identificador único asociado con el al menos un mensaje, obteniendo de esta manera al menos un identificador válido para recuperar; y medios (14) para enviar una solicitud de recuperación con el al menos un identificador válido para recuperar, estableciendo la solicitud de recuperación una sesión para entregar el al menos un mensaje al usuario; caracterizado porque los mensajes pendientes de recuperar son mensajes instantáneos, se ha interceptado y almacenado una secuencia de mensajes de protocolo de iniciación de sesión relacionados con los mensajes instantáneos, respectivamente, mediante un servidor de aplicación, la solicitud de recuperación es un mensaje invite de protocolo de iniciación de sesión, y en respuesta a la solicitud de recuperación se configuran los medios de recepción para recibir mensajes de protocolo de iniciación de sesión encapsulados de los mensajes de protocolo de iniciación de sesión almacenados mediante el servidor de aplicación, que están relacionados con el al menos un mensaje.
Description
Recuperación de mensajes instantáneos fuera de línea.
Antecedentes de la invención
La presente invención se refiere a una tecnología de mensajería instantánea basada en SIP (Protocolo de Iniciación de Sesión)/SIMPLE (SIP para Mensajería Instantánea y Extensiones de Aprovechamiento de Presencia). En particular, la presente invención se dirige al problema que surge cuando un servidor de correo almacena mensajes instantáneos en la red para entrega adicional a un usuario final (presumiblemente cuando el usuario se conecta a la red en un momento posterior).
Se supone que un usuario A envía uno o más mensajes instantáneos a un usuario B. La tecnología usada para entregar estos mensajes se puede basar en el procedimiento de MESSAGE SIP o el Protocolo de Retransmisión de Sesión de Mensaje (MSRP). Se supone adicionalmente que el usuario B no está registrado en su servidor SIP, y que un servidor de aplicación de correo está almacenando los mensajes instantáneos reales para entrega adicional al usuario B en un momento posterior.
Cuando el usuario B se registra en su red SIP, el Agente de Usuario SIP se suscribe a un paquete de evento de Resumen de Mensaje e Indicador de Espera y obtiene notificaciones de los mensajes que están pendientes de recuperar. Se supone que el servidor de correo almacena una gran cantidad de mensajes instantáneos, de modo que el usurario B obtiene una notificación que contiene un resumen de esos mensajes instantáneos almacenados.
El artículo de Myers y col.: “RFC 1939: Post Office Protocol Version 3” Network Working Group Request for Comments, XX, XX, mayo 1996 (1996-05), páginas 1-20, documento XP002197697, se refiere al Protocolo de Oficina Postal Versión 3 (POP3) que permite a una estación de trabajo acceder dinámicamente a la entrega de correo en un servidor anfitrión, es decir permite recuperar a una estación de trabajo correo que el servidor mantiene para ella. En el capítulo 10 se proporciona un ejemplo de una sesión POP3 en la que se proporciona un resumen de mensajes almacenados en el servidor a un cliente y el cliente recupera los mensajes indicando un número de mensaje al servidor que se incluye en el resumen.
El documento US 2003/0165231 A1 desvela un sistema de telefonía de red que posibilita servicios de mensajería unificados. El sistema generalmente incluye al menos un agente de usuario acoplado operativamente a una red de datos y un servidor de señalización acoplado operativamente a la red de datos. Los agentes de usuario son puntos finales de telefonía, tales como aplicaciones de telefonía de internet independientes u ordenadores personales con software de telefonía apropiado. Se proporciona un servidor de mensajería que se acopla operativamente a la red de datos y es receptivo al servidor de señalización. El sistema también incluye un servidor de medios que se acopla operativamente a la red e incluye medios de almacenamiento de datos informáticos para almacenar ficheros de mensaje. El servidor de medios es receptivo al servidor de mensajería y, en la aparición de una condición de mensaje, es directamente accesible a una parte que llama para almacenar un archivo de mensaje para posterior recuperación por una parte llamada.
Sumario de la invención
La presente invención debería posibilitar una recuperación mejorada de mensajes instantáneos fuera de línea.
Esto se consigue mediante un dispositivo terminal de la reivindicación 1, un procedimiento de la reivindicación 10, un dispositivo de red de la reivindicación 4, un procedimiento de la reivindicación 13, un dispositivo de red de la reivindicación 19 y un procedimiento de la reivindicación 21.
La Figura 1 muestra un diagrama de bloques esquemático que ilustra una configuración de un dispositivo terminal y un dispositivo de red de acuerdo con la invención.
El dispositivo terminal 10 comprende un bloque de recepción 11, un bloque de selección 12, un bloque de determinación 13 y un bloque de envío 14. El bloque de recepción 11 recibe un resumen de mensajes almacenados en un servidor de correo tal como el dispositivo de red 20 y pendientes de recuperarse por un usuario, cada mensaje asociado con un identificador único. El bloque de selección 12 selecciona al menos uno de los mensajes a recuperar desde el servidor de correo, basándose en el resumen de mensajes. El bloque de determinación 13 determina un identificador válido para recuperar el al menos un mensaje en base identificador único asociado con el al menos un mensaje, obteniendo de esta manera al menos un identificador válido para recuperar. Y el bloque de envío 14 envía al servidor de correo una solicitud de recuperación con el al menos un identificador válido para recuperar.
El identificador único puede ser un identificador de mensaje proporcionado mediante el servidor de correo o un Identificador de Recurso Uniforme (URI).
El dispositivo de red 20 tal como un servidor de correo almacena mensajes pendientes de recuperarse por un usuario, y comprende un bloque de recepción 21 y un bloque de envío 22. El bloque de recepción 21 recibe una solicitud de recuperación con al menos un identificador válido para recuperar al menos uno de los mensajes almacenados, y el bloque de envío 22 envía el al menos un mensaje hacia un dispositivo terminal (por ejemplo el dispositivo terminal 10) del usuario que origina la solicitud de recuperación.
El bloque de envío 22 puede enviar el al menos un mensaje en un mensaje SEND del Protocolo de Retransmisión de Sesión de Mensaje (MSRP).
De acuerdo con una primera realización, el dispositivo de red 20 puede comprender adicionalmente un bloque de provisión 23 que proporciona un identificador de mensaje para cada uno de los mensajes almacenados, en el que el bloque de envío 22 envía al usuario un resumen de los mensajes almacenados, por ejemplo el dispositivo terminal 10, cada mensaje asociado con el identificador de mensaje determinado.
El bloque de provisión 23 puede usar un campo de encabezamiento ID-Llamada incluido en una solicitud de Protocolo de Iniciación de Sesión de cada uno de los mensajes almacenados para el identificador de mensaje o generar un Identificador de Recurso Uniforme (URI) único, siendo el URI enrutable al dispositivo de red en el que el identificador de mensaje es parte del URI.
El bloque de provisión 23 puede usar un campo de encabezamiento ID-Mensaje de una solicitud del Protocolo de Retransmisión de Sesión de Mensaje para cada uno de los mensajes almacenados por el identificador de mensaje.
De acuerdo con una segunda realización, el dispositivo de red 20 puede comprender un servidor de conferencia y puntos finales virtuales tales como Agentes de Usuario SIP virtuales que corresponden a los mensajes almacenados. El servidor de conferencia puede recibir una solicitud de recuperación desde el usuario que comprende una lista de identificadores que apuntan a los seleccionados de los mensajes almacenados, la solicitud de recuperación que establece una primera sesión para entregar los mensajes seleccionados, establece segundas sesiones para cada uno de los mensajes seleccionados identificados en la lista con los puntos finales virtuales que corresponden a los mensajes seleccionados, y recibe los mensajes seleccionados en dichas segundas sesiones y reenvía los mensajes seleccionados al usuario en dicha primera sesión.
Debe observarse que la configuración mostrada en la Figura 1 es para ilustrar la invención, y el dispositivo terminal y el dispositivo de red pueden comprender adicionalmente bloques que implementan funciones adicionales (tal como un bloque de almacenamiento en el dispositivo de red 20 para almacenar los mensajes), que no son relevantes para entender la invención y la descripción de lo que se omite en este punto.
La Figura 2 muestra un diagrama de flujo que ilustra un procedimiento de recuperación de mensajes desde un servidor de correo en un lado del dispositivo terminal 10. En la etapa S31, se recibe un resumen de mensajes almacenados en el servidor de correo y pendientes de recuperar por un usuario en el dispositivo terminal, cada mensaje asociado con un identificador único. En la etapa S32, se selecciona al menos uno de los mensajes a recuperar desde el servidor de correo basándose en el resumen de los mensajes recibidos en la etapa S31. En la etapa S33, se determina un identificador válido para recuperar el al menos un mensaje basándose en el identificador único asociado con el al menos un mensaje, obteniendo de esta manera al menos un identificador válido para recuperar, y en la etapa S34 se envía una solicitud de recuperación con el identificador válido para recuperación al servidor de correo.
La Figura 3 muestra un diagrama de flujo que ilustra un procedimiento de recuperación de mensajes desde un servidor de correo en un lado del dispositivo de red 20. En la etapa S41, se recibe una solicitud de recuperación con al menos un identificador válido para recuperar al menos uno de los mensajes almacenados, y en la etapa S42 se envía el al menos un mensaje hacia un dispositivo terminal del usuario que origina la solicitud de recuperación.
De acuerdo con la segunda realización, se recibe una solicitud de recuperación desde el usuario que comprende una lista de identificadores que apuntan a los seleccionados de los mensajes almacenados en el dispositivo de red 20, estableciendo la solicitud de recuperación una primera sesión para entregar los mensajes seleccionados. Se establecen segundas sesiones para cada uno de los mensajes seleccionados identificados en la lista, y se reciben los mensajes seleccionados en dichas segundas sesiones y se reenvían los mensajes seleccionados al usuario en dicha primera sesión.
La invención se puede implementar también como un producto de programa informático.
El servidor de correo se puede implementar como un servidor de aplicación de almacén de correo o servidor de correo de mensajes instantáneos.
De acuerdo con la primera realización de la invención, un usuario recibe una notificación de resumen de mensaje que incluye una identidad de mensaje única asignada a cada mensaje almacenado. Para cada mensaje que el usuario quiere recuperar, el Agente de Usuario SIP crea una sesión SIP de los mensajes direccionados a la identidad del mensaje, por ejemplo, después de hacer alguna transformación. El servidor, al recibir la solicitud INVITE, puede determinar únicamente el mensaje real que el usuario quiere recuperar.
Esta solución permite al usuario seleccionar aquellos mensajes instantáneos almacenados que se deberían recuperar. La ventaja es enorme en escenarios móviles, donde el ancho de banda es limitado, y especialmente en casos donde es relevante el número y tamaño de los mensajes instantáneos almacenados. De modo que el usuario puede seleccionar recuperar aquellos mensajes dirigidos como urgente, o que se han recibido desde un usuario particular, y a continuación leer los mensajes restantes en un momento posterior.
De acuerdo con la segunda realización de la invención, se proporciona un mecanismo por el que el usuario, una vez que ha seleccionado los mensajes instantáneos que quiere recuperar desde el servidor de correo, crea una sola sesión (INVITE SIP) direccionada a los mensajes seleccionados, haciendo uso del concepto lista-URI. Esta realización modela el servidor de correo como compuesto de un servidor de conferencia y un número de agentes de usuario SIP virtuales, cada uno representando un mensaje instantáneo almacenado.
De acuerdo con esta realización, se proporciona un mecanismo para seleccionar y recuperar mensajes seleccionados ya almacenados en el servidor de correo de una manera optimizada que se pueda usar en entornos móviles. De acuerdo con esta solución, el usuario puede recuperar un número seleccionado ilimitado de mensajes almacenados en una sola operación de protocolo.
Esta solución permite al usuario minimizar la señalización y las idas y vueltas para recuperar mensajes seleccionados usando una sola sesión hacia el servidor de correo. La solicitud de patente provisional “Procedimiento y aparato para mensajería instantánea” por Garcia y col. presentada con la Oficina de Patentes y Marcas de Estados Unidos el 30 de septiembre de 2005, el contenido de la cual se incorpora en el presente documento por referencia, y la primera realización permiten recuperar el volumen completo de mensajes instantáneos almacenados o mensajes seleccionados uno por uno (lo que significa que cada mensaje requiere una sesión SIP separada).
Por lo tanto, la segunda realización de la presente invención aumenta la experiencia del usuario debido a los menores retardos en establecer sesiones, y optimiza el manejo de recursos sobre los canales de ancho de banda bajos, tales como la interfaz aérea.
En los dibujos:
La Figura 1 muestra un diagrama de bloques esquemático que ilustra una configuración de un dispositivo terminal y un dispositivo de red de acuerdo con la invención.
La Figura 2 muestra un diagrama de flujo que ilustra un procedimiento de recuperación de acuerdo con la invención.
La Figura 3 muestra un diagrama de flujo que ilustra un procedimiento de recuperación de acuerdo con la invención.
La Figura 4 muestra un diagrama de señalización de acuerdo con una primera realización de la invención.
La Figura 5 muestra un diagrama de bloques esquemático que ilustra un servidor de correo anfitrión de acuerdo con una segunda realización de la invención.
La Figura 6 muestra un diagrama de señalización de acuerdo con la segunda realización de la invención.
Descripción de las realizaciones de la invención
Suponiendo que se han depositado mensajes instantáneos en el buzón de un usuario, cuando se enciende el teléfono del usuario, el teléfono envía una suscripción a un paquete de evento de resumen de mensajes, y recibe una notificación con el mensaje pendiente; de acuerdo con el documento RFC3842 “Un Resumen de Mensaje y Paquete de Evento de Indicación de Espera de Mensaje para el Protocolo de Iniciación de Sesión (SIP)”. El contenido del documento RFC 3842 se incorpora en el presente documento por referencia. Este mecanismo se aplica también a CORREO DE VOZ, FAX, etc. El Notificante (un Agente de Usuario SIP que actúa en beneficio del sistema de mensajería del usuario) envía un resumen de mensaje de los mensajes almacenados en el cuerpo de un
NOTIFY por ejemplo “hay 4 mensajes antiguos y 3 mensajes nuevos esperando para ti”.
Opcionalmente, después del recuento del resumen, se pueden adjuntar los encabezamientos de mensaje tales como Para, De, Fecha, Asunto e ID-Mensaje a cada mensaje.
Una vez que se notifica al Usuario/UE (Equipo de Usuario), puede enviar un INVITE al servidor que incluya el tipo de medios deseados a recuperar (con el fin de grupo de Mensajería en OMA (Alianza Móvil Abierta), el INVITE debe incluir una descripción SDP (Protocolo de Descripción de Sesión) del MSRP, pero puede incluir también otro tipo de medios).
Adicionalmente, el usuario puede aplicar un mecanismo como se describe en la solicitud de patente provisional
“Procedimiento y Aparato para Mensajería Instantánea” para recuperar todos los mensajes instantáneos
almacenados desde el servidor de correo, incluyendo información de metadatos (por ejemplo, emisor, hora de entrega, etc.). Con este fin, se proporciona un mecanismo SIP para recuperar mensajes instantáneos que se depositaron previamente en un servidor de aplicación que actuaba como un servidor de aplicación de almacén de mensajes. Esto se puede conseguir manteniendo los encabezamientos relevantes del mensaje SIP encapsulándolos como un mensaje/sip, por ejemplo, como se define en el documento RFC 3261 Sección 27.5, o como un mensaje/sipfrag, como se define en el documento RFC 3420, y a continuación enviarlos como la carga útil de una solicitud SEND MSRP. Los contenidos de los documentos RFC 3261 y 3420 se incorporan en el presente documento por referencia. Adicionalmente, un servidor de aplicación de almacenamiento puede a continuación añadir un encabezamiento al mensaje SEND MSRP y al mensaje SIP encapsulado que contiene la hora y la fecha cuando se recibió el mensaje. Más particularmente, se inserta un encabezamiento de fecha/hora en cada mensaje SIP y MSRP almacenado. Se puede usar semántica novedosa para la encapsulación de los mensajes instantáneos almacenados, y se usa el mensaje/sip y el mensaje/sipfrag en MSRP, fuera de su contexto original. Por lo tanto, se proporciona un procedimiento de entrega de mensajes SIP encapsulados, que incluye la información de encabezamiento, como la carga útil de un mensaje MSRP.
Con el mecanismo anterior, se proporciona un procedimiento y aparato por el que un usuario puede contactar con su servidor de correo y recuperar mensajes instantáneos existentes ya depositados en el servidor de aplicación de almacén de mensajes. Se pueden depositar los mensajes instantáneos en el servidor de aplicación de almacén de mensajes usando solicitudes MESSAGE SIP (según el documento IETF RFC 3428) o mensajes MSRP (por ejemplo, solicitudes SEND MSRP) que son parte de una sesión SIP. El contenido del documento RFC 3428 se incorpora en el presente documento por referencia. Los metadatos y/o información de encabezamiento pueden posibilitar al usuario determinar la fuente del mensaje, la hora en la que el mensaje partió, etc.
Una vez que se establece la sesión SIP con los medios MSRP, todos los mensajes almacenados se transferirán desde el servidor al usuario/UE. Se enviará cada mensaje almacenado en una solicitud SEND MSRP separada (antes de que tenga lugar la partición de solicitudes SEND MSRP) y cada uno se identificará mediante su propio ID-Mensaje original. En este sentido el usuario recupera todos los mensajes en una sola vez, pero podrá todavía clasificar todos los mensajes mediante la ID-Mensaje.
Una de las desventajas de algunas soluciones es que la identificación del emisor original (información de usuario) se pierde necesariamente debido a que los encabezamientos MSRP no contienen ninguna relación con el URI SIP que deposita el mensaje. Por lo tanto, se perderá la asociación de los emisores a sus mensajes particulares ya disponible en las bandejas de entrada de aplicación de mensajería tales como correo electrónico, mensajería instantánea, MMS, etc. Esto se aplica también a solicitudes MESSAGE SIP, en las que pueden enviar pero el receptor no podrá identificar al emisor, debido a que se establece para el servidor de aplicación de almacén de mensaje.
Se propone un mecanismo por el que el usuario, cuando él o ella quieren recuperar sus mensajes instantáneos almacenados, establece una sesión MSRP con su servidor de aplicación de almacén de mensajes. El AS de almacén de mensajes encapsula cada sesión recibida o MESSAGE independiente en una solicitud SEND MSRP. De modo que cada solicitud SEND MSRP representa una sesión SIP o MESSAGE que contiene una carga útil (una o más solicitudes SEND MSRP, o algún otro tipo en el caso de mensaje).
Sin embargo, con los mecanismos anteriores no se permite al usuario B recuperar un mensaje seleccionado (por ejemplo, enviado por un usuario dado, durante un marco de tiempo específico, cuyo asunto es uno específico, o con una prioridad dada). Particularmente, no hay mecanismo donde el usuario B pueda indicar al servidor de correo qué mensaje el usuario está interesado en recibir.
Primera realización
La Figura 4 muestra un diagrama de señalización que ilustra mensajes intercambiados entre usuarios y un servidor de aplicación de almacén de mensajes (AS) de acuerdo con una primera realización. Como se muestra en la Figura 4, Alicia envía un Mensaje Instantáneo a Carlos usando una solicitud MESSAGE SIP (flujo 1). Esta solicitud MESSAGE contiene algún texto, denominado en este punto Texto Nº 1. Suponiendo que Carlos está fuera de línea, se recibe el mensaje y se almacena en el Servidor de Aplicación de almacén de mensajes (AS).
Otro usuario, Bob, crea una sesión SIP enviando una solicitud INVITE (flujo 3) a Carlos. La solicitud INVITE contiene una descripción de sesión que incluye un descriptor MSRP con el fin de enviar mensajes instantáneos basados en sesión. Puesto que Carlos está fuera de línea, el AS de almacén de mensajes intercepta la solicitud INVITE y establece la sesión. A continuación Carlos deposita dos mensajes en la cuenta de mensajería de Carlos, usando solicitudes SEND MSRP (flujos 5 y 7, que incluyen un Texto Nº 2 y Texto Nº 3, respectivamente). Es decir, se envían los mensajes reales con solicitudes SEND MSRP. El mensaje Nº 9 es una solicitud BYE SIP que termina la sesión de mensajes instantáneos.
En un momento posterior, Carlos se conecta a la red y se suscribe a notificaciones de resumen de mensaje, enviando una solicitud SUBSCRIBE SIP (mensaje Nº 11) hacia su servidor de correo, es decir el AS de almacén de mensajes.
Se incluyen las notificaciones en la solicitud NOTIFY (mensaje Nº 13). Las notificaciones que el usuario recibe desde la suscripción al resumen de mensajes y paquete de evento de indicador de espera de mensaje contienen, entre otros elementos, un identificador único de cada mensaje, en el formato de un encabezamiento ID-Mensaje. El servidor de correo selecciona el ID-Mensaje para cada mensaje. En un mapeo típico, la ID-Mensaje en la notificación puede contener el mismo valor que el campo de encabezamiento ID-Llamada en las solicitudes MESSAGE SIP o INVITE SIP (que iniciaron la sesión MSRP), o la ID-Mensaje en la notificación puede contener el mismo valor que el campo de encabezamiento ID-Mensaje en la solicitud SEND MSRP. Una vez que Carlos ha seleccionado el mensaje a recuperar, crea una solicitud INVITE (mensaje Nº 15) direccionada al mensaje específico a recuperar.
Hay dos alternativas y ejemplos de implementación similares de la primera realización:
Ejemplo de implementación A:
El servidor de correo copia el campo de encabezamiento ID-Llamada incluido en SIP al encabezamiento ID-Mensaje
del resumen del mensaje, o copia el encabezamiento ID-Mensaje de la solicitud SEND MSRP al encabezamiento ID-Mensaje del resumen de mensaje. Por lo tanto, cada MESSAGE SIP almacenado, sesión MSRP completa (que se ha iniciado mediante un INVITE SIP) o solicitud SEND MSRP individual se identifica únicamente mediante la ID-Mensaje. A continuación, cuando el usuario selecciona un mensaje particular a recuperar, desde el resumen de mensajes, se asigna al mensaje almacenado un URI SIP único que se crea tras el encabezamiento ID-Mensaje en el resumen de mensaje.
Esto permite recuperar mensajes uno por uno si se depositaron con una solicitud MESSAGE SIP. Si los mensajes se depositaron con una colección de solicitudes SEND MSRP (en una sesión INVITE-BYE), a continuación la solución permite recuperar todos los mensajes MSRP que fueron parte de la sesión identificada mediante la ID-Llamada del INVITE SIP, o cada solicitud SEND MSRP almacenada individual.
El siguiente es un ejemplo de la notificación de resumen de mensaje que recibe el usuario B. La notificación indica que dos nuevos mensajes de textos en espera de ser recuperados.
NOTIFY sip:carlos@pc.ejemplo.com SIP/2.0
Para: <sip:carlos@ejemplo.com>;tag=78923
De: <sip:servidordecorreo.ejemplo.com>;tag=4442
Fecha: Lun, 10 Jul 2000 04:28:53 GMT
Contacto: <sip:servidordecorreo.ejemplo.com>
ID-Llamada: adsf0923jsdjw
CSeq: 31 NOTIFY
Evento: resumen-mensajes
Estado-Suscripción: activo
Tipo-Contenido: aplicación/resumen-mensaje-simple
Tamaño-Contenido: 503
Mensajes-en-espera: sí
Cuenta-Mensaje: sip:carlos@servidordecorreo.ejemplo.com
Mensaje-Texto: 2/0 (1/0)
Para: <carlos@ejemplo.com>
De: <alicia@ejemplo.org>
Asunto: ¿compartimos coche mañana?
Fecha: Dom, 09 Jul 2000 21:23:01 -0700
Prioridad: normal
Para: <carlos@ejemplo.com>
De: <bob@ejemplo.com>
Asunto: ¡AYUDA! Enfermo en cada, regalo para mí por favor
Fecha: Dom, 09 Jul 2000 21:25:12 -0700 Prioridad: urgente
ID-Mensaje: d0982dkjs@bobmobile.ejemplo.com
Se supone que Carlos quiere recuperar únicamente el segundo mensaje, que se ha enviado mediante bob@ejemplo.com y se identifica mediante un encabezamiento ID-Mensaje cuyo valor es d0982dkjs@bobmobile.ejemplo.com. A continuación Carlos crea una solicitud INVITE SIP direccionada a un URI SIP (cuyo formato general es “sip:nombre-de-usuario@nombredeanfitrión”) compuesto como sigue:
- -
- El valor escapado del ID-Mensaje seleccionado, como el nombre de usuario en el URI
- -
- El nombre de anfitrión del servidor de correo (esto se preconfigura normalmente en el Agente de Usuario SIP).
Es decir, el usuario (es decir Carlos) mapea el identificador único mensaje instantáneo almacenado en un identificador válido para recuperar. Continuando con el ejemplo, Carlos crea una solicitud INVITE SIP (por ejemplo mensaje Nº 15 en la Figura 4) cuya
URI-Solicitud es:
sip:d0982dkjs%40bobmobile.ejemplo.com@servidordecorreo.ejemplo.com El “%40” es el carácter escapado que corresponde a un signo “@” (esto es una práctica convencional en SIP). Por ejemplo, el usuario (es decir Carlos) enviará el siguiente INVITE (únicamente se imprimen encabezamientos
relevantes) al servidor de correo de voz (el AS de almacén de mensajes) en el mensaje Nº 15. INVITE sip:d0982dkjs%40bobmobile.ejemplo.com@servidordecorreo.ejemplo.com SIP/2.0 De: <sip:carlos@ejemplo.com> Para: <sip:d0982dkjs%40bobmobile.ejemplo.com@servidordecorreo.ejemplo.com>
Esta solicitud INVITE se enruta al servidor de correo (el AS de almacén de mensajes) de acuerdo con procedimientos SIP regulares. El servidor de correo extrae el “nombre de usuario”, lo desescapa para obtener la ID de mensaje original, recupera ese mensaje y lo envía a Carlos. Con este fin, se pueden aplicar los mecanismos
descritos en la solicitud de patente provisional “Procedimiento y Aparato para Mensajería Instantánea”.
Por ejemplo, el AS de almacén de mensajes toma el mensaje Nº 3 INVITE SIP almacenado en la Figura 4, las solicitudes Nº 5 y Nº 7 SEND MSRP almacenadas y el mensaje Nº 9 BYE SIP almacenado y los encapsula en una solicitud SEND MSRP (no mostrado), también con el tipo de mensaje establecido a mensaje/sip (Sección 27.5 del documento RFC 3261) o mensaje/sipfrag (documento RFC 3420).
Ejemplo de implementación B: Esta implementación es esencialmente la misma que A. La única diferencia es que el servidor de correo rellena el encabezamiento ID-Mensaje, no con el valor del encabezamiento ID-Llamada del MESSAGE SIP o INVITE que
depositó el mensaje instantáneo, sino en su lugar, con un URI único que apunta al servidor de correo e identifica el mensaje. Por ejemplo, lo siguiente es la misma solicitud NOTIFY como se indicó con el ejemplo de implementación A, pero
modificada para el ejemplo de implementación B: NOTIFY sip:carlos@pc.ejemplo.com SIP/2.0 Para: <sip:charlie@example.com>;tag=78923 De: <sip:servidordecorreo.ejemplo.com>;tag=4442 Fecha: Lun, 10 Jul 2000 04:28:53 GMT Contacto: <sip:servidordecorreo.ejemplo.com> ID-Llamada: adsf0923jsdjw CSeq: 31 NOTIFY Evento: resumen-mensaje
Estado-Suscripción: activo
Tipo-Contenido: aplicación/resumen-mensaje-simple
Tamaño-Contenido: 503
Mensajes-En-espera: sí
5 Cuenta-Mensaje: sip:carlos@servidordecorreo.ejemplo.com
Mensaje-Texto: 2/0 (1/0)
Para: <carlos@ejemplo.com>
De: <alicia@ejemplo.org>
Asunto: ¿compartimos coche mañana?
10 Fecha: Dom, 09 Jul 2000 21:23:01 -0700 Prioridad: normal
Para: <carlos@ejemplo.com>
De: <bob@ejemplo.com>
15 Asunto: ¡AYUDA! Enfermo en cada, regalo para mí por favor Fecha: Dom, 09 Jul 2000 21:25:12 -0700 Prioridad: urgente
ID-Mensaje: 120933@servidordecorreo.ejemplo.com
De modo que, si Carlos quiere recuperar el mismo segundo mensaje entregado por Bob, creará una solicitud INVITE
20 direccionada al valor del ID-Mensaje asignado mediante el servidor de correo a ese mensaje, que identificará únicamente el mensaje en el servidor. En esta alternativa, no hay necesidad de traducir el ID-Mensaje recibido a otra cosa, antes de crear la URI-Solicitud del mensaje SIP, es decir, se copia el valor del ID-Mensaje del mensaje a recuperar a la URI-Solicitud de la solicitud SIP.
INVITE sip:120933@servidordecorreo.ejemplo.com SIP/2.0
25 De: <sip:carlos@ejemplo.com>
Para: <sip:120933@servidordecorreo.ejemplo.com>
Segunda realización
De manera similar a lo anterior se supone que el usuario ha estado fuera de línea durante algún tiempo, y algunos otros usuarios han depositado uno o más mensajes instantáneos en el AS de almacén de mensajes, normalmente 30 usando una combinación de SIP (Protocolo de Iniciación de Sesión, documento RFC 3261) y MSRP (Protocolo de Retransmisión de Sesión de Mensaje, Borrador-Internet borrador-ietf sesiones-mensaje-simple-12.txt) como protocolos. Cuando el usuario vuelve a estar en línea (se conecta a la red) el usuario puede recuperar todos los mensajes instantáneos almacenados, por ejemplo, aplicando los mecanismos descritos en la solicitud de patente provisional “Procedimiento y Aparato para Mensajería Instantánea”. Sin embargo, este mecanismo funciona en
35 TODOS los mensajes instantáneos almacenados.
La primera realización anteriormente descrita permite al usuario seleccionar uno y exactamente un mensaje instantáneo para recuperar (si el mensaje se entregó con una solicitud MESSAGE SIP), una y exactamente una sesión de mensajes instantáneos (si se depositaron usando INVITE SIP y un número de solicitudes SEND MSRP), o uno y exactamente un mensaje SEND MSRP. Este mecanismo presenta un problema si el usuario quiere recuperar
40 más de un mensaje instantáneo o más de una sesión de mensajes instantáneos o más de un (pero no todos) mensajes SEND MSRP que pertenecen a la misma sesión, debido a que para acción de recuperación el usuario tiene que establecer una sesión SIP separada (es decir, el usuario tiene que enviar una solicitud INVITE SIP separada) al servidor de correo.
Esto obviamente presenta problemas, especialmente en entornos móviles. Por un lado, crea retardos entre 45 mensajes recuperados consecutivos, debido a la adición de 1,5 idas y vueltas (INVITE-200-ACK) del flujo de señalización. Adicionalmente, cada una de estas solicitudes INVITE podría contener un gran número de encabezamientos, de modo que el número de bytes transferidos entre el agente de usuario y el servidor de correo no es insignificante.
De acuerdo con la segunda realización se supone que:
- -
- Los mensajes instantáneos direccionados a un usuario particular se han depositado en un servidor de correo.
- -
- Hay un mecanismo en su lugar mediante el que se informa al usuario de un resumen de los mensajes instantáneos pendientes de recuperar. Este mecanismo incluye un identificador único de cada mensaje en el servidor de correo. Un ejemplo de un mecanismo de este tipo se describe en el documento RFC 3842, “Un Resumen de Mensaje y Paquete de Evento de Indicación de Espera de Mensaje para el Protocolo de Iniciación
de Sesión (SIP)”.
- -
- Hay un mecanismo que permite al usuario mapear el identificador único de los mensajes instantáneos almacenados en un identificador válido para recuperar. Se describe un ejemplo de un mecanismo de este tipo en la primera realización.
- -
- Hay un mecanismo por el que el usuario puede establecer una sesión para recuperar uno o más mensajes instantáneos almacenados. Se describe un ejemplo de un mecanismo de este tipo en la solicitud de patente
provisional “Procedimiento y Aparato para Mensajería Instantánea”.
De acuerdo con la segunda realización, se modela un AS de almacén de mensajes o servidor de correo anfitrión como una entidad virtual que comprende:
- -
- Un servidor distribuidor lista-URI para transacciones INVITE SIP, también conocido como un servidor de conferencia de acuerdo con el documento “Establecimiento de Conferencia Usando Listas de Solicitudes Contenidas en el Protocolo de Iniciación de Sesión (SIP)”, borrador-ietf-usando-sip-uri-lista-conferencia-03.txt, el contenido del cual se incorpora en el presente documento por referencia.
- -
- Uno más Agentes de Usuario SIP virtuales, también contenidos en el mismo servidor de correo anfitrión. Cada uno de estos Agentes de Usuario SIP virtuales representa un recurso, que en el caso de la invención, es efectivamente un mensaje instantáneo almacenado o sesión de mensajes instantáneos. Una característica es que se identifica cada mensaje instantáneo o sesión de mensajes instantáneos mediante un identificador de recurso uniforme (URI) único.
La Figura 5 muestra esquemáticamente el modelo del servidor de correo anfitrión (servidor de correo de mensajes instantáneos), que integra un servidor de conferencia y un número de Agentes de Usuario SIP virtuales, representando cada uno un mensaje instantáneo almacenado.
La Figura 6 muestra un diagrama de señalización que ilustra mensajes intercambiados entre un usuario y el servidor de correo de mensajes instantáneos de acuerdo con la segunda realización.
Habiendo modelado el servidor de correo como se ha indicado, cuando un usuario quiere recuperar una selección de mensajes instantáneos almacenados estableciendo una sola sesión SIP, el agente de usuario envía una sola solicitud INVITE SIP (mensaje Nº 1) que contiene dos cuerpos de mensaje: el Protocolo de Descripción de Sesión (documento RFC 2327) para establecer la sesión de mensaje instantáneo, y una lista-URI (como se indica en el borrador-ietf-usando-sip-lista-uri-conferencia-03.txt). El SDP indica la disposición para establecer al menos un flujo de medios de mensaje basándose en MSRP (borrador-ietf-sesiones-mensaje-simple-12.txt). La lista-URI contiene uno o más URI, identificando cada uno únicamente un mensaje instantáneo almacenado en el servidor que el usuario quiere recuperar. El servidor de correo contesta con una respuesta OK 200 (mensaje Nº 2) que contiene SDP que indica un flujo de medios de mensaje basándose en MSRP.
Al recibir una solicitud INVITE de este tipo, el servidor de conferencia parte del servidor de correo distribuye la solicitud INVITE a cada uno de los Agentes de Usuario SIP virtuales que identifican el mensaje almacenado. El servidor de conferencia envía una solicitud INVITE que incluye SDP para cada uno de los URI indicados en la lista URI del INVITE entrante. En otras palabras, el servidor de conferencia del servidor de correo envía una solicitud INVITE a cada uno de los URI contenidos en la lista-URI del INVITE (Nº 1). Estas son las solicitudes INVITE Nº 4, Nº 5 y Nº 6 en la Figura 6. Cada una de las cuales contiene un cuerpo SDP que indica la disposición para establecer al menos un flujo de medios de mensaje basándose en MSRP.
Esto crea una conferencia centralizada virtual entre el usuario final y cada uno de los Agentes de Usuario SIP virtuales que identifica un mensaje dado. A continuación cada uno de estos Agentes de Usuario SIP virtuales envía el mensaje instantáneo almacenado al servidor de conferencia, que a su vez, los retransmite al usuario final. En otras palabras, los Agentes de Usuario SIP virtuales contestan con un mensaje OK 200 que contiene su propio SDP (mensajes Nº 7, Nº 8 y Nº 9 en la Figura 6), y a continuación envía el mensaje almacenado (o sesión de mensajes instantáneos), por ejemplo, aplicando los procedimientos indicados en la solicitud de patente provisional “Procedimiento y Aparato para Mensajería Instantánea” (esto corresponde para el resto de los mensajes Nº 13 a Nº 24 en la Figura 6).
En particular, cada agente de usuario SIP virtual puede tomar el MESSAGE almacenado, mantener los encabezamientos relevantes de las solicitudes MESSAGE SIP (por ejemplo, De, Para, ID-Llamada, P-Identidad-Confirmada, etc.), los encapsula como un mensaje/sip (Sección 27.5 del documento RFC 3261) o mensaje/sipfrag (documento RFC 3420), y lo envía como la carga útil de una solicitud SEND MSRP (mensajes Nº 13, Nº 17, Nº 21 en la Figura 6).
De manera similar, cada agente de usuario SIP virtual puede tomar el mensaje INVITE SIP almacenado, las solicitudes SEND MSRP almacenadas correspondientes y el mensaje BYE SIP almacenado correspondiente y encapsularlos en otra solicitud SEND MSRP (mensajes Nº 13, Nº 17, Nº 21), también con el tipo de mensaje establecido a mensaje/sip o mensaje/sipfrag. De manera similar, cada agente de usuario SIP virtual puede tomar la solicitud SEND MSRP almacenada, encapsularla como un mensaje/msrp, y enviarla como la carga útil de una solicitud SEND MSRP (Nº 13, Nº 17, Nº 21).
La invención cubre todas las posibles combinaciones y permutaciones. Por ejemplo, la solicitud Nº 13 SEND MSRP puede encapsular una solicitud SEND MSRP almacenada, mientras que la solicitud Nº 15 SEND MSRP puede encapsular una solicitud MESSAGE SIP, o la solicitud Nº 17 SEND MSRP puede encapsular una solicitud INVITE SIP que incluye todas las solicitudes SEND MSRP como parte de esa sesión y una solicitud BYE SIP.
Una vez que un UA SIP virtual ha entregado su mensaje instantáneo almacenado al servidor, envía una solicitud BYE (mensajes Nº 25, Nº 27 y Nº 29 en la Figura 6) al servidor de conferencia para finalizar la sesión. Una vez que se ha desconectado el último UA SIP virtual, el servidor de conferencia envía una solicitud BYE (mensaje Nº 31) al usuario para finalizar la sesión.
Al final, el usuario final ha recuperado una selección de los mensajes instantáneos almacenados en solamente una sesión de señalización.
Debe observarse que se considera que el servidor de correo se compone de un servidor de conferencia y un número de Agentes de Usuario SIP virtuales, representando cada uno un mensaje instantáneo almacenado. Se considera una implementación monolítica del servidor de correo, que se descompone adicionalmente para mejor entendimiento. Sin embargo, esto no impone una restricción de una implementación, y se pueden decidir implementaciones para separar cada uno de los componentes del servidor de correo en diferentes anfitriones. En tal caso, se usa la expresión “servidor de correo” para referirse a la colección de estos anfitriones.
Debe observarse también que, en el caso de la implementación monolítica del servidor de correo, las interfaces que se definen entre el servidor de conferencia y cada uno de los Agentes de Usuario virtuales SIP se vuelven llamadas internas o una API definida, pero no necesariamente se necesitan implementar con SIP.
Es importante observar que las realizaciones de la invención son también aplicables a mecanismos de entrega “de tipo push” de mensaje fuera de línea. En sistemas de entrega de tipo push, el servidor de aplicación de almacén de mensajería conoce cuándo un usuario fuera de línea vuelve a en línea, es decir, mediante NOTFIY/SUBSCRIBE SIP y/o cualquier otro mecanismo.
Debe entenderse que la descripción anterior es ilustrativa de la invención y no se debe interpretar como que limita la invención, a los expertos en la materia se les pueden ocurrir diversas modificaciones y aplicaciones sin alejarse del alcance de la invención como se define por las reivindicaciones adjuntas.
Claims (24)
- REIVINDICACIONES1. Un dispositivo terminal (10) que comprende:medios (11) para recibir un resumen de mensajes pendientes de recuperar por un usuario, cada mensaje asociado con un identificador único;medios (12) para seleccionar al menos uno de los mensajes a recuperar, basándose en el resumen de mensajes;medios (13) para determinar un identificador válido para recuperar el al menos un mensaje basándose en el identificador único asociado con el al menos un mensaje, obteniendo de esta manera al menos un identificador válido para recuperar; ymedios (14) para enviar una solicitud de recuperación con el al menos un identificador válido para recuperar, estableciendo la solicitud de recuperación una sesión para entregar el al menos un mensaje al usuario;caracterizado porquelos mensajes pendientes de recuperar son mensajes instantáneos,se ha interceptado y almacenado una secuencia de mensajes de protocolo de iniciación de sesión relacionados con los mensajes instantáneos, respectivamente, mediante un servidor de aplicación,la solicitud de recuperación es un mensaje invite de protocolo de iniciación de sesión, yen respuesta a la solicitud de recuperación se configuran los medios de recepción para recibir mensajes de protocolo de iniciación de sesión encapsulados de los mensajes de protocolo de iniciación de sesión almacenados mediante el servidor de aplicación, que están relacionados con el al menos un mensaje.
-
- 2.
- El dispositivo terminal de la reivindicación 1, en el que el identificador único es un identificador de mensaje.
-
- 3.
- El dispositivo terminal de la reivindicación 1, en el que el identificador único es un Identificador de Recurso Uniforme (URI).
-
- 4.
- Un dispositivo de red (20) para almacenar mensajes pendientes de recuperar por un usuario, comprendiendo el dispositivo de red:
medios de recepción (21) para recibir una solicitud de recuperación con al menos un identificador válido para recuperar al menos un mensaje de los mensajes almacenados, estableciendo la solicitud de recuperación una sesión para entregar el al menos un mensaje al usuario; ymedios de envío (22) para enviar el al menos un mensaje al usuario que origina la solicitud de recuperación en la sesión, estando el dispositivo de red caracterizado porquelos mensajes pendientes de recuperar son mensajes instantáneos;el dispositivo de red (20) de está adaptado para interceptar y almacenar una secuencia de mensajes de protocolo de iniciación de sesión relacionados con los mensajes instantáneos, respectivamente;la solicitud de recuperación es un mensaje invite del protocolo de iniciación de sesión; ylos medios de envío (22), para enviar el al menos un mensaje al usuario que origina la solicitud de recuperación en la sesión, están configurados para encapsular y enviar mensajes de protocolo de iniciación de sesión de los mensajes de protocolo de iniciación de sesión almacenados, que están relacionados con el al menos un mensaje, en respuesta al mensaje invite del protocolo de iniciación de sesión. -
- 5.
- El dispositivo de red de la reivindicación 4, en el que los medios de envío se configuran para enviar el al menos un mensaje en un mensaje SEND del Protocolo de Retransmisión de Sesión de Mensaje (MSRP).
-
- 6.
- El dispositivo de red de la reivindicación 4, que comprende adicionalmente:
medios de provisión (23) para proporcionar un identificador de mensaje para cada uno de los mensajes almacenados, en los quelos medios de envío están configurados para enviar un resumen de los mensajes almacenados al usuario, estando asociado cada mensaje con el identificador de mensaje proporcionado. -
- 7.
- El dispositivo de red de la reivindicación 6, en el que los medios de provisión están configurados para usar un campo de encabezamiento ID-Llamada incluido en una solicitud de Protocolo de Iniciación de Sesión para cada uno
de los mensajes almacenados para el identificador de mensaje proporcionado. -
- 8.
- El dispositivo de red de la reivindicación 6, en el que los medios de provisión están configurados para usar un campo de encabezamiento ID-Mensaje de una solicitud del Protocolo de Retransmisión de Sesión de Mensaje para cada uno de los mensajes almacenados para el identificador de mensaje proporcionado.
-
- 9.
- El dispositivo de red de la reivindicación 6, en el que los medios de provisión están configurados para generar un Identificador de Recurso Uniforme (URI) único, siendo el URI enrutable al dispositivo de red y en el que el identificador de mensaje proporcionado es parte del URI.
-
- 10.
- Un procedimiento para recuperar mensajes pendientes de recuperar por un usuario, comprendiendo el procedimiento:
recibir (S31) un resumen de los mensajes almacenados en el servidor de correo y pendientes de recuperar por el usuario, estando asociado cada mensaje con un identificador único;seleccionar (S32) al menos un mensaje de los mensajes a recuperar desde el servidor de correo, basándose en el resumen de mensajes;determinar (S33) un identificador válido para recuperar el al menos un mensaje basándose en el identificador único asociado con el al menos un mensaje, obteniendo de esta manera al menos un identificador válido para recuperar; yenviar (S34) una solicitud de recuperación con el al menos un identificador válido para recuperar, estableciendo la solicitud de recuperación una sesión para entregar el al menos un mensaje al usuario,caracterizado porquelos mensajes pendientes de recuperar son mensajes instantáneos,se ha interceptado y almacenado una secuencia de mensajes de protocolo de iniciación de sesión relacionados con los mensajes instantáneos, respectivamente, mediante un servidor de aplicación,la solicitud de recuperación es un mensaje invite del protocolo de iniciación de sesión, yen respuesta a la solicitud de recuperación se reciben mensajes de protocolo de iniciación de sesión encapsulados de los mensajes de protocolo de iniciación de sesión almacenados mediante el servidor de aplicación, que están relacionados con el al menos un mensaje. -
- 11.
- El procedimiento de la reivindicación 10, en el que el identificador único es un identificador de mensaje.
-
- 12.
- El procedimiento de la reivindicación 10, en el que el identificador único es un Identificador de Recurso Uniforme (URI).
-
- 13.
- Un procedimiento para recuperar mensajes almacenados pendientes de recuperar por un usuario, comprendiendo el procedimiento:
recibir (S41) una solicitud de recuperación con al menos un identificador válido para recuperar al menos un mensaje de los mensajes almacenados, estableciendo la solicitud de recuperación una sesión para entregar el al menos un mensaje al usuario; yenviar (S42) el al menos un mensaje al usuario que origina la solicitud de recuperación en la sesión,caracterizado porquelos mensajes pendientes de recuperar son mensajes instantáneos,se ha interceptado y almacenado una secuencia de mensajes de protocolo de iniciación de sesión relacionados con los mensajes instantáneos, respectivamente,la solicitud de recuperación es un mensaje invite del protocolo de iniciación de sesión, ypara enviar (S42) el al menos un mensaje al usuario que origina la solicitud de recuperación en la sesión, se encapsulan y envían mensajes de protocolo de iniciación de sesión de los mensajes de protocolo de iniciación de sesión almacenados, que están relacionados con el al menos un mensaje, en respuesta al mensaje invite del protocolo de iniciación de sesión. -
- 14.
- El procedimiento de la reivindicación 13, que comprende adicionalmente: proporcionar un identificador de mensaje para cada uno de los mensajes almacenados; y
enviar un resumen de los mensajes almacenados al usuario, cada mensaje asociado con el identificador de mensaje proporcionado. -
- 15.
- El procedimiento de la reivindicación 13, en el que se envía el al menos un mensaje en un mensaje SEND del Protocolo de Retransmisión de Sesión de Mensaje (MSRP).
-
- 16.
- El procedimiento de la reivindicación 14, en el que se usa un campo de encabezamiento ID-Llamada incluido en una solicitud del Protocolo de Iniciación de Sesión de cada uno de los mensajes almacenados para el identificador de mensaje proporcionado.
-
- 17.
- El procedimiento de la reivindicación 14, en el que se usa un campo de encabezamiento ID-Mensaje de una solicitud de Protocolo de Retransmisión de Sesión de Mensaje de cada uno de los mensajes almacenados para el identificador de mensaje proporcionado.
-
- 18.
- El procedimiento de la reivindicación 14, que comprende:
generar un Identificador de Recurso Uniforme (URI) único, siendo el URI enrutable a un dispositivo de red que almacena los mensajes pendientes de recuperar por el usuario, en el que el identificador de mensaje proporcionado es parte del URI. -
- 19.
- Un dispositivo de red para almacenar mensajes instantáneos pendientes de recuperar por un usuario, comprendiendo el dispositivo de red:
un servidor de conferencia; ypuntos finales virtuales que corresponden a los mensajes instantáneos almacenados;en el que el servidor de conferencia está configurado para recibir una solicitud de recuperación desde el usuario que comprende una lista de identificadores cada uno apuntando a un mensaje seleccionado de los mensajes instantáneos almacenados, estableciendo la solicitud de recuperación una primera sesión del protocolo de iniciación de sesión para entregar los mensajes seleccionados, para establecer segundas sesiones para cada uno de los mensajes seleccionados identificados en la lista con los puntos finales virtuales que corresponden a los mensajes seleccionados, y para recibir los mensajes seleccionados en dichas segundas sesiones y reenviar los mensajes seleccionados al usuario en dicha primera sesión de la sesión del protocolo de iniciación de sesión. -
- 20.
- El dispositivo de red de la reivindicación 19, en el que los puntos finales virtuales son Agentes de Usuario del Protocolo de Iniciación de Sesión (SIP).
-
- 21.
- Un procedimiento para recuperar mensajes instantáneos almacenados en un servidor de correo y pendientes de recuperar por un usuario, comprendiendo el procedimiento:
recibir una solicitud de recuperación desde el usuario que comprende una lista de identificadores cada uno apuntando a un mensaje seleccionado de los mensajes instantáneos almacenados, estableciendo la solicitud de recuperación una primera sesión del protocolo de iniciación de sesión para entregar los mensajes seleccionados,establecer segundas sesiones para cada uno de los mensajes seleccionados identificados en la lista con los puntos finales virtuales que corresponden a los mensajes seleccionados; yrecibir los mensajes seleccionados en dichas segundas sesiones y reenviar los mensajes seleccionados al usuario en dicha primera sesión del protocolo de iniciación de sesión. -
- 22.
- Un producto de programa informático que incluye un programa para un dispositivo de procesamiento, que comprende porciones de código de software para realizar las etapas de una cualquiera de las reivindicaciones 10 a 18 o 21 cuando se ejecuta el programa en el dispositivo de procesamiento.
-
- 23.
- El producto de programa informático de acuerdo con la reivindicación 22, en el que el producto de programa informático comprende un medio legible por ordenador en el que se almacenan porciones de código software.
-
- 24.
- El producto de programa informático de acuerdo con la reivindicación 22, en el que el programa se carga directamente en una memoria interna del dispositivo de procesamiento.
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US350088 | 1982-02-18 | ||
US72787005P | 2005-10-19 | 2005-10-19 | |
US727870P | 2005-10-19 | ||
US11/350,088 US9258259B2 (en) | 2005-09-30 | 2006-02-09 | Retrieval of offline instant messages |
PCT/IB2006/053769 WO2007046046A1 (en) | 2005-10-19 | 2006-10-13 | Retrieval of offline instant messages |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2403188T3 true ES2403188T3 (es) | 2013-05-16 |
Family
ID=37769349
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES06809590T Active ES2403188T3 (es) | 2005-10-19 | 2006-10-13 | Recuperación de mensajes instantáneos fuera de línea |
Country Status (9)
Country | Link |
---|---|
US (1) | US9258259B2 (es) |
EP (1) | EP1938536B1 (es) |
JP (1) | JP2009512931A (es) |
KR (1) | KR100966959B1 (es) |
DK (1) | DK1938536T3 (es) |
ES (1) | ES2403188T3 (es) |
PL (1) | PL1938536T3 (es) |
PT (1) | PT1938536E (es) |
WO (1) | WO2007046046A1 (es) |
Families Citing this family (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7561595B2 (en) * | 2005-09-30 | 2009-07-14 | Nokia Corporation | Method and apparatus for instant messaging |
CN100514968C (zh) | 2005-10-11 | 2009-07-15 | 华为技术有限公司 | 离线消息的处理方法和即时消息服务器 |
US20070115926A1 (en) * | 2005-10-27 | 2007-05-24 | 3Com Corporation | System and method for receiving a user message at a packet-network telephone |
WO2007048448A1 (en) * | 2005-10-28 | 2007-05-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Media sharing |
US7917590B2 (en) * | 2006-03-13 | 2011-03-29 | Nokia Corporation | Deleting mechanism in SIP multimedia services |
MX2008012811A (es) * | 2006-04-03 | 2008-10-15 | Nokia Corp | Mecanismo de supresion en servicios multimedia sip. |
JP4910542B2 (ja) * | 2006-07-27 | 2012-04-04 | 富士通株式会社 | Sipメッセージ引渡プログラム |
CN101207577B (zh) * | 2006-12-19 | 2011-04-13 | 华为技术有限公司 | 消息系统间的互连方法及消息互连网关 |
US8606861B2 (en) | 2007-04-27 | 2013-12-10 | Cellco Partnership | Method, apparatus, and computer program product for reducing session related message size |
CN101110792A (zh) * | 2007-08-08 | 2008-01-23 | 腾讯科技(深圳)有限公司 | 一种即时通信终端中管理会话消息的系统和方法 |
WO2009064226A1 (en) * | 2007-11-16 | 2009-05-22 | Telefonaktiebogalet Lm Ericsson (Publ) | A method for event packet handling |
EP2324460B1 (en) * | 2008-08-12 | 2013-06-19 | Google, Inc. | Touring in a geographic information system |
JP5522985B2 (ja) * | 2009-06-30 | 2014-06-18 | パナソニック株式会社 | 通信装置、通信システム及びセッション制御方法 |
US20110053565A1 (en) * | 2009-08-26 | 2011-03-03 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for delivering a message digest |
US8495153B1 (en) * | 2009-12-14 | 2013-07-23 | Emc Corporation | Distribution of messages in nodes connected by a grid architecture |
CN101895842B (zh) * | 2010-08-09 | 2014-06-04 | 华为终端有限公司 | 一种唤醒离线移动终端的方法、装置和系统 |
CN101964717A (zh) * | 2010-10-18 | 2011-02-02 | 苏州阔地网络科技有限公司 | 一种基于即时通群组发起会议的方法 |
US8861509B2 (en) * | 2011-06-27 | 2014-10-14 | Intel Mobile Communications GmbH | Communication devices and methods for generating a message |
ES2751133T3 (es) * | 2011-06-29 | 2020-03-30 | Orange | Motor de notificaciones |
CN103369121B (zh) * | 2012-04-09 | 2015-10-28 | 腾讯科技(深圳)有限公司 | 未读消息显示方法和装置 |
CN104518953B (zh) * | 2013-09-30 | 2019-12-24 | 腾讯科技(深圳)有限公司 | 删除消息的方法、即时通信终端及系统 |
CN103812762B (zh) * | 2013-11-27 | 2017-12-01 | 大唐移动通信设备有限公司 | 一种发送即时消息的方法和系统 |
US9871753B2 (en) | 2015-04-08 | 2018-01-16 | Blackberry Limited | Method, device and system for distinct forwarding of a plurality of messages selected as a group |
US10649609B2 (en) * | 2016-03-31 | 2020-05-12 | Microsoft Technology Licensing, Llc | Universal notification pipeline |
US11005802B1 (en) * | 2020-06-25 | 2021-05-11 | Sony Corporation | Importance determination for undelivered messages |
CN115002137B (zh) * | 2022-08-03 | 2022-10-21 | 广州此声网络科技有限公司 | 离线消息处理方法、装置、计算机设备和存储介质 |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5923848A (en) * | 1996-05-31 | 1999-07-13 | Microsoft Corporation | System and method for resolving names in an electronic messaging environment |
US6052709A (en) * | 1997-12-23 | 2000-04-18 | Bright Light Technologies, Inc. | Apparatus and method for controlling delivery of unsolicited electronic mail |
US5999932A (en) * | 1998-01-13 | 1999-12-07 | Bright Light Technologies, Inc. | System and method for filtering unsolicited electronic mail messages using data matching and heuristic processing |
US6493007B1 (en) * | 1998-07-15 | 2002-12-10 | Stephen Y. Pang | Method and device for removing junk e-mail messages |
US6728714B1 (en) * | 1999-11-30 | 2004-04-27 | International Business Machines Corporation | System and method for assigning unique identifier to deleted unopened original sender e-mail after delivery |
US6981041B2 (en) * | 2000-04-13 | 2005-12-27 | Aep Networks, Inc. | Apparatus and accompanying methods for providing, through a centralized server site, an integrated virtual office environment, remotely accessible via a network-connected web browser, with remote network monitoring and management capabilities |
AU2001287177A1 (en) | 2000-08-11 | 2002-02-25 | The Trustees Of Columbia University In The City Of New York | System and method for unified messaging in inter/intranet telephony |
EP1322395B1 (en) * | 2000-09-13 | 2011-02-23 | Entegris, Inc. | Liquid filtration device |
US7174368B2 (en) * | 2001-03-27 | 2007-02-06 | Xante Corporation | Encrypted e-mail reader and responder system, method, and computer program product |
US7058687B2 (en) * | 2001-04-03 | 2006-06-06 | Sendmail, Inc. | E-mail system with methodology for accelerating mass mailings |
US7194252B1 (en) * | 2001-12-13 | 2007-03-20 | Bellsouth Intellectual Property Corp. | Remote electronic mailbox access |
JP2004342098A (ja) | 2003-04-25 | 2004-12-02 | Daiwa Securities Group Inc | 情報配信システム、方法及びプログラム |
WO2004100581A1 (en) | 2003-05-08 | 2004-11-18 | Vimplicity Ltd. | Methods and systems for instant voice messaging and instant voice message retrieval |
JP2005073160A (ja) | 2003-08-27 | 2005-03-17 | Nippon Telegr & Teleph Corp <Ntt> | セッション制御方法及びシステム装置 |
JP4264016B2 (ja) | 2004-03-22 | 2009-05-13 | 株式会社日立製作所 | 通信制御装置及び通信制御装置におけるフィルタリング方法 |
ATE472879T1 (de) * | 2005-03-24 | 2010-07-15 | Ericsson Telefon Ab L M | Verfahren und anordnung in einem kommunikationssystem zum abliefern von nachrichten an einen empfänger |
US8533271B2 (en) * | 2006-02-10 | 2013-09-10 | Oracle International Corporation | Electronic mail recovery utilizing recorded mapping table |
-
2006
- 2006-02-09 US US11/350,088 patent/US9258259B2/en active Active
- 2006-10-13 ES ES06809590T patent/ES2403188T3/es active Active
- 2006-10-13 PT PT68095900T patent/PT1938536E/pt unknown
- 2006-10-13 JP JP2008536181A patent/JP2009512931A/ja active Pending
- 2006-10-13 KR KR1020087009283A patent/KR100966959B1/ko active IP Right Grant
- 2006-10-13 PL PL06809590T patent/PL1938536T3/pl unknown
- 2006-10-13 WO PCT/IB2006/053769 patent/WO2007046046A1/en active Application Filing
- 2006-10-13 DK DK06809590.0T patent/DK1938536T3/da active
- 2006-10-13 EP EP06809590A patent/EP1938536B1/en active Active
Also Published As
Publication number | Publication date |
---|---|
WO2007046046A1 (en) | 2007-04-26 |
EP1938536B1 (en) | 2013-03-13 |
EP1938536A1 (en) | 2008-07-02 |
KR20080048078A (ko) | 2008-05-30 |
US9258259B2 (en) | 2016-02-09 |
PT1938536E (pt) | 2013-04-18 |
JP2009512931A (ja) | 2009-03-26 |
US20070078935A1 (en) | 2007-04-05 |
KR100966959B1 (ko) | 2010-06-30 |
PL1938536T3 (pl) | 2013-07-31 |
DK1938536T3 (da) | 2013-05-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2403188T3 (es) | Recuperación de mensajes instantáneos fuera de línea | |
US8478825B2 (en) | Method and arrangment in a communication system for delivering messages to a recipient | |
US10326721B2 (en) | Real-time messaging method and apparatus | |
ES2638588T3 (es) | Método y aparato para mensajería instantánea | |
JP5246332B2 (ja) | 拡張されたメッセージングプラットフォーム | |
US8990322B2 (en) | Archive control for text messages | |
US8832299B2 (en) | Using the addressing, protocols and the infrastructure of email to support real-time communication | |
US8688789B2 (en) | Progressive messaging apparatus and method capable of supporting near real-time communication | |
US8645477B2 (en) | Progressive messaging apparatus and method capable of supporting near real-time communication | |
US20090037539A1 (en) | Methods and Systems for Message Interworking | |
US20190280998A1 (en) | Real-time messaging method and apparatus | |
JP2014511075A (ja) | 国際化eメールシステムと非国際化eメールシステムとのメッセージ伝送 | |
JP2009086916A (ja) | メール仲介システムおよびメールシステム | |
US10419385B2 (en) | Systems and methods for use in transmitting electronic messages between different protocols | |
CA2746734C (en) | Email client capable of supporting near real-time communication and methods for using the addressing, protocols and the infrastructure of email to support near real-time communication | |
EP2391076A2 (en) | Method and device for real-time e-mail communication | |
AU2013202611B2 (en) | Method and device for near real-time communication |