MX2012011620A

MX2012011620A - Transicion entre llamadas de circuito conmutado y videollamadas.

Info

Publication number: MX2012011620A
Application number: MX2012011620A
Authority: MX
Inventors: Justin Santamaria; David Mcleod; Jeremy Brown
Original assignee: Apple Inc
Priority date: 2010-04-07
Filing date: 2010-09-23
Publication date: 2012-11-30
Also published as: US20110252146A1; MX2012011624A; JP2013525879A; TWI551112B; US8725880B2; KR101436225B1; US20110250909A1; US8948797B2; EP2556640B1; WO2011126505A1; JP2013529410A; US9577976B2; AU2010350741B2; US8423058B2; BR112012025358B1; KR101453640B1; BR112012025379A2; EP2540052B1; JP5791056B2; GB2495814A

Abstract

La transición entre una llamada de circuito conmutado de audio solamente y una videollamada; un dispositivo de cliente, el cual actualmente está conectado a uno o más dispositivos de cliente diferentes a través de una llamada de circuito conmutado de audio solamente establecida, recibe entrada de un usuario para cambiar de la llamada de circuito conmutado de audio solamente a la videollamada; un mensaje de invitación de videollamada es transmitido a los otros dispositivos de cliente; el dispositivo de cliente recibe un mensaje de aceptación de videollamada desde los otros dispositivos de cliente y comienza a transmitir video capturado por su cámara de vista frontal a los otros dispositivos de cliente; en respuesta a recibir al menos un cuadro de video de cada uno de uno o más dispositivos de cliente diferentes, el dispositivo de cliente cambia de la llamada de circuito conmutado de audio solamente a la videollamada; después de cambiar a la videollamada, se corta la llamada de circuito conmutado.

Description

TRANSICION ENTRE LLAMADAS DE CIRCUITO CONMUTADO Y VIDEOLLAMADAS CAMPO DE LA INVENCION Las modalidades de la invención se refieren al campo de la conexión en red de computadoras; y de manera más especifica a la transición entre llamadas de circuito conmutado y videollamadas .

ANTECEDENTES DE LA INVENCION Muchas implementaciones para proporcionar sesiones de comunicación en linea (por ejemplo, mensajería instantánea, videoconferencia, etcétera) requieren que los usuarios de los dispositivos de computación instalen software y/o se registren con el servicio. Por lo tanto, como un pre-requisito para que un usuario establezca una sesión de comunicación en línea con otro usuario, ambos usuarios deben estar registrados y/o tener el mismo software instalado. Muchas implementaciones también mantienen presencia (por ejemplo, una lista de amigos) que permite a los usuarios determinar el estatus de otros usuarios (por ejemplo, en línea, fuera de línea, ausente, etcétera) .

Las redes públicas grandes, tales como la Internet, con frecuencia tienen conexiones con redes privadas más pequeñas, tal como aquellas mantenidas por una corporación, proveedor de servicio de Internet, o incluso hogares individuales. Por su naturaleza, las redes públicas deben tener .una asignación comúnmente acordada de direcciones de red, es decir, direcciones públicas. Por una variedad de motivos, los mantenedores de redes privadas con frecuencia eligen utilizar direcciones de redes privadas para las redes privadas que no son parte de la asignación comúnmente acordada. Por lo tanto, para que el tráfico de red de la red privada pueda atravesar la red pública, se requiere cierta forma de traducción de dirección de red privada/pública ("NAT") .

Un dispositivo que ejecuta operaciones NAT altera los paquetes de datos que están siendo enviados desde la red privada para cumplir con el esquema de direccionamiento de la red pública. Particularmente, el traductor de la dirección de red reemplaza la dirección privada de origen y el número de puerto de un paquete con su propia dirección pública y un número de puerto asignado. Un traductor de dirección de red también altera los paquetes de datos que están siendo recibidos para que computadoras en la red privada reemplacen la dirección pública de destino y el número de puerto con la dirección privada correcta y el número de puerto del destinatario pretendido. Tal como aquí se utiliza, el término dirección debiera ser interpretado para incluir tanto una dirección como un número de puerto en caso que sea apropiado en el contexto, tal como lo entenderán aquellos expertos en la técnica.

NAT se ha vuelto cada vez más común en la computación de red moderna. Una ventaja de NAT es que hace más lento el vaciado del espacio de direcciones de red pública. Por ejemplo, el direccionamiento TCP/IP, el cual es utilizado en la Internet, comprende cuatro secuencias de tres dígitos cada una, proporcionando así un espacio de dirección finito. Adicionalmente, algunas porciones de este espacio de dirección se reservan para usos o usuarios particulares, vaciando aún más el número real de direcciones disponibles. Sin embargo, si se utiliza NAT, una red privada o subred puede utilizar un número arbitrario de direcciones, y aun así presentar solamente una sola dirección pública estandarizada al mundo exterior. Esto hace que el número de direcciones disponibles sea prácticamente ilimitado, debido a que cada red privada podría, teóricamente, utilizar exactamente las mismas direcciones privadas.

Una ventaja proporcionada por NAT es la seguridad incrementada que surge del hecho de que aquéllos en la red pública no pueden determinar la dirección de red real (es decir, privada) de una computadora en una red privada. Esto se debe solamente a que la dirección pública es proporcionada en la red pública por el traductor de dirección de red. Adicionalmente, esta dirección pública puede corresponder a cualquier número de computadoras en la red privada.

Diferentes tipos de NAT emplean diferentes niveles de seguridad. Por ejemplo, con una "NAT de cono completo", una vez que una dirección interna (iAddr : iPort) es mapeada a una dirección externa (eAddr rePort) , cualquier huésped externo puede enviar paquetes a iAddr riPort enviando paquetes a eAddr :ePort. Con una "NAT de cono restringido", un huésped externo con una dirección hAddr puede enviar paquetes a iAddr: iPort enviando paquetes a eAddr :ePort solamente si iAddr riPort ha enviado previamente un paquete a hAddr. El puerto del huésped externo es irrelevante. Con una "NAT de cono con puerto restringido", un huésped externo que tiene una dirección/puerto hAddr :hPort puede enviar paquetes a iAddr :iPort enviando paquetes a eAddr rePort solamente si iAddr :iPort envió previamente un paquete a hAddr :hPort. Finalmente, con una NAT simétrica, cada solicitud desde la misma iAddr :iPort a una dirección IP de destino especifico y puerto es mapeada a una eAddrrePort única. Si el mismo huésped interno envía un paquete a un destino diferente, se utiliza un mapeo de puerto y dirección externa diferente. Solamente un huésped externo que recibe un paquete desde un huésped interno puede enviar un paquete de regreso al huésped interno .

La computación par-a-par ("P2P") se refiere a una arquitectura de red distribuida comprendida de nodos de computación que ponen una porción de sus recursos directamente disponibles a otros participantes de la red. Los pares en una red P2P establecen canales de comunicación directa entre sí y actúan tanto como clientes como servidores, en contraste al modelo de cliente-servidor tradicional en el cual los servidores suministran recursos y los clientes consumen recursos.

Las operaciones NAT antes descritas poseen numerosos problemas para conexiones P2P. Por ejemplo, el establecimiento de una conexión directa entre dos pares se vuelve cada vez más difícil si uno o ambos de los pares están ubicados detrás de uno o más de los tipos de NAT antes descritos. Este problema es exacerbado por el hecho de que los dispositivos del cliente tales como el Apple iPod Touch®, Apple iPhone®, Apple iPad® y otros dispositivos diversos (por ejemplo, dispositivos RIM Blackberry®, dispositivos Palm Pre®, etcétera) frecuentemente son movidos entre redes que tienen diferentes implementaciones NAT. Por ejemplo, el Apple iPhone™ tiene la capacidad para comunicarse sobre redes Wi-Fi (por ejemplo, redes 802.11b, g, n) ; redes 3G (por ejemplo, redes del Sistema de Telecomunicaciones Móviles Universales ("UMTS"), Redes de Acceso de Paquete de Enlace Ascendente de Alta Velocidad ("HSUPA"), etcétera); y redes conocidas como redes de área personal ("PANs")). Dispositivos del cliente futuros tendrán la capacidad para comunicarse sobre canales de comunicación adicionales tales como WiMAX, Telecomunicación Móvil Internacional ("IMT") Avanzada, y Evolución a Largo Plazo ("LTE") Avanzada, por mencionar unos cuantos .

Las unidades manos libres (por ejemplo, auriculares, equipos para vehículos) típicamente se utilizan para comunicarse con un dispositivo de computación para servicios de manos libres. Por ejemplo, resulta común que un dispositivo de computación que incluye funcionalidad de telefonía celular incluya la capacidad para comunicarse con una unidad manos libres que actúa como un relé de auditorio entre la unidad manos libres y el dispositivo de computación.

BREVE DESCRIPCIÓN DE IA INVENCION Se describen un método y aparato para cambiar entre una llamada de circuito conmutado de audio solamente y una videollamada . Un dispositivo de cliente, el cual actualmente está conectado a uno o más dispositivos de cliente diferentes a través de una llamada de circuito conmutado de audio solamente, recibe entrada desde un usuario para cambiar de la llamada de circuito conmutado de audio solamente a la videollamada. Un mensaje de invitación de videollamada es transmitido a los otros dispositivos de cliente. Los usuarios en los dispositivos de cliente que reciben el mensaje de invitación de videollamada pueden seleccionar si aceptan o rechazan el mensaje. Si la invitación de videollamada es aceptada, un mensaje de aceptación de videollamada es transmitido al dispositivo de cliente origen. Después de aceptar la invitación de videollamada, los dispositivos de cliente que participan en la llama de circuito conmutado establecen una conexión par-a-par (P2P) . Después que se establece la conexión P2P, los dispositivos de cliente comienzan a transmitir y recibir video sobre la conexión P2P. Después que cada uno de los dispositivos de cliente ha recibido al menos un cuadro, los dispositivos de cliente cambian de la llamada de circuito conmutado de audio solamente a la videollamada, incluyendo el despliegue del video gue está siendo recibido y cambiando la ruta del audio de la llamada de circuito conmutado a la videollamada. Después de cambiar a la videollamada, la llamada de circuito conmutado de audio solamente se corta.

BREVE DESCRIPCION DE LAS FIGURAS La invención se puede entender mejor por referencia a la siguiente descripción y los dibujos acompañantes que se utilizan para ilustrar modalidades de la invención. En los dibu os : La figura 1 es un diagrama de flujo de datos que ilustra el registro de un dispositivo de cliente para sesiones de comunicación en linea de acuerdo con una modalidad; La figura 2 es un diagrama en bloques que ilustra el dispositivo de cliente de la figura 1 con más detalle de acuerdo con una modalidad; La figura 3 es un diagrama de bloques que ilustra el servidor de registro de la figura 1 con mayor detalle de acuerdo con una modalidad; La figura 4 es un diagrama de flujo que ilustra operaciones ejemplares para el registro de un dispositivo de cliente para sesiones de comunicación en linea de acuerdo con una modalidad; La figura 5 ilustra un almacenamiento de datos de registro ejemplar de acuerdo con una modalidad; La figura 6 ilustra una topología de red general de una modalidad; La figura 7 es un diagrama de flujo de datos que ilustra el establecimiento de una sesión de comunicación en linea entre dispositivos de cliente de acuerdo con una modalidad; La figura 8 es un diagrama de bloques que ilustra un servicio de retransmisión ejemplar de acuerdo con una modalidad; La figura 9 ilustra una modalidad de una arquitectura API de acuerdo con una modalidad; La figura 10 ilustra un almacenamiento de datos de registro ejemplar de acuerdo con una modalidad; La figura 11 ilustra una tabla de compatibilidad NAT ejemplar de acuerdo con una modalidad; La figura 12 ilustra un dispositivo de cliente ejemplar y una interfaz de usuario gráfica que se utiliza para cambiar entre llamadas de circuito conmutado y videollamadas de acuerdo con algunas modalidades; La figura 13 ilustra el dispositivo de cliente de la figura 12 desplegando una vista previa del video de acuerdo con una modalidad; La figura 14 ilustra un dispositivo de cliente ejemplar e interfaz de usuario gráfica que se utiliza para aceptar o rechazar invitaciones de videollamada de acuerdo con una modalidad; Las figuras 15 y 16 ilustran dispositivos de cliente después de cambiar a una videollamada de acuerdo con una modalidad; Las figuras 17 y 18 son diagramas de flujo que ilustran operaciones ejemplares para cambiar entre una llamada telefónica de circuito conmutado de audio solamente a una videollamada de acuerdo con una modalidad; La figura 19 es un diagrama de flujo que ilustra operaciones ejemplares ejecutadas en un dispositivo de cliente que ha recibido un mensaje de rechazo de videollamada de acuerdo con una modalidad; La figura 20 es un diagrama de flujo que ilustra operaciones ejemplares ejecutadas en un dispositivo de cliente para cambiar de una videollamada a una llamada de circuito conmutado de acuerdo con una modalidad; La figura 21 ilustra una topología de red general utilizada para registrar un dispositivo de cliente para sesiones de comunicación en línea utilizando una dirección de correo electrónico como un identificador de punto final de la sesión de comunicación en línea de acuerdo con una modalidad; Las figuras 22A-B son diagramas de flujo que ilustran operaciones ejemplares para el registro de una dirección de correo electrónico como un identificador de punto final de la sesión de comunicación en línea de acuerdo con una modalidad; La figura 23 es un diagrama de flujo que ilustra operaciones ejemplares para un usuario que proporciona información de inicialización para registro de una dirección de correo electrónico como un identificador de punto final de la sesión de comunicación en línea de acuerdo con una modalidad; La figura 24 ilustra operaciones ejemplares para validar una dirección de correo electrónico de acuerdo con una modalidad; La figura 25 es un diagrama de flujo que ilustra operaciones ejemplares ejecutadas en un servicio de registro cuando una dirección de correo electrónico ha sido validada de acuerdo con una modalidad; La figura 26 es un diagrama de flujo de datos que ilustra operaciones ejemplares para administrar invitaciones cuando un usuario tiene múltiples dispositivos de cliente que están asociados con el mismo identificador de punto final de la sesión de comunicación en línea de acuerdo con una modalidad; La figura 27 es un diagrama de flujo de datos que ilustra operaciones ejemplares que son ejecutadas cuando es viable una conexión P2P directa de acuerdo con una modalidad; La figura 28 es un diagrama de flujo de datos que ilustra operaciones ejemplares que son ejecutadas cuando no es viable una conexión P2P directa de acuerdo con una modalidad; La figura 29 es un diagrama de flujo de datos que ilustra operaciones ejemplares ejecutadas cuando finaliza una sesión de comunicación en línea de acuerdo con una modalidad; La figura 30 es un diagrama de flujo que ilustra operaciones ejemplares ejecutadas 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 modalidad; La figura 31 es un diagrama de flujo que ilustra operaciones ejemplares para iniciar y establecer una sesión de comunicación en línea con múltiples usuarios de acuerdo con una modalidad; La figura 32 es un diagrama de bloques que ilustra un dispositivo de computación del cliente conectándose en interfaz con una unidad manos libres de acuerdo con una modalidad; La figura 33 ilustra un dispositivo de computación del cliente recibiendo una invitación para una videollamada, ocasionando que un dispositivo manos libres suene, recibiendo una indicación de respuesta desde el dispositivo manos libres, estableciendo la videollamada, y enrutando el audio al dispositivo manos libres de acuerdo con una modalidad; La figura 34 ilustra un dispositivo de computación del cliente iniciando una videollamada y enrutando el audio para la videollamada establecida a través de un dispositivo manos libres de acuerdo con una modalidad; La figura 35 ilustra un dispositivo de computación del cliente iniciando una videollamada que responde a la recepción de una solicitud de llamada desde un dispositivo manos libres de acuerdo con una modalidad; La figura 36 ilustra un dispositivo de computación del cliente enrutando audio de una videollamada establecida a un dispositivo manos libres de acuerdo con una modalidad; La figura 37 ilustra un dispositivo de computación del cliente terminando una videollamada en respuesta a la recepción de una solicitud de finalizar llamada desde un dispositivo manos libres de acuerdo con una modalidad; La figura 38 es un diagrama de bloques que ilustra un sistema de computadora ejemplar que puede ser utilizado en algunas modalidades; y La figura 39 es un diagrama de bloques que ilustra un sistema de procesamiento de datos ejemplar el cual puede ser utilizado en algunas modalidades.

DESCRIPCION DETALLADA DE LA INVENCION En la siguiente descripción se establecen numerosos detalles específicos. Sin embargo, se entenderá que modalidades de la invención pueden ser practicadas sin estos detalles específicos. En otros casos, circuitos bien conocidos, estructuras y técnicas no se han mostrado a detalle para no obscurecer el entendimiento de esta descripción. Aquellos expertos en la técnica, con las descripciones incluidas, podrán implementar la funcionalidad apropiada sin una experimentación indebida.

Las referencias en la especificación a "una modalidad", "la modalidad", "una modalidad ejemplar", etcétera, indican que la modalidad descrita pueden incluir una característica, estructura o función particular, pero cada modalidad puede no necesariamente incluir la característica, estructura o función particular. Además, dichas frases no necesariamente se refieren a la misma modalidad. Además, cuando una función, estructura o característica se describe en relación con una modalidad, se está admitiendo que está dentro del conocimiento de un experto en la técnica efectuar dicha función, estructura o característica en conexión con otras modalidades que hayan sido o no descritas de forma explícita.

En la siguiente descripción y reivindicaciones, se pueden utilizar los términos "acoplado" y "conectado", junto con sus derivados. Se debiera entender que estos términos no están destinados como sinónimos entre sí. "Acoplado" se utiliza para indicar que dos o más elementos, los cuales pueden o no estar en contacto físico o eléctrico directo entre sí, cooperan o interactúan entre sí. "Conectado" se utiliza para indicar el establecimiento de la 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 Se describe un método y aparato para registro automático de un dispositivo de computación de cliente ("dispositivo de cliente") (por ejemplo, una estación de trabajo, una laptop, una palmtop, un teléfono móvil, un teléfono inteligente, un teléfono multimedia, una tableta, un reproductor de medios portátil, una unidad GPS, un sistema de juego, etcétera) para sesiones de comunicación en linea (por ejemplo, videoconferencia P2P, mensajería instantánea P2P, etcétera) . En una modalidad, al momento de un evento en un dispositivo de computación (por ejemplo, el encendido del dispositivo de computación) , el dispositivo de cliente automáticamente comienza 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 (servicio de mensaje corto) con un componente léxico de identificación (por ejemplo, su componente léxico de empuje) y un identificador de dispositivo de cliente a un dispositivo de tránsito SMS (por ejemplo, una compuerta SMS o un agregador SMS) . El componente léxico de identificación identifica de manera única un dispositivo de cliente para mensajes de sesión de comunicación en línea (por ejemplo, solicitud de invitación y mensajes de aceptar invitación) , y en una modalidad, es un componente léxico de empuje que puede contener información que permite que un servicio de notificación de empuje localice el dispositivo de cliente. El componente léxico de identificación en la modalidad de servicio de notificación de empuje también se utiliza como una forma de establecer confianza respecto a que una notificación particular es legitima. En otras modalidades, cualquier registro o mapeo de dispositivos de cliente a componentes léxicos únicos puede ser utilizado para asociar componentes léxicos de identificación con dispositivos de cliente y para proporcionar un método confiable para asociar la identidad del dispositivo de cliente con un componente léxico identificado de manera única. El identificador de dispositivo identifica de manera única al dispositivo de cliente y típicamente está basado en uno o más identificadores de hardware (por ejemplo, un número de serie del dispositivo, un ICC-ID (ID de tarjeta de circuito integrado) de una tarjeta SIM (módulo de identidad de suscriptor) , etcétera) .

El dispositivo de tránsito SMS determina el número de teléfono del dispositivo de cliente (por ejemplo, examinando el encabezado del mensaje SMS) y transmite un mensaje IP (protocolo de Internet) a un servidor de registro con el componente léxico de identificación, identificador de dispositivo, y el número de teléfono. El servidor de registro genera una firma basada en el componente léxico de identificación, el identificador de dispositivo y el número de teléfono, y transmite estos al dispositivo de tránsito SMS para entrega al dispositivo de cliente. El dispositivo de tránsito SMS transmite un mensaje SMS al dispositivo de cliente incluyendo la firma y el número de teléfono. El dispositivo de cliente entonces transmite un mensaje IP al servidor de registro con la firma, identificador de dispositivo, componente léxico de identificación y número de teléfono .

El servidor de registro valida la información del dispositivo de cliente y almacena una asociación entre el componente léxico de identificación y el número de teléfono en un almacenamiento de datos de registro de la sesión de comunicación en linea. Juntos, el par asociado del componente léxico de identificación y el número de teléfono identifican de manera única al dispositivo en una red de sesión de comunicación en linea. Después 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 linea (por ejemplo, video charla/sesión de conferencia, sesión de mensajería instantánea, etcétera). En una modalidad, el número de teléfono de un dispositivo de cliente es utilizado como el identificador de punto final de la sesión de comunicación en linea de una sesión de comunicación en linea. ? manera de ejemplo, un usuario, en un dispositivo de cliente, puede invitar a otros usuarios en otros dispositivos de cliente a participar en una sesión de comunicación en linea utilizando sus números de teléfono. En algunas modalidades, 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 ilustra el registro de un dispositivo de cliente para sesiones de comunicación en linea de acuerdo con una modalidad. La figura 1 incluye el dispositivo de cliente 110, la red SMS 120, el servidor de registro 140, y el almacenamiento de datos de mensajería IP 150. El dispositivo de cliente 110 (por ejemplo, una estación de trabajo, una laptop, una palmtop, un teléfono de computación, un teléfono inteligente, un teléfono multimedia, una tableta, un reproductor de medios portátil, una unidad GPS, un sistema de juegos, etcétera) incluye el componente léxico de identificación 115 (el cual puede ser un componente léxico de empuje en una modalidad) . El componente léxico ' de identificación 15 identifica de manera única al dispositivo de cliente 110 para recibir mensajes de solicitud de invitación y aceptación (o negación) de invitación, los cuales se describirán con mayor detalle más adelante. El identificador de dispositivo 117 identifica de manera única al dispositivo de cliente y típicamente está basado en uno o más identificadores de hardware (por ejemplo, un número de serie del dispositivo, un ICC-ID (ID de Tarjeta de Circuito Integrado) de una tarjeta SIM (Módulo de Identidad del Suscriptor) , etcétera) . El dispositivo de cliente 110 incluye la capacidad para transmitir y recibir mensajes SMS así como la capacidad para conectar 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. Aunque en una modalidad el identificador de punto final de sesión de comunicación en línea es un número de teléfono del dispositivo de cliente 110, en otras modalidades el identificador de punto final de sesión de comunicación en línea es un identificador diferente (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 MAC, u otro identificador) .

