ES2813430T3

ES2813430T3 - Método de comunicaciones basado en la capacidad de servicio y la presencia social

Info

Publication number: ES2813430T3
Application number: ES12275012T
Authority: ES
Inventors: Rogelio Martinez; Phillip Carter; Oscar Gallego; Alfonso Gomez; Jonathon Marchant
Original assignee: Vodafone IP Licensing Ltd
Current assignee: Vodafone IP Licensing Ltd
Priority date: 2011-02-11
Filing date: 2012-02-10
Publication date: 2021-03-23
Anticipated expiration: 2032-02-10
Also published as: US9065970B2; US8868072B2; US20120225652A1; EP2493166A1; EP2493166B1; US20140375747A1

Abstract

Un método para facilitar la comunicación entre un primer dispositivo (21) de comunicación y un segundo dispositivo (50) de comunicación usando una red (11) que soporta un primer y un segundo métodos de comunicación diferentes, que comprende las etapas de: iniciar, por medio del primer dispositivo (21) de comunicación, una comunicación entre el primer dispositivo comunicación y el segundo dispositivo (50) de comunicación usando el primer método de comunicación; determinar un primer indicador de estado de dispositivo de comunicación indicativo de la capacidad del primer dispositivo (21) de comunicación para comunicar usando el segundo método de comunicación en base a una conectividad de red actual del primer dispositivo (21) de comunicación; registrar, por medio del primer dispositivo (21) de comunicación, el primer dispositivo (21) de comunicación en una plataforma (20) de servicio de la red (11); solicitar desde la plataforma (20) de servicio un segundo indicador de estado de dispositivo de comunicación indicativo de la capacidad del segundo dispositivo (50) de comunicación para comunicar usando el segundo método de comunicación en base a una conectividad de red actual del segundo dispositivo (50) de comunicación, cuando un usuario del primer dispositivo (21) de comunicación selecciona un usuario del segundo dispositivo (50) de comunicación a partir de una visualización de usuarios en el primer dispositivo (21) de comunicación; recibir el segundo indicador de estado de dispositivo de comunicación desde la plataforma (20) de servicio, y permitir, mediante visualización de opciones de comunicación en el primer dispositivo (21) de comunicación, que el primer dispositivo (21) de comunicación comunique con el segundo dispositivo (50) de comunicación usando el segundo método de comunicación en dependencia del primer indicador de estado de dispositivo de comunicación y del segundo indicador de estado de dispositivo de comunicación recibido.

Description

DESCRIPCIÓN

Método de comunicaciones basado en la capacidad de servicio y la presencia social

Antecedentes de la invención

Rich Communications Suite (RCS) Versión 1, fue publicada por primera vez en Diciembre de 2008. RCS fue definida por la GSMA, una asociación de operadores de telecomunicaciones y compañías relacionadas, con el objetivo de producir un paraguas de servicios de comunicación avanzados que priorizan la ínter-operatividad de los servicios a través de operadores de red y de fabricantes de aparatos de telefonía. La RCS Versión 1 estableció los servicios y componentes principales a ser usados como parte de la RCS tal como libretas de direcciones mejoradas y chat, por ejemplo, mensajería instantánea. La RCS Versión 2 fue publicada en Junio de 2009 y amplió la Versión 1 para cubrir dispositivos de Acceso de Banda Ancha (BA) tales como PCs conectados a través de Wi-Fi adicionalmente a los dispositivos de telecomunicaciones móviles soportados por la Versión 1. La Versión 3, además de otras mejoras, incluyó la funcionalidad de que servicios de comunicación avanzados, tal como video, no requieran una llamada de voz para ser iniciados con anterioridad a la iniciación de los servicios de comunicación avanzados, tal y como habría sido el caso en las versiones anteriores.

Según se ha mencionado con anterioridad, la RCS define servicios de comunicación avanzados para su adopción. Ésta define los perfiles y la implementación para la adopción de servicios estandarizados ya existentes según ha sido definido por parte de varios organismos de estandarización, tal como 3rd Generation Partnership Project (3GPP), Open Mobile Alliance (OMA) o Internet Engineering Task Force (IETF). Los servicios de comunicación definidos por RCS incluyen chat, transferencia de archivos, compartir imagen y compartir video (unidireccional y bidireccional). Otra funcionalidad definida en RCS incluye libreta de direcciones mejorada (EAB), incluyendo capacidad de servicio y presencia social, libreta de direcciones de red (NAB), incluyendo copia de seguridad y restauración remotas, y mensajería mejorada incluyendo historia del mensaje.

Como parte de la EAB, la RCS incluye servicios para presencia social. La presencia social es un indicador de estado que muestra la disponibilidad de una persona para comunicar. Ésta puede variar desde lo simplista, tal como indicadores coloreados en rojo-ámbar-verde, a lo complejo, tal como el Protocolo de Inicio de Sesión para Mensajería Instantánea y Extensiones de Aprovechamiento de Presencia (SIMPLE) y el Protocolo Extensible de Mensajería y Presencia (XMPP), los cuales son estándares definidos y ampliamente adoptados. La presencia social es indicada por el usuario y a menudo almacenada en caché a nivel de red para que otros identifiquen fácilmente el estado de presencia indicado por el usuario. La presencia social no es autónoma sino que requiere publicación del estado social por cliente usuario.

Muchos de los servicios de comunicaciones estandarizados adoptados por RCS han existido durante una cantidad de tiempo considerable, habiendo sido implementados algunos de ellos en una diversidad de formas por diferentes operadores y fabricantes. Un ejemplo de ello es el hecho de compartir de forma bidireccional video o videollamadas como ha sido común en telecomunicaciones dado el uso generalizado de teléfonos 3G.

A pesar de la disponibilidad generalizada, la videollamada no ha sido adoptada por el consumidor medio. Una razón sugerida para la aparente falta de interés del consumidor en la tecnología es la inconsistencia del servicio y la confianza del usuario en la finalización potencial del servicio. Un usuario iniciará típicamente una videollamada con la esperanza de que el contacto esté en línea, tenga buena conectividad para una llamada de alta calidad, esté disponible para transmitir video y tenga un hardware capacitado para video.

La videollamada tiene una elevada tasa media de transferencia de datos y por lo tanto requiere una buena conectividad para una alta calidad de servicio. Adicionalmente, existe actualmente un pequeño número de modelos de aparatos de telefonía y por lo tanto de contactos que estén equipados para videollamada. No hay ningún método disponible actualmente para establecer, con anterioridad a la iniciación de la llamada, la probabilidad potencial de que la llamada se complete con éxito ni la calidad de la llamada.

Aunque lo anterior ha sido descrito en términos de videollamada, queda claro que los problemas se aplican a cualquier servicio de comunicación que requiera un cierto nivel de conectividad y capacidad de red. El usuario no tiene idea de si el destinatario tiene un dispositivo que sea capaz de comunicar usando el servicio, y de si el dispositivo tiene o no suficiente calidad de red para recibir el servicio.

Se han realizado algunos intentos para abordar este problema. Por ejemplo, el documento WO2006/052176 describe un sistema de comunicaciones de telefonía móvil en el que, durante una llamada en curso a través de una red de circuito conmutado entre un primer y un segundo terminales, cuando un terminal detecta que es posible la comunicación conmutada por paquetes, por ejemplo debido a una ubicación móvil, se intercambian mensajes de capacidad correspondientes entre los terminales y a continuación se indica al usuario del terminal la posibilidad de usar servicios multimedia. De una manera similar, el documento WO2006/121272 describe un cambio de llamada entrante en el estado del primer equipo de usuario que provoca la transferencia de una lista de comunicaciones a un segundo equipo de usuario. El documento US2008/0317010 describe un sistema y un método para reducir el tráfico de señalización cuando se comparte información de capacidades de compartir video entre UEs. Los modernos servicios de video, tal como Google TalkTM y Apple FaceTime® ofrecen videollamadas y otros servicios de comunicación avanzados en dispositivos móviles. Estos servicios requieren registro y por lo tanto no están disponibles para cualquier contacto en un dispositivo móvil y son servicios cerrados, es decir, no son interoperables con otros aparatos de telefonía producidos por otros fabricantes. Estos servicios proporcionan indicaciones online/offline mínimas junto con un mínimo de información de presencia social. Un usuario del servicio se enfrenta a los mismos problemas que los que se producen con videollamadas 3G donde los sistemas no están capacitados para identificar, ni garantizar, la calidad de servicio.

En resumen, en los servicios de comunicación avanzados conocidos, el usuario debe asumir que la comunicación sea viable y solo ser consciente de que ese no es el caso si se produce un fallo de la comunicación. Esta es una barrera continua y significativa para el uso de servicios de comunicación avanzados. La presente invención tiene como objetivo abordar todo esto y sus problemas relativos.

Compendio de la invención

La invención está definida por la reivindicación 1 independiente de método anexa. Otras realizaciones están definidas por las reivindicaciones 2 a 5 dependientes anexas.

Según un primer aspecto de la presente invención, se proporciona un método para facilitar la comunicación entre un primer dispositivo de comunicaciones operable para comunicar con un segundo dispositivo usando una red que soporta un primer y un segundo métodos de comunicación diferentes.

En sistemas de comunicaciones típicos, se requiere que exista una cierta cantidad de conjeturas por parte del usuario cuando inicia las comunicaciones. Por ejemplo, que el dispositivo del contacto esté encendido o que ambos tengan una conexión 3G, que el usuario del dispositivo haya conmutado a un modo en el que ambos no están recibiendo llamadas ni comunicaciones de un cierto tipo (p. ej., capacidad de videollamada deshabilitada por motivos de coste o de privacidad, ya sea mediante introducción manual o ya sea establecido automáticamente dependiendo de ciertos parámetros (tales como estado diario, ubicación, hora del día)). La conectividad de red del dispositivo tendrá un impacto directo sobre la calidad potencial del servicio de comunicación. La conectividad de red es un factor que está relacionado con la calidad de servicio. Los diferentes tipos de cobertura (2G, 3G, HSPA, LTE, por ejemplo) proporcionan impactos diferentes a servicios diferentes. Por ejemplo, la latencia en 3G comparada con LTE, puede no permitir ciertos servicios, a pesar de que haya ahí ancho de banda. Normalmente no existe ninguna indicación de las capacidades de conexión del dispositivo objetivo. En la presente invención, se proporciona al usuario una indicación a priori de la terminación del servicio, es decir se permite el método de comunicación dependiendo de la conectividad de red, mejorando significativamente de ese modo la experiencia del usuario.

