ES2657498T3

ES2657498T3 - Mensajería en modo página

Info

Publication number: ES2657498T3
Application number: ES06755408.9T
Authority: ES
Inventors: Arto Leppisaari; Jari Mutikainen; Pekka Kuure; Adamu Haruna
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2005-06-06
Filing date: 2006-06-05
Publication date: 2018-03-05
Anticipated expiration: 2026-06-05
Also published as: FI20055288A0; JP5135421B2; US9288174B2; IL216991A; RU2410843C2; EP1889424A4; IL187751A; EP3300313A1; US7835345B2; US8351423B2; MY144805A; MX2007015286A; WO2006131597A1; TW200708017A; CN103023868A; US20110110365A1; IL216991A0; UA90144C2; CN101223746A; JP5504315B2

Abstract

Un método para enviar un mensaje en modo página, caracterizado por comprender el método: crear, mediante un aparato, en respuesta al tamaño de mensaje en modo página que excede un límite predeterminado (203), una invitación de sesión para un mecanismo de mensajería en modo sesión; añadir, mediante el aparato, a la invitación de sesión una indicación con un valor que indica a un receptor que el modo sesión es para un mensaje en modo página; enviar, mediante el aparato, la invitación de sesión con la indicación (6-2, 7-2, 8-2, 9-2); y enviar, mediante el aparato, usando el mensaje en modo página (205) el mecanismo de mensajería en modo sesión.

Description

5

10

15

20

25

30

35

40

45

50

55

60

65

DESCRIPCION

Mensajería en modo página Campo de la invención

La invención se refiere a mensajería y más particularmente a mensajería en modo página, también llamada mensajería de una sola vez.

Antecedentes de la invención

La evolución de la tecnología de comunicación, particularmente tecnología de comunicación basada en IP y terminales de usuario final, ha habilitado posibilidades de comunicación versátiles y la introducción de diferentes servicios. Más y más a menudo los servicios se implementan usando primitivas provistas mediante SIP (Protocolo de Iniciación de Sesión) que no se integran verticalmente en un sistema de comunicaciones sino una herramienta para construir una arquitectura multimedia. Más precisamente SIP es un protocolo de control (señalización) de capa de aplicación definida por IETF para crear, modificar y terminar sesiones con uno o más participantes. Estas sesiones incluyen llamadas telefónicas por Internet, distribución multimedia, conferencias multimedia y sesiones PoC (Pulsar para hablar por Celular), por ejemplo. Para servicios de mensajería, en IETF se define SIMPLE (SIP para Mensajería Instantánea y Extensiones de Aprovechamiento de Presencia) usando SIP e implementaciones existentes de SIP para proporcionar presencia y servicio de mensajería instantánea. OMA (Alianza Móvil Abierta) también define habilitador IM (Mensajería Instantánea) en protocolos SIP/SIMPLE. SIMPLE define dos modos de intercambio de mensaje instantáneo: modo página y modo sesión. El modo página usa método de SIP MESSAGE por el cual se envía un mensaje instantáneo en modo página y en el que, a un nivel de protocolo, un mensaje instantáneo posterior no está relacionado con el precedente: cada mensaje inmediato, incluso una respuesta a un mensaje previo, se considera como una transacción independiente. Por lo tanto, el método de SIP MESSAGE se parece a un correo electrónico convencional o servicio de mensajes cortos. El modo sesión usa SIP para la señalización y establecimiento de sesión y MSRP (Protocolo de Retransmisión de Sesión de Mensaje) para transportar una serie de mensajes instantáneos después de que se ha establecido una sesión. Por ejemplo, CAMPBELL J ROSENBERG R SPARKS DYNAMICSOFT P KYZIVAT CISCO SYSTEMS B: "Instant Message Sessions in SIMPLE draft-ietf- simple-message-session s-01; draft-ietf-simplemessage-sessions-01.txt", vol. simple, n.° 1, 30 de junio de 2003 (3006-2003) NETWORK WORKING GROUP INTERNET DRAFT, XX, XX, páginas 1-46, y CAMPBELL J ROSENBERG DYNAMICSOFT B: SDP Extensions for SIP Instant Message Sessions; draft-ietf-simple-im-sdp-00.txt", vol. simple, 13 de julio de 2001 () divulgan la utilización de método de SIP MESSaGe para sesiones y mensajes independientes para mensajes instantáneos. A continuación, la combinación se llama simplemente mecanismo MSRP. En otras palabras, un mecanismo MSRP proporciona mensajería tipo conversación, llamado mensajería en modo sesión.