La red SMS 120, la cual incluye el SMSC del operador (centro de servicio de mensajes cortos) 125 y el dispositivo de tránsito SMS 130 (por ejemplo, una compuerta SMS o un agregador SMS) . El SMSC de operador 125 es especifico del operador de computación y recibe y entrega mensajes SMS. Por ejemplo, el SMSC de operador 125 entrega mensajes SMS enviados desde el dispositivo de cliente 110 al dispositivo de tránsito SMS 130, y entrega mensajes SMS enviados desde el dispositivo de tránsito SMS 130 al dispositivo de cliente 110. El dispositivo de tránsito SMS 130 separa la red móvil y la red IP.

El servidor de registro 140 registra los dispositivos de cliente tal como el dispositivo de cliente 110 para sesiones de comunicación en linea. El registro de un dispositivo de cliente para sesiones de comunicación en línea incluye asociar un componente léxico de identificación de un dispositivo con el 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 componentes léxicos de identificación e identificadores de punto final de sesión de comunicación en línea son almacenadas en el almacenamiento de datos del registro de sesión de comunicación en línea 150.

Al momento en que ocurre un evento en el dispositivo de cliente 110 (por ejemplo, el encendido del dispositivo de cliente, un lanzamiento de aplicación de sesión de comunicación en linea (por ejemplo, una aplicación de videoconferencia P2P, una aplicación de mensaje instantáneo P2P, etcétera), el dispositivo de cliente 110 comienza un proceso de registro para sesiones de comunicación en linea. En una modalidad, el proceso de registro comienza automáticamente (sin interacción del usuario) mientras que en otras modalidades el proceso de registro comienza después que un usuario selecciona registrar el dispositivo de cliente para sesiones de comunicación en linea.

En modalidades donde el número de teléfono del dispositivo de cliente 110 es utilizado como el identificador de punto final de la sesión de comunicación en linea, y por lo tanto va a ser asociado con el componente léxico de identificación 115 del dispositivo de cliente 110 en el almacenamiento de datos de registro 150, el número de teléfono del dispositivo de cliente 110 debe ser determinado. Debido a que el dispositivo de cliente 110 no conoce de origen su propio número de teléfono, en -algunas modalidades 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 su componente léxico de identificación 115 y el identificador de dispositivo 117 al dispositivo de tránsito SMS 130 a través del SMSC de operador 125. En algunas modalidades, el mensaje SMS es direccionado a un número de teléfono, el cual puede ser un número de longitud estándar o un código corto (un tipo de número de teléfono que por lo regular es significativamente más corto que un número de teléfono completo) , que es específicamente establecido para el registro de la sesión de comunicación en linea. El número de teléfono al que está dirigido el mensaje SMS es almacenado en el dispositivo de cliente (por ejemplo, en un paquete de configuración del operador) .

El SMSC del operador 125 recibe el mensaje SMS y lo entrega al dispositivo de tránsito SMS 130. El dispositivo de tránsito 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 SMS 130 examina el encabezado 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 SMS 130 transmite un mensaje IP al servidor de registro 140 con el número de teléfono del dispositivo de cliente 110, el componente léxico de identificación 115, y el identificador de dispositivo 117. Esto en ocasiones se refiere como un mensaje de solicitud de registro .

El servidor de registro 140 recibe el mensaje IP desde el dispositivo de tránsito SMS incluyendo el número de teléfono del dispositivo de cliente 110, el componente léxico de identificación 115, y el identificador de dispositivo 117, y crea una firma. La firma puede estar basada en el número de teléfono del dispositivo de cliente 110, el componente léxico de identificación 115 y/o el identificador de dispositivo 117, y se utiliza para propósitos de validación (los cuales se describirán con mayor detalle a continuación en este documento) . En algunas modalidades, también se utiliza un número aleatorio cuando se genera la firma para consideración en situaciones donde múltiples dispositivos de cliente tienen el mismo número de teléfono. El servidor de registro 140 transmite la firma, número de teléfono, identificador de dispositivo, y el componente léxico de regreso al dispositivo de tránsito SMS 130 en la operación 5 (por ejemplo, en un mensaje IP) . Esto en ocasiones se refiere como un mensaje de respuesta de registro.

El dispositivo de tránsito SMS 130 recibe la firma, número de teléfono, identificador de dispositivo, y componente léxico desde el servidor de registro 140 y genera un mensaje SMS con la firma y número de teléfono para el dispositivo de cliente 110. El dispositivo de tránsito SMS 130 transmite el mensaje SMS al dispositivo de cliente 110 con la firma y número de teléfono en la operación 6 (a través del SMSC del operador 125) .

El dispositivo de cliente 110 recibe y procesa el mensaje SMS incluyendo el almacenamiento de su número de teléfono. El dispositivo de cliente 110 transmite un mensaje IP con su componente léxico de identificación 115, identificador de dispositivo 117, su número de teléfono, y la firma generada por el servidor de registro al servidor de registro 140 en la operación 7. Esto en ocasiones se refiere como un mensaje de solicitud de validación de registro.

Utilizando la firma, el servidor de registro 140 valida los datos enviados por el dispositivo de cliente 110. Por ejemplo, el servidor de registro 140 compara la firma enviada por el dispositivo de cliente 110 con la firma generada durante la operación 4. Si coinciden, entonces los datos son validados. Asumiendo que los datos son válidos, el servidor de registro 140 almacena una asociación entre el componente léxico de identificación 115 y el número de teléfono del dispositivo de cliente 110 en el almacenamiento de datos de registro de la sesión de comunicación en linea 150.

En una modalidad alternativa, en lugar de determinar el número de teléfono del dispositivo de cliente 110 a través de la transmisión de mensajes SMS, al usuario del dispositivo se le solicita que ingrese el número de teléfono del dispositivo de cliente 110. En estas modalidades, el dispositivo de cliente 110 transmite directamente el número de teléfono del dispositivo de cliente 110 (como entrada por parte del usuario) y su componente léxico de identificación 115 al servidor de registro 140, el cual puede asociarlos en el almacenamiento de datos de registro de la sesión de comunicación en linea 150.

La figura 5 ilustra un almacenamiento de datos de registro ejemplar 150 de acuerdo con una modalidad. Tal como se ilustra en la figura 5, cada uno de los registros de identificador de la sesión de comunicación en linea 510 incluye un campo de componente léxico de identificación 520 y un campo de número de teléfono 525. En algunas situaciones, es posible que un solo número de teléfono sea asociado con múltiples componente léxicos de identificación. Por ejemplo, diferentes dispositivos de cliente pueden tener el mismo número de teléfono. En estos casos, estos dispositivos de cliente diferentes tendrían diferentes componentes léxicos de identificación. Por lo tanto, cuando una invitación de sesión de comunicación en línea es enviada para un número de teléfono asociado con múltiples componente léxicos de identificación, una invitación será transmitida a cada dispositivo asociado con el componente léxico de identificación .

La figura 2 es un diagrama en bloques que ilustra el dispositivo de cliente 110 con mayor detalle de acuerdo con una modalidad. La figura 2 será descrita con referencia a la modalidad ejemplar de la figura 4, la cual es un diagrama de flujo que ilustra operaciones ejemplares para el registro de un dispositivo de cliente para sesiones de comunicación en línea. Sin embargo, se debiera entender que las operaciones de la figura 4 pueden ser ejecutadas mediante modalidades diferentes a aquéllas analizadas con referencia a la figura 2, y las modalidades analizadas con referencia a la figura 2 pueden ejecutar operaciones diferentes a aquéllas analizadas con referencia a la figura 4.

Tal como se ilustra en la figura 2, el dispositivo de cliente 110 incluye el módulo de registro de la sesión de comunicación en línea del cliente ("módulo de registro de cliente") 210, los paquetes de configuración de operador 215, el componente léxico de empuje 115, el identificador de dispositivo 117, el módulo SMS 220, y el almacenamiento de datos de registro de la sesión de comunicación en linea del cliente ("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 linea. Los paquetes de configuración de operador 215 incluyen configuraciones especificas para un operador incluyendo el número de teléfono para el dispositivo de tránsito SMS utilizado para registro (por ejemplo, el número para el dispositivo de tránsito SMS 130) y otras configuraciones (por ejemplo, configuraciones de Nombre de Punto de Acceso (APN) , configuraciones de servicio de mensajería multimedia (MMS) , etcétera) . El módulo SMS 220 transmite y recibe mensajes SMS. El almacenamiento de datos de registro de cliente 230 almacena datos relacionados con el registro de la sesión de comunicación en línea (por ejemplo, el 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 dispara el registro de la sesión de comunicación en línea. Ejemplos de dichos eventos incluyen el encendido del dispositivo de cliente 110, un usuario que abre una aplicación de comunicación en linea (por ejemplo, una aplicación de videoconferencia P2P, una aplicación de mensajería instantánea P2P, etcétera), etcétera. En algunas modalidades, el proceso de registro es ejecutado cada vez que el dispositivo de cliente 410 se enciende, mientras que en otras modalidades el proceso de registro es ejecutado la primera vez que el dispositivo de cliente 110 es encendido. El flujo se mueve del bloque 410 al bloque 415.

En el bloque 415 el módulo de registro de cliente 210 determina si hay un componente léxico de identificación válido para el dispositivo de cliente 110. Si no hay un componente léxico de identificación, o el componente léxico de identificación ha expirado, entonces el flujo se mueve al bloque 425 donde se emprende una acción alternativa. Por ejemplo, en modalidades que utilizan componentes léxicos de empuje, el dispositivo de cliente 110 puede iniciar un procedimiento de generación de componente léxico solicitando que un componente léxico de empuje sea generado por un servicio de notificación de empuje (el cual típicamente está lejos del dispositivo de cliente 110) . El servicio de notificación de empuje genera un componente léxico de empuje específico para el dispositivo de cliente 110 y lo regresa al dispositivo de cliente 110. Si hay un componente léxico de identificación válido, entonces el flujo se mueve al bloque 420 donde el módulo de registro de cliente 210 tiene acceso al componente léxico de identificación 115. El flujo se mueve del bloque 420 al bloque 428.

En el bloque 428, el módulo de registro de cliente 210 tiene acceso al identificador de dispositivo 117. El flujo entonces se mueve al bloque 430, donde el módulo de registro de cliente 210 determina el número de teléfono para el dispositivo de tránsito SMS utilizado en el proceso de registro. Por ejemplo, el módulo de registro de cliente 210 tiene acceso al grupo del operador 215 para determinar el número de teléfono del dispositivo de tránsito SMS. El número de teléfono puede ser un código corto 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 SMS 130. El flujo se mueve del bloque 430 al bloque 435.

En el bloque 435, un mensaje SMS que tiene el componente léxico de identificación 115 y el identificador de dispositivo 117 es transmitido al número determinado (el dispositivo de tránsito SMS 130) . Por ejemplo, el módulo de registro de cliente 210 solicita al módulo SMS 220 transmitir un mensaje SMS con el componente léxico de identificación 115 y el identificador de dispositivo 117 al número determinado. El módulo SMS 220 transmite el mensaje SMS con el componente léxico de identificación al número determinado. El flujo se mueve del bloque 435 al bloque 440. El mensaje SMS será recibido por el SMSC del operador 125, el cual lo entrega al dispositivo de tránsito SMS 130.

En el bloque 440, el dispositivo de tránsito SMS 130 determina el número de teléfono del dispositivo de cliente 110 con base en el mensaje SMS recibido. Por ejemplo, el dispositivo de tránsito SMS examina el encabezado del mensaje SMS, el cual incluirá el número de teléfono del remitente, que en este caso es el dispositivo de cliente 110. El flujo entonces se mueve al bloque 445 donde el dispositivo de tránsito SMS 130 transmite el número de teléfono del dispositivo de cliente 110, el componente léxico de identificación 115, y el identificador de dispositivo 117 al servidor de registro 140 (por ejemplo, en un mensaje IP seguro). El flujo se mueve del bloque 445 al bloque 450.

La figura 3 es un diagrama de bloques que ilustra el servidor de registro 140 con mayor detalle de acuerdo con una modalidad. La figura 3 se describirá con referencia a la modalidad ejemplar de la figura 4. Sin embargo, se debiera entender que las operaciones de la figura 4 pueden ser ejecutadas por modalidades diferentes a aquéllas analizadas con referencia a la figura 3, y las modalidades analizadas con referencia a la figura 3 pueden ejecutar operaciones diferentes a aquéllas analizadas con referencia a la figura 4. Tal como se ilustra en la figura 3, el servidor de registro 140 incluye el módulo de registro de sesión de comunicación en linea 305, el cual incluye la interfaz de tránsito SMS 310, el generador de firma 315, la interfaz de dispositivo 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. La interfaz de tránsito SMS 310 recibe y envía mensajes al dispositivo de tránsito SMS 130. Por ejemplo, la interfaz de tránsito SMS 310 recibe el número de teléfono, componente léxico ,de identificación, y tupias de identificador de dispositivo de la interfaz de tránsito SMS 310, y transmite el número de teléfono, componente léxico de identificación, identificador de dispositivo y tupias de firma (en ocasiones referidos como "tupias de validación") a la interfaz de tránsito SMS 310. La interfaz de dispositivo de cliente 325 recibe y puede transmitir mensajes a los dispositivos de cliente. Por ejemplo, la interfaz de dispositivo de cliente 325 recibe tupias de validación desde los dispositivos de cliente.

Haciendo referencia nuevamente a la figura 4, en el bloque 450, el generador de firma 310 genera una firma para el número de teléfono, componente léxico de identificación y tupia de identificador de dispositivo que recibió desde el dispositivo de tránsito SMS 130. La firma será utilizada para validar el par del número de teléfono y el componente léxico de identificación antes de almacenar el par en el almacenamiento de datos de registro 150. En algunas modalidades, la firma está basada en el número de teléfono, componente léxico de identificación y/o identificador de dispositivo (por ejemplo, una función Hash criptográfica es aplicada al número de teléfono, componente léxico de identificación, y/o identificador de dispositivo, o alguna porción del mismo, para generar la firma) . En algunas modalidades, la firma también está basada en un número aleatorio para que se considere en situaciones donde múltiples dispositivos de cliente tienen el mismo número de teléfono. El generador de firma 310 almacena la firma y opcionalmente el número de teléfono, componente léxico de identificación y/o identificador de dispositivo en el almacenamiento de datos de validación 325. El flujo entonces se mueve al bloque 455, donde la interfaz de tránsito SMS 310 transmite la firma, número de teléfono, identificador de dispositivo, y componente léxico de identificación al dispositivo de tránsito SMS 130. El flujo se mueve del bloque 455 al bloque 460.

El dispositivo de tránsito SMS 130 recibe la firma, número de teléfono y componente léxico de identificación desde el servidor de registro 140. En el bloque 460, el dispositivo de tránsito SMS transmite un mensaje SMS (a través del SMSC de operador 125) con la firma y número de teléfono para el dispositivo de cliente 110. El flujo a continuación se mueve al bloque 465.

En el bloque 465, el módulo SMS 220 recibe el mensaje SMS con la firma y el número de teléfono y almacena la firma y el número de teléfono en el almacenamiento de datos de registro de cliente 230. El flujo entonces se mueve al bloque 470, donde el módulo de registro de cliente 210 transmite un mensaje IP al servidor de registro con su número de teléfono, componente léxico de identificación 115, identificador de dispositivo 117 y firma. El flujo entonces se mueve al bloque 475.

La interfaz de dispositivo de cliente 325 recibe el número de teléfono, componente léxico de identificación, identificador de dispositivo, y firma desde el 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 Hash, tal como es aplicada cuando genera la firma, es utilizada en el número de teléfono, componente léxico de identificación y/o identificador de dispositivo recibido desde el dispositivo de cliente, y el módulo de validación 330 compara el resultado con la firma que fue previamente generada (almacenada en el almacenamiento de datos de validación 335) . Si las firmas coinciden, entonces los datos son válidos y el flujo se mueve 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 componente léxico de identificación del dispositivo de cliente en el almacenamiento de datos de registro 150. En algunas modalidades, el servidor de registro 140 puede transmitir un mensaje de estatus de registro al dispositivo de cliente 110 alertando al dispositivo de cliente 110 si el registro fue exitoso .

Después 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 linea (por ejemplo, video charla/sesión de conferencia, sesión de mensajería instantánea, etcétera) . A manera de ejemplo, un usuario en un dispositivo de cliente puede invitar a otros usuarios en otros dispositivos de cliente a participar en una sesión de comunicación en línea utilizando sus números de teléfono. En algunas modalidades, el dispositivo de cliente no conoce de origen su propio número de teléfono. Aunque las modalidades han descrito el uso de mensajes SMS durante el registro, en otras modalidades se pueden utilizar otros tipos de mensajería de texto (por ejemplo, MMS (Servicio de Mensajería Multimedia)).

Registro de direcciones de correo electrónico para sesiones de comunicación en línea Mientras la figura 1 se describió en relación al registro de un número de teléfono como un identificador de punto final de la sesión de comunicación en línea, en otras modalidades se utiliza una dirección de correo electrónico como un identificador de punto final de la sesión de comunicación en línea. La figura 21 ilustra una topología de red general utilizada para registrar un dispositivo de cliente para sesiones de comunicación en línea utilizando una dirección de correo electrónico como un identificador de punto final de la sesión de comunicación en linea. Los dispositivos de cliente 2110A-N utilizan el servidor de registro 2130 para registrar sesiones de comunicación en linea. Por ejemplo, en una modalidad, el usuario de un dispositivo de cliente 2110A utiliza el cliente de la sesión de comunicación en linea 2115 para registrar una dirección de correo electrónico para uso como un identificador de sesión de comunicación en linea para comunicaciones en linea sobre la red 2180 (por ejemplo, la Internet) .

Las figuras 22A-B son diagramas de flujo que ilustran operaciones ejemplares para registrar una dirección de correo electrónico como un identificador de punto final de la sesión de comunicación en linea de acuerdo con una modalidad. Las figuras 22A-B serán descritas con referencia a la modalidad ejemplar ilustrada en la figura 21. Sin embargo, se debiera entender que las operaciones de las figuras 22A-B pueden ser ejecutadas por modalidades diferentes a aquéllas analizadas con referencia a la figura 21, y las modalidades analizadas con referencia a la figura 21 pueden ejecutar operaciones diferentes a aquéllas analizadas con referencia a las figuras 22A-B.

En la operación 2210, el servidor de registro 2130 recibe una solicitud de autenticación desde el dispositivo de cliente 2110A. Por ejemplo, con referencia a la figura 23, la cual describe operaciones ejemplares para un usuario que proporciona información de inicialización, en la operación 2310, la aplicación de sesión de comunicación en linea 2115 es iniciada en el dispositivo de cliente 2110A. El flujo entonces se mueve a la operación 2315 y el dispositivo de cliente 2110A recibe la entrada desde el usuario incluyendo un ID de usuario y contraseña y una o más direcciones de correo electrónico a registrar para uso como identificadores de punto final de sesión de comunicación en línea. El flujo entonces se mueve a la operación 2320 y el dispositivo de cliente 2110A transmite el ID de usuario y contraseña al servicio de registro 2130.

Aunque el dispositivo de cliente 2110A está registrando una dirección de correo electrónico como un identificador de punto final de la sesión de comunicación en linea y puede no incluir funcionalidad de teléfono, éste puede enviar una invitación de sesión de comunicación en linea utilizando un número de teléfono en lugar de una dirección de correo electrónico. Además de recibir un ID de usuario, contraseña y una o más direcciones de correo electrónico a registrar, en algunas modalidades el usuario también puede proporcionar información referente al país y/o región en el que se encuentran ubicados actualmente de manera que se puede utilizar un código de país y/o código de región correspondiente en caso que el usuario inicie una sesión de comunicación en línea para un número de teléfono que no incluye un código de país y/o código de región. Por ejemplo, en los Estados Unidos, se puede colocar una llamada de teléfono local utilizando 7 dígitos (por lo tanto, el código de país y código de área no son requeridos) . El sistema telefónico subyacente automáticamente determina el código de país y área y completa la llamada. Sin embargo, en casos donde el dispositivo de cliente 2110A no incluye funcionalidad de teléfono, el dispositivo de cliente 2110A no se puede basar en el sistema telefónico subyacente para incluir automáticamente el código de país y/o código de región cuando se invita 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 código de región.

En la operación 2320, el dispositivo de cliente 2110A recibe la entrada desde el usuario con referencia al país y/o región (por ejemplo, código de área, estado, provincia, ciudad, etcétera) en la cual se encuentra. El flujo entonces se mueve a la operación 2320 donde el dispositivo de cliente 2320 asocia los códigos de teléfono del país y/o región correspondientes con la aplicación de sesión de comunicación en línea 2115 para uso en caso que el usuario inicie una sesión de comunicación en línea para un número de teléfono que no incluye un código de país y/o código de región. Por ejemplo, si el usuario indica que están ubicados en los Estados Unidos 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 2110A automáticamente añade el código de país para los Estados Unidos al número de teléfono .

Con referencia nuevamente a la figura 22A, después de recibir la solicitud de autenticación desde el dispositivo de cliente 2110A, se ejecuta un proceso de autenticación utilizando el nombre de usuario y contraseña proporcionados. En una modalidad, el servicio de registro 2130 ejecuta el proceso de autenticación mientras que en otra modalidad el servicio de directorio de usuario 2160 ejecuta el proceso de autenticación. El servicio de directorio de usuario 2160 es un servicio centralizado que proporciona cuenta de usuario, autenticación y otros servicios. El servicio de directorio de usuario 2160 administra los registros de usuario 2165. En una modalidad, cada usuario autenticado es asociado con un registro de usuario que incluye diversa información (por ejemplo, uno o más de un ID de usuario, contraseña, dirección de correo, número de teléfono, nombre, cumpleaños, país, una lista de correos electrónicos asociados con el usuario (lo cual puede también indicar si la dirección de correo electrónico es validada), etcétera). Si la autenticación es exitosa, entonces el flujo se mueve a la operación 2216. Si la autenticación falla, entonces el flujo se mueve a la operación 2214 y se emprende 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 de usuario y/o contraseña no es correcto) .

En la operación 2216, el servicio de registro 2130 genera y/o tiene acceso a un perfil de sesión de comunicación en linea asociado con el ID de usuario. Por ejemplo, el servidor de registro 2130 puede incluir un servidor de cuenta de sesión de comunicación en linea 2140 que administra los registros de perfil de sesión de comunicación en linea 2150. En una modalidad, cada usuario que se está registrando o está registrado para sesiones de comunicación en línea tiene un registro de perfil de sesión de comunicación en linea correspondiente. Cada registro de perfil de sesión de comunicación en línea puede incluir un conjunto de una o más direcciones de correo electrónico, incluyendo su estatus de validación, que están asociadas con el perfil. Cada registro de perfil de sesión de comunicación en linea también puede incluir uno o más componentes léxicos de empuje que correspondan a uno o más dispositivos de cliente respectivamente que están registrados para sesiones de comunicación en línea. Cada registro de perfil también puede incluir credenciales de perfil que son utilizadas para validar algunas comunicaciones de los dispositivos de cliente. Cada registro de perfil también puede indicar cuáles dispositivos de cliente (conforme a lo indicado por los componentes léxicos de empuje) han registrado o están intentando registrar direcciones de correo electrónico.

El flujo se mueve de la operación 2216 a la operación 2218 y el servidor de registro 2130 transmite una respuesta de autenticación al dispositivo de cliente 2110A que incluye el ID de perfil (por ejemplo, una secuencia que identifica el perfil asociado con el ID de usuario proporcionado) y las credenciales de perfil. La respuesta de autenticación también puede indicar que la autenticación fue exitosa. El flujo entonces se mueve a la operación 2220 y el servicio de registro 2130 recibe una solicitud de validación de correo electrónico desde el dispositivo de cliente 2110? que incluye una o más direcciones de correo electrónico para validar, ID de perfil, credenciales de perfil, y el componente léxico de empuje del dispositivo de cliente 2110A. El mensaje de solicitud de validación de correo electrónico también puede incluir el ID de dispositivo del dispositivo de cliente 2110A. El servicio de registro 2130 entonces determina si las credenciales de perfil son válidas para el ID de perfil en la operación 2222. En caso de no serlo, entonces el flujo de mueve a la operación 2224 y se emprende una acción alternativa (por ejemplo, el servicio de registro 2130 transmite un mensaje de error al dispositivo de cliente 2110A) . En caso que las credenciales de perfil sean válidas, entonces el flujo se mueve a la operación 2223. En la operación 2223, el servicio de registro 2130 asocia el componente léxico de empuje con el perfil, por ejemplo, el servidor de cuenta de sesión de comunicación en linea 2140 almacena el componente léxico de empuje en el registro de perfil para el usuario.

El flujo entonces se mueve a la operación 2226 y el servidor de registro 2130 determina si la dirección de correo electrónico es validada. 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 sea registrada para uso como un identificador de punto final de sesión de comunicación en linea. El servidor de cuenta de sesión de comunicación en linea 2140 tiene acceso al registro de perfil 2150 del usuario para determinar si la dirección de correo electrónico es validada. Si el registro de perfil no indica que la dirección de correo electrónico está validada, en algunas modalidades el servidor de registro 2130 transmite una solicitud de validación de direcció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 la dirección de correo electrónico está validada. Si la dirección de correo electrónico no está validada, entonces el flujo se mueve a la operación 2227 y el servicio de registro 2130 ocasiona que un mensaje de correo electrónico de validación sea enviado a la dirección de correo electrónico que incluye un enlace que, cuando es seleccionado (o cuando se ingresa en un navegador de Internet) ocasiona que la dirección de correo electrónico sea validada. Por ejemplo, la selección del enlace ocasiona que un mensaje de validación de dirección de correo electrónico sea enviado, mismo que incluye la dirección de correo electrónico y un componente léxico de validación que son utilizados para validar la dirección de correo electrónico.

El servicio de registro 2130 también puede transmitir un mensaje de validación de necesidades de dirección de correo electrónico al dispositivo de cliente que indica que la dirección de correo electrónico no está validada (y por lo tanto, necesita ser validada) y también puede indicar 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 entonces se mueve a la operación 2410, la cual se describirá en referencia a la figura 24. Sin embargo, si la dirección de correo electrónico es validada, entonces el flujo se mueve a la operación 2228.

En la operación 2228, el servidor de registro 2130 transmite un mensaje de éxito de dirección de correo electrónico validada al dispositivo de cliente 2228 que indica que la dirección de correo electrónico ha sido validada. El flujo entonces se mueve a la operación 2230 y el servicio de registro 2130 recibe una solicitud de activar correo electrónico desde el dispositivo de cliente 2228 que incluye la dirección de correo electrónico, ID de perfil, y credenciales de perfil. El servidor de registro 2130 entonces determina si las credenciales de perfil son válidas para el ID de perfil en la operación 2232. En caso que no lo sean, entonces el flujo se mueve a la operación 2224 y se emprende 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 mueve a la operación 2240.

En la operación 2240, el servidor de registro 2130 genera o tiene acceso a las credenciales de correo electrónico para la dirección de correo electrónico. Por ejemplo, en una modalidad, el servidor de cuenta de sesión de comunicación en linea 2140 almacena las credenciales de correo electrónico para cada dirección de correo electrónico validada de un usuario en el registro de perfil 2150 de ese usuario. El flujo entonces se mueve a la operación 2242 y el servidor de registro 2130 transmite un mensaje de éxito de 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 mueve desde la operación 2242 a la operación 2244 y el servidor de registro 2130 recibe un mensaje de solicitud 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 componente léxico de empuje del dispositivo de cliente 2110A, y el ID de dispositivo del dispositivo de cliente 2110A. En una modalidad, el mensaje de solicitud es recibido en el servidor de registro de sesión de comunicación en linea 2145. El servidor de registro de sesión de comunicación en linea administra el almacenamiento de datos de registro de sesión de comunicación en linea 2155. El almacenamiento de datos de registro de sesión de comunicación en linea 2155 asocia un componente léxico de empuje (y opcionalmente el ID de dispositivo) con el perfil que tiene un conjunto de una o más direcciones de correo electrónico como identificadores de punto final de la sesión de comunicación en linea. Por lo tanto, cada registro en el almacenamiento de datos de registro de sesión de comunicación 2155 representa que un dispositivo particular con un componente léxico de empuje particular está utilizando un perfil de sesión de comunicación en linea que tiene una o más direcciones de correo electrónico que pueden ser utilizadas para invitar a un usuario en ese dispositivo a una sesión de comunicación en linea. El flujo se mueve de la operación 2244 a la operación 2246.

En la operación 2246, el servidor de registro 2130 (por ejemplo, el servidor de registro de sesión de comunicación en linea 2145) determina si las credenciales de perfil son válidas. En caso de no ser válidas, entonces el flujo se mueve a la operación 2250 y se emprende una acción alternativa (por ejemplo, el servidor de registro 2130 transmite un mensaje de error al dispositivo de cliente 2110A) . En caso de ser válidas, el flujo se mueve a la operación 2248 y el servidor de registro 2130 (por ejemplo, el servidor de registro de sesión de comunicación en linea 2145) determina si las credenciales de dirección de correo electrónico son válidas. En caso de no serlo, entonces el flujo se mueve a la operación 2250. En caso de ser válidas, entonces el flujo se mueve a la operación 2252.

En la operación 2252, el servidor de registro 2130 (por ejemplo, el servidor de registro de sesión de comunicación en linea 2145) asocia el dispositivo de cliente 2110A con su componente léxico de empuje con el perfil que tiene la dirección de correo electrónico, y almacena la asociación en el almacenamiento de datos de registro 2155. El flujo entonces se mueve a la operación 2254 y el servicio de registro 2130 genera un identificador de cuenta de sesión de comunicación en linea y credenciales de sesión de comunicación en linea y los transmite al dispositivo de cliente 2110A en la operación 2256.

Existen diferentes formas para validar las direcciones de correo electrónico en diferentes modalidades.

Con referencia a la figura 24, la cual es un diagrama de flujo que ilustra operaciones ejemplares 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 tiene una cuenta para una dirección de correo electrónico que ha intentado registrar y no ha recibido un mensaje de correo electrónico de validación positiva. Si este no incluye dicho cliente de correo electrónico, entonces el flujo se mueve a la operación 2240, de otra manera el flujo se mueve a la operación 2415.

En la operación 2415, la cuenta de correo electrónico es automáticamente revisada de forma periódica en busca de 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 modalidad, la aplicación de sesión de comunicación en linea 2115 periódicamente solicita al cliente de correo electrónico 2120 revisar si tiene el mensaje de correo electrónico de validación (el cliente de correo electrónico 2120 puede consultar el servidor de correo electrónico 2170 para revisar si hay un 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 más criterios incluyendo el De: campo, el Para: campo, y un componente léxico de validación (el componente léxico de validación puede ser único para cada dirección de correo electrónico que se esté validando) que es utilizado para validar la dirección de correo electrónico. El componente léxico de validación puede estar ubicado en el encabezado o el cuerpo del mensaje de correo electrónico de validación. Si el mensaje de correo electrónico de validación es recibido, entonces el flujo se mueve de la operación 2420 a la operación 2425, de otra manera el flujo se mueve 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 de sesión de comunicación en linea 2115 y éste analiza sintácticamente el mensaje para ubicar el componente léxico de validación. Después de la localización del componente léxico de validación, la aplicación de sesión de comunicación en linea 2115 transmite un mensaje de validación de dirección de correo electrónico al servicio de registro 2130 con el componente léxico de validación, la dirección de correo electrónico, el ID de perfil y las credenciales de perfil. Por lo tanto, en esta modalidad, la dirección de correo electrónico es validada automáticamente sin requerir que el usuario haga clic en un enlace o de otra manera valide la dirección de correo electrónico. En una modalidad, después de recibir el mensaje y determinar que las credenciales de perfil son válidas, el servicio de registro 2130 transmite un mensaje de empuje de correo electrónico validado (a través del servicio de notificación de empuje 640) al dispositivo que indica que la dirección de correo electrónico ha sido validada con éxito. Por lo tanto, el flujo se mueve de la operación 2425 a la operación 2430 y el dispositivo de cliente 2110A espera a recibir el mensaje de empuje de dirección de correo electrónico validado.

Si un mensaje de correo electrónico de validación no ha sido recibido, entonces el flujo se mueve a la operación 2435 donde el dispositivo de cliente determina si un mensaje de empuje de correo electrónico validado ha sido recibido, mismo que indica que la dirección de correo electrónico que se está intentando registrar ha sido validada. Si dicho mensaje es recibido, entonces el flujo se mueve a la operación 2445, de otra manera el flujo se mueve de regreso a la operación 2415.

En la operación 2440 (el dispositivo de cliente 2110A no incluye un cliente de correo electrónico que incluya una cuenta para la dirección de correo electrónico que se está registrando) , el dispositivo de cliente 2110A espera a recibir un mensaje de empuje de correo electrónico validado, mismo que indica que la dirección de correo electrónico que se está intentando registrar ha sido validada. Si dicho mensaje es recibido, entonces el flujo se mueve a la operación 2445, de otra manera el flujo permanece en la operación 2440.

En la operación 2445, el dispositivo de cliente 2110A despliega que la dirección de correo electrónico ha sido validada y consulta al usuario para continuar con el proceso de registro con esa dirección de correo electrónico. Si el dispositivo de cliente 2110A recibe una entrada que indica continuar con el proceso de registro, entonces el flujo se mueve a la operación 2455 y el dispositivo de cliente 2110A transmite una solicitud 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, comenzando en la operación 2230 de la figura 22, entonces son ejecutadas. Si el dispositivo de cliente 2110A recibe la entrada que indica que el usuario no quiere continuar con el proceso de registro, entonces el flujo se mueve de la operación 2450 a la operación 2460 y se sale del proceso.

La figura 25 es un diagrama de flujo que ilustra operaciones ejemplares ejecutadas en el servicio de registro cuando una dirección de correo electrónico ha sido validada de acuerdo con una modalidad. En la operación 2510, el servicio de registro 2130 recibe un mensaje de estatus validado de dirección de correo electrónico que indica que una dirección de correo electrónico que está asociada con un perfil de sesión de comunicación en linea ha sido validada. El mensaje de estatus validado de dirección de correo electrónico pudiera haber sido recibido como un resultado de la operación 2425, o pudiera haber sido recibido como un resultado de que la dirección de correo electrónico está siendo validada en una manera diferente (por ejemplo, un usuario que hace clic en un enlace de validación en un mensaje de correo electrónico de validación que ocasiona que la dirección de correo electrónico sea validada, la cual puede ser enviada en un dispositivo diferente que el dispositivo que está intentando registrar la dirección de correo electrónico para uso en sesiones de comunicación en linea) .

El flujo entonces se mueve a la operación 2515 y el servicio de registro 2130 actualiza el estado de validación para la dirección de correo electrónico en los registros de perfil 2150. El flujo entonces se mueve a la operación 2515 y el servicio de registro 2130 determina si hay dispositivos de cliente que estén asociados con el perfil de sesión de comunicación en linea que han solicitado validar la dirección de correo electrónico que no han recibido un mensaje de dirección de correo electrónico validado. Por ejemplo, el servicio de registro 2130 tiene acceso al registro de perfil 2150 para el perfil de sesión de comunicación en linea a fin de determinar cuáles dispositivos de cliente (por ejemplo, conforme a lo identificado por los componente léxicos de empuje únicos) han solicitado validar la dirección de correo electrónico y cuáles no han recibido un mensaje de validación de correo electrónico para esa dirección de correo electrónico. Para cada dispositivo de cliente de ese tipo, el servicio de registro transmite un mensaje de empuje de correo electrónico validado a ese dispositivo de cliente que incluye el ID de perfil, credenciales de perfil y la dirección de correo electrónico que ha sido validada en la operación 2525. El mensaje de empuje de correo electrónico validado también puede incluir una actualización de estatus para indicar que la dirección de correo electrónico ha sido validada. Si no hay dispositivos que han solicitado validar la dirección de correo electrónico que no han recibido un mensaje de dirección de correo electrónico validado, entonces el flujo se mueve a la operación 2530 y el proceso finaliza.

Establecimiento de sesiones de comunicación en linea Tal como se ilustra en la figura 6, una topología de red general implementada en una modalidad puede incluir un número de dispositivos de cliente A-N, 670A-N respectivamente, comunicándose entre sí y con uno o más servicios 610, 620, 630, 640 y 650 sobre una red 660. Aunque se ilustra como una sola nube de red, la red 660 puede incluir una variedad de diferentes componente incluyendo redes públicas tales como la Internet y redes privadas tales como redes Wi-Fi locales (por ejemplo, redes inalámbricas residenciales 802.11? o puntos calientes inalámbricos), redes Ethernet de área local, redes de datos celulares (por ejemplo, 3G, 4G, Edge, etcétera) y redes WiMAX, por mencionar unas cuantas. Los dispositivos de cliente 670A-N se pueden conectar a la red 660 sobre diferentes enlaces de red. Por ejemplo, el dispositivo de cliente 670A se puede conectar a una red Wi-Fi residencial representada por el enlace de red 675A y el dispositivo de cliente 670N se puede conectar a una red 3G (por ejemplo, Sistema de Telecomunicaciones Móviles Universales ("UMTS"), Acceso de Paquete de Enlace Ascendente de Alta Velocidad ("HSUPA"), etcétera sobre en enlace de red 675N. Cada uno de los enlaces de red 675A-N sobre los cuales están conectados los dispositivos de cliente 670A-N se pueden acoplar a una red pública tal como la Internet a través de una compuerta y/o dispositivo NAT (Traducción de Dirección de Red) (que no se muestra en la figura 6) , permitiendo asi la comunicación entre los diversos dispositivos de cliente 670A-N sobre la red pública. Sin embargo, si dos dispositivos de cliente están en la misma red local o privada (por ejemplo, la misma red Wi-Fi) , entonces los dos dispositivos se pueden comunicar directamente sobre esa red local /privada , eludiendo la red pública. Por supuesto, se debiera observar que los principios subyacentes de la invención no están limitados a algún conjunto particular de tipos de red o topologías de red .

Cada uno de los dispositivos de cliente 670?-? se 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 de empuje 640, y un servicio de retransmisión 650. En una modalidad, los servicios 610-650 se pueden implementar como software ejecutado a través de uno o más dispositivos de computación físicos tales como servidores.

En una modalidad, el servicio CDX 610 opera como un punto de intercambio central para datos de conexión requeridos para establecer sesiones de comunicación en linea entre dos o más dispositivos de cliente. Específicamente, una modalidad del servicio CDX 610 genera datos NAT Traversal (en ocasiones referidos como datos de "perforación de agujero" en respuesta a las solicitudes del dispositivo de cliente para habilitar servicios externos y que los clientes se comuniquen a través de la NAT de cada dispositivo de cliente (es decir, "perforar un agujero" a través de la NAT para llegar al dispositivo) , por ejemplo, en una modalidad, el servicio CDX detecta la dirección IP externa y el puerto necesarios para comunicarse con el dispositivo de cliente y proporciona esta información al dispositivo de cliente. En una modalidad, el servicio CDX también recibe y procesa listas de dispositivos de cliente generadas por el servicio de invitación 620 y de manera eficiente y segura distribuye datos de conexión a cada uno de los dispositivos de cliente incluidos en las listas (tal como se describe a detalle a continuación) .

Los usuarios de los dispositivos de cliente 670A-N utilizan el servicio de invitación 620 para invitar a los usuarios a participar en sesiones de comunicación en línea colaborativas (por ejemplo, videoconferencia P2P, salas de charla/conferencia de mensajería instantánea P2P, etcétera) .

Por ejemplo, un usuario del dispositivo de cliente 670A solicita una sesión de comunicación en linea con uno o más usuarios de uno o más dispositivos de cliente diferentes transmitiendo una solicitud de invitación al servicio de invitación 620 que incluye un identificador de punto final de sesión de comunicación en linea de cada uno de los otros usuarios. El identificador de punto final de sesión de comunicación en linea puede ser diferente en diferentes modalidades (por ejemplo, un número de teléfono, 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 MAC, u otro identificador ) . El servicio de invitación 620 lee los identificadores de punto final de sesión de comunicación en linea a partir de la solicitud de invitación y ejecuta una búsqueda en el almacenamiento de datos de registro 655 para ubicar los dispositivos de cliente que están asociados con los identificadores de punto final de sesión de comunicación en linea.

Los dispositivos de cliente 670A-N utilizan el servicio de registro 630 para registrar sesiones de comunicación en línea. Por ejemplo, en una modalidad, cuando cada uno de los dispositivos de cliente 670A-N es encendido y es activado en la red, esto ocasiona que su componente léxico de identificación (por ejemplo, su componente léxico de empuje) sea asociado con un identificador de punto final de sesión de comunicación en linea. Las asociaciones son almacenadas en el almacenamiento de datos de registro 655. En una modalidad, los dispositivos de cliente 670A-N se registran para participación para el servicio de sesión de comunicación en linea utilizando el servicio de registro 630 tal como se describió con respecto a la figura 4, mientras que en otras modalidades el proceso de registro ocurre de manera diferente (por ejemplo, proporcionando tanto su componente léxico de empuje como su identificador de punto final de sesión de comunicación en linea) .

El servicio de notificación de empuje 640 utiliza los componentes léxicos de empujes de los dispositivos de cliente 670A-N para transmitir notificaciones de empuje a los dispositivos de cliente 670A-N. En una modalidad, las notificaciones de empuje son utilizadas para transmitir las indicaciones para las sesiones de comunicación en linea. El servicio de retransmisión 650 establece conexiones de sesión de comunicación en linea entre los dispositivos de cliente cuando los tipos de NAT de los dispositivos de cliente no son compatibles o el establecimiento de la conexión P2P ha fallado entre los dispositivos de cliente.

En una modalidad, la comunicación entre los dispositivos de cliente y el servicio CDX 610 se establece utilizando un protocolo de red relativamente de peso ligero tal como enchufes de Protocolo de Datagrama de Usuario ("UDP"). Tal como lo saben aquellos expertos en la técnica, las conexiones de enchufe UDP no requieren diálogos de control de flujo de datos (hand-shaking) para garantizar la conflabilidad del paquete, ordenamiento, o integridad de datos y, por lo tanto, no consume tanta sobrecarga de procesamiento de paquete como las conexiones de enchufe DCP. En consecuencia, la naturaleza apátrida, de peso ligero de los UDP es útil para servidores que responden a pequeñas consultas de un vasto número de clientes. Además, a diferencia del TCP, el UDP es compatible con la difusión de paquetes (en donde los paquetes son enviados a todos los dispositivos en una red local) y multidifusión (en donde los paquetes son enviados a un subconjunto de dispositivos en la red local) . Tal como se describe a continuación, aun cuando se puede utilizar UDP, la seguridad puede ser mantenida en el servicio CDX 610 codificando datos NAT Traversal utilizando claves de sesión.

En contraste al protocolo de red de peso ligero, de baja sobrecarga utilizado por el servicio CDX 610, en una modalidad, la comunicación entre los dispositivos de cliente 670A-N y el servicio de invitación 620, el servicio de registro 630, el servicio de notificación de empuje 640 y/o el servicio de retransmisión 650 es establecida con un protocolo de red inherentemente seguro tal como Seguro de Protocolo de Transferencia de Hipertexto ( "HTTPS" ) , el cual se basa en conexiones de Capa de Enchufes Seguros ("SSL") o de Seguridad de Capa de Transporte ("TLS") . Detalles asociados con estos protocolos son muy conocidos por aquellos expertos en la técnica.

La figura 7 es un diagrama de flujo de datos que ilustra el establecimiento de la sesión de comunicación en linea entre dispositivos de cliente de acuerdo con una modalidad. En el ejemplo de la figura 7, un usuario en el dispositivo de cliente A710 invita a un usuario en el dispositivo de cliente B720 a una sesión de comunicación en linea (por ejemplo, una videoconferencia P2P, un sistema de mensajería instantánea P2P, etcétera). En este ejemplo, el dispositivo de cliente A710 en ocasiones es referido como un dispositivo de cliente de inicio, el usuario del dispositivo de cliente B720 en ocasiones es referido como un destinatario pretendido, y el dispositivo de cliente B720 en ocasiones es referido como un dispositivo de cliente destinatario pretendido. En algunas modalidades, la invitación de sesión de comunicación en linea es una invitación ciega sin presencia. Por ejemplo, el usuario en el dispositivo de cliente A710 no sabe si el usuario en el dispositivo de cliente B720 actualmente está en linea o disponible para participar en la sesión de comunicación en linea.

Aunque modalidades descritas con referencia a las figuras 6 y 7 sn especificas para utilizar componentes léxicos de empuje y notificaciones de empuje, otras modalidades no están limitadas a esto. Por ejemplo, en otras modalidades, se puede utilizar cualquier registro o mapeo de dispositivos de cliente a componente léxicos únicos para asociar los componentes léxicos de identificación con dispositivos de cliente y proporcionar un método confiable para asociar la identidad del dispositivo de cliente con un componente léxico identificado de manera única.

En la operación 1, el dispositivo de cliente A710 solicita sus datos de conexión del intercambio de datos de conexión 610. Los datos de conexión incluyen información para que dispositivos de cliente la intercambien entre si a fin de establecer una sesión de comunicación en linea (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 solicitud, y otra información (por ejemplo, información de prioridad, etcétera) . El intercambio de datos de conexión 610 determina los datos de conexión del dispositivo de cliente A710 (por ejemplo, las direcciones IP públicas/privadas y puertos, tipo de NAT del dispositivo NAT del dispositivo de cliente A) . En la operación 2, el intercambio de datos de conexión 610 devuelve los datos de conexión al dispositivo de cliente A710.

En la operación 3, el dispositivo de cliente A710 transmite una solicitud de invitación de sesión de comunicación en linea al servicio de invitación 620 para invitar al dispositivo de cliente B720 a una sesión de comunicación en linea (por ejemplo, una videoconferencia P2P, una sesión de mensajería instantánea P2P, etcétera) . En una modalidad, la invitación incluye los datos de conexión del dispositivo de cliente A710, los cuales pueden incluir direcciones IP públicas/privadas y puertos para el dispositivo de cliente A710 y el tipo NAT para el dispositivo NAT del dispositivo de cliente 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 B720 (por ejemplo, un número de teléfono del dispositivo de cliente B720, un nombre de usuario del usuario (por ejemplo, un ID de Apple), una dirección de correo electrónico, una dirección de correo, una dirección MAC, etcétera) . La solicitud de invitación de sesión de comunicación en linea puede asumir la forma de una solicitud HPPTS y puede incluir un certificado de cliente firmado por una autoridad de certificado previamente especificada .

En la operación 4, el servicio de invitación 620 determina los componentes léxicos de empuje asociados con el identificador de punto final de sesión de comunicación en linea incluido en la solicitud de la operación 3. Por ejemplo, el servicio de invitación 620 tiene acceso al almacenamiento de datos de registro 655 para determinar los componentes léxicos de empuje que están asociados con el identificador de punto final de sesión de comunicación en linea. Tal como se ilustra en la figura 7, el componente léxico de empuje 725 es asignado al dispositivo de cliente B720 y, por lo tanto, queda asociado con su identificador de punto final de sesión de comunicación en linea. La figura 10 ilustra un almacenamiento de datos de registro ejemplar 655 de acuerdo con una modalidad. Tal como se ilustra en la figura 10, cada uno de los registros de identificador de sesión de comunicación en linea 1010 incluye un campo de componente léxico de empuje 1015 y un campo de identificador de sesión de comunicación en linea 1020. Tal como se ilustra en la figura 10, el mismo identificador de sesión de comunicación en linea puede ser asociado con múltiples componentes léxicos de empuje. En dicho caso, múltiples invitaciones serán transmitidas (por ejemplo, una por componente léxico de empuje) .

El servicio de invitación 620 transmite un mensaje de solicitud de empuje al servicio de notificación de empuje 640. En la operación 5, el servicio de notificación de empuje 640 transmite una solicitud de invitación de sesión de comunicación en linea, en la forma de un mensaje de notificación de empuje, al dispositivo de cliente B720. La solicitud incluye los datos de conexión, el identificador de punto final de sesión de comunicación en linea, y el componente léxico de empuje del dispositivo de cliente A710 (el componente léxico de empuje 715) . La solicitud de invitación también puede incluir información especifica de la sesión de comunicación en linea para proporcionar al usuario del dispositivo de cliente B720 información referente a la invitación (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) , para qué es la invitación (por ejemplo, una videoconferencia P2P, una sesión de mensajería instantánea P2P, etcétera), etcétera) .

La solicitud de invitación de sesión de comunicación en línea será recibida y desplegada en el dispositivo de cliente B720 en caso que esté encendido y operando correctamente. La solicitud de invitación incluye un mecanismo para que el usuario acepte o rechace la invitación (por ejemplo, un botón de aceptar y un botón de rechazar) . El usuario en el dispositivo de cliente ?710 puede recibir una notificación en caso que la solicitud de invitación sea rechazada. Asumiendo que un usuario en el dispositivo de cliente B720 acepta la solicitud de invitación, en la operación 6 el dispositivo de cliente B720 solicita 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 B720 (por ejemplo, direcciones IP públicas /privadas ) y puertos, tipo de NAT del dispositivo NAT del dispositivo de cliente B) , y en la operación 7, devuelve los datos de conexión al dispositivo de cliente B720.

El dispositivo de cliente B720 entonces transmite un mensaje de aceptación al servicio de invitación 620 en la operación 8. El mensaje de aceptación incluye los datos de conexión del dispositivo de cliente B720 e incluye el componente léxico de empuje del dispositivo de cliente A710. El mensaje de aceptación también puede contener una indicación respecto a si se trata de un reintento de un intento de conexión P2P directo que previamente falló entre el dispositivo de cliente A710 y el dispositivo de cliente B720. El mensaje de aceptación puede asumir la forma de un mensaje HTTPS.

En algunas modalidades, el servicio de invitación 620 determina si una conexión P2P entre el dispositivo de cliente A710 y el dispositivo de cliente B720 es viable. En la operación 9, el servicio de invitación 620 determina si una conexión P2P directa entre los dispositivos de cliente A y B es viable. Por ejemplo, en una modalidad, si el mensaje de aceptación recibido desde el dispositivo de cliente B620 indica que se trata de un reintento a partir de un intento de conexión directa que previamente falló (o un número especificado de intentos de conexión directa que fallaron previamente) entonces el servicio de invitación 620 puede concluir que una conexión P2P directa no es viable. Para determinar la viabilidad, el servicio de invitación 620 puede comparar los datos tipo NAT para los dispositivos de cliente A y B a fin de determinar si los dispositivos NAT de los dispositivos de cliente A y B soportarán una conexión P2P directa. En una modalidad, el mensaje de aceptación descrito anteriormente no incluye una indicación de intentos fallidos previos. Más bien, después de un intento de conexión directa fallido, cualquiera de los dispositivos de cliente 710-720 pueden transmitir una solicitud de "retransmitir invitación" especial (por ejemplo, en lugar de la solicitud de invitación en la operación 3 de la figura 7) indicando que se necesita una conexión de retransmisión. En respuesta, el servicio de invitación automáticamente puede recurrir a las operaciones de retransmisión aquí descritas (tal como se analiza a continuación) .

Algunas combinaciones de tipos de NAT son conocidas como incompatibles para establecer conexiones P2P. Por ejemplo, una NAT de cono completo puede ser utilizada con cualquier otro tipo de NAT excepto una NAT cerrada/con muro cortafuego para establecer una conexión P2P directa. En contraste, una NAT simétrica solamente puede ser utilizada con una NAT de cono completo para establecer una conexión P2P directa. La viabilidad de combinar varios tipos de NAT en una modalidad se establece en la tabla de compatibilidad NAT 1110 que se muestra en la figura 11, en la cual las columnas representan los tipos de NAT de un dispositivo de cliente (por ejemplo, dispositivo de cliente A710) y las filas representan los tipos de NAT del otro dispositivo de cliente (por ejemplo, dispositivo de cliente B720). Un "1.0" en una celda indica que los tipos de NAT en la fila y columna asociadas son compatibles y un "0.0" indica que los tipos de NAT son incompatibles.

Si el servicio de invitación 620 determina que una conexión P2P directa es viable, entonces el servicio de invitación 620 transmite una solicitud de empuje al servicio de notificación de empuje 640 para transmitir la aceptación de la solicitud de invitación. Por lo tanto en la operación 10B, el servicio de notificación de empuje 640 transmite un mensaje de aceptación de sesión de comunicación en linea, en la forma de una notificación de empuje, al dispositivo de cliente A710. El mensaje de aceptación incluye los datos de conexión, el identificador de punto final de sesión de comunicación en linea, y el componente léxico de empuje del dispositivo de cliente B720. El mensaje de aceptación será desplegado en el dispositivo de cliente A710. Debido a que los dispositivos de cliente A y B tienen los datos de conexión del otro, los dispositivos de cliente A y B tiene 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 el Establecimiento de Conectivídad de Internet (ICE) u otros mecanismos de conectivídad P2P conocidos).

Sin embargo, si el servicio de invitación 620 determina que una conexión P2P directa no es viable, entonces éste transmite una solicitud de búsqueda de retransmisión en la operación 10B al servicio de retransmisión 650 para determinar uno o más huéspedes de retransmisión para los dispositivos de cliente A y B a utilizar para la conexión. La solicitud de búsqueda de retransmisión puede contener la información de conexión en red para los dispositivos de cliente A y B (por ejemplo, datos de conexión/NAT Traversal y/o datos de tipo de NAT) la cual es utilizada por el servicio de retransmisión 650 para seleccionar huéspedes de retransmisión apropiados para ambos de los dispositivos de cliente.

Tal como se ilustra en la figura 8, en una modalidad, el servicio de retransmisión 650 incluye un módulo de búsqueda de retransmisión 805, múltiples huéspedes de retransmisión 815A-B, y una base de datos de huéspedes de retransmisión 810 que contiene información de red relacionada con cada uno de los huéspedes de retransmisión 815A-B. Aunque la figura 8 ilustra dos huéspedes de retransmisión, se debiera entender que puede haber una cantidad mayor o menor de huéspedes de retransmisión en algunas modalidades. El servicio de invitación 620 transmite una solicitud de búsqueda de retransmisión al módulo de búsqueda de retransmisión 805, el cual consulta la base de datos de huéspedes de retransmisión 810 utilizando la información de red para los dispositivos de cliente A y B. Al momento de recibir los resultados de la base de datos, el módulo de búsqueda de retransmisión 805 proporciona una respuesta que identifica los huéspedes de retransmisión seleccionados SIS B en la operación 11B al servicio de invitación 620.

En una modalidad, la respuesta de búsqueda de retransmisión contiene un componente léxico de retransmisión generado por el servicio de retransmisión 650 y las direcciones de red (direcciones IP/puertos) de los huéspedes de retransmisión seleccionados 815A-B a ser utilizados por los dispositivos de cliente A y B para la conexión de retransmisión. En una modalidad, el componente léxico de retransmisión está asociado con la sesión de retransmisión y es utilizado por los huéspedes de retransmisión 815A-B para autenticar los dispositivos de cliente A y B al momento de conectarse al servicio de retransmisión 650. El componente léxico puede asumir varias formas incluyendo, por ejemplo, código ID de sesión de retransmisión de ID único, un 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 B indicando que se realizará una conexión de retransmisión. En una modalidad, la respuesta de retransmisión al dispositivo de cliente B puede incluir el componente léxico de retransmisión y la información de red para el huésped de retransmisión 815B. En una modalidad, la respuesta al dispositivo de cliente B puede ser enviada directamente (eludiendo el servicio de notificación de empuje 640) debido a que está siendo enviado en respuesta al mensaje de aceptación de invitación del dispositivo de cliente B. El servicio de invitación 620 también transmite una respuesta de retransmisión al dispositivo de cliente A, la cual puede incluir el componente léxico de retransmisión y la información de red para el huésped de retransmisión A 815A. En este caso, la respuesta es empujada al dispositivo de cliente A a través del servicio de notificación de empuje 640.

En la operación 12B, el dispositivo de cliente A710 utiliza la información de red para que el huésped de retransmisión 815A establezca una conexión con' el servicio de retransmisión 650. De manera similar, en la operación 13B, el dispositivo de cliente B720 utiliza la información de red para que el huésped de retransmisión 815B establezca una conexión con el servicio de retransmisión 650. En cada una de estas transacciones, cuando se abren agujeros en cualquiera de los muros cortafuego NAT de los dispositivos de cliente A y B, y la NAT Traversal/datos de conexión para los dispositivos de cliente A y B pueden 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 modalidad, el servicio de retransmisión 650 y los dispositivos de cliente A y B implementan el protocolo Transversabilidad de NAT Utilizando Retransmisión ("TURN"), el cual, tal como lo entienden aquellos expertos en la técnica, permite que un elemento detrás de una NAT o muro cortafuego reciba datos de entrada sobre conexiones TCP o UDP.

En la operación 14B, el dispositivo de cliente A710 transmite una actualización de retransmisión al servicio de invitación 620, el cual es reenviado al servicio de notificación de empuje y empujado al dispositivo de cliente P720 en la operación 17B. De manera similar, en la operación 15B, el dispositivo de cliente B720 transmite una actualización de retransmisión al servicio de invitación 620 la cual es reenviada al servicio de notificación de empuje 620 y empujada al dispositivo de cliente A610 en la operación 16B. La actualización de retransmisión transmitida por el dispositivo de cliente A710 puede incluir el componente léxico de sesión, el identificador de punto final de sesión de comunicación en linea de cada dispositivo, y la NAT Traversal/datos de conexión determinados por el servicio de retransmisión 650.

En la operación 18B y 19B, los dispositivos de cliente A y B, respectivamente, establecen una conexión de sesión de comunicación en linea a través del servicio de retransmisión 650. En una modalidad, las conexiones de retransmisión pueden ser establecidas cuando el dispositivo de cliente A710 envía la NAT Traversal /datos de conexión del dispositivo de cliente B720.al servicio de retransmisión 650, y viceversa, permitiendo así que el servicio de retransmisión determine la trayectoria correcta al huésped de retransmisión 815?-? de cada par.

Al utilizar las técnicas antes descritas, el servicio de invitación 620 puede ser implementado como un servicio apátrida, el cual es inherentemente escalable y resiliente, incluso en un sistema a gran escala con un vasto número de dispositivos de cliente. Por ejemplo, debido a que el servicio de notificación de empuje 640 inherentemente tiene la capacidad para localizar y empujar contenido a dispositivos de cliente registrados, no se requiere que el servicio de invitación 620 rastree la ubicación actual de cada dispositivo. Adicionalmente, debido a que los dispositivos pueden transmitir NAT Traversal/datos de conexión con solicitudes y respuestas, nunca se requiere que el servicio de invitación 620 mantenga alguna información de estado por-conexión, reduciendo asi los requerimientos de almacenamiento y procesamiento del servicio de invitación. Dicha impleraentación es particularmente útil en un sistema a gran escala.

Aunque la figura 7 describe a un usuario en un dispositivo de cliente invitando a un solo usuario a una sesión de comunicación en linea, las modalidades no quedan limitadas a esto. Por ejemplo, en algunas modalidades, un usuario en un dispositivo de cliente puede invitar a múltiples usuarios a una sesión de comunicación en linea. Por ejemplo, el usuario puede transmitir un solo mensaje de solicitud de invitación al servicio de invitación con múltiples identificadores de punto final de sesión de comunicación en linea para invitar a múltiples usuarios en diferentes dispositivos de cliente a participar en una sesión de comunicación en linea.

En algunas situaciones, un usuario puede tener múltiples dispositivos de cliente que estén asociados con el mismo identificador de punto final de sesión de comunicación en linea. La figura 26 es un diagrama de flujo de datos que ilustra operaciones ejemplares para administrar invitaciones cuando un 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 linea.

El dispositivo de cliente A (operado por el usuario A) 2610 transmite una solicitud para sus datos de conexión del intercambio de datos de conexión 610 en la operación 2632. El intercambio de datos de conexión 610 devuelve los datos de conexión del dispositivo de cliente A en la operación 2634. El dispositivo de cliente entonces transmite una solicitud 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 videoconferencia P2P, una sesión de mensajería instantánea P2P, una videollamada , etcétera) . La solicitud de invitación incluye datos de conexión de A.

El servicio de invitación ejecuta una búsqueda de directorio en la operación 2638 con base en el ID de B incluido en el mensaje de solicitud de invitación. En este ejemplo, la operación de búsqueda de directorio devuelve un componente léxico de empuje para el dispositivo de cliente Bl y un componente léxico de empuje para el dispositivo de cliente B2. Por lo tanto, los dispositivos de cliente Bl y B2 están asociados con el ID de B. El servicio de invitación 620 entonces transmite un mensaje de solicitud de empuje en la operación 2640 al servicio de notificación de empuje 640 para empujar los mensajes de solicitud de invitación al dispositivo de cliente Bl 2615 y el dispositivo de cliente B2 2620. El servicio de notificación de empuje 640 transmite una solicitud de invitación de sesión de comunicación en línea, en la forma de un mensaje de notificación de empuje, al dispositivo de cliente Bl 2615 en la operación 2642 y al dispositivo de cliente B2 2620 en la operación 2644. Cada mensaje de solicitud de invitación incluye los datos de conexión del dispositivo de cliente A2610, el identificador de punto final de sesión de comunicación en linea utilizado por el usuario A, y el componente léxico de empuje del dispositivo de cliente A2610. Las solicitudes de invitación también pueden incluir información especifica para la sesión de comunicación en linea (por ejemplo, el nombre de la persona que envía la invitación (por ejemplo, nombre usuario, nombre real, número de teléfono, o alguna combinación de los mismos), para qué es la invitación (por ejemplo, una videoconferencia P2P, una sesión de mensajería instantánea P2P, etcétera), etcétera). Por lo tanto, una solicitud de invitación de sesión de comunicación en línea es enviada a cada uno de los dispositivos que están asociados con el identificador de punto final de sesión de comunicación en línea incluido en la solicitud de invitación original.

En una modalidad, el servicio de invitación 620 transmite un mensaje de estatus al dispositivo de cliente que invita para indicar a cuáles dispositivos de cliente fue transmitida la invitación. Por lo tanto, en la operación 2646, el servicio de invitación 620 transmite una actualización del estatus de invitación al dispositivo de cliente A2610 que indica que una solicitud de invitación de sesión de comunicación en línea fue enviada al dispositivo de cliente Bl 2615 y el dispositivo de cliente B2 2620. En una modalidad, el dispositivo de cliente A2610 rastrea cuáles dispositivos de cliente aceptan la invitación y mantiene a los otros dispositivos de cliente informados sobre el estado de la sesión de comunicación en linea.

En una modalidad, el dispositivo de cliente Bl 2615 y el dispositivo de cliente B2 2620 desplegarán una solicitud de invitación en caso que estén encendidos y con la capacidad para recibir la solicitud de invitación. En el ejemplo ilustrado en la figura 26, un usuario en el dispositivo de cliente Bl 2615 estará aceptando la invitación. Por lo tanto, en la operación 2648, el dispositivo de cliente Bl 2615 solicita 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 Bl 2615 y en la operación 2650 los devuelve al dispositivo de cliente Bl 2615.

El dispositivo de cliente Bl 2615 entonces transmite 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 Bl 2615 y el componente léxico de empuje del dispositivo de cliente A 2610. El mensaje de aceptación también puede contener una indicación respecto a si se trata de un reintento de un intento de conexión P2P directo fallido previo entre el dispositivo de cliente A2610 y el dispositivo de cliente Bl 2615. Además, el mensaje de aceptación también puede incluir los identificadores de punto final de sesión de comunicación en linea de A y B y el componente léxico de empuje para el dispositivo de cliente B 2615.

En algunas modalidades, después de recibir un mensaje de aceptación a una sesión de comunicación en linea, el servicio de invitación 620 determina si es viable una conexión P2P directa. Por lo tanto, en la operación 2654, el servicio de invitación 620 ejecuta una revisión de compatibilidad P2P directa para determinar si una conexión P2P directa entre el dispositivo de cliente A 2610 y el dispositivo de cliente Bl 2615 es viable, en una manera similar a la previamente descrita. Si los dispositivos de cliente son compatibles para una conexión P2P directa, entonces las operaciones descritas en referencia a la figura 27 (comenzando en la operación 2710) son ejecutadas. Si los dispositivos de cliente no son compatibles para una conexión P2P directa, entonces las operaciones descritas en referencia a la figura 28 (comenzando en la operación 2810) son ej ecutadas .

Con referencia a la figura 27, la cual ilustra operaciones ejecutadas cuando una conexión P2P directa es viable, en la operación 2710 el servicio de invitación 620 transmite una solicitud de empuje al servicio de notificación de empuje 640 para transmitir la aceptación de la invitación por el dispositivo de cliente Bl 2615. En la operación 2712, el servicio de notificación de empuje 640 transmite un mensaje de aceptación de sesión de comunicación en linea, en la forma de una notificación de empuje, al dispositivo de cliente A 2610. Este mensaje de aceptación incluye los datos de conexión y el componente léxico de empuje del dispositivo de cliente Bl 2615, y el identificador de punto final de sesión de comunicación en linea utilizado por el usuario B.

En una modalidad, cierto tiempo después de recibir el mensaje de aceptación que indica que el dispositivo de cliente Bl 2615 ha aceptado la invitación, el dispositivo de cliente A2610 informa al dispositivo de cliente B2 2620 que el dispositivo de cliente A 2620 ha aceptado la invitación. Por lo tanto, en la operación 2714, el dispositivo de cliente A 2610 transmite una solicitud de actualización de invitación al servicio de invitación que incluye el identificador de punto final de sesión de comunicación en linea del usuario B e indica que el dispositivo de cliente Bl 2615 ha aceptado la invitación. La solicitud de actualización de invitación también puede ordenar o indicar al servicio de invitación 620 cuál dispositivo de cliente asociada con el identificador de punto final de sesión de comunicación en linea del usuario B debiera recibir el mensaje de actualización de invitación (en este ejemplo, el dispositivo de cliente B2 2620 debiera recibir el mensaje de actualización de invitación) .

El servicio de invitación 620 ejecuta una búsqueda de directorio 2716 con base en el identificador de punto final de sesión de comunicación en linea del usuario B para determinar el componente léxico de empuje del dispositivo de cliente B2 2620. Después de determinar el componente léxico de empuje, el servicio de invitación transmite una solicitud de empuje en la operación 2718 al servicio de notificación de empuje 640 para empujar el mensaje de actualización de invitación al dispositivo de cliente B2 2620. En la operación 2720, el servicio de notificación de empuje 640 transmite mensaje de actualización de invitación, en la forma de un mensaje de notificación de empuje, al dispositivo de cliente B2 2620. El mensaje de actualización de invitación indica que el dispositivo de cliente Bl 2615 ha aceptado la invitación de sesión de comunicación en linea. El dispositivo de cliente B2 2620 puede desplegar el mensaje de actualización de invitación y puede mantener el estado de la sesión de comunicación en linea entre el dispositivo de cliente A 2610 y el dispositivo de cliente Bl 2615 (por ejemplo, la duración de la sesión de comunicación en linea, etcétera) . Tal como se describirá con mayor detalle con referencia a la figura 30, en una modalidad, el dispositivo de cliente B2 2620 puede transmitir una solicitud de transferencia para ocasionar que la sesión de comunicación en linea se transfiera desde el dispositivo de cliente Bl 2615 al dispositivo de cliente B2 2620.

Cierto 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 Bl 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 el establecimiento de conectividad de Internet (ICE) u otros mecanismos de conectividad P2P conocidos) . Se debiera entender que la operación 2722 puede ser ejecutada antes de o durante las operaciones 2714-2720.