Un usuario que interactúe con el dispositivo tiene así la seguridad del éxito potencial de la comunicación. La futilidad de intentar contactar con un dispositivo usando una forma avanzada de comunicación tal como video, solamente para encontrar que la conexión es imposible o inutilizable debido a un ancho de banda bajo, puede ser frustrante para el usuario. Por el contrario, el usuario está capacitado, con la presente invención, para intentar la comunicación con la confianza de saber que el servicio tendrá una probabilidad más alta de éxito de conexión y de calidad de conexión/servicio. Ventajosamente, no hay intercambio de datos privados para que se indique la probabilidad de éxito. El método de comunicación se permite dependiendo de la conectividad de red y por lo tanto, no se requiere el acceso a información de presencia social, que el usuario puede desear mantener privada.

El método puede comprender también, además, determinar un primer indicador de estado de dispositivo sobre la capacidad del primer dispositivo para comunicar usando el segundo método de comunicación en base a la conectividad de red actual del primer dispositivo; y, permitir que el primer dispositivo intente comunicar con el segundo dispositivo usando el segundo método de comunicación dependiendo del primer indicador de estado de dispositivo.

De este modo, la experiencia del usuario se mejora significativamente. Existe una confianza proporcionada al usuario en base a la calidad potencial del servicio. Aunque el dispositivo de destino pueda tener conectividad de red adecuada, el dispositivo local debe tener conectividad adecuada así como asegurar que la calidad de servicio sea alta y que se mantiene la experiencia del usuario.

La etapa de solicitud puede comprender además reenviar el indicador de estado de dispositivo a la plataforma de servicio para su reenvío al segundo dispositivo para que actualice su información de capacidad en cuanto al primer dispositivo o para almacenar en caché en la plataforma de servicio.

La etapa de permitir que el primer dispositivo comunique con el segundo dispositivo usando el segundo método de comunicación en función del segundo indicador de estado de dispositivo recibido, incluye visualizar opciones de comunicación en cuanto al segundo dispositivo por parte de un usuario del primer dispositivo conforme al segundo indicador de estado de dispositivo recibido, mejorando así aún más la experiencia del usuario del dispositivo.

Con anterioridad a la etapa de petición de un segundo indicador de estado de dispositivo, el método puede comprender también visualizar el primer método de comunicación a modo de opción seleccionable para el usuario y no visualizar el segundo método de comunicación como opción seleccionable, de tal modo que, cuando se selecciona, el dispositivo inicia comunicación con el segundo dispositivo usando el primer método de comunicación.

Se presenta por lo tanto al usuario solamente aquellas opciones de comunicación que puedan tener una alta probabilidad de éxito. Las comunicaciones de riesgo que sean dependientes de una buena conectividad de red, no se presentan al usuario antes de que se compruebe la conectividad de la red.

Si el primer dispositivo no puede ser registrado en la plataforma de servicio, el método puede comprender visualizar el primer método de comunicación como opción seleccionable para el usuario y no visualizar el segundo método de comunicación como opción seleccionable, de tal modo que, cuando se selecciona, el dispositivo inicia la comunicación con el segundo dispositivo usando el primer método de comunicación. Por lo tanto, de una manera similar a la anterior, las comunicaciones con riesgo que sean dependientes de una buena conectividad de red no son presentadas al usuario antes de que se pueda comprobar la conectividad de red, asegurando de ese modo una buena experiencia de usuario.

Si el segundo dispositivo no está capacitado para el uso del segundo método de comunicación, el método puede comprender también visualizar el primer método de comunicación como opción seleccionable para el usuario y no visualizar el segundo método de comunicación como opción seleccionable, de tal modo que, cuando se selecciona, el dispositivo inicia la comunicación con el segundo dispositivo usando el primer método de comunicación. Según lo anterior, se presenta por lo tanto al usuario solamente aquellas opciones de comunicación que tengan una alta probabilidad de éxito y las comunicaciones de riesgo que sean dependientes de una buena conectividad de red no son presentadas al usuario antes de que se compruebe la conectividad de la red.

El primero o el segundo o ambos indicadores de estado pueden depender de uno o más criterios seleccionado en un grupo que comprende calidad de servicio, funcionalidad del hardware del dispositivo, funcionalidad del software del dispositivo (por ejemplo, capacidades/códecs de software), estado del hardware del terminal y estado de aprovisionamiento del operador de red. El método puede así proporcionar también un contexto adaptativo para el despliegue de nuevos servicios por los operadores de red. La experiencia de usuario para esos nuevos servicios se incrementa y se dota al usuario con la información, con anterioridad al inicio de la comunicación, de que el servicio tendrá éxito. El Operador de Red puede provisionar los servicios en los dispositivos según se requiera para un despliegue efectivo. Adicionalmente, no se intentan los servicios de comunicación cuando el dispositivo objetivo no está capacitado para el procesamiento del método de comunicación.

Además, dado que los indicadores de estado pueden depender del estado del hardware del terminal, se pueden usar factores tales como vida de batería y almacenaje de archivos para determinar si el servicio de comunicación puede ser usado. Por ejemplo, no se puede intentar una transferencia de un archivo si el dispositivo destinatario no tiene espacio para almacenar el archivo. Por lo tanto, se mejora significativamente la experiencia de usuario.

Adicionalmente, el método puede comprender también intentar comunicar con el segundo dispositivo usando el segundo método de comunicación con anterioridad a la etapa de solicitar el segundo indicador de estado de dispositivo. La probabilidad de éxito del método de comunicación se comprueba antes de que el método haya sido iniciado por completo. El usuario puede ser, por lo tanto, advertido de una conexión de pobre calidad o de una funcionalidad inadecuada con anterioridad a que se complete la conexión.

Además, la etapa de solicitar el segundo indicador de estado de dispositivo puede ser llevada a cabo cuando un usuario del primer dispositivo selecciona el usuario del segundo dispositivo a partir de una visualización de usuarios en el primer dispositivo. De ese modo, como parte de la experiencia global de usuario, se descubren las capacidades de usuario del segundo dispositivo cuando se necesiten, es decir cuando se seleccione el contacto. Esto asegura que las capacidades estén actualizadas y que la confianza que el usuario pueda tener en cualquier conexión potencial sea alta. Con preferencia, las capacidades no están almacenadas en caché (el almacenamiento en caché podría ser potencialmente impreciso), sino que son descubiertas tras la selección para mejorar la precisión.

Adicionalmente, la etapa de solicitar el segundo indicador de estado de dispositivo puede ser llevada a cabo periódicamente conforme a una frecuencia predeterminada que asegure que las capacidades de aquellos contactos no se hayan seleccionados o que no se hayan contactado con frecuencia, están relativamente actualizadas.

El segundo método de comunicación puede tener una transferencia media de datos requerida más alta que el primer método de comunicación. Se puede permitir, por lo tanto, que el segundo método sea usado por el dispositivo si la conectividad de red del segundo dispositivo es suficientemente buena como para gestionar la conexión. Se permite que el primer método sea usado con independencia de la conectividad de red dado que tiene un tasa de transferencia media de datos requerida más baja.

El primer método de comunicación se inicia con anterioridad a la etapa de solicitud. De ese modo, se puede permitir la combinación de métodos de comunicación cuando la conectividad sea adecuada. Un ejemplo de todo esto es un intercambio de video mediante una llamada de voz, donde la llamada de voz se inicia en primer lugar, y se comprueba que el segundo dispositivo esté capacitado para intercambio de video y que esté permitido que haga esto. Adicionalmente, el método puede comprender también detectar un cambio en la conectividad de red del primer dispositivo, en donde la etapa de petición se realiza cuando existe un cambio que se haya detectado en la conectividad de red del primer dispositivo. De esta manera, se asegura que las capacidades están actualizadas mejorando con ello la experiencia de usuario.

El método puede comprender además: recibir una petición desde la plataforma de servicio para proporcionar un primer indicador de estado de dispositivo acerca de la capacidad del primer dispositivo para comunicar usando el segundo método de comunicación, incluyendo la petición un segundo indicador de estado de dispositivo acerca de la capacidad del segundo dispositivo para comunicar usando el segundo método de comunicación; determinar el primer indicador de estado de dispositivo en base a la conectividad de red actual del primer dispositivo; reenviar el primer indicador de estado de dispositivo a la plataforma de servicio; y, permitir que el primer dispositivo comunique con el segundo dispositivo usando el segundo método de comunicación en función del primer y segundo indicadores de estado de dispositivo, en donde el segundo indicador de estado de dispositivo depende de la conectividad de red actual del segundo dispositivo. De ese modo, se puede proporcionar al segundo dispositivo el estado del primer dispositivo para proporcionar servicios similares a los disponibles para el primer dispositivo, es decir que se permita que el método de comunicación dependa de los indicadores de estado.

Dentro de las modernas redes de comunicación, resulta cada vez más importante asegurar la operatividad de red para permitir la comunicación de extremo a extremo. Por ejemplo, un ordenador personal conectado a internet a través de un cable Ethernet y de una conexión ADSL, se puede esperar ahora que entre en contacto, por medio de un software adecuado, con un teléfono móvil inalámbrico. Esto se efectúa por medio de la red inalámbrica que está conectada a internet a través de una puerta de enlace de red apropiada. A los efectos de la invención, una red prevé por lo tanto, e incluye, una pluralidad de redes de comunicación diferentes pero interconectadas que son capaces, cada una de ellas, de soportar tanto el primer como el segundo métodos diferentes de comunicación, en donde el primer y el segundo dispositivos pueden estar capacitados para comunicar con la plataforma de servicio a través de redes de comunicación diferentes (p. ej., un teléfono móvil podrá comunicar a través de la red de telecomunicaciones móviles, mientras que un ordenador personal puede comunicar con la plataforma de servicio a través de una conexión de internet convencional). Con preferencia, el segundo indicador de estado de dispositivo depende de al menos uno de entre (i) la conectividad de red actual del segundo dispositivo, o (ii) la capacidad del método de comunicación del segundo dispositivo; o (iii) introducir manualmente información de estado de usuario; o (iv) información de estado de usuario generada automáticamente; o (v) funcionalidad de hardware del dispositivo; o (vi) funcionalidad de software del dispositivo; o (vii) calidad de servicio del método de comunicación. Al menos uno de entre el primer y el segundo dispositivos será normalmente un dispositivo de telecomunicaciones móviles.

Conforme a un segundo aspecto de la presente descripción, se proporciona un método de operación de una red que tiene una plataforma de servicio, soportando la red un primer y un segundo métodos de comunicación diferentes, comprendiendo el método: recibir una petición para el registro de un primer dispositivo en la plataforma de servicio; registrar el primer dispositivo en la plataforma de servicio; y, recibir una petición desde el primer dispositivo para proporcionar un segundo indicador de estado de dispositivo relativo a la capacidad de un segundo dispositivo para comunicar usando el segundo método de comunicación, en donde al menos uno de entre el primer y el segundo dispositivos es un dispositivo de telecomunicaciones móviles; y, en donde, si el segundo dispositivo está registrado en la plataforma de servicio, entonces: enrutar la petición hasta el segundo dispositivo; recibir el segundo indicador de estado de dispositivo desde el segundo dispositivo; y, enrutar el segundo indicador de estado de dispositivo recibido hasta el primer dispositivo, en donde, si el dispositivo no está registrado en la plataforma de servicio, entonces: proporcionar un segundo indicador de estado de dispositivo negativo al primer dispositivo. Típicamente, el segundo indicador de estado de dispositivo depende de la conectividad de red actual del segundo dispositivo.

