MENSAJER A DE MODO DE PAGINA
Campo de la Invención La invención se refiere a la mensajería, y de manera más particular, a la mensajería de modo de página, que también es denominada mensajería única.
Antecedentes de la Invención El desarrollo de la tecnología de comunicación, de manera particular, la tecnología de comunicación basada en IP y las terminales de usuario final, ha permitido posibilidades versátiles de comunicación y la introducción de diferentes servicios. Cada vez más servicios son implementados utilizando conceptos básicos proporcionados por el Protocolo de Iniciación de Sesión (SIP, por sus siglas en inglés) que no es verticalmente integrado en un sistema de comunicaciones, sino en una herramienta que construye una arquitectura multimedia. De manera más precisa, el SIP es un protocolo
(señalización) de control de capa de aplicación definido IEFT para la creación, modificación y terminación de sesiones con uno o más participantes. Estas sesiones incluyen, por ejemplo, las llamadas telefónicas de la Internet, la distribución multimedia, las conferencias multimedia y las sesiones PoC (Pulsar-para-Hablar a través de Celular) . Para los servicios de mensajería, el protocolo SIMPLE (el SIP para R?F„ 188256 Mensajería Instantánea y Extensiones de Influencia de Presencia) que utilizan SIP y las implementaciones existentes del SIP para proporcionar el servicio de presencia y mensajería instantánea están siendo definidas en IEFT. La OMA (Alianza Móvil Abierta) también define un activador IM (Mensajería Instantánea) basado en los protocolos SIP/SIMPLE. El protocolo SIMPLE define dos modos de intercambio de mensajería instantánea: el modo de página y el modo de sesión. El modo de página utiliza el método SIP MESSAGE a través del cual es enviado un mensaje instantáneo de modo de página, y en donde en un nivel de protocolo, un subsiguiente mensaje instantáneo no está relacionado con el precedente: cada mensaje inmediato, incluso una respuesta a un mensaje previo, es considerado como una transacción independiente. Por lo tanto, el método SIP MESSAGE se asemeja a un servicio convencional de correo electrónico o de mensaje corto. El modo de sesión utiliza el SIP para señalizar y establecer una sesión y el MSRP (Protocolo de Retraso de Sesión de Mensaje) lleva una serie de mensajes instantáneos una vez que ha sido establecida una sesión. Más adelante, la combinación es simplemente llamada un mecanismo MSRP. En otras palabras, el mecanismo MSRP proporciona una mensajería de tipo de charla o plática, llamada mensajería de modo de sesión. Un problema es generado cuando un usuario quiere enviar un mensaje grande de modo de página. El método SIP MESSAGE podría utilizar, ya sea el transporte UDP o TCP. El protocolo TCP proporciona un método confiable de transporte también para grandes mensajes, aunque el transporte TCP no siempre puede ser garantizado por el método SIP MESSAGE. Si fuera utilizado el protocolo UDP para el envío de un mensaje grande, serían fragmentados los paquetes más grandes que del tamaño máximo UDP y no podrían llegar en el orden correcto al receptor. Además, incluso si el protocolo TCP pudiera ser garantizado, permanecería otro problema, el cual se refiere al control de la congestión. Debido a que el método SIP MESSAGE es parte de la señalización de control de sesión SIP, un mensaje es enviado y recibido utilizando los mismos recursos como es empleado a través de la señalización SIP. Para una terminal de usuario, esto significa que la actual señalización SIP podría ser bloqueada durante el tiempo que esté siendo enviado o recibido el gran mensaje en la terminal de usuario. El recurso mencionado con anterioridad para la señalización SIP podría ser un contexto PDP (Protocolo de Datos de Paquete) de uso general o un contexto de señalización dedicada PDP en el caso, por ejemplo, de los sistemas GERAN (GSM/EDGE Red de Acceso de Radio) y/o UTRAN
(UMTS Red Terrestre de Acceso de Radio). En otros sistemas, el recurso podría ser, por ejemplo, una banda ancha reservada y/o dedicada con propósitos de señalización. Además de que esté siendo bloqueada la señalización SIP, un problema adicional que se refiere a la carga de los dispositivos proxies SIP podría generarse. Puesto que un mensaje de modo de página utiliza, de manera convencional, el método SIP MESSAGE, todos los mensajes que utilizan el método SIP MESSAGE son transmitidos a través de los dispositivos proxies SIP. De esta manera, los mensajes de modo de página de tamaño grande que son transmitidos a través de los dispositivos proxies SIP, podrían provocar una disminución severa en el rendimiento de los dispositivos proxies SIP, originando un bloqueo efectivo en toda la señalización SIP y disminuyendo el rendimiento total de la red SIP. Por lo tanto, en algunos casos, no es factible que sea utilizado el método SIP MESSAGE para un mensaje de tamaño grande. Una solución es que cuando el tamaño del mensaje exceda un cierto límite, en lugar de que sea utilizado el método SIP MESSAGE, sería empleado el mecanismo MSRP. Sin embargo, el mecanismo MSRP es para el servicio de mensajería de modo de sesión, no para la mensajería de modo de página. Además, los mensajes recibidos de modo de página pueden ser aplazados o diferidos y son almacenados en el buzón de entrada de mensajería, a partir del cual el usuario los puede leer cuando sea conveniente, aunque en la mensajería de modo de sesión un mensaje recibido es abierto por la terminal de usuario y es mostrado al usuario para facilitar el diálogo. De esta manera, a partir del punto de vista del receptor, ninguno de los mensajes de modo de página puede ser recibido cuando sea utilizado el mecanismo MSRP.
Breve Descripción de la Invención Un objetivo de la presente invención es proporcionar un método y aparato para la implementación del método, a fin de superar el problema anterior. Los objetivos de la invención son alcanzados a través de un método, terminales de usuario y un servidor que son caracterizados por lo que es señalado en las reivindicaciones independientes. Las modalidades preferidas de la invención son descritas en las reivindicaciones dependientes . La invención está basada en la realización del problema y en resolverlo mediante la indicación de si un mensaje enviado que utiliza un mecanismo de mensajería de modo de sesión (de tipo de plática o conversación) es o no un mensaje de modo de página, y en respuesta al mensaje que es un mensaje de modo de página, se actúa como si éste hubiera sido recibido utilizando un mecanismo de modo de página o de acuerdo con las instrucciones específicas definidas por este mensaje de modo de página. El término modo de sesión significa un protocolo, tal como el MSRP, que se pretende sea utilizado para el intercambio de una serie de mensajes. El término modo de página significa que cada mensaje es una transacción independiente en el nivel de protocolo, es decir, un mensaje instantáneo subsiguiente no está relacionado, en el nivel de protocolo, con el mensaje precedente. Una ventaja de la invención es que mediante la utilización de la indicación, los mensajes de modo de página pueden ser recibidos como mensajes de modo de página, incluso cuando sean transmitidos como mensajes de modo de sesión. Otra ventaja es que puede ser evitado el bloqueo de la señalización SIP debido a los grandes mensajes.
Breve Descripción de las Figuras A continuación, la invención será descrita en mayor detalle por medio de las modalidades preferidas con referencia a las figuras adjuntas, en las cuales: La Figura 1 muestra una arquitectura simplificada de sistema; La Figura 2 es un diagrama de flujo que ilustra la funcionalidad de una terminal de usuario de acuerdo con una modalidad de la invención en el modo de envío; Las Figuras 3 y 4 son diagramas de flujo que ilustran la funcionalidad de una terminal de usuario de acuerdo con las modalidades de la invención en el modo de recepción; Las Figuras 5A-5D ilustran ejemplos de los mensajes SIP INVITE de acuerdo con las modalidades de la invención; y Las Figuras 6, 7, 8 y 9 ilustran la señalización de acuerdo con las modalidades de la invención.
Descripción Detallada la ?nve-acióa Las siguientes modalidades son de ejemplo. Aunque la especificación podría referirse a "una", "la", o "algunas" modalidad (es) en varias ubicaciones, esto no necesariamente significa que cada referencia sea para la misma modalidad (es) , o que la característica sólo se aplique a una modalidad única. Las características únicas de las distintas modalidades, también podrían ser combinadas a fin de proporcionar otras modalidades. La presente invención puede ser aplicada a cualquiera de las terminales de usuario, servidores y/o a cualquier sistema de comunicaciones o cualquier combinación de los distintos sistemas de comunicaciones que es/son accesibles a través de las terminales de usuario y proporciona (n) servicios de mensajería, es decir, el envío de datos en un formato de mensaje de una entidad a otra, ya sea en tiempo casi real o hacia un buzón de correo. No existen limitaciones al formato del mensaje, ni tampoco para el tipo de datos. Los datos podrían ser texto, voz, video clips, multimedia, etcétera. El sistema de comunicaciones podría ser un sistema fijo de comunicaciones o un sistema inalámbrico de comunicaciones o un sistema de comunicaciones que utiliza ambas de las redes fijas e inalámbricas. Los protocolos utilizados, las especificaciones de los sistemas y terminales de comunicaciones, sobre todo en las comunicaciones inalámbricas, se desarrollan con rapidez. Este desarrollo podría requerir cambios adicionales en la invención. Por lo tanto, todas las palabras y expresiones deben ser interpretadas de manera amplia y se pretenden que ilustren pero que no restrinjan la invención. A continuación, la presente invención será descrita utilizando, como un ejemplo de un entorno de sistema en el que podría aplicarse la presente invención, un entorno de sistema muy simplificado que utiliza SIP y MSRP, sin restringir la invención a los mismos. Debe apreciarse que el sistema de comunicaciones y los nodos intermedios, tales como los dispositivos proxies y otros protocolos utilizados más adelante o con anterioridad SIP y MSRP, o los protocolos correspondientes, son irrelevantes para la actual invención. Por lo tanto, éstos no necesitan ser discutidos en mayor detalle en la presente. La presente invención se refiere principalmente a la transmisión de un mensaje en una capa de aplicación. La Figura 1 es una arquitectura altamente simplificada de sistema que sólo muestra el sistema de comunicaciones 1, dos terminales de usuario UT 2, 2' y una red 3. Es aparente para una persona experta en la técnica que el sistema (s) también comprende (n) otros dispositivos, entidades de sistema, tales como servidores de mensajería instantánea, funciones y estructuras que no necesitan ser descritos en detalle en la presente. Una terminal de usuario 2, 2' es una pieza de equipo o un dispositivo que permite que el usuario interactué con un sistema de comunicaciones en forma directa o por medio del sistema de cómputo, es decir, presenta la información al usuario y permite que el usuario ingrese información, es decir, la terminal de usuario es un punto de terminación de una comunicación particular. En otras palabras, la terminal de usuario 2, 2' podría ser cualquier nodo o un anfitrión que soporte la mensajería y sea capaz de comunicarse con una red del sistema, a través de una red de acceso (no se muestra en la Figura 1) si existiera esta red de acceso. La terminal de usuario 2, 2' podría ser un aparato no móvil, tal como una computadora personal PC, que se conecta de manera inalámbrica con la red 3 o por medio de una conexión fija. La terminal de usuario 2, 2' también podría ser una terminal móvil inalámbrica que soporte la mensajería, una terminal de múltiples servicios que sirva como una plataforma de servicio y que soporte la carga y la ejecución de distintas funciones relacionadas con el servicio o una computadora portátil PC de tipo laptop' que pueda conectarse con la red (por medio de una posible red de acceso) , un asistente digital personal PDA, que pueda conectarse con la red (por medio de una posible red de acceso) , etcétera. La terminal de usuario 2 comprende al menos una interfaz de usuario (Ul) 21 por medio de la cual el usuario puede crear y/o leer mensajes, una o más aplicaciones de mensajería (Appl) 22, memoria (Mem) 23 (o la terminal de usuario es situada de manera que tenga acceso a la memoria) para el almacenamiento de los mensajes recibidos de tipo de modo de página, por lo menos temporalmente, y un transceptor (TRx) 24 para el envío y recepción de comunicaciones (mensajes) . La aplicación de mensajería 22 podría ser una aplicación de software configurada para implementar una funcionalidad de acuerdo con la invención. La funcionalidad podría ser conseguida actualizando, por ejemplo, una correspondiente aplicación de mensajería o agregando una nueva aplicación de mensajería a la terminal. La Figura 2 es un diagrama de flujo que ilustra una funcionalidad de una terminal de usuario de acuerdo con una modalidad 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 de modo de página en un modo similar y que la terminal de usuario selecciona el método/mecanismo que será utilizado con el mensaje. La Figura 2 inicia cuando el usuario ha creado un mensaje de modo de página y proporcionan las instrucciones por medio de una interfaz de usuario para enviar el mensaje a un receptor (etapa 201) . En otras palabras, la terminal de usuario recibe un comando en la etapa 201 de "enviar el mensaje a esta dirección". En respuesta al comando, la terminal de usuario determina en la etapa 202, el tamaño del mensaje y verifica en la etapa 203 si el tamaño de mensaje es más grande o no que un límite predeterminado para el tamaño. El límite predeterminado podría ser definido por un protocolo de servicio empleado, por ejemplo, mediante el usuario o mediante el operador o podría ser preconfigurado en la terminal. De preferencia, el límite predeterminado corresponde con un tamaño que se ajuste a un mensaje de protocolo de transporte. Sin embargo, el valor del límite predeterminado y el modo en el cual el límite predeterminado es establecido no tiene significancia para la presente invención. En algunas modalidades de la invención, incluso es posible que todos los mensajes de modo de página, sin considerar su tamaño, sean enviados utilizando el mecanismo MSRP o un mecanismo correspondiente. Por ejemplo, la terminal de usuario podría ser previamente configurada para utilizar siempre el modo de sesión debido a que el operador no permite que sea utilizado el modo de página. Si el tamaño de mensaje no excediera el tamaño límite (etapa 203), la terminal de usuario enviaría los contenidos en la etapa 204, utilizando el método SIP MESSAGE.
Si el tamaño de mensaje no excediera el límite (etapa 203), la terminal de usuario enviaría el mensaje en la etapa 205, utilizando el mecanismo MSRP, de acuerdo con la invención, con un indicador de modo de página. En función de la implementación, la terminal de usuario podría o no agregar información al mensaje de modo de página enviado por el MSRP en el tamaño actual del mensaje. El procedimiento actual de envío de mensaje se ilustra en mayor detalle en las Figuras 6, 7 y 8. En una modalidad de la invención, el usuario tiene que seleccionar de entre tres opciones: un mensaje pequeño de modo de página (el tamaño es más pequeño o igual a un límite predeterminado) , otros mensajes de modo de página, la mensajería de sesión (de plática) y cuando el usuario seleccione otros mensajes de modo de página, el mecanismo de mensajería de modo de sesión con un indicador de modo de página sería utilizado cuando sea enviado el mensaje. La Figura 3 es un diagrama de flujo que ilustra la funcionalidad de una terminal de usuario de acuerdo con una modalidad de la invención en un modo de recepción. En el ejemplo de la Figura 3, se supone que ninguna información sobre el tamaño actual del mensaje es transmitida. Las suposiciones adicionales realizadas por motivos de claridad son que la terminal de usuario tenga una suficiente memoria libre para los mensajes, de modo que el mensaje pudiera ser recibido, y que la terminal de usuario sea configurada para aceptar los mensajes de modo de página. Lo que sucedería si el mensaje fuera más grande que la memoria libre es irrelevante para la invención; esto está en función de la implementación de la terminal de recepción; una terminal podría rechazar la petición de sesión si no existiera una memoria libre suficiente, o una petición de sesión sería aceptada aunque la sesión sea terminada, por ejemplo, cuando la memoria esté llena o completa. En respuesta a la recepción de un SIP INVITE (MSRP)
(etapa 301) , la terminal de usuario verifica en la etapa 302 si el SIP INVITE (MSRP) es o no para un mensaje de modo de página. Si fuera así, la terminal de usuario establecería una sesión en la etapa 303; después, recibiría el mensaje en la etapa 304 y almacenaría el mensaje en la etapa 305; y finalmente, liberaría la sesión en la etapa 306. De manera subsiguiente o simultánea, la terminal de usuario indica al usuario en la etapa 307 que un mensaje ha sido recibido. Entonces, el usuario podría leer el mensaje posteriormente. En otras palabras, la terminal de usuario actúa hacia el usuario como si el mensaje fuera recibido a través del método SIP MESSAGE. Si el SIP MESSAGE (MSRP) fuera para plática o conversación (es decir, para la mensajería de modo de sesión) no para un mensaje de modo de página (etapa 302), la terminal de usuario establecería una sesión en la etapa 308 y presentaría el diálogo en la etapa 309 hasta que finalice la sesión. La terminal de usuario de recepción podría ser configurada para rechazar todos los mensajes de modo de página, en este caso ninguna sesión sería establecida, sino que en lugar de las etapas 303-307, sería enviado un rechazo. La terminal de usuario de recepción podría ser configurada para transmitir peticiones de mensaje de modo de página a un buzón de entrada de red, a otra terminal, etc., en este caso ninguna sesión sería establecida, sino que en lugar de las etapas 303-307, la petición sería transmitida. Los ejemplos de estas situaciones son ilustrados en las Figuras 7 y 8. Incluso si todos los mensajes de modo de página fueran transmitidos para que sean almacenados en otro lugar, y si el usuario necesitará observarlos a través de otra terminal, la terminal de transmisión sería considerada a fin de proporcionar la mensajería de modo de página. En otra modalidad de la invención, la verificación es realizada una vez que sea recibido el mensaje (es decir, la etapa 302 es realizada después de la etapa 304, y el proceso continuaría después de la verificación ya sea en la etapa 305 o la etapa 308) . La Figura 4 es un diagrama de flujo que ilustra una funcionalidad de una terminal de usuario de acuerdo con otra modalidad 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. Las suposiciones adicionales realizadas por motivos de claridad son, del mismo modo que con anterioridad en conexión con la Figura 3 , con las mismas explicaciones no necesariamente repetidas aquí, que la terminal de usuario tenga una memoria libre suficiente para los mensajes y que la terminal de usuario sea configurada para aceptar los mensajes de modo de página. En respuesta a la recepción SIP MESSAGE (MSRP)
(etapa 401), la terminal de usuario verifica en la etapa 402 si el SIP MESSAGE (MSRP) es o no para un mensaje de modo de página. Si fuera así, la terminal de usuario notificaría al usuario en la etapa 403 acerca del tamaño del mensaje. Si el usuario aceptara el mensaje (etapa 404), la terminal de usuario establecería una sesión en la etapa 405; después, recibiría el mensaje en la etapa 406; y finalmente, almacenaría el mensaje en la etapa 407. A continuación, el usuario puede leer el mensaje posteriormente. En seguida, la terminal de usuario libera la sesión en la etapa 408. En otras palabras, la terminal de usuario actúa hacia el usuario como si el mensaje fuera recibido a través del método SIP MESSAGE. En este ejemplo específico, la terminal de usuario no notifica al usuario acerca de la recepción del mensaje debido a que se supone que mediante la aceptación del suministro de mensaje, el usuario ya fue notificado acerca del mensaje. Sin embargo, en otra implementación, el dispositivo de usuario podría ser configurado también para notificar la recepción del mensaje al usuario. Si el usuario no aceptara el mensaje (etapa 404) , la terminal rechazaría el establecimiento de la sesión en la etapa 409. En otra modalidad, la terminal de usuario podría transmitir el establecimiento de la sesión, en lugar de su rechazo, de modo que el mensaje sea almacenado en la red y pueda ser posteriormente recuperado, como se ilustra en las Figuras 7 y 8. Si el mensaje SIP MESSAGE (MSRP) fuera para plática o conversación (es decir, para la mensajería de modo de sesión), no para la mensajería de modo de página (etapa 402), la terminal de usuario establecería una sesión en la etapa 410 y mostraría el diálogo en la etapa 411 hasta que finalice la sesión. En otra modalidad de la invención, en lugar de preguntar si el usuario acepta o no el mensaje, (es decir, en lugar de la etapa 403), la terminal de usuario es configurada para aceptar un mensaje que no exceda un límite predefinido de tamaño. El límite predefinido de tamaño podría ser definido, por ejemplo, por un operador, por el fabricante de la terminal de usuario y/o por un usuario. A continuación, la señalización será descrita en mayor detalle con algunos ejemplos ilustrados en las Figuras 5A-8, utilizando el SDP (Protocolo de Descripción de Sesión) para iniciar una sesión y un MSRP a través de TCP para transmitir los actuales contenidos sin limitar la invención a estos ejemplos. Otra suposición realizada en conexión con los siguientes ejemplos es que la terminal de usuario de recepción no rechazará el mensaje. Si fuera requerida, podría encontrarse información adicional en http: //www. ietf . org/internet-drafts/draft-ietf-simple-message-sessions-10.txt, que se incorpora en la presente como referencia. Sin embargo, esto no tiene significancia para la invención acerca de cuáles protocolos son utilizados, los anteriores sólo son ejemplos. Por ejemplo, el lugar del SDP, podrían utilizarse otros protocolos de mecanismo de oferta-respuesta y el lugar del TCP, podrían utilizarse otros protocolos controlados de congestión tales como SCTP (Protocolo de Transporte Común de Señalización) . Las Figuras 5A, 5B, 5C ilustran algunos ejemplos de la manera como un mensaje de modo de sesión podría indicar que una invitación de modo de sesión es para un mensaje de modo de página . En la modalidad de la Figura 5A, un mensaje de modo de página es indicado a través de una combinación de una línea-m que contiene un nuevo indicador de modo de página 5-1 (m=mensaje 9 msrp modo de página) y un parámetro a=tamaño 1
máximo que indica el tamaño actual del mensaje 5-2 (a=tamaño máximo: tamaño actual). En la modalidad de la Figura 5B, un mensaje de modo de página es indicado a través de una combinación de la línea-m que contiene el nuevo indicador de modo de página 5-1 (m=mensaje 9 msrp modo de página) y un parámetro 5-3 a=tamaño actual que indica el tamaño actual del mensaje (a=tamaño-actual: tamaño actual). En esta modalidad, el parámetro a=tamaño máximo indica el tamaño máximo del mensaje. En la modalidad de la Figura 5C, un mensaje de modo de página es indicado por el parámetro 5-3 a=tamaño actual. Cuando el valor del parámetro difiera de 0, este indica, de manera implícita que el mensaje es un mensaje de modo de página, o viceversa. En esta modalidad, la información de línea-m indica que el MSRP será utilizado y el parámetro a=tamaño máximo indica el tamaño máximo del mensaje. En la modalidad de la Figura 5D, un mensaje de modo de página es indicado por la línea-m que contiene un nuevo indicador de modo de página 5-1 (m= mensaje 9 msrp modo de página) . En esta modalidad, el parámetro a=tamaño máximo indica el tamaño máximo del mensaje y ningún parámetro-a adicional es requerido. En el diagrama de señalización de la Figura 6, sólo es mostrada la señalización entre los puntos de extremo aunque podrían involucrarse uno o más puntos intermedios . La Figura 6 ilustra la señalización cuando un receptor, o de manera más precisa, un cliente correspondiente en la terminal de usuario del receptor, acepta el mensaje. La Figura 6 inicia cuando Alice quiere enviar un mensaje a Bob. La terminal de usuario UTI de Alice (de manera más precisa, un cliente correspondiente en UTI) observa en el punto 6-1 que el mensaje de modo de página tiene que eer enviado utilizando el mecanismo de modo de sesión. (El punto 6-1 es descrito en detalle con anterioridad en la Figura 2) . Por lo tanto, la UTl envía un mensaje de invitación de sesión 6-2 con una indicación de modo de página PMI a la terminal de usuario UT2 de Bob. De preferencia, el mensaje 6-2 es uno de los mensajes ilustrados en las Figuras 5A-5D. En respuesta a la recepción del mensaje 6-2 la UT2 detecta en el punto 6-3 que el mensaje es una invitación de modo de sesión para un mensaje de modo de página, y acepta la invitación enviando el mensaje 6-4. La UTI reconoce la aceptación enviando el mensaje 6-5, y posteriormente, la UTl envía los contenidos actuales del mensaje de modo de página en un mensaje de modo de sesión 6-6. En respuesta a la recepción de los contenidos, la UT2 almacena los contenidos en el punto 6-7, de modo que Bob pueda observarlos posteriormente. La UT2 también podría notificar a Bob, como se describió con anterioridad en las Figuras 3 y 4. En respuesta la recepción de los contenidos, la UT2 también reconoce la recepción mediante el envío de un reconocimiento de modo de sesión en el mensaje 6-8. En la modalidad ilustrada en la Figura 6, la terminal de usuario de emisión o envío, UTl, es configurada para terminar la sesión en respuesta al reconocimiento enviando el mensaje 6-9 a la UT2 , la cual entonces envía el mensaje 6-10 para reconocer la terminación. En el diagrama de señalización de la Figura 7, es mostrada la señalización entre los puntos de extremo por medio de un servidor participante de mensajería instantánea del punto final de recepción, aunque podría estar involucrado uno o más intermediarios. La Figura 7 ilustra la señalización cuando un receptor, o de manera más precisa un cliente correspondiente en la terminal de usuario de recepción, no acepta el mensaje sino que requiere que la red guarde el mensaje para su recuperación posterior. La Figura 7 inicia cuando Alice quiere enviar un mensaje a Bob. La terminal de usuario UTI de Alice (de manera más precisa, un cliente correspondiente en la UTI) observa en el punto 7-1 que el mensaje de modo de página tiene que ser enviado utilizando un mecanismo de modo de sesión. (El punto 7-1 es descrito en detalle con anterioridad en conexión con la Figura 2) . Por lo tanto, la UTI envía un mensaje de invitación de sesión 7-2 con una indicación de modo de página PMI a la terminal de usuario UT2 de Bob por medio del servidor. De preferencia, el mensaje 7-2 es uno de los mensajes ilustrados en las Figuras 5A-5D. En respuesta a la recepción del mensaje 7-2, la UT2 detecta en el punto 7-3 que el mensaje es una invitación de modo de sesión para el mensaje de modo de página. Por alguna razón, la UT2 no acepta el mensaje de modo de página sino que envía un mensaje de redireccionamiento 7-4 al servidor. Un ejemplo de mensajes de redireccionamiento es un mensaje SIP 302 "Movido en Forma Temporal" que podría contener información sobre cómo tiene que ser tratado un mensaje. Sin embargo, es irrelevante para la invención la manera cómo y con cuales protocolos la redirección es realizada y las instrucciones adicionales/información es/son dadas, si fuera necesario. Otros ejemplos incluyen la utilización de transacciones separadas utilizando los protocolos SIP, tales como SIP PUBLISH, SIP OPTIONS, llamadas capacidades en SIP REGISTER, o con XCAP (Protocolo de Acceso de Configuración de lenguaje de señalización extensible) . La UT2 también podría notificar a Bob acerca del mensaje, como se describió con anterioridad en conexión con las Figuras 3 y 4. En este ejemplo, el servidor y de manera más precisa un usuario-agente espalda-con espalda, acepta ofrecer un servicio alternativo y por lo tanto, el servidor supone por sí mismo que será el punto final de sesión y acepta la invitación inicial enviando el mensaje 7-5. La UTI reconoce la aceptación enviando el mensaje 7-6 al servidor, y posteriormente, envía los contenidos actuales del mensaje de modo de página en el mensaje de modo de sesión 7-7 al servidor. En respuesta a la recepción de los contenidos, el servidor almacena los contenidos en el punto 7-8, de modo que Bob pueda observarlos posteriormente. En respuesta a la recepción de los contenidos, el servidor también reconoce la recepción enviando un reconocimiento de modo de sesión en el mensaje 7-9. En la modalidad que se ilustra en la Figura 7, la terminal de usuario de envío UTI es configurada para terminar la sesión en respuesta al reconocimiento enviando el mensaje 7-10 al servidor, el cual posteriormente transmite el mensaje 7-11 para reconocer la terminación. A continuación, Bob podría observar los contenidos de mensaje posteriormente, aunque la implementación de esta visualización es irrelevante para la invención, y por lo tanto, no se discute en detalle en este documento. En el diagrama de señalización de la Figura 8, del mismo modo que en la Figura 7, se muestra la señalización entre los puntos de extremo por medio del servidor participante de mensajería instantánea del punto final de recepción, aunque podrían involucrarse uno o más puntos intermedios. La Figura 8 ilustra la señalización cuando un receptor, o de manera más precisa un cliente correspondiente en la terminal de usuario de recepción, no acepta el mensaje sino que solicita una GW de pasarela en la red para guardar el mensaje para su recuperación posterior. La Figura 8 inicia cuando Alice quiere enviar un mensaje a Bob. La terminal de usuario UTI de Alice (de manera más precisa, un cliente correspondiente en la UTl) observa en el punto 8-1, que el mensaje de modo de página tiene que ser enviado utilizando un mecanismo de modo de sesión. (El punto 8-1 se describió en detalle con anterioridad en conexión con la Figura 2). Por lo tanto, la UTl envía un mensaje de invitación de sesión 8-2 con una indicación de modo de página PMI a la terminal de usuario UT2 de Bob por medio del servidor. De preferencia, el mensaje 8-2 es uno de los mensajes que se ilustra en las Figuras 5A-5D. En respuesta a la recepción del mensaje 8-2, la UT2 detecta en el punto 8-3 que el mensaje es una invitación de modo de sesión para un mensaje de modo de página. Por alguna razón, la UT2 no acepta el mensaje de modo de página sino que envía un mensaje de redireccionamiento 8-4 al servidor, el mensaje de redireccionamiento indica que el mensaje tiene que ser transmitido a la pasarela GW. (Los mensajes de redireccionamiento fueron discutidos con anterioridad en conexión con la Figura 7). La UT2 también podría notificar a Bob acerca del mensaje, como se describió con anterioridad en conexión con las Figuras 3 y 4. En este ejemplo, el servidor y de manera más precisa, un usuario-agente espalda-con espalda genera una nueva petición a la URI (identificador uniforme de recursos) de la GW indicada en el mensaje 8-4 y envía la petición en el mensaje 8-5. De preferencia, la petición es una invitación de modo de sesión sin una indicación de modo de página. GW acepta la invitación inicial enviando un mensaje 8-6. La UTI reconoce la aceptación enviando el mensaje 8-7 a GW y posteriormente, envía los contenidos actuales del mensaje de modo de página en un mensaje de modo de sesión 8-8 a la GW. En respuesta a la recepción de los contenidos, GW almacena los contenidos en el punto 8-9, de modo que Bob los pueda observar posteriormente. En respuesta a la recepción de los contenidos, GW también reconoce la recepción enviando un reconocimiento de modo de sesión en el mensaje 8-10. En la modalidad ilustrada en conexión con la Figura 8, la terminal de usuario de envío UTI es configurada para terminar la sesión en respuesta al reconocimiento enviando el mensaje 8-11 a GW, la cual entonces envía el mensaje 8-12 para reconocer la terminación. Entonces, Bob podría observar los contenidos del mensaje posteriormente, aunque la implementación de esta visualización es irrelevante para la invención, y por lo tanto, no se discute en detalle en la presente. La Figura 9 ilustra la señalización de acuerdo con una modalidad adicional de la invención, en esta modalidad un servidor de mensajería instantánea también es configurado para detectar la indicación.. El servidor de mensajería instantánea podría ser un servidor separado o un componente de servidor en un nodo de red que comprende uno o más de otros componentes. En el ejemplo que se ilustra en la Figura 9, se supone que el receptor (UT2) no puede ser conectado o que tiene una configuración de acuerdo con la cual los mensajes de modo de página del receptor serán almacenados en el buzón de entrada de red del recipiente, en este ejemplo, se encuentra situado en el servidor. Esta también podría ser una configuración de red. En el diagrama de señalización de la Figura 9, se muestra la señalización entre un punto final de envío UTI y un servidor participante de mensajería instantánea del punto final de recepción, aunque uno o más puntos intermedios podrían estar involucrados. La Figura 9 inicia cuando Alice quiere enviar un mensaje a Bob. La terminal de usuario UTI de Alice (de manera más precisa, un cliente correspondiente en UTI) observa en el punto 9-1 que el mensaje de modo de página tiene que ser enviado utilizando un mecanismo de modo de sesión. (El punto 9-1 es descrito en detalle con anterioridad en conexión con la Figura 2). Por lo tanto, la UTI envía un mensaje de invitación de sesión 9-2 con una indicación de modo de página PMI a la terminal de usuario UT2 de Bob por medio del servidor. De preferencia, el mensaje 9-2 es uno de los mensajes ilustrados en las Figuras 5B-5C. En respuesta a la recepción del mensaje 9-2, el servidor y de manera más precisa un usuario-agente espalda-con-espalda detecta en el punto 9-3 que el mensaje es una invitación de modo de sesión para un mensaje de modo de página, y por lo tanto, verifica las UT2 de Bob, es decir, las configuraciones para los mensajes de modo de página. Debido a que las configuraciones mostraron que los mensajes de modo de página serán almacenados para su recuperación posterior, el servidor supone por sí mismo que será el punto final de sesión y acepta la indicación enviando el mensaje 9-4. La UTI reconoce la aceptación enviando el mensaje 9-5 al servidor, y posteriormente, envía los contenidos actuales del mensaje de modo de página en un mensaje de modo de sesión 9-6 al servidor. En respuesta a la recepción de los contenidos, el servidor almacena los contenidos en el punto 9-7, de modo que Bob los pueda observar posteriormente. En alguna otra modalidad de la invención, el mensaje podría ser almacenado en otro nodo de red o base de datos remota, o podría ser transmitido hacia una pasarela. En respuesta a la recepción de los contenidos, el servidor también reconoce la recepción enviando un reconocimiento de modo de sesión en el mensaje 9-8. En la modalidad que se ilustra en conexión con la Figura 9, la terminal de usuario de envío UTI es configurada para terminar la sesión en respuesta al reconocimiento enviando el mensaje 9-9 al servidor, el cual entonces envía el mensaje 9-10 para reconocer la terminación. A continuación, Bob podría observar los contenidos de mensaje posteriormente, aunque la implementación de esta visualización es irrelevante para la 7
invención y por lo tanto, no se discute en detalle en la presente. En otra modalidad de la invención, el servidor de mensajería instantánea del receptor es situado para decidir si o no enviar la petición de sesión o asumir por sí mismo que será un punto de finalización con base en el tamaño del mensaje, las capacidades de la terminal del receptor y/o la carga de la red. En una modalidad adicional basada en la Figura 9, el usuario podría tener una configuración de acuerdo con el cual los mensajes de modo de página que son transmitidos utilizando un mecanismo de modo de sesión son almacenados en el buzón de entrada de red y sólo son notificados al usuario, mientras que los mensajes de modo de página que son transmitidos utilizando el mecanismo de modo de página son transmitidos al usuario. Las etapas, puntos y mensajes de señalización que se muestran en las Figuras 2, 3, 4, 6, 7, 8 y 9 no se encuentran en un orden absoluto cronológico y algunas de las etapas/puntos podrían ser realizados de manera simultánea o en un orden diferente del orden dado. Otras funciones también pueden ser ejecutadas entre las etapas/puntos o dentro de las etapas/puntos . Algunas de las etapas/puntos o parte de las etapas/puntos también pueden ser dejados. Los mensajes y señalización sólo son de ejemplo e incluso podrían comprender varios mensajes separados para la transmisión de la misma información. Además, los mensajes también podrían contener otra información. Los mensajes y las etapas/puntos también pueden ser combinados o divididos con libertad en varias partes. Además, los nombres, tipos y/o contenidos de los mensajes podrían diferir de los mencionados con anterioridad, así como también de los protocolos utilizados. Aunque con anterioridad la invención ha sido descrita suponiendo que la comunicación, es decir, la transmisión de archivos y llamadas es una comunicación de uno-a-uno, es obvio para una persona experta en la técnica que la comunicación también podría ser una comunicación de uno-con-muchos . Las modalidades presentadas con anterioridad o partes de la misma pueden ser combinadas para producir las modalidades preferidas de la invención. Las terminales de usuario, otros dispositivos y/o servidores correspondientes o componentes correspondientes del servidor que implementa la funcionalidad de la presente invención no sólo comprenden medios de la técnica anterior sino también medios para el envío y/o recepción de mensajes de modo de página en el modo descrito con anterioridad. Los presentes nodos de red y terminales de usuario comprenden procesadores y memoria que pueden ser utilizados en las funciones de acuerdo con la invención. Todas las modificaciones y configuraciones requeridas para la implementación de la invención podrían ser realizadas como rutinas, las cuales a su vez podrían ser implementadas como rutinas agregadas o actualizadas de software, circuitos de aplicación (ASIC) y/o circuitos programables. Será obvio para una persona experta en la técnica que a medida que la tecnología avanza, el concepto inventivo puede ser implementado en varios modos . La invención y sus modalidades no son limitadas a los ejemplos descritos con anterioridad sino que podrían variar dentro del alcance de las reivindicaciones . Se hace constar que con relación a esta fecha el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.