Auque la figura 26 describe un ejemplo donde solamente un dispositivo de cliente único 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 linea dirigida a un solo usuario. Por ejemplo, el dispositivo de cliente Bl 2615 y el dispositivo de cliente B2 2620 pueden aceptar la invitación en algunas situaciones. En una modalidad, el dispositivo de cliente A 2610 establece una sesión de comunicación en linea con el primer dispositivo de cliente del cual recibe un mensaje de aceptación. El dispositivo de cliente ?2610 puede ocasionar que un mensaje de cancelación sea enviado a los otros dispositivos de cliente (por ejemplo, el mensaje de cancelación puede ser transmitido al servicio de invitación y después empujado, a través del servicio de notificación de empuje, a aquellos otros dispositivos de cliente) .

Haciendo referencia nuevamente a la operación 2654 de la figura 26, si una conexión P2P directa no es viable entre el dispositivo de cliente A 2610 y el dispositivo de cliente Bl 2615, entonces se ejecutan las operaciones descritas en la figura 28. La figura 28 es un diagrama de flujo de datos que ilustra operaciones ejemplares que son ejecutadas cuando no es viable una conexión P2P directa. En la operación 2810, el servicio de invitación 620 transmite una solicitud de búsqueda de retransmisión 2810 al servicio de retransmisión 650 para determinar un huésped de retransmisión a ser utilizado por el dispositivo de cliente A 2610 y el dispositivo de cliente Bl 2615. La solicitud de búsqueda de retransmisión puede contener la información de conexión en red para los dispositivos de cliente (por ejemplo, NAT Traversal/datos de conexión y/o datos de tipo NAT) la cual es utilizada por el servicio de retransmisión 650 para seleccionar huéspedes de retransmisión apropiados para los dispositivos de cliente. Tal como se ilustra en la figura 8, una modalidad del servicio de retransmisión 650 incluye una pluralidad de huéspedes de retransmisión 815A-B y una base de datos de huéspedes de retransmisión 810 que contiene información de red relacionada con cada uno de los huéspedes de retransmisión. Por ejemplo, el servicio de invitación 620 transmite una solicitud de búsqueda de retransmisión a un servicio de retransmisión 650, el cual consulta la base de datos de huéspedes de retransmisión 810 utilizando la información de red para los dispositivos de cliente. Al momento de recibir los resultados de búsqueda de la base de datos, el servicio de retransmisión 650 proporciona una respuesta de búsqueda de retransmisión en la operación 1201 identificando los huéspedes de retransmisión seleccionados 815A-B. En una modalidad, la respuesta de búsqueda de retransmisión contiene un componente léxico de retransmisión generado por el servicio de retransmisión 650 y las direcciones de red (direcciones iP/puertos) de los huéspedes de retransmisión 815A-B a ser utilizados por los dispositivos de cliente para la conexión de retransmisión. En una modalidad, el componente léxico de retransmisión está asociado con la sesión de retransmisión y es utilizado por los huéspedes de retransmisión 815A-B para autenticar el dispositivo de cliente A2610 y el dispositivo de cliente Bl 2615 al momento de conectarse al servicio de retransmisión 650. El componente léxico puede asumir varias formas incluyendo, por ejemplo, código de ID de sesión de retransmisión con ID único, un certificado digital y/o una clave de codificación única asociada con la sesión de retransmisión.