El método puede también comprender además: registrar el segundo dispositivo en una plataforma de servicio de la red; determinar el segundo indicador de estado de dispositivo en base a la conectividad de red actual del segundo dispositivo; y, reenviar el segundo indicador de estado de dispositivo a la plataforma de servicio.

Según un tercer aspecto de la presente descripción, se proporciona un primer dispositivo de comunicaciones operable para comunicar con un segundo dispositivo usando una red que soporta un primer y un segundo métodos de comunicación diferentes, estando el primer dispositivo adaptado para: permitir que el primer dispositivo comunique con el segundo dispositivo usando el primer método de comunicación; registrar el primer dispositivo en una plataforma de servicio de la red; solicitar desde la plataforma de servicio un segundo indicador de estado de dispositivo en cuanto a la capacidad del segundo dispositivo para comunicar usando el segundo método de comunicación; recibir el segundo indicador de estado de dispositivo desde la plataforma de servicio; y, permitir que el primer dispositivo comunique con el segundo dispositivo usando el segundo método de comunicación en dependencia del segundo indicador de estado de dispositivo recibido. De nuevo, el segundo indicador de estado de dispositivo depende típicamente de la conectividad de red actual del segundo dispositivo. Habitualmente, al menos uno de entre el primer y el segundo dispositivos es un dispositivo de telecomunicaciones móviles.

Según un cuarto aspecto de la presente descripción, se proporciona una plataforma de servicio de una red, soportando la red un primer y un segundo métodos de comunicación diferentes, estando la plataforma de servicio adaptada para recibir una solicitud para registrar un primer dispositivo en la plataforma de servicio; registrar el primer dispositivo en la plataforma de servicio; y, recibir una petición desde el primer dispositivo para proporcionar un segundo indicador de estado de dispositivo en relación con la capacidad de un segundo dispositivo para comunicar usando el segundo método de comunicación, en donde, si el segundo dispositivo está registrado en la plataforma de servicio, la plataforma de servicio está adaptada para: enrutar la petición hasta el segundo dispositivo; recibir el segundo indicador de estado de dispositivo desde el segundo dispositivo; y, enrutar el segundo indicador de estado de dispositivo recibido hasta el primer dispositivo, en donde, si el segundo dispositivo no está registrado en la plataforma de servicio, la plataforma de servicio está adaptada para proporcionar un segundo indicador de estado de dispositivo negativo al primer dispositivo. Típicamente, el segundo indicador de estado de dispositivo depende de la conectividad de red actual del segundo dispositivo. Habitualmente, al menos uno de entre el primer y el segundo dispositivos es un dispositivo de telecomunicaciones móviles.

Según un aspecto adicional de la presente descripción, se proporciona un sistema para facilitar las comunicaciones entre dos dispositivos que comprende: un primer dispositivo según el tercer aspecto de la presente descripción; una entidad de red según el cuarto aspecto de la presente descripción, y un segundo dispositivo que está adaptado para: registrar el segundo dispositivo en una plataforma de servicio de la red; recibir una petición desde la plataforma de servicio para proporcionar un segundo indicador de estado de dispositivo relativo a la capacidad del segundo dispositivo para comunicar usando el segundo método de comunicación; determinar el segundo indicador de estado de dispositivo, preferiblemente en base a la conectividad de red actual del segundo dispositivo, y reenviar el segundo indicador de estado de dispositivo a la plataforma de servicio. Adicionalmente, al menos una parte de la red puede ser inalámbrica.

Según un aspecto adicional de la presente descripción, se proporciona un sistema de comunicaciones que comprende una red de comunicación que soporta un primer y un segundo métodos de comunicación diferentes y un primer dispositivo operable para comunicar con un segundo dispositivo usando dicha red, estando el sistema adaptado para permitir que el primer dispositivo comunique con el segundo dispositivo usando el primer método de comunicación, registrar el primer dispositivo en una plataforma de servicio de la red, solicitar desde la plataforma de servicio un segundo indicador de estado de dispositivo sobre la capacidad del segundo dispositivo para comunicar usando el segundo método de comunicación, recibir el segundo indicador de estado de dispositivo desde la plataforma de servicio; y, permitir que el primer dispositivo comunique con el segundo dispositivo usando el segundo método de comunicación en dependencia del segundo indicador de estado de dispositivo recibido.

Según otro aspecto de la presente descripción, se proporciona un producto de programa informático o un grupo de productos adaptados para llevar a cabo las etapas del primer o segundo aspectos de la presente invención.

Descripción detallada de los dibujos

Algunos ejemplos de la presente invención van a ser descritos ahora con detalle haciendo referencia a los dibujos que se acompañan, en los que:

La Figura 1 muestra una representación esquemática de un sistema para implementar la invención;

La Figura 2 muestra un diagrama de secuencia de puesta en marcha de un aparato de teléfono;

La Figura 3 muestra un diagrama de secuencia de descubrimiento de capacidad;

La Figura 4A muestra un diagrama de secuencia de sondeo de estado de capacidad usando OPCIONES DE SIP; La Figura 4B muestra un diagrama de secuencia de sondeo de estado de capacidad usando presencia;

La Figura 5A muestra un diagrama de secuencia de adición de contacto usando presencia donde el contacto sea compatible con RCS;

La Figura 5B muestra un diagrama de secuencia de adición de contacto usando OPCIONES DE SIP donde el contacto es compatible con RCS;

La Figura 6 muestra un diagrama de secuencia de adición de contacto donde el contacto no es compatible con RCS; La Figura 7 muestra un diagrama de secuencia de selección de contacto donde el contacto no es compatible con RCS; La Figura 8 muestra un diagrama de secuencia de selección de contacto donde el contacto es compatible con RCS; La Figura 9 muestra un diagrama de secuencia de iniciación de una sesión de chat;

La Figura 10 muestra un diagrama de secuencia de chat donde el contacto no está registrado;

La Figura 11 muestra un diagrama de secuencia de chat donde el mensaje no puede ser entregado;

La Figura 12 muestra un diagrama de secuencia de chat donde el contacto ha sido desregistrado;

La Figura 13 muestra un diagrama de secuencia de chat donde las capacidades han cambiado;

La Figura 14 muestra un diagrama de secuencia de transferencia de archivo;

La Figura 15 muestra un diagrama de secuencia de abandono de chat durante la transferencia de archivo;

La Figura 16 muestra un diagrama de secuencia de transferencia de archivo que ha sido rechazada;

La Figura 17 muestra un diagrama de secuencia de transferencia de archivo que ha sido cancelada;

La Figura 18 muestra un diagrama de secuencia de una conexión que se ha perdido;

La Figura 19 muestra un diagrama de secuencia donde no hay respuesta a una invitación;

La Figura 20 muestra un diagrama de secuencia de intercambio de video durante una llamada;

La Figura 21 muestra un diagrama de secuencia donde la conexión del aparato de teléfono ha caído desde 3G a 2G durante el intercambio de video;

La Figura 22 muestra un diagrama de secuencia de intercambio de video;

La Figura 23 muestra un diagrama de secuencia de una caída no ordenada desde 3G a 2G;

La Figura 24 muestra un diagrama de secuencia donde se envía una invitación alta tasa de transferencia de datos requerida a un dispositivo que tiene una conexión inapropiada, y

La Figura 25 muestra un diagrama de secuencia del envío de información de contacto.

Descripción detallada

Ahora se van a describir ejemplos de implementación de la divulgación; sin embargo, a efectos de entender el enfoque de contexto, se va a discutir en primer lugar la tecnología subyacente que se usa para implementar esos ejemplos.

Las abreviaturas que siguen van a ser usadas a través de la presente descripción:

3GPP 3rd Generation Partnership Project;

BA Acceso de Banda Ancha;

EAB Libreta de Direcciones Mejorada;

GPRS Servicio General de Radio por Paquetes

HSPA Acceso por Paquetes de Alta Velocidad;

HSPA+ Acceso por Paquetes de Alta Velocidad Evolucionado;

IETF Internet Engineering Task Force;

IMS Subsistema Multimedia de IP;

IP Protocolo de Internet;

LTE Evolución de Largo Plazo;

MSISDN Número de Red Digital de Servicios Integrados de Abonado Móvil;

MSRP Protocolo de Retransmisión de Sesión de Mensaje;

NAB Libreta de Direcciones de Red;

OMA Open Mobile Alliance;

QoS Calidad de Servicio;

RCS Rich Communication Suite;

RFC Solicitud de Comentarios;

RLS Servicio de Lista de Recursos;

RTP Protocolo de Transferencia en Tiempo Real;

SIMPLE Protocolo de Iniciación de Sesión para Mensajería Instantánea y Extensiones de Aprovechamiento de Presencia;

SIP Protocolo de Iniciación de Sesión;

UI Interfaz de Usuario;

XDMS Servidor de Gestión de Datos XML:

XML Lenguaje de Marcado Extensible, y

XMPP Mensajería Extensible y Protocolo de Presencia.

Rich Communications Suite (RCS) define servicios de comunicaciones ínter-operables a ser adoptados por operadores de red y fabricantes de teléfonos móviles. RCS adopta varios estándares existentes y define cómo deben ser implementados. Ésta utiliza el Subsistema Multimedia de IP (IMS) conocido para proporcionar el contexto para esos servicios. IMS es un contexto arquitectónico para suministrar servicios multimedia de protocolo de internet (IP). Uno de los componentes clave de IMS es el Protocolo de Inicio de Sesión (SIP) del protocolo de Internet Engineering Task Force (IETF) que se usa para controlar sesiones de comunicaciones multimedia a través de IP. La Figura 1 muestra, esquemáticamente, un ejemplo de sistema 10 RCS. Una pluralidad de dispositivos 12, 13, 14, 15, 16 y 17 pueden ser conectados a una red central del operador de red por medio de una diversidad de métodos de conexión. Estos pueden incluir 2G GPRS, 3G GPRS, HSPA/HSPA+, Wi-Fi, Acceso de Banda Ancha (BA) o 4G como por ejemplo Wi-Max o LTE. Los dispositivos pueden incluir cualquier dispositivo adecuado para comunicaciones de IP tal como un teléfono móvil, un teléfono inteligente, un asistente digital personal, un ordenador portátil equipado con una tarjeta de datos o un ordenador personal o un PC conectado a través de BA o por Wi-Fi. En comunicación con la red 11 central del operador de red se encuentra el Subsistema Multimedia de IP (IMS) 20. El IMS proporciona una forma de Convergencia Fija-Móvil (FMC) que ayuda a la comunicación de aplicaciones multimedia y de voz desde terminales inalámbricos a fijos. Adicionalmente, en comunicación con la red 11 puede haber varios servidores tal como servidores 18 de presencia o servidores 19 de mensajería instantánea, que proporcionan instalaciones y almacenaje para esos servicios.

