ES2469852T3

ES2469852T3 - Procedimiento y dispositivos para registrar dispositivos inform�ticos de cliente para sesiones de comunicación en línea

Info

Publication number: ES2469852T3
Application number: ES10763094.9T
Authority: ES
Inventors: Arun Mathias; Justin Santamaria; Justin Wood; Joe Abuan; Jeremy Brown; Patrick Gates; Natthew Klahn; Andrew H. Vyrros; Braden Thomas; Drew Yao
Original assignee: Apple Inc
Current assignee: Apple Inc
Priority date: 2010-04-07
Filing date: 2010-09-23
Publication date: 2014-06-20
Anticipated expiration: 2030-09-23
Also published as: AU2010350744A1; DE112010005457B4; EP2556639A1; JP2013525879A; KR20130018288A; EP2540052A1; KR101435309B1; GB201217440D0; CN102893572A; DE112010005457T5; JP5596849B2; BR112012025382B1; AU2010350743A1; MX2012011620A; AU2010350741B2; WO2011126505A1; BR112012025379A2; MX2012011624A; US20110250909A1; US8948797B2

Abstract

Procedimiento para el registro de un dispositivo informático de cliente para sesiones de comunicación en línea, que comprende: recibir un mensaje que tiene un símbolo de identificación (115), que es exclusivo del dispositivo informático (110) del cliente, y un número de teléfono del dispositivo informático (110) del cliente, a partir de un SMS, Servicio de Mensaje Corto, dispositivo de tránsito (130), que ha recibido un mensaje SMS que tiene el símbolo de identificación (115) del dispositivo informático (110) del cliente, y que determinó el número de teléfono del dispositivo informático (110) del cliente; caracterizado por asociar el símbolo de identificación (115) y el número de teléfono; y almacenar la asociación.

Description

Procedimiento y dispositivos para registrar dispositivos inform�ticos de cliente para sesiones de comunicación en línea

ANTECEDENTES

Sector técnico

Las realizaciones de la invención se refieren al sector de redes inform�ticas; y más específicamente para el registro de dispositivos inform�ticos de clientes para sesiones de comunicación en línea.

Antecedentes técnicos

Muchas implementaciones para proporcionar sesiones de comunicación en línea (por ejemplo, mensajes instantáneos, conferencias de vídeo, etc.), requieren que los usuarios de dispositivos inform�ticos instalen software y/o se registren en el servicio. De este modo, el requisito previo para un usuario para establecer una sesión de comunicación en línea con otro usuario, es que ambos usuarios se deben haber registrado y/o deben tener el mismo software instalado. Muchas implementaciones mantienen también presencia (por ejemplo, lista de amigos), que permite a los usuarios determinar la situación de otros usuarios (por ejemplo, en línea, fuera de línea, ausente, etc.). Se encuentran ejemplos de la técnica anterior en el documento EP1819124A1, que describe registros automatizados de usuarios, y en el documento EP1956796A1, que describe un sistema, aparato y procedimiento para proporcionar servicios IMS. Las redes públicas grandes, tales como Internet, tienen frecuentemente conexiones con redes privadas más pequeñas, tales como las mantenidas por una empresa, proveedor de servicios de Internet, o incluso hogares individuales. Por su propia naturaleza, las redes públicas deben tener una asignación acordada conjuntamente de direcciones de red, es decir, direcciones públicas. Por una serie de razones, los gestores de redes privadas deciden frecuentemente utilizar direcciones de red privadas para las redes privadas que no forman parte de la asignación acordada en común. De este modo, para que el tráfico de red procedente de la red privada sea capaz de atravesar la red pública, se requiere alguna forma de traducción de dirección de red privada/pública (“NAT”).

Un dispositivo que lleva a cabo operaciones NAT altera los paquetes de datos enviados de la red privada para cumplir con el esquema de direccionado de la red pública. Particularmente, el traductor de dirección de red sustituye la dirección privada y número de puerto de origen de un paquete por su dirección pública propia y un número de puerto asignado. Un traductor de dirección de red altera también los paquetes de datos recibidos para ordenadores de la red privada, para sustituir la dirección pública y número de puerto de destino por la dirección privada y número de puerto correctos del destinatario previsto. Tal como se utiliza en esta descripción, el término dirección se debe considerar que incluye tanto una dirección como un número de puerto, si ello es apropiado en el contexto, tal como se comprendería por un experto ordinario en la materia.

El NAT ha pasado a ser cada vez más habitual en la informática de red mediante módem. Una ventaja del NAT es que retrasa el agotamiento del espacio de direcciones de red pública. Por ejemplo, el direccionado TCP/IP, que se utiliza en internet, comprende cuatro cadenas de tres dígitos cada una, proporcionando de esta manera un espacio de direcciones finito. Adicionalmente, ciertas partes de este espacio de direcciones est�n reservadas para usuarios particulares o usos particulares, agotando adicionalmente el número real de direcciones disponible. No obstante, si se utiliza NAT, una red o subred privada puede utilizar un número arbitrario de direcciones presentando todavía una dirección normalizada única al mundo exterior. Esto hace que el número de direcciones disponibles sea prácticamente ilimitado, porque cada red privada podría, teóricamente, utilizar exactamente las mismas direcciones privadas.

Una ventaja proporcionada por el NAT es una mayor seguridad que procede del hecho de que los que se encuentran en la red pública no pueden determinar la dirección de red real (es decir, privada) de un ordenador de una red privada. La razón de ello es que solamente se proporciona la dirección pública en la red pública por el traductor de dirección de red. De manera adicional, la dirección pública puede corresponder a cualquier número de ordenadores de la red privada.

Diferentes tipos de NAT utilizan diferentes niveles de seguridad. Por ejemplo, con un “NAT de cono completo”, una vez se ha mapeado una dirección interna (iAddr: iPort) a una dirección externa (eAddr: ePort), cualquier ordenador externo puede enviar paquetes a iAddr: iPort enviando paquetes a eAddr: ePort. Con un “NAT de cono restringido”, un ordenador externo con una dirección hAddr puede enviar paquetes a iAddr: iPort al enviar paquetes a eAddr: ePort solamente si iAddr: iPort ha enviado previamente un paquete a hAddr. El puerto del ordenador externo es irrelevante. Con un “NAT de cono con puerto restringido”, un ordenador externo que tiene un hAddr:hPort de dirección/puerto puede enviar iAddr:iPort enviando paquetes a eAddr:ePort solamente si iAddr:iPort ha enviado previamente un paquete a hAddr:hAPort. Finalmente, con un NAT simétrico, cada solicitud del mismo iAddr:iPort a una dirección de IP de destino específica y puerto es mapeada a un único eAddr:ePort. Si el mismo ordenador interno envía un paquete a un destino distinto, se utiliza una dirección externa diferente y mapeado de puerto

diferente. Solamente un ordenador externo que recibe un paquete de un ordenador interno puede enviar un paquete en retorno al ordenador interno.

La informática punto a punto (“peer to peer”) (“P2P”) se refiere a una arquitectura de red distribuida formada por nodos de cálculo que ponen una parte de sus recursos a disposición directamente de otros participantes de la red. Los participantes de una red P2P establecen canales de comunicación directa entre s� y actúan tanto como clientes como servidores, en contraste con el modelo tradicional de cliente-servidor en el que los servidores suministran recursos y los clientes consumen recursos.

Las operaciones NAT que se han descrito anteriormente presentan numerosos problemas para las conexiones P2P. Por ejemplo, el establecer una conexión directa entre dos puntos y homólogos (“peers”) resulta cada vez más difícil si uno o ambos homólogos est� situado detrás de uno o varios de los tipos de NAT descritos anteriormente. Este problema es incrementado por el hecho de que los dispositivos de cliente tales como Apple iPod Touch�, Apple iPhone�, Apple iPad� y otros varios dispositivos (por ejemplo, dispositivos RIM Blackberry�, dispositivos Palm Pre�, etc.) son desplazados frecuentemente entre redes que tienen diferentes implementaciones NAT. Por ejemplo, el Apple iPhoneTM es capaz de comunicar a través de redes Wi-Fi (por ejemplo, redes 802.11b, g, n); redes 3G (por ejemplo, redes Sistema de Telecomunicaciones Móviles Universal (“UMTS”), redes de acceso ascendente de paquetes de alta velocidad (“HSUPA”), etc.); y redes Bluetooth (conocidas como redes de área personal (“PAN”)). Los dispositivos de futuros clientes ser�n capaces de comunicar por canales de comunicación adicionales tales como WiMAX. International Mobile Communication (“IMT”) Advanced, y Long Term Evolution (“LTE”) Advanced, entre otros.

Las unidades con manos libres (por ejemplo, auriculares, equipos de automóvil) se utilizan de manera típica para emparejarse con un dispositivo inform�tico para servicios de manos libres. Por ejemplo, es habitual para un dispositivo inform�tico que comprende funcionalidad de telefonía celular, que incluya la capacidad de corresponder con una unidad de manos libres que actúa como relevador de auditoría entre la unidad de manos libres y el dispositivo inform�tico.

CARACTER�STICAS

La invención se refiere a un procedimiento según la reivindicación 1, a un servidor de registro según la reivindicación 7, a un medio de almacenamiento según la reivindicación 11 y a un sistema según la reivindicación 12.

Se describen en la presente descripción un procedimiento y aparato para registrar automáticamente un dispositivo inform�tico de cliente (“dispositivo de cliente”) (por ejemplo, una estación de trabajo, un ordenador portátil, un ordenador de mano, un teléfono celular, un teléfono inteligente, un teléfono multimedia, una tableta, un reproductor portátil de medios, una unidad GPS, un sistema de juego, etc.) para sesiones de comunicación en línea (por ejemplo, conferencia de vídeo P2P, mensajes instantáneos P2P, etc.). En una realización, cuando tiene lugar un evento en un dispositivo inform�tico (por ejemplo la activación del dispositivo inform�tico), el dispositivo de cliente empieza automáticamente un proceso de registro para sesiones de comunicación en línea. El proceso de registro automático incluye que el dispositivo de cliente transmite un mensaje SMS (“Short message service”) con un símbolo de identificación (por ejemplo, su símbolo de puesta en marcha) a un dispositivo de tránsito de SMS (por ejemplo, una pasarela SMS o un agregador SMS). El símbolo de identificación identifica únicamente un dispositivo de cliente y, en una realización, es un símbolo de puesta en marcha que puede contener información que permite a un servicio de identificación localizar el dispositivo de cliente. El símbolo de identificación de identificación de la realización de servicio de notificación automática “push” se utiliza también como forma de establecer la garantía de que una notificación determinada es legítima. En otras realizaciones, se pueden utilizar cualesquiera registros o mapeados de dispositivos de cliente con respecto a símbolos únicos para asociar los símbolos de identificación con dispositivos de cliente y proporcionar un método garantizado de asociación de la identidad del dispositivo de cliente con un símbolo identificado de manera única.

El dispositivo de tránsito de SMS determina el número de teléfono del dispositivo de cliente (por ejemplo, por examen de la cabecera del mensaje SMS) y transmite un mensaje IP (protocolo Internet) a un servidor de registro con el símbolo de identificación y el número de teléfono. El servidor de registro genera una señal de identificación basada en el símbolo de identificación del número de teléfono y transmite estos al dispositivo de tránsito de SMS al dispositivo de cliente. El dispositivo de tránsito de SMS transmite un mensaje SMS al dispositivo de cliente incluyendo la señal de identificación, símbolo de identificación y número de teléfono. El dispositivo de cliente transmite a continuación un mensaje IP al servidor de registro con la señal de identificación, símbolo de identificación y número de teléfono. El servidor de registro valida la información procedente del dispositivo de cliente y almacena una asociación entre el símbolo de identificación y el número de teléfono en un almacenamiento de datos de registro de sesión de comunicación en línea. Juntamente, el par asociado del símbolo de identificación y el número de teléfono identifican de manera única el dispositivo en una red de sesión de comunicación en línea.

Despu�s de que el dispositivo de cliente ha sido registrado, un usuario en el dispositivo de cliente puede iniciar y/o aceptar una invitación para una sesión de comunicación en línea (por ejemplo, conversación de vídeo/sesión de conferencia, sesión de mensaje instantáneo, etc.). En una realización, el número de teléfono del dispositivo de cliente es utilizado como el identificador de punto final de sesión de comunicación en línea en una sesión de comunicación en línea. A título de ejemplo, un usuario en un dispositivo de cliente puede invitar a otro usuario o usuarios en otro dispositivo de cliente para participar en una sesión de comunicación en línea utilizando el número o números de teléfono. En algunas realizaciones, el dispositivo de cliente no conoce de manera inicial o de origen su

5 propio número de teléfono.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

La invención se comprender� mejor haciendo referencia a la descripción siguiente y a los dibujos adjuntos que se 10 utilizan para mostrar realizaciones de la invención. En los dibujos:

La figura 1 es un diagrama de flujo de datos que muestra el registro de un dispositivo de cliente para sesiones de comunicación en línea, de acuerdo con una realización;

15 La figura 2 es un diagrama de bloques que muestra el dispositivo de cliente de la figura 1 con mayor detalle, de acuerdo con una realización;

La figura 3 es un diagrama de bloques que muestra el servidor de registro de la figura 1 de manera más detallada, de acuerdo con una realización;

20 La figura 4 es un diagrama de flujo que muestra operaciones, a título de ejemplo, para registrar un dispositivo de cliente para sesiones de comunicación en línea, de acuerdo con una realización;

La figura 5 muestra un almacenamiento de datos de registro, a título de ejemplo, de acuerdo con una realización; 25 La figura 6 muestra una topología de red general de una realización;

La figura 7 muestra un diagrama de flujo de datos de establecimiento de una sesión de comunicación en línea entre dispositivos de cliente, de acuerdo con una realización; 30 La figura 8 es un diagrama de bloques que muestra un servicio relevador, de acuerdo con una realización;

La figura 9 muestra una realización de una arquitectura API, de acuerdo con una realización;

35 La figura 10 muestra un almacenamiento de datos de registro, a título de ejemplo, de acuerdo con una realización;

La figura 11 muestra una tabla de compatibilidad NAT, a título de ejemplo, de acuerdo con una realización;

La figura 12 muestra un dispositivo de cliente, a título de ejemplo, y un interfaz de usuario gráfico que se utiliza para 40 transitar entre llamadas conmutadas de circuito y llamadas de vídeo, de acuerdo con algunas realizaciones;

La figura 13 muestra el dispositivo de cliente de la figura 12 con visualización de un pre-visionado de vídeo, de acuerdo con una realización;

45 La figura 14 muestra un dispositivo de cliente, a título de ejemplo, y un interfaz de usuario gráfico utilizado para aceptar o denegar invitaciones de llamada de vídeo, de acuerdo con una realización;

Las figuras 15 y 16 muestran dispositivos de cliente después de transición a una llamada de vídeo, de acuerdo con una realización;

50 Las figuras 17 y 18 son diagramas de flujo que muestran operaciones, a título de ejemplo, para transitar entre una llamada de teléfono conmutada por un circuito solamente de audio a una llamada de vídeo, de acuerdo con una realización;

55 La figura 19 es un diagrama de flujo que muestra operaciones, a título de ejemplo, llevadas a cabo en un dispositivo de cliente que ha recibido un mensaje de rechazo de una llamada de vídeo, de acuerdo con una realización;

La figura 20 es un diagrama de flujo que muestra operaciones, a título de ejemplo, llevadas a cabo en un dispositivo de cliente para transitar de una llamada de vídeo a una llamada conmutada de circuito, de acuerdo con una 60 realización;

La figura 21 muestra una topología general de red utilizada para registrar un dispositivo de cliente para sesiones de comunicación en línea utilizando una dirección de correo electrónico como identificador de punto final de sesión de comunicación en línea, de acuerdo con una realización;

Las figuras 22A-B son diagramas de flujo que muestran operaciones, a título de ejemplo, para registrar una dirección de correo electrónico como identificador de punto final de sesión de comunicación en línea, de acuerdo con una realización;

La figura 23 es un diagrama de flujo que muestra operaciones, a título de ejemplo, para un usuario que proporciona información de inicialización para registrar una dirección de correo electrónico como identificador de punto final de sesión de comunicación en línea, de acuerdo con una realización;

La figura 24 muestra operaciones, a título de ejemplo, para validar una dirección de correo electrónico, de acuerdo con una realización;

La figura 25 es un diagrama de flujo que muestra operaciones, a título de ejemplo, llevadas a cabo en un servicio de registro cuando una dirección de correo electrónico a ha sido validada, de acuerdo con una realización;

La figura 26 es un diagrama de flujo de datos que muestra operaciones, a título de ejemplo, para gestionar invitaciones cuando un usuario tiene múltiples dispositivos de clientes que est�n asociados con el mismo identificador de punto final de sesión de comunicación en línea, de acuerdo con una realización;

La figura 27 es un diagrama de flujo de datos que muestra operaciones, a título de ejemplo, que son llevadas a cabo cuando es factible una conexión directa P2P, de acuerdo con una realización;

La figura 28 es un diagrama de flujo de datos que muestra operaciones, a título de ejemplo, que son llevadas a cabo cuando una conexión directa P2P no es factible, de acuerdo con una realización;

La figura 29 es un diagrama de flujo de datos que muestra operaciones, a título de ejemplo, que son llevadas a cabo cuando una sesión de comunicación en línea termina, de acuerdo con una realización;

La figura 30 es un diagrama de flujo que muestra operaciones, a título de ejemplo, que son llevadas a cabo para transferir una sesión de comunicación en línea desde un dispositivo de cliente a otro dispositivo de cliente, de acuerdo con una realización;

La figura 31 es diagrama de flujo que muestra operaciones, a título de ejemplo, para iniciar y establecer una sesión de comunicación en línea con múltiples usuarios, de acuerdo con una realización;

La figura 32 es un diagrama de bloques que muestra un dispositivo inform�tico de un cliente en interfaz con una unidad de manos libres, de acuerdo con una realización;

La figura 33 muestra un dispositivo inform�tico de un cliente que recibe una invitación para una llamada de vídeo, generando que un dispositivo de manos libres efectúe la llamada, recibiendo una indicación de contestación desde el dispositivo de manos libres, estableciendo la llamada de vídeo y enrutando la señal de audio al dispositivo de manos libres, de acuerdo con una realización;

La figura 34 muestra un dispositivo inform�tico de un cliente que inicia una llamada de vídeo y enrutando la señal de audio para establecer la llamada de vídeo a través de un dispositivo de manos libres, de acuerdo con una realización;

La figura 35 muestra un dispositivo inform�tico de un cliente que inicia una llamada de vídeo que responde a la recepción de una petición de llamada des de un dispositivo de manos libres, de acuerdo con una realización;

La figura 36 muestra un dispositivo inform�tico de un cliente que enruta una señal de audio de una llamada de vídeo establecida a un dispositivo de manos libres, de acuerdo con una realización;

La figura 37 muestra un dispositivo inform�tico de un cliente que termina una llamada de vídeo que responde a la recepción de una petición de llamada final desde un dispositivo de manos libres, de acuerdo con una realización;

La figura 38 es un diagrama de bloques que muestra un sistema inform�tico, a título de ejemplo, que puede ser utilizado en algunas realizaciones; y

La figura 39 es un diagrama de bloques que muestra un sistema de proceso de datos, a título de ejemplo, que puede ser utilizado en algunas realizaciones.

DESCRIPCI�N DETALLADA

En la siguiente descripción, se explican numerosos detalles específicos. No obstante, se comprender� que se pueden llevar a la práctica realizaciones de la invención sin estos detalles específicos. En otros casos, no se han

mostrado en detalle circuitos, estructuras y técnicas de tipo bien conocido para no dificultar la comprensión de la presente descripción.

Los técnicos ordinarios en este sector, con la ayuda de las descripciones que se incluyen, ser�n capaces de implementar funcionalidades apropiadas sin experimentación indebida.

Las referencias que se hacen en la descripción a “una realización”, “realización”, “una realización a título de ejemplo”, etc. indican que la realización descrita puede incluir una característica, estructura o peculiaridad específica, pero que cada realización puede no incluir necesariamente la característica, estructura, o peculiaridad característica. Además, dichas frases no hacen referencia necesariamente a la misma realización. Además, cuando se describe una característica, estructura o peculiaridad específica en relación con una realización, se expone que encuentra dentro de los conocimientos de un técnico de la materia el llevar a cabo dicha característica, estructura o peculiaridad en relación con otras realizaciones descritas de forma explícita o no.

En la siguiente descripción y reivindicaciones, se pueden utilizar los términos “acoplado” y “conectado”, junto con sus derivados. Se debe comprender que estos términos no est�n destinados a ser considerados sinónimos entre s�. “Acoplado” se utiliza para indicar que dos o más elementos, que pueden estar o no en contacto directo físico o eléctrico entre s� cooperan o interaccionan uno con otro. “Conectado” se utiliza para indicar el establecimiento de comunicación entre dos o más elementos que est�n acoplados entre s�.

Registro automático para sesiones de comunicación en línea