El servicio de invitación 620 entonces transmite una respuesta de retransmisión al dispositivo de cliente Bl 2615 en la operación 2814 que contiene una indicación de que se establecerá una conexión de retransmisión. En una modalidad, la respuesta de retransmisión puede incluir el componente léxico de retransmisión y la información de red para el huésped de retransmisión seleccionado para el dispositivo de cliente Bl 2615. En una modalidad, la respuesta de retransmisión puede ser enviada directamente al dispositivo de cliente Bl 2615 (eludiendo el servicio de notificación de empuje 640) . El servicio de invitación 620 también transmite una respuesta de retransmisión al dispositivo de cliente A2610 en la operación 2816 que incluye el componente léxico de retransmisión y la información de red para el huésped de retransmisión seleccionado para el dispositivo de cliente A2610. En algunas modalidades, la respuesta de retransmisión es empujada al dispositivo móvil A a través del servicio de notificación de empuje 640.

En la operación 2818, el dispositivo de cliente A2610 entonces transmite una solicitud de actualización de invitación al servicio de invitación 620 que incluye el identificador de punto final de sesión de comunicación en linea del usuario B e indica que el dispositivo de cliente Bl 2615 ha aceptado la invitación. La solicitud de actualización de invitación también puede ordenar o indicar al servicio de invitación 620 cuál dispositivo de cliente asociado con el identificador de punto final de sesión de comunicación en linea del usuario B debiera recibir el mensaje de actualización de invitación (en este ejemplo, el dispositivo de cliente B2 2620 debiera recibir el mensaje de actualización de invitación) .