Según se ha mencionado con anterioridad, RCS e IMS usan el protocolo SIP con el fin de controlar las sesiones de comunicaciones multimedia a través de IP definidas en la serie. SIP es un protocolo basado en texto donde cada transacción consiste en una petición de un cliente, que invoca un método o función particular en el servidor, y una respuesta. Cada petición de SIP tiene un método que define su naturaleza tal como INVITE u OPCIONES. Cada respuesta contiene un código combinado con información adicional; estos códigos definen el éxito o el fallo de la petición.

Una vez que las sesiones han sido iniciadas, se pueden usar otros protocolos para facilitar la comunicación, tal como el protocolo de transmisión de sesión de mensaje (MSRP) o el Protocolo de Transferencia de Transmisión (RTP). MSRP se usa típicamente en RCS para mensajería instantánea, transferencia de archivo e intercambio de imagen, mientras que RTP se usa para intercambio de video. Aunque en la presente memoria se describe que estos protocolos y servicios pueden ser usados en los ejemplos de realización de la presente invención, se debe entender que se pueden utilizar cualesquiera protocolos adecuados para llevar a cabo los conceptos que se describen de la presente invención.

En la especificación RCS, el modelo de petición y respuesta de SIP se usa para una diversidad de funciones. Un ejemplo de ello es el método de PUBLICAR SIP que se usa para hacer públicas las capacidades de dispositivo del aparato de teléfono del cliente. Por ejemplo, el dispositivo usará el método de PUBLICAR SIP para enviar a un servidor (en RCS éste es el servidor de presencia) que el dispositivo es un dispositivo compatible con RCS y los servicios para los que el dispositivo resulta adecuado. Esta información de dispositivo podrá ser almacenada a continuación de modo que pueda ser recuperada posteriormente desde el servidor por medio de otro dispositivo que use un método de SUBSCRIBIR SIP. El método de SUBSCRIBIR SIP puede ser anónimo y podría devolver las capacidades de RCS, es decir, el hardware de terminal, del dispositivo en cuestión.

En la especificación RCS no existe ninguna consideración de la disponibilidad del cliente para una comunicación distinta del método de presencia social que está definida como parte de la serie. RCS usa el protocolo de iniciación de sesión para mensajería instantánea y extensiones de aprovechamiento de presencia (SIMPLE) para definir la implementación de presencia social. La presencia social está extendida entre aplicaciones de mensajería instantánea y proporciona una adición clave a interacciones de usuario. No existe ninguna consideración, sin embargo, de la conectividad de red o de la disponibilidad autónoma del cliente distintas de la presencia social que sea publicada por el usuario.

SIMPLE usa la petición de PUBLICAR SIP (RFC 3903) para permitir que los usuarios informen al servidor de presencia de sus estados actuales. Los mensajes de estado común pueden incluir “salir a comer”, “ocupado”, “fuera” y “en línea”. Un cliente puede suscribirse para recibir actualizaciones de presencia desde el servidor de presencia para un contacto particular. Cuando se descarga la presencia social en el servidor de presencia, el mensaje puede ser enviado al dispositivo de cliente. Las actualizaciones sociales son iniciadas por el usuario del dispositivo de cliente y no son autónomas.

Cuando el dispositivo hace pública la información de presencia social en el servidor de presencia, el servidor de presencia utiliza la respuesta de SIP ‘200 OK’ para acusar recibo. El servidor de presencia envía a continuación la presencia social a aquellos observadores suscritos que usan la petición NOTIFICAR de SIP. La respuesta del observador devolverá a continuación ‘200 OK’ como respuesta. El estado de presencia social de texto libre es posible usando el contexto SIMPLE donde la petición de PUBLICAR puede incorporar el mensaje de estado deseado del usuario.

El Protocolo de Mensajería Extensible y Presencia (XMPP) es un protocolo de comunicaciones alternativo que incorpora información de presencia social. Al igual que con SIMPLE, el protocolo XMPP requiere que la presencia social sea publicada por el usuario. Ésta es la clave para la presencia social, donde la flexibilidad de la experiencia de usuario es importante. La presencia social no incluye ninguna indicación del estado del dispositivo o de su conectividad, sino que en cambio incluye una indicación de la disponibilidad del usuario que opera el dispositivo y de su estado.

Con presencia social, los intentos de comunicación no son inhibidos sino que la presencia social es simplemente una indicación del estado del usuario. Este puede ser el caso de que, aunque el usuario haya indicado su presencia como que está “fuera”, pueden aún desear comunicar de forma selectiva. El modelo de PUBLICAR/NOTIFICAR SIP requiere que el usuario esté suscrito para que el usuario reciba las notificaciones. Adicionalmente, muchos de los mensajes de presencia social pueden ser privados para el usuario y sus contactos.

La presencia social es un componente de la libreta de direcciones mejorada (EAB) de RCS, de la que otra característica es la información de capacidad. Típicamente, los contactos de la libreta de direcciones pueden ser identificados como si estuvieran usando un dispositivo compatible con RCS. Las capacidades de RCS incluyen los servicios que el dispositivo es capaz de usar, por ejemplo el dispositivo puede tener una cámara enfrentada hacia delante y que por lo tanto esté capacitado para videollamada. Esta información está almacenada en el servidor de presencia junto con información de presencia. Las capacidades de servicio son publicadas usando el método de PUBLICAR SIP de una manera similar a la publicación de presencia social. Al igual que con presencia social, estas capacidades son enviadas a usuarios suscritos. Si el usuario ha adquirido un dispositivo compatible con RCS, las capacidades serán publicadas en el servidor de presencia y enviadas a los contactos suscritos.

Adicionalmente, dentro de un RCS, cuando se establece una videollamada, los dispositivos pueden intercambiar capacidades. Las capacidades se intercambian usando una pregunta de OPCIONES DE SIP y la respuesta correspondiente. Un destinatario compatible con RCS recibirá y responderá a la pregunta de opciones. La respuesta incluirá las opciones de comunicación para las que el dispositivo está capacitado. Este intercambio de opciones ocurre solamente durante una llamada de voz y no afecta a las capacidades mostradas en la EAB que están basadas en el modelo de PUBLICAR/NOTIFICAR SIP.

Si, durante una llamada de voz, el usuario desea compartir algún contenido, se utiliza la solicitud de SIP INVITE que se reenvía a todos los clientes compatibles en la conversación. Si el usuario acepta la invitación, se envía una respuesta de ‘200 OK’. Se envía una respuesta ‘603’ si la invitación es rechazada. En este sistema, no existe ninguna indicación del éxito potencial de la comunicación en base a la conectividad de red del destinatario. El intercambio de OPCIONES DE SIP puede ser usado para actualizar la capacidad del dispositivo de compartir el contenido durante una llamada. Por ejemplo, si el dispositivo tiene una cámara enfrentada hacia delante, el dispositivo puede estar capacitado para videollamada, pero si están conectados por una conexión de baja tasa de datos, la calidad puede ser muy pobre. En las publicaciones de RCS, se proporciona solamente una indicación de presencia social y las capacidades de dispositivo usando PUBLICAR SIP u OPCIONES DE SIP durante una llamada. No existe ninguna indicación de presencia de red, es decir de la conectividad de red, y por lo tanto del éxito o la calidad de la terminación potencial del servicio.

Ahora se van a describir ejemplos de implementación de la presente invención.

En una realización, el usuario puede seleccionar un contacto compatible a partir de su libreta de direcciones. Cuando esto ocurre, el dispositivo puede llevar a cabo una comprobación de capacidad de servicio instantánea cuando se visualizan los servicios disponibles. Esto puede ser implementado usando OPCIONES DE SIP. Según se ha descrito con anterioridad, OPCIONES DE SIP es una petición de igual a igual enrutada por la red al dispositivo de cliente que deberá generar uno de dos tipos de respuesta. En primer lugar, si el contacto está registrado para el servicio, entonces se retornarán las capacidades del servicio de contacto en ese instante de tiempo. Éstas son recibidas a continuación y registradas por el cliente. En segundo lugar, si el usuario no está registrado o bien no se ha encontrado, un mensaje indicando todo esto será devuelto por el IMS 20. Este mecanismo permite que el cliente determine qué servicios están disponibles con anterioridad a que se realice la llamada. Se pueden usar las OPCIONES DE SIP para descubrir inicialmente (y/o comprobar periódicamente) las capacidades de servicio de todos los contactos de la libreta de direcciones cuando el usuario se registra para el servicio, con independencia de cuantos existan.

Las capacidades devueltas en respuesta a una petición de OPCIONES, representan la lista de servicios a los que el cliente puede acceder en un determinado instante de tiempo. Puede existir un número de factores que afecten a las capacidades del dispositivo. En primer lugar, la capacidad puede depender del estado de aprovisionamiento del operador de red del usuario. El operador de red puede elegir limitar el servicio a los clientes dependiendo de su estado de pago. Por ejemplo, se puede permitir que el usuario chatee o comparta archivos, pero estar limitado en cuanto al uso de video. En segundo lugar, el hardware del terminal puede afectar a la capacidad de uso del servicio. Por ejemplo, el hardware puede que no tenga ninguna capacidad de procesamiento de video ni ninguna cámara enfrentada hacia delante, pero puede estar capacitado para recibir transferencias de archivos. En tercer lugar, el estado del terminal puede afectar a su capacidad. Por ejemplo, puede que el terminal no esté capacitado para recibir archivos si su almacén está lleno o puede que no esté capacitado para usar comunicación avanzada si el dispositivo tiene batería baja cuando el procesamiento intensivo puede drenarla. Además, las capacidades de software y la compatibilidad mutua de software entre los dispositivos pueden afectar a las capacidades del dispositivo. Finalmente, ciertos servicios pueden requerir un determinado nivel de calidad de servicio de la red. Por ejemplo, transmitir video sobre una señal GPRS 2G no proporciona la experiencia de usuario adecuada.

La calidad de servicio (QoS) consiste en mecanismos de control en cuanto a rendimiento, fiabilidad y usabilidad de telecomunicaciones. La métrica usada en la evaluación de la QoS puede ser, entre otros, calidad, accesibilidad y cobertura de audio. Estos indicadores pueden ser usados para evaluar el éxito potencial de un servicio de comunicaciones. Por ejemplo, una QoS baja puede afectar a las comunicaciones de red que tengan una tasa media de datos elevada. Se puede necesitar un buen nivel de QoS para aplicaciones particulares.