Un problema surge cuando un usuario quiere enviar un mensaje en modo página grande. El método de SIP MESSAGE puede usar transporte o bien UDP o TCP. TCP proporciona un método de transporte fiable también para mensajes grandes, pero transporte TCP no siempre puede garantizarse para el método de SIP MESSAGE. Si se usa UDP para enviar un mensaje grande, paquetes mayores que el tamaño máximo de UDP se fragmentan y pueden no llegar en el orden correcto al receptor. Además, incluso si TCP pudiera garantizarse, queda otro problema relacionado con control de congestión. Ya que el método de SIP MESSAGE es parte de señalización de control de sesión SIP, un mensaje se envía y recibe usando el mismo recurso que el usado por la señalización SIP. Para un terminal de usuario esto significa que la señalización SIP actual puede bloquearse para el momento que el menaje grande se envía o recibe en el terminal de usuario. El anteriormente mencionado recurso para la señalización SIP puede ser un contexto PDP (Protocolo de Datos de Paquetes) de fin general o un contexto PDP de señalización especializado en caso de los sistemas GERAN (Red de Acceso de Radio GSM/EDGE) y/o UTRAN (UMTS Red de Acceso de Radio Terrestre), por ejemplo. En otros sistemas, el recurso puede ser un ancho de banda reservado o especializado para señalizar propósitos, por ejemplo. Además del bloqueo de la señalización SIP, puede surgir un problema adicional relacionado con carga de intermediarios SIP. Como un mensaje en modo página usa convencionalmente el método de SIP MESSAGE, todos los mensajes que usan el método de SIP MESSAGE se transmiten a través de los intermediarios SIP. Por lo tanto, los mensajes en modo página de gran tamaño transmitidos a través de los intermediarios SIP pueden provocar un fuerte descenso en el rendimiento de los intermediarios SIP, resultando tanto en bloqueo efectivo de toda la señalización SIP y disminución del rendimiento global de la red SIP. Por lo tanto, en algunos casos, el método de SIP MESSAGE no es viable para usar para un mensaje de gran tamaño.

Una solución es que cuando el tamaño de mensaje excede un cierto límite, en lugar del método de SIP MESSAGE se usa el mecanismo MSRP. Sin embargo, el mecanismo MSRP es para un servicio de mensajera en modo sesión, no para mensajería en modo página. Adicionalmente, mensajes en modo página recibidos pueden diferirse y se almacenan en un buzón de entrada de mensajería, de donde el usuario puede leer los mismos cuando es conveniente, pero en la mensajería en modo sesión un mensaje recibido se abre por el terminal de usuario y muestra al usuario para facilitar un dialogo. Por lo tanto, desde el punto de vista del receptor, no pueden recibirse mensajes en modo página cuando se usa el mecanismo MSRP.

5

10

15

20

25

30

35

40

45

50

55

60

65

Breve descripción de la invención

Un objetivo de la presente invención es proporcionar un método y un aparato para implementar el método para superar el anterior problema. Los objetivos de la invención se logran mediante métodos, terminales de usuario y un servidor que se caracterizan por lo que se indica en las reivindicaciones independientes. Realizaciones preferidas de la invención se divulgan en las reivindicaciones dependientes.

La invención se basa en darse cuenta del problema y resolver el mismo indicando si un mensaje enviado usando un mecanismo de mensajería en modo sesión (tipo conversación) es o no un mensaje en modo página y en respuesta al mensaje que es un mensaje en modo página, actuar como si se ha recibido usando un mecanismo de modo página o de acuerdo con instrucciones específicas definidas para un mensaje en modo página de este tipo. Por modo sesión se entiende que se usa un protocolo, tal como MSRP, que tiene por objeto el intercambio de una serie de mensajes. Por modo página se entiende que cada mensaje es una transacción independiente a un nivel de protocolo, es decir, un mensaje instantáneo posterior no está relacionado, al nivel de protocolo, con el precedente.

Una ventaja de la invención es que, usando la indicación, mensajes en modo página pueden recibirse como mensajes en modo página, incluso cuando se transmiten como mensajes en modo sesión. Otra ventaja es que puede evitarse el bloqueo de señalización SIP debido a mensajes grandes.

Breve descripción de los dibujos

A continuación, la invención se describirá en mayor detalle por medio de las realizaciones preferidas con referencia a los dibujos adjuntos, en los que

la Figura 1 muestra una arquitectura de sistema simplificada;

la Figura 2 es un diagrama de flujo que ilustra una funcionalidad de un terminal de usuario de acuerdo con una realización de la invención en un modo de envío;

las Figuras 3 y 4 son diagramas de flujo que ilustran una funcionalidad de un terminal de usuario de acuerdo con realizaciones de la invención en un modo de recepción;

las Figuras 5A a 5D ilustran ejemplos de mensajes SIP INVITE de acuerdo con realizaciones de la invención; y las Figuras 6, 7, 8 y 9 ilustran señalización de acuerdo con realizaciones de la invención.

Descripción detallada de algunas realizaciones

Las siguientes realizaciones son ilustrativas. Aunque la memoria descriptiva puede referirse a "un", "una" o "algunas" realización(es) en varias ubicaciones, esto no significa necesariamente que tal referencia es a la(s) misma(s) realización(es), o que la característica únicamente se aplica a una única realización. Características únicas de diferentes realizaciones también pueden combinarse para proporcionar otras realizaciones.