El servicio de invitación 620 ejecuta una búsqueda de directorio 2820 con base en el identificador de punto final de sesión de comunicación en linea del usuario B para determinar el componente léxico de empuje del dispositivo de cliente B2 2620. Después de determinar el componente léxico de empuje, el servicio de invitación transmite una solicitud de empuje en la operación 2822 al servicio de notificación de empuje 640 para empujar el mensaje de actualización de invitación al dispositivo de cliente B2 2620. En la operación 2824, el servicio de notificación de empuje 640 transmite un mensaje de actualización de invitación, en la forma de un mensaje de notificación de empuje, al dispositivo de cliente B2 2620. El mensaje de actualización de invitación indica que el dispositivo de cliente Bl 2615 ha aceptado la invitación de sesión de comunicación en linea. El dispositivo de cliente B2 2620 puede desplegar el mensaje de actualización de invitación y puede mantener el estado de la sesión de comunicación en linea entre el dispositivo de cliente A 2610 y el dispositivo de cliente Bl 2615 (por ejemplo, la duración de la sesión de comunicación en linea, etcétera) . En una modalidad, el dispositivo de cliente B2 2620 puede transmitir una solicitud de transferencia para ocasionar que la sesión de comunicación en linea se transfiera del dispositivo de cliente Bl 2615 al dispositivo de cliente B2 2620.

En la operación 2826, el dispositivo de cliente A2610 utiliza la información de red para que su huésped de retransmisión seleccionado establezca una conexión con el servicio de retransmisión 650. De manera similar, en la operación 2828, el dispositivo de cliente Bl 2620 utiliza la información de red para que su huésped de retransmisión seleccionado establezca una conexión con el servicio de retransmisión 650. En cada una de estas operaciones, se pueden abrir nuevos agujeros en cualquiera de los muros cortafuego NAT de los dispositivos de cliente y la NAT Traversal/datos de conexión para que los dispositivos de cliente puedan ser determinados por el servicio de retransmisión 650 y devueltos a los mismos (por ejemplo, determinando el IP público/puerto de los dispositivos de cliente) . En una modalidad, el servicio de retransmisión 650 y el dispositivo de cliente A2610 y el dispositivo de cliente Bl 2615 implementan el protocolo Transversabilidad de NAT Utilizando Retransmisión ("TURN") el cual, tal como lo entienden aquellos expertos en la técnica, permite que un elemento detrás de una NAT o muro cortafuego reciba datos de entrada sobre 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 la cual es reenviada al servicio de notificación de empuje en la operación 2832 y empujada al dispositivo de cliente Bl 2615 en la operación 2834. De manera similar, en la operación 2836 el dispositivo de cliente Bl 2615 transmite una actualización de retransmisión al servicio de invitación 620 la cual es reenviada al servicio de notificación de empuje 640 en la operación 2838 y empujada el 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 componente léxico de retransmisión, cada identificador de sesión de comunicación en linea, y la NAT Traversal/datos de conexión determinados por el servicio de retransmisión 650 en las operaciones 2826 y 2828. En una modalidad, las operaciones de actualización de retransmisión son ejecutadas debido a que una o más de la información NAT del dispositivo de cliente pudiera haber cambiado. Finalmente, en las operaciones 2842 y 2844, el dispositivo de cliente A 3610 y el dispositivo de cliente Bl 2620 respectivamente establecen una conexión P2P a través del servicio de retransmisión 650. En una modalidad, las conexiones de retransmisión pueden ser establecidas en respuesta al dispositivo de cliente A 2610 que transmite la NAT Traversal/datos de conexión del dispositivo de cliente Bl 2615 al servicio de retransmisión 650, y viceversa, permitiendo asi que el servicio de retransmisión 650 determine la trayectoria correcta al huésped de retransmisión de cada par.

La figura 29 es un diagrama de flujo de datos que ilustra operaciones ejemplares ejecutadas cuando finaliza una sesión de comunicación en línea de acuerdo con una modalidad. En la operación 2910, la sesión de comunicación en linea entre el dispositivo de cliente A 2610 y el dispositivo de cliente Bl 2615 ha finalizado. Por ejemplo, ya sea el dispositivo de cliente A2610 o el dispositivo de cliente Bl 2615 ha terminado la sesión de comunicación en línea (o de otra manera ha sido terminada la sesión de comunicación en línea) . La sesión de comunicación en línea pudiera haber sido a través de una conexión P2P directa o a través de una retransmisión .

Cierto tiempo después que la sesión de comunicación en línea ha finalizado, en la operación 2912, el dispositivo de cliente A 2610 transmite una solicitud de actualización de sesión de comunicación en línea al servicio de invitación 620. La actualización de sesión de comunicación en línea es enviada para notificar al dispositivo de cliente B2 2620, el cual no fue parte de la sesión de comunicación en linea, respecto de la terminación de la sesión de comunicación en linea. La solicitud de actualización de sesión de comunicación en linea puede incluir el identificador de sesión de comunicación en linea del usuario B y puede ordenar o indicar al servicio de invitación 620 cuál dispositivo de cliente asociado con el usuario B (por ejemplo, el dispositivo de cliente B2 2620) va a recibir la actualización.

El servicio de invitación 620 ejecuta una operación de búsqueda de directorio 2914 basada en el identificador de punto final de sesión de comunicación en línea del usuario B para determinar el componente léxico de empuje de dispositivo de cliente B2 2620. Después de determinar el componente léxico de empuje, el servicio de invitación transmite una solicitud de empuje en la operación 2916 al servicio de notificación de empuje 640 para empujar el mensaje de actualización al dispositivo de cliente B2 2620. En la operación 2720, el servicio de notificación de empuje 640 transmite un mensaje de actualización de sesión de comunicación en línea, en la forma de un mensaje de notificación de empuje, al dispositivo de cliente B2 2620. El mensaje de actualización de sesión de comunicación en linea indica que la sesión de comunicación en linea entre el dispositivo de cliente A 2910 y el dispositivo de cliente Bl 2615 ha finalizado.

La figura 30 es un diagrama de flujo que ilustra operaciones ejemplares ejecutadas para transferir una sesión de comunicación en linea desde un dispositivo de cliente a otro dispositivo de cliente de acuerdo con una modalidad. En el ejemplo ilustrado en la figura 30, se asume que cada uno de los dispositivos de cliente Bl 2615 y B2 2620 recibió una invitación a una sesión de comunicación en linea originada por el dispositivo de cliente A2610 (éstos comparten el identificador de punto final de sesión de comunicación en línea que fue utilizado en la invitación) y el dispositivo de cliente Bl 2615 aceptó y estableció una sesión de comunicación en línea con el dispositivo de cliente ? 2610 (tal como se describe en las figuras 26 y 27 o 28) . Además, el dispositivo de cliente B2 2620 ha recibido una actualización de invitación que indica que el dispositivo de cliente Bl 2615 ha aceptado la invitación. En el ejemplo ilustrado en la figura 30, la sesión de comunicación en línea será transferida del dispositivo de cliente Bl 2615 al dispositivo de cliente B2 2620. Por ejemplo, un usuario en el dispositivo de cliente B2 2620 ha indicado que desea tomar el control de la sesión de comunicación en linea entre los dispositivos de cliente A2610 y el dispositivo de cliente Bl 2620. En una modalidad, la aplicación de sesión de comunicación en linea 2115 despliega un estado de la sesión de comunicación en linea entre el dispositivo de cliente A 2610 y el dispositivo de cliente Bl 2615 que permite a un usuario en el dispositivo de cliente B2 2620 emitir una solicitud de sesión de comunicación en linea de transferencia (por ejemplo, a través de un clic o presionando un enlace o botón virtual disponible en la aplicación de sesión de comunicación en linea 2115 del dispositivo de cliente Bl 2615) .

En la operación 3010, el dispositivo de cliente B2 2620 solicita sus datos de conexión del intercambio de datos de conexión 610 y recibe los datos de conexión solicitados en la operación 3012 (en caso que todavía no conozca sus datos de conexión) . El dispositivo de cliente B2 2620 entonces transmite un mensaje de solicitud de transferencia en la operación 3014 al servicio de invitación 620 que incluye el componente léxico de empuje del dispositivo de cliente A 2610 y los datos de conexión del dispositivo de cliente B2 2620. El mensaje de solicitud de transferencia también puede incluir los identificadores de punto final de sesión de comunicación en línea de A y/o B y/o el componente léxico de empuje para el dispositivo de cliente A 2610.

El servicio de invitación 620 entonces transmite una solicitud de empuje al servicio de notificación de empuje 640 en la operación 3016 para ocasionar que el servicio de notificación de empuje 640 transmita el mensaje de transferencia, en la forma de una notificación de empuje al dispositivo de cliente A 2610. El servicio de invitación 620 también ejecuta una revisión de compatibilidad P2P directa en la operación 3018 para determinar si es viable una conexión P2P directa entre el dispositivo de cliente A2610 y el dispositivo de cliente B2 2620. Para propósitos de este ejemplo es viable una conexión directa, sin embargo se debiera entender que una transferencia de sesión de comunicación en línea también puede ocurrir en una situación de retransmisión.

En la operación 3020, el servicio de notificación de empuje transmite el mensaje de solicitud de transferencia al dispositivo de cliente A 2610. El mensaje de solicitud de transferencia puede incluir el identificador de punto final de sesión de comunicación en línea de B y los datos de conexión para el dispositivo de cliente B2 2620. El mensaje de solicitud de transferencia también indica cuál es el dispositivo (es decir, el dispositivo de cliente B2 2620) que está solicitando la transferencia de sesión de comunicación en línea (por ejemplo, a través de un ID de dispositivo y/o componente léxico de empuje del dispositivo de cliente B2 2620) . El mensaje de solicitud de transferencia puede ocasionar que la aplicación de sesión de comunicación en línea 2115 del dispositivo de cliente A 2610 despliegue la solicitud de transferencia, y puede permitir que el usuario acepte o rechace la solicitud de transferencia. Asumiendo que la solicitud de transferencia es aceptada, el dispositivo de cliente A 2610 establece una conexión P2P directa con el dispositivo de cliente B 2620 utilizando los datos de conexión intercambiados en la operación 3022. Se debiera entender que en este punto, la sesión de comunicación en línea entre el dispositivo de cliente A 2610 y el dispositivo de cliente Bl 2615 está activa. El dispositivo de cliente A 2610 entonces transmite una actualización de sesión de comunicación en línea al dispositivo de cliente Bl 2615 que indican que la sesión de comunicación en línea se transferirá al dispositivo de cliente B2 2620. En una modalidad, este mensaje de actualización es transmitido en la sesión de comunicación en línea existente entre los dispositivos de cliente. El dispositivo de cliente A 2610 entonces cambia a la sesión de comunicación en linea con el dispositivo de cliente B2 2620 en la operación 3026 y tira la sesión de comunicación en linea con el dispositivo de cliente Bl 2615 en la operación 3028.

Aunque se han descrito modalidades con referencia a invitar a un solo usuario a una sesión de comunicación en linea (el cual puede o no estar asociada con múltiples dispositivos de cliente) , en algunas modalidades múltiples usuarios pueden ser invitados a una sesión de comunicación en linea. La figura 31 es un diagrama de flujo que ilustra operaciones ejemplares para iniciar y establecer una sesión de comunicación en linea con múltiples usuarios.

El dispositivo de cliente 3110 solicita sus datos de conexión del intercambio de datos de conexión 610 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 solicitud 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 linea asociado con el usuario B y un identificador de punto final de sesión de comunicación en linea asociado con el usuario C. Por lo tanto, un usuario en el dispositivo de cliente A 3110 está invitando a múltiples usuarios a una sesión de comunicación en linea.

El servicio de invitación 620 ejecuta una operación de búsqueda de directorio 3138 para determinar los componentes léxicos de empuje asociados con el identificador de punto final de sesión de comunicación en linea del usuario B y el identificador de punto final de sesión de comunicación en linea del usuario C. En este ejemplo y para propósitos de simplicidad, la búsqueda de directorio devuelve un resultado del dispositivo de cliente B 3115 que está asociado con el identificador de punto final de sesión de comunicación en linea del usuario B y el dispositivo de cliente C 3120 que está asociado con el identificador de punto final de sesión de comunicación en linea del usuario C. El servicio de invitación 620 entonces transmite una solicitud de empuje 3140 al servicio de notificación de empuje 640 para solicitar que el servicio de notificación de empuje 640 transmita las invitaciones, en la forma de mensajes de empuje, a los dispositivos de cliente B y C. El servicio de notificación de empuje 640 entonces transmite la solicitud de invitación al dispositivo de cliente B3115 en la operación 3142 y transmite la solicitud de invitación al dispositivo de cliente C 3120 en la operación 3144. Cada mensaje de solicitud 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 linea utilizado por el usuario A, y el componente léxico de empuje del dispositivo de cliente A 3110.

En una modalidad, el servicio de invitación 620 transmite un mensaje de estatus al dispositivo de cliente que hace la invitación para indicar a cuáles dispositivos de cliente fue transmitida la invitación. Por lo tanto, en la operación 3146, el servicio de invitación 620 transmite una actualización de estatus de invitación al dispositivo de cliente A 3110 que indica que una solicitud de invitación de sesión de comunicación en linea fue enviada al dispositivo de cliente B 3115 y el dispositivo de cliente C 3120. En una modalidad, el dispositivo de cliente B 3115 y el dispositivo de cliente C 3120 desplegarán una solicitud de invitación en caso que estén encendidos y con la capacidad para recibir la solicitud de invitación.

En el ejemplo ilustrado en la figura 31, cada una de las invitaciones será aceptada. Por lo tanto, en la operación 3148, el dispositivo de cliente B 3115 solicita 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 de datos de conexión 610 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 entonces transmite un mensaje de aceptación al servicio de invitación 620 en la operación 3156, y el dispositivo de cliente C 3120 transmite un mensaje de aceptación al servicio de invitación 620 en la operación 3158. El servicio de invitación 620 entonces ejecuta una revisión de compatibilidad P2P directa 3160 para determinar si una conexión P2P directa es viable 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. Para propósitos de este ejemplo, una conexión P2P directa es viable entre los dispositivos de cliente. Por lo tanto, al utilizar los datos de conexión intercambiados, 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 linea 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 linea en la operación 3164. En este ejemplo, el dispositivo de cliente A 3110 esencialmente actúa como el huésped de la sesión de comunicación en linea. Por lo tanto, 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 modalidades, una red completa de conexiones es establecida entre las partes. En dicha modalidad, se establecería otra conexión P2P entre el dispositivo de cliente B 3115 y el dispositivo de cliente C 3120.