Un ejemplo de resumen de los requisitos de servicio para métodos de comunicación avanzados es como sigue. El chat puede estar disponible en todas las conexiones, la transferencia de archivo (si el destinatario tiene espacio para almacenar el archivo) puede no ser adecuada sobre GPRS 2G cuando la transferencia puede ser muy lenta para el usuario pero puede ser permitida a través de conexiones más rápidas. De forma similar, compartir imagen puede no ser adecuado sobre GPRS 2G cuando la experiencia de usuario pueda ser pobre. En un ejemplo adicional, compartir video puede ser una forma solamente a través de GPRS 3G, pero puede ser enviado y recibido simultáneamente a través de conexiones más rápidas.

Ventajosamente, un nivel bajo de batería puede impedir algunos o todos los servicios. En la implementación descrita, el intercambio de video y de imagen tiene lugar solamente una vez que se ha establecido una llamada de voz activa. Esta llamada de voz no debe ser una llamada multiparte, no debe quedar en espera ni tampoco debe tener lugar un reenvío o un desvío. En la realización descrita, el chat está siempre disponible puesto que este no requiere ninguna conexión rápida. Se contempla que este puede que no sea siempre el caso y que las realizaciones descritas deben ser entendidas como ejemplos.

El modelo de petición y respuesta de OPCIONES requiere que el intercambio de capacidad sea recíproco. Se comprenderá que esto no se necesite; el intercambio de capacidad puede ser unidireccional solamente. En la implementación descrita, el intercambio es recíproco y las capacidades del dispositivo pueden ser diferentes y los servicios estar disponibles para el usuario de manera correspondiente. Aunque el dispositivo del cliente puede soportar codificación de video y el destinatario puede soportar descodificación, y por lo tanto se puede suponer que el intercambio de video debe ser posible, ambos dispositivos podrían necesitar una conexión suficiente para que la conexión sea permitida por los dispositivos.

Si lo permite la configuración, cuando se enciende el aparato de teléfono, se puede llevar a cabo el proceso mostrado en la Figura 2. El aparato de teléfono se registra en la central 20 de IMS cuando el aparato de teléfono se enciende y puede ser mantenido hasta que el aparato de teléfono se apague. En primer lugar, se envía una solicitud de REGISTRO DE SIP al IMS 20 (etapa 23) desde el dispositivo 21 de cliente. Según se muestra en la etapa 24, la respuesta es una respuesta ‘200 OK’ de SIP.

La autorización puede ser responsabilidad de la red y no está basada en un desafío ni en una respuesta de ID/contraseña de usuario procedente del dispositivo del cliente, aunque también se contempla este caso. Cuando el REGISTRO ha sido reconocido por el IMS 20, el dispositivo 21 de cliente PUBLICARÁ sus capacidades para su almacenaje en el IMS 20 (etapa 25) y el IMS 20 devuelve a continuación una respuesta de OK cuando son recibidas (etapa 26). Las capacidades pueden ser almacenadas en un servidor de presencia.

Si, por ejemplo, el dispositivo de cliente se está apagando, su batería está baja, se enfrenta a una pérdida inminente de cobertura o tiene un cambio de portadora de datos o un cambio de configuración de IP, el dispositivo de cliente puede desear desregistrarse del IMS 20. Esto puede hacerse usando un método de petición de REGISTRO DE SIP con un mensaje relevante que pueda ser reconocido por el IMS 20 usando un mensaje ‘200 OK’ de SIP.

Se prevé que, como parte de la interfaz 22 de usuario, se debe generar y mantener una lista por parte del cliente de los contactos registrados y no registrados. Este sistema puede ser usado, por ejemplo, cuando el usuario desea compartir una imagen procedente de la galería multimedia en la transferencia de un archivo. Una vez que la foto ha sido seleccionada, se mostrará al usuario una lista de contactos con el fin de que seleccione el contacto objetivo para la transferencia del archivo. Esta lista, en vez de tener todos los contactos en la libreta de direcciones, contendrá solamente los contactos descubiertos capacitados (es decir, los que puedan soportar la transferencia del archivo). Una vez que se ha seleccionado un contacto a partir de la lista mencionada con anterioridad, tiene lugar el intercambio de OPCIONES para actualizar las capacidades y verificar que la transferencia puede tener lugar en ese instante de tiempo, lo que se va a discutir con mayor detalle a continuación.

Una vez que el usuario ha sido registrado en el IMS de la red, se pueden descubrir las capacidades de un usuario de la lista de contactos. Un método a considerar consiste en usar el modelo de OPCIONES DE SIM. Alternativamente, se puede usar el método de descubrimiento de presencia. El mecanismo de descubrimiento de OPCIONES ha sido mostrado en la Figura 3. En la etapa 30, la petición de OPCIONES se envía desde un cliente A a través de la red central de IMS a un usuario B. En este escenario, se está suponiendo que el usuario B está registrado, el usuario C no está registrado y el usuario D no es un usuario compatible. El usuario B devuelve un mensaje de OK 200 de SIP que incluye sus capacidades en respuesta al mensaje de OPCIONES procedente del dispositivo de cliente (etapa 31). El cliente envía a continuación un mensaje de OPCIONES DE SIP al usuario C (etapa 32). Se devuelve un mensaje 480 de error por parte del IMS 20 titulado ya sea ‘no registrado’ o ya sea ‘solicitar tiempo de espera’ (etapa 33). Si el usuario B no está actualmente registrado (p. ej., el teléfono está apagado, fuera de cobertura o itinerante con servicios de datos deshabilitados), entonces la red puede responder ya sea con el mensaje 480 ‘no registrado’ (se llevó a cabo una cancelación no ordenada del registro) o ya sea con ‘solicitar tiempo de espera’ (etapa 33). Estos mensajes significan que el usuario es un usuario compatible pero que no está en ese momento registrado con el IMS 20. El cliente envía a continuación un mensaje de OPCIONES DE SIP al IMS 20 destinado al usuario D (etapa 34). El IMS 20 devuelve un mensaje 404 de error de ‘no encontrado’ (etapa 35). Este mensaje significa que el usuario no es un usuario capacitado, sin que haya sido provisionado para esos servicios RIC de comunicación y que el IMS 20 no tiene conocimiento alguno del usuario. Los usuarios B, C y D no necesitan ser registrados en el momento en que se realiza la pregunta de OPCIONES DE SIP por parte del dispositivo de cliente para determinar están o no provisionados para su uso con los servicios puesto que el IMS 20 mantiene el reconocimiento de sus detalles, devolviendo una respuesta de que los mismos no están actualmente registrados pero que están provisionados para el servicio, es decir el mensaje 480.

Los mensajes de intercambio de OPCIONES DE SIP pueden ser enviados en los siguientes escenarios:

• registro posterior a la primera vez para obtener un conjunto por defecto de capacidades según se muestra en la Figura 3;

• cuando se añade un nuevo contacto a la libreta de direcciones del teléfono según se muestra en la Figura 5B;

• periódicamente, con la frecuencia determinada por un parámetro predeterminado que asegure que las capacidades están actualizadas cuando los usuarios no son contactados de manera frecuente, como se muestra en la Figura 4A;

• cuando se modifican o se añaden MSISDNs (cuando los usuarios tienen varias suscripciones y cada suscripción está asociada potencialmente a una cuenta compatible);

• cuando se comprueban las capacidades disponibles de comunicación con otro usuario según se muestra en la Figura 8;

• al comienzo de una llamada de voz o de otra sesión de comunicación para obtener capacidades en tiempo real, según se muestra en la Figura 9;

• durante una llamada de voz cuando las capacidades cambian, como se muestra en la Figura 21, y

• siempre que exista un evento de comunicación con otro usuario en la libreta de direcciones donde exista un MSISDN válido (es probable que el usuario esté en línea y que sus capacidades puedan ser fácilmente actualizadas).

Alternativamente, se puede usar el sistema de presencia como mecanismo de descubrimiento. En este mecanismo, la lista de contactos está cotejada y se envía una petición de SUCRIBIR SIP ANÓNIMO al IMS y se acusa recibo. Un mensaje de NOTIFICAR SIP se envía de nuevo al cliente desde la central de IMS, que incluye las capacidades por usuario registrado como una respuesta agregada. No se hará referencia alguna a ninguno de los usuarios que no esté capacitado para comunicar por medio de los servicios.

Aunque se describe que el IMS puede agregar la respuesta de NOTIFICAR, ésta puede ser una opción de configuración de red y NOTIFICAR pueda consistir de hecho en varias respuestas individuales correspondientes a cada contacto.

Una vez que el usuario ha sido registrado en el sistema de IMS, puede ser deseable descubrir las capacidades de los contactos en la libreta de direcciones periódicamente. Las capacidades de los usuarios pueden ser sondeadas según un parámetro predeterminado indicativo de la frecuencia. El mecanismo para hacer esto ha sido mostrado en las Figuras 4A y B. La Figura 4A muestra el método de sondeo de los dispositivos usando el modelo de OPCIONES DE SIP. El mecanismo del mensaje de OPCIONES se usa para preguntar secuencialmente las capacidades y el estado de cada contacto de una manera similar al método que se produce cuando el usuario se registra primero en el IMS. El cliente envía un mensaje de opciones a cada usuario por turno (etapas 41, 43 y 45) y las respuestas (etapas 42, 44 y 46) indican las capacidades de los dispositivos.

La Figura 4B muestra un diagrama de secuencia de un mecanismo de sondeo configurado para usar el mecanismo de descubrimiento de capacidad de presencia. Según se ha descrito con anterioridad, en este mecanismo, la petición de SUSCRIBIR SIP ANÓNIMO se envía a la red 20 central de IMS desde el dispositivo 21 de cliente (etapa 40). Acompañando a la petición hay una lista de contactos. Esto significa para la central de IMS que al dispositivo le gustaría conocer la información de presencia y capacidad de esos contactos. La lista puede estar almacenada previamente como lista de XDMS para la interoperabilidad entre el dispositivo de cliente y el IMS. Cuando cada petición tiene éxito, se acusa recibo con una respuesta ‘200 OK’ de SIP (etapa 47).

En respuesta a la petición de SUSCRIBIR SIP ANÓNIMO, la central de IMS puede transmitir una respuesta de RLS (etapa 48). El servidor de lista de recursos (RLS) se usa en la aplicación de presencia de IMS, dado que optimiza la gestión de señalización de presencia intensiva, y agrega información para abonados desde dentro de la red central de IMS. El uso de un RLS puede reducir las demandas de la aplicación de Presencia de IMS sobre recursos de red de acceso restringido. Puesto que la información de presencia social no es relevante en ese caso, la respuesta de RLS se ignora.

En la etapa 49 el IMS usa el método de NOTIFICAR SIP para transmitir las capacidades de cada usuario registrado. Al igual que con el descubrimiento descrito con anterioridad, no se hará ninguna referencia a ninguno de los usuarios que no esté capacitado para comunicar a través de los servicios, y la respuesta puede ser agregada o no dependiendo de la configuración.