La presente invención es aplicable a cualquier terminal de usuario, servidores y/o a cualquier sistema de comunicaciones o cualquier combinación de diferentes sistemas de comunicaciones que es/son accesible/s mediante terminales de usuario y proporciona(n) servicios de mensajería, es decir enviar datos en un formato de mensaje desde una entidad a otra ya sea en casi tiempo real o en un buzón de correo. No existen limitaciones al formato de mensaje, ni al tipo de datos. Los datos pueden ser texto, voz, clips de video, multimedia, etc. El sistema de comunicaciones puede ser un sistema de comunicaciones fijo o un sistema de comunicaciones inalámbricas o un sistema de comunicaciones que utiliza tanto redes fijas como redes inalámbricas. Los protocolos usados, las especificaciones de sistemas de comunicaciones y terminales, especialmente en comunicaciones inalámbricas, se desarrollan rápidamente. Tal desarrollo puede requerir cambios adicionales a la invención. Por lo tanto, todas las palabras y expresiones deberían interpretarse ampliamente y se conciben para ilustrar, no restringir, la invención.

A continuación, la presente invención se describirá usando, como un ejemplo de un entorno de sistema en el que puede aplicarse la presente invención, un entorno de sistema muy simplificado que utiliza SIP y MSRP, sin restringir la invención a los mismos. Debería apreciarse que el sistema de comunicaciones y los nodos intermedios, tales como intermediarios, y otros protocolos usados por debajo o encima de SIP y MSRP, o protocolos correspondientes, son irrelevantes a la invención actual. Por lo tanto, no necesitan analizarse en más detalle en este punto. La presente invención esencialmente se refiere a una transmisión de mensaje en una capa de aplicación.

La Figura 1 es una arquitectura de sistema altamente simplificada mostrando únicamente un sistema de comunicaciones 1, dos terminales de usuario UT 2, 2' y una red 3. Es evidente a un experto en la materia que el(los) sistema(s) también comprende(n) otros dispositivos, entidades de sistemas, tales como servidores de mensajería instantánea, funciones y estructuras, que no necesitan describirse en detalle en este documento.

Un terminal de usuario 2, 2' es una pieza de equipo o un dispositivo que permite que un usuario interactúe con un sistema de comunicaciones directamente o a través de un sistema informático, es decir, presenta información al usuario y permite que el usuario introduzca información, es decir el terminal de usuario es un punto de terminación de una comunicación particular. En otras palabras, el terminal de usuario 2, 2' puede ser cualquier nodo o un

5

10

15

20

25

30

35

40

45

50

55

60

65

anfitrión que soporta mensajería y es capaz de comunicarse con una red del sistema, en una red de acceso (no mostrada en la Figura 1) si existe una red de acceso de este tipo. El terminal de usuario 2, 2' puede ser un aparato no móvil, tal como un ordenador personal PC, conectado a la red 3 inalámbricamente o a través de una conexión fija. El terminal de usuario 2, 2' también puede ser un terminal móvil inalámbrico que soporta mensajería, un terminal de múltiples servicios que sirve como una plataforma de servicio y soporta la carga y ejecución de diferentes funciones relacionadas con servicio o un PC portátil, conectable a la red (a través de una posible red de acceso), un asistente digital personal PDA, conectable a la red (a través de la posible red de acceso), etc.

El terminal de usuario 2 comprende al menos una interfaz de usuario (UI) 21 a través de la que el usuario puede crear y/o leer mensajes, una o más aplicaciones de mensajería (Appl) 22, memoria (Mem) 23 (o el terminal de usuario se dispone para tener acceso a la memoria) para almacenar recibidos mensajes de tipo modo página al menos temporalmente y un transceptor (TRx) 24 para enviar y recibir comunicaciones (mensajes).

La aplicación de mensajería 22 puede ser una aplicación de software configurada para implementar una funcionalidad de acuerdo con la invención. La funcionalidad puede lograrse actualizando una aplicación de mensajería correspondiente o añadiendo una nueva aplicación de mensajería al terminal, por ejemplo.

La Figura 2 es un diagrama de flujo que ilustra una funcionalidad de un terminal de usuario de acuerdo con una realización de la invención en un modo de envío. En el ejemplo de la Figura 2 se supone que el usuario siempre crea mensajes en modo página de una forma similar y que el terminal de usuario selecciona el método/mecanismo a usar con el mensaje.

La Figura 2 comienza cuando el usuario ha creado un mensaje en modo página y da instrucciones, a través de una interfaz de usuario, para enviar el mensaje a un receptor (etapa 201). En otras palabras, el terminal de usuario recibe, en la etapa 201, una orden de "enviar mensaje a esta dirección". En respuesta a la orden, el terminal de usuario determina, en la etapa 202, el tamaño del mensaje y comprueba, en la etapa 203, si el tamaño de mensaje es mayor o no que un límite predeterminado para el tamaño. El límite predeterminado puede definirse mediante un protocolo de servicio usado, por el usuario o por el operador o puede preconfigurarse al terminal, por ejemplo. Preferentemente, el límite predeterminado corresponde a un tamaño que encaja en un mensaje de protocolo de transporte. Sin embargo, el valor del límite predeterminado y la forma en la que el límite predeterminado se establece no tiene ninguna significancia para la presente invención. En algunas realizaciones de la invención, es incluso posible que todos los mensajes en modo página, independientemente de sus tamaños, se envíen usando el mecanismo MSRp o un mecanismo correspondiente. Por ejemplo, el terminal de usuario puede preconfigurarse para usar siempre modo sesión porque el operador no permite que se use modo página.

Si el tamaño de mensaje no excede el límite (etapa 203), el terminal de usuario envía, en la etapa 204, los contenidos usando el método de SIP MESSAGE.