Aunque las modalidades aquí descritas describen un mecanismo para registrar dispositivos de cliente para sesiones de comunicación en línea, en algunas modalidades el registro 140 puede implementar una API para permitir que diferentes aplicaciones registren el identificador de punto final de sesión de comunicación en línea y los componentes léxicos de empuje. La API implementada en una modalidad, es una interfaz implementada por un componente de software (en los sucesivo "componente de software implementando API") que permite que un componente de software diferente (en lo sucesivo "componente de software llamando API" tenga acceso y utilice una o más funciones, métodos, procedimientos, estructuras de datos y/u otros servicios proporcionados por el componente de software implementando API. Por ejemplo, una API permite a un desarrollador de un componente de software llamando API (el cual puede ser un desarrollador tercero) apalancar características especificadas proporcionadas por un componente de software implementando API . Puede haber un componente de software llamando API o puede haber más de un componente de software de ese tipo. Una API puede ser una interfaz de código fuente que un sistema de computadora o biblioteca de programa proporciona para soportar solicitudes para servicios de una aplicación de software. Una API puede ser especificada en términos de un lenguaje de programación que puede ser interpretativo o compilado cuando se construye una aplicación, en lugar de una descripción de bajo nivel explícito respecto a la manera en que los datos están desplegados en la memoria.

La API define el lenguaje y parámetros que utilizan los componentes de software llamando API cuando tienen acceso y utilizan características especificadas del componente de software implementando API. Por ejemplo, un componente de software llamando API tiene acceso a las características especificadas del componente de software implementando API a través de una o más llamadas de API (en ocasiones referidas como llamadas de función o método) expuestas por la API. El componente de software implementando API puede devolver un valor a través de la API en respuesta a una llamada de API de un componente de software llamando API. Aunque la API define la sintaxis y el resultado de una llamada de API (por ejemplo, como recurrir a la llamada de API y qué es lo que hace la llamada de API), la API típicamente no revela la manera en que la llamada de API logra la función especificada por la llamada de API. Diversas llamadas de función o mensajes son transferidos a través de una o más interfaces de programación de aplicación entre el software que llama (componente de software llamando API) y un componente de software implementando API. La transferencia de las llamadas de función o mensajes pueden incluir emitir, iniciar, invocar, llamar, recibir, devolver o responder a las llamadas de función o mensajes. Por lo tanto, un componente de software llamando API puede transferir una llamada y un componente de software implementando API puede transferir una llamada .

A manera de ejemplo, el componente de software implementando API y el componente de software llamando API pueden ser un sistema operativo, una biblioteca, una unidad de dispositivo, una API, un programa de aplicación, u otro módulo de software (se debiera entender que el componente de software implementando API y el componente de software llamando API pueden ser los mismos o diferentes tipos de módulo de software entre si) . El componente de software llamando API puede ser un componente de software local (es decir, en el mismo sistema de procesamiento de datos que el componente de software implementando API) o un componente de software remoto (es decir, en un sistema de procesamiento de dato diferente que el componente de software implementando API) que se comunica con el componente de software implementando API a través de la API sobre una red. Se debiera entender que un componente de software implementando API también puede actuar como un componente de software llamando API (es decir, éste puede realizar llamadas de API a una API expuesta por un componente de software implementando API diferente) y un componente de software llamando API también puede actuar como un componente de software implementando API mediante la implementación de una API que está expuesta a un componente de software llamando API diferente .

La API puede permitir múltiples componentes de software llamando API escritos en diferentes lenguajes de programación para comunicarse con el componente de software implementando API (por lo tanto, la API puede incluir características para trasladar llamadas y devoluciones entre el componente de software implementando API y el componente de software llamando API); sin embargo la API puede ser implementada en términos de un lenguaje de programación específico .

La figura 9 ilustra una modalidad de una arquitectura API la cual incluye un componente de software implementando API 910 (por ejemplo, un sistema operativo, una biblioteca, una unidad de 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 más funciones, métodos, clases, objetos, protocolos, estructuras de datos, formatos y/u otras características del componente de software implementando API que pueden ser utilizados por el componente de software llamando API 930. La API 920 puede especificar al menos una convención de llamada que especifique la manera en que una función en el componente de software implementando API recibe parámetros desde el componente de software llamando API y la manera en que la función devuelve un resultado al componente de software llamando API. El componente de software llamando API 930 (por ejemplo, un sistema operativo, una biblioteca, una unidad de dispositivo, una API, un programa de aplicación, u otro módulo de software) , realiza llamadas de API a través de la API 920 para tener acceso y utilizar las características del componente de software implementando API 910 que son especificadas por la API 920. El componente de software implementando API 910 puede devolver un valor a través de la API 920 al componente de software llamando API 930 en respuesta a una llamada de API .

Se apreciará que el componente de software implementando API 910 puede incluir funciones adicionales, métodos, clases, estructuras de datos y/u otras características que no están especificadas a través de la API 920 y que no están disponibles para el componente de software llamando API 930. Se debiera entender que el componente de software llamando API 930 puede estar en el mismo sistema que el componente de software implementando API 910 o puede estar ubicado remotamente y tiene acceso al componente de software implementando API 910 utilizando la API 920 sobre una red. Aunque la figura 9 ilustra un solo componente de software llamando API 930 interactuando con la API 920, se debiera entender que otros componentes de software llamando API, los cuales pueden estar escritos en lenguajes diferentes (o el mismo lenguaje) que el componente de software llamando API 930, pueden utilizar la API 920.

El componente de software implementando API 910, la API 920, y el componente de software llamando API 930 pueden estar almacenados en un medio legible por máquina, el cual incluye cualquier mecanismo para almacenar información en una forma legible mediante una máquina (por ejemplo, una computadora u otro sistema de procesamiento de datos) . Por ejemplo, un medio legible por máquina incluye discos magnéticos, discos ópticos, memoria de acceso aleatorio; memoria de solo lectura, dispositivos de memoria flash, etcétera .

Transición entre llamadas de circuito conmutado y videollamadas En algunas modalidades, un dispositivo de cliente puede cambiar de una llamada de circuito conmutado de audio solamente establecida a una videollamada, sin interrumpir significativamente la comunicación entre las partes. Por ejemplo, una parte de una llamada de circuito conmutado de audio solamente establecida selecciona cambiar a una videollamada (la cual incluye cuadros de video y audio) , lo cual ocasiona que un mensaje de iniciación de videollamada (una forma de un mensaje de invitación de sesión de comunicación en linea) sea enviado a los otros participantes de la llamada. Si los otros participantes aceptan la invitación de videollamada, se establecerá una conexión P2P entre los dispositivos de cliente de los participantes. Mientras se está negociando la conexión P2P, los participantes se pueden comunicar a través de la llamada de circuito conmutado de audio solamente. Después que se establece la conexión P2P y el video es comunicado entre las partes, los dispositivos de cliente cambian a la videollamada. La llamada de circuito conmutado de audio solamente después se corta, y los participantes se pueden comunicar a través de la videollamada.

La figura 12 ilustra un dispositivo de cliente ejemplar 1210 y una interfaz de usuario gráfica que es utilizada para cambiar entre llamadas de circuito conmutado y videollamadas de acuerdo con algunas modalidades. El dispositivo de cliente 1210 incluye el altavoz 1255 (el cual es utilizado durante el modo de teléfono en altavoz) , cámara de vista frontal 1260 (la cual captura video utilizado para la videollamada) , micrófono 1265 (el cual captura sonido) , el receptor/altavoz 1270 (el cual típicamente se utiliza cuando un usuario sostiene el dispositivo de cliente 1210 en su oído durante una llamada) , y la pantalla de despliegue 1275 (la cual es una pantalla táctil en algunas modalidades) . El dispositivo de cliente 1210 también puede incluir un conector de auricular/audífonos, un sensor de proximidad, un sensor de luz ambiental, acelerómetros , y otros componentes. Se debiera entender que la arquitectura del dispositivo de cliente 2110 es ejemplar y se pueden utilizar diferentes arquitecturas que incluyen una cantidad mayor o menor de componentes en las modalidades.

Tal como se ilustra en la figura 12, la interfaz de usuario gráfica 1205 actualmente está siendo desplegada en la pantalla de despliegue 1275. El usuario del dispositivo de cliente 1210 actualmente está participando en una llamada telefónica de audio solamente (con el número de teléfono (408) 555-1234). La interfaz de usuario gráfica 1205 incluye varias opciones diferentes para el usuario durante la llamada. Por ejemplo, el dispositivo de cliente 1210 ejecuta lo siguiente en respuesta a la recepción de la entrada de usuario (por ejemplo, golpeteando u otros gestos predefinidos en el icono apropiado) : finaliza la llamada cuando la entrada es aplicada al icono de finalizar llamada 1250, enmudece la llamada de audio en respuesta a la entrada que se está aplicando al icono de enmudecer 1220, despliega un teclado numérico (por ejemplo, para agregar números telefónicos adicionales a la llamada) en respuesta a la entrada que se está aplicando al icono de teclado 1225, coloca la llamada en-el teléfono en altavoz en respuesta a la entrada que se está aplicando al icono de altavoz 1230 (el cual cambia la salida de audio al altavoz 1255), agrega una llamada en respuesta a la entrada que se está aplicando al icono de agregar llamada 1235, coloca la llamada en espera en respuesta a la entrada que se está aplicando al icono de espera 1240, despliega la lista de contacto del usuario en respuesta a la entrada que se está aplicando al icono de contactos 1245, y cambia a una videollamada en respuesta a la entrada que se está aplicando al icono de videollamada 1215.

Las figuras 17-18 son diagramas de flujo que ilustran operaciones ejemplares para cambiar entre una llamada de circuito conmutado de audio solamente a una videollamada de acuerdo con una modalidad. Las figuras 17-18 se describirán con referencia a las modalidades ejemplares de las figuras 12, 13 y 14. Sin embargo, se debiera entender que las operaciones de las figuras 17-18 pueden ser ejecutadas por modalidades de la invención diferentes a aquéllas analizadas con referencia a las figuras 12, 13 y 14, y las modalidades analizadas con referencia a las figuras 12, 13 y 14 pueden ejecutar operaciones diferentes a aquéllas analizadas con referencia a las figuras 17-18.

Tal como se ilustra en la figura 17, los dispositivos de cliente 1210 y 1410 están conectados a través de una llamada de circuito conmutado de audio solamente 1710 (ya sea el usuario del dispositivo de cliente 1210 o el usuario del dispositivo de cliente 1410 que inició la llamada) . Por lo tanto, los usuarios del dispositivo de cliente 1210 y 1410 se pueden comunicar sobre una llamada de audio de circuito conmutado establecida. En el bloque 1712, el dispositivo de cliente 1210 recibe la entrada para cambiar a una videollamada . Por ejemplo, el usuario ha seleccionado cambiar a una videollamada golpeteando o ejecutando otro gesto definido en el icono de videollamada 1215.

El flujo entonces se mueve al bloque 1714, donde el dispositivo de cliente 1210 ocasiona que un mensaje de invitación de videollamada (el cual es una forma de un mensaje de solicitud de invitación de sesión de comunicación en linea) sea enviado al dispositivo de cliente 1410 (tal como es identificado por el número de teléfono del dispositivo de cliente 1410) . En algunas modalidades, el mensaje de solicitud de invitación de sesión de comunicación en línea es enviado utilizando la arquitectura descrita en las figuras 6 y 7. El flujo entonces se mueve al bloque 1716.

En el bloque 1716, el dispositivo de cliente 1210 determina si el audio en el presente está siendo enrutado a través del teléfono en altavoz (por ejemplo, el altavoz 1255) o a través de del conector de auricular/audífonos. En caso de ser así, entonces el flujo se mueve al bloque 1720. En caso de no ser así, entonces el flujo se mueve al bloque 1718 donde el dispositivo de cliente 1210 enruta el audio a través del teléfono en altavoz del dispositivo de cliente 1210 (por ejemplo, el altavoz 1255) y el flujo se mueve al bloque 1720.

En el bloque 1720, el dispositivo de cliente 1210 despliega una vista previa del video de lo que la cámara de vista frontal 1260 actualmente está capturando para permitir al usuario del dispositivo de cliente 1210 prepararse para la videollamada (por ejemplo, para colocar de manera apropiada el dispositivo de cliente 1210 para la videollamada). La figura 13 ilustra el dispositivo de cliente 1210 desplegando la vista previa de video 1310 que despliega el video de lo que la cámara de vista frontal 1260 actualmente está capturando. Aunque no se ilustra en la figura 13, en algunas modalidades un botón de cancelar también es desplegado en la GUI 1305 el cual permite al usuario cancelar la invitación de videollamada . El flujo se mueve del bloque 1720 al bloque 1722.

En el bloque 1726, el dispositivo de cliente 1410 recibe un mensaje de invitación de videollamada invitando al usuario del dispositivo de cliente 1410 a una videollamada. El flujo se mueve del bloque 1726 al bloque 1728. En algunas modalidades, el dispositivo de cliente 1410 tiene una arquitectura que es similar al dispositivo de cliente 1210. Por ejemplo, tal como se ilustra en la figura 14, el dispositivo de cliente 1410 incluye el altavoz 1455 (el cual se utiliza durante el modo de teléfono en altavoz) , la cámara de vista frontal 1460 (la cual captura el video utilizado para la videollamada), el micrófono 1465 (el cual captura sonido), el receptor/altavoz 1470 (el cual típicamente es utilizado cuando un usuario sostiene el dispositivo de cliente 1210 en su oído durante una llamada) , y la pantalla de despliegue 1475 (la cual es una pantalla táctil en algunas modalidades). El dispositivo de cliente 1410 también puede incluir un conector de auricular/audífonos, un sensor de proximidad, un sensor de luz ambiental, acelerómetros, y otros componentes. Se debiera entender que la arquitectura del dispositivo de cliente 1410 es ejemplar y que diferentes arquitecturas que incluyen una mayor o menor cantidad de componentes pueden ser utilizadas en las modalidades.

En el bloque 1728, el dispositivo de cliente 1410 reproduce uno o más tonos de audio indicando la recepción del mensaje para alertar al usuario del mensaje. Los tonos de audio pueden ser diferentes en diferentes modalidades (por ejemplo, los tonos de audio pueden ser similares a los tonos de llamada en espera utilizados en el dispositivo de cliente 1410 (aunque no son originados por el operador asociado con el dispositivo de cliente 1410) , los tonos de audio pueden ser únicos y específicos para las videollamadas , etcétera) . En algunas modalidades, el dispositivo de cliente 1410 no reproduce tonos de audio indicando la recepción del mensaje de invitación de videollamada si el dispositivo de cliente 1410 no está cerca del oído del usuario (por ejemplo, conforme a lo indicado por un sensor de proximidad del dispositivo de cliente 1410) y/o si la llamada actualmente está en modo de teléfono en altavoz. El flujo se mueve del bloque 1728 al bloque 1730.

En el bloque 1730, el dispositivo de cliente 1410 despliega el mensaje de invitación de videollamada y opcionalmente despliega una vista previa de video de lo que la cámara de vista frontal 1460 actualmente está capturando para permitir al usuario del dispositivo de cliente 1410 prepararse para la videollamada, y el flujo se mueve al bloque 1732. La figura 14 ilustra la GUI 1405 que despliega la invitación de videollamada 1440. Tal como se ilustra en la figura 14, la invitación de videollamada 1440 incluye un botón de aceptar 1432, un botón de rechazar 1434, y la vista previa de video 1430 (la cual muestra lo que la cámara de vista frontal 1460 actualmente está capturando). Aunque la figura 1410 ilustra la invitación de videollamada 1440 incluyendo la vista previa de video 1430 (es decir, la vista previa de video 1430 está contenida dentro de la invitación de videollamada 1440), en otras modalidades la vista previa de video 1430 está ubicada fuera y/o está traslapando la invitación de videollamada 1440. El usuario del dispositivo de cliente 1410 puede seleccionar el botón de aceptar 1432 para aceptar la invitación de videollamada (por ejemplo, golpeteando o ejecutando otro gesto predefinido para entrada en el botón de aceptar 1432) y puede seleccionar el botón de rechazar 1434 para rechazar la invitación de videollamada (por ejemplo, golpeteando o ejecutando otro gesto predefinido para entrada en el botón de rechazar 1434).

En el bloque 1732, el dispositivo de cliente 1410 determina si la entrada ha sido recibida para aceptar la videollamada (por ejemplo, si el usuario ha aceptado la invitación de videollamada seleccionando el botón de aceptar 1432) . Si el dispositivo de cliente 1410 recibe la entrada para aceptar la videollamada, entonces el flujo se mueve al flujo 1734, de otra manera el flujo se mueve al bloque 1736. En el bloque 1734, el dispositivo de cliente 1410 ocasiona que un mensaje de aceptación de videollamada sea transmitido al dispositivo de cliente 1210. En algunas modalidades, el mensaje de aceptar es transmitido al dispositivo de cliente 1210 utilizando la arquitectura descrita en las figuras 6 y 7. El flujo entonces se mueve al bloque 1810.

En el bloque 1736, se determina si se ha recibido la entrada para rechazar la solicitud de videollamada (por ejemplo, si el usuario ha rechazado la invitación de videollamada seleccionando el botón de rechazar 1434). Si el dispositivo de cliente 1410 recibe la entrada para rechazar la invitación de videollamada, entonces el flujo se mueve al bloque 1738, de otra manera el flujo se mueve de regreso al bloque 1732. En el bloque 1738, el dispositivo de cliente 1410 ocasiona que un mensaje de rechazo de videollamada sea transmitido al dispositivo de cliente 1210. El dispositivo de cliente 1410 también puede borrar la invitación de videollamada 1440 y detener el despliegue de la vista previa de video 1430. En algunas modalidades, el mensaje de rechazo de videollamada es transmitido 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 un mensaje de aceptación de videollamada desde el dispositivo de cliente 1410. En caso de ser asi, entonces el flujo se mueve al bloque 1816, de otra manera el flujo se mueve al bloque 1724 donde el dispositivo de cliente 1210 determina si ha recibido un mensaje de rechazo de videollamada desde el dispositivo de cliente 1410. En caso de ser asi, entonces el flujo se mueve al bloque 1910, de otra manera el flujo se mueve de regreso al bloque 1722.

Con referencia a la figura 18, en el bloque 1810 (el usuario en el dispositivo de cliente 1410 ha aceptado la invitación de videollamada) , el dispositivo de cliente 1410 determina si el audio actualmente está siendo enrutado a través del teléfono en altavoz (por ejemplo, el altavoz 1470) o el auricular del dispositivo de cliente 1410. En caso de no ser asi, entonces el flujo se mueve al bloque 1812 donde la ruta de audio es cambiada del altavoz 1455 al teléfono en altavoz (por ejemplo, el altavoz 1470) , y el flujo se mueve al bloque 1814. Si el audio ya está siendo enrutado a través del teléfono en altavoz o un auricular, entonces el flujo se mueve al bloque 1814.

En el bloque 1814, el dispositivo de cliente 1410 despliega una vista previa de video de lo que la cámara de vista frontal 1460 actualmente está capturando. La operación en el bloque 1814 es ejecutada solamente si la vista previa de video actualmente no está siendo desplegada como un resultado de la operación en el bloque 1730. El flujo se mueve 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 si. La conexión P2P puede ser establecida a través de mecanismos conocidos (por ejemplo, utilizando el Establecimiento de Conectividad de Internet (ICE) u otros mecanismos de conectividad P2P conocidos). Asumiendo que la conexión P2P es establecida con éxito, el flujo se mueve de los bloques 1818 y 1820 a los bloques 1822 y 1824 respectivamente, donde los dispositivos de cliente 1210 y 1410 comienzan a transmitir video entre si sobre la conexión P2P (el video de las cámaras de video de vista frontal 1260 y 1460). En algunas modalidades, el video incluye tanto cuadros de video como audio correspondiente (capturado por los micrófonos 1265 y 1465 de los dispositivos de cliente 1210 y 1410 respectivamente) , mientras que en otras modalidades el video y audio son corrientes separadas comunicadas a través de la conexión P2P.

El flujo se mueve de los bloques 1822 y 1824 a los bloques 1826 y 1828 respectivamente. En los bloques 1826 y 1828, los dispositivos de cliente 1210 y 1410 respectivamente determinan si han recibido uno o más cuadros de video de su par. En caso de ser asi, entonces el flujo se mueve de los bloques 1826 y 1828 a los bloques 1830 y 1832 respectivamente. En caso de no ser asi, entonces el flujo permanece en los bloques 1826 y 1828 hasta que uno o más cuadros de video han sido recibidos. En algunas modalidades, los dispositivos de cliente 1210 y 1410 esperan a recibir cuadros de video unos de otros por una cierta cantidad de tiempo y en caso que estos no intercambien cuadros de video durante ese tiempo se emprende una acción alternativa. Por ejemplo, en algunas modalidades, la videollamada es cancelada y un mensaje es desplegado en las pantallas de los dispositivos de cliente 1210 y 1410 respecto a que la videollamada no pudo ser establecida. La videollamada puede no establecerse por un número de motivos incluyendo que el ancho de banda es insuficiente para la videollamada, que los cuadros de video no han podido ser transmitidos o recibidos, etcétera. Aunque en algunas modalidades los dispositivos de cliente esperan un solo cuadro de video antes de proceder, en otras modalidades los dispositivos de cliente esperan a recibir un número de cuadros durante un periodo de tiempo determinado (por ejemplo, un flujo de cuadros de video) antes de proceder.

En los bloques 1830 y 1832, los dispositivos de cliente 1210 y 1410 respectivamente cambian a la videollamada . La transición a la videollamada incluye desplegar el video que está siendo recibido y cambiar la ruta de audio de la llamada de audio de circuito conmutado a la videollamada. En algunas modalidades, la vista previa de video (por ejemplo, la vista previa de video 1310) se mueve a una esquina de la pantalla (y se encoge de tamaño) y el video que está siendo recibido desde el par es revelado. Por lo tanto, se debiera entender que hasta que la ruta de audio ha sido cambiada de la llamada de audio de circuito conmutado a la videollamada, los participantes se pueden comunicar a través de la llamada de audio de circuito conmutado (es decir, la llamada de audio de circuito conmutado permanece establecida mientras que se está negociando la videollamada). Después de cambiar a la videollamada, la llamada de audio de circuito conmutado es cortada. Por lo tanto, el flujo se mueve de los bloques 1830 y 1832 a los bloques 1834 y 1836 respectivamente donde la llamada de audio de circuito conmutado es cortada.

Las figuras 15 y 16 ilustran los dispositivos de cliente 1210 y 1410 respectivamente después de que han cambiado a la videollamada . Tal como se ilustra' en la figura 15, el dispositivo de cliente 1210 despliega el video 1510, el cual es video de lo que está siendo capturado por la cámara de vista frontal 1460 del dispositivo de cliente 1410. El dispositivo de cliente 1210 también despliega el video 1515, el cual es video de lo que está siendo capturado por la cámara de vista frontal 1260. La GUI 1505 también incluye el botón de finalizar video 1520 y el botón de finalizar video y llamada 1625. El botón de finalizar video 1520 permite al usuario finalizar la videollamada y regresar a una llamada de audio solamente. El botón de finalizar video y llamada 1525 permite al usuario finalizar la videollamada completamente (por ejemplo, finalizar la conversación con el usuario en el dispositivo de cliente 1410). Tal como se ilustra en la figura 16, el dispositivo de cliente 1410 despliega el video 1610, el cual es video de lo que está siendo capturado por la cámara de vista frontal 1260 del dispositivo de cliente 1210. El dispositivo de cliente 1410 también despliega el video 1615, el cual es video de lo que está siendo capturado por la cámara de vista frontal 1460. La GUI 1605 también incluye el botón de. finalizar video 1620 y el botón de finalizar video y llamada 1625.

La figura 19 es un diagrama de flujo que ilustra operaciones ejemplares ejecutadas en un dispositivo de cliente que ha recibido un mensaje de rechazo de videollamada de acuerdo con una modalidad. En el bloque 1910, el dispositivo de cliente 1210 recibe un mensaje de rechazo de videollamada (el usuario en el dispositivo de cliente 1410 ha rechazado la invitación de videollamada) . El flujo se mueve del bloque 1910 al bloque 1912 y el dispositivo de cliente 1210 despliega un mensaje de videollamada rechazada y opcionalmente reproduce uno o más tonos de audio indicando la recepción del mensaje de rechazo de videollamada. El flujo entonces se mueve al bloque 1914 donde el dispositivo de cliente 1210 deja de desplegar su propia vista previa de video. El dispositivo de cliente 1210 también puede solicitar al usuario retornar a la salida de audio original (por ejemplo, a través del altavoz 1270) en caso que la salida de audio fuese previamente cambiada al teléfono en altavoz en el bloque 1718.

La figura 20 es un diagrama de flujo que ilustra operaciones ejemplares ejecutadas en un dispositivo de cliente para cambiar de una videollamada a una llamada de circuito conmutado de acuerdo con una modalidad. Una videollamada 2010 es establecida entre los dispositivos de cliente 1210 y 1410 (la videollamada puede ser establecida de acuerdo con mecanismos descritos en referencia a las figuras 17 y 18 o puede ser establecida sin cambiar de una llamada de audio de circuito conmutado) . En el bloque 1712, el dispositivo de cliente 1210 recibe la entrada para cambiar a una llamada de circuito conmutado de audio solamente. Por ejemplo, con referencia a la figura 15, el usuario del dispositivo de cliente 1210 ha seleccionado el botón de finalizar video 1520 (por ejemplo, golpeteando o ejecutando otro gesto predefinido en el botón de finalizar video 1520) . El dispositivo de cliente 1210 entonces transmite un mensaje al dispositivo de cliente 1410 que indica una transición a una llamada de circuito conmutado de audio solamente 2014.

El dispositivo de cliente 1210 entonces inicia una solicitud de llamada de audio de circuito conmutado para el dispositivo de cliente 1410 (por ejemplo, el dispositivo de cliente 1210 llama automáticamente al número de dispositivo de cliente 1410). En algunas modalidades, esto es ejecutado en el fondo y no requiere la interacción del usuario. La llamada es enrutada a través de un número de elementos de red de la infraestructura de red del operador (por ejemplo, estaciones base, centros de conmutación móviles, etcétera) .

El dispositivo de cliente 1410 recibe y contesta la llamada de circuito conmutado 2020. En una modalidad, el dispositivo de cliente 1410 despliega la solicitud de llamada entrante y puede reproducir tonos de audio indicando la solicitud de llamada entrante (por ejemplo, tonos de llamada en espera u otros tonos) , y requiere la intervención del usuario para contestar la llamada. En otra modalidad, el dispositivo de cliente 1410 contesta automáticamente la llamada sin la intervención del usuario (y puede o no reproducir tonos de audio indicando la solicitud de llamada entrante) . Después que la llamada es contestada, la llamada de circuito conmutado de audio solamente es establecida 2030 entre los dispositivos de cliente 1210 y 1410.

Después que la llamada de circuito conmutado de audio solamente es establecida con éxito, los dispositivos de cliente 1210 y 1410 cambian a la llamada de audio solamente 2032 y 2034 respectivamente. Por ejemplo, la transición a la llamada de audio solamente incluye cambiar la ruta de audio de la videollamada a la llamada de circuito conmutado, deteniendo la reproducción del video que está siendo recibido, y deteniendo la transmisión del video. El dispositivo de cliente también puede detener el despliegue de la vista previa de video. Por lo tanto, se debiera entender que aunque la llamada de circuito conmutado de audio solamente está siendo negociada, los usuarios en los dispositivos de cliente 1210 y 1410 se pueden comunicar a través de la llamada de video (es decir, la videollamada permanece establecida mientras la llamada de circuito conmutado de audio solamente está siendo negociada) . Después de la transición exitosa a la llamada de circuito conmutado de audio solamente, los dispositivos de cliente 1210 y 1410 finalizan la conexión P2P 2040. Los usuarios en los dispositivos de cliente 1210 y 1410 entonces se pueden comunicar a través de la llamada de circuito conmutado de audio solamente.

Aunque las modalidades de la invención se han descrito en relación a una videollamada que tiene dos participantes, las modalidades no quedan limitadas a esto ya que puede haber más participantes en la videollamada. En dichas modalidades, el dispositivo de cliente puede desplegar múltiples corrientes de video de cada participante diferente en la videocharla.

Aunque modalidades de la invención han sido descritas en relación a una videollamada que tiene dos participantes donde cada participante transmite video, las modalidades no quedan limitadas a esto. Por ejemplo, en algunas modalidades solamente una sola parte puede estar transmitiendo video a los otros participantes y esos otros participantes solo pueden estar transmitiendo audio. En algunas modalidades, cada participante puede determinar si suspende la transmisión de video en cualquier punto durante la videollamada .

En algunas modalidades, la calidad del video transmitido durante la llamada es ajustada dinámicamente con base en las condiciones de la red. Por ejemplo, durante periodos en que la red está congestionada, la tasa de transferencia de bits del video se puede reducir. De manera similar, durante periodos en los cuales la red está relativamente libre de congestión, la tasa de transferencia de bits del video se puede incrementar. En algunas modalidades, si las condiciones de la red evitan que el video sea transmitido, los dispositivos de cliente participantes cambian automáticamente a una llamada de circuito conmutado de audio solamente. Por lo tanto, si el ancho de banda cae por debajo de un cierto nivel, los dispositivos de cliente participantes pueden cambiar automáticamente a una llamada de circuito conmutado de audio solamente (o pueden solicitar al usuario cambiar a una llamada de circuito conmutado de audio solamente) .

Soporte de servicios manos libres a través de un dispositivo manos libres para videollamadas IP En una modalidad, los dispositivos de cliente incluyen funcionalidad para soportar la interacción con un dispositivo manos libres (por ejemplo, un auricular, un equipo de carro) sobre una WPAN (Red de Area Personal Inalámbrica) (por ejemplo, Bluetooth, ZigBee, etcétera) incluyendo el soporte para administrar videollamadas IP con la unidad manos libres. La figura 32 es un diagrama de bloques que ilustra un dispositivo de cliente conectado en interfaz con una unidad manos libres para administrar videollamadas IP de acuerdo con una modalidad. El dispositivo de cliente 3210 incluye la capacidad para iniciar videollamadas (por ejemplo, invitar a uno o más destinatarios a una sesión de comunicación en línea que es una videollamada) y la capacidad para aceptar videollamadas. En algunas modalidades, el dispositivo de cliente 3210 también incluye componentes de telefonía celular para hacer y recibir llamadas telefónicas celulares y/o tener acceso a la Internet u otra red a través de una conexión celular.

Tal como se muestra en la figura 32, el dispositivo de cliente 3210 incluye el administrador de videollamadas IP 3250, el administrador de telefonía 3260, el administrador de audio 3275, y el administrador de manos libres 3270. En algunas modalidades, el dispositivo de cliente 3210 también incluye el administrador de llamadas celulares 3255. El administrador de videollamadas IP 3250 administra una aplicación de videollamadas P2P incluyendo el establecimiento de una videollamada P2P IP sobre la red IP 3235 a través del servicio de videollamada IP 3230 tal como se describió previamente en este documento. En una modalidad, el servicio de videollamada IP 3230 incluye uno o más del servicio de invitación 620, el servicio de notificación de empuje 640, el servicio de registro 630 y/o el servicio de registro 2130, y el servicio de retransmisión 650. El administrador de llamadas celulares 3255 administra los componentes celulares para hacer y recibir llamadas telefónicas celulares de audio solamente sobre la red celular 3245 utilizando el servicio de llamada de audio celular 3240.

El administrador de videollamadas IP 3250 y el administrador de llamadas celulares 3255 están acoplados con el administrador de telefonía 3260. El administrador de telefonía 3260 administra las operaciones de telefonía tanto para el administrador de videollamadas IP 3250 como para el administrador de llamadas celulares 3255 incluyendo el rastreo del historial de la llamada (tanto para videollamadas como para llamadas celulares de audio solamente) y otra información relacionada con las llamadas. El administrador de telefonía 3260 también se conecta en interfaz con el administrador de manos libres 3270 para proporcionar servicios manos libres a través de un dispositivo manos libres externo para videollamadas IP y llamadas celulares en beneficio del administrador de videollamadas IP 3250 y el administrador de llamadas celulares 3255. En una modalidad, un formato de mensaje común es utilizado entre el administrador de videollamadas IP 3250, el administrador de llamadas celulares 3255, y el administrador de telefonía 3260, para proporcionar soporte para los servicios manos libres para diferentes tipos de protocolos y llamadas ( ideollamada IP y llamada celular de audio solamente). Por lo tanto, el administrador de telefonía 3260 proporciona soporte similar para servicios manos libres sin considerar si los servicios manos libres son para una videollamada IP o una llamada celular de audio solamente. Esto también evita que el administrador de manos libres 3270 tenga la necesidad de entender si los servicios manos libres son para una videollamada IP o para una llamada celular de audio solamente de manera que comandos estándar que pueden ser entendidos por los dispositivos manos libres pueden ser utilizados para proporcionar servicios manos libres para videollamadas IP asi como para llamadas celulares de audio solamente.

En una modalidad, el administrador de telefonía 3260 también funciona como árbitro entre el administrador de videollamadas IP 3250 y el administrador de llamadas celulares 3255. Por ejemplo, el administrador de telefonía 3260 puede ocasionar que una videollamada IP sea colocada en espera para cambiar a una llamada celular de audio solamente establecida y/o para ocasionar que una llamada celular de audio solamente sea colocada en espera para cambiar a una videollamada IP.

El administrador de manos libres 3270 proporciona soporte para procesamiento de manos libres. En una modalidad, el administrador de manos libres 3270 implementa una pila de protocolo Bluetooth para conexión con dispositivos manos libres que cumplen con Bluetooth tal como el auricular Bluetooth y equipos para carro Bluetooth. En una modalidad específica, el administrador de manos libres 3270 implementa un perfil de auricular Bluetooth (por ejemplo, conforme a lo definido en el Perfil de Auricular (HSP) 1.2 especificación del 18 de Diciembre de 2008) y/o un perfil manos libres Bluetooth (por ejemplo, conforme a lo definido en el Perfil de Manos Libres 1.5 (HFP 1.5) especificación del 25 de Noviembre de 2005). El administrador de manos libres 3270 permite que la unidad manos libres 3220 actúe como un relé de auditoria para una videollamada IP y para una llamada a celular de audio solamente sobre la WPAN 3225, asi como que ejecute otros servicios manos libres. Por ejemplo, en el caso de una videollamada IP, la porción de audio de la llamada puede ser enrutada a través de la unidad manos libres 3220 en lugar de un altavoz del dispositivo de cliente 3210 mientras que la porción de video de la llamada sigue siendo desplegada por el dispositivo de cliente 3210 (o por un despliegue anexo) . La unidad manos libres 3220 también incluye un micrófono para capturar información de audio que después es transmitida al dispositivo de computación de cliente 3210. Por lo tanto, un usuario puede utilizar la unidad manos libres 3220 para hablar y/o escuchar el audio durante una videollamada IP y/o durante una llamada celular de audio solamente.

El administrador de manos libres 3270 también soporta otros servicios manos libres en respuesta a la recepción de la entrada desde la unidad manos libres 3220 incluyendo la ejecución de uno o más de los siguientes para videollamadas IP y/o llamadas celulares de audio solamente: permitir a un usuario contestar una llamada; finalizar una llamada; colocar una llamada en espera; enmudecer una llamada; aumentar/disminuir el volumen de una llamada; transferir audio al dispositivo de cliente; transferir audio a la unidad manos libres; colocar una llamada; y volver a marcar el último número. Por lo tanto, un usuario puede utilizar la unidad manos libres 3220 para responder una videollamada IP, finalizar una llamada IP, colocar una videollamada IP en espera y/o en enmudecer, aumentar/reducir el volumen de una videollamada IP, transferir audio de la videollamada IP para que sea emitido a un altavoz del dispositivo de cliente 3210 , transferir audio desde el dispositivo de cliente 3210 a la unidad manos libres 3220 , colocar una videollamada IP, y volver a marcar la última videollamada IP.

El administrador de videollamadas IP 3250 , el administrador de llamadas celulares 3255 , y el administrador de manos libres 3270 también están acoplados con el administrador de audio 3275 . El administrador de audio 3275 enruta el audio de las videollamadas IP y las llamadas celulares de audio solamente a través de diferentes fuentes.

Por ejemplo, el administrador de audio 3275 puede ocasionar que el audio sea emitido a través de un altavoz del dispositivo de cliente 3210 conveniente para el modo de teléfono en altavoz, a través de un altavoz del dispositivo de cliente 3210 utilizado cuando un usuario sostiene el dispositivo de cliente 3210 en su oído durante una llamada, a través de un conector de auricular/audífonos a un auricular o audífono que está enchufado en el dispositivo de cliente 3210, y a través de una unidad manos libres en par (tal como la unidad manos libres 3220).

La figura 33 ilustra el dispositivo de cliente 3210 recibiendo una invitación para una videollamada, ocasionando que suene el dispositivo manos libres, recibiendo una indicación de respuesta del dispositivo manos libres, estableciendo la videollamada, y enrutando el audio al dispositivo manos libres de acuerdo con una modalidad. La figura 33 se describirá con referencia a la modalidad ejemplar de la figura 32. Sin embargo, se debiera entender que las operaciones de la figura 33 pueden ser ejecutadas por modalidades diferentes a aquéllas analizadas con referencia a la figura 32, y las modalidades analizadas con referencia a la figura 32 pueden ejecutar operaciones diferentes a aquéllas analizadas con referencia a la figura 33.

En la operación 3310, el administrador de videollamadas IP 3250 recibe una invitación de videollamada IP desde otro dispositivo de cliente que invita al usuario del dispositivo de cliente 3210 a participar en una videollamada IP. La invitación de videollamada IP. puede asumir la forma de la invitación tal como se describió previamente aqui . El administrador de videollamadas IP 3250 procesa la solicitud de invitación incluyendo ocasionar que la invitación sea desplegada en la operación 3315. Por ejemplo, la solicitud de invitación puede ser desplegada en una manera similar a la invitación de videollamada ejemplar 1410 que se ilustra en la figura 14.

Además, el administrador de videollamadas IP 3250 genera y transmite un objeto de llamada 3320 al administrador de telefonía 3260. El objeto de llamada 3320 incluye un conjunto de parámetros referentes a la llamada. Por ejemplo, los parámetros del objeto de llamada incluyen uno o más de un estatus de la llamada (por ejemplo, conectando), y el identificador de participante de llamada (por ejemplo, el número de teléfono, dirección de correo electrónico, u otro identificador de punto final de sesión de comunicación en línea) , una hora de inicio, una indicación respecto a si es una llamada de salida o de entrada, y un identificador de llamada utilizado internamente para identificar la llamada.

En una modalidad, el objeto de llamada 3320 es un objeto de llamada genérico que, aunque los parámetros están basados en la información de la invitación de videollamada IP, es en un formato que es común para las solicitudes de invitación de videollamada IP y las llamadas celulares de audio solamente entrantes. Por lo tanto, cuando se recibe una llamada celular de audio solamente entrante, el administrador de llamadas celulares 3255 genera un objeto de llamada entrante del mismo formato. Por lo tanto, desde la perspectiva del administrador de telefonía 3260, una solicitud de invitación de videollamada IP o una llamada celular de audio solamente entrante parecen ser las mismas.

El administrador de telefonía 3260 almacena la información en el objeto de llamada 3320 como parte de una estructura de historial de llamadas. El administrador de telefonía 3260 también genera y envía un mensaje de llamada entrante 3322 al administrador de manos libres 3270. En una modalidad, el administrador de telefonía 3260 solamente envía el mensaje de llamada entrante 3322 si hay un dispositivo manos libres tal como el dispositivo de cliente manos libres 3220 en par con el dispositivo cliente 3210 (pqr ejemplo, el administrador de telefonía 3260 primero revisa si hay un dispositivo manos libres que esté en par con el dispositivo de cliente 3210) . En otras modalidades, el administrador de telefonía 3260 envía el mensaje de llamada entrante 33220 al administrador de manos libres 3270 sin considerar si hay un dispositivo manos libres en par y el administrador de manos libres 3270 determina si tira/ignora el mensaje o lo procesa dependiendo si hay un dispositivo manos libres en par. Para los propósitos de la figura 33 y las figuras posteriores, se asumen que el dispositivo manos libres 3220 está en par con el dispositivo de computación de cliente 3210. En una modalidad, el mensaje de llamada entrante 3322 incluye el identificador de llamada.

En respuesta a la recepción del mensaje de llamada entrante 3320, el dispositivo manos libres 3270 ocasiona que una serie de mensajes sean transmitidos al dispositivo manos libres 3220 alertando a éste y al usuario respecto a que hay una llamada entrante. Tal como se muestra en la figura 33, el administrador de manos libres establece una conexión de audio 3325 (por ejemplo, un enlace Orientado a la Conexión Sincrónica (SCC) ) con el dispositivo manos libres 3220 antes de enviar un mensaje de tono sonoro 3330 sobre la conexión de audio establecida 3325. El mensaje de tono sonoro es seleccionado por el dispositivo de cliente 3210 y puede ser personalizado por el usuario del dispositivo de cliente 3210. En una modalidad, el mensaje de tono sonoro para videollamadas IP es diferente que el tono sonoro para llamadas celulares de audio solamente. En otra modalidad, una conexión de audio no es establecida hasta después que la llamada es contestada. En dicha modalidad, un mensaje de alerta sonora es enviado al dispositivo manos libres 3220 el cual entonces determina localmente si reproduce un tono sonoro para alertar al usuario de la llamada entrante (el mensaje de alerta sonora también puede ser enviado antes de enviar el mensaje de tono sonoro 3330) . En dicha modalidad, el mensaje de alerta sonora puede ser enviado múltiples veces al dispositivo manos libres 3220 hasta que la llamada es contestada o terminada.

Cierto tiempo después de recibir el mensaje de alerta sonora y/o el mensaje sonoro 3330, el dispositivo manos libres 3220 transmite el mensaje contestado 3335 que indica que un usuario ha contestado la llamada. Por ejemplo, el usuario ha presionado un botón de responder en su dispositivo manos libres 3220 o de otra manera ha emprendido una acción en el dispositivo manos libres 3220 para responder la llamada. El administrador de manos libres 3270 recibe el mensaje contestado 3335 y transmite un mensaje respondido 3340 al administrador de telefonía 3260. En una modalidad, el mensaje respondido 3340 incluye el identificador de llamada. Aunque no se ilustre en la figura 33, el administrador de manos libres 3270 también puede transmitir un mensaje de reconocimiento al dispositivo manos libres 3220 en respuesta a la recepción del mensaje contestado 3335.

El administrador 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 el mensaje 3340 con la información almacenada del objeto de llamada 3320) y transmite un mensaje 3345 al administrador de videollamada IP 3250 que indica que la llamada ha sido contestada. En respuesta a la recepción de este mensaje, el administrador de videollamadas IP 3250 establece una videollamada IP en una operación 3350. Por ejemplo, el administrador de videollamadas IP 3250 ocasiona que un mensaje de aceptación de videollamada IP sea enviado a un servicio de invitación tal como se describió previamente aquí y se establece una conexión P2P (ya sea directa o a través de un relé) con el dispositivo de computación que transmitió la invitación .

Cierto tiempo después que la videollamada IP ha sido establecida, el administrador de videollamadas IP 3250 transmite un objeto de llamada 3355 al administrador de telefonía 3260. El objeto de llamada 3355 incluye un conjunto similar de parámetros que el objeto de llamada 3320 con la excepción de que el estatus ha cambiado de conectando a conectado. En una modalidad, el objeto de llamada 3355 es un objeto de llamada genérico que está en un formato que es común tanto para videollamadas IP establecidas como para llamadas celulares de audio solamente conectadas.

Además, cierto tiempo después que la videollamada IP ha sido establecida, el administrador de audio 3275 enruta la porción de audio de la videollamada IP establecida a través del dispositivo manos libres 3220. En una modalidad, el administrador de videollamada IP 3250 o el administrador de telefonía 3260 solicita al administrador de audio 3275 enrutar el audio a través del dispositivo manos libres. El administrador de audio 3275 también puede transmitir un mensaje 3360 al administrador de manos libres 3270 que indica que la ruta de audio será modificada para pasar al dispositivo manos libres 3220. Si una conexión de audio no se ha establecido todavía, el administrador de manos libres 3270 establecerá una conexión de audio con el dispositivo manos libres 3220. Asumiendo que hay una conexión de audio establecida, la porción de audio 3365 de la videollamada es enrutada al dispositivo manos libres 3220. Por lo tanto, la porción de audio de la videollamada es manejada a través del dispositivo manos libres 3220 mientras que la porción de video de la videollamada es desplegada en el dispositivo de cliente 3210.

La figura 34 ilustra el dispositivo de cliente 3210 iniciando una videollamada y enrutando el audio para la videollamada establecida a través de un dispositivo manos libres de acuerdo con una modalidad. La figura 34 se describirá con referencia a la modalidad ejemplar de la figura 32. Sin embargo, se debiera entender que las operaciones de la figura 34 pueden ser ejecutadas por modalidades diferentes a aquéllas analizadas con referencia a la figura 32, y las modalidades analizadas con referencia la figura 32 pueden ejecutar operaciones diferentes a aquéllas analizadas con referencia a la figura 34.

En la operación 3410, el administrador de videollamadas IP 3250 ocasiona que uno o más mensajes de invitación de videollamada IP sean enviados a otros dispositivos de cliente para invitar a usuarios a una videollamada IP. Los mensajes de invitación de videollamada IP pueden asumir la forma de la invitación tal como se describió aquí previamente. El administrador de videollamada IP 3250 genera y transmite un objeto de llamada 3415 al administrador de telefonía 3260. Similar al objeto de llamada 3320, el objeto de llamada 3415 incluye un conjunto de parámetros referentes a la llamada y es en un formato genérico. El administrador de telefonía 3260 almacena la información en el objeto de llamada 3415 como parte de una estructura de historial de llamadas.

En una modalidad, el administrador de telefonía 3260 también genera y envía un mensaje de llamada de salida 3420 al administrador de manos libres 3270 que indica que hay una llamada de salida. En respuesta a este mensaje, el administrador de manos libres 3270 establece una conexión de audio 3425 con el dispositivo manos libres 3220 (en caso que se vaya a enviar un tono sonoro en-banda personalizado) y después transmite un mensaje de tono sonoro 3430 al dispositivo manos libres 3220. En otra modalidad, el administrador de manos libres 3270 transmite solamente un mensaje de alerta de tono sonoro al dispositivo manos libres 3220 en lugar de establecer una conexión de audio y transmitir un tono sonoro en-banda.

Cierto tiempo después de enviar la invitación de videollamada IP, el administrador de videollamadas IP 3250 recibe un mensaje de aceptación de videollamada IP 3435, el cual puede asumir la forma de un mensaje de aceptación de videollamada tal como se describió aquí previamente. Después de recibir este mensaje, se establece una videollamada IP P2P con el dispositivo de cliente de aceptación en la operación 3440 (por ejemplo, se establece una conexión P2P (ya sea directa o a través de un relé) con el dispositivo de computación que aceptó la invitación) .

Cierto tiempo después que se ha establecido la videollamada IP, el administrador de videollamadas IP 3250 transmite un objeto de llamada 3445 al administrador de telefonía 3260. El objeto de llamada 3445 incluye un conjunto similar de parámetros como el objeto de llamada 3415 con la excepción de que el estatus ha cambiado de conectando a conectado. El objeto de llamada 3445 también está en un formato genérico. Además, cierto tiempo después que se ha establecido la videollamada IP, el administrador de audio 3275 enruta la porción de audio de la videollamada IP establecida a través del dispositivo manos libres 3220. En una modalidad, el administrador de videollamadas IP 3250 o el administrador de telefonía 3260 solicita al administrador de audio 3275 enrutar el audio a través del dispositivo manos libres. El administrador de audio 3275 también puede transmitir un mensaje 3455 al administrador de manos libres 3270 que indica que la ruta de audio será modificada para ir al dispositivo manos libres 3220. Si no se ha establecido todavía una conexión de audio, el administrador de manos libres 3270 establecerá una conexión con el dispositivo manos libres 3220. Asumiendo que hay una conexión de audio establecida, el puerto de audio 3460 de la videollamada es enrutado al dispositivo manos libres 3220. Por lo tanto, la porción de audio de la videollamada es entregada a través del dispositivo manos libres 3220 mientras que la- porción de video de la videollamada es desplegada en el dispositivo de cliente 3210.

La figura 35 ilustra el dispositivo de cliente 3210 iniciando una videollamada en respuesta a la recepción de una solicitud de llamada desde el dispositivo manos libres 3220 de acuerdo con una modalidad. La figura 35 se describirá con referencia a la modalidad ejemplar de la figura 32. Sin embargo, se debiera entender que las operaciones de la figura 35 pueden ser ejecutadas por modalidades diferentes a aquéllas analizadas con referencia a la figura 32, y las modalidades analizadas con referencia a la figura 32 pueden ejecutar operaciones diferentes a aquéllas analizadas con referencia a la figura 35.

El administrador de manos libres 3270 recibe una solicitud de llamada 3510 desde el dispositivo manos libres 3220. La solicitud de llamada 3510 puede ser generada en respuesta a un usuario que selecciona un número de teléfono u otro identificador de punto final de sesión de comunicación en linea al que se vaya a llamar. Por ejemplo, el usuario puede seleccionar un botón de remarcar en el dispositivo manos libres 3220 el cual solicita que la última llamada vuelva a ser marcada. El administrador de manos libres 3270 transmite un mensaje de solicitud de llamada 3520 al administrador de telefonía 3260. El administrador de telefonía 3260 determina si el mensaje de solicitud de llamada 3520 está solicitando una llamada a un identificador que está asociado con una videollamada (y, por lo tanto, el mensaje de solicitud de llamada debiera ser enviado al administrador de videollamada IP 3250) o asociado con un número de teléfono para una llamada celular de audio solamente (y por lo tanto debiera ser enviado al administrador de llamadas celulares 3255). Por ejemplo, en caso que la solicitud de llamada 3520 sea una solicitud de remarcar, el administrador de telefonía 3260 tiene acceso a la última llamada marcada, la cual puede ser una videollamada IP o una llamada celular de audio solamente, para determinar a dónde enviar la solicitud de llamada. Tal como se muestra en la figura 35, el administrador de telefonía envía el mensaje de solicitud de llamada 3525 al administrador de videollamadas IP 3250. El mensaje de solicitud de llamada 3525 incluye el identificador del participante solicitado para la videollamada (por ejemplo, un número de teléfono, una dirección de correo electrónico, u otro identificador de punto final de sesión de comunicación en línea) . En respuesta a la recepción del mensaje de solicitud de llamada 3525, el administrador de videollamadas IP 3250 ocasiona que un mensaje de invitación de videollamada IP sea enviado al participante indicado en la operación 3410 tal como se describió en la figura 34. Las operaciones restantes mostradas en la figura 35 son ejecutadas tal como se describió con referencia a la figura 34. Por lo tanto, el dispositivo de cliente 3210 soporta el establecimiento de una videollamada IP como resultado de la acción del usuario en un dispositivo manos libres en par.

La figura 36 ilustra el dispositivo de cliente 3210 enrutando audio de una videollamada establecida al dispositivo manos libres 3220 de acuerdo con una modalidad. Hay una videollamada IP establecida 3610 entre el dispositivo de cliente 3210 y uno o más dispositivos de cliente diferentes. La porción de audio de esta llamada actualmente está siendo emitida por un altavoz del dispositivo de cliente 3210 o a través de auriculares que están enchufados en el dispositivo de cliente 3210. En la operación 3615, el administrador de videollamadas IP 3250 recibe la entrada para transferir el audio al dispositivo manos libres 3220. Por ejemplo, un usuario del dispositivo de cliente 3210 ha proporcionado entrada a la aplicación de videollamada IP para transferir el audio a un dispositivo manos libres en par. En respuesta a la recepción de dicha entrada, el administrador de videollamadas IP 3250 envía una solicitud de enrutar audio 3620 al administrador de audio 3275 para enrutar la porción de audio de la videollamada a través del dispositivo manos libres 3220. El administrador de audio 3275 puede transmitir un mensaje 3625 al administrador de manos libres 3270 que indica que la ruta de audio será modificada para ir a través del dispositivo manos libres 3220. Si una conexión de audio todavía no está establecida, el administrador de manos libres 3270 establecerá una conexión de audio 3630 con el dispositivo manos libres 3220. Asumiendo que hay una conexión de audio establecida, la porción de audio 3635 de la videollamada es enrutada al dispositivo manos libres 3220. Por lo tanto, después que se establece una videollamada IP, el dispositivo de cliente 3210 permite al usuario transferir el audio a un dispositivo manos libres.

Aunque la figura 36 ilustra la transferencia de audio a un dispositivo manos libres en respuesta a la recepción de entrada directa en el dispositivo de cliente, en otras modalidades el usuario puede ocasionar que el audio sea transferido al dispositivo manos libres 3220 a través de la entrada en el dispositivo manos libres 3220. En dichas modalidades, el administrador de manos libres 3270 recibe un comando desde el dispositivo manos libres 3220 para transferir el audio. El administrador de manos libres 3270 entonces envía la solicitud al administrador de audio 3275 el cual entonces vuelve a enrutar el audio.

Además, aunque la figura 36 ilustra la transferencia de audio a un dispositivo manos libres, en algunas modalidades el audio también puede ser transferido desde el dispositivo manos libres a un altavoz (o audífonos) del dispositivo de cliente 3210. Esto puede ser iniciado en el dispositivo de cliente 3210 y/o el dispositivo manos libres 3220. En dichas modalidades, el administrador de audio 3275 recibe la solicitud de enrutar audio (ya sea desde el administrador de videollamadas IP 3250 o el administrador de manos libres 3270) para enrutar el audio al dispositivo de cliente 3210 y actúa por consiguiente.

La figura 37 ilustra el dispositivo de cliente 3210 terminando una videollamada en respuesta a la recepción de una solicitud de finalizar llamada desde el dispositivo manos libres 3220 de acuerdo con una modalidad. El administrador de manos libres 3270 recibe un mensaje de finalizar llamada 3710 desde el dispositivo manos libres 3220 en respuesta a un usuario que selecciona finalizar una llamada (por ejemplo, un botón de finalizar fue seleccionado en el dispositivo manos libres 3220) en el dispositivo manos libres 3220. El administrador de manos libres 3270 transmite la solicitud de finalizar llamada 3715 al administrador de telefonía 3260. En una modalidad, la solicitud de finalizar llamada 3715 incluye un identificador de llamada para indicar cuál llamada finalizar (en caso que haya múltiples llamadas) . El administrador de telefonía 3260 determina que la llamada a finalizar está asociada con el administrador de videollamadas IP 3250 y envía el mensaje de finalizar llamada 3720 al administrador de videollamadas IP 3250. En respuesta a la recepción del mensaje de finalizar llamada 3720, el administrador de videollamadas IP 3250 ocasiona que la videollamada IP sea terminada y ocasiona que el dispositivo de cliente 3210 se desconecte de la conexión P2P. Por lo tanto, el dispositivo de cliente 3210 soporta el permitir que el usuario finalice una videollamada IP utilizando un dispositivo manos libres en par.

La figura 38 es un diagrama en bloques que ilustra un sistema de computadora ejemplar el cual puede ser utilizado en algunas modalidades. Por ejemplo, la arquitectura ejemplar del sistema de computadora 3800 puede ser incluida en los dispositivos de cliente 110, 1210, 1410, 2110, 2610, 3210, etcétera u otros dispositivos de computación aquí descritos. Se debiera entender que aunque la figura 38 ilustra diversos componentes de un sistema de computadora, no se pretende representar alguna arquitectura o manera particular de interconexión de los componentes ya que dichos detalles no son fundamentales para la presente invención. Se apreciará que también se pueden utilizar otros sistemas de computadora que tienen una menor cantidad de componentes o una mayor cantidad de componentes.

Tal como se ilustra en la figura 38, el sistema de computadora 3800, el cual es en la forma de un sistema de procesamiento de datos, incluye los enlaces 3850 que están acoplados con el sistema de procesamiento 3820, suministro de energía 3825, memoria 3830 y la memoria no volátil 3840 (por ejemplo, un disco duro, memoria Flash, Memoria de Cambio de Fase (PCM), etcétera). Los enlaces 3850 pueden estar conectados entre sí a través de diversos puentes, controladores y/o adaptadores tal como bien se conoce en la técnica. El sistema de procesamiento 3820 puede recuperar instrucciones de la memoria 30 y/o la memoria no volátil 3840, y ejecutar las instrucciones para realizar operaciones tal como se describió anteriormente. El enlace 3850 interconecta los componentes anteriores y también interconecta aquellos componentes al puerto opcional 3860, el controlador de despliegue y dispositivo de despliegue 3870, dispositivos de Entrada/Salida 3880 (por ejemplo, NIC (Tarjeta de Interfaz de Red), un control de cursor (por ejemplo, ratón, pantalla táctil, teclado táctil, etcétera), un teclado, etcétera) , y los transceptores inalámbricos opcionales 3890 (por ejemplo Bluetooth, Wi-Fi, infrarrojo, etcétera) .

La figura 39 es un diagrama en bloques que ilustra un sistema de procesamiento de datos ejemplar que puede ser utilizado en algunas modalidades. Por ejemplo, el sistema de procesamiento de datos 3900 puede ser una computadora manual, un asistente digital personal (PDA) , un teléfono móvil, un sistema de juegos portátil, un reproductor de medios portátil, una tableta o un dispositivo de computación portátil que puede incluir un teléfono móvil, un reproductor de medios y/o un sistema de juegos. Como otro ejemplo, el sistema de procesamiento de datos 3900 puede ser una computadora de red o un dispositivo de procesamiento incorporado dentro de otro dispositivo.

De acuerdo con una modalidad, la arquitectura ejemplar del sistema de procesamiento de datos 3900 se puede incluir en los dispositivos de cliente 110, 1210, 1410, 2110, 2610, 3210, etcétera u otros dispositivos de computación aquí descritos. El sistema de procesamiento de datos 3900 incluye el sistema de procesamiento 3920, el cual puede incluir uno o más microprocesadores y/o un sistema de un circuito integrado. El .sistema de procesamiento 3920 está acoplado con una memoria 3910, un suministro de energía 3925 (el cual incluye una o más baterías) una entrada/salida de audio 3940, un controlador de despliegue y dispositivo de despliegue 3960, entrada/salida opcional 3950, dispositivos de entrada 3970, y transceptores inalámbricos 3930. Se apreciará que componentes adicionales, que no se muestran en la figura 39, también pueden ser una parte del sistema de procesamiento de datos 3900 en algunas modalidades, y en algunas modalidades se puede utilizar una cantidad menor de componentes a la mostrada en la figura 39. Además, se apreciará que se pueden utilizar uno o más enlaces, que no se muestran en la figura 39, para interconectar los diversos componentes tal como bien se conoce en la técnica.

La memoria 3910 puede almacenar datos y/o programas para ejecución por el sistema de procesamiento de datos 3900. La entrada/salida de audio 3940 puede incluir un micrófono y/o un altavoz, por ejemplo, para reproducir música y/o proporcionar funcionalidad de telefonía a través del altavoz y micrófono. El controlador de despliegue y dispositivo de despliegue 3960 pueden incluir una interfaz de usuario gráfica (GUI). Los transceptores inalámbricos (por ejemplo, RF) 3930 (por ejemplo, un transceptor Wi-Fi, un transceptor infrarrojo, un transceptor Bluetooth, un transceptor de telefonía celular inalámbrica, etcétera) pueden ser utilizados para comunicarse con otros sistemas de procesamiento de datos. Uno o más dispositivos de entrada 3970 permiten a un usuario proporcionar la entrada al sistema. Estos dispositivos de entrada pueden ser un teclado, teclado numérico, panel táctil, panel multi-táctil , etcétera. La otra entrada/salida opcional 3950 puede ser un conector para un puerto.

Las técnicas mostradas en las figuras pueden ser implementadas utilizando un código y datos almacenados y ejecutados en uno o más dispositivos de computación (por ejemplo, dispositivos de cliente, servidores, etcétera). Dichos dispositivos de computación almacenan y transmiten (internamente y/o con otros dispositivos de computación sobre una red) un código (compuesto de instrucciones de software) y datos utilizando un medio legible por máquina, tal como un medio legible por máquina no transitorio (por ejemplo, medio de almacenamiento legible por máquina tal como discos magnéticos; discos ópticos; memoria de solo lectura; dispositivos de memoria flash) y señales de propagación transitoria (por ejemplo, eléctricas, ópticas, acústicas u otra forma de señales propagadas, tal como ondas de portadora, señales infrarrojas, señales digitales, etcétera). Además, dichos dispositivos de computación típicamente incluyen un conjunto de uno o más procesadores acoplados a uno o más componentes diferentes, tal como uno o más medios legibles por máquina tangibles no transitorios (para almacenar el código y/o datos) , dispositivos de entrada/salida de usuario (por ejemplo, un teclado, una pantalla táctil, y/o un despliegue) , y conexiones de red (para transmitir el código y/o datos utilizando señales de propagación transitorias) . El acoplamiento del conjunto de procesadores y otros componentes típicamente es a través de uno o más enlaces y puentes (también denominados como controladores de enlace) . Por lo tanto, un medio legible por máquina no transitorio de un dispositivo de computación determinado típicamente almacena instrucciones para ejecución en el conjunto de uno o más procesadores de ese dispositivo de computación. Una o más partes de una modalidad pueden ser implementadas utilizando diferentes combinaciones de software, microprogramación cableada y/o hardware.

Aunque las operaciones se han descrito aquí con referencia a la validación automática de una dirección de correo electrónico sin requerir que un usuario haga clic en un enlace incluido en un mensaje de correo electrónico de validación con respecto a la validación de una dirección de correo electrónico para uso como un identificador de punto final de sesión de comunicación en línea, las modalidades no quedan limitadas a esto, por ejemplo, en algunas modalidades las operaciones descritas con referencia a la validación automática de una dirección de correo electrónico son ejecutadas cuando una dirección de correo electrónico necesita ser validada por otros motivos. Por ejemplo, un usuario pudiera estar registrándose para un servicio que requiere que una dirección de correo electrónico sea validada como perteneciente a ese usuario como parte del proceso de registro. El usuario proporciona la dirección de correo electrónico al servicio y recibe un mensaje (por ejemplo, a través del despliegue de una página Web del servicio) que indica que la dirección de correo electrónico necesita ser validada y que un mensaje de correo electrónico de validación ha sido enviado o será enviado a la dirección de correo electrónico que fue proporcionada (el mensaje de correo electrónico de validación puede o no incluir un enlace de validación) . Una aplicación en el dispositivo de cliente automáticamente puede revisar una cuenta de correo electrónico correspondiente a la dirección de correo electrónico para el mensaje de validación y cuando es localizada, automáticamente analiza de forma sintáctica el mensaje para ubicar un componente léxico de validación y transmitir un mensaje de validación de dirección de correo electrónico que incluye la dirección de correo electrónico y el componente léxico 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. Aunque los diagramas de flujo en las figuras muestran un orden particular de operaciones ejecutadas por algunas modalidades, se debiera entender que dicho orden es ejemplar (por ejemplo, modalidades alternativas pueden ejecutar las operaciones en un orden diferente, combinar ciertas operaciones, traslapar ciertas operaciones, etcétera) .

Aunque la invención se ha descrito en términos de varias modalidades, aquellos expertos en la técnica reconocerán que la invención no queda limitada a las modalidades descritas, puede ser practicada con modificación y alteración dentro del espíritu y alcance de las reivindicaciones anexas. La descripción entonces será vista como ilustrativa en lugar de limitativa.

Claims

NOVEDAD DE LA INVENCION Habiendo descrito el presente invento, se considera como una novedad y, por lo tanto, se reclama como prioridad lo contenido en las siguientes: REIVINDICACIONES

1.- Un método ejecutado en un dispositivo de cliente para cambiar entre una llamada de audio de circuito conmutado y una videollamada, el dispositivo de cliente incluyendo una cámara de vista frontal para capturar el video de la videollamada, el método comprende: recibir la entrada de un usuario del dispositivo de cliente para transición de una llamada de audio de circuito conmutado establecida a una videollamada, en donde la llamada de audio de circuito conmutado establecida tiene una pluralidad de participantes incluyendo el usuario del dispositivo de cliente y un conjunto de uno o más participantes remotos en un conjunto de uno o más dispositivos de cliente diferentes; ocasionar que un mensaje de invitación de videollamada sea transmitido al conjunto de otros dispositivos de cliente de los participantes remotos; recibir un mensaje de aceptación de videollamada desde el conjunto de otros dispositivos de cliente del conjunto de participantes remotos; transmitir el video capturado por la cámara de vista frontal del dispositivo de cliente al conjunto de otros dispositivos de cliente del conjunto de participantes remotos; y en respuesta a la recepción de al menos un cuadro de video de cada uno del conjunto de otros dispositivos de cliente del conjunto de participantes remotos, cambiar de la llamada de audio de circuito conmutado a la videollamada.

2. - El método de conformidad con la reivindicación 1, que además comprende: cortar la llamada de audio de circuito conmutado en respuesta a la transición exitosa a la videollamada.

3. - El método de conformidad con la reivindicación 1, que además comprende: en respuesta a determinar que el audio actualmente está siendo enrutado a través de un altavoz del receptor del dispositivo de cliente, enrutar el audio a través de un altavoz de audífono del dispositivo de cliente; y desplegar una vista previa de video que está siendo capturado por la cámara de vista frontal del dispositivo de cliente .

4. - El método de conformidad con la reivindicación 1, caracterizado porque la transición de la llamada de audio de circuito conmutado a la videollamada incluye ejecutar lo siguiente : desplegar video que está siendo recibido desde el conjunto de otros dispositivos de cliente del conjunto de participantes remotos; y cambiar una ruta de audio de la llamada de audio de circuito conmutado a la videollamada.

5. - El método de conformidad con la reivindicación 1, que además comprende: establecer una conexión par a par (P2P) directa con el conjunto de otros dispositivos de cliente, en donde el video es transmitido sobre la conexión P2P.

6. - Un método ejecutado en un dispositivo de cliente para cambiar entre una llamada de audio de circuito conmutado a una videollamada, el dispositivo de cliente incluye una cámara de vista frontal para capturar video para la videollamada, el método comprende: recibir un mensaje de invitación de videollamada originada de un dispositivo de cliente de un participante remoto de la llamada de audio de circuito conmutado; recibir la entrada de un usuario para aceptar la invitación de videollamada; ocasionar que un mensaje de aceptación de invitación de videollamada sea transmitido al dispositivo de cliente del participante remoto; transmitir el video capturado por la cámara de vista frontal al dispositivo de cliente del participante remoto; y en respuesta a la recepción de al menos un cuadro de video del dispositivo de cliente del participante remoto, cambiar de la llamada de audio de circuito conmutado a la videollamada .

7. - El método de conformidad con la reivindicación 6, que además comprende: cortar la llamada de audio de circuito conmutado en respuesta a la transición exitosa a la videollamada.

8. - El método de conformidad con la reivindicación 6, que además comprende: en respuesta a la determinación de que el audio actualmente está siendo enrutado a través de un altavoz de receptor del dispositivo de cliente, enrutar el audio a través de un altavoz de audífono del dispositivo de cliente y desplegar una vista previa de video que está siendo capturado por la cámara de vista frontal.

9.- El método de conformidad con la reivindicación 6, caracterizado porque la transición de la llamada de audio de circuito conmutado a la videollamada incluye ejecutar lo siguiente : desplegar video que está siendo recibido desde el dispositivo de cliente del participante remoto; y cambiar una ruta de audio de la llamada de audio de circuito conmutado a la videollamada.

10. - El método de conformidad con la reivindicación 6, que además comprende: establecer una conexión par a par (P2P) directa con el dispositivo de cliente del participante, en donde el video es transmitido sobre la conexión P2P.

11. - Un dispositivo de cliente para cambiar entre una llamada de audio de circuito conmutado y una videollamada, el dispositivo de cliente comprende: una cámara de vista frontal para capturar video para la videollamada; un transceptor inalámbrico para comunicarse con otros dispositivos de cliente; una memoria para almacenar un código de programa; un procesador acoplado con la memoria para procesar el código de programa para: recibir entrada desde un usuario del dispositivo de cliente para cambiar de una llamada de audio de circuito conmutado establecida a una videollamada, en donde la llamada de audio de circuito conmutado establecida tiene una pluralidad de participantes incluyendo al usuario del dispositivo de cliente y un conjunto de uno o más participantes remotos en un conjunto de uno o más dispositivos de cliente diferentes; ocasionar que un mensaje de invitación de videollamada sea transmitido al conjunto de otros dispositivos de cliente de los participantes remotos; recibir un mensaje de aceptación de videollamada desde el conjunto de otros dispositivos de cliente del conjunto de participantes remotos; transmitir video capturado por la cámara de vista frontal al conjunto de otros dispositivos de cliente del conjunto de participantes remotos; y en respuesta a la recepción de al menos un cuadro de video de cada uno del conjunto de otros dispositivos de cliente del conjunto de participantes remotos, cambiar de la llamada de audio de circuito conmutado a la videollamada .

.12.- El dispositivo de cliente de conformidad con la reivindicación 11, caracterizado porque el procesador además es para: cortar la llamada de audio de circuito conmutado en respuesta a una transición exitosa a la videollamada y en donde el dispositivo de cliente además comprende: un altavoz de receptor para proporcionar una señal de audio de salida; un altavoz de audífonos para proporcionar una señal de audio de salida; en donde el procesador además es para, en respuesta a una determinación de que el audio actualmente está siendo enrutado a través del altavoz del receptor, enrutar audio a través del altavoz de los audífonos.

13.- El dispositivo de cliente de conformidad con la reivindicación 11, caracterizado porque el procesador además es para: desplegar una vista previa de video que está siendo capturado por la cámara de vista frontal del dispositivo de cliente en la pantalla.

14. - El dispositivo de cliente de conformidad con la reivindicación 11, caracterizado porque el procesador para cambiar de la llamada de audio de circuito conmutado a la videollamada incluye el procesador para: desplegar video que está siendo recibido desde el conjunto de otros dispositivos de cliente del conjunto de participantes remotos; y cambiar una ruta de audio de la llamada de audio de circuito conmutado a la videollamada.

15. - El dispositivo de cliente de conformidad con la reivindicación 11, caracterizado porque el procesador además es para: establecer conexión par a par (P2P) directa con el conjunto de otros dispositivos de cliente, en donde el video es transmitido sobre la conexión P2P.

16. - Un dispositivo de cliente para cambiar entre una llamada de audio de circuito conmutado y una videollamada, el dispositivo de cliente comprende: una cámara de vista frontal para capturar video para la videollamada; un transceptor inalámbrico para comunicarse con otros dispositivos de cliente; una memoria para almacenar un código de programa; un procesador acoplado con la memoria para procesar el código de programa para: recibir un mensaje de invitación de videollamada originada de un dispositivo de cliente de un participante remoto de la llamada de audio de circuito conmutado; recibir la entrada de un usuario para aceptar la invitación de videollamada; ocasionar que un mensaje de aceptación de invitación de videollamada sea transmitido al dispositivo de cliente del participante remoto; transmitir el video capturado por la cámara de vista frontal al dispositivo de cliente del participante remoto; y en respuesta a la recepción de al menos un cuadro de video del dispositivo de cliente del participante remoto, cambiar de la llamada de audio de circuito conmutado a la videollamada.

17.- El dispositivo de cliente de conformidad con la reivindicación 16, caracterizado porque el procesador además es para: cortar la llamada de audio de circuito conmutado en respuesta a una transición exitosa a la videollamada.

18. - El dispositivo de cliente de conformidad con la reivindicación 16, que además comprende: un altavoz de receptor para proporcionar una señal de audio de salida; un altavoz de audífonos para proporcionar una señal de audio de salida; en donde el procesador además es para, en respuesta a una determinación de que el audio está siendo enrutado actualmente a través del altavoz del receptor, enrutar audio a través del altavoz de audífonos.

19. - El dispositivo de cliente de conformidad con la reivindicación 16, caracterizado porque el procesador para cambiar de la llamada de audio de circuito conmutado a la videollamada incluye el procesador para: desplegar video que está siendo recibido desde el dispositivo de cliente del participante remoto; y cambiar una ruta de audio de la llamada de audio de circuito conmutado a la videollamada.

20. - El dispositivo de cliente de conformidad con la reivindicación 16, caracterizado porque el procesador además es para: establecer una conexión par a par (P2P) directa con de cliente del participante, en donde el video tido sobre la conexión P2P.