Cuando se añade un nuevo contacto a la libreta de direcciones, hay necesidad de determinar si el MSISDN añadido recientemente identifica un abonado de IMS. Esta secuencia ha sido mostrada en las Figuras 5A y 5B. La Figura 5A muestra la secuencia cuando el dispositivo está configurado para usar el mecanismo de descubrimiento de presencia, y la Figura 5B muestra cuándo está el dispositivo configurado para usar el método de descubrimiento de OPCIONES.

En la Figura 5A, en primer lugar, un mensaje de SUSCRIBIR SIP se envía al IMS 20 (etapa 51). Si el contacto es un abonado de IMS, el IMS 20 devuelve un mensaje de ‘200 OK’ de SIP al dispositivo 21 de cliente (etapa 52). La interfaz de usuario mostrará probablemente a continuación el contacto como un contacto inteligente capacitado para comunicación avanzada. El IMS 20 enviará a continuación un mensaje de NOTIFICAR al cliente 21 con capacidades almacenadas en caché (etapa 53) para su almacenaje por el cliente y su posterior uso en la interfaz de usuario. En este punto, no se requiere que las capacidades del contacto sean actualizadas puesto que el usuario no ha seleccionado el contacto a partir de la lista, ni ha empezado a iniciar la comunicación. Se usará OPCIONES DE SIP en un instante posterior para asegurar que esas capacidades sean actualizadas. En ese punto, la información clave es la que proporcione un abonado de IMS y sea potencialmente capaz de comunicación inteligente. Las capacidades actualizadas basadas en conectividad de red pueden ser calculadas más tarde cuando se seleccione el contacto individual.

La Figura 5B muestra la secuencia de etapas llevadas a cabo cuando se añade un nuevo contacto a la libreta de direcciones y el cliente 21 está configurado para descubrimiento de OPCIONES. Se envía un mensaje de OPCIONES De SIP desde el cliente 21, a través de la red 20 de IMS hasta el dispositivo 50 de contacto (etapa 54). El mensaje de OPCIONES DE SIP incluye las capacidades del dispositivo cliente. Si el nuevo contacto 50 ha sido provisionado para servicios inteligentes y está registrado en el IMS, se recibe una respuesta ‘200 OK’ de SIP que incluye las capacidades del dispositivo (etapa 55). Si el nuevo contacto no está registrado ni provisionado para el servicio, se recibe una de las respuestas de error mencionadas con anterioridad (etapa 56). Esta información puede ser almacenada en el teléfono y puede ser comprobada periódicamente mediante sondeo.

Cuando el dispositivo de cliente está configurado para descubrimiento de presencia, si un nuevo contacto no está suscrito en el IMS y está capacitado para comunicaciones avanzadas, según se muestra en la Figura 6, entonces cuando el cliente 21 transmite un mensaje de SUSCRIBIR SIP al IMS 20 (etapa 61), éste devolverá un mensaje ‘404’ de SIP que pone de relieve que el usuario llamado es desconocido (etapa 62). En este punto, la interfaz de usuario mostrará al usuario que el contacto no es un contacto inteligente y no se permitirán comunicaciones avanzadas con independencia de la conectividad. La interfaz de usuario puede mostrar la misma información (inteligente/no inteligente) con independencia del mecanismo de descubrimiento utilizado.

En la libreta de direcciones de la interfaz de usuario, el usuario tendrá acceso a los servicios de comunicaciones. Cuando se selecciona el contacto, la capacidad de servicio se actualiza por medio de OPCIONES DE SIP para proporcionar el estado actual, en tiempo real, para el cliente. Los servicios disponibles serán presentados al usuario para la selección.

En primer lugar, en la interfaz 22 de usuario, el usuario abre la agenda del teléfono para buscar un contacto. La Figura 7 muestra la situación en la que el cliente no está disponible para la comunicación. El usuario selecciona un contacto en la libreta de direcciones. Tan pronto como esto ocurre, y siempre que el contacto 50 sea adecuado (información previamente obtenida a través de descubrimiento de presencia o de opciones), la interfaz 22 de usuario puede mostrar solamente aquellas comunicaciones que estén siempre disponibles, o bien, en su caso, mostrar aquellos servicios potencialmente disponibles identificados a través de los mecanismos de descubrimiento. Aquellos servicios que no estén disponibles pueden ser visualizados como en color gris de modo que estos no puedan ser seleccionados o pueden no ser visualizados en absoluto. A continuación, se envía un mensaje de OPCIONES al cliente 50 para actualizar las capacidades del contacto (etapa 72). En este escenario, se devuelve una respuesta de no éxito desde la central de IMS (etapa 73). Puesto que el mensaje de opciones ha fallado, las comunicaciones inteligentes se muestran como no disponibles al usuario en la interfaz 22 de usuario y las mismas se consideran como no disponibles. Estas pueden mostrarse en color gris o no ser mostradas en absoluto.

La Figura 8 muestra la secuencia en que el dispositivo de cliente está capacitado para comunicaciones avanzadas. El usuario entra en primer lugar en la agenda del teléfono para buscar un contacto. Una vez que se ha seleccionado un contacto, las capacidades almacenadas en caché pueden ser mostradas o solamente pueden ser mostradas las comunicaciones básicas, por ejemplo, voz o SMS. Un mensaje de OPCIONES se envía a continuación al dispositivo 50 de contacto, enrutado por el IMS 20, para actualizar las capacidades (etapa 81). En este escenario, el mensaje de OPCIONES contiene la capacidad del dispositivo de cliente. El dispositivo 50 de cliente actualizará entonces las capacidades almacenadas para el dispositivo 21 de cliente, las cuales pueden haber sido previamente almacenadas en caché para este usuario. Las capacidades actuales del dispositivo 50 de contacto serán retornadas a continuación como respuesta (etapa 82). Una vez que el mensaje de OPCIONES ha llegado, se actualizan los servicios disponibles que sean mostrados al usuario. Por lo tanto, si el método de comunicación avanzada está capacitado para ser usado por el dispositivo 21, éste se hace que esté disponible para su uso por el usuario en la interfaz 22. Por ejemplo, si el dispositivo 50 de contacto es una conexión de alta velocidad y está preparada para los servicios, se puede hacer que la opción de transferencia de archivo esté disponible para el usuario.

Adicionalmente, si las capacidades retornadas indican que el dispositivo de contacto puede estar capacitado para manejar el servicio de comunicación pero la calidad puede ser pobre, la opción puede ser aún presentada al usuario, pero se puede informar al usuario de la baja calidad potencial. Por ejemplo, la opción de transferencia de archivo puede ser diferente para indicar que aunque el usuario esté capacitado para recibir el archivo, está conectado por una conexión de baja velocidad y por lo tanto la transferencia del archivo puede ser lenta o intermitente. El usuario está capacitado para tomar una decisión informada de si ha de enviar o no el archivo. La experiencia del usuario se mejora por tanto de forma significativa. Si el dispositivo local tiene una calidad de conexión baja, el dispositivo puede informar también al usuario adecuadamente o no permitir que el usuario comunique usando el servicio.

Cabe resaltar que en los escenarios anteriores, si existe un problema de comunicaciones con la red 22 de IMS, las características de comunicación avanzada serán/se mantendrán inhabilitadas.

Un ejemplo de escenario de chat, por ejemplo la mensajería instantánea, va a ser descrito ahora en el contexto de las Figuras 9 a 13. Un servicio de chat permite que los usuarios intercambien mensajes entre uno o más usuarios de forma instantánea. Esto no requiere un alto nivel de conectividad de red y por lo tanto puede estar disponible para el usuario en todo momento, aunque ambos contactos puedan necesitar estar registrados para el servicio. Uno a uno, los chats pueden ser implementados usando la mensajería en modo de papel de IM y los mensajes ser discretos y no formar parte de una sesión. Los cuerpos de los mensajes están contenidos dentro de un mensaje de SIP del que acusa recibo el destinatario de una manera habitual. El escenario ha sido mostrado en la Figura 9.

En primer lugar se usa una petición de OPCIONES DE SIP para determinar si puede estar disponible el intercambio de video o la transferencia de archivo con ese contacto 50 (etapa 91). Para esos servicios, ambos usuarios necesitarán tener una buena conectividad de red. Si están capacitados, las opciones de conexión se hacen ahora disponibles para ambos usuarios en las interfaces 22, 70 de usuario. Las opciones no se presentan y se impide que el dispositivo use los servicios si cualquiera de los usuarios no tiene una conectividad de red adecuada.

La petición de OPCIONES DE SIP y la respuesta de OPCIONES DE SIP contienen ambas las capacidades de los dispositivos. Una vez que las capacidades han sido establecidas, el mensaje se envía desde el cliente 21 hasta el IMS 20, y se reenvía al dispositivo 50 del destinatario (etapa 91). La respuesta sigue a continuación la misma ruta (etapa 92). Se usa un método de petición de MENSAJE DE SIP para transportar el cuerpo del mensaje transmitido usando la aplicación de chat (etapa 93) y se acusa recibo usando la respuesta ‘200 OK’ de SIP habitual (etapa 94).

La Figura 10 muestra la secuencia en que el destinatario 50 deja de estar registrado en la red 20 de IMS. Un chat puede ser introducido solamente si la segunda parte está en línea. Sin embargo, estos pueden dejar de estar en línea durante la sesión. La interfaz 22 de usuario muestra una ventana de chat para el usuario en la que el usuario puede escribir mensajes para su envío. El mensaje se envía a través de un mensaje de SIP (etapa 101) y se devuelve un SIP ‘480 respuesta de usuario llamado no registrado’ por parte de la red 20 de IMS (etapa 102). A nivel 22 de interfaz de usuario, se puede presentar un mensaje de servicio actualmente no disponible al usuario. Se puede evitar que el usuario envíe mensajes o se puede permitir que lo haga en caso de que el destinatario vuelva a estar en línea.

La Figura 11 muestra un escenario en el que la mensajería instantánea no puede ser entregada. El IMS 20 indica al cliente 21 que el mensaje no puede ser entregado. El mensaje SIP se envía en primer lugar (etapa 111) y se devuelve el código de respuesta de SIP indicando el fallo del mensaje (etapa 112). La interfaz 22 de usuario muestra a continuación que la entrega del mensaje ha fallado. Se puede permitir el envío adicional de mensajes en caso de que éstos puedan ser entregados, o se podría impedir.