Si el tamaño de mensaje no excede el límite (etapa 203), el terminal de usuario envía, en la etapa 205, el mensaje usando el mecanismo MSRP, de acuerdo con la invención, con un indicador de modo página. Dependiendo de la implementación, el terminal de usuario puede o no añadir información al mensaje en modo página enviado mediante MSRP sobre el tamaño actual del mensaje. El procedimiento de envío de mensaje actual se ilustra en más detalle en las Figuras 6, 7 y 8.

En una realización de la invención, el usuario debe seleccionar de entre tres opciones: mensaje en modo página pequeño (tamaño es más pequeño que o igual a un límite predeterminado), otros mensajes en modo página, mensajería de sesión (conversación) y, cuando el usuario selecciona otros mensajes en modo página, se usa el mecanismo de mensajería en modo sesión con un indicador de modo página cuando el mensaje se envía.

La Figura 3 es un diagrama de flujo que ilustra una funcionalidad de un terminal de usuario de acuerdo con una realización de la invención en un modo de recepción. En el ejemplo de la Figura 3, se supone que no se transmite información sobre el tamaño actual del mensaje. Adicionalmente suposiciones hechas en aras de la claridad son que el terminal de usuario tiene suficiente memoria libre para mensajes de modo que el mensaje puede recibirse y que el terminal de usuario se configura para aceptar mensajes en modo página. Lo que sucede si el mensaje es mayor que la memoria libre es irrelevante para la invención; esto depende de la implementación del terminal de recepción; un terminal puede rechazar la solicitud de sesión si no existe suficiente memoria libre o se acepta una solicitud de sesión, pero la sesión se termina cuando la memoria se llena, por ejemplo.

En respuesta a la recepción de un SIP INVITE (MSRP) (etapa 301), el terminal de usuario comprueba, en la etapa 302, si el SIP INVITE (MSRP) es o no para un mensaje en modo página. Si es así, el terminal de usuario establece, en la etapa 303, una sesión; recibe, en la etapa 304, el mensaje; y almacena, en la etapa 305, el mensaje; y lanza, en la etapa 306, la sesión. Posteriormente, o simultáneamente, el terminal de usuario indica, en la etapa 307, al usuario que se ha recibido un mensaje. El usuario puede entonces leer el mensaje más tarde. En otras palabras, el terminal de usuario actúa hacia el usuario como si el mensaje se hubiera recibido en un método de SIP MESSAGE.

Si el SIP INVITE (MSRP) es para conversación (es decir para mensajería de modo sesión), no para un mensaje en

5

10

15

20

25

30

35

40

45

50

55

60

65

modo página (etapa 302), el terminal de usuario establece, en la etapa 308, una sesión y muestra, en la etapa 309, el dialogo hasta que la sesión finaliza.

El terminal de usuario de recepción puede configurarse para rechazar todos los mensajes en modo página, en cuyo caso no se establece ninguna sesión, sino que, en lugar de etapas 303 a 307, se envía un rechazo.

El terminal de usuario de recepción puede configurarse para reenviar solicitudes de mensaje en modo página a un buzón entrante de red, a otro terminal, etc., en cuyo caso no se establece ninguna sesión, sino que, en lugar de las etapas 303 a 307, se reenvía la solicitud. Ejemplos de tales situaciones se ilustran en las Figuras 7 y 8. Incluso si todos los mensajes en modo página se reenvían para almacenarse en otra parte y el usuario necesita ver los mismos mediante otro terminal, el terminar de reenvío se considera para proporcionar la mensajería en modo página.

En otra realización de la invención, la comprobación se realiza después de que se recibe el mensaje (es decir la etapa 302 se realiza después de la etapa 304 y el proceso continúa después de la comprobación o bien en la etapa 305 o en la etapa 308).

La Figura 4 es un diagrama de flujo que ilustra una funcionalidad de un terminal de usuario de acuerdo con otra realización de la invención en un modo de recepción. En el ejemplo de la Figura 4, se supone que existe información sobre el tamaño actual del mensaje. Adicionalmente suposiciones hechas en aras de la claridad son, como anteriormente en conexión con la Figura 3, con las mismas explicaciones no repetidas innecesariamente en este documento, que el terminal de usuario tiene suficiente memoria libre para mensajes y que el terminal de usuario se configura para aceptar mensajes en modo página.

En respuesta a la recepción de SIP INVITE (MSRP) (etapa 401), el terminal de usuario comprueba, en la etapa 402, si el SIP INVITE (MSRP) es o no para un mensaje en modo página. Si es así, el terminal de usuario notifica, en la etapa 403, al usuario acerca del tamaño del mensaje. Si el usuario acepta el mensaje (etapa 404), el terminal de usuario establece, en la etapa 405, una sesión; recibe, en la etapa 406, el mensaje; y almacena, en la etapa 407, el mensaje. El usuario puede entonces leer el mensaje más tarde. A continuación, el terminal de usuario lanza, en la etapa 408, la sesión. En otras palabras, el terminal de usuario actúa hacia el usuario como si el mensaje se hubiera recibido en un método de SIP MESSAGE. En este ejemplo específico, el terminal de usuario no notifica al usuario acerca de la recepción del mensaje porque se supone que aceptando la entrega de mensaje ya se notificó al usuario acerca del mensaje. Sin embargo, en otra implementación, el dispositivo de usuario puede configurarse también para notificar la recepción del mensaje al usuario.