El objeto de la descripción es un procedimiento y aparato para el registro automático de un dispositivo inform�tico de cliente (“dispositivo de cliente”) (por ejemplo, una estación de trabajo, un ordenador portátil, un ordenador de mano, un teléfono celular, un teléfono inteligente, un teléfono multimedia, una tableta, un reproductor de medios portátil, una unidad GPS, un sistema de juegos, etc.) para sesiones de comunicación en línea (por ejemplo, conferencias de vídeo P2P, mensajes instantáneos P2P, etc.). En una realización, cuando tiene lugar un evento en un dispositivo inform�tico (por ejemplo, la activación del dispositivo inform�tico), el dispositivo de cliente empieza automáticamente un proceso de registro para sesiones de comunicación en línea. El proceso de registro automático incluye que el dispositivo de cliente transmita un mensaje SMS (short message service) (servicio de mensajes cortos) con un símbolo de identificación (por ejemplo, su símbolo automático o “push”) y un identificador del dispositivo de cliente a un dispositivo de tránsito de SMS (por ejemplo, una pasarela de SMS o un agregador de SMS. El símbolo de identificación identifica de modo único un dispositivo de cliente para mensajes de sesión de comunicación en línea (por ejemplo, mensajes de petición de invitación y de aceptación de invitación) y en una realización, es un símbolo automático que puede contener información que permite a un servicio de notificación automática el localizar el dispositivo de cliente. El símbolo de identificación en la realización del servicio de identificación automática se utiliza también como forma de establecer la expectativa o confianza de que una notificación especifica es legítima. En otras realizaciones, cualquier registro o mapeado de dispositivos de cliente con respecto a símbolos únicos se puede utilizar para asociar símbolo de identificación con dispositivos de cliente y facilitar un método de confianza de asociación de la identidad del dispositivo de cliente con un símbolo identificado de manera única. El identificador del dispositivo identifica de manera única el dispositivo de cliente, y se basa de manera típica en uno o varios identificadores de hardware (por ejemplo, el número de serie del dispositivo, un ICC-ID (Integrated Circuit Card ID) (Tarjeta ID de Circuito Integrado) o una tarjeta SIM (Subscriber Identity Module) (Módulo de Identidad del Abonado), etc.

El dispositivo de tránsito de SMS determina el número de teléfono del dispositivo de cliente (por ejemplo, al examinar la cabecera del mensaje SMS) y transmite un mensaje IP (Protocolo Internet) a un servidor de registro con el símbolo de identificación, identificador del dispositivo y número de teléfono. El servidor de registro genera una señal de identificación basada en el símbolo de identificación, identificador del dispositivo y número de teléfono, y transmite estos datos al dispositivo de tránsito de SMS para su suministro del cliente. El dispositivo de tránsito de SMS transmite un mensaje SMS al dispositivo de cliente incluyendo la señal de identificación y el número de teléfono. El dispositivo de cliente transmite entonces un mensaje IP al servidor de registro con la señal de identificación, identificador del dispositivo, símbolo de identificación y número de teléfono.

El servidor de registro valida la información procedente del dispositivo de cliente y almacena una asociación entre el símbolo de identificación y el número de teléfono en un almacenamiento de datos de registro de sesión de comunicación en línea. Conjuntamente, el par asociado del símbolo de identificación y el número de teléfono identifican de manera única el dispositivo en una red de sesión de comunicación en línea. Después de que el dispositivo de cliente ha sido registrado, un usuario en el dispositivo de cliente puede iniciar y/o aceptar una invitación para una sesión de comunicación en línea (por ejemplo, sesión de charla de vídeo/conferencia, sesión de mensaje instantáneo, etc.). En una realización, el número de teléfono de un dispositivo de cliente es utilizado como identificador de punto final de sesión de comunicación en línea de una sesión de comunicación en línea. A título de ejemplo, un usuario en un dispositivo de cliente, puede invitar a otros usuarios en otro dispositivo de cliente para participar en una sesión de comunicación en línea utilizando sus números de teléfono. En algunas realizaciones, el dispositivo de cliente no conoce de origen su propio número de teléfono.

La figura 1 es un diagrama de flujo de datos que muestra el registro de un dispositivo de cliente para sesiones de comunicación en línea, de acuerdo con una realización. La figura 1 incluye el dispositivo de cliente -110-, la red de SMS -120-, el servidor de registro -140- y el almacenamiento de datos de mensaje IP -150-. El dispositivo de cliente -110- (por ejemplo, una estación de trabajo, un ordenador portátil, un ordenador de mano, un teléfono celular, un teléfono inteligente, un teléfono multimedia, una tableta, un reproductor de medios portátil, una unidad GPS, un sistema de juegos, etc.) incluye el símbolo de identificación -115- (que puede ser un símbolo automático en una realización). El símbolo de identificación -115- identifica de forma única el dispositivo de cliente -110- para recibir una petición de invitación y aceptar una invitación (o rechazarla), que se describirán en mayor detalle más adelante. El identificador del dispositivo -117- identifica de forma única el dispositivo de cliente y se basa de manera usual en uno

o varios identificadores de hardware (por ejemplo, un número de serie del dispositivo, un ICC-ID (Tarjeta de ID de Circuito Integrado) o una tarjeta SIM (Módulo de Identidad de Abonado, etc.). El dispositivo de cliente -110- incluye la capacidad de transmitir y recibir mensajes SMS as� como la capacidad de conectarse y enviar/recibir mensajes IP.

Despu�s del registro para sesiones de comunicación en línea, el dispositivo de cliente -110- puede invitar y/o aceptar invitaciones para sesiones de comunicación en línea. El dispositivo de cliente -110- es identificado en las sesiones de comunicación en línea a través de un identificador de punto final de sesión de comunicación en línea. Si bien en una realización el identificador de punto final de la sesión de comunicación en línea es un número de teléfono del dispositivo de cliente -110-, en otras realizaciones, el identificador de punto final de sesión de comunicación en línea es un identificador distinto (por ejemplo, un nombre de usuario (por ejemplo, un ID de Apple), una dirección de correo electrónico, una dirección de correo, una dirección de MAC, u otro identificador).

La red SMS -120- que comprende el portador SMS (Short Message Service Center) (Centro de Servicio de Mensajes Cortos) -125-, y el dispositivo de tránsito de SMS -130- (por ejemplo, una pasarela de SMS o un agregador de SMS). El SMSC portador -125- es específico del dispositivo inform�tico portador, y recibe y suministra mensajes SMS. Por ejemplo, el portador SMSC -125- suministra mensajes SMS enviados desde el dispositivo de cliente -110- al dispositivo de tránsito de SMS -130-, y suministra mensajes de SMS enviados desde el dispositivo de tránsito de SMS -130- al dispositivo de cliente -110-. El dispositivo de tránsito de SMS -130- separa la red celular y la red de IP.

El servidor de registro -140- registra dispositivos de cliente, tales como el dispositivo de cliente -110- para sesiones de comunicación en línea. El registro de un dispositivo de cliente para sesiones de comunicación en línea incluye la asociación de un símbolo de identificación de un dispositivo con un número de teléfono del dispositivo (u otro identificador de punto final de sesión de comunicación en línea). Las asociaciones entre símbolos de identificación e identificadores finales de sesión de comunicación en línea est�n almacenadas en el almacenamiento de datos de registro de sesión de comunicación en línea -150-.

Cuando tiene lugar un evento en el dispositivo de cliente -110- (por ejemplo, la puesta en marcha del dispositivo de cliente, una aplicación de sesión de comunicación en línea (por ejemplo, una aplicación de conferencia de vídeo P2P, una aplicación de mensaje instantáneo P2P, etc.), lanzamiento, etc.), el dispositivo de cliente -110- empieza un proceso de registro para sesiones de comunicación en línea. En una realización, el proceso de registro empieza automáticamente (sin interacción del usuario), mientras que en otras realizaciones, el proceso de registro empieza después de que un usuario decide registrar el dispositivo de cliente para sesiones de comunicación en línea.

En realizaciones en las que el número de teléfono del dispositivo de cliente -110- es utilizado como identificador de punto final de la sesión de comunicación en línea y, por lo tanto, se tiene que asociar con el símbolo de identificación -115- del dispositivo de cliente -110- en el almacenamiento de datos de registro -150-, se debe determinar el número de teléfono del dispositivo de cliente -110-. Dado que el dispositivo de cliente -110- no conoce de origen su propio número de teléfono, en algunas realizaciones, el número de teléfono del dispositivo de cliente -110- es determinado a través del dispositivo de cliente -110- que transmite un mensaje SMS. Por ejemplo, en la operación -1-, el dispositivo de cliente -110- transmite un mensaje SMS con el símbolo de identificación -115- y el dispositivo identificador -117- al dispositivo de tránsito de SMS -130- a través del SMSC portador -125-. En algunas realizaciones, el mensaje SMS es dirigido a un número de teléfono, que puede ser un número de longitud estándar o un número de código más corto (un tipo de número de teléfono que es significativamente más corto que un número completo de teléfono), que se establece específicamente para registro de sesiones de comunicación en línea. El número de teléfono al que se dirige el mensaje SMS se almacena en el dispositivo de cliente (por ejemplo, en un haz portador).

El SMSC portador -125- recibe el mensaje SMS y lo facilita al dispositivo de tránsito de SMS -130-. El dispositivo de tránsito de SMS -130- determina el número de teléfono del dispositivo de cliente en la operación -2-. Por ejemplo, el dispositivo de tránsito de SMS -130- examina la cabecera del mensaje SMS para determinar el número de teléfono del dispositivo de cliente -110-. Después de determinar el número de teléfono, el dispositivo de tránsito de SMS -130- transmite un mensaje IP al servidor de registro -140- con el número de teléfono del dispositivo de cliente -110y el símbolo de identificación -115- y el identificador de dispositivo -117-. Todo ello se designa en algunos casos como mensaje de petición de registro.

El servidor de registro -140- recibe un mensaje IP del dispositivo de tránsito de SMS incluyendo el número de teléfono del dispositivo de cliente -110-, el símbolo de identificación -115-, el identificador de dispositivo -117- y crea una señal de identificación. La señal de identificación se puede basar en el número de teléfono del dispositivo de cliente -110-, el símbolo de identificación -115- y/o el identificador de dispositivo -117-, y es utilizado para objetivos de validación (que se describirán más adelante de forma más detallada). En algunas realizaciones, también se utiliza un número al azar cuando se genera la señal de identificación para tener en cuenta situaciones en las que múltiples dispositivos de cliente tienen el mismo número de teléfono. El servidor de registro -140- transmite la señal de identificación, número de teléfono, identificador del dispositivo y símbolo en retorno al dispositivo de tránsito de SMS -130- en la operación -5- (por ejemplo, en un mensaje IP). Esto se indica en algunos casos como mensaje de respuesta al registro.

El dispositivo de tránsito de SMS -130- recibe la señal de identificación, número de teléfono, identificador del dispositivo y símbolo del servidor de registro -140- y genera un mensaje SMS con la señal de identificación y el número de teléfono para el dispositivo de cliente -110-. El dispositivo de tránsito de SMS -130- transmite el mensaje de SMS al dispositivo de cliente -110- junto con la señal de identificación y número de teléfono en la operación -6- (a través del SMSC portador -125-).

El dispositivo de cliente -110- recibe y procesa el mensaje SMS incluyen el almacenamiento de su número de teléfono. El dispositivo de cliente -110- transmite un mensaje IP con su señal de identificación -115-, identificador de señal -117-, número de teléfono y señal de identificación generada por el servidor de registro al servidor de registro -140- en la operación -7-. Esto se designa en algunos casos como mensaje de petición de validación de registro.

Utilizando la señal de identificación, el servidor de registro -140- valida los datos enviados por el dispositivo de cliente -110-. Por ejemplo, el servidor de registro -140- compara la señal de identificación enviada por el dispositivo de cliente -110- con la señal de identificación generada durante la operación -4-. Si se corresponden, entonces los datos son validados. Suponiendo que los datos sean válidos, el servidor de registro -140- almacena una asociación entre el símbolo de identificación -115- y el número de teléfono del dispositivo de cliente -110- en el almacenamiento de datos -150- de registro de la sesión de comunicación.

En una realización alternativa, en vez de determinar el número de teléfono del dispositivo de cliente -110- mediante mensajes de SMS, el usuario del dispositivo recibe la indicación de introducir el número de teléfono del dispositivo de cliente -110-. En estas realizaciones, el dispositivo de cliente -110- transmite directamente el número de teléfono del dispositivo de cliente -110- (introducido por el usuario) y su símbolo de identificación -115- al servidor de registro -140-, que los puede asociar en el almacenamiento de datos de registro de sesión de comunicación en línea -150-.

La figura 5 muestra un almacenamiento de datos de registro -150- a título de ejemplo, de acuerdo con una realización. Tal como se ha mostrado en la figura 5, cada uno de los registros -510- de identificador de sesión de comunicación en línea, incluye un campo para el símbolo de identificación -520- y un campo para el número de teléfono -525-. En algunas realizaciones, es posible que un número de teléfono único est� asociado a múltiples símbolos de identificación. Por ejemplo, diferentes dispositivos de clientes pueden tener un mismo número de teléfono. En estos casos, estos dispositivos de cliente diferentes, tendrían diferentes símbolos de identificación. Por lo tanto, cuando se envía una invitación para una sesión de comunicación en línea para un número de teléfono asociado con múltiples símbolos de identificación, se transmitir� una invitación a cada dispositivo asociado con el símbolo de identificación.

La figura 2 es un diagrama de bloques que muestra el dispositivo de cliente -110- con mayor detalle según una realización. La figura 2 se describir� haciendo referencia a la realización a título de ejemplo de la figura 4, que es un diagrama de flujo ilustrativo a título de ejemplo para registrar un dispositivo de cliente para sesiones de comunicación en línea. No obstante, se debe comprender que las operaciones de la figura 4 se pueden llevar a cabo por realizaciones distintas de las explicadas con referencia a la figura 2, y las realizaciones explicadas con referencia a la figura 2 pueden llevar a cabo operaciones diferentes de las explicadas con referencia a la figura 4.

Tal como se ha mostrado en la figura 2, el dispositivo de cliente -110- incluye el modelo de registro de sesión de comunicación en línea (“Módulo de registro de cliente”) -210-, el haz o haces portadores -215-, el símbolo de identificación -115-, identificador de dispositivo -117-, el módulo SMS -220- y el almacenamiento de datos de registro de sesión de comunicación en línea (“almacenamiento de datos de registro de cliente”) -230-. El módulo de registro de cliente -210- controla el registro del dispositivo de cliente -110- para sesiones de comunicación en línea. El haz o haces portadores -215- incluyen ajustes específicos para un portador, incluyendo el número de teléfono para el dispositivo de tránsito de SMS utilizado para registro (por ejemplo, el número del dispositivo de tránsito de SMS -130-) y otros ajustes (por ejemplo, Ajustes del Nombre de Punto de Acceso (APN), ajustes de Servicio de Mensajes Multimedia (MMS), etc.). El módulo SMS -220- trasmite y recibe mensajes SMS. El almacenamiento -230- de datos de registro de cliente almacena datos relativos al registro de la sesión de comunicación en línea (por ejemplo, número de teléfono del dispositivo de cliente -110- una vez determinado).

Haciendo referencia a la figura 4, en el bloque -410-, el módulo de registro de cliente -210- detecta o recibe un evento que pone en marcha el registro de la sesión de comunicación en línea. Se incluyen entre los ejemplos de

dichos eventos la activación del dispositivo de cliente -110-, la apertura de una aplicación de comunicación en línea por un usuario (por ejemplo, una aplicación de conferencia de vídeo P2P, una aplicación de mensaje instantáneo P2P, etc.), etc. En algunas realizaciones, el proceso de registro es llevado a cabo cada vez que el dispositivo de cliente -410- se activa, mientras que en otras realizaciones, el proceso de registro es llevado a cabo la primera vez que se activa el dispositivo de cliente -110-. El flujo se desplaza desde el bloque -410- al bloque -415-.

En el bloque -415-, el módulo -210- de registro de cliente determina si existe un símbolo de identificación válido para el dispositivo de cliente -110-. Si no hay símbolo de identificación o el símbolo de identificación ha expirado, entonces el flujo se desplaza al bloque -425- en el que se toma una acción alternativa. Por ejemplo, en realizaciones que utilizan símbolos automáticos, el dispositivo de cliente -110- puede iniciar un proceso de generación de símbolo pidiendo la generación de un símbolo automático por un servicio de notificación automática (que de manera típica est� alejado del dispositivo de cliente -110-). El servicio de notificación automática genera un símbolo automático específico para el dispositivo de cliente -110- y lo devuelve al dispositivo de cliente -110-. Si es un símbolo de identificación válido, entonces el flujo se desplaza al bloque -420-, en el que el módulo de registro de cliente -210tiene acceso al símbolo de identificación -115-. El flujo se desplaza del bloque -420- al bloque -428-.

El bloque -428-, el módulo -210- de registro de cliente accede al identificador de dispositivo -117-. Entonces, el flujo se desplaza al bloque -430-, en el que el módulo de registro de cliente -410- determina el número de teléfono para el dispositivo de tránsito de SMS utilizado en el proceso de registro. Por ejemplo, el módulo de registro de cliente -210accede al haz o haces portadores -215- para determinar el número de teléfono del servicio de tránsito de SMS. El número de teléfono puede ser un código abreviado o puede ser un número de longitud estándar. En este ejemplo, el dispositivo de tránsito SMS utilizado en el proceso de registro es el dispositivo de tránsito de SMS -130-. El flujo se desplaza del bloque -430- al bloque -435-.

En el bloque -435-, se transmite un mensaje SMS que tiene el símbolo de identificación -115- y el identificador de dispositivo -117- al número determinado (dispositivo de tránsito de SMS -130-). Por ejemplo, el módulo de registro de cliente -210- requiere al módulo de SMS -220- transmitir un mensaje SMS con el símbolo de identificación -115- y el identificador de dispositivo -117- al número determinado. El módulo de SMS -220- transmite el mensaje de SMS con el símbolo de identificación a un número determinado. El flujo se desplaza del bloque -435- al bloque -440-. El mensaje SMS ser� recibido por el SMSC portador -125-, que lo suministra al dispositivo de tránsito de SMS -130-.

En el bloque -440-, el dispositivo de tránsito de SMS -130- determina el número de teléfono del dispositivo de cliente -110- basándose en el mensaje SMS recibido. Por ejemplo, el dispositivo de tránsito de SMS examina la cabecera del mensaje SMS que incluir� el número de teléfono del remitente, que en este caso es el dispositivo de cliente -110-. El flujo se desplaza entonces al bloque -445- en el que el dispositivo de tránsito de SMS -130- transmite el número de teléfono de dispositivo de cliente -110-, el símbolo de identificación -115- y el identificador de dispositivo -117- al servidor de registro -140- (por ejemplo, en un mensaje seguro IP). El flujo se desplaza del bloque -445- al bloque -450-.

La figura 3 es un diagrama de bloques que muestra el servidor de registro -140- de manera más detallada, de acuerdo con una realización. La figura 3 se describir� haciendo referencia a la realización a título de ejemplo de la figura 4. No obstante, se debe comprender que las operaciones de la figura 4 pueden ser llevadas a cabo por realizaciones distintas de las explicadas con referencia a la figura 3 y las realizaciones explicadas con referencia a la figura 3 pueden llevar a cabo operaciones diferentes de las explicadas con referencia a la figura 4. Tal como se ha mostrado en la figura 3, el servidor de registro -140- incluye el módulo servidor -305- de registro de sesión de comunicación en línea, que comprende el interfaz de tránsito de SMS -310-, el generador de señal de identificación -315-, el dispositivo interfaz de cliente -325-, el módulo de validación -330-, el almacenamiento de datos de validación -335- y el módulo de asociación -340-. El interfaz de tránsito de SMS -310- recibe y envía mensajes al dispositivo -130- de tránsito de SMS. Por ejemplo, el interfaz de tránsito de SMS -310- recibe el número de teléfono, símbolo de identificación y líneas del identificador de dispositivo desde el interfaz -130- de tránsito de SMS y transmite el número de teléfono, señal de identificación, identificador del dispositivo y líneas de la señal de identificación (designadas en algunos casos como “líneas de validación”) al interfaz -310- de tránsito de SMS. El interfaz -325- del dispositivo de cliente recibe y puede transmitir mensajes a dispositivo de cliente. Por ejemplo, el interfaz -325- del dispositivo de cliente recibe líneas de validación de los dispositivos de cliente.

Haciendo referencia nuevamente a la figura 4, en el bloque -450- el generador de señal de identificación -310genera una señal de identificación para el número de teléfono, símbolo de identificación y línea del identificador dispositivo que ha recibido del dispositivo -130- de tránsito de SMS. La señal de identificación ser� utilizada para validar el apareamiento del número de teléfono y del símbolo de identificación antes de almacenar el par en el almacenamiento de datos -150- de registro. En algunas realizaciones, la señal de identificación se basa en el número de teléfono, símbolo de identificación y/o identificador de dispositivo (por ejemplo, se aplica un acortamiento (“hash”) criptogr�fico al número de teléfono, símbolo de identificación y/o identificador de dispositivo o a una parte de los mismos, para generar la señal de identificación). En algunas realizaciones, la señal de identificación se basa también en un número al azar para tener en cuenta situaciones en las que múltiples dispositivos de cliente tiene el mismo número de teléfono. El generador -310- de señal de identificación almacena la señal de identificación y opcionalmente el número de teléfono, símbolo de identificación y/o identificador de dispositivo en el almacenamiento

de datos de validación -325-. El flujo se desplaza entonces al bloque -455- en el que el interfaz -310- de tránsito de SMS transmite la señal de identificación número de teléfono, identificador de dispositivo y señal de identificación al dispositivo -130- de tránsito de SMS. El flujo se desplaza del bloque -455- al bloque -460-.

El dispositivo -130- de tránsito de SMS recibe la señal de identificación, el número de teléfono y el símbolo de identificación del servidor de registro -140-. En el bloque -460- el dispositivo de tránsito de SMS transmite un mensaje SMS (a través del SMSC portador -125-) con la señal de identificación y el número de teléfono para el dispositivo de cliente -110-. El flujo se desplaza a continuación al bloque -465-.

En el bloque -465-, el módulo de SMS -220- recibe el mensaje SMS con la señal de identificación y el número de teléfono y almacena la señal de identificación y el número de teléfono en el almacenamiento de datos de registro de cliente -230-. El flujo se desplaza a continuación, al bloque -470-, en el que el módulo -210- de registro de cliente transmite un mensaje IP al servidor de registro con su número de teléfono, símbolo de identificación -115-, identificador de dispositivo -117- y señal de identificación. El flujo se desplaza entonces, al bloque -475-.

El interfaz -325- del dispositivo de corriente recibe el número de teléfono, símbolo de identificación, identificador de dispositivo y señal de identificación del dispositivo de cliente. La información es pasada al módulo de validación -330- que determina si los datos son válidos en el bloque -475-. Por ejemplo, la misma función de acortamiento (“hash”) aplicada cuando se genera la señal de identificación es utilizada en el número de teléfono, símbolo de identificación y/o identificador de dispositivo recibido del dispositivo de cliente y el módulo de validación -330compara el resultado con la señal de identificación previamente generada (almacenada en el almacenamiento de datos de validación -335-). Si las señales de identificación se corresponden, entonces los datos son válidos y el flujo de desplaza al bloque -480-.

En el bloque -480-, el módulo de asociación -330- del servidor de registro -140- almacena una asociación del número de teléfono del dispositivo de cliente y el símbolo de identificación del dispositivo de cliente en el almacenamiento de datos -150- de registro. En algunas realizaciones, el servidor de registro -140- puede transmitir un mensaje de situación de registro al dispositivo de cliente -110- avisando al dispositivo de cliente -110- de si el registro ha sido satisfactorio.

Despu�s de que el dispositivo de cliente ha sido registrado, un usuario en el dispositivo de cliente puede iniciar y/o aceptar una invitación para una sesión de comunicación en línea (por ejemplo, charla de vídeo, sesión de conferencia, sesión de mensaje instantáneo, etc.) a título de ejemplo, un usuario en un dispositivo de cliente puede invitar a otros usuario de otros dispositivos de cliente para participar en una sesión de comunicación en línea utilizando su número o números de teléfono. En algunas realizaciones, el dispositivo de cliente no sabe en origen su propio número de teléfono. Si bien algunas realizaciones han descrito la utilización de mensajes SMS durante el registro, en otras realizaciones se pueden utilizar otros tipos de mensajes de texto (por ejemplo, MMS (servicio de mensajes multimedia)).

Registro de direcciones de correo electrónico para sesiones de comunicación en línea

Si bien la figura 1 ha sido descrita en relación con el registro de un número de teléfono como un identificador de punto final de sesión de comunicación, en otras realizaciones se utiliza una dirección de correo electrónico como identificador de punto final de sesión de comunicación en línea. La figura 21 muestra una topología general de red utilizada para registrar un dispositivo de cliente para sesiones de comunicación en línea utilizando una dirección de correo electrónico como identificador de punto final de sesión de comunicación en línea. Los dispositivos de cliente -2110A-N utilizan el servicio de registro -2130- para registrar sesiones de comunicaciones en línea. Por ejemplo, en una realización, el usuario del dispositivo de cliente -2110A- utiliza el cliente -2115- de la sesión de comunicación en línea para registrar una dirección de correo electrónico a utilizar como identificador de sesión de comunicación en línea para comunicaciones en línea por la red -2180- (por ejemplo, Internet).

Las figuras 22A-B son diagramas de flujo que muestran operaciones a título de ejemplo para el registro de una dirección de correo electrónico como identificador de punto final de sesión de comunicación en línea, de acuerdo con una realización. Las figuras 22A-B se describirán haciendo referencia a la realización a título de ejemplo mostrada en la figura 21. No obstante, se debe comprender que las operaciones de las figuras 22A-B pueden ser llevadas a cabo por otras realizaciones distintas a las explicadas con referencia a la figura 21 y las realizaciones explicadas con referencia a la figura 21 pueden llevar a cabo operaciones distintas de las explicadas con referencia a las figuras 22A-B.

En la operación -2210-, el servicio de registro -2130- recibe una petición de autentificaci�n procedente del dispositivo de cliente -2110A-. Por ejemplo, con referencia a la figura 23 que describe operaciones a título de ejemplo para un usuario que proporciona información de inicialización, en la operación -2310-, la aplicación -2115- de sesión de comunicación en línea es iniciada en el dispositivo de cliente -2110A-. Entonces, el flujo se desplaza a la operación -2315- y el dispositivo de cliente -2110A- recibe una entrada del usuario incluyendo ID de usuario y palabra de contraseña y una o varias direcciones de correo electrónico para registro para utilización como identificador o identificadores de punto final de sesión de comunicación en línea. El flujo se desplaza a continuación a la operación

-2320- y el dispositivo de cliente -2110A- transmite el ID de usuario y la contraseña al servicio de registro -2130-. Si bien el dispositivo de cliente -2110A- registra una dirección de correo electrónico como identificador de punto final de sesión de comunicación en línea y puede no incluir funcionalidad de teléfono, puede enviar una invitación de sesión de comunicación en línea utilizando un número de teléfono en vez de una dirección de correo electrónico. Además de recibir un ID de usuario, contraseña y una o varias direcciones de correo electrónico a registrar, en algunas realizaciones, el usuario puede proporcionar también información con respecto a qué país y/o región est�n situados, de manera que se pueda utilizar un código correspondiente de país y/o región si el usuario pone en marcha una sesión de comunicación en línea a un número de teléfono que no comprende el código de país y/o código de región. Por ejemplo, en EEUU se puede hacer una llamada de teléfono local utilizando siete dígitos (por lo tanto, no se requiere el código de país y el código de área). El sistema telefónico subyacente determina automáticamente el país y el código de área y completa la llamada. No obstante, en casos en los que el dispositivo de cliente -2110A- no incluye funcionalidad de teléfono, el dispositivo de cliente -2110A- no puede basarse en el sistema telefónico subyacente para incluir automáticamente el código de país y/o el código de región cuando invite a un usuario a una sesión de comunicación en línea utilizando un número de teléfono que no incluye el código de país y/o el código de región.

En la operación -2320-, el dispositivo de cliente -2110A- recibe una entrada del usuario con respecto a qué país y/o región est�n situados (por ejemplo, código de área, estado, provincia, ciudad, etc.). El flujo se desplaza entonces en la operación -2320- en la que el dispositivo de cliente -2320- asocia los correspondientes códigos de teléfono de país y/o región con la aplicación -2115- de sesión de comunicación en línea para utilización si el usuario inicia una sesión de comunicación en línea a un número de teléfono que no incluye numero de país y/o código de región. Por ejemplo, si el usuario indica que est� situado en EEUU y el usuario invita a un usuario a una sesión de comunicación en línea utilizando un número de teléfono de 10 dígitos que no incluye el código de país, el dispositivo de cliente -2110Aa�ade automáticamente el código de país para EEUU al número de teléfono.

Haciendo referencia nuevamente a la figura 22A, después de recibir la petición de autentificaci�n del dispositivo de cliente -2110A- se lleva a cabo un proceso de autentificaci�n utilizando el nombre del usuario y la contraseña facilitados. En una realización, el servicio de registro -2130- lleva a cabo el proceso de autentificaci�n, mientras que en otra realización, el servicio de directorio -2160- del usuario lleva a cabo el proceso de autentificaci�n. El servicio de directorio de usuario -2160- es un servicio centralizado que proporciona contabilizaci�n de usuario, autentificaci�n y otros servicios. El servicio de directorio de usuario -2160- gestiona los registros de usuario -2165-. En una realización, cada uno de los usuarios autentificados es asociado con un registro de usuario que incluye varias informaciones (por ejemplo, uno o varios ID de usuario, contraseña, dirección de correo electrónico, número de teléfono, nombre, fecha de nacimiento, país, lista de correos electrónicos asociados con el usuario (que puede indicar también si la dirección de correo electrónico est� validada), etc.). Si la autentificaci�n es satisfactoria, entonces el flujo se desplaza a la operación -2216-. Si la autentificaci�n fracasa, entones el flujo se desplaza a la operación -2214- y se toma una acción alternativa (por ejemplo, el servicio de registro -2130- transmite un mensaje de error al dispositivo de cliente -2110A- que indica que el nombre del usuario y/o la contraseña no son correctos).

En la operación -2216- el servicio de registro -2130- genera y/o accede a un perfil de sesión de comunicación en línea asociado con el ID de usuario. Por ejemplo, el servicio -2130- de registro puede incluir un servidor de contabilizaci�n de sesión de comunicación en línea -2140- que gestiona los registros -2150- de perfil de sesión de comunicación en línea. En una realización, cada usuario se registra o est� registrado para sesiones de comunicación en línea teniendo un registro de perfil de sesión de comunicación en línea correspondiente. Cada registro de perfil de sesión de comunicación en línea puede incluir un conjunto de una o varias direcciones de correo electrónico, incluyendo su situación de validación, que se asocian con el perfil. Cada registro de perfil de sesión de comunicación en línea puede incluir también uno o varios símbolos automáticos que corresponden a uno o varios dispositivitos de cliente respectivamente que est�n registrados para sesiones de comunicación en línea. Cada registro de perfil puede incluir credenciales de perfil que se utilizan para validar ciertas comunicaciones de dispositivos de cliente. Cada registro de perfil puede indicar también qué dispositivo de cliente (indicados por símbolos automáticos) se han registrado o intentan registrar unas determinadas direcciones de correo electrónico.

El flujo se desplaza de la operación -2216- a la operación -2218- y el servicio de registro -2130- transmite una respuesta de autentificaci�n al dispositivo de cliente -2110A- que incluye el ID de perfil (por ejemplo, una cadena que identifica el perfil asociado con el ID de usuario facilitado) y las credenciales del perfil. La respuesta de autentificaci�n puede indicar también que la autentificaci�n ha sido satisfactoria. Entonces el flujo se desplaza a la operación -2220- y el servicio de registro -2130- recibe una petición de validación de correo del dispositivo de cliente -2110A- que incluye una o varias direcciones de correo electrónico para validar, ID de perfil, credenciales de perfil y símbolo automático del dispositivo de cliente -2110A-. El mensaje de petición de validación de correo electrónico puede incluir también el ID del dispositivo de cliente -2110A-. El servicio de registro -2130- determina entonces si las credenciales del perfil son válidas para el ID de perfil en la operación -2222-. Si no lo son, el flujo se desplaza a la operación -2224- y se toma una acción alternativa (por ejemplo, el servicio de registro -2130- transmite un mensaje de error al dispositivo de cliente -2210A-). Si las credenciales de perfil son válidas, entonces el flujo se desplaza a la operación -2223-. En la operación -2223- el servicio de registro -2130- asocia el símbolo automático con el perfil. Por ejemplo, el servidor de contabilizaci�n de sesión de comunicación en línea -2140- almacena el símbolo automático en el registro de perfil para el usuario.

A continuación, el flujo se desplaza a la operación -2226- y el servicio de registro -2130- determina si se valida la dirección de correo electrónico. Una dirección de correo electrónico validada es una dirección de correo electrónico que ha sido validada como perteneciente al usuario, que solicita que su petición sea registrada para utilización como identificador de punto final de la sesión de comunicación en línea. El servidor de contabilizaci�n de la sesión de comunicación en línea -2140- accede al registro -2150- del perfil de usuario para determinar si la dirección de correo electrónico est� validada. Si el registro del perfil no indica que la dirección de correo electrónico est� validada, en algunas realizaciones el servicio de registro -2130- transmite una petición de validación de correo electrónico al servicio de directorio de usuario -2160- para determinar si el registro de usuario -2165- para el usuario indica que se ha validado la dirección de correo electrónico. Si la dirección de correo electrónico no ha sido validada entonces el flujo se desplaza a la operación -2227- y el servicio de registro -2130- provoca el envío de un mensaje de correo electrónico de validación a la dirección de correo electrónico que incluye un enlace, tal que cuando es seleccionado (o cuando es introducido en un navegador de internet) provoca la validación de la dirección de correo electrónico. Por ejemplo, la selección del enlace provoca el envío de un mensaje de validación de dirección de correo electrónico que incluye la dirección de correo electrónico y un símbolo de validación que son utilizados para validar la dirección de correo electrónico. El servicio de registro -2130- puede transmitir también un mensaje de que se requiere la validación de la dirección de correo electrónico al dispositivo de cliente, que indica que la dirección del correo electrónico no est� validada (y, por lo tanto, requiere ser validad) y puede indicar también que un mensaje de correo electrónico de validación fue enviado a la dirección de correo electrónico en cuestión. El flujo se desplaza entonces a la operación -2410-, que se describir� con referencia a la figura 24. No obstante, si la dirección de correo electrónico est� validada, entonces el flujo se desplaza a la operación -2228-.

En la operación -2228-, el servicio de registro -2130- transmite un mensaje de éxito de la validación de la dirección de correo electrónico al dispositivo de cliente -2228-, que indica que la dirección de correo electrónico ha sido validada. Entonces el flujo se desplaza a la operación -2230- y el servicio de registro -2130- recibe una petición de correo electrónico activada del dispositivo de cliente -2228- que incluye la dirección de correo electrónico, el ID del perfil y las credenciales del perfil. El servicio de registro -2130- determina entonces si las credenciales del perfil son válidas para el ID del perfil en la operación -2232-. Si no lo son, el flujo se desplaza a la operación -2234- y se realiza una acción alternativa (por ejemplo, el servicio de registro -2130- transmite un mensaje de error al dispositivo de cliente -2110A-). Si las credenciales de perfil son válidas entonces el flujo se desplaza a la operación -2240-.

En la operación -2240- el servicio de registro -2130- genera o accede a las credenciales de correo electrónico para la dirección de correo electrónico. Por ejemplo, en una realización, el servidor -2140- de contabilizaci�n de sesión de comunicación en línea almacena las credenciales de correo electrónico para cada dirección de correo electrónico validada de un usuario en el registro -2150- de perfil de usuario. El flujo se desplaza entonces a la operación -2242y el servicio de registro -2130- transmite un mensaje de éxito de la activación al dispositivo de cliente -2110A- que incluye la dirección de correo electrónico y las credenciales de correo electrónico.

El flujo se desplaza de la operación -2242- a la operación -2244- y el servicio de registro -2130- recibe un mensaje de petición de registro que incluye la dirección de correo electrónico, las credenciales de correo electrónico, el ID de perfil, las credenciales de perfil, el símbolo automático del dispositivo de cliente -2110A- y el ID de dispositivo del dispositivo de cliente -2110A-. En una realización, el mensaje de petición es recibido en el servidor -2145- de registro de sesión de comunicación en línea. El servidor de registro de sesión de comunicación en línea gestiona el almacenamiento -2155- de datos de registro de sesión de comunicación. El almacenamiento -2155- de datos de registro de sesión de comunicación en línea asocia un símbolo automático (y opcionalmente el ID del dispositivo) con el perfil que ha dispuesto una o varias direcciones de correo electrónico como identificador o identificadores de punto final de sesión de comunicación en línea. De este modo, cada registro del almacenamiento de datos -2155- de registro de sesión de comunicación representa que un dispositivo específico con un símbolo automático particular utiliza un perfil de sesión de comunicación en línea que tiene una o varias direcciones de correo electrónico que pueden ser utilizadas para invitar a un usuario en aquel dispositivo a una sesión de comunicación en línea. El flujo se desplaza de la operación -2244- a la operación -2246-.

En la operación -2246- el servicio de registro -2130- (por ejemplo, el servidor -2145-de registro de sesión de comunicación en línea) determina si son válidas las credenciales de perfil. Si no son válidas, entonces el flujo se desplaza a la operación -2250- y se toma una acción alternativa (por ejemplo, el servicio -2130- de registro transmite un mensaje de error al dispositivo de cliente -2110A-). Si son válidas, entonces el flujo se desplaza a la operación -2248- y el registro de servicio -2130- (por ejemplo, el servidor -2145- de registro de sesión de comunicación en línea) determina si las credenciales de dirección del correo electrónico son válidas. Si no lo son, entonces el flujo se desplaza a la operación -2250-. Si son válidas, entonces el flujo se desplaza a la operación -2252-.

En la operación -2252- el servicio de registro -2130- (por ejemplo, el servidor -2145-de registro de sesión de comunicación en línea) asocia el dispositivo de cliente -2110A- con su símbolo automático con el perfil que tiene la dirección de correo electrónico y almacena la asociación en el almacenamiento -2155- de datos de registro. Entonces, el flujo se desplaza a la operación -2254- y el servicio de registro -2130- genera un identificador de contabilizador de sesión de comunicación en línea y credenciales de sesión de comunicación en línea y los transmite al dispositivo -2110A- del cliente en la operación -2256-.

Existen diferentes maneras de validar direcciones de correo electrónico en diferentes realizaciones. Haciendo referencia a la figura 24, que es un diagrama de flujo que muestra operaciones a título de ejemplo para validar una dirección de correo electrónico, en la operación -2410-, el dispositivo de cliente -2110A- determina si incluye un cliente de correo electrónico que comprende una cuenta para una dirección electrónico que ha intentado registrar y no ha recibido ningún mensaje de correo electrónico de validación positiva. Si no incluye dicho correo electrónico de cliente, entonces el flujo se desplaza a la operación -2240-, de otro modo, se desplaza a la operación -2415-.

En la operación -2415-, la cuenta de correo electrónico es comprobada automáticamente de forma periódica en cuanto a un mensaje de correo electrónico de validación (por ejemplo, el mensaje de correo electrónico de validación transmitido en la operación -2227-). En una realización, la aplicación -2115- de sesión de comunicación en línea pide periódicamente al cliente de correo electrónico -2120- que compruebe el mensaje de correo electrónico de validación (el cliente de correo electrónico -2120- puede explorar el servidor de correo electrónico -2170- para comprobar el mensaje de correo electrónico de validación). El mensaje de correo electrónico de validación es identificado por un conjunto de uno o varios criterios que incluyen el Desde: campo, el A: campo y un símbolo de validación (el símbolo de validación puede ser único para cada dirección de correo electrónico sometido a validación) que se utiliza para validar direcciones de correo electrónico. El símbolo de validación puede estar situado en la cabecera o en el cuerpo del mensaje de correo electrónico de validación. Si se recibe el mensaje de correo electrónico de validación, entonces el flujo se desplaza de la operación -2420- a la operación -2425-, de otro modo, pasa a la operación -2435-.

En la operación -2425-, el mensaje de correo electrónico de validación es devuelto a la aplicación -2115- de sesión de comunicación en línea y analiza el mensaje para localizar el símbolo de validación. Después de localizar el símbolo de validación, la aplicación -2215- de sesión de comunicación en línea transmite un mensaje de validación de dirección de correo electrónico al servicio de registro -2130- con el símbolo de validación, la dirección de correo electrónico, el ID de perfil y las credenciales de perfil. De este modo, en esta realización, la dirección de correo electrónico es validada automáticamente sin requerir que el usuario pulse en un enlace o valide de otro modo la dirección de correo electrónico. En una realización, después de recibir el mensaje y de determinar que las credenciales del perfil son válidas, el servicio de registro -2130- transmite un mensaje automático validado de correo electrónico (a través del servicio de notificación automática -640-) al dispositivo, que indica que la dirección de correo electrónico ha sido validada satisfactoriamente. De este modo, el flujo se desplaza de la operación -2425- a la operación -2430- y el dispositivo de cliente -2110A- espera para el mensaje automático de la dirección de correo electrónico validada.

Si el mensaje de correo electrónico de validación no ha sido recibido, entonces el flujo se desplaza a la operación -2435-, en la que el dispositivo de cliente determina si se ha recibido un mensaje automático de correo electrónico validado que indica que la dirección de correo electrónico que intenta ser registrada ha sido validada. Si se recibe este mensaje, entonces el flujo se desplaza a la operación -2445-, de otro modo, el flujo retrocede a la operación -2415-.

En la operación -2440- (el dispositivo de cliente -2110A- no incluye un correo electrónico de cliente que comprenda una cuenta para la dirección de correo electrónico que est� siendo registrada), el dispositivo de cliente -2110Aespera para recibir un mensaje automático validado de correo electrónico que se ha recibido indicando que la dirección de correo electrónico que intenta ser registrada ha sido validada. Si se recibe este mensaje, entonces el flujo se desplaza a la operación -2445-, de otro modo, el flujo permanece en la operación -2440-.

En la operación -2445-, el dispositivo de cliente -2110A-muestra que la dirección de correo electrónico ha sido validada y pide al usuario continuar con el proceso de registro con aquella dirección de correo electrónico. Si el dispositivo de cliente -2110A- recibe una indicación de entrada para continuar con el proceso de registro, entonces el flujo se desplaza a la operación -2455- y el dispositivo de cliente -2110A- transmite una petición de correo electrónico activo que incluye la dirección de correo electrónico, el ID de perfil y las credenciales de perfil al servidor de registro. Las operaciones descritas que empiezan en la operación -2230- de la figura 22 son llevadas a cabo a continuación. Si el dispositivo de cliente -2110A- recibe indicación de entrada de que el usuario no desea continuar con el proceso de registro, entonces el flujo se desplaza de la operación -2450- a la operación -2460- y terminando el proceso.

La figura 25 es un diagrama de flujo que muestra operaciones a título de ejemplo llevadas a cabo en el servicio de registro cuando se ha validado la dirección de correo electrónico de acuerdo con una realización. En la operación -2510-, el servicio de registro -2130- recibe un mensaje de situación validada de la dirección de correo electrónico que indica que una dirección de correo electrónico asociada con el perfil de sesión de comunicación en línea ha sido validada. El mensaje de situación validada de la dirección de correo electrónico puede haber sido recibido como resultado de la operación -2425- o se puede haber recibido como resultado de la validación de la dirección de correo electrónico de diferente manera (por ejemplo, el accionamiento por parte de un usuario de un enlace de validación en un enlace de correo electrónico de validación que provoca la validación de la dirección de correo electrónico, que puede ser enviado en un dispositivo diferente que el dispositivo que est� intentando registrar la dirección de correo electrónico para utilización en sesiones de comunicación en línea).

El flujo se desplaza entonces a la operación -2515- y el servicio de registro -2130- actualiza la situación de validación para la dirección de correo electrónico en los registros de perfil -2150-. El flujo se desplaza entonces a la operación -2515- y el servicio de registro -2130- determina si existen dispositivos de cliente que est�n asociados con el perfil de sesión de comunicación en línea que hayan pedido validar la dirección de correo electrónico que no ha recibido el mensaje validado de la dirección de correo electrónico. Por ejemplo, el dispositivo de registro -2130accede al registro de perfil -2150- para que el perfil de sesión de comunicación en línea determine cuáles de los dispositivos de cliente (por ejemplo, identificados por símbolos automáticos únicos) han pedido validar la dirección de correo electrónico y cuáles no han recibido un mensaje de validación de la dirección de correo electrónico para aquella dirección de correo electrónico. Para cada uno de estos dispositivos de cliente, el servicio de registro transmite un mensaje automático validado de correo electrónico a aquel dispositivo de cliente que incluye el ID de perfil, credenciales de perfil y dirección de correo electrónico que han sido validados en la operación -2525-. El mensaje automático validado de correo electrónico puede incluir también una actualización de situación para indicar que la dirección de correo electrónico ha sido validada. Si no hay dispositivos que no hayan pedido validar la dirección de correo electrónico que no han recibido el mensaje validado de dirección de correo electrónico, entonces el flujo se desplaza a la operación -2530- y el proceso termina.

Establecimiento de sesiones de comunicación en línea.

Tal como se ha mostrado en la figura 6, una topología de red general implementada en una realización puede incluir una serie de dispositivos de cliente -A-N-, -670A-N-, respectivamente, que comunican entre s� y con uno o varios servicios -610-, -620-, -630-, -640- y -650- a través de una red -660-. Si bien se ha mostrado como una única nube de red, la red -660- puede comprender una serie de diferentes componentes incluyendo redes públicas, tales como redes de internet y redes privadas tales como redes locales WiFi (por ejemplo, redes inalámbricas domésticas, 802.11n, o puntos calientes inalámbricos (“hotspots”)), redes de área local Ethernet, redes de datos celulares (por ejemplo, 3G, 4G, Edge, etc.) y redes WiMAX, entre otras. Los dispositivos de cliente -670A-N- pueden conectarse a la red -660- por diferentes enlaces de red. Por ejemplo, el dispositivo de cliente -670A- se puede conectar a una red doméstica WiFi representada por el enlace de red -675A- y el dispositivo de cliente -670N- puede estar conectado a una red 3G (por ejemplo, Universal Mobile Telecommunications System ("UMTS"), High-Speed Uplink Packet Access ("HSU PA"), etc.) a través del enlace de red -675N-. Cada uno de los enlaces de red -675A-N- por el que se conectan los dispositivos de cliente -670A-N- se puede acoplar a una red pública, tal como internet, a través de una pasarela y/o dispositivo NAT (Network Address Translation) (no mostrado en la figura 6), posibilitando de esta manera la comunicación entre los diferentes dispositivos de cliente -670A-N- a través de la red pública. No obstante, si dos dispositivos de cliente se encuentran en la misma red local o red privada (por ejemplo, la misma red WiFi) entonces los dos dispositivos pueden comunicar directamente a través de dicha red local/privada derivándose de la red pública. Se debe observar, desde luego, que los principios subyacentes de la invención no est�n limitados a ningún conjunto particular de tipos de red o de topologías de red.

Cada uno de los dispositivos de cliente -670A-N- puede comunicar con un servicio de intercambio de datos de conexión (CDX) -610-, un servicio de invitación -620-, un servicio de registro -630-, un servicio de notificación automática -640- y un servicio de retransmisión -650-. En una realización, los servicios -610-650- pueden ser implementados como software ejecutado a través de uno o varios dispositivos inform�ticos físicos tales como servidores.

En una realización, el servicio de CDX -610- funciona como punto de intercambio central para datos de conexión requeridos para establecer sesiones de comunicación en línea entre dos o más dispositivos de cliente. De manera específica, una realización del servicio CDX -610- genera datos transversales NAT (designados en algunos casos como datos de perforación o “Hole Punch”) en respuesta a peticiones de dispositivos de cliente para activar servicios externos y clientes para que se comuniquen a través del NAT de cada dispositivo de cliente (es decir, “punzar un orificio” (“punch a hole”) a través del NAT para llegar al dispositivo). Por ejemplo, en una realización el servicio de CDX detecta la dirección de IP externa y el puerto necesario para comunicar con un dispositivo de cliente y proporcionar esta información al dispositivo de cliente. En una realización, el servicio de CDX recibe también y procesa listas de dispositivos de cliente generadas por el servicio de invitación -620- y distribuye de manera eficiente y segura datos de conexión a cada uno de los dispositivos de cliente, incluidos en las listas (tal como se describe en detalle más abajo).

Los usuarios de los dispositivos de cliente -670A-N- utilizan el servicio de invitación -620- para invitar usuarios a participar en sesiones de comunicación en línea colaborativas (por ejemplo, conferencias de vídeo P2P, charlas/conferencias de mensajes instantáneos P2P, etc.). Por ejemplo, un usuario del dispositivo de cliente -670Apide una sesión de comunicación en línea con uno o varios usuarios de uno o varios dispositivos de cliente diferentes, transmitiendo una petición de invitación al servicio de invitación -620- que incluye un identificador de punto final de sesión de comunicación en línea para cada uno de los otros usuarios. El identificador de punto final de sesión de comunicación en línea puede ser diferente en diferentes realizaciones (por ejemplo, un número de teléfono, un nombre de usuario (por ejemplo, ID Apple), una dirección de correo electrónico, una dirección de correo, una dirección MAC u otro identificador). El servicio de invitación -620- lee el identificador o identificadores de punto final de sesión de comunicación en línea de la petición de invitación y lleva a cabo una consulta en el

almacenamiento -655- de datos de registro para localizar el dispositivo o dispositivos de cliente que est�n asociados con el identificador o identificadores de punto final de sesión de comunicación.

Los dispositivos de cliente -670A-N- utilizan el servicio de registro -630- para registrarse para sesiones de comunicación en línea. Por ejemplo, en una realización, cuando cada uno de los dispositivos de cliente -670A-N- es conectado y es activado en la red, provoca que su símbolo de identificación (por ejemplo, subs�mbolo automático) quede asociado con un identificador de punto final de sesión de comunicación en línea. Las asociaciones son almacenadas en el almacenamiento -655- de datos de registro. En una realización, los dispositivos de cliente -670A-N- se registran para participación para el servicio de sesión de comunicación en línea utilizando el servicio de registro -630-, tal como se ha descrito con respecto a la figura 4, mientras que en otras realizaciones, el proceso de registro tiene lugar de manera diferente (por ejemplo, proporcionando su símbolo automático y su identificador de punto final de sesión de comunicación en línea).

El servicio de notificación automática -640- utiliza los símbolos automáticos de los dispositivos de cliente -670A-Npara transmitir notificaciones automáticas a los dispositivos de cliente -670A-N-. En una realización, las notificaciones automáticas son utilizadas para transmitir las invitaciones para las sesiones de comunicación en línea. El servicio de retransmisión -650- establece conexiones de sesión de comunicación en línea entre dispositivos de cliente cuando los tipos de NAT de los dispositivos de cliente no son compatibles o ha fallado el establecimiento de conexión P2P entre los dispositivos de cliente.

En una realización, se establece la comunicación entre los dispositivos de cliente y el servicio CDX -610- utilizando un protocolo de red relativamente ligero, tal como conexiones ”socket” de Protocolo Datagram de Usuario (“UDP”). Tal como es conocido por los técnicos en la materia, las conexiones ”socket UDP no requieren diálogos de bienvenida para garantizar fiabilidad del paquete, pedidos, o integridad de datos y, por lo tanto, no consumen tantos recursos de proceso de paquetes como las conexiones ”socket” TCP. Como consecuencia, la naturaleza ligera, sin situación de estado de UDP es útil para servidores que contestan pequeñas consultas de un vasto número de clientes. Además, a diferencia de TCP, el UDP es compatible con envío de paquetes (en el que se envían paquetes a todos los dispositivos de una red local) y multienv�o (en el que los paquetes son enviados a un subconjunto de dispositivos de la red local). Tal como se ha descrito más adelante, aunque se pueden utilizar UDP, la seguridad puede ser mantenida en el servicio CDX -610- codificando datos transversales de NAT utilizando claves de sesión.

En contraste con el protocolo con baja necesidad de recursos, de red ligera, utilizado por el servicio CDX -610-, en una realización, la comunicación entre los dispositivos de cliente -670A-N- y el servicio de invitación -620-, servicio de registro -630-, servicio de notificación automática -640- y/o servicio de retransmisión -650- es establecido con un protocolo de red básicamente seguro, tal como Hypertext Transfer Protocol Secure (“HTTPS”), que se basa en una capa de conexiones socket seguras (“Secure Sockets Layer”) (“SSL”) o conexiones socket de seguridad de capa de transporte (“TLS”). Los detalles relacionados con estos protocolos son bien conocidos por los técnicos en la materia.

La figura 7 es un diagrama de flujo de datos que muestra el establecimiento de una sesión de comunicación en línea entre dispositivos de cliente, de acuerdo con una realización. En el ejemplo de la figura 7, un usuario en el dispositivo de cliente -A- -710- invita a un usuario en el dispositivo de cliente -B- -720- a una sesión de comunicación en línea (por ejemplo, una conferencia de vídeo P2P, un sistema de mensaje instantáneo P2P, etc.). En este ejemplo, el dispositivo de cliente -A- -710-se designa en algunos casos como dispositivo de cliente iniciador, el usuario del dispositivo de cliente -B- -720- es designado en algunos casos como destinatario previsto, y el dispositivo de cliente -B- -720- se designa en algunos casos como dispositivo de cliente destinatario previsto. En algunas realizaciones, la invitación a sesión de comunicación en línea es una invitación a ciegas, sin presencia. Por ejemplo, el usuario en el dispositivo de cliente -A- -710-no sabe si el usuario en el dispositivo de cliente -B- -720- se encuentra en aquel momento en línea o disponible para participar en la sesión de comunicación en línea.

Si bien la realizaciones descritas con referencia a las figuras 6 y 7 son específicas para utilizar símbolos automáticos y notificaciones automáticas, otras realizaciones no est�n limitadas de este modo. Por ejemplo, en otras realizaciones, cualquier registro o mapeado de dispositivos de cliente con respecto a símbolos de identificación únicos, puede ser utilizado para asociar símbolos de identificación asociados con dispositivos de cliente y para facilitar un método fiable de asociación de la identidad del dispositivo de cliente con un símbolo de identificación identificado de manera única.

En la operación -1-, el dispositivo de cliente -A- -710- solicita sus datos de conexión del intercambiador de datos de conexión -610-. Los datos de conexión incluyen información para dispositivos de cliente, para intercambio entre s� para establecer una sesión de comunicación en línea (por ejemplo, una sesión P2P). Los datos de conexión incluyen la dirección IP del dispositivo de cliente (por ejemplo, la dirección IP pública), el número de puerto de la petición y otras informaciones (por ejemplo, información de prioridad, etc.). El intercambio de datos de conexión -610determina los datos de conexión del dispositivo de cliente -A- -710- (por ejemplo, las direcciones y puertos IP públicos/privados, tipo de NAT del dispositivo de cliente, dispositivo NAT de tipo A). En la operación -2-, el intercambio de datos de conexión -610- devuelve los datos de conexión al dispositivo de cliente -A- -710-.

En la operación -3-, el dispositivo de cliente -A- -710- transmite una petición de invitación a sesión de comunicación en línea al servicio de invitación -620- para invitar el dispositivo de cliente -B- -720- a una sesión de comunicación en línea (por ejemplo, una conferencia de vídeo P2P, una sesión de mensajes instantáneos P2P, etc.). En una realización, la invitación incluye los datos de conexión del dispositivo de cliente -A- -710-que pueden incluir direcciones IP públicas/privadas y puertos para el dispositivo de cliente -A- -710-y el tipo de NAT para el dispositivo NAT de cliente de tipo -A-, y un identificador de punto final de sesión de comunicación en línea asociado con el usuario en el dispositivo de cliente -B- -720- (por ejemplo, un número de teléfono del dispositivo de cliente -B- -720-, nombre del usuario (por ejemplo, ID Apple), dirección de correo electrónico, dirección de correo, dirección MAC, etc.). La petición de invitación a sesión de comunicación en línea puede adoptar la forma de una petición HTTPS y puede incluir un certificado de cliente firmado por una autoridad de la certificación pre-especificada.

En la operación -4-, el servicio de invitación -620- determina los símbolos de identificación automática asociados con el identificador de punto final de sesión de comunicación en línea, incluidos en la petición de operación -3-. Por ejemplo, el servicio de invitación -620- accede al almacenamiento de datos de registro -655- para determinar los símbolos de identificación automáticos que est�n asociados con el identificador de punto final de sesión de comunicación en línea. Tal como se ha mostrado en la figura 7, el símbolo de identificación automático -725- es asignado al dispositivo de cliente -B- -720-, y por lo tanto, est� asociado con su identificador de punto final de sesión de comunicación en línea. La figura 10 muestra un almacenamiento de datos de registro -655- a título de ejemplo, de acuerdo con una realización. Tal como se ha mostrado en la figura 10, cada uno de los registros de identificador de sesión de comunicación incluye un campo de símbolo de identificación automática -1015- y un campo de identificador de sesión de comunicación en línea -1020-. Tal como se ha mostrado en la figura 10, el mismo identificador de sesión de comunicación en línea puede estar asociado con múltiples símbolos de identificación automática. En este caso, se transmitirán múltiples invitaciones (por ejemplo, una para cada símbolo de identificación automática).

El servicio de invitación -620- transmite un mensaje de petición automático al servicio de notificación automática -640-. En la operación -5-, el servicio de notificación automática -640- transmite una petición de invitación de sesión de comunicación en línea en forma de un mensaje de notificación automático al dispositivo de cliente -B- -720-. La petición incluye los datos de conexión, el identificador de punto final de sesión de comunicación en línea y la señal de identificación automática del dispositivo de cliente -A- -710- (símbolo automático -715-). La petición de invitación puede incluir también información específica a la sesión de comunicación en línea para proporcionar al usuario del dispositivo de cliente -B- -720- información acerca de la invitación (por ejemplo, el nombre de la persona que envía la invitación (por ejemplo, utilizando nombre de usuario, nombre real, número de teléfono o una cierta combinación de los mismos) para qué se hace la invitación (por ejemplo, una conferencia de vídeo P2P, una sesión de mensaje instantáneo P2P, etc.), etc.).

La petición de invitación de sesión de comunicación en línea ser� recibida y visualizada en el dispositivo de cliente -B- -720- si est� conectada y funciona correctamente. La petición de invitación incluye un mecanismo para que el usuario acepte o rechace la invitación (por ejemplo, un bot�n de aceptación y un bot�n de rechazo). El usuario en el dispositivo de cliente -A- -710- puede recibir una notificación si la petición de invitación es rechazada. Suponiendo que un usuario en el dispositivo de cliente -B- -720- acepta la petición de invitación, en la operación -6-, el dispositivo de cliente -B- -720- pide los datos de conexión del intercambio de datos de conexión -610-. El intercambio de datos de conexión -610- determina los datos de conexión del dispositivo de cliente -B- -720- (por ejemplo, las direcciones IP pública/privada y puertos, tipo NAT del dispositivo de cliente de los dispositivos NAT tipo -B-) y en la operación -7-, devuelve los datos de conexión al dispositivo de cliente -B- -720-.

El dispositivo de cliente -B- -720- transmite a continuación un mensaje de aceptación al servicio de invitación -620en la operación -8-. El mensaje de aceptación incluye los datos del dispositivo de cliente de tipo -B- e incluye el símbolo automático del dispositivo de cliente -A- -710-. El mensaje de aceptación puede contener también una indicación de si es un nuevo intento de un intento a partir de conexión anterior que ha fallado P2P directo entre el dispositivo de cliente -A- -710- y el dispositivo de cliente -B- -720-. El mensaje de aceptación puede adoptar la forma de un mensaje HTTPS.

En algunas realizaciones, el servicio de invitación -620- determina si es factible una conexión P2P entre el dispositivo de cliente -A- -710- y el dispositivo de cliente -B--720-. En la operación -9-, el servicio de invitación -620determina si es factible una conexión directa P2P entre los dispositivos de cliente -A- y -B-. Por ejemplo, en una realización, si el mensaje de aceptación recibido desde el dispositivo de cliente -B- -620- indica que es un nuevo intento procedente de un intento de conexión directa anterior que ha fallado (o un número especificado de intentos de conexión previos directos que han fallado), entonces, el servicio de invitación -620- puede llegar a la conclusión de que no es factible una conexión P2P directa. Para determinar la factibilidad, el servicio de invitación -620- puede comparar los datos de tipo NAT para los dispositivos de cliente -A- y -B- para determinar si los dispositivos NAT de los dispositivos de cliente -A- y -B- soportarán una conexión P2P directa. En una realización, el mensaje de aceptación descrito anteriormente no incluye indicación de intentos anteriores que hayan fallado. En vez de ello, después de un intento de conexión directa que ha fallado, cualquiera de los dispositivos de cliente -710- - -720puede transmitir una petición “invitación de retransmisión” especial (por ejemplo, en lugar de la petición de invitación en la operación -3- de la figura 7) indicando que se requiere una conexión de retransmisión. Como respuesta, el

servicio de invitación puede invocar automáticamente las operaciones de retransmisión descritas en esta descripción (descritas más adelante).

Algunas combinaciones de tipos NAT son conocidas como incompatibles para establecer conexiones P2P. Por ejemplo, se puede utilizar un NAT de cono completo con cualquier otro tipo de NAT, excepto un NAT cerrado/protegido con cortafuegos para establecer una conexión P2P directa. Como contraste, un NAT simétrico puede ser utilizado solamente con un NAT de cono completo para establecer una conexión directa P2P. La factibilidad de combinar varios tipos de NAT en una realización se desarrolla en la tabla de compatibilidad NAT -1110- mostrada en la figura 11, en la que las columnas representan tipos NAT de un dispositivo de cliente (por ejemplo, dispositivo de cliente -A- -710-) y las filas representan tipos de NAT de otro dispositivo de cliente (por ejemplo, dispositivo de cliente -B- -720-). Un “1.0” en una celda indica que los tipos de NAT de la fila y columna asociadas son compatibles y “0.0” indica que los tipos de NAT son incompatibles.

Si el servicio de invitación -620- determina que es factible una invitación directa P2P, entonces el servicio de invitación -620- transmite una petición automática al servicio de notificación automática -640- para transmitir la aceptación de la petición de invitación. De esta manera, en la operación -10B-, el servicio -640- de notificación automática transmite un mensaje de aceptación de sesión de comunicación en línea en forma de una notificación automática, al dispositivo de cliente -A- -710-. El mensaje de aceptación comprende los datos de conexión, el identificador de punto final de sesión de comunicación en línea y el símbolo identificador automático del dispositivo de cliente -B- -720-. El mensaje de aceptación ser� visualizado en el dispositivo de cliente -A- - 710-. Dado que los dispositivos de cliente -A- y -B- tienen cada uno de ellos los datos de conexión del otro, los dispositivos de cliente -Ay -B- tienen suficiente información para establecer una conexión P2P directa. Por lo tanto, en la operación -11A-, los dispositivos de cliente -A-y -B- establecen una conexión P2P directa utilizando los datos de conexión intercambiados. La conexión P2P directa puede ser establecida a través de mecanismos conocidos (por ejemplo, utilizando Internet Connectivity Establishment (ICE) (Establecimiento de Conectividad por Internet) u otros mecanismos de conectividad P2P conocidos).

No obstante, si el servicio de invitación -620- determina que no es factible una conexión directa P2P, entonces transmite una petición de consulta de retransmisión en la operación -10B- al servicio de retransmisión -650- a determinar uno o varios ordenadores de retransmisión para los dispositivos de cliente -A- y -B- para utilizar para la conexión. La petición de consulta de retransmisión puede contener la información de red para los dispositivos de cliente -A- y -B- (por ejemplo, datos NAT transversales/conexión de datos y/o datos de tipo NAT) que se utiliza por el servicio de retransmisión -650- para seleccionar ordenadores de retransmisión apropiados para ambos dispositivos de cliente.

Tal como se ha mostrado en la figura 8, en una realización, el servicio de retransmisión -650- comprende un módulo de consulta de retrasmisi�n -805-, ordenadores de retransmisión múltiples -815A-B- y una base de datos de ordenador de retransmisión -810- que contiene información de red relativa a cada uno de los ordenadores de retransmisión -815A-B-. Mientras que la figura 8 muestra dos ordenadores de retransmisión, se debe comprender que puede haber un número mayor o menor de ordenadores de retransmisión en algunas realizaciones. El servicio de invitación -620- transmite una petición de revisión de retransmisión al módulo de revisión de retransmisión -805que consulta la base de datos -810- de ordenadores de retransmisión utilizando la información de red para los dispositivos de cliente -A- y -B-. Después de recibir los resultados de la base de datos, el módulo de consulta de retransmisión -805- proporciona una respuesta que identifica los ordenadores de retransmisión seleccionados -815A-B- en la operación -11B- al servicio de invitación -620-.

En una realización, la respuesta de consulta de retransmisión contiene un símbolo de retransmisión generado por un servicio de retransmisión -650- y las direcciones de red (direcciones/puertos IP) de los ordenadores de retransmisión seleccionados -815A-B- a utilizar por los dispositivos de cliente -A- y -B- para la conexión de retransmisión. En una realización, el símbolo de retransmisión es asociado con la sesión de retransmisión y es utilizado por los ordenadores de retransmisión -815A-B- para autentificar los dispositivos de cliente -A- y -B- cuando tiene lugar la conexión al servicio de retransmisión -650-. El símbolo puede adoptar diferentes formas, incluyendo, por ejemplo, un código ID de sesión de retransmisión ID única, certificado digital y/o una clave de codificación única asociada con la sesión de retransmisión.

El servicio de invitación -620- transmite una respuesta de retransmisión a los dispositivos de cliente -A- y -Bindicando que se llevar� a cabo una conexión de retransmisión. En una realización, la respuesta de retransmisión al dispositivo de cliente -B- puede incluir el símbolo de retransmisión y la información de red para el ordenador de retransmisión -815B-. En una realización, la respuesta al dispositivo cliente -B- puede ser enviada directamente (prescindiendo del servicio de notificación automática -640-) porque est� siendo enviada como respuesta al mensaje de aceptación de invitación del dispositivo de cliente -B-. El servicio de invitación -620- trasmite también una respuesta de retransmisión al dispositivo de cliente -A- que puede incluir el símbolo de retransmisión y la información de red para el ordenador de retransmisión -815A-. En este caso, la respuesta es enviada al dispositivo de cliente -Aa través del servicio de notificación automática -640-.

En la operación -12B-, el dispositivo de cliente -A- -710- utiliza la información de red para el ordenador de retransmisión -815A- para establecer una conexión con el servicio de retransmisión -650-. De manera similar, en la operación -13B-, el dispositivo de cliente -B- -720- utiliza la información de red para el ordenador de retransmisión -815B- para establecer una conexión con el servicio de retransmisión -650-. En cada una de esas transacciones se abren nuevos orificios en las paredes de protección de cualquier NAT de los dispositivos de cliente -A- y -B- y los datos transversales/de conexión NAT de los dispositivos de cliente -A- y -B- para los dispositivos de cliente -A- y -Bpueden ser determinados por el servicio de retransmisión -650- y devueltos a los dispositivos de cliente -A- y -B-, respectivamente (por ejemplo, determinando el IP público/puerto para los dispositivos). En una realización, el servicio de retransmisión -650- y los dispositivos de cliente -A- y -B- implementan el protocolo Relevador de Utilización Transversal NAT (“TURN”), que tal como se comprender� por los técnicos en la materia, permite que un elemento que se encuentre detrás de un NAT o de un tabique de protección reciba datos entrantes con respecto a conexiones TCP � UDP.

En la operación -14B-, el dispositivo de cliente -A- -710- transmite una actualización de retransmisión al servicio de invitación -620- que es enviado al servicio de notificación automática y enviado al dispositivo de cliente -B- -720- en la operación -17B-. De manera similar, en la operación -15B- el dispositivo de cliente -B- -720- transmite una actualización de retransmisión al servicio de invitación -620- que es enviado al servicio de notificación automática -620- y enviado al dispositivo de cliente -A- -610- en la operación -16B-. La actualización de retransmisión transmitida por el dispositivo de cliente -A- -710-puede incluir el símbolo de la sesión, cada identificador de punto final de sesión de comunicación en línea del dispositivo y datos transversales/de conexión NAT determinados por el servicio de retransmisión -650-.

En las operaciones -18B- y -19B, los dispositivos de cliente -A- y -B-, respectivamente, establecen una conexión de sesión de comunicación en línea a través del servicio de retransmisión -650-. En una realización, las conexiones de retransmisión pueden ser establecidas cuando el dispositivo de cliente -A- -710- envía los datos transversales/de conexión NAT del dispositivo de cliente -B- -720- al servicio de retransmisión -650- y viceversa, permitiendo de esta manera que el servicio de retransmisión determina la ruta de transmisión correcta a cada ordenador de retransmisión de cada punto -815A-B-.

Utilizando las técnicas que se han descrito anteriormente, el servicio de invitación -620- puede ser implementado como un servicio sin situación, que es intrínsecamente escalable y resiliente, incluso en un sistema a gran escala con un elevado número de dispositivos de cliente. Por ejemplo, dado que el servicio de notificación automática -640es intrínsecamente capaz de localizar y enviar contenido a dispositivos de cliente registrados, el servicio de invitación -620- no es necesario que detecte la localización actual de cada dispositivo. De manera adicional, dado que los dispositivos pueden transmitir datos transversales/de conexión NAT con peticiones y respuestas, el servicio de invitación -620- no se requiere en ningún caso que mantenga ninguna información de estado de preconexi�n, reduciendo de esta manera las exigencias de almacenamiento y proceso del servicio de invitación. Esta implementación es particularmente útil en un sistema a gran escala.

Si bien la figura 7 describe un usuario en un dispositivo de cliente invitando a un usuario único a una sesión de comunicación en línea, las realizaciones no est�n limitadas de este modo. Por ejemplo, en algunas realizaciones, un usuario en un dispositivo de cliente puede invitar múltiples usuarios a una sesión de comunicación en línea. Por ejemplo, el usuario puede transmitir un único mensaje de invitación al servicio de invitación con múltiples identificadores de punto final de sesión de comunicación en línea para invitar múltiples usuarios en diferentes dispositivos de cliente para participar en una sesión de comunicación en línea.

En algunas situaciones, el usuario puede tener múltiples dispositivos de cliente que est�n identificados con el mismo identificador de punto final de sesión de comunicación en línea. La figura 26 es un diagrama de flujo de datos que muestra operaciones a título de ejemplo para gestionar invitaciones cuando el usuario tiene múltiples dispositivos de cliente que est�n asociados con el mismo identificador de punto final de sesión de comunicación en línea.

El dispositivo de cliente -A- (accionado por el usuario -A-) -2610- transmite una petición para sus datos de conexión desde el intercambio -610- de datos de conexión en la operación -2632-. El intercambio -610- de datos de conexión devuelve al dispositivo de cliente -A- datos de conexión en la operación -2634-. El dispositivo de cliente transmite entonces una petición de invitación de sesión de comunicación en línea al servicio de invitación -620- con un ID de usuario -B- para invitar al usuario -B- a una sesión de comunicación en línea (por ejemplo, una v�deoconferencia P2P, una sesión de mensaje instantáneo P2P, una llamada de vídeo…). La petición de invitación incluye los datos de conexión de -A-.

El servicio de invitación lleva a cabo una consulta de directorio en la operación -2638- basado en el ID de -B-, incluido en el mensaje de petición de invitación. En este ejemplo, la operación de consulta de directorio devuelve un símbolo automático para el dispositivo de cliente -B1- y un símbolo automático para el dispositivo de cliente -B2-. De este modo, los dispositivos de cliente -B1- y -B2- son asociados con el ID de -B-. El servicio de invitación -620transmite entonces un mensaje de petición automático en la operación -2640- al servicio de notificación automática -640- para enviar los mensajes de petición de invitación al dispositivo de cliente -B1- -2615- y al dispositivo de cliente -B2- -2620-. El servicio -640- de notificación automática transmite una petición de invitación de sesión de

comunicaci�n en línea en forma de un mensaje de notificación automática al dispositivo de cliente -B1- -2615- en la operación -2642- y al dispositivo de cliente -B2- -2620 en la operación -2644-. Cada uno de los mensajes de petición de invitación incluye los datos de conexión del dispositivo de cliente -A- -2610- el identificador de punto final de sesión de comunicación en línea utilizado por el usuario -A- y el símbolo automático del dispositivo de cliente -A-2610-. Las peticiones de invitación incluyen también información específica de la sesión de comunicación en línea (por ejemplo, el nombre de la persona que envía la invitación (por ejemplo, nombre de usuario, nombre real, número de teléfono o alguna combinación de los mismos), a qué est� destinada la invitación (por ejemplo, una conferencia de vídeo P2P, una sesión de mensaje instantánea P2P, etc.), etc.). De este modo, una petición de invitación de comunicación en línea es enviada a cada uno de los dispositivos asociados con el identificador de punto final de sesión de comunicación en línea incluido en la petición de invitación original.

En una realización, el servicio de invitación -620- transmite un mensaje de situación al dispositivo de cliente para indicar a qué dispositivo o dispositivos de cliente se transmitió la invitación. De este modo, en la operación -2646-, el servicio de invitación -620- transmite una actualización de situación de invitación al dispositivo de cliente -A- -2610que indica que se ha enviado una petición de invitación de sesión de comunicación en línea al dispositivo de cliente -B1- -2615- y al dispositivo de cliente -B2- -2620-. En una realización, el dispositivo de cliente -A- -2610- detecta cuáles son los dispositivos de cliente que aceptan la invitación y mantienen a los otros dispositivos de cliente advertidos del estado de la sesión de comunicación en línea.

En una realización, el dispositivo de cliente -B1- -2615- y el dispositivo de cliente -B2- -2620- mostrarán una petición de invitación si est�n activados y son capaces de recibir la petición de invitación. En el ejemplo mostrado en la figura 26, un usuario en el dispositivo de cliente -B1- -2615- aceptar� la invitación. De este modo, en la operación -2648- el dispositivo de cliente -B1- -2615- pide sus datos de conexión del intercambio de datos de conexión -610-. El intercambio -610- de datos de conexión determina los datos de conexión del dispositivo de cliente -B1- -2615- y en la operación -2650- los devuelve al dispositivo de cliente -B1- -2615-.

El dispositivo de cliente -B1- -2615- transmite a continuación un mensaje de aceptación al servicio de invitación -620- en la operación -2652-. El mensaje de aceptación incluye los datos de conexión del dispositivo de cliente -B1-2615- y el símbolo automático del dispositivo de cliente -A- -2610-. El mensaje de aceptación puede contener también una indicación de si es un nuevo intento de un intento anterior fracasado de conexión directa P2P entre el dispositivo de cliente -A- -2610- y el dispositivo de cliente -B1- -2615-. De modo adicional, el mensaje de aceptación puede incluir también los identificadores de punto final de sesión de comunicación en línea de -A- y -B- y el símbolo automático para el dispositivo de cliente -B- -2615-.

En algunas realizaciones, después de recibir un mensaje de aceptación a una sesión de comunicación en línea, el servicio de invitación -620- determina si es factible una conexión directa P2P. De este modo, en la operación -2654-, el servicio de invitación -620- lleva a cabo una comprobación de compatibilidad P2P directa para determinar si es factible una conexión P2P directa entre el dispositivo de cliente -A- -2610- y el dispositivo de cliente -B1- -2615-, de manera similar a lo que se ha descrito anteriormente. Si los dispositivos de cliente son compatibles para conexión P2P directa, entonces se llevan a cabo las operaciones descritas con referencia a la figura 27 (empezando en la operación -2710-). Si los dispositivos de cliente no son compatibles para conexión P2P directa, entonces se llevan a cabo las operaciones descritas con referencia a la figura 28 (empezando en la operación -2810-).

Con referencia a la figura 27 que muestra operaciones llevadas a cabo cuando es factible una operación P2P directa, en la operación -2710- el servicio de invitación -620- transmite una petición de envío al servicio de notificación automática -640- para transmitir la aceptación de la invitación por el dispositivo de cliente -B1- -2615-. En la operación -2712- el servicio de notificación automática -640- transmite un mensaje de aceptación de la sesión de comunicación en línea, en forma de una notificación automática, al dispositivo de cliente -A- -2610-. Este mensaje de aceptación incluye los datos de conexión y el símbolo automático del dispositivo de cliente -B1- -2615- y el identificador de punto final de sesión de comunicación en línea utilizado por el usuario -B-.

En una realización, algún tiempo después de recibir el mensaje de aceptación que indica que el dispositivo de cliente -B1- -2615- ha aceptado la invitación, el dispositivo de cliente -A- -2610- informa al dispositivo de cliente -B2- -2620que el dispositivo de cliente -A- -2620- ha aceptado la invitación. De este modo, en la operación -2714-, el dispositivo de cliente -A- -2610- transmite una petición actualizada de invitación al servicio de invitación que incluye el identificador de punto final de sesión de comunicación en línea del usuario -B- e indica que el dispositivo de cliente -B1- -2615- ha aceptado la invitación. La petición de actualización de invitación puede dar también instrucciones o indicar al servicio de invitación -620- qué dispositivo de cliente asociado con el identificador de punto final de sesión de comunicación en línea del usuario -B- debe recibir el mensaje actualizado de invitación (en este ejemplo, el dispositivo de cliente -B2- -2620- debería recibir el mensaje de actualización de invitación).

El servicio de invitación -620- lleva a cabo una consulta de directorio -2716- basada en el identificador de punto final de sesión de comunicación en línea del usuario -B- para determinar el símbolo automático del dispositivo de cliente -B2- -2620-. Después de determinar el símbolo automático, el servicio de invitación transmite una petición automática en la operación -2718- al servicio de notificación automática -640- para enviar el mensaje de actualización de invitación al dispositivo de cliente -B2- -2620-. En la operación -2720-, el servicio de notificación

autom�tica -640- transmite un mensaje de actualización de invitación en forma de un mensaje de notificación automático al dispositivo de cliente -B2 -2620-. El mensaje de actualización de invitación indica que el dispositivo de cliente -B1- -2615- ha aceptado la invitación a la sesión de comunicación en línea. El dispositivo de cliente -B2-2620- puede mostrar el mensaje de actualización de invitación y puede mantener el estado de la sesión de comunicación en línea entre el dispositivo de cliente -A- -2610- y el dispositivo de cliente -B1- -2615- (por ejemplo, la duración de la sesión de comunicación en línea, etc.). Tal como se describir� en mayor detalle, haciendo referencia a la figura 30, en una realización, el dispositivo de cliente -B2- -2620- puede transmitir una petición de transferencia para provocar que la sesión de comunicación en línea se transfiera del dispositivo de cliente -B1- -2615- al dispositivo de cliente -B2- -2620-.

Alg�n tiempo después de recibir el mensaje de aceptación de invitación en la operación -2712-, el dispositivo de cliente -A- -2610- y el dispositivo de cliente -B1- -2615-establecen una conexión P2P directa utilizando los datos de conexión intercambiados en la operación -2722-. La conexión P2P directa puede ser establecida a través de mecanismos conocidos (por ejemplo, utilizando Internet Connectivity Establishment (ICE) (Establecimiento de conectividad por Internet y otros mecanismos de conectividad P2P)). Se debe comprender que la operación -2722puede ser llevada a cabo antes o durante las operaciones -2714- - -2720-.

Si bien la figura 26 describe un ejemplo en el que solamente un dispositivo de cliente acepta el mensaje de invitación, en algunas situaciones, múltiples dispositivos de cliente pueden aceptar una invitación a una sesión de comunicación en línea dirigida a un usuario único. Por ejemplo, el dispositivo de cliente -B1- -2615- y el dispositivo de cliente -B2- -2620- pueden aceptar la invitación en algunas situaciones. En una realización, el dispositivo de cliente -A- -2610- establece una sesión de comunicación en línea con el primer dispositivo de cliente del que recibe un mensaje de aceptación. El dispositivo de cliente -A- -2610- puede provocar el envío de un mensaje de cancelación al otro dispositivo o dispositivos de cliente (por ejemplo, el mensaje de cancelación puede ser transmitido al servicio de invitación y luego enviado a través del servicio de notificación automática a aquéllos otros dispositivo o dispositivos de cliente).

Haciendo referencia nuevamente a la operación -2654- de la figura 26, si no es factible una conexión P2P directa entre el dispositivo de cliente -A- -2610- y el dispositivo de cliente -B1- -2615-, entonces, se llevan a cabo las operaciones descritas en la figura 28. La figura 28 es un diagrama de flujo de datos que muestra operaciones a título de ejemplo que se llevan a cabo cuando no es factible una conexión P2P directa. En la operación -2810-, el servicio de invitación -620- transmite una petición de consulta de retransmisión -2810- al servicio de retransmisión -650- para determinar un ordenador de retransmisión a utilizar por el dispositivo de cliente -A- -2610- y el dispositivo de cliente -B1- -2615-. La petición de consulta de retransmisión puede contener la información de red para los dispositivos de cliente (por ejemplo, datos transversales/de conexión NAT y/o datos de tipo NAT) que se utilizan por el servicio de retransmisión -650- para seleccionar ordenadores de retransmisión apropiados para los dispositivos de cliente. Tal como se ha mostrado en la figura 8, una realización del servicio de retransmisión -650- incluye una serie de ordenadores de retransmisión -815A-B- y una base de datos de ordenadores de retransmisión -810- que contiene información de red relativa a cada uno de los ordenadores de retransmisión. Por ejemplo, el servicio de invitación -620- transmite una petición de consulta de retransmisión a un servicio de retransmisión -650- que consulta la base de datos del ordenador de retransmisión -810- utilizando la información de red para los dispositivos de cliente. Después de recibir los resultados de la consulta de la base de datos, el servicio de retransmisión -650- proporciona una respuesta de consulta de retransmisión en la operación -1201- identificando los ordenadores de retransmisión seleccionados -815A-B-. En una realización, la respuesta a la consulta de símbolo de retransmisión contiene un servicio de retransmisión generado por el servicio de retransmisión -650-y las direcciones de red (direcciones/puertos IP) de los ordenadores de retransmisión -815A-B- a utilizar por los dispositivos de cliente para la conexión de retransmisión. En una realización del símbolo de retransmisión es asociado con la sesión de retransmisión y es utilizado por los ordenadores de retransmisión -815A-B- para autentificar al dispositivo de cliente -A- -2610- y el dispositivo de cliente -B1- -2615- después de conexión con el servicio de retransmisión -650-. El símbolo puede adoptar varias formas, incluyendo, por ejemplo, un código ID de sesión de retransmisión ID única, certificado digital y/o una clave codificada única asociada con la sesión de retransmisión.

El servicio de invitación -620- transmite entonces una respuesta de retransmisión al dispositivo de cliente -B1- -2615en la operación -2814- que contiene una indicación de que se realizar� una conexión de retransmisión. En una realización, la respuesta de retransmisión puede incluir el símbolo de retransmisión y la información de red para el ordenador de retransmisión seleccionado para el servicio de cliente -B1- -2615-. En una realización, la respuesta de retransmisión puede ser enviada directamente al dispositivo de cliente -B1- -2615- (prescindiendo del servicio de notificación automática -640-). El servicio de invitación -620- transmite también una respuesta de retransmisión al dispositivo de cliente -A- -2610- en la operación -2816- que incluye el símbolo de retransmisión y la información de red al ordenador de retransmisión seleccionado para el dispositivo de cliente -A- -2610-. En algunas realizaciones, la respuesta de retransmisión es enviada al dispositivo celular -A- mediante el servicio de notificación automática -640-.

En la operación -2818-, el dispositivo de cliente -A- -2610- transmite entonces una petición de actualización de invitación al servicio de invitación -620- que incluye el identificador de punto final de la sesión de comunicación en línea del usuario -B- e indica que el dispositivo de cliente -B1- -2615- ha aceptado la invitación. La petición de actualización de invitación puede instruir o indicar también al servicio de invitación -620- qué dispositivo de cliente

asociado con el identificador de punto final de sesión de comunicación en línea del usuario -B- debe recibir el mensaje actualizado de invitación (en este ejemplo, el dispositivo de cliente -B2- -2620- debe recibir el mensaje de actualización de invitación).

El servicio de invitación -620- lleva a cabo una consulta -2820- de directorio basada en el identificador de punto final de sesión de comunicación en línea del usuario -B- para determinar el símbolo automático del dispositivo de cliente -B2- -2620-. Después de determinar el símbolo automático, el servicio de invitación transmite una petición automática en la operación -2822- al servicio de notificación automática -640- para enviar el mensaje de actualización de invitación al dispositivo de cliente -B2- -2620-. En la operación -2824-, el servicio de notificación automática -640- transmite un mensaje de actualización de invitación en forma de un mensaje de notificación automática al dispositivo de cliente -B2- -2620-. El mensaje de actualización de invitación indica que el dispositivo de cliente -B1- -2615- ha aceptado la sesión de invitación a la sesión de comunicación en línea. El dispositivo de cliente -B2- -2620- puede mostrar el mensaje de actualización de invitación y puede mantener el estado de la sesión de comunicación en línea entre el dispositivo de cliente -A- -2610- y el dispositivo de cliente -B1- -2615- (por ejemplo, la duración de la sesión de comunicación en línea, etc.). En una realización, el dispositivo de cliente -B2- -2620- puede transmitir una petición de transferencia para provocar que la sesión de comunicación en línea se transfiera del dispositivo de cliente -B1- -2615- al dispositivo de cliente -B2- -2620-.

En la operación -2826-, el dispositivo de cliente -A- -2610- utiliza la información de red para que su ordenador de retransmisión seleccionado establezca una conexión con el servicio de retransmisión -650-. De modo similar, en la operación -2828-, el dispositivo de cliente -B1 2620- utiliza la información de red para su ordenador de red de transmisión seleccionado para establecer conexión con el servicio de retransmisión -650-. En cada una de estas operaciones, se pueden abrir nuevos orificios en cualesquiera cortafuegos NAT de los dispositivos de cliente y los datos transversales/de conexión NAT para los dispositivos de cliente pueden ser determinados por el servicio de retransmisión -650- y devueltos a aquéllos (por ejemplo, determinando el IP/puerto público de los dispositivos del cliente). En una realización, el servicio de retransmisión -650- y el dispositivo de cliente -A- -2610- y el dispositivo de cliente -B1- -2615- implementan el protocolo “Traversal Using Relay NAT (“TURN”)” que, tal como se comprender� por los técnicos en la materia, permite que un elemento situado por detrás de un NAT o cortafuegos reciba datos entrantes a través de conexiones TCP o UDP.

En la operación -2830-, el dispositivo de cliente -A- -2610- transmite una actualización de retransmisión al servicio de invitación -620-, que es enviado al servicio de notificación automática en la operación -2832- y transmitido al dispositivo de cliente -B1- -2615- en la operación 2834. De manera similar, en la operación, el dispositivo de cliente -B1- -2615- transmite una operación de retransmisión al servicio de invitación -620- que es enviado al servicio de notificación automática -640- en la operación -2838- y transmitido al dispositivo de cliente -A- -2610- en la operación -2840-. El mensaje de actualización de retransmisión transmitido por el dispositivo de cliente -A- -2610- puede incluir el símbolo de retransmisión, cada uno de los identificadores de sesión de comunicación en línea y los datos transversales/de conexión NAT determinados por el servicio de retransmisión -650- en las operaciones -2826- y -2828-. En una realización, las operaciones de actualización de retransmisión son llevadas a cabo dado que la información de uno o varios de los dispositivos NAT de cliente pueden haber cambiado. Finalmente, en las operaciones -2842- y -2844-, el dispositivo de cliente -A- -2610- y el dispositivo de cliente -B1- -2620- establecen respectivamente una conexión P2P a través del servicio de retransmisión -650-. En una realización, las conexiones de retransmisión pueden ser establecidas como respuesta a que el dispositivo de cliente -A- -2610- transmite los datos transversales/ de conexión NAT del dispositivo de cliente -B1- -2615- al servicio de retransmisión -650-, y viceversa, permitiendo de esta manera que el servicio de retransmisión -650- determine la ruta correcta al ordenador de cada punto de retransmisión.

La figura 29 es un diagrama de flujo de datos que muestra operaciones a título de ejemplo llevadas a cabo cuando una sesión de comunicación en línea termina, de acuerdo con una realización. En la operación -2910-, la sesión de comunicación en línea entre el dispositivo de cliente -A- -2610- y el dispositivo de cliente -B1- -2615- ha terminado. Por ejemplo, o bien el dispositivo de cliente -A- -2610- o el dispositivo de cliente -B1- -2615- ha terminado la sesión de comunicación en línea (o bien la sesión de comunicación en línea ha sido terminada de otro modo). La sesión de comunicación en línea puede haber tenido lugar a través de una conexión P2P directa o a través de una retransmisión.

Un cierto tiempo después de que ha terminado la sesión de comunicación en línea, en la operación -2812-, el dispositivo de cliente -A- -2610- transmite una petición de actualización de sesión de comunicación en línea al servicio de invitación -620-. La actualización de la sesión de comunicación en línea es enviada para notificar al dispositivo de cliente -B2- -2620- que no formaba parte de la sesión de comunicación en línea, de la terminación de la sesión de comunicación en línea. La petición de actualización de sesión de comunicación en línea puede incluir el identificador de sesión de comunicación en línea del usuario -B -y puede dar instrucciones o puede indicar al servicio de invitación -620- qué dispositivo de cliente asociado con el usuario -B- (por ejemplo, el dispositivo de cliente -B2-2620-) tiene que recibir la actualización.

El servicio de invitación -620- lleva a cabo una operación de consulta -2914- del directorio, basándose en el identificador de punto final de sesión de comunicación en línea del usuario -B- para determinar el símbolo

autom�tico del dispositivo de cliente -B2- -2620-. Después de determinar el símbolo automático, el servicio de invitación transmite una petición de transmisión en la operación -2916- al servicio de notificación automática -640para transmitir el mensaje de actualización al dispositivo de cliente -B2- -2620-. En la operación -2720-, el servicio de notificación automática -640- transmite un mensaje de actualización de la sesión de comunicación en línea en forma de un mensaje de notificación automática al dispositivo de cliente -B2- -2620-. El mensaje de actualización de sesión de comunicación en línea, indica que la sesión de comunicación en línea entre el dispositivo de cliente -A- -2910- y el dispositivo de cliente -B- -2615- ha terminado.

La figura 30 es un diagrama de flujo que muestra operaciones a título de ejemplo llevadas a cabo para transferir una sesión de comunicación en línea de un dispositivo de cliente a otro dispositivo de cliente, de acuerdo con una realización. En el ejemplo mostrado en la figura 30, se supone que cada uno de los dispositivos de cliente -B1-2615- y -B2- -2620-ha recibido una invitación para sesión de comunicación en línea originada por el dispositivo de cliente -A- -2610- (cada uno de ellos comparte el identificador de punto final de sesión de comunicación en línea que ha sido utilizado en la invitación) y el dispositivo de cliente -B1- -2615- ha aceptado y establecido una sesión de comunicación en línea con el dispositivo de cliente -A- -2610- (tal como se ha descrito en las figuras 26 y 27 � 28. Además, el dispositivo de cliente -B2--2620-ha recibido una actualización de invitación que indica que el dispositivo de cliente -B1- -2615- ha aceptado la invitación. En el ejemplo mostrado en la figura 30, la sesión de comunicación en línea ser� transferida del dispositivo de cliente -B1- -2615- al dispositivo de cliente -B2- -2620-. Por ejemplo, un usuario en el dispositivo de cliente -B2- -2620-ha indicado que desea recibir la sesión de comunicación en línea entre los dispositivos de cliente -A- -2610- y el dispositivo de cliente -B1- -2620-. En una realización, la aplicación -2115- de sesión de comunicación en línea muestra una situación de la sesión de comunicación en línea entre el dispositivo de cliente -A- -2610- y el dispositivo de cliente -B1- -2615- que permite a un usuario en el dispositivo de cliente -B2- -2620-enviar una petición de sesión de comunicación en línea de transferencia (por ejemplo, a través de accionamiento o presionado de un enlace o bot�n virtual disponible en la aplicación -2115- de sesión de comunicación en línea del dispositivo de cliente -B1- -2615-.

En la operación -3010- el dispositivo de cliente -B2- -2620-pide sus datos de conexión del intercambio de datos de conexión -610- y recibe los datos de conexión pedidos en la operación -3012- (si no conoce ya sus datos de conexión). El dispositivo de cliente -B2- -2620-transmite entonces un mensaje de petición de transferencia en la operación -3014- al servicio de invitación -620- que incluye un símbolo automático del dispositivo de cliente -A-2610- y los datos de conexión del dispositivo de cliente -B2- -2620-. El mensaje de petición de transferencia puede incluir también el identificador de punto final de sesión de comunicación en línea de -A- y/o B y/o el símbolo automático para el dispositivo de cliente -A- -2610-.

El servicio de invitación -620- transmite a continuación una petición automática al servicio de notificación automática -640- en la operación -3016- para provocar que el servicio de notificación automática -640- transmita el mensaje de transferencia en forma de una notificación automática al dispositivo de cliente -A- -2610-. El servicio de invitación -620- llev� a cabo también una comprobación de compatibilidad directa P2P en la operación -3018- para determinar si una conexión P2P directa entre el dispositivo de cliente -A- -2610- y el dispositivo de cliente -B2- -2620-es factible. A los objetivos de este ejemplo, es factible una conexión directa, no obstante, se debe comprender que una transferencia de sesión de comunicación en línea puede tener lugar también en una situación de retransmisión.

En la operación -3020-, el servicio de notificación automática transmite el mensaje de petición de transferencia al dispositivo de cliente -A--2610-. El mensaje de petición de transferencia puede incluir identificador de punto final de sesión de comunicación en línea de los B, y los datos de conexión por el dispositivo de cliente -B2- -2620-. El mensaje de petición de transferencia indica también qué dispositivo (es decir, el dispositivo de cliente -B2- -2620-) est� solicitando la transferencia de sesión de comunicación en línea (por ejemplo, a través del ID del dispositivo y/o símbolo automático del dispositivo de cliente -B2- -2620-). El mensaje de petición de transferencia puede provocar que la aplicación -2115- de sesión de comunicación en línea del dispositivo de cliente -A- -2610- muestre la petición de transferencia, y puede permitir al usuario aceptar o rechazar la petición de transferencia. Suponiendo que la petición de transferencia es aceptada, el dispositivo de cliente -A- -2610- establece una conexión P2P directa con el dispositivo de cliente -B2- -2620-utilizando los datos de conexión intercambiados en la operación -3022-. Se debe comprender que en este momento, la sesión de comunicación en línea entre el dispositivo de cliente -A- -2610- y el dispositivo de cliente -B1- -2615- se encuentra activa. El dispositivo de cliente -A- -2610- trasmite a continuación una actualización de la sesión de comunicación en línea al dispositivo de cliente -B1- -2615- que indica que la sesión de comunicación en línea se transferir� al dispositivo de cliente -B2- -2620-. En una realización, este mensaje de actualización es transmitido por la sesión de comunicación en línea existente entre los dispositivos de cliente. El dispositivo de cliente -A- -2610- conmuta a continuación a la sesión de comunicación en línea con el dispositivo de cliente -B2- -2620-en la operación -3026- y destruye la sesión de comunicación en línea con el dispositivo de cliente -B1- -2615- en la operación -3028-.

Si bien se han descrito realizaciones que hacen referencia a invitar un usuario único a una sesión de comunicación en línea (que puede estar asociada o no con múltiples dispositivos de cliente), en algunas realizaciones se puede invitar a múltiples usuarios a una sesión de comunicación en línea. La figura 31 es un diagrama de flujo que muestra operaciones a título de ejemplo para iniciar y establecer una sesión de comunicación en línea con múltiples usuarios.

El dispositivo de cliente -3110- solicita sus datos de conexión del intercambio -610- de datos de conexión en la operación -3132-, y los datos de conexión solicitados son devueltos en la operación -3134-. En la operación -3136-, el dispositivo de cliente -A- -3110- transmite una petición de invitación al servicio de invitación -620- que incluye los datos de conexión del dispositivo de cliente -A- -3110-, un identificador de punto final de sesión de comunicación en línea asociado con el usuario -B- y un identificador de punto final de sesión de comunicación en línea asociado con el usuario -C-. De este modo, un usuario en el dispositivo de cliente -A- -3110- est� invitando múltiples usuarios a una sesión de comunicación en línea.

El servicio de invitación -620- lleva a cabo una operación de consulta de directorio -3138- para determinar los símbolos automáticos asociados con el identificador de punto final de sesión de comunicación en línea de los -B-, y el identificador de punto final de sesión de comunicación en línea de los -C-. En este ejemplo, y a efectos de simplicidad, la consulta del directorio devuelve un resultado del dispositivo de cliente -B- -3115- asociado con el identificador de punto final de sesión de comunicación en línea de los B y el dispositivo de cliente -3120- asociado con el identificador de punto final de sesión de comunicación en línea de los -C-.

El servicio de invitación -620- transmite a continuación una invitación automática -3140- al servicio de notificación automática -640- para solicitar que el servicio de notificación automática -640- transmita las invitaciones en forma de mensajes automáticos a los dispositivos de cliente -B- y -C-. El servicio -640- de notificación automática transmite a continuación la petición de invitación al dispositivo de cliente -B- -3115- en la operación -3142- y transite la petición de invitación al servicio de cliente -C- -3120- en la operación -3144-. Cada mensaje de petición de invitación incluye los datos de conexión del dispositivo de cliente -A- -3110-, el identificador de punto final de sesión de comunicación en línea utilizado por el usuario -A- y el símbolo automático del dispositivo de cliente -A- -3110-.

En una realización, el servicio de invitación -620- transmite un mensaje de situación al dispositivo de cliente que efectúa la invitación para indicar a qué dispositivo o dispositivos de cliente se ha transmitido la invitación. De este modo, en la operación -3146-, el servicio de invitación -620- transmite una actualización de estado de invitación al dispositivo de cliente -A- -3110- que indica que se envi� al dispositivo de cliente -B- -3115- y al dispositivo de cliente -C- -3120- una petición de invitación a sesión de comunicación en línea. En una realización, el dispositivo de cliente -B- -3115- y el dispositivo de cliente -C- -3120- mostrarán una petición de invitación si son activados y capaces de recibir la petición de invitación.

En el ejemplo mostrado en la figura 31, se aceptarán cada una de las invitaciones. De este modo, en la operación -3148-, el dispositivo de cliente -B- -3115- pide sus datos de conexión del intercambio de datos de conexión -610-. El intercambio de datos de conexión -610- determina los datos de conexión del dispositivo de cliente -B- -3115-, y en la operación -3150- los devuelve al dispositivo de cliente -B- -3115-. De manera similar, el dispositivo de cliente -C-3120- solicita sus datos de conexión del intercambio de datos de conexión -610- en la operación -3152-. El intercambio -610- de datos de conexión determina los datos de conexión del dispositivo de cliente -C- -3120- y en la operación -3154- los devuelve al dispositivo de cliente -C--3120-. El dispositivo de cliente -B- -3115- transmite a continuación el mensaje de aceptación al servicio -620- de invitación en la operación -3156-, y el dispositivo de cliente -3120- transmite un mensaje de aceptación al servicio de invitación -620- en la operación -3158-. El servicio de invitación -620- lleva a cabo entonces una comprobación -3160- de compatibilidad P2P directa para determinar si es factible una conexión P2P directa entre el dispositivo de cliente -A- -3110- y el dispositivo de cliente -B- -3115-, y entre el dispositivo de cliente -A- -3110- y el dispositivo de cliente -C- -3120-. A los efectos de este ejemplo, una conexión P2P directa es factible entre los dispositivos de cliente. Por lo tanto, utilizando los datos de conexión que se han intercambiado, el dispositivo de cliente -A- -3110- y el dispositivo de cliente -B- -3115- establecen una conexión P2P directa para la sesión de comunicación en línea en la operación -3162- y el dispositivo de cliente -A-3110- y el dispositivo de cliente -B- -3120- establecen una conexión P2P directa para la sesión de comunicación en línea en la operación -3164-. En este ejemplo, el dispositivo de cliente -A- -3110- actúa esencialmente como principal de la sesión de comunicación en línea. De este modo, los datos que est�n siendo transmitidos entre el dispositivo de cliente -B- -3115- y el dispositivo de cliente -C- -3120- son retransmitidos por el dispositivo de cliente -A- -3110-. En otras realizaciones, se establece un entramado completo de conexiones entre las partes. En esta realización, se establecería otra conexión P2P entre el dispositivo de cliente -B- -3115- y el dispositivo de cliente -C-3120-.

Si bien las realizaciones que se describen se refieren a un mecanismo para registrar dispositivos de cliente para sesiones de comunicación en línea, en algunas realizaciones, el registro -140- puede implementar un API para permitir que diferentes aplicaciones registren identificadores de punto final de sesión de comunicación en línea y símbolos de automatismo. El API implementado en una realización es un interfaz implementado por un componente de software (se describe a continuación como “Componente de software que implementa API”) que permite que un componente de software diferente (designado a continuación “Componente de software de llamada de API”) acceda y utilice una o varias funciones, métodos, procesos, estructuras de datos y/o otros servicios proporcionados por el componente de software de implementación de API. Por ejemplo, un API permite un desarrollador de un componente de software de llamada de API (que puede ser un desarrollador tercero) que potencie características especificadas proporcionadas por un componente de software de implementación de API. Puede existir un componente de software de llamada de API o pueden existir más de uno de dichos componentes de software. Un API puede ser un interfaz de código fuente que proporciona una biblioteca de programas o sistema inform�tico a

efectos de soportar peticiones de servicio de una aplicación de software. Se puede especificar un API en términos de un lenguaje de programación que puede ser interpretativo o compilado cuando se constituye una aplicación, en vez de una descripción explícita de bajo nivel de cómo se disponen los datos en la memoria.

La API define el lenguaje y los parámetros que los componentes de software de llamada de API utilizan cuando acceden y utilizan características especificadas del componente de software que implementa la API. Por ejemplo, un componente de software de llamada de API accede a las características especificadas del componente de software de implementación de API a través de una o varias llamadas de API (en algunos casos se indican como llamadas de función o de método) dispuestas por la API. El componente de software que implementa la API puede devolver un valor a través de la API en respuesta a una llamada de API desde un componente de software de llamada de API. Si bien la API define la sintaxis y resultado de una llamada API (por ejemplo, cómo invocar la llamada API y qué hace la llamada API), la API, de manera típica, no revela la forma en la que la llamada API consigue la función especificada por la llamada API. Varias llamadas o mensajes de función son transferidas a través de una o varias interfaces de programación de aplicación entre el software de llamada (componente de software de llamada de API) y un componente de software de implementación de API. La transferencia de las llamadas o mensajes de función puede incluir la emisión, inicio, invocaci�n, llamada, recepción, devolución o respuesta a los mensajes o llamadas de función. Por lo tanto, un componente de software de llamada de API puede transferir una llamada y un componente de software de implementación de API puede transferir una llamada.

A título de ejemplo, el componente de software de implementación de API y el componente de software de llamada de API pueden ser un sistema operativo, una biblioteca, un disco duro de dispositivo, una API, un programa de aplicación, o un módulo de software distinto (se debe comprender que el componente de software de implementación de API y el componente de software de API pueden ser del mismo o diferente tipo de módulo de software uno con respecto a otro). El componente de software de llamada de API puede ser un componente de software local (es decir, en el mismo sistema de proceso de datos que el componente de software que implementa el API) o un componente de software remoto (es decir, en un sistema de proceso de datos diferente al componente de software de implementación de API) que comunica con el componente de software de implementación de API a través del API mediante una red. Se debe comprender que un componente de software de implementación de API puede actuar también como componente de software de llamada de API (es decir, puede hacer llamadas API a un API expuesto por un componente de software de implementación de API diferente) y un componente de software de llamada de API puede actuar también como software de implementación de API al implementar un API expuesto a un componente de software de llamada de API diferente.

La API puede permitir que diferentes componentes de software de llamada de API escritos en diferentes lenguajes de programación comuniquen con el componente de software de implementación de API (de este modo, la API puede incluir características para traducir llamadas y retornos entre el componente de software de implementación de API y el componente de software de llamada de API); no obstante, la API puede ser implementada en términos de lenguaje de programación específico.

La figura 9 muestra una realización de una arquitectura de API que incluye un componente de software de implementación de API -910- (por ejemplo, un sistema operativo, una biblioteca, un disco del dispositivo, una API, un programa de aplicación u otro módulo de software) que implementa la API -920-. La API -920- especifica una o varias funciones, métodos, clases, objetos, protocolos, estructuras de datos, formatos y/u otras características del componente de software que implementa la API que se pueden utilizar por el componente de software -930- de llamada de API. La API -920- puede especificar, como mínimo, una convención de llamada que especifica la forma en la que una función en la componente de software que implementa la API recibe parámetros de la componente de software de llamada de API y la forma en la que la función devuelve un resultado a la componente de software de llamada de API. La componente -930- de software de llamada de API (por ejemplo, el sistema operativo, una biblioteca, un disco de dispositivo, un API, un programa de aplicación u otro módulo de software) hace llamadas de API a través del API -920-para acceder y utilizar las características de la componente de software de implementación de API -910- especificadas por la API -920-. La componente -910- de software que implementa la API puede devolver un valor a través de la API -920- a la componente -930- de software de llamada de API como respuesta a una llamada de API.

Se observar� que el componente de software -910- que implementa la API puede incluir funciones, procedimientos, clases, estructuras de datos y/u otras características adicionales que no est�n especificadas por la API -920- y que no son disponibles al componente de software -930- de llamada de API. Se debe comprender que el componente de software -930- de llamada de API puede encontrarse el mismo sistema que en el componente -910- de software que implementa API o puede estar situado de forma remota y accede al componente -910-de software de implementación de API utilizando la API -920- a través de una red. Si bien la figura 9 muestra un único componente de software de llamada de API -930- que interacciona con el API -920- se debe comprender que otros componentes de software de llamada de API que pueden estar escritos en diferentes lenguajes (o el mismo lenguaje) que el componente -930- de software de llamada de API pueden utilizar el API -920-.

El componente -910- de software de implementación de API, la API -920- y el componente de software -930- de llamada de API pueden estar almacenados en un medio legible mecánicamente que incluye cualquier mecanismo

para almacenar información en una forma legible por un aparato (por ejemplo, un ordenador u otro sistema de proceso de datos). Por ejemplo, un medio legible por un aparato incluye discos magnéticos, discos ópticos, memorias de acceso al azar, memorias únicamente de lectura solamente, dispositivos de memoria flash, etc.

Transici�n entre llamadas conmutadas por circuito y llamadas de vídeo

En algunas realizaciones, un dispositivo de cliente puede transicionar desde una llamada conmutada de circuito solamente de audio a una llamada de vídeo sin interrumpir significativamente la comunicación entre los participantes. Por ejemplo, un participante de una llamada conmutada de circuito solamente de audio ya establecida, selecciona la transición a una llamada de vídeo (que incluye tramas de vídeo y de audio) que provoca un mensaje de inicio de llamada de vídeo (una forma de mensaje de invitación de sesión de comunicación en línea) a enviar al otro u otros participantes de la llamada. Si el otro u otros participantes aceptan la invitación a la llamada de vídeo, se establecer� una conexión P2P entre los dispositivos de cliente de los participantes. Mientras la conexión P2P est� siendo negociada, los participantes son capaces de comunicar a través de la llamada conmutada de circuito de audio solamente. Después de que se ha establecido la conexión P2P y que se comunica vídeo entre los participantes, los dispositivos de cliente pasan a la llamada de vídeo. Entonces, se renuncia a la llamada conmutada de circuito solamente de audio y los participantes son capaces de comunicar a través de la llamada de vídeo.

La figura 12 muestra un dispositivo de cliente -A- título de ejemplo, -1210- y un interfaz gráfico de usuario que se utiliza como transición entre llamadas conmutadas de circuito y llamadas de vídeo, de acuerdo con algunas realizaciones. El dispositivo de cliente -1210- incluye un altavoz -1255- (que es utilizado durante la modalidad de teléfono con manos libres), cámara dirigida frontalmente -1260- (que capta vídeo que se utiliza para la llamada de vídeo), micrófono -1265- (que capta sonido), el receptor/altavoz -1270- (que se utiliza de manera típica cuando un usuario sostiene el dispositivo de cliente -1210- en el oído durante una llamada) y la pantalla de visualización -1275(que es una pantalla táctil en algunas realizaciones). El dispositivo de cliente -1210- puede incluir también un conector de teléfono de cabeza/auriculares (“headphone”/”headset”), un sensor de proximidad, un sensor de luz ambiente, un aceler�metro o aceler�metros y otros componentes. Se debe comprender que la arquitectura del dispositivo de cliente -1210- tiene carácter de ejemplo y se puede utilizar en realizaciones diferentes arquitecturas que incluyen un número mayor o menor de componentes.

Tal como se ha mostrado en la figura 12, el interfaz gráfico de usuario -1205- est� siendo visualizado en el momento sobre la pantalla de visualización -1275-. El usuario del dispositivo de cliente -1210- participa en aquel momento en una llamada de teléfono por audio solamente (con el número de teléfono (408) 555-1234)). El interfaz gráfico de usuario -1205- incluye diferentes opciones para el usuario durante la llamada. Por ejemplo, el dispositivo de cliente -1210- lleva a cabo la siguiente reacción ante la recepción de una entrada de usuario (por ejemplo, golpeo u otros gestos predefinidos del icono apropiado): termina la llamada cuando se aplica una entrada al icono de final de llamada -1250-, enmudece la llamada de audio como respuesta a la entrada aplicada al icono de silencio -1220-, exhibe un teclado numérico (por ejemplo, para añadir número de teléfono adicional a la llamada), que responde a la entrada aplicada al icono de teclado -1225-, pone la llamada en el altavoz del teléfono como respuesta a la entrada aplicada al icono -1230- de altavoz (que cambia la salida de audio al altavoz -1255-), añade una llamada como respuesta a la entrada aplicada al icono de añadidura de llamada -1235-, coloca la llamada en espera como respuesta a la entrada aplicada al icono de espera -1240-, visualiza la lista de contacto del usuario como respuesta a la entrada aplicada al icono de contactos -1245- y transiciona a una llamada de vídeo como respuesta a la entrada aplicada al icono de llamada de vídeo -1215-.

Las figuras 17 y 18 son diagramas de flujo que muestran operaciones a título de ejemplo para la transición de una llamada conmutada de circuitos solamente de audio a una llamada de vídeo de acuerdo con una realización. Las figuras 17 y 18 ser�n descritas con referencia a las realizaciones a título de ejemplo de las figuras 12, 13 y 14. No obstante, se debe comprender que las operaciones en las figuras 17 y 18 pueden ser llevadas a cabo por realizaciones de la invención diferentes de las explicadas con referencia a las figuras 12, 13 y 14, y las realizaciones explicadas con referencia a las figuras 12, 13 y 14 pueden llevar a cabo operaciones distintas de las explicadas con referencia a las figuras 17 y 18.

Tal como se ha mostrado en la figura 17, los dispositivos de cliente -1210- y -1410- est�n conectados a través de una llamada conmutada de circuito solamente de audio -1710- (la llamada ha sido iniciada por el usuario del dispositivo de cliente -1210- o por el usuario del dispositivo de cliente -1410-). De este modo, los usuarios de los dispositivos de cliente -1210- y -1410- pueden comunicar sobre la llamada de audio establecida conmutada de circuito. En el bloque -1712-el dispositivo de cliente -1210- recibe una entrada para transición a una llamada de vídeo. Por ejemplo, el usuario ha escogido la transición a una llamada de vídeo al teclear o llevar a cabo otro gesto definido sobre el icono de llamada de vídeo -1215-.

El flujo se desplaza entonces al bloque -1714-, en el que el dispositivo de cliente -1210- provoca un mensaje de invitación de llamada de vídeo (que es una forma de mensaje de petición de invitación de sesión de comunicación en línea) a enviar al dispositivo de cliente -1410- (tal como se ha identificado por el número de teléfono del dispositivo de cliente -1410-). En algunas realizaciones el mensaje de petición de invitación de sesión de

comunicaci�n es enviado utilizando la arquitectura descrita en las figuras 6 y 7. El flujo se desplaza entonces al bloque -1716-.

En el bloque -1716-, el dispositivo de cliente -1210- determina si el audio est� enrutado en el momento presente a través del altavoz del teléfono (por ejemplo, el altavoz -1255-) o a través del conector del teléfono de casco/auriculares (“headphone”/”headset”). Si lo est�, entonces el flujo se desplaza al bloque -1720-. Si no lo est�, el flujo se desplaza al bloque -1718- en el que el dispositivo de cliente -1210- enruta el audio a través del altavoz del teléfono del dispositivo de cliente -1210- (por ejemplo, el altavoz -1255-) y el flujo se desplaza al bloque -1720-.

En el bloque -1720-, el dispositivo de cliente -1210- visualiza un pre-visionado de vídeo de lo que est� captando en aquel momento la cámara frontal -1260- para permitir al usuario del dispositivo de cliente -1210- prepararse para la llamada de vídeo (por ejemplo, posicionar de manera apropiada el dispositivo de cliente -1210- para la llamada de vídeo). La figura 13 muestra el dispositivo de cliente -1210- que visualiza el pre-visionado de vídeo -1310- que muestra el vídeo de lo que est� captando en aquel momento la cámara dirigida frontalmente -1260-. Si bien no se ha mostrado en la figura 13, en algunas realizaciones se muestra también un bot�n de cancelación en el GUI -1305que permite al usuario cancelar la invitación de llamada de vídeo. El flujo se desplaza del bloque -1720- al bloque -1722-.

En el bloque -1726-, el dispositivo de cliente -1410- recibe un mensaje de invitación de llamada de vídeo invitando al usuario de dispositivo de cliente -1410- a una llamada de vídeo. El flujo se desplaza del bloque -1726- al bloque -1728-. En algunas realizaciones, el dispositivo de cliente -1410- tiene una arquitectura similar al dispositivo de cliente -1210-. Por ejemplo, tal como se ha mostrado en la figura 14, el dispositivo de cliente -1410- incluye el altavoz -1455- (que es utilizado durante la modalidad de teléfono con manos libres), cámara dirigida frontalmente -1460- (que capta el vídeo utilizado para la llamada de vídeo, el micrófono -1465- (que capta el sonido), el receptor/altavoz -1470-, que se utiliza de manera típica cuando un usuario sostiene el dispositivo de cliente -1210aplicado al oído durante una llamada) y la pantalla de visualización -1475- (que es una pantalla táctil en algunas realizaciones). El dispositivo de cliente -1410- puede incluir también un conector de teléfono de casco/auriculares, un sensor de proximidad, un sensor de luz de ambiente, un aceler�metro o aceler�metros y otros componentes. Se debe comprender que la arquitectura del dispositivo de cliente -1410- tiene carácter de ejemplo y que se pueden utilizar diferentes estructuras que incluyen un número mayor o menor de componentes en ciertas realizaciones.

En el bloque -1728-, el dispositivo de cliente -1410- interpreta uno o varios tonos de audio indicando la recepción del mensaje para avisar al usuario de dicho mensaje. Los tonos de audio pueden ser diferentes en diferentes realizaciones (por ejemplo, los tonos de audio pueden ser similares a los tonos de espera de llamada utilizados en el dispositivo de cliente -1410- (si bien no han sido originados por el portador asociado con el dispositivo de cliente -1410-), los tonos de audio pueden ser únicos y específicos para llamadas de vídeo, etc.). En algunas realizaciones, el dispositivo de cliente -1410- no interpreta tonos de audio s�mboloes de la recepción del mensaje de invitación de llamada de vídeo si el dispositivo de cliente -1410- no se encuentra cerca del oído del usuario (por ejemplo, tal como se ha indicado mediante el sensor de proximidad del dispositivo de cliente -1410-) y/o si la llamada se encuentra en el momento en modalidad de teléfono con manos libres (“speakerphone”). El flujo se desplaza del bloque -1728- al bloque -1730-.

En el bloque -1730-, el dispositivo de cliente -1410- muestra el mensaje de invitación de llamada de vídeo y opcionalmente muestra un pre-visionado de vídeo de lo que est� captando en aquél momento la cámara dirigida frontalmente -1460- para permitir al usuario del dispositivo de cliente -1410- preparar la llamada de vídeo y el flujo se desplaza al bloque -1732-. La figura 14 muestra el GUI -1405- que muestra la invitación de llamada de vídeo -1440-. Tal como se ha mostrado en la figura 14, la invitación de llamada de vídeo -1440- incluye un bot�n de aceptación -1432-, un bot�n de rechazo -1434- y el pre-visionado de vídeo -1430- (que muestra lo que est� captando en aquél momento la cámara dirigida frontalmente -1460-). Si bien la figura 14 muestra la invitación de llamada de vídeo -1440- incluyendo el pre-visionado de vídeo -1430- (es decir, el pre-visionado de vídeo -1430- est� contenido dentro de la invitación de llamada de vídeo -1440-), en otras realizaciones, el pre-visionado de vídeo -1430- est� situado fuera y/o est� solapado con la invitación -1440- de llamada de vídeo. El usuario del dispositivo de cliente -1410puede seleccionar el bot�n de aceptación -1432- para aceptar la invitación de llamada de vídeo (por ejemplo, tecleando o llevando a cabo otro gesto predefinido para introducción en el bot�n de aceptación -1432-) y puede seleccionar el bot�n de rechazo -1434- para rechazar la invitación de llamada de vídeo (por ejemplo, tecleando o llevando a cabo otro gesto predefinido para entrada en el bot�n de rechazo -1434-).

En el bloque -1732-, el dispositivo de cliente -1410- determina si se ha recibido una entrada para aceptar la llamada de vídeo (por ejemplo, si el usuario ha aceptado la invitación de llamada de vídeo seleccionando el bot�n de aceptación -1432-). Si el dispositivo de cliente -1410- recibe una entrada para aceptar la llamada de vídeo, entonces el flujo se desplaza al bloque -1734-, de otro modo, el flujo se desplaza al bloque -1736-. En el bloque -1734-, el dispositivo de cliente -1410- provoca la transmisión de un mensaje de aceptación de llamada de vídeo al dispositivo de cliente -1210-. En algunas realizaciones, el mensaje de aceptación es transmitido al dispositivo de cliente -1210utilizando la arquitectura descrita en las figuras 6 y 7. Entonces, el flujo se desplaza al bloque -1810-.

En el bloque -1736- se determina si se ha recibido datos de entrada para rechazar la petición de llamada de vídeo (por ejemplo, si el usuario ha rechazado la invitación de llamada de vídeo al seleccionar el bot�n de rechazo -1434-). Si el dispositivo de cliente -1410- recibe datos de entrada para rechazar la invitación de llamada de vídeo, entonces, el flujo se desplaza al bloque -1738-, de otro modo, el flujo retrocede al bloque -1732-. En el bloque -1738-, el dispositivo de cliente -1410- provoca la transmisión del mensaje de rechazo de la llamada de vídeo al dispositivo de cliente -1210-. El dispositivo de cliente -1410- debe también eliminar la invitación -1440- de llamada de vídeo y dejar de visualizar el pre-visionado de vídeo -1430-. En algunas realizaciones, el mensaje de rechazo de llamada de vídeo se transmite al dispositivo de cliente -1210- utilizando la arquitectura descrita en las figuras 6 y 7.

En el bloque -1722-, el dispositivo de cliente -1210- determina si ha recibido mensaje de aceptación de llamada de vídeo del dispositivo de cliente -1410-. En caso positivo, entonces el flujo se desplaza al bloque -1816-, de otro modo, se desplaza el flujo al bloque -1724- en el que el dispositivo de cliente -1210- determina si ha recibido un mensaje de rechazo de llamada de vídeo del dispositivo de cliente -1410-. En caso positivo, entonces el flujo se desplaza al bloque -1910-, de otro modo, el flujo retrocede al bloque -1722-.

Haciendo referencia a la figura 18, en el bloque -1810- (el usuario en el dispositivo de cliente -1410- ha aceptado la invitación de llamada de vídeo), el dispositivo de cliente -1410- determina si se est� enrutando audio en aquél momento a través del teléfono con manos libres (“speakerphone”) (por ejemplo, el altavoz -1470-) o los auriculares del dispositivo de cliente -1410-. En caso negativo, el flujo se desplaza al bloque -1812- en el que la ruta de audio es cambiada del altavoz -1455- al teléfono con manos libres (por ejemplo, el altavoz -1470-) y el flujo se desplaza al bloque -1814-. Si el audio est� siendo ya enrutado a través del teléfono con manos libres o auriculares, entonces el flujo se desplaza al bloque -1814-.

En el bloque -1814-, el dispositivo de cliente -1410- muestra un pre-visionado de vídeo de lo que est� captando en aquel momento la cámara dirigida frontalmente -1460-. La operación en el bloque -1814- se lleva a cabo solamente si el pre-visionado de vídeo no est� siendo mostrado en aquel momento como resultado de la operación en el bloque -1730-. El flujo se desplaza del bloque -1814- al bloque -1820-.

En los bloques -1818- y -1820-, los dispositivos de cliente -1210- y -1410- establecen una conexión P2P entre s�. La conexión P2P puede ser establecida a través de mecanismos conocidos (por ejemplo, utilizando el Establecimiento de Conectividad por Internet (ICE) u otros mecanismos de conectividad P2P conocidos). Suponiendo que la conexión P2P se establezca satisfactoriamente, el flujo se desplaza de los bloques -1818- y -1820- a los bloques -1822- y -1824-, respectivamente, en los que los dispositivos de cliente -1210- y -1410- empiezan a transmitir vídeo entre s� a través de la conexión P2P (el vídeo de las cámaras de vídeo dirigidas frontalmente -1260- y -1460-). En algunas realizaciones, el vídeo comprende tanto tramas de vídeo como correspondiente audio (captadas por los micrófonos -1265- y -1465- de los dispositivos de cliente -1210- y -1410-, respectivamente), mientras que en otras realizaciones el vídeo y audio son flujos separados comunicados a través de la conexión P2P.

El flujo se desplaza de los bloques -1822- y -1824- a los bloques -1826- y -1828-, respectivamente. En los bloques -1826- y -1828- los dispositivos -1210- y -1410- determinan respectivamente si han recibido una o varias tramas de vídeo de su homólogo. En caso positivo, entonces el flujo se desplaza desde los bloques -1826- y -1828- a los bloques -1830- y -1832-, respectivamente. En caso negativo, entonces el flujo permanece en los bloques -1826- y -1828- hasta que se han recibido una o varias tramas de vídeo.

En algunas realizaciones, los dispositivos de cliente -1210-y -1410- esperan recibir las tramas de vídeo, uno de otro, durante un cierto periodo de tiempo, y sino intercambian tramas de vídeo a lo largo de dicho periodo, se toma una acción alternativa. Por ejemplo, en algunas realizaciones, la llamada de vídeo es cancelada y se muestra un mensaje en las pantallas de los dispositivos de cliente -1210- y -1410- que la llamada de vídeo no ha podido ser establecida. La llamada de vídeo puede fallar en su establecimiento por una serie de razones, incluyendo el hecho de que la anchura de banda es insuficiente para la llamada de vídeo, las tramas de vídeo han fallado en su transmisión o recepción, etc. S bien en algunas realizaciones los dispositivos de cliente esperan una trama única de vídeo antes de continuar, en otras realizaciones los dispositivos de cliente esperan recibir una serie de tramas a lo largo de un periodo de tiempo determinado (por ejemplo, un flujo de tramas de vídeo) antes de continuar.

En los bloques -1830- y -1832-, los dispositivos de cliente -1210- y -1410- transicionan respectivamente a la llamada de vídeo. La transición a la llamada de vídeo comprende la visualización del vídeo recibido en aquel momento y cambiar la ruta de audio de la llamada de audio conmutada de circuito a la llamada de vídeo. En algunas realizaciones, el pre-visionado de vídeo (por ejemplo, el pre-visionado de vídeo -1310-) se desplaza a una esquina de la pantalla (y se retrae en sus dimensiones) y se muestra el vídeo recibido desde el homólogo. De este modo, se debe comprender que hasta que la ruta de audio ha sido cambiada de la llamada de audio conmutada de circuito a la llamada de vídeo, los participantes pueden comunicar a través de la llamada de audio conmutada de circuito (es decir, la llamada de audio conmutada de circuito permanece establecida mientras que la llamada de vídeo est� siendo negociada). Después de transicionar a la llamada de vídeo, la llamada de audio conmutada de circuito puede ser eliminada. De este modo, el flujo se desplaza de los bloques -1830- y -1832- a los bloques -1834- y -1836-, respectivamente, en los que se elimina la llamada de audio conmutada de circuito.

Las figuras 15 y 16 muestran los dispositivos de cliente -1210- y -1410-, respectivamente, después de que han transicionado a la llamada de vídeo. Tal como se ha mostrado en la figura 15, el dispositivo de cliente -1210muestra el vídeo -1510-, que es un vídeo de lo que se ha captado por la cámara dirigida frontalmente -1460- del dispositivo de cliente -1410-. El dispositivo de cliente -1210- muestra también el vídeo -1515-, que es el vídeo de lo que se est� captando por la cámara dirigida frontalmente -1260-. El GUI -1505- incluye también el bot�n de final de vídeo -1520- y el final de vídeo y el bot�n de llamada -1625-. El bot�n -1520- de final de vídeo permite al usuario terminar la llamada de vídeo y volver a una llamada de audio solamente. El bot�n de final de vídeo y de llamada -1525- permite al usuario terminar por completo la llamada de vídeo (por ejemplo, terminar la conversación con el usuario en el dispositivo de cliente -1410-). Tal como se ha mostrado en la figura 16, el dispositivo de cliente -1410muestra el vídeo -1610-, que es un vídeo de lo que est� siendo captado por la cámara dirigida frontalmente -1260del dispositivo de cliente -1210-. El dispositivo de cliente -1410- muestra también el vídeo -1615-, que es un vídeo de lo que est� siendo captado por la cámara dirigida frontalmente -1460-. El GUI -1605- incluye también el bot�n de final de vídeo -1620- y el bot�n de final de vídeo y de llamada -1625-.

La figura 19 es un diagrama de flujo que muestra operaciones a título de ejemplo realizadas en un dispositivo de cliente que ha recibido un mensaje de rechazo de llamada de vídeo de acuerdo con una realización. En el bloque -1910-, el dispositivo de cliente -1210- recibe un mensaje de rechazo de llamada de vídeo (el usuario en el dispositivo de cliente -1410- ha rechazado la invitación de llamada de vídeo). El flujo del bloque -1910- se desplaza al bloque -1912- y el dispositivo de cliente -1210- muestra un mensaje rechazado de llamada de vídeo e interpreta opcionalmente uno o varios tonos de audio indicando la recepción del mensaje de rechazo de llamada de vídeo. El flujo se desplaza a continuación al bloque -1914- en el que el dispositivo de cliente -1210- termina de mostrar su propio pre-visionado de vídeo. El dispositivo de cliente -1210-, puede avisar también al usuario para que vuelva a la salida de audio original (por ejemplo, a través del altavoz -1270-) si se ha cambiado previamente la salida de audio al altavoz de manos libres del bloque -1718-.

La figura 20 es un diagrama de flujo que muestra operaciones a título de ejemplo llevadas a cabo en el dispositivo de cliente para transicionar desde una llamada de vídeo a una llamada conmutada de circuito de acuerdo con una realización. Se establece una llamada de vídeo -2010- entre los dispositivos de cliente -1210- y -1410- (la llamada de vídeo puede ser establecida de acuerdo con mecanismos descritos con referencia a las figuras 17 y 18 o se puede establecer sin transicionar desde una llamada de audio conmutada de circuito). En el bloque -1712-, el dispositivo de cliente -1210- recibe datos de entrada para transicionar a una llamada conmutada de circuito de audio solamente. Por ejemplo, con referencia a la figura 15, el usuario del dispositivo de cliente -1210- tiene seleccionado el bot�n -1520- de final de vídeo (por ejemplo, al teclear o llevar a cabo otro gesto predefinido sobre el bot�n de final de vídeo -1520-). El dispositivo de cliente -1210-transmite entonces un mensaje al dispositivo de cliente -1410- que indica transición a una llamada conmutada de circuito solamente de audio -2014-.

El dispositivo de cliente -1210- inicia entonces una petición de llamada de audio conmutada de circuito al dispositivo de cliente -1410- (por ejemplo, el dispositivo de cliente -1210- llama automáticamente al número del dispositivo de cliente -1410-). En algunas realizaciones, esto es llevado a cabo en el trasfondo básico y no requiere interacción con el usuario. La llamada es enrutada a través de una serie de elementos de red de la infraestructura de red portadora (por ejemplo, estaciones de base, centros de conmutación celulares, etc.).

El dispositivo de cliente -1410- recibe y contesta la llamada conmutada de circuito -2020-. En una realización, el dispositivo de cliente -1410- muestra la petición de llamada entrante y puede interpretar tonos de audio indicativos de que la petición de llamada entrante (por ejemplo, tonos de espera de llamada u otros tonos) y requiere intervención del usuario para contestar la llamada. En otras realizaciones, el dispositivo de cliente -1410- contesta automáticamente la llamada sin intervención del usuario (y puede interpretar o no tonos de audio indicativos de la petición de llamada entrante). Después de que se ha contestado la llamada, se establece la llamada conmutada de circuito de audio solamente -2030- entre los dispositivos de cliente -1210- y -1410-.

Despu�s de que la llamada conmutada de circuito solamente de audio ha sido establecida satisfactoriamente, los dispositivos de cliente -1210- y -1410- transicionan a la llamada solamente de audio -2032- y -2034respectivamente. Por ejemplo, la transición a la llamada solamente de audio comprende el cambio de la ruta de audio de la llamada de vídeo a la llamada conmutada de circuito, cesando de visualizar el vídeo que se est� recibiendo y parando la transmisión de vídeo. El dispositivo de cliente puede interrumpir también la visualización del pre-visionado de vídeo. De este modo, se debe comprender que, si bien la llamada solamente de audio conmutada de circuito est� siendo negociada, los usuarios en los dispositivos de cliente -1210- y -1410- pueden comunicar a través de la llamada de vídeo (es decir, la llamada de vídeo continua establecida, mientras que la llamada conmutada de circuito solamente de audio est� siendo negociada). Después de transicionar satisfactoriamente a la llamada conmutada de circuito de audio solamente, los dispositivos de cliente -1210- y -1410- terminan la conexión P2P -2040-. Los usuarios en los dispositivos de cliente -1210- y -1410- pueden comunicar a continuación a través de la llamada conmutada de circuito de audio solamente.

Si bien se han descrito realizaciones de la invención en relación con una llamada de vídeo que tiene dos participantes, las realizaciones no est�n limitadas de este modo puesto que pueden haber más participantes en la

llamada de vídeo. En estas realizaciones, el dispositivo de cliente puede mostrar diferentes entradas de vídeo de cada participante distinto en la charla de vídeo.

Si bien se han descrito realizaciones de la invención en relación con una llamada de vídeo que tiene dos participantes, en la que cada participante transmite vídeo, las realizaciones no est�n limitadas de este modo. Por ejemplo, en algunas realizaciones, solamente uno de los participantes puede estar transmitiendo vídeo al otro u otros participantes, y estos otro u otros participantes pueden estar trasmitiendo solamente audio. En algunas realizaciones, cada uno de los participantes puede determinar suspender la transmisión de vídeo en cualquier momento durante la llamada de vídeo.

En algunas realizaciones, la calidad del vídeo transmitido durante la llamada se ajusta din�micamente basándose en condiciones de red. Por ejemplo, durante periodos en los que la red est� congestionada, la velocidad de bits del vídeo se puede disminuir. De manera similar, durante periodos en los que la red est� relativamente libre de congestión, la velocidad de los bits del vídeo se puede incrementar. En algunas realizaciones, si las condiciones de la red impiden la transmisión del vídeo, los dispositivos de cliente participantes transicionan automáticamente a una llamada conmutada de circuito solamente de audio. De este modo, si la anchura de banda desciende por debajo de un límite determinado, los dispositivos de cliente participante pueden transicionar automáticamente a una llamada conmutada de circuito de audio solamente (o puede avisar al usuario que transicione a una llamada conmutada de circuito de audio solamente).

Soporte de servicios de manos libres mediante un dispositivo de manos libres para llamadas de vídeo IP

En una realización, los dispositivos de cliente incluyen la funcionalidad de soportar interacción con un dispositivo de manos libres (por ejemplo, auriculares con micrófono, es decir, un casco telefónico, un equipo de automóvil) a trav�sde una WPAN (“Wireless Personal Area Network”) (“Red de área Personal Inalámbrica”) (por ejemplo, Bluetooth, ZigBee, etc.) incluyendo soporte para gestionar llamadas de vídeo IP con la unidad de manos libres. La figura 32 es un diagrama de bloques que muestra un dispositivo de cliente en interfaz con una unidad de manos libres para gestionar llamadas de vídeo IP de acuerdo con una realización. El dispositivo de cliente -3210- incluye la capacidad de iniciar llamadas de vídeo (por ejemplo, invitar a uno o varios destinatarios a una sesión de comunicación en línea que consiste en una llamada de vídeo) y la capacidad de aceptar llamadas de vídeo. En algunas realizaciones, el dispositivo de cliente -3210- incluye también componentes de telefonía celular para realizar y recibir llamadas telefónicas celulares y/o tener acceso a Internet u otra red a través de una conexión celular.

Tal como se ha mostrado en las figura 32, el dispositivo de cliente -3210- incluye el gestor -3250- de llamadas de vídeo IP, el gestor de telefonía -3260-, el gestor de audio -3275- y el gestor de manos libres -3270-. En algunas realizaciones, el dispositivo de cliente -3210- incluye también el gestor de llamada celular -3255-. El gestor -3250- de llamada de vídeo IP gestiona una aplicación de llamada de vídeo P2P, incluyendo el establecimiento de una llamada de vídeo P2P IP a través de la red IP -3235- a través del servicio de llamada de vídeo IP -3230-, tal como se ha descrito anteriormente. En una realización, el servicio -3230- de llamada de vídeo IP incluye uno o varios servicios de invitación 320, el servicio de notificación automática -640-, el servicio de registro -630- y/o el servicio de registro -2130- y el servicio de retransmisión -650-. El gestor de llamada celular -3255- gestiona los componentes celulares para realizar y recibir llamadas telefónicas celulares de audio solamente a través de la red celular -3245- utilizando el servicio de llamada de audio celular -3240-.

El gestor -3250- de llamada de vídeo IP y el gestor -3255- de llamada celular est�n acoplados al gestor de telefonía -3260-. El gestor de telefonía -3260- gestiona las operaciones de telefonía tanto para el gestor de llamada de vídeo IP -3250- como para el gestor de llamada celular -3255-, incluyendo el seguimiento del historial de la llamada (tanto para llamadas de vídeo y para llamadas celulares de audio solamente) y otras informaciones relativas a las llamadas. El gestor de telefonía -3260- actúa también en interfaz con el gestor de manos libres -3270- para proporcionar servicios de manos libres con un dispositivo externo de manos libres para llamadas de vídeo IP y llamadas celulares a base del gestor -3250- de llamadas de vídeo IP y el gestor de llamadas celular -3255-. En una realización, se utiliza un formato de mensaje común entre el gestor -3250- de llamadas de vídeo IP, el gestor -3255de llamadas celulares, y el gestor de telefonía -3260- para proporcionar soporte para los servicios de manos libres para protocolos de tipos de llamada dispares (llamada de vídeo IP y llamada celular solamente de audio). De este modo, el gestor de telefonía -3260- proporciona soporte similar para servicios de manos libres con independencia de si los servicios de manos libres son para llamada de vídeo IP o para llamada celular solamente de audio. Esto impide asimismo que el gestor de manos libres -3270- necesite comprender si los servicios de manos libres son para una llamada de vídeo IP o para una llamada celular solamente de audio, de manera que las instrucciones estándar que son comprensibles por los dispositivos de manos libres, se pueden utilizar para proporcionar servicios de manos libres para llamadas de vídeo IP y también para llamadas celulares solamente de audio.

En una realización, el gestor de telefonía -3260- arbitra también entre el gestor -3250- de llamadas de vídeo IP y el gestor -3255- de llamadas celulares. Por ejemplo, el gestor de telefonía -3260- puede provocar la realización de una llamada de vídeo IP en espera para conmutación a una llamada celular establecida de audio solamente y/o provocar la realización de una llamada celular de audio solamente en espera para conmutación a una llamada de vídeo IP.

El gestor de manos libres -3270- proporciona soporte para proceso de manos libres. En una realización, el gestor de manos libres -3270- implementa un apilamiento de protocolo Bluetooth para conexión a dispositivos de manos libres adaptados a Bluetooth tales como un casco Bluetooth y equipos de automóvil Bluetooth. En una realización específica, el gestor -3270- de manos libres implementa un perfil de casco Bluetooth (por ejemplo, tal como se ha definido en la especificación 1.2 de perfil de casco (HSP) de 18 de diciembre de 2008) y/o un perfil de manos libres Bluetooth (por ejemplo, tal como se define en la especificación 1.5 (HFP 1.5) de perfil de manos libres de 25 de noviembre de 2005). El gestor -3270- de manos libres permite que la unidad de manos libres -3220- actúe como retransmisión de auditoría para una llamada de vídeo IP y para una llamada celular solamente de audio a través de la WPAN -3225-, llevando a cabo también otros servicios de manos libres. Por ejemplo, en el caso de una llamada de vídeo IP, la parte de audio de la llamada puede ser enrutada a través de la unidad de manos libres -3220-, en vez de un altavoz del dispositivo de cliente -3210-, mientras que la parte de vídeo de la llamada restante es visualizada por el dispositivo de cliente -3210- (o por una pantalla adjunta). La unidad -3220- de manos libres incluye también un micrófono para captar información de audio que es transmitida a continuación al dispositivo inform�tico del cliente -3210-. De este modo, un usuario puede utilizar una unidad de manos libres -3220- para hablar o escuchar audio durante una llamada de vídeo IP y/o una llamada celular solamente de audio.

El gestor -3270- de manos libres soporta también otros servicios de manos libres sensibles a recibir datos de entrada de la unidad de manos libres -3220-, incluyendo la realización de una o varias de las siguientes llamadas de vídeo IP y/o llamadas celulares solamente de audio: permitiendo a un usuario contestar una llamada; terminar una llamada; poner una llamada en espera; poner una llamada en silencio; aumentar/disminuir el volumen de una llamada; transferir audio al dispositivo de cliente; transferir audio a la unidad de manos libres; hacer una llamada y repetir el marcado de la última llamada. De este modo, un usuario puede utilizar la unidad de manos libres -3220para contestar una llamada de vídeo IP; terminar una llamada de vídeo IP; poner una llamada de vídeo IP en espera y/o en silencio, aumentar/disminuir el volumen de una llamada de vídeo IP, transferir audio de la llamada de vídeo IP para su salida a través de un altavoz del dispositivo de cliente -3210-, transferir audio del dispositivo de cliente -3210- a la unidad de manos libres -3220-, hacer una llamada de vídeo IP y volver a marcar la última llamada de vídeo IP.

El gestor -3250- de llamadas de vídeo IP, el gestor -3255- de llamadas celulares, y el gestor -3270- de manos libres est�n acoplados también al gestor de audio -3275-. El gestor de audio -3275- enruta audio de las llamadas de vídeo IP y las llamadas celulares solamente de audio a través de diferentes fuentes. Por ejemplo, el gestor de audio -3275puede provocar que el audio sea emitido a través de un altavoz del dispositivo de cliente -3210- adecuado para la modalidad de altavoz de manos libres, a través de un altavoz del dispositivo de cliente -3210- utilizado cuando el usuario sostiene el dispositivo de cliente -3210- en el oído durante una llamada, a través de un conector de casco/auriculares a un casco o auriculares enchufados al dispositivo de cliente -3210- y a través de una unidad de manos libres (tal como la unidad de manos libres -3220-).

La figura 33 muestra el dispositivo de cliente -3210- que recibe una invitación para una llamada de vídeo, provocando que suene el dispositivo de manos libres, recibiendo una indicación de contestación del dispositivo de manos libres, estableciendo la llamada de vídeo y enrutando el audio al dispositivo de manos libres, de acuerdo con una realización. La figura 33 se describir� con referencia a la realización a título de ejemplo de la figura 32. No obstante, se comprender� que las operaciones de la figura 33 pueden ser llevadas a cabo por realizaciones distintas de las explicadas con referencia a la figura 32, y las realizaciones explicadas con referencia a la figura 32 pueden llevar a cabo operaciones distintas de las explicadas con referencia a la figura 33.

En la operación -3310-, el gestor -3250- de llamadas de vídeo IP recibe una invitación de llamada de vídeo IP de otro dispositivo de cliente que invita al usuario del dispositivo de cliente -3210- a participar en una llamada de vídeo IP. La invitación de llamada de vídeo IP puede adoptar la forma de la invitación descrita anteriormente. El gestor -3250- de llamada de vídeo IP procesa la petición de invitación, incluyendo el provocar la visualización de la invitación en la operación -3315-. Por ejemplo, la petición de invitación puede ser visualizada de manera similar a la invitación -1410- de llamada de vídeo a título de ejemplo mostrada en la figura 14.

Adem�s, el gestor -3250- de llamada de vídeo IP genera y transmite un objeto de llamada -3320- al gestor de telefonía -3260-. El objeto de llamada -3320- incluye un juego de parámetros referentes a la llamada. Por ejemplo, los parámetros objeto de la llamada incluyen uno o varios de la situación de la llamada (por ejemplo, conexión) y un identificador de participante de la llamada (por ejemplo, el número de teléfono, dirección electrónica, u otro identificador de punto final de sesión de comunicación en línea), el tiempo de inicio, una indicación de si es una llamada saliente o entrante, y un identificador de llamada utilizado internamente para identificar la llamada.

En una realización, el objeto de llamada -3320- es un objeto de llamada genérico que, si bien los parámetros se basan en la información de la invitación de llamada de vídeo IP, se encuentra en un formato que es común, tanto para las peticiones de invitación de llamada de vídeo IP como para las llamadas celulares entrantes solamente de audio. De este modo, cuando se recibe una llamada celular entrante solamente de audio, el gestor -3255- de llamadas celulares genera un objeto de llamada entrante del mismo formato. De este modo, desde la perspectiva del gestor de telefonía -3260-, una petición de invitación de llamada de vídeo IP o una llamada entrante de audio solamente de tipo celular, parecen ser la misma.

El gestor de telefonía -3260- almacena la información en el objeto de llamada -3320- como parte de estructura de historial de la llamada. El gestor de telefonía -3260- genera también y envía un mensaje de llamada entrante -3322al gestor de manos libres -3270-. En una realización, el gestor de telefonía -3260- solamente envía el mensaje de llamada entrante -3322- si existe un dispositivo de manos libres, tal como el dispositivo de manos libres -3220asociado con el dispositivo de cliente -3210- (por ejemplo, el gestor de telefonía -3260- comprueba en primer lugar si existe un dispositivo de manos libres asociado con el dispositivo de cliente -3210-). En otras realizaciones, el gestor de telefonía -3260- envía el mensaje de llamada entrante -3320- al gestor de manos libres -3270- con independencia de si existe un dispositivo asociado de manos libres y el gestor de manos libres -3270- determina si rechaza/ignora el mensaje o lo procesa dependiendo de si existe un dispositivo de manos libres asociado. Para los objetivos de la figura 33 y figuras subsiguientes, se supone que el dispositivo de manos libres -3220- est� asociado al dispositivo inform�tico -3210- del cliente. En una realización, el mensaje de llamada entrante -3322- incluye el identificador de llamada.

Como respuesta a la recepción del mensaje de llamada entrante -3320-, el gestor de manos libres -3270- provoca una serie de mensajes a transmitir en el dispositivo de manos libres -3220- alert�ndolo y también al usuario de que existe una llamada entrante. Tal como se ha mostrado en la figura 33, el gestor de manos libres establece una conexión de audio -3325- (por ejemplo, un enlace Orientado a Conexión Síncrona (SCO) (“Synchronous Connection Oriented”)) con el dispositivo de manos libres -3220- antes de enviar un mensaje de tono de llamada -3330- por la conexión de audio establecida -3325-. Este mensaje de tono de llamada es seleccionado por el dispositivo de cliente -3210- y puede ser adaptable por el usuario del dispositivo de cliente -3210-. En una realización, el mensaje de tono de llamada para llamadas de vídeo IP es distinto que el tono de llamada para llamadas celulares solamente de audio. En otra realización, no se establece una conexión de audio hasta después de que la llamada ha sido contestada. En esta realización, se envía un mensaje de alerta de llamada al dispositivo de manos libres -3320- que entonces determina localmente si debe interpretar un tono de llamada para avisar al usuario de la llamada entrante (el mensaje de aviso de llamada puede ser enviado también antes de enviar el mensaje de tono de llamada -3330-). En esta realización, el mensaje de aviso de llamada puede ser enviado múltiples veces al dispositivo de manos libres -3220-, hasta que la llamada ha sido contestada o terminada.

En algunos casos, después de recibir el mensaje de aviso de llamada y/o el mensaje de llamada -3330-, el dispositivo de manos libres -3220- transmite el mensaje de contestación -3335-, que indica que el usuario ha contestado la llamada. Por ejemplo, el usuario ha presionado un bot�n de contestación en su dispositivo de manos libres -3220- o de otra forma, ha llevado a cabo acciones en el dispositivo de manos libres -3220- para contestar la llamada. El gestor -3270- de manos libres recibe el mensaje de llamada -3335- y transmite un mensaje de llamada -3340- al gestor de telefonía -3260-. En una realización, el mensaje de contestación -3340- incluye el identificador de llamada. Si bien no se ha mostrado en la figura 33, el gestor -3270- de manos libres puede transmitir también un mensaje de reconocimiento al dispositivo de manos libres -3220-, que es sensible a la recepción del mensaje de contestación -3335-.

El gestor de telefonía -3260- determina que el mensaje de llamada contestada -3340- pertenece a la llamada indicada en el objeto de llamada -3320- (por ejemplo, comparando el identificador de llamada incluido en un mensaje -3340- con la información almacenada desde el objeto de llamada -3320-) y transmite un mensaje -3345- al gestor de llamada de vídeo IP -3250- que indica que la llamada ha sido contestada. Como respuesta a la recepción de este mensaje, el gestor -3250- de llamada de vídeo IP establece una llamada de vídeo IP en una operación -3350-. Por ejemplo, el gestor -3250- de llamada de vídeo IP provoca un mensaje de aceptación de llamada de vídeo IP que se envía a un servicio de invitación, tal como se ha descrito anteriormente, y se establece una conexión P2P (de manera directa a través de una retransmisión) con el dispositivo inform�tico que ha transmitido la información.

Un cierto tiempo después de que la llamada de vídeo IP ha sido establecida, el gestor de llamada de vídeo IP -3250transmite un objeto de llamada -3355- al gestor de telefonía -3260-. El objeto de llamada -3355- incluye un conjunto similar de parámetros, tal como el objeto de llamada -3320- a excepción de que ha cambiado la situación de conectando a conectado. En una realización, el objeto de llamada -3355- es un objeto de llamada genérico que adopta un formato que es común, tanto para llamadas de vídeo IP establecidas como para llamadas a celulares conectadas de audio solamente.

Adem�s, un cierto tiempo después de que la llamada de vídeo IP ha sido establecida, el gestor de audio -3275enruta la parte de audio de la llamada de vídeo IP establecida a través del dispositivo de manos libres -3220-. En una realización, el gestor -3250- de llamada de vídeo IP o el gestor de telefonía -3260- solicita al gestor de audio -3275- el enrutado del audio a través del dispositivo de manos libres. El gestor del audio -3275- puede también transmitir un mensaje -3360- al gestor -3270- de manos libres que indica que la ruta de audio ser� cambiada para pasar por el dispositivo de manos libres -3220-. Si no se ha establecido todavía conexión de audio, el gestor -3270de manos libres establecer� una conexión de audio con el dispositivo de manos libres -3220-. Suponiendo que se ha establecido una conexión de audio, la parte de audio -3365- de la llamada de vídeo es enrutada al dispositivo de manos libres -3220-. De este modo, la parte de audio de la llamada de vídeo es controlada a través del dispositivo de manos libres -3220-, mientras que la parte de vídeo de la llamada de vídeo es visualizada en el dispositivo de cliente -3210-.

La figura 34 muestra el dispositivo de cliente -3210- que inicia una llamada de vídeo y el enrutado del audio para la llamada de vídeo establecida a través de un dispositivo de manos libres, de acuerdo con una realización. La figura 34 se ha descrito con referencia a la realización a título de ejemplo de la figura 32. No obstante, se debe comprender que las operaciones de la figura 34 pueden ser llevadas a cabo por realizaciones distintas de las que se han explicado con referencia a la figura 32 y las realizaciones explicadas con referencia a la figura 32 pueden llevar a cabo operaciones diferentes de las explicadas con referencia a la figura 34.

En la operación -3410-, el gestor de llamadas de vídeo IP -3250- provoca el envío de uno o varios mensajes de invitación de llamada de vídeo IP a otro dispositivo o dispositivos de cliente para invitar a un usuario o usuarios a una llamada de vídeo IP. El mensaje o mensajes de invitación de llamada de vídeo IP pueden adoptar la forma de la invitación descrita anteriormente. El gestor -3250- de llamada de vídeo IP genera y transmite el objeto de llamada -3415- al gestor de telefonía -3260-. De manera similar al objeto de llamada -3220-, el objeto de llamada -3415incluye un conjunto de parámetros con respecto a la llamada y adopta un formato genérico. El gesto de telefonía -3260- almacena la información en el objeto de llamada -3415- como parte de una estructura de historial de una llamada.

En una realización, el gestor de telefonía -3260- genera también y envía un mensaje de llamada saliente -3420- al gestor de manos libres -3270- que indica que existe una llamada saliente. Como respuesta a este mensaje, el gestor de manos libres -3270- establece una conexión de audio -3425- con el dispositivo de manos libres -3220- (si se tiene que enviar un tono de llamada específico en banda) y a continuación transmite un mensaje de tono de llamada -3430- al dispositivo de manos libres -3220-. En otra realización, el gestor de manos libres -3270- transmite solamente un mensaje de aviso de tono de llamada al dispositivo de manos libres -3220- en vez de establecer una conexión de audio y transmitir un tono de llamada en banda.

Alg�n tiempo después del envío de la invitación de llamada de vídeo IP, el gestor -3250- de llamada de vídeo IP recibe un mensaje -3435- de aceptación de la llamada de vídeo IP, que puede adoptar la forma de un mensaje de aceptación de llamada de vídeo, tal como se ha descrito anteriormente. Después de recibir el mensaje se establece una llamada de vídeo IP P2P con el dispositivo de cliente que acepta en la operación -3440- (por ejemplo, una conexión P2P (directa o a través de reproducción) se establece con el dispositivo inform�tico que ha aceptado la invitación).

Un cierto tiempo después de que la llamada de vídeo IP ha sido establecida, el gestor de llamada de vídeo IP -3250transmite un objeto de llamada -3445- al gestor de telefonía -3260-. El objeto de llamada -3445- incluye un conjunto similar de parámetros, tal como el objeto de llamada -3415- a excepción de que la situación ha cambiado de conectando a conectado. El objeto de llamada -3445- es también un formato genérico. Además, en algún momento después de que la llamada de vídeo IP ha sido establecida, el gestor de audio -3275- enruta la parte de audio de la llamada de vídeo IP establecida a través de un dispositivo de manos libres -3220-. En una realización, el gestor -3250- de llamada de vídeo IP o el gestor de telefonía -3260- requiere al gestor de audio -3275- el enrutado del audio a través del dispositivo de manos libres. El gestor de audio -3275- puede transmitir también un mensaje -3455al gestor de manos libres -3270- que indica que la ruta de audio ser� cambiada para pasar por el dispositivo de manos libres -3220-. Si no se ha establecido todavía conexión de audio, el gestor -3270- de manos libres establecer� una conexión de audio con el dispositivo de manos libres -3220-. Suponiendo que se ha establecido conexión de audio, la parte de audio -3460- de la llamada de vídeo es enrutada al dispositivo de manos libres -3220-. De este modo, la parte de audio de la llamada de vídeo es controlada a través del dispositivo de manos libres -3220- mientras que la parte de vídeo de la llamada de vídeo es visualizada en el dispositivo de cliente -3210-.

La figura 35 muestra un dispositivo de cliente -3210- que inicia una llamada de vídeo como respuesta a la recepción de una petición de llamada del dispositivo de manos libres -3220-, de acuerdo con una realización. La figura 35 se describir� haciendo referencia a la realización a título de ejemplo de la figura 32. No obstante, se debe comprender que las operaciones de la figura 35 pueden ser llevadas a cabo por realizaciones distintas de las explicadas con referencia a la figura 32 y las realizaciones explicadas con referencia a la figura 32 pueden llevar a cabo operaciones diferentes de las explicadas con referencia a la figura 35.

El gestor de manos libres -3270- recibe una petición de llamada -3510- del dispositivo de manos libres -3220-. La petición de llamada -3510- puede ser generada como respuesta a que un usuario ha seleccionado un número de teléfono o un identificador de punto final de sesión de comunicación en línea que se debe llamar. Por ejemplo, el usuario puede seleccionar un bot�n de nueva llamada en el dispositivo de manos libres -3220- que requiere que la última llamada sea marcada otra vez. El gestor de manos libres -3270- transmite un mensaje -3250- de petición de llamada al gestor de telefonía -3260-. El gestor de telefonía -3260- determina si el mensaje -3520- de petición de llamada est� solicitando una llamada a un identificador que est� asociado con una llamada de vídeo (y por lo tanto, la petición de llamada debe ser enviada al gestor -3250- de llamada de vídeo IP) o asociada con un número de teléfono para una llamada celular de audio solamente (y por lo tanto, se debe enviar al gestor de llamada celular -3255-). Por ejemplo, en caso de que la petición de llamada -3520- es una petición de nuevo marcado, el gestor de telefonía -3260- accede a la última llamada marcada, que puede ser o bien una llamada de vídeo IP o una llamada celular de audio solamente, para determinar dónde enviar la petición de llamada. Tal como se ha mostrado en la

figura 35, el gestor de telefonía envía el mensaje de petición de llamada -3525- al gestor de llamada de vídeo IP -3250-. El mensaje de petición de llamada -3525- incluye el identificador de participante solicitado para la llamada de vídeo (por ejemplo, un número de teléfono, una dirección de correo electrónico o un identificador de punto final de sesión de comunicación en línea). Como respuesta a la recepción del mensaje de petición de llamada -3525-, el gestor -3250- de llamada de vídeo IP provoca el envío de un mensaje de invitación de llamada de vídeo IP al participante indicado en la operación -3410-, tal como se ha descrito en la figura 34. Las operaciones restantes mostradas en la figura 35 son llevadas a cabo tal como se ha descrito, con referencia a la figura 34. De este modo, el dispositivo de cliente -3210- soporta el establecimiento de una llamada de vídeo IP como resultado de la acción del usuario en un dispositivo de manos libres asociado.

La figura 36 muestra el dispositivo de cliente -3210- enrutando audio de una llamada de vídeo establecida al dispositivo de manos libres -3220-, de acuerdo con una realización. Existe una llamada de vídeo IP establecida -3610- entre el dispositivo de cliente -3210- y uno o varios otros dispositivos de cliente. La parte de audio de esta llamada est� siendo emitida en este momento por un altavoz del dispositivo de cliente -3210- o a través de un dispositivo de auriculares conectado al dispositivo de cliente -3210-. En la operación -3615-, el gestor -3250- de llamada de vídeo IP recibe datos de entrada para transferir el audio al dispositivo de manos libres -3220-. Por ejemplo, un usuario del dispositivo de cliente -3210- ha proporcionado datos de entrada a la aplicación de llamada de vídeo IP para transferir la señal de audio a un dispositivo apareado de manos libres. Como respuesta a la recepción de dichos datos de entrada, el gestor -3250- de llamada de vídeo IP envía una petición de enrutado de audio -3620- al gestor de audio -3275- para enrutar la parte de audio de la llamada de vídeo a través del dispositivo de manos libres -3220-. El gestor de audio -3275- puede transmitir un mensaje -3625- al gestor -3270- de manos libres que indica que la ruta de audio ser� cambiada para pasar al dispositivo de manos libres -3220-. Si no se ha establecido todavía una conexión de audio, el gestor -3270- de manos libres establecer� una conexión de audio -3630- con el dispositivo de manos libres -3220-. Suponiendo que existe una conexión de audio establecida, la parte de audio -3635- de la llamada de vídeo es enrutada al dispositivo de manos libres -3220-. De este modo, después de que se ha establecido una llamada de vídeo IP, el dispositivo de cliente -3210- permite al usuario transferir la llamada de audio al dispositivo de manos libres.

Si bien la figura 36 muestra la transferencia de audio a un dispositivo de manos libres como respuesta a la recepción de datos de entrada directos en el dispositivo de cliente, en otras realizaciones, el usuario puede provocar la transferencia de audio al dispositivo de manos libres -3220- a través de datos de entrada en el dispositivo de manos libres -3220-. En estas realizaciones, el gestor de manos libres -3270- recibe una instrucción del dispositivo de manos libres -3220- para transferir la señal de audio. El gestor de manos libres -3270- envía entonces la petición al gestor de audio -3275- que entonces enruta la señal de audio.

Adem�s, si bien la figura 36 muestra la transferencia de audio a un dispositivo de manos libres, en algunas realizaciones se puede transferir también audio desde el dispositivo de manos libres a un altavoz (o a un dispositivo de auriculares) del dispositivo de cliente -3210-. Esto se puede iniciar en el dispositivo de cliente -3210- y/o el dispositivo de manos libres -3220-. En estas realizaciones, el gestor de audio -3275- recibe la petición de enrutado de audio (del gestor -3250- de llamadas de vídeo IP o del gestor -3270- de manos libres) para enrutar el audio al dispositivo de cliente -3210- y actúa de acuerdo con ello.

La figura 37 muestra el dispositivo de cliente -3210- que termina en una llamada de vídeo que responde a la recepción de una petición de llamada final desde el dispositivo de manos libres -3220-, de acuerdo con una realización. El gestor -3270- de manos libres recibe un mensaje -3710- de llamada final del dispositivo de manos libres -3220-, que responde a la selección por parte del usuario de terminar una llamada (por ejemplo, se ha seleccionado un bot�n de final en el dispositivo de manos libres -3220-) en el dispositivo de manos libres -3220-. El gestor -3270- de manos libres transmite la petición -3715- de llamada final al gestor de telefonía -3260-. En una realización, la petición de llamada final -3715- incluye un identificador de llamada para indicar qué llamada se tiene que terminar (en el caso de que existan múltiples llamadas). El gestor de telefonía -3260- determina que la llamada que se debe terminar est� asociada con el gestor -3250- de llamadas de vídeo IP y envía el mensaje de llamada final -3720- al gestor -3250- de llamadas de vídeo IP. Como respuesta a la recepción del mensaje de llamada final -3720-, el gestor -3250- de llamadas de vídeo IP provoca la terminación de la llamada de vídeo IP y provoca que el dispositivo de cliente -3210- sea desconectado de la conexión P2P. De este modo, el dispositivo de cliente -3210soporta que se permita al usuario terminar una llamada de vídeo IP utilizando un dispositivo de manos libres asociado.

La figura 38 es un diagrama de bloques que muestra un sistema inform�tico a título de ejemplo, que se puede utilizar en algunas realizaciones. Por ejemplo, la arquitectura a título de ejemplo del sistema inform�tico -3800puede ser incluida en los dispositivos de cliente -110-, -1210-, -1410-, -2110-, -2610-, -3210-, etc. u otros dispositivos inform�ticos que se describan. Se debe comprender que si bien la figura 38 muestra varios componentes del sistema inform�tico, no est� destinada a representar ninguna arquitectura particular o forma de interconectar los componentes, dado que dichos detalles no pertenecen a la presente invención. Se apreciar� que otros sistemas de ordenador que tienen menos componentes o más componentes pueden ser también utilizados.

Tal como se ha mostrado en la figura 38, el sistema inform�tico -3800- que adopta la forma de un sistema de proceso de datos, incluye el bus o buses -3850- acoplados con el sistema de proceso -3820-, suministro de potencia -3825-, memoria -3830-, y memoria no volátil -3840- (por ejemplo, un disco duro, memoria flash, memoria de cambio de fase (PCM), etc.). El bus o buses -3850- pueden estar conectados entre s� a través de varios puentes, controladores y/o adaptadores, tal como es bien conocido en esta técnica. El sistema de proceso -3820- puede recuperar instrucciones de la memoria -3830- y/o y de la memoria no volátil -3840- y puede ejecutar las instrucciones para llevar a cabo operaciones que se han descrito anteriormente. El bus -3850- interconecta los componentes anteriormente mencionados entre s�, e interconecta también aquellos componentes al muelle opcional -3860-, dispositivo controlador de visualización y dispositivo de pantalla -3870-, dispositivos entrada/salida -3880- (por ejemplo, NIC (Network Interface Card) (Tarjeta de Interfaz de Red), un control de cursor (por ejemplo, ratón, pantalla táctil, panel táctil, etc.), teclado, etc.) y el transceptor o transceptores inalámbricos opcionales 3890, por ejemplo, Bluetooth, Wi-Fi, infrarrojos, etc.

La figura 39 es un diagrama de bloques que muestra un sistema de proceso de datos a título de ejemplo, que puede ser utilizado en algunas realizaciones. Por ejemplo, el sistema de proceso de datos -3900- puede ser un ordenador de mano, un asistente digital personal (PDA), un teléfono celular, un sistema de juegos portátil, un reproductor portátil de medios, una tableta o un dispositivo inform�tico manual que puede incluir un teléfono celular, un reproductor de medios y/o un sistema de juegos. Como otro ejemplo, el sistema de proceso de datos -3900- puede ser un ordenador de red o un dispositivo de proceso incorporado con otro dispositivo.

De acuerdo con una realización, la arquitectura a título de ejemplo del sistema de proceso de datos -3900- puede ser incluida en los dispositivos de cliente -110-, -1210-, -1410-, -2110-, -2610-, -3210-, etc. u otros dispositivos inform�ticos que se han descrito. El sistema de proceso de datos -3900- incluye el sistema de proceso -3920- que puede comprender uno o varios microprocesadores y/o un sistema en un circuito integrado. El sistema de proceso -3920- est� acoplado a una memoria -3910-, a un suministro de potencia -3925- (que incluye una o varias baterías), una entrada/salida de audio 3940, un controlador de visualización y dispositivo de visualización 3960, un dispositivo opcional de entrada/salida 3950, un dispositivo o dispositivos de entrada -3970- y un transceptor o transceptores inalámbricos 3930. Se apreciar� que también pueden formar parte del sistema de proceso de datos -3900- en ciertas realizaciones otros componentes adicionales no mostrados en la figura 39, y en ciertas realizaciones, se pueden utilizar menos componentes de los mostrados en la figura 39. De forma adicional, se apreciar� que se pueden utilizar uno o varios buses, no mostrados en la figura 39, para interconectar los diferentes componentes, tal como es bien conocido en la técnica.

La memoria -3910- puede almacenar datos y/o programas para ejecución por el sistema de proceso de datos -3900-. El dispositivo de entrada/salida de audio -3940- puede incluir un micrófono y/o un altavoz para interpretar, por ejemplo, música y/o proporcionar funcionalidad de teléfono a través del altavoz y el micrófono. El controlador de visualización y dispositivo de visualización -3960- pueden incluir un interfaz gráfico de usuario (GUI). Los transceptores inalámbricos (por ejemplo, RF) -3930- (por ejemplo, un transceptor Wi-Fi, un transceptor de infrarrojos, un transceptor Bluetooth, un transceptor de telefonía celular inalámbrica, etc.) se pueden utilizar para comunicar con otros sistemas de proceso de datos. El dispositivo o dispositivos de entrada -3970- permitirán a los usuarios proporcionar datos de entrada al sistema. Estos dispositivos de entrada pueden ser un teclado, tablero, panel táctil, multipanel táctil, etc. Los otros dispositivos de entrada/salida opcionales -3950- pueden consistir en un conector para un muelle.

Las técnicas mostradas en las figuras pueden ser implementadas utilizando códigos y datos almacenados y ejecutados en uno o varios dispositivos inform�ticos (por ejemplo, dispositivos de cliente, servidores, etc.). Estos dispositivos inform�ticos almacenan y transmiten (internamente y/o con otros dispositivos inform�ticos a través de una red) código (compuesto por instrucciones de software) y datos utilizando medios legibles por aparatos, tal como medios legibles por aparatos no temporales, tangibles (por ejemplo, medios de almacenamiento legibles por aparatos, tales como discos magnéticos, discos ópticos; memorias solamente de lectura; dispositivos de memoria flash) y señales con propagación temporal (por ejemplo, señales eléctricas, ópticas, acústicas, o de otra forma de señales con propagación, tales como ondas portadoras, señales de infrarrojos, señales digitales, etc.). Además, estos dispositivos de cálculo incluyen de manera típica un conjunto de uno o varios procesadores acoplados a uno o varios otros componentes, tales como uno o varios medios legibles por aparato, tangibles, no temporales (para almacenar códigos y/o datos) dispositivos de entrada/salida de usuario (por ejemplo, un teclado, un panel táctil, y/o una pantalla) y conexiones de red (para transmitir código y/o datos utilizando señales de propagación temporal). El acoplamiento del conjunto de procesadores y otros componentes tiene lugar típicamente con intermedio de uno o varios buses y puentes (designados también como controladores bus). De este modo, un medio legible por aparato, no temporal, de un determinado dispositivo inform�tico, almacena típicamente instrucciones para ejecución en el conjunto de uno o varios procesadores de dicho dispositivo inform�tico. Se pueden implementar una o varias partes de una realización utilizando diferentes combinaciones de software, firmware y/o hardware.

Si bien se han descrito operaciones haciendo referencia a la validación automática de una dirección de correo electrónico sin requerir que el usuario cliquee en un enlace incluido en un mensaje de correo electrónico de validación con respecto a una dirección electrónica de validación a utilizar como identificador de punto final de sesión de comunicación en línea, las realizaciones no est�n limitadas de este modo. Por ejemplo, en algunas

realizaciones, las operaciones descritas con referencia a validación automática de correo electrónico son llevadas a cabo cuando se tiene que validar una dirección de correo electrónico por otras razones. Por ejemplo, un usuario puede registrarse para un servicio que requiere la validación de una dirección de correo electrónico como perteneciente a aquél usuario como parte del proceso de registro. El usuario proporciona la dirección de correo 5 electrónico al servicio, y recibe un mensaje (por ejemplo, a través de la visualización de una página web del servicio) que indica que la dirección de correo electrónico debe ser validada y que se ha enviado un mensaje de correo electrónico de validación o que ser� enviado a la dirección de correo electrónico que fue facilitada (el mensaje de correo electrónico de validación puede incluir o no un enlace de validación). Una aplicación en el dispositivo de cliente puede comprobar automáticamente una cuenta de correo electrónico correspondiente a la dirección de correo 10 electrónico para el mensaje de validación, y cuando se ha localizado, analizar automáticamente el mensaje para localizar un símbolo de validación y transmitir un mensaje de validación de la dirección electrónica que incluye la dirección de correo electrónico y el símbolo de validación a un servidor de validación de correo electrónico asociado con el servicio para validar la dirección de correo electrónico. Si bien los diagramas de flujo de las figuras muestran un orden específico de operaciones llevado a cabo por ciertas realizaciones, se debe comprender que este orden es

15 solamente a título de ejemplo (por ejemplo, realizaciones alternativas pueden llevar a cabo las operaciones en un orden distinto, pueden combinar ciertas operaciones, pueden solapar otras operaciones, etc.).

Si bien la invención ha sido descrita en términos de varias realizaciones, los técnicos en la materia reconocerán que la invención no est� limitada a las realizaciones descritas. Por lo tanto, la descripción se tiene que considerar como 20 ilustrativa en vez de limitativa.

Claims

REIVINDICACIONES

1. Procedimiento para el registro de un dispositivo inform�tico de cliente para sesiones de comunicación en línea, que comprende:

5 recibir un mensaje que tiene un símbolo de identificación (115), que es exclusivo del dispositivo inform�tico (110) del cliente, y un número de teléfono del dispositivo inform�tico (110) del cliente, a partir de un SMS, Servicio de Mensaje Corto, dispositivo de tránsito (130), que ha recibido un mensaje SMS que tiene el símbolo de identificación (115) del dispositivo inform�tico (110) del cliente, y que determin� el número de teléfono del dispositivo inform�tico (110) del

10 cliente; caracterizado

por asociar el símbolo de identificación (115) y el número de teléfono;

y almacenar la asociación. 15
2. Procedimiento, según la reivindicación 1, en el que el mensaje procedente del dispositivo de tránsito SMS (130) fue transmitido como respuesta a la activación del dispositivo inform�tico (110) del cliente y transmitiendo automáticamente el mensaje SMS que tenía el símbolo de identificación (115) del dispositivo inform�tico (110) del cliente.
3. Procedimiento, según la reivindicación 1, en el que el símbolo de identificación (115) identifica de manera única el dispositivo inform�tico de cliente (110) y contiene información que permite a un servicio de notificación automática localizar y transmitir mensajes de notificación automática al dispositivo inform�tico de cliente (110).

25 4. Procedimiento, según la reivindicación 1, que comprende además facilitar la asociación entre el símbolo de identificación (115) y el número de teléfono a un servicio de invitación de sesión de comunicación en línea a utilizar cuando la transmisión de sesión de comunicación en línea invita al dispositivo inform�tico (110) del cliente.
5. Procedimiento, según la reivindicación 1, que comprende además, antes de asociar el símbolo de identificación 30 (115) y el número de teléfono, llevar a cabo lo siguiente:

generar una señal de identificación basándose en uno o varios de los símbolos de identificación (115) y el número de teléfono;

35 transmitir un mensaje incluyendo la señal de identificación, símbolo de identificación (115) y número de teléfono al dispositivo de tránsito SMS (130) para suministro al dispositivo inform�tico de cliente (110);

recibir un mensaje que tiene la señal de identificación, símbolo de identificación (115) y número de teléfono procedente del dispositivo inform�tico de cliente (110); y 40 validar el símbolo de identificación (115) y número de teléfono recibido del dispositivo (110) inform�tico del cliente.
6. Procedimiento, según la reivindicación 1, en el que el dispositivo (130) de tránsito SMS es una pasarela SMS o un

agregador SMS. 45
7. Servidor de registro (140) para registrar dispositivos inform�ticos de cliente (110) para sesiones de comunicación en línea comprendiendo:

un SMS, servicio de mensajes cortos, un interfaz de tránsito para recibir mensajes de petición de registro de un

50 dispositivo de tránsito de SMS que recibe mensajes SMS de dispositivos inform�ticos de cliente (110), incluyendo cada mensaje de petición de registro un símbolo de identificación (115) que es único para un dispositivo inform�tico de cliente (110) y un número de teléfono de dicho dispositivo inform�tico determinado por el dispositivo de tránsito de SMS (130); y caracterizado por un módulo de asociación para asociar símbolos de identificación (115) y números de teléfono y almacenar los símbolos de identificación asociados (115) y números de teléfono en un almacenamiento

55 de datos de registro de sesión de comunicación en línea.
8. Servidor de registro (140), según la reivindicación 7, en el que un símbolo de identificación (115) identifica de manera única a un dispositivo inform�tico de cliente (110) y contiene información que permite que un servicio de notificación automática localice y transmita mensajes de notificación automática a aquél dispositivo inform�tico de

60 cliente (110).
9. Servidor de registro (140), según la reivindicación 7, que comprende además: un módulo de generación de señal de identificación para generar una señal de identificación para cada símbolo de identificación (115) y un par de número de teléfono recibido del dispositivo de tránsito SMS (130), y

en el que el interfaz de tránsito para transmitir mensajes de respuesta de registro al dispositivo de tránsito SMS (130), incluyendo cada mensaje de respuesta de registro una señal de identificación, un símbolo de identificación

(115) y un número de teléfono para un dispositivo inform�tico de cliente (110);

un interfaz de dispositivo de cliente para recibir mensajes de petición de validación de registro de dispositivos de cliente, incluyendo cada mensaje de petición de validación de registro una señal de identificación, símbolo de identificación (115) y número de teléfono de un dispositivo inform�tico de cliente (110); y

un módulo de validación para validar símbolos automáticos y números de teléfono para dispositivos inform�ticos de cliente (110) antes de su almacenamiento en el almacenamiento de datos de registro de sesión de comunicación en línea.
10.

Servidor de registro (140), según la reivindicación 7, en el que el dispositivo de tránsito SMS (130) es una pasarela SMS o un agregador SMS.
11.

Medio de almacenamiento legible por aparato, no temporal, que proporciona instrucciones que cuando son ejecutadas por un procesador, provocan que dicho procesador lleve a cabo un procedimiento para el registro de un dispositivo inform�tico de cliente (110) para sesiones de comunicación en línea, según cualquiera de las reivindicaciones 1-6.
12.

Sistema de registro de sesión de comunicación en línea que comprende:

un servicio de mensajes cortos, SMS, un dispositivo de tránsito (130) adaptado para recibir mensajes SMS de dispositivos inform�ticos de cliente (110) que tienen símbolos de identificación (115) de los dispositivos inform�ticos de cliente (110) y para determinar números de teléfono de los dispositivos inform�ticos de cliente (110) a partir de los mensajes SMS, estando además el dispositivo de tránsito SMS (130) adaptado para transmitir símbolos de identificación (115) y pares de números de teléfono a un servidor de registro; y caracterizado porque

el servidor de registro est� adaptado para asociar símbolos de identificación (115) y pares de números de teléfono y almacenar los símbolos de identificación asociados (115) y números de teléfono en un almacenamiento de datos de registro de sesión de comunicación en línea.
13.

Sistema, según la reivindicación 12, en el que cada uno de los símbolos de identificación (115) identifica de manera única un dispositivo inform�tico de cliente (110) y contiene información que permite que un servicio de notificación automática localice y transmita mensajes de notificación automática a dicho dispositivo inform�tico de cliente (110).
14.

Sistema, según la reivindicación 12, en el que el servidor de registro est� adaptado además para generar una señal de identificación para cada símbolo de identificación (115) y par de números de teléfono recibidos del dispositivo de tránsito de SMS (130) y para transmitir mensajes de tránsito de SMS (130) que tienen una señal de identificación, símbolo de identificación (115) y número de teléfono para un dispositivo inform�tico de cliente (110).
15.

Sistema, según la reivindicación 14, en el que el dispositivo de tránsito de SMS (130) est� adaptado además para transmitir mensajes de SMS a los dispositivos inform�ticos de cliente (110), teniendo cada mensaje una señal de identificación generada por el servidor de registro y un número de teléfono para aquél dispositivo inform�tico de cliente (110).
16.

Sistema, según la reivindicación 15, en el que el servidor de registro est� adaptado además para recibir mensajes de dispositivos inform�ticos de cliente (110), incluyendo cada mensaje una señal de identificación, un número de teléfono y un símbolo de identificación (115), y en el que el servidor de registro est� adaptado además para validar los símbolos de identificación (115) y pares de números de teléfono recibidos de los dispositivos inform�ticos de cliente (110) basándose en la señal de identificación recibida del dispositivo inform�tico de cliente

(110) y la señal de identificación generada por el servidor de registro.