La Figura 12 muestra un escenario en donde el dispositivo 21 de envío resulta desregistrado de la red 20 de IMS. El dispositivo del remitente puede perder cobertura de red o resultar desregistrado por otra razón. El cliente 21 informa a la interfaz 22 de usuario de que ha sido desregistrado de la red (etapa 121) y la interfaz 22 de usuario muestra que las comunicaciones inteligentes no están disponibles en ese momento. El botón de envío está deshabilitado de modo que la interfaz de usuario no indica que el envío del mensaje es posible, mejorando con ello la experiencia de usuario. El botón de envío puede ser habilitado cuando el usuario se registre en el IMS de nuevo. El procedimiento de registro ha sido mostrado en la Figura 2. En los escenarios anteriores, cuando la conexión y el chat ya no son posibles, el usuario puede ser dirigido a un mecanismo de respaldo para que envíe un mensaje SMS al contacto. Cuando ambos usuarios están en una sesión de chat, las capacidades de uno de los usuarios pueden cambiar, por ejemplo puede moverse desde un área con cobertura 3G a un área con cobertura 2G. Aunque las capacidades hayan cambiado, el chat puede continuar aún ya que no se ve afectado por el cambio de la conectividad de red. Aunque el chat puede continuar, el otro contacto deberá ser informado del cambio de modo que sus opciones de comunicación puedan ser actualizadas. Esto se hace usando un mensaje de OPCIONES DE SIP según es habitual. Cuando el dispositivo 21 del cliente detecta un cambio, el mensaje de OPCIONES DE SIP se envía al primer usuario (etapa 131). Se acusa recibo de éste según es habitual con un mensaje de ‘200 OK’ de SIP que contiene sus capacidades actuales (etapa 132). Las opciones disponibles presentadas al usuario en las interfaces 22 y 70 son cambiadas según sea aplicable. Por ejemplo, si la transferencia no está ya disponible, el icono se visualiza en color gris o bien puede ser eliminado. La opción ya no es seleccionable y la comunicación ya no está permitida. Esta secuencia se ha mostrado en la Figura 13.

Se debe enfatizar que en los escenarios descritos en la presente memoria se supone con frecuencia que el primer dispositivo de usuario tiene conectividad de red adecuada. Si el dispositivo de cliente no la tiene, puede que no se permita comunicar al dispositivo usando los servicios de comunicación inteligente o avanzada. El intercambio de capacidades reflejará todo esto, así como la interfaz de usuario.

La Figura 14 muestra un diagrama de secuencia de comunicaciones de transferencia de archivo. La transferencia de archivo puede ser iniciada desde dentro de una sesión de chat o puede ser independiente de la misma. Se ha ilustrado que la transferencia de archivo se implementa usando el protocolo MSRP y mensajes en una sesión de SIP. Sin embargo, se comprenderá que se puede usar cualquier protocolo de transferencia adecuado. El protocolo MSRP está definido en RFC 4975. El MSRP tiene una sintaxis similar a SIP, es decir sigue el modelo de petición y respuesta.

Cuando el usuario decide enviar un archivo mediante transferencia de archivo, el cliente 21 envía en primer lugar un mensaje de SIP INVITE al dispositivo 50 de contacto (etapa 141). El método de solicitud de SIP INVITE podrá incluir una invitación para comenzar una sesión de MSRP. Cuando la invitación es aceptada por el usuario del segundo dispositivo a través de la interfaz 70, se devuelve un mensaje ‘200 OK’ de SIP (etapa 142). Puesto que el contacto ha aceptado la invitación, se envía el archivo usando el mensaje de envío de protocolo de MSRP (etapa 143) y el acuse de recibo usando una respuesta de 200 OK de MSRP (etapa 144).

Cuando se ha completado la transferencia del archivo, se envía un mensaje de SIP BYE (etapa 145) para terminar la sesión, del que se acusa recibo (etapa 146). Cualquiera de las partes es libre de abandonar una sesión de chat durante la transferencia de un archivo. La transferencia del archivo continuará con la notificación adecuada que se proporcione cuando se haya completado. Esto ha sido mostrado en la Figura 15. Al igual que con el escenario de la Figura 14, se envía el mensaje de envío de MSRP y se acusa recibo para promulgar la transferencia del archivo (etapas 151 y 152). Esto continúa cuando cualquiera de las partes abandona la sesión de chat en la interfaz 22 de usuario; operando la transferencia en un segundo plano (etapas 153 y 154). Cuando se ha completado la transferencia, se envía un mensaje de SIP BYE y se acusa recibo según es habitual (etapas 155 y 156) y se proporciona una notificación adecuada en la interfaz 22. Se debe apreciar que el MSRP no puede ser usado solamente para enviar mensajes sino también información acerca del estado de actividad en ambos extremos. El intercambio de imagen y de video puede estar también disponible desde dentro de una sesión de chat. La Figura 16 ilustra que un destinatario puede rechazar una invitación de compartir un archivo. La invitación se envía según se ha descrito con anterioridad y un mensaje de 603 RECHAZAR SIP se envía (etapas 161 y 162) cuando el contacto rechaza la invitación en la interfaz 70 de usuario.

Una transferencia de archivo en curso puede ser cancelada en cualquier momento por cualquiera de las partes. Esto se ha mostrado en la Figura 17. La transferencia se inicia usando ENVÍO DE MSRP y un acuse de recibo según es habitual (etapas 171 y 173). Para cancelar la transferencia, se transmite un mensaje de SIP BYE y a continuación se acusa recibo si se ha recibido (etapas 173 y 174). En la interfaz 22 de usuario, se usa una indicación visual para mostrar que la transferencia de archivo en curso fue cancelada.

Adicionalmente a que la transferencia sea cancelada, el destinatario o el remitente pueden perder la conexión de datos durante el proceso. Según se ha mostrado en la Figura 18, el ENVÍO DE MSRP y el acuse de recibo se envían según es habitual (etapas 181 y 182). La sesión puede ser finalizada en cualquier momento y las interfaces 22 y 70 de usuario informarán a los usuarios de que la transferencia ha fallado.

Resulta, por supuesto, posible que el destinatario pueda no responder a una invitación de aceptar o rechazar una transferencia de un archivo. El usuario puede estar fuera del dispositivo o puede estar ocupado. En esa situación, la interfaz 22 de usuario del dispositivo 21 del remitente tendrá normalmente un temporizador que expire. Cuando el temporizador expira, la sesión se da por terminada desde el iniciador 21. La Figura 19 muestra las etapas involucradas. La petición de SIP INVITE se envía a un segundo dispositivo 50 que incluye una invitación a iniciar una sesión de MSRP (etapa 191). El temporizador se pone en marcha en el remitente. Cuando éste expira, se envía un mensaje de CANCELAR SIP al segundo dispositivo 50 (etapa 192) donde el usuario puede ser informado o no de que la transferencia ha sido cancelada dependiendo de la configuración. De hecho, el usuario puede no tener conocimiento de la existencia de un intento de transferencia de archivo.

En un ejemplo de realización, compartir video en vivo se presenta solamente al usuario cuando está conectado en una llamada de voz con un abonado capacitado en línea que normalmente está conectado por una conexión 3G o más rápida. El servicio de comunicaciones puede ser usado también cuando el dispositivo no forme parte de una llamada de voz de circuito conmutado.

La Figura 20 muestra un diagrama de secuencia de un intercambio en vivo. Una vez que el usuario está conectado a la otra parte, si la otra parte es un abonado capacitado, con el fin de determinar la capacidad para proporcionar un video el dispositivo envía un mensaje de OPCIONES DE SIP (etapa 201). Este es recibido por el segundo dispositivo 50 y se usa para determinar si el intercambio de video está disponible y ofrecerlo a un usuario del segundo dispositivo en la interfaz 70. El acuse de recibo ‘200 OK’ de SIP se transmite a través del IMS 20 (etapa 202) y retorna las capacidades del segundo dispositivo 50 dependiendo de la conectividad de red del dispositivo 50 y de las capacidades y el estado del aparato de teléfono. La respuesta de OPCIONES DE SIP se utiliza para determinar si el intercambio de video está o no disponible durante la llamada de voz.

En este ejemplo de implementación, ambas partes deben estar en una conexión 3G o más rápida para un intercambio de video efectivo. La opción de video en vivo se muestra al usuario usando la interfaz 22 solamente si la conectividad de red de ambos dispositivos es adecuada (determinada a partir de los mensajes de OPCIONES DE SIP). Si la conectividad de red es adecuada, la opción se deshabilita en la interfaz 22 y no se permite que los dispositivos comuniquen usando videollamada.

Adicionalmente, la interfaz de usuario puede mostrar al usuario, en base a las capacidades del dispositivo destinatario, que el servicio de comunicación puede ser posible pero que puede ser de calidad pobre. Por ejemplo, en este ejemplo, la opción del usuario de comunicar usando video puede ser presentada, pero el usuario puede ser informado de que el destinatario o el dispositivo local tiene una conexión de baja calidad y por lo tanto la calidad del video será pobre. El intercambio de capacidad puede indicar la conectividad del dispositivo para permitir que esta información sea presentada. Esta visualización de la calidad potencial del servicio de comunicación puede ser aplicada igualmente a los otros escenarios descritos en la presente memoria.

Aunque se puede acordar que el video esté disponible mediante negociación de OPCIONES DE SIP durante la llamada de voz, uno de los aparatos de teléfono puede caer a una conexión más baja, por ejemplo 2G, durante la llamada. En este punto, la opción de compartir video se deshabilita y no se permite que el dispositivo comunique usando este método de comunicación. Según se muestra en la Figura 21, cuando el aparato de teléfono cae a conectividad de 2G, se retira el botón de video en vivo y se envía un mensaje de OPCIONES DE SIP (etapa 211) con las capacidades actualizadas para indicar que el video ya no está disponible debido a que la conectividad de red ha cambiado. La respuesta de OPCIONES define la conectividad de red y el video soportado del segundo dispositivo 50 que puede ser adecuado para soportar video (etapa 212). Éste no será el caso dado que el primer dispositivo 21 tiene conectividad inadecuada. Cuando se restablezca la conectividad, se envía de nuevo un mensaje de OPCIONES para asegurar que el servicio de video está disponible. Si ambas partes tienen conectividad 3G, se permitirá ahora que los dispositivos usen el método de comunicación si los usuarios así lo desean.

51 los usuarios están conectados a una conexión adecuada, y están capacitados para compartir video, la opción de comunicar por medio de este método puede ser presentada al usuario. En una realización, esta puede ser presentada solamente cuando los usuarios estén conectados en una llamada de voz.

Según se muestra en la Figura 22, se puede suministrar intercambio de video usando el protocolo de transporte en tiempo real (RTP). El RTP fue publicado por primera vez en 1996 en RFC 1889 y reemplazado por RFC 3550 en 2003. Este se usa para suministrar audio y video a través de redes de IP. Se invita al usuario a una sesión usando el mensaje de SIP INVITE y el acuse de recibo correspondiente (etapas 221 y 222). El RTP se usa entonces para compartir el video (etapas 223 y 224). La invitación puede ser rechazada con los métodos de comunicación descritos con anterioridad en donde se devuelven mensajes relevantes en vez del acuse de recibo de OK.