Si el usuario no acepta el mensaje (etapa 404), el terminal de usuario rechaza, en la etapa 409, el establecimiento de sesión. En otra realización, el terminal de usuario, en lugar de rechazar, puede reenviar el establecimiento de sesión de modo que el mensaje se almacena en la red y puede recuperarse más tarde, como se ilustra en las Figuras 7 y 8.

Si el SIP INVITE (MSRP) es para conversación (es decir para mensajería de modo sesión), no para un mensaje en modo página (etapa 402), el terminal de usuario establece, en la etapa 410, una sesión y muestra, en la etapa 411, el dialogo hasta que la sesión finaliza.

En otra realización de la invención, en lugar de preguntar si el usuario acepta o no el mensaje, (es decir en lugar de etapa 403), el terminal de usuario se configura para aceptar un mensaje que no excede un límite de tamaño predefinido. El límite de tamaño predefinido puede definirse mediante un operador, mediante un fabricante de terminal de usuario y/o mediante un usuario, por ejemplo.

A continuación, se describirá la señalización en más detalle con algunos ejemplos ilustrados en las Figuras 5A a 8, usando SDP (Protocolo de Descripción de Sesión) para iniciar una sesión y MSRP en TCP para transmitir los contenidos actuales sin limitar la invención a tales ejemplos. Otra suposición hecha en conexión con los siguientes ejemplos es que el terminal de usuario de recepción no rechazará el mensaje. Si se requiere, puede encontrarse información adicional en
http://www.ietf.org/internet-drafts/draft-ietfsimple-mensaje-sessions-10.txt, que se incorpora en este documento como una referencia. Sin embargo, no tiene importancia para la invención qué protocolos se usan, siendo los anteriores únicamente ejemplos. Por ejemplo, en lugar de SDP, pueden usarse otros protocolos de mecanismo de oferta-respuesta y, en lugar de TCP, pueden usarse otros protocolos de control de congestión, tales como SCTP (Protocolo de Transporte Común de Señalización).

Las Figuras 5A a 5D ilustran algunos ejemplos de cómo un mensaje en modo sesión puede indicar que una invitación de modo sesión es para un mensaje en modo página.

En la realización de la Figura 5A, un mensaje en modo página se indica mediante una combinación de una línea m que contiene un nuevo indicador de modo página 5-1 (m=message 9 msrp page-mode) y un parámetro a=max-size indicando el tamaño actual del mensaje 5-2 (a=max-size: tamaño actual).

5

10

15

20

25

30

35

40

45

50

55

60

65

En la realización de la Figura 5B, un mensaje en modo página se indica mediante una combinación de la línea m que contiene el nuevo indicador de modo página 5-1 (m=message 9 msrp page-mode) y un parámetro 5-3 a=actual- size que indica el tamaño actual del mensaje (a=actual-size: tamaño actual). En esta realización, el parámetro a=max-size indica el tamaño máximo de un mensaje.

En la realización de la Figura 5C, un mensaje en modo página se indica mediante el parámetro 5-3 a=actual-size. Cuando el valor del parámetro difiere de 0, indica implícitamente que el mensaje es un mensaje en modo página, o vice versa. En esta realización, la línea m información indica que debe usarse MSRP y el parámetro a=max-size indica el tamaño máximo de un mensaje.

En la realización de la Figura 5D, un mensaje en modo página se indica mediante la línea m que contiene un nuevo indicador de modo página 5-1 (m=message 9 msrp page-mode). En esta realización, el parámetro a=max-size indica el tamaño máximo de un mensaje y no se requiere ningún parámetro a adicional.

En el gráfico de señalización de la Figura 6, únicamente se muestra señalización entre puntos de extremo, aunque uno o más intermediarios puede implicarse. La Figura 6 ilustra señalización cuando un receptor, o más precisamente un cliente correspondiente en el terminal de usuario del receptor, acepta el mensaje. La Figura 6 comienza cuando Alice quiere enviar un mensaje a Bob. El terminal de usuario de Alice UT1 (más precisamente un cliente correspondiente en UT1) observa, en el punto 6-1, que el mensaje en modo página debe enviarse usando un mecanismo de modo sesión. (El punto 6-1 se describe en detalle anteriormente en la Figura 2). Por lo tanto, UT1 envía un mensaje de invitación de sesión 6-2 con una indicación de modo página PMI al terminal de usuario de Bob UT2. El mensaje 6-2 es preferentemente uno de los mensajes ilustrados en las Figuras 5A a 5D. En respuesta a la recepción del mensaje 6-2, UT2 detecta, en el punto 6-3, que el mensaje es una invitación de modo sesión para un mensaje en modo página y acepta la invitación enviando el mensaje 6-4. UT1 reconoce la aceptación enviando el mensaje 6-5 y UT1 a continuación envía los contenidos actuales del mensaje en modo página en un mensaje de modo sesión 6-6. En respuesta a la recepción de los contenidos, UT2 almacena, en el punto 6-7, los contenidos de modo que Bob puede ver los mismos más tarde. UT2 también puede notificar a Bob, como se ha descrito anteriormente en las Figuras 3 y 4. En respuesta a la recepción de los contenidos, UT2 también reconoce la recepción enviando un acuse de recibo de modo sesión en el mensaje 6-8. En la realización ilustrada en la Figura 6, el terminal de usuario de envío, UT1, se configura para terminar la sesión en respuesta al acuse de recibo enviando el mensaje 6-9 a UT2, que a continuación envía el mensaje 6-10 para reconocer la terminación.

En el gráfico de señalización de la Figura 7, se muestra señalización entre puntos de extremo a través de un servidor de mensajería instantánea de participación del punto de extremo de recepción, aunque puede implicarse uno o más intermediarios. La Figura 7 ilustra señalización cuando un receptor, o más precisamente un cliente correspondiente en el terminal de usuario del receptor, no acepta el mensaje, pero solicita a la red que guarde el mensaje para recuperación posterior. La Figura 7 comienza cuando Alice quiere enviar un mensaje a Bob. El terminal de usuario de Alice UT1 (más precisamente un cliente correspondiente en UT1) observa, en el punto 7-1, que el mensaje en modo página debe enviarse usando un mecanismo de modo sesión. (El punto 7-1 se describe en detalle anteriormente en conexión con la Figura 2). Por lo tanto, UT1 envía un mensaje de invitación de sesión 7-2 con una indicación de modo página PMI al terminal de usuario de Bob UT2 a través del servidor. El mensaje 7-2 es preferentemente uno de los mensajes ilustrados en las Figuras 5A a 5D. En respuesta a la recepción del mensaje 72, UT2 detecta, en el punto 7-3, que el mensaje es una invitación de modo sesión para un mensaje en modo página. Por alguna razón, UT2 no acepta el mensaje de modo página, sino que envía un mensaje de redirección 7-4 al servidor. Un ejemplo de mensajes de redirección es un mensaje SIP 302 "Movido Temporalmente" que puede contener información de cómo debería tratarse un mensaje. Sin embargo, es irrelevante para la invención cómo y con qué protocolos se realiza la redirección y se da(n) instrucciones/información adicional/es, si es necesario. Otros ejemplos incluyen utilizar transacciones separadas usando protocolos SIP, tales como SIP PUBLISH, SIP OPTIONS, llamados capacidades en SIP REGISTER, o con XCAP (Protocolo de Acceso de Configuración de lenguaje de marcas extensible). UT2 también puede notificar a Bob acerca del mensaje, como se ha descrito anteriormente en conexión con la Figuras 3 y 4.

En este ejemplo, el servidor, y más precisamente un agente de usuario adosado, acepta ofrecer un servicio alternativo y, por lo tanto, el servidor se supone a sí mismo como el punto de extremo de sesión y acepta la invitación inicial enviando el mensaje 7-5. UT1 reconoce la aceptación enviando el mensaje 7-6 al servidor y a continuación envía los contenidos actuales del mensaje en modo página en un mensaje de modo sesión 7-7 al servidor. En respuesta a la recepción de los contenidos, el servidor almacena, en el punto 7-8, los contenidos de modo que Bob puede ver los mismos más tarde. En respuesta a la recepción de los contenidos, el servidor también reconoce la recepción enviando un acuse de recibo de modo sesión en el mensaje 7-9. En la realización ilustrada en la Figura 7, el terminal de usuario de envío, UT1, se configura para terminar la sesión en respuesta al acuse de recibo enviando el mensaje 7-10 al servidor, que a continuación envía el mensaje 7-11 para reconocer la terminación. Bob puede entonces ver los contenidos de mensaje más tarde, pero la implementación de esta visualización es irrelevante para la invención y, por lo tanto, no se analiza en este punto en detalle.

En el gráfico de señalización de la Figura 8, como en la Figura 7, se muestra señalización entre puntos de extremo a través de un servidor de mensajería instantánea de participación del punto de extremo de recepción, aunque puede

5

10

15

20

25

30

35

40

45

50

55

60

65

implicarse uno o más intermediarios. La Figura 8 ilustra señalización cuando un receptor, o más precisamente un cliente correspondiente en el terminal de usuario del receptor, no acepta el mensaje, pero solicita a una pasarela GW en la red que guarde el mensaje para recuperación posterior. La Figura 8 comienza cuando Alice quiere enviar un mensaje a Bob. El terminal de usuario de Alice UT1 (más precisamente un cliente correspondiente en UT1) observa, en el punto 8-1, que el mensaje en modo página debe enviarse usando un mecanismo de modo sesión. (El punto 8-1 se describe en detalle anteriormente en conexión con la Figura 2). Por lo tanto, UT1 envía un mensaje de invitación de sesión 8-2 con una indicación de modo página PMI al terminal de usuario de Bob UT2 a través del servidor. El mensaje 8-2 es preferentemente uno de los mensajes ilustrados en las Figuras 5A a 5D. En respuesta a la recepción del mensaje 8-2, UT2 detecta, en el punto 8-3, que el mensaje es una invitación de modo sesión para un mensaje en modo página. Por alguna razón, UT2 no acepta el mensaje de modo página, sino que envía un mensaje de redirección 8-4 al servidor, indicando el mensaje de redirección que el mensaje debería reenviarse a la pasarela GW. (Los mensajes de redirección se analizaron anteriormente en conexión con la Figura 7.) UT2 también puede notificar a Bob acerca del mensaje, como se ha descrito anteriormente en conexión con la Figuras 3 y 4.