En el escenario mostrado en la Figura 23, se produce la terminación no ordenada de intercambio de video o de imagen. En este escenario, una transacción de MSRP de imagen estaba teniendo lugar cuando se produjo el fallo de la conexión a la red (etapa 231). Esto podría ser causado, entre otros, por error del cliente debido a reinicios del teléfono, a que no haya portadora de datos o a que una conmutación de portadora de datos (p. ej., de 3G+ a 3G) ocasione una configuración de capa de IP. Un temporizador expira en el primer dispositivo cuando no tiene lugar ninguna actividad. Un mensaje de SIP BYE se envía a continuación junto con una petición de actualización de las capacidades del segundo dispositivo 50 usando OPCIONES DE SIP (etapas 232 y 233). El segundo dispositivo 50 puede responder con un acuse de recibo del SIP BYE o de un ERROR DE SIP, según sea pertinente (234). El IMS 20 puede responder a las OPCIONES DE SIP con una respuesta de usuario no registrado o el dispositivo 21 de cliente puede responder a las OPCIONES DE SIP con capacidades actualizadas (etapa 235) dependiendo del error que haya causado la determinación no ordenada. Los servicios inteligentes disponibles pueden ser actualizados a continuación, o ambos o uno cualquiera de los dispositivos en base a las capacidades recibidas y transmitidas o a los mensajes de error. No se reciben capacidades si se transmite un mensaje de ERROR DE SIP o un mensaje no registrado de SIP desde el IMS 20. No se permitirá que el primer dispositivo 21 use ninguno de los métodos de comunicación avanzada, es decir, los servicios inteligentes, dado que el segundo dispositivo 50 se considerará no disponible.

Es posible que una invitación de video sea recibida mientras está en una conexión 2G. Esto puede ocurrir cuando, por ejemplo, la conexión ha cambiado y las capacidades no han sido actualizadas. El usuario puede emitir una invitación para tomar parte en una comunicación de alta tasa de transferencia de datos tal como una sesión de video como se muestra en la Figura 24. El segundo dispositivo rechazará la petición de video en base a la conectividad de red y emitirá una respuesta de 603 RECHAZAR de SIP (etapas 241 y 242). El usuario queda informado de esto por medio de la interfaz 22 de usuario. Una vez que esto ha sido detectado por el segundo dispositivo 50, éste emitirá un mensaje de OPCIONES indicando que la conectividad de red del dispositivo es baja, por ejemplo de 2G (etapa 243). El primer dispositivo acusará recibo de esto (etapa 244) y transmitirá sus propias capacidades según es habitual. El primer dispositivo 21 ya no estará más capacitado para usar el método de comunicación (p. ej., video) y, en el ejemplo de la Figura 24, el botón de video en vivo se elimina.

El intercambio de información de contacto, mediante el uso de una tarjeta V por ejemplo, puede ser implementado con el uso de una sesión de MSRP de la misma manera que una transferencia de archivo. Con anterioridad a que la información de contacto pueda ser enviada, el dispositivo identificará las capacidades del segundo dispositivo 51 para determinar si está en condiciones de recibir la información de contacto en base a su conectividad de red. El intercambio de contacto está disponible solamente si el dispositivo de cliente tiene una conectividad de red y una calidad de servicio adecuadas. Según se ha mostrado en la Figura 25, esto está basado en el mensaje de OPCIONES DE SIP y en el acuse de recibo, según se ha descrito en muchos de los escenarios anteriores (etapas 251 y 252). El primer usuario entra en la agenda del teléfono buscando su perfil. En este caso, el usuario decide compartir el perfil con otros usuarios. El botón de compartir solamente se vuelve disponible si las capacidades del primer usuario son tales que se pueda acceder al servicio de transferencia de archivo. Por ejemplo, si el dispositivo está en una zona de baja conectividad de red, el servicio de transferencia de archivo y por tanto de envío de información no estará disponible para el dispositivo. Solamente aquellos clientes que estén disponibles para recibir la información del contenido, es decir, que tengan un hardware capacitado según se determine mediante los mecanismos de sondeo y las capacidades almacenadas en caché, están disponibles para transferencia de archivo.

El usuario del primer dispositivo puede escoger uno o más contactos para compartir el perfil. Una vez que se ha seleccionado un contacto, el cliente enviará un mensaje de OPCIONES DE SIP, según se muestra en la Figura 25, etapas 251 y 252, para determinar las capacidades de este último. El mensaje de OPCIONES DE SIP debe ser suficientemente rápido como para que la interfaz 22 de usuario cambie para ocultar el retardo entre pantallas. Una vez que el contacto ha sido seleccionado y el intercambio de mensaje de OPCIONES DE SIP confirme que las capacidades necesarias están en su lugar, el usuario del primer dispositivo puede seleccionar continuar y proceder a compartir la información de contacto a través de los procedimientos de transferencia de archivo descritos con anterioridad y mostrados en la Figura 14.

Existen escenarios posibles en donde el dispositivo puede estar visitando una región fuera del área de cobertura proporcionada por el operador de red y, potencialmente, itinerando por la red de un operador de red diferente. Muchas de las comunicaciones descritas en la presente memoria pueden incurrir en cargos de itinerancia significativos. De ese modo, ventajosamente, se puede presentar al usuario opciones de configuración específicas para que cada servicio habilite o deshabilite el servicio según se requiera. Esta información podría estar incluida en la información de capacidades. También se puede presentar al usuario la opción de comunicar usando el servicio según, y cuando, se requiera adicionalmente a, o en vez de, un ajuste de configuración que lo abarque todo. El usuario puede también deshabilitar la conectividad de datos, impidiendo de ese modo que el dispositivo comunique usando muchos de los servicios descritos. Por supuesto, las capacidades reflejarán todo esto.

Debe entenderse que los ejemplos de realización descritos en la presente memoria pueden ser implementados a través de enlaces de datos solamente, en combinación con servicios de voz o por sí solos. Adicionalmente, las características descritas pueden ser implementadas junto con modelos de experiencia de usuario y servicios de comunicación conocidos. Aunque la presente invención ha sido descrita en términos de servicios específicos, se comprenderá que cualesquiera servicios y métodos de comunicación podrán ser adecuados para su uso con los principios de la presente invención. Se pueden definir servicios en el futuro que sean igualmente aplicables con las realizaciones descritas en la presente memoria.

Se comprenderá que una ventaja clave de la invención consiste en que es independiente de la portadora y del dispositivo. Esto proporciona una conectividad mucho mayor entre una base más amplia de usuarios (en comparación con más alternativas específicas de dispositivos y portadoras), mientras que al mismo tiempo proporciona una experiencia de usuario incrementada a cada uno de esos usuarios. El uso de SIP en el suministro de esta funcionalidad proporciona un medio eficiente de implementación de la invención.

Los ejemplos descritos en la presente memoria pueden ser implementados en cualquier sistema operativo del dispositivo. Se comprenderá que la lógica de servicio clave ha sido descrita y que el experto en la materia puede implementar esas características de manera diferente cuando las presente al usuario. Los procesos descritos en la presente memoria pueden estar automatizados o pueden ser llevados a cabo mediante instrucción manual.

Mientras que los terminales son mencionados con frecuencia como “móviles” en la discusión precedente, el término “móvil” no debe ser entendido como que requiere que un terminal sea siempre móvil, sino simplemente que tenga la capacidad de estar en comunicación con una red de telecomunicaciones inalámbricas o con una red de IP, dependiendo del contexto, que permita la movilidad. Por ejemplo, un terminal de PC o un cliente de máquina a máquina (M2M) que no se haya movido nunca de cualquier localización geográfica particular puede ser, en un sentido, considerado móvil puesto que podría ser movido hasta una localización diferente mientras esté aun accediendo a la misma red. El término “terminal móvil” se usa en la presente discusión solamente de modo que ha de ser leído como que incluye la posibilidad de que un terminal es “semipermanente” o incluso “fijo” donde el contexto no contradiga tal interpretación. Un ejemplo de tales dispositivos podría incluir un Apple iPod® o un Apple iPad® que puedan estar conectados inalámbricamente a un enrutador de internet a través de una conexión WiFi convencional que pueda comunicación con una red de IP (internet).

Adicionalmente, la “red” en la discusión precedente debe ser entendida como que tiene al menos un elemento inalámbrico y, típicamente, elementos de protocolo de internet (IP).

Claims

REIVINDICACIONES

1. - Un método para facilitar la comunicación entre un primer dispositivo (21) de comunicación y un segundo dispositivo (50) de comunicación usando una red (11) que soporta un primer y un segundo métodos de comunicación diferentes, que comprende las etapas de:

iniciar, por medio del primer dispositivo (21) de comunicación, una comunicación entre el primer dispositivo (21) de comunicación y el segundo dispositivo (50) de comunicación usando el primer método de comunicación; determinar un primer indicador de estado de dispositivo de comunicación indicativo de la capacidad del primer dispositivo (21) de comunicación para comunicar usando el segundo método de comunicación en base a una conectividad de red actual del primer dispositivo (21) de comunicación;

registrar, por medio del primer dispositivo (21) de comunicación, el primer dispositivo (21) de comunicación en una plataforma (20) de servicio de la red (11);

solicitar desde la plataforma (20) de servicio un segundo indicador de estado de dispositivo de comunicación indicativo de la capacidad del segundo dispositivo (50) de comunicación para comunicar usando el segundo método de comunicación en base a una conectividad de red actual del segundo dispositivo (50) de comunicación, cuando un usuario del primer dispositivo (21) de comunicación selecciona un usuario del segundo dispositivo (50) de comunicación a partir de una visualización de usuarios en el primer dispositivo (21) de comunicación;

recibir el segundo indicador de estado de dispositivo de comunicación desde la plataforma (20) de servicio, y permitir, mediante visualización de opciones de comunicación en el primer dispositivo (21) de comunicación, que el primer dispositivo (21) de comunicación comunique con el segundo dispositivo (50) de comunicación usando el segundo método de comunicación en dependencia del primer indicador de estado de dispositivo de comunicación y del segundo indicador de estado de dispositivo de comunicación recibido.

2. - El método según se define en la reivindicación 1, en donde el primer método de comunicación es una comunicación de voz.

3. - El método según se define en la reivindicación 1, en donde el segundo método de comunicación es una comunicación de video.

4. - El método según se define en la reivindicación 1, en donde la etapa de solicitar un segundo indicador de estado de dispositivo de comunicación se lleva a cabo con posterioridad a la etapa de permitir que el primer dispositivo (21) de comunicación comunique con el segundo dispositivo (50) de comunicación.

5. - El método según se define en la reivindicación 1, en donde el segundo indicador de estado de dispositivo es dependiente del estado del hardware del terminal actual, incluyendo el estado del hardware del terminal actual al menos uno de entre una duración de batería, espacio de almacenaje de archivos del segundo dispositivo (50) de comunicación, y conectividad de red actual del segundo dispositivo (50) de comunicación.