En este ejemplo, el servidor, y más precisamente un agente de usuario adosado, genera una nueva solicitud al URI (identificador de recurso uniforme) de GW indicada en el mensaje 8-4 y envía la solicitud en el mensaje 8-5. La solicitud es preferentemente una invitación de modo sesión sin una indicación de modo página. GW acepta la invitación inicial enviando el mensaje 8-6. UT1 reconoce la aceptación enviando el mensaje 8-7 a GW y a continuación envía los contenidos actuales del mensaje en modo página en un mensaje de modo sesión 8-8 a la GW. En respuesta a la recepción de los contenidos, Gw almacena, en el punto 8-9, los contenidos de modo que Bob puede ver los mismos más tarde. En respuesta a la recepción de los contenidos, GW también reconoce la recepción enviando un acuse de recibo de modo sesión en el mensaje 8-10. En la realización ilustrada en conexión con la Figura 8, el terminal de usuario de envío, UT1, se configura para terminar la sesión en respuesta al acuse de recibo enviando el mensaje 8-11 a GW, que a continuación envía el mensaje 8-12 para reconocer la terminación. Bob puede entonces ver los contenidos de mensaje más tarde, pero la implementación de esta visualización es irrelevante para la invención y, por lo tanto, no se analiza en este punto en detalle.

La Figura 9 ilustra señalización de acuerdo con una realización adicional de la invención, en la que realización de un servidor de mensajería instantánea también se configura para detectar la indicación. El servidor de mensajería instantánea puede ser un servidor separado o un componente de servidor en un nodo de red que comprende uno o más otros componentes. En el ejemplo ilustrado en la Figura 9, se supone que el receptor (UT2) no se puede alcanzar o tiene una configuración de acuerdo con la que mensajes en modo página del receptor deben almacenarse en el buzón de entrada de red del receptor, estando en este ejemplo ubicado en el servidor. Esto también puede ser una configuración de red. En el gráfico de señalización de la Figura 9, se muestra señalización entre un punto de extremo de envío UT1 y un servidor de mensajería instantánea de participación del punto de extremo de recepción, aunque puede implicarse uno o más intermediarios. La Figura 9 comienza cuando Alice quiere enviar un mensaje a Bob. El terminal de usuario de Alice UT1 (más precisamente un cliente correspondiente en UT1) observa, en el punto 9-1, que el mensaje en modo página debe enviarse usando un mecanismo de modo sesión. (El punto 9-1 se describe en detalle anteriormente en conexión con la Figura 2). Por lo tanto, UT1 envía un mensaje de invitación de sesión 9-2 con una indicación de modo página PMI al terminal de usuario de Bob UT2 a través del servidor. El mensaje 9-2 es preferentemente uno de los mensajes ilustrados en las Figuras 5A a 5D. En respuesta a la recepción del mensaje 9-2, el servidor, y más precisamente a agente de usuario adosado, detecta, en el punto 9-3, que el mensaje es una invitación de modo sesión para un mensaje en modo página y, por lo tanto, comprueba configuraciones de Bob, es decir de UT2, para mensajes en modo página. Ya que las configuraciones muestran que mensajes en modo página deben almacenarse para recuperación posterior, el servidor se supone a sí mismo como el punto de extremo de sesión y acepta la invitación enviando el mensaje 9-4. UT1 reconoce la aceptación enviando el mensaje 9-5 al servidor y a continuación envía los contenidos actuales del mensaje en modo página en un mensaje de modo sesión 9-6 al servidor. En respuesta a la recepción de los contenidos, el servidor almacena, en el punto 9-7, los contenidos de modo que Bob puede ver los mismos más tarde. En alguna otra realización de la invención, el mensaje puede almacenarse en otro nodo de red o una base de datos remota o reenviarse a una pasarela. En respuesta a la recepción de los contenidos, el servidor también reconoce la recepción enviando un acuse de recibo de modo sesión en el mensaje 9-8. En la realización ilustrada en conexión con la Figura 9, el terminal de usuario de envío, UT1, se configura para terminar la sesión en respuesta al acuse de recibo enviando el mensaje 9-9 al servidor, que a continuación envía el mensaje 9-10 para reconocer la terminación. Bob puede entonces ver los contenidos de mensaje más tarde, pero la implementación de esta visualización es irrelevante para la invención y, por lo tanto, no se analiza en este punto en detalle.

En otra realización de la invención, el servidor de mensajería instantánea del receptor se dispone para decidir si reenviar o no la solicitud de sesión o suponerse a sí mismo como el punto de extremo sobre la base del tamaño de mensaje, capacidades de terminal del receptor y/o carga de red.

En una realización adicional basada en la Figura 9, el usuario puede tener una configuración de acuerdo con la que mensajes en modo página transmitidos usando un mecanismo de modo sesión se almacenan en la red buzón de entrada y únicamente se notifican al usuario, mientras que mensajes en modo página transmitidos usando un mecanismo de modo página se reenvían al usuario.

5

10

15

20

25

Las etapas, puntos y mensajes de señalización mostrados en las Figuras 2, 3, 4, 6, 7, 8 y 9 no están en absoluto en orden cronológico y algunas de las etapas/puntos pueden realizarse simultáneamente o en un orden diferente del dado. Otras funciones también pueden ejecutarse entre las etapas/puntos o dentro de las etapas/puntos. Algunas de las etapas/puntos o parte de las etapas/puntos también pueden dejarse fuera. Los mensajes de señalización son únicamente ilustrativos y pueden incluso comprender varios mensajes separados para transmitir la misma información. Además, los mensajes también pueden contener otra información. Los mensajes y etapas/puntos también pueden combinarse libremente o dividirse en varias partes. Adicionalmente, los nombres, tipos y/o contenidos de los mensajes pueden diferir de los mencionados anteriormente, así como los protocolos usados.

Aunque en lo anterior la invención se ha divulgado asumiendo que la comunicación, es decir transmisión de ficheros y llamadas, es comunicación uno a uno, es obvio para un experto en la materia que la comunicación puede ser también comunicación uno a muchos.

Las realizaciones presentadas anteriormente o partes de las mismas pueden combinarse para producir realizaciones preferidas de la invención.

Los terminales de usuario, otros dispositivos correspondientes y/o servidores o componentes de servidor correspondientes que implementan la funcionalidad de la presente invención comprenden no únicamente los medios de técnica anterior sino también medios para enviar y/o recibir mensajes en modo página de la manera anteriormente descrita. Nodos de red y terminales de usuario presentes comprenden procesadores y memoria que pueden utilizarse en las funciones de acuerdo con la invención. Todas las modificaciones y configuraciones requeridas para implementar la invención pueden realizarse como rutinas, que pueden implementarse como rutinas de software añadidas o actualizadas, circuitos de aplicación (ASIC) y/o circuitos programables.

Será obvio para un experto en la materia que a medida que la tecnología avanza, el concepto inventivo puede implementarse de diversas maneras. La invención y sus realizaciones no se limitan a los ejemplos descritos anteriormente, sino que pueden variar dentro del alcance de las reivindicaciones.

Claims

5

10

15

20

25

30

35

40

45

50

REIVINDICACIONES

1. Un método para enviar un mensaje en modo página, caracterizado por comprender el método:

crear, mediante un aparato, en respuesta al tamaño de mensaje en modo página que excede un límite predeterminado (203), una invitación de sesión para un mecanismo de mensajería en modo sesión; añadir, mediante el aparato, a la invitación de sesión una indicación con un valor que indica a un receptor que el modo sesión es para un mensaje en modo página;

enviar, mediante el aparato, la invitación de sesión con la indicación (6-2, 7-2, 8-2, 9-2); y

enviar, mediante el aparato, usando el mensaje en modo página (205) el mecanismo de mensajería en modo sesión.
2. Un método de acuerdo con la reivindicación 1, comprendiendo además crear (6-2, 7-2, 8-2, 9-2) una sesión para enviar el mensaje; y terminar (6-9, 7-10, 8-10, 9-9) la sesión en respuesta al mensaje que se ha enviado.
3. Un método para recibir un mensaje en modo página, comprendiendo el método:

recibir (301), mediante un aparato, una invitación de sesión para un mecanismo de mensajería en modo sesión; caracterizado por:

detectar (302), mediante el aparato, en la invitación de sesión recibida, una indicación con un valor que indica que el mecanismo de mensajería en modo sesión es para un mensaje en modo página; y en respuesta a dicho valor, tratar (304, 305), mediante el aparato, un mensaje de mecanismo de mensajería en modo sesión recibido como un mensaje en modo página.
4. Un método de acuerdo con la reivindicación 3, comprendiendo además crear (303) una sesión para recibir el mensaje; y terminar (306) la sesión en respuesta al mensaje que se ha recibido.
5. Un método como se indica en una cualquiera de las reivindicaciones anteriores, en el que una línea m (5-1) en la invitación contiene dicho valor.
6. Un método como se indica en una cualquiera de las reivindicaciones anteriores 1 a 4, en el que dicha indicación comprende una línea m para el valor (5-1) y un parámetro (5-3) indicando el tamaño real del mensaje.
7. Un método de acuerdo con cualquier reivindicación anterior, en el que la invitación de sesión para un mecanismo de mensajería en modo sesión es un SIP INVITE para una sesión de Protocolo de Retransmisión de Sesión de Mensaje.
8. Un aparato (2, UT1) que proporciona mensajería en modo página y mecanismos de mensajería en modo sesión, caracterizado por que el aparato (2, UT1) comprende medios para implementar un método de acuerdo con cualquiera de las reivindicaciones 1 a 7.
9. Un aparato de acuerdo con la reivindicación 8, en donde el aparato es un terminal de usuario.
10. Un programa informático que comprende instrucciones que, cuando el programa se ejecuta mediante el aparato, provocan que el aparato efectúe el método de cualquiera de las reivindicaciones 1 a 7.