BR112012025382B1

BR112012025382B1 - Método para registrar um dispositivo de computação cliente para sessões de comunicação online, servidor de registro para registrar dispositivos de computação clientes para sessões de comunicação online, meio de armazenamento legível por máquina não transitório e sistema de registro de sessão de comunicação online

Info

Publication number: BR112012025382B1
Application number: BR112012025382-4A
Authority: BR
Inventors: Arun Matthias; Justin Santamaria; Justin Wood; Joe Abuan; Jeremy Brown; Patrick Gates; Natthew Klahn; Andrew H. Vyrros; Braden Thomas; Drew Yao
Original assignee: Apple Inc
Priority date: 2010-04-07
Filing date: 2010-09-23
Publication date: 2021-04-27
Also published as: TW201141190A; BR112012025358B1; AU2010350741B2; CN102859962B; US20130231146A1; ES2469852T3; US8423058B2; US8725880B2; WO2011126505A1; KR20130018288A; KR101436225B1; MX2012011620A; US20110249079A1; WO2011126503A1; KR20130020785A; CN102893572B; US8704863B2; KR20130020786A; JP5833098B2; BR112012025379A2

Abstract

método e dispositivo para registrar dispositivos de computação clientes para sessões de comunicação online. a presente invenção refere-se ao registro de um dispositivo de computação cliente (110) para sessões de comunicação online. um servidor de registro (140) recebe uma mensagem (3) que tem um token de processamento que é exclusivo para o dispositivo de computação cliente e um número de telefone do dispositivo de computação cliente de um dispositivo de trânsito de sms (serviço de mensagem curta) (130), o qual recebeu uma mensagem de sms (1) que tem o token de prosseguimento do dispositivo de computação cliente (140) e determinou o número de telefone do dispositivo de computação cliente daquela mensagem de sms. o servidor de registro (140) associa o token de prosseguimento e o número de telefone e os armazena em um armazenamento de dados de registro (150), o qual é usado para convidar usuários para sessões de comunicação online.

Description

Referência Cruzada a Pedidos Relacionados

[001] Este pedido reivindica prioridade ao Pedido de Patente de N° U.S. 12/886.479, depositado no dia 20 de setembro de 2010, e também reivindica o benefício do Pedido Provisório de N° U.S. 61/382.479, depositado no dia 13 de setembro de 2010, Pedidos Provisórios de N° U.S. 61/378.924 e 61/378.926, sendo cada um depositado no dia 31 de agosto de 2010, Pedido Provisório de N° U.S. 61/351.814, depositado no dia 4 de junho de 2010, e Pedidos Provisórios de N° U.S. 61/321.865 e 61/321.866, cada um depositado no dia 7 de abril de 2010, sendo que cada um é aqui incorporado a título de referência.

[002] Este pedido pode incluir o assunto relacionado ao Pedido Provisório copendente concedido de N° U.S. 61/321.832, depositado no dia 7 de abril de 2010, e é intitulado: Apparatus and Method For Inviting Users to Online Sessions, que é incorporado a título de referência ao presente documento.

[003] A invenção a ser descrita e reivindicada nesse pedido foi prematuramente, e sem a autorização da Apple, descrita ao público quando um protótipo do iPhone 4 da Apple foi aparentemente roubado de um engenheiro da Apple em 25 de março de 2010. O pedido de prioridade U.S., no qual este pedido é baseado, não foi depositado antes do aparente roubo.

ANTECEDENTES Campo

[004] Modalidades da invenção referem-se ao campo de redes de computadores; e mais especificamente ao registro de dispositivos de computação clientes para sessões de comunicação online.

Antecedentes

[005] Muitas implantações para fornecer sessões de comunica ção online (por exemplo, mensagens instantâneas, videoconferências etc.) exigem que usuários de dispositivos de computação instalem software e/ou se registrem no serviço. Dessa forma, como um pré- requisito para um usuário estabelecer uma sessão de comunicação online com outro usuário, os usuários devem estar registrados e/ou ter o mesmo software instalado. Muitas implantações também mantém a presença (por exemplo, uma lista de amigos) que permite que usuários determinem um estado de outros usuários (por exemplo, online, offline, ausente etc.).

[006] Grandes redes públicas, como a Internet, frequentemente têm conexões a redes privadas menores, como aquelas mantidas por uma corporação, provedor de serviço de Internet, ou até mesmo famílias individuais. Pela sua natureza, redes públicas devem ter um acordo comum sobre alocação de endereços de rede, ou seja, endereços públicos. Para uma variedade de razões, mantenedores de redes privadas frequentemente escolhem usar endereços de rede privados para as redes privadas que não são parte do acordo comum sobre alocação. Dessa forma, para que o tráfico de rede da rede privada possa atravessar a rede pública, alguma forma de tradução de endereço de rede privada/pública ("NAT") é exigida.

[007] Um dispositivo que realiza operações de NAT altera os pa cotes de dados que estão sendo enviados da rede privada para cumprir com o esquema de endereçamento da rede pública. Particular- mente, o tradutor de endereço de rede substitui o endereço privado originário e o número de porta de um pacote por seu próprio endereço público e um número de porta atribuído. Um tradutor de endereço de rede também altera os pacotes de dados que são recebidos por computadores na rede privada para substituir o endereço público de destino e número de porta pelo endereço privado correto e número de porta do receptor pretendido. Como usado no presente documento, o termo endereço deve ser construído para incluir tanto um endereço quanto um número de porta, se apropriado no contexto, como deve ser entendido por elementos de conhecimento comum na técnica.

[008] A NAT se tornou cada vez mais comum em computação de rede moderna. Uma vantagem de NAT é que o mesmo desacelera a diminuição de espaço de endereço da rede pública. Por exemplo, o endereçamento de TPC/IP, que é usado na Internet, compreende quatro cadeias de três dígitos cada, fornecendo então, um espaço de endereço finito. Adicionalmente, determinadas porções desse espaço de endereço são reservadas para usos ou usuários particulares, diminuindo adicionalmente o número real de endereços disponíveis. Contudo, se NAT é usado, uma rede privada ou sub-rede pode usar um número arbitrário de endereços, e ainda apresentar apenas um endereço público padronizado exclusivo ao mundo exterior. Isso torna o número de endereços disponíveis praticamente sem limites, porque cada rede privada pode, teoricamente, usar exatamente os mesmos endereços privados.

[009] Uma vantagem fornecida pela NAT é a segurança aumen tada decorrente do fato que elementos na rede pública não podem de-terminar o endereço de rede atual (ou seja, privado) de um computador em uma rede privada. Isso acontece porque apenas o endereço público é fornecido na rede pública pelo tradutor de endereço de rede. Adicionalmente, esse endereço público pode corresponder a qualquer número de computadores na rede privada.

[0010] Diferentes tipos de NAT empregam diferentes níveis de se gurança. Por exemplo, com uma "NAT de cone completo", uma vez que um endereço interno (iAddr:iPort) é mapeado para um endereço externo (eAddr:ePort), qualquer hospedagem externa pode enviar pacotes para iAddr:iPort por enviar pacotes para eAddr:ePort. Com uma "NAT de cone restrito", uma hospedagem externa com um endereço hAddr pode enviar pacotes para iAddr:iPort por enviar pacotes para eAddr:ePort apenas se iAddr:iPort tiver enviado previamente um pacote para hAddr. A porta da hospedagem externa é irrelevante. Com um "NAT de cone restrito de porta", uma hospedagem externa que tem um endereço/porta hAddr:hPort pode enviar pacotes para iAddr:iPort por enviar pacotes para eAddr:ePort apenas se iAddr:iPort tiver enviado previamente um pacote para hAddr:hPort. Finalmente, com uma NAT Simétrica, cada solicitação a partir do mesmo iAddr:iPort para um endereço IP e porta de destino específico é mapeado para um eAddr:ePort exclusivo. Se a mesma hospedagem interna enviar um pacote a um diferente destino, um diferente endereço externo e mapeamento de porta é usado. Apenas uma hospedagem externa que recebe um pacote de uma hospedagem interna pode enviar um pacote de volta à hospedagem interna.

[0011] A computação entre pares ("P2P") refere-se a uma arquite tura de rede distribuída que compreende nós de computação que tornam uma porção de seus recursos diretamente disponível para outros participantes de rede. Os pontos em uma rede P2P estabelecem canais de comunicação direta entre si e agem tanto como clientes quanto servidores, em contraste ao modelo cliente-servidor tradicional em que servidores fornecem recursos e clientes consomem recursos.

[0012] As operações de NAT descritas acima emitem problemas numerosos para conexões P2P. Por exemplo, o estabelecimento de uma conexão direta entre dois pontos se torna cada vez mais difícil se um ou os dois dos pontos estão localizados atrás de um ou mais dos tipos de NAT descritos acima. Esse problema é exacerbado pelo fato de que dispositivos clientes como o Apple iPod Touch®, Apple iPhone®, Apple iPad® e vários outros dispositivos (por exemplo, dispositivos RIM Blackberry®, dispositivos Palm Pre® etc.) são frequentemente movidos entre redes que têm diferentes implantações de NAT. Por exemplo, o Apple iPhone® pode realizar comunicação por redes Wi-Fi (por exemplo, redes 802.11b, g, n); redes 3G (por exemplo, redes do Sistema Universal de Telecomunicações Móveis ("UMTS"), redes de Acesso de Pacote de Enlace Ascendente de Alta Velocidade ("HSU- PA") etc.); e redes de Bluetooth (conhecido como redes de área pessoal ("PANs")). Dispositivos clientes futuros poderão realizar comunicação em canais de comunicação adicionais como WiMAX, Telecomunicação Móvel Internacional ("IMT") Avançada, e Evolução de longo prazo ("LTE") Avançada, para citar alguns.

[0013] As unidades de mãos livres (por exemplo, fones de ouvido, kits de carros) são tipicamente usadas para parear com um dispositivo de computação com serviços de mãos livres. Por exemplo, é comum um dispositivo de computação que inclui a funcionalidade de telefonia celular para incluir a habilidade de pareamento com uma unidade de mãos livres que age como um retransmissor auditivo entre a unidade de mãos livres e o dispositivo de computação.

SUMÁRIO

[0014] Um método e aparelho para registrar automaticamente um dispositivo de computação cliente ("dispositivo cliente") (por exemplo, uma estação de trabalho, um laptop, um palmtop, um telefone móvel, um smartphone, um telefone de multimídia, um computador do tipo tablet, um reprodutor de mídia portátil, uma unidade de GPS, um sistema de jogos etc.) para sessões de comunicação online (por exem- plo, videoconferências de P2P, mensagens instantâneas de P2P etc.) é descrito. Em uma modalidade, sob um evento em um dispositivo de computação (por exemplo, a energização do dispositivo de computação), o dispositivo cliente inicia automaticamente um processo de registro para sessões de comunicação online. O processo de registro automático inclui o dispositivo cliente que transmite uma mensagem de SMS (serviço de mensagem curta) com um token de identificação (por exemplo, seu "token" de prosseguimento (passar adiante) token de prosseguimento) a um dispositivo de trânsito de SMS (por exemplo, uma porta de comunicação de SMS ou um agregador de SMS). O token de identificação identifica exclusivamente um dispositivo cliente e em uma modalidade, é um token de prosseguimento que pode conter informações que permitem que um serviço de notificação de prosseguimento localize o dispositivo cliente. O token de identificação na modalidade de serviço de notificação de prosseguimento é também usado como uma forma de estabelecer a confiança de que uma notificação particular é legítima. Em outras modalidades, qualquer registro ou mapeamento de dispositivos clientes para unificar tokens pode ser usado para associar tokens de identificação com dispositivos clientes e fornecer um método confiável de associar a identidade do dispositivo cliente com um token exclusivamente identificado.

[0015] O dispositivo de trânsito de SMS determina o número de telefone do dispositivo cliente (por exemplo, por examinar o cabeçalho da mensagem SMS) e transmite uma mensagem de IP (Protocolo de Internet) a um servidor de registro com o token de identificação e o número de telefone. O servidor de registro gera uma assinatura baseada no token de identificação e o número de telefone, e transmite a mesma ao dispositivo de trânsito de SMS para entrega ao dispositivo cliente. O dispositivo de trânsito de SMS transmite uma mensagem de SMS ao dispositivo cliente que inclui a assinatura, token de identifica- ção, e número de telefone. O dispositivo cliente então transmite uma mensagem de IP ao servidor de registro com a assinatura, token de identificação, e número de telefone. O servidor de registro valida as informações do dispositivo cliente e armazena uma associação entre o token de identificação e o número de telefone em um armazenamento de dados de registro de sessão de comunicação online. Juntos, o par associado do token de identificação e o número de telefone identifica exclusivamente o dispositivo em uma rede de sessão de comunicação online.

[0016] Após o dispositivo cliente ter sido registrado, um usuário no dispositivo cliente pode iniciar e/ou aceitar um convite para uma sessão de comunicação online (por exemplo, bate-papo de vídeo/sessão de conferência, sessão de mensagens instantâneas etc.). Em uma modalidade, o número de telefone de um dispositivo cliente é usado como um identificador de ponto final de sessão de comunicação online de uma sessão de comunicação online. Como forma de exemplo, um usuário em um dispositivo cliente pode convidar outros usuário(s) em outros dispositivo(s) cliente(s) a participar em uma sessão de comunicação online com o uso de seus números de telefone. Em algumas modalidades, o dispositivo cliente não reconhece de modo nativo seu próprio número de telefone.

BREVE DESCRIÇÃO DOS DESENHOS

[0017] A invenção pode ser melhor entendida por referência à se guinte descrição e desenhos anexos que são usados para ilustrar mo-dalidades da invenção. Nos desenhos:

[0018] a figura 1 é um diagrama de fluxo de dados que ilustra o registro de um dispositivo cliente para sessões de comunicação online de acordo com uma modalidade;

[0019] a figura 2 é um diagrama em bloco que ilustra o dispositivo cliente da figura 1 em mais detalhes de acordo com uma modalidade;

[0020] a figura 3 é um diagrama em bloco que ilustra o servidor de registro da figura 1 em mais detalhes de acordo com uma modalidade;

[0021] a figura 4 é um diagrama de fluxo que ilustra operações exemplificativas para registrar um dispositivo cliente para sessões de comunicação online de acordo com uma modalidade;

[0022] a figura 5 ilustra um armazenamento de dados de registro exemplificativo de acordo com uma modalidade;

[0023] a figura 6 ilustra uma topologia de rede geral de uma moda lidade;

[0024] a figura 7 é um diagrama de fluxo de dados que ilustra o estabelecimento de sessão de comunicação online entre dispositivos clientes de acordo com uma modalidade;

[0025] a figura 8 é um diagrama em bloco que ilustra um serviço de retransmissão exemplificativo de acordo com uma modalidade;

[0026] a figura 9 ilustra uma modalidade de uma arquitetura API de acordo com uma modalidade;

[0027] a figura 10 ilustra um armazenamento de dados de registro exemplificativo de acordo com uma modalidade;

[0028] a figura 11 ilustra uma tabela de compatibilidade de NAT exemplificativa de acordo com uma modalidade;

[0029] a figura 12 ilustra um dispositivo cliente exemplificativo e uma interface de usuário gráfica que é usada para transição entre chamadas de circuito comutado e chamadas de vídeo de acordo com algumas modalidades;

[0030] a figura 13 ilustra o dispositivo cliente da figura 12 que exi be uma visualização de vídeo de acordo com uma modalidade;

[0031] a figura 14 ilustra um dispositivo cliente exemplificativo e interface de usuário gráfica que é usada para aceitar ou negar convites de chamada de vídeo de acordo com uma modalidade;

[0032] as figuras 15 e 16 ilustram dispositivos clientes após transi- ção a uma chamada de vídeo de acordo com uma modalidade;

[0033] as figuras 17 e 18 são diagramas de fluxo que ilustram ope rações exemplificativas para transição entre um chamada de telefone de circuito comutado de apenas áudio para uma chamada de vídeo de acordo com uma modalidade;

[0034] a figura 19 é um diagrama de fluxo que ilustra operações exemplificativas realizadas em um dispositivo cliente que recebeu uma mensagem de rejeição de chamada de vídeo de acordo com uma mo-dalidade;

[0035] a figura 20 é um diagrama de fluxo que ilustra operações exemplificativas realizadas em um dispositivo cliente para transição de uma chamada de vídeo para uma chamada de circuito comutado de acordo com uma modalidade;

[0036] a figura 21 ilustra uma topologia de rede geral usada para registrar um dispositivo cliente para sessões de comunicação online com o uso de um endereço de correio eletrônico como um identificador de ponto final de sessão de comunicação online de acordo com uma modalidade;

[0037] as figuras 22A a B são diagramas de fluxo que ilustram operações exemplificativas para registrar um endereço de correio eletrônico como um identificador de ponto final de sessão de comunicação online de acordo com uma modalidade;

[0038] a figura 23 é um diagrama de fluxo que ilustra operações exemplificativas para um usuário que fornece inicialização de informações para registrar um endereço de correio eletrônico como um identificador de ponto final de sessão de comunicação online de acordo com uma modalidade;

[0039] a figura 24 ilustra operações exemplificativas para validar um endereço de correio eletrônico de acordo com uma modalidade;

[0040] a figura 25 é um diagrama de fluxo que ilustra operações exemplificativas realizadas em um serviço de registro quando um endereço de correio eletrônico tiver sido validado de acordo com uma modalidade;

[0041] a figura 26 é um diagrama de fluxo de dados que ilustra operações exemplificativas para gerenciar convites quando um usuário tem múltiplos dispositivos clientes que estão associados com o mesmo identificador de ponto final de sessão de comunicação online de acordo com uma modalidade;

[0042] a figura 27 é um diagrama de fluxo de dados que ilustra operações exemplificativas que são realizadas quando uma conexão P2P direta é praticável de acordo com uma modalidade;

[0043] a figura 28 é um diagrama de fluxo de dados que ilustra operações exemplificativas que são realizadas quando uma conexão P2P direta é impraticável de acordo com uma modalidade;

[0044] a figura 29 é um diagrama de fluxo de dados que ilustra operações exemplificativas realizadas quando uma sessão de comunicação online termina de acordo com uma modalidade;

[0045] a figura 30 é um diagrama de fluxo que ilustra operações exemplificativas realizadas para transferir uma sessão de comunicação online de um dispositivo cliente para outro dispositivo cliente de acordo com uma modalidade;

[0046] a figura 31 é um diagrama de fluxo que ilustra operações exemplificativas para iniciar e estabelecer uma sessão de comunicação online com múltiplos usuários de acordo com uma modalidade;

[0047] a figura 32 é um diagrama em bloco que ilustra um disposi tivo de computação cliente que realiza interface com uma unidade de mãos livres de acordo com uma modalidade;

[0048] a figura 33 ilustra um dispositivo de computação cliente que recebe um convite para uma chamada de vídeo, faz com que um dispositivo de mãos livres toque, recebendo uma indicação de resposta do dispositivo de mãos livres, estabelecendo a chamada de vídeo, e roteando o áudio ao dispositivo de mãos livres de acordo com uma modalidade;

[0049] a figura 34 ilustra um dispositivo de computação cliente que inicia uma chamada de vídeo e realizar a rota do áudio para a chamada de vídeo estabelecida através de um dispositivo de mãos livres de acordo com uma modalidade;

[0050] a figura 35 ilustra um dispositivo de computação cliente que inicia uma chamada de vídeo responsiva para receber uma solicitação de chamada de um dispositivo de mãos livres de acordo com uma modalidade;

[0051] a figura 36 ilustra um dispositivo de computação cliente que realiza a rota de áudio de uma chamada de vídeo estabelecida a um dispositivo de mãos livres de acordo com uma modalidade;

[0052] a figura 37 ilustra um dispositivo de computação cliente que finaliza uma chamada de vídeo responsiva para receber uma solicitação final de chamada de um dispositivo de mãos livres de acordo com uma modalidade;

[0053] a figura 38 é um diagrama em bloco que ilustra um sistema de computador exemplificativo que pode ser usado em algumas moda-lidades; e

[0054] a figura 39 é um diagrama em bloco que ilustra um sistema de processamento de dados exemplificativo que pode ser usado em algumas modalidades.

Descrição Detalhada

[0055] Na seguinte descrição, detalhes específicos numerosos são apresentados. Contudo, é entendido que modalidades da invenção podem ser praticadas sem esses detalhes específicos. Em outros casos, circuitos, estruturas e técnicas bem conhecidas não foram mostrados em detalhes para não complicar o entendimento dessa descri- ção. Aqueles versados na técnica, com as descrições incluídas, poderão implantar a funcionalidade apropriada sem o experimento indevido.

[0056] As referências no relatório descritivo para "uma modalida de", "modalidade", "uma modalidade exemplificativa," etc., indicam que as modalidades descritas podem incluir um recurso particular, estrutura, ou característica, mas cada modalidade pode não incluir necessariamente o recurso, estrutura, ou característica particular. Além disso, tais frases não são necessariamente referenciadas à mesma modalidade. Além disso, quando um recurso, estrutura, ou característica particular é descrito em conexão com uma modalidade, alega-se que está dentro do conhecimento de elementos versados na técnica em efetuar tal recurso, estrutura, ou característica em conexão com outras modalidades se ou não explicitamente descritas.

[0057] Na seguinte descrição e concretizações, os termos "aco plado" e "conectado", junto com seus derivados, podem ser usados. Deve ser entendido que esses termos são não destinados a serem sinônimos uns nos outros. "Acoplado" é usado para indicar que dois ou mais elementos, que podem ou não podem estar em contato físico ou elétrico direto um com o outro, cooperam ou interagem um com o outro. "Conectado" é usado para indicar o estabelecimento de comunicação entre dois ou mais elementos que são acoplados um ao outro. Registro Automático para Sessões de Comunicação Online

[0058] Um método e aparelho para registrar automaticamente um dispositivo de computação cliente ("dispositivo cliente") (por exemplo, uma estação de trabalho, um laptop, um palmtop, um telefone móvel, um smartphone, um telefone de multimídia, um computador do tipo tablet, um reprodutor de mídia portátil, uma unidade de GPS, um sistema de jogos etc.) para sessões de comunicação online (por exemplo, videoconferências de P2P, mensagens instantâneas de P2P etc.) é descrito. Em uma modalidade, sob um evento em um dispositivo de computação (por exemplo, a energização do dispositivo de computação), o dispositivo cliente inicia automaticamente um processo de registro para sessões de comunicação online. O processo de registro automático inclui o dispositivo cliente que transmite uma mensagem de SMS (serviço de mensagem curta) com um token de identificação (por exemplo, seu token de prosseguimento) e um identificador de dispositivo cliente para um dispositivo de trânsito de SMS (por exemplo, uma porta de comunicação de SMS ou um agregador de SMS). O token de identificação identifica exclusivamente um dispositivo cliente para mensagens de sessão de comunicação online (por exemplo, solicitação de convite e mensagens de convite aceitas), e em uma modalidade, está um token de prosseguimento que pode conter informações que permitem que um serviço de notificação de prosseguimento localize o dispositivo cliente. O token de identificação na modalidade de serviço de notificação de prosseguimento é também usado como uma forma de estabelecer a confiança de que uma notificação particular é legítima. Em outras modalidades, qualquer registro ou mapeamento de dispositivos clientes para unificar tokens pode ser usado para associar tokens de identificação com dispositivos clientes e fornecer um método confiável de associar a identidade do dispositivo cliente com um token exclusivamente identificado. O identificador de dispositivo identifica exclusivamente o dispositivo cliente e é tipicamente baseado em um ou mais identificadores de hardware (por exemplo, um número de série do dispositivo, um ICC-ID (ID de Cartão de Circuito Integrado) de cartão SIM (Módulo de Identidade de Assinante) etc.).

[0059] O dispositivo de trânsito de SMS determina o número de telefone do dispositivo cliente (por exemplo, por examinar o cabeçalho da mensagem de SMS) e transmite uma mensagem de IP (Protocolo de Internet) a um servidor de registro com o token de identificação, identificador de dispositivo, e o número de telefone. O servidor de re- gistro gera uma assinatura com base no token de identificação, identificador de dispositivo, e o número de telefone, e transmite os mesmos ao dispositivo de trânsito de SMS para entrega ao dispositivo cliente. O dispositivo de trânsito de SMS transmite uma mensagem de SMS ao dispositivo cliente que inclui a assinatura e número de telefone. O dispositivo cliente então transmite uma mensagem de IP ao servidor de registro com a assinatura, identificador de dispositivo, token de identificação, e número de telefone.

[0060] O servidor de registro valida as informações do dispositivo cliente e armazena uma associação entre o token de identificação e o número de telefone em um armazenamento de dados de registro de sessão de comunicação online. Juntos, o par associado do token de identificação e o número de telefone identifica exclusivamente o dispositivo em uma rede de sessão de comunicação online. Após o dispositivo cliente ter sido registrado, um usuário no dispositivo cliente pode iniciar e/ou aceitar um convite para uma sessão de comunicação online (por exemplo, bate-papo de vídeo/sessão de conferência, sessão de mensagens instantâneas etc.). Em uma modalidade, o número de telefone de um dispositivo cliente é usado como o identificador de ponto final de sessão de comunicação online de uma sessão de comunicação online. Como forma de exemplo, um usuário em um dispositivo cliente pode convidar outros usuário(s) em outros dispositivo(s) clien- te(s) a participar de uma sessão de comunicação online com o uso de seu(s) número(s) de telefone. Em algumas modalidades, o dispositivo cliente não reconhece de modo nativo seu próprio número de telefone.

[0061] A figura 1 é um diagrama de fluxo de dados que ilustra o registro de um dispositivo cliente para sessões de comunicação online de acordo com uma modalidade. A figura 1 inclui o dispositivo cliente 110, a rede de SMS 120, o servidor de registro 140, e o armazenamento de dados de mensagem de IP 150. O dispositivo cliente 110 (por exemplo, uma estação de trabalho, um laptop, um palmtop, um telefone de computação, um smartphone, um telefone de multimídia, um computador do tipo tablet, um reprodutor de mídia portátil, uma unidade de GPS, um sistema de jogos etc.) inclui o token de identificação 115 (que pode ser um token de prosseguimento em uma modalidade). O token de identificação 115 identifica exclusivamente o dispositivo cliente 110 para receber mensagens de solicitação de convite e aceitação de convite (ou rejeição), que será descrito em maiores detalhes posteriormente no presente documento. O identificador de dispositivo 117 identifica exclusivamente o dispositivo cliente e está tipicamente baseado em um ou mais identificadores de hardware (por exemplo, um número de série do dispositivo, um ICC-ID (ID de Cartão de Circuito Integrado) de um cartão SIM (Módulo de identidade de assinante) etc.). O dispositivo cliente 110 inclui a habilidade de transmitir e receber mensagens de SMS bem como a habilidade de conectar e enviar/receber mensagens de IP.

[0062] Após registro para sessões de comunicação online, o dis positivo cliente 110 pode convidar e/ou aceitar convites para sessões de comunicação online. O dispositivo cliente 110 é identificado nas sessões de comunicação online através de um identificador de ponto final de sessão de comunicação online. Enquanto em uma modalidade, o identificador de ponto final de sessão de comunicação online é um número de telefone do dispositivo cliente 110, em outras modalidades, o identificador de ponto final de sessão de comunicação online é um identificador diferente (por exemplo, um nome de usuário (por exemplo, um ID da Apple), um endereço de correio eletrônico, um endereço de correspondência, um endereço de MAC, ou outro identificador).

[0063] A rede de SMS 120 inclui o SMSC de portador (Centro de Serviço de Mensagem Curta) 125 e o dispositivo de trânsito de SMS 130 (por exemplo, uma porta de comunicação de SMS ou um agrega- dor de SMS). O SMSC de portador 125 é portador de computação específico e recebe e entrega mensagens de SMS. Por exemplo, o SMSC de portador 125 entrega mensagens de SMS enviadas a partir do dispositivo cliente 110 ao dispositivo de trânsito de SMS 130, e entrega as mensagens de SMS enviadas do dispositivo de trânsito de SMS 130 ao dispositivo cliente 110. O dispositivo de trânsito de SMS 130 separa a rede móvel e a rede de IP.

[0064] O servidor de registro 140 registra dispositivos clientes co mo o dispositivo cliente 110 para sessões de comunicação online. O registro de um dispositivo cliente para sessões de comunicação online inclui associar um token de identificação de um dispositivo com o número de telefone do dispositivo (ou outro identificador de ponto final de sessão de comunicação online). As associações entre tokens de identificação e identificadores finais de sessão de comunicação online são armazenadas no armazenamento de dados de registro de sessão de comunicação online 150.

[0065] Mediante um evento que ocorre no dispositivo cliente 110 (por exemplo, a energização do dispositivo cliente, uma aplicação de sessão de comunicação online (por exemplo, uma aplicação de videoconferência de P2P, uma aplicação de mensagem instantânea de P2P etc.), execução etc.), o dispositivo cliente 110 inicia um processo de registro para sessões de comunicação online. Em uma modalidade, o processo de registro começa automaticamente (sem interação de usuário) enquanto que, em outras modalidades, o processo de registro começa depois que um usuário seleciona registrar o dispositivo cliente para sessões de comunicação online.

[0066] Em modalidades em que o número de telefone do dispositi vo cliente 110 é usado como o identificador de ponto final de sessão de comunicação online, e deve então ser associado com o token de identificação 115 do dispositivo cliente 110 no armazenamento de dados de registro 150, o número de telefone do dispositivo cliente 110 deve ser determinado. Visto que o dispositivo cliente 110 não conhece de modo nativo seu próprio número de telefone, em algumas modalidades, o número de telefone do dispositivo cliente 110 é determinado através do dispositivo cliente 110 que transmite uma mensagem de SMS. Por exemplo, na operação 1, o dispositivo cliente 110 transmite uma mensagem de SMS com seu token de identificação 115 e o identificador de dispositivo 117 ao dispositivo de trânsito de SMS 130 através do SMSC de portador 125. Em algumas modalidades, a mensagem de SMS é endereçada a um número de telefone, que pode ser um número de comprimento padrão ou um token curto (um tipo de número de telefone que é tipicamente mais curto de modo significante do que um número de telefone completo), que é especificamente estabelecido para registro de sessão de comunicação online. O número de telefone ao qual a mensagem de SMS é endereçada é armazenado no dispositivo cliente (por exemplo, em um pacote de portador).

[0067] O SMSC de portador 125 recebe a mensagem de SMS e entrega a mesma ao dispositivo de trânsito de SMS 130. O dispositivo de trânsito de SMS 130 determina o número de telefone do dispositivo cliente na operação 2. Por exemplo, o dispositivo de trânsito de SMS 130 examina o cabeçalho da mensagem de SMS e determina o número de telefone do dispositivo cliente 110. Após determinar o número de telefone, o dispositivo de trânsito de SMS 130 transmite uma mensagem de IP ao servidor de registro 140 com o número de telefone do dispositivo cliente 110, o token de identificação 115, e o identificador de dispositivo 117. Essa é, algumas vezes, chamada de mensagem de solicitação de registro.

[0068] O servidor de registro 140 recebe a mensagem de IP do dispositivo de trânsito de SMS que inclui o número de telefone do dis- positivo cliente 110, o token de identificação 115, e o identificador de dispositivo 117, e cria uma assinatura. A assinatura pode ser baseada no número de telefone do dispositivo cliente 110, o token de identificação 115, e/ou o identificador de dispositivo 117, e é usada para propósitos de validação (que será descrita em maiores detalhes posteriormente no presente documento). Em algumas modalidades, um número aleatório é também usado ao gerar a assinatura de conta para situações em que múltiplos dispositivos clientes têm o mesmo número de telefone. O servidor de registro 140 transmite a assinatura, número de telefone, identificador de dispositivo, e o token de volta ao dispositivo de trânsito de SMS 130 na operação 5 (por exemplo, em uma mensagem de IP). Essa é, algumas vezes, chamada de mensagem de resposta de registro.

[0069] O dispositivo de trânsito de SMS 130 recebe a assinatura, número de telefone, identificador de dispositivo, e token do servidor de registro 140 e gera uma mensagem de SMS com a assinatura e número de telefone para o dispositivo cliente 110. O dispositivo de trânsito de SMS 130 transmite a mensagem de SMS ao dispositivo cliente 110 com a assinatura e número de telefone na operação 6 (através do SMSC de portador 125).

[0070] O dispositivo cliente 110 recebe e processa a mensagem de SMS que inclui armazenar seu número de telefone. O dispositivo cliente 110 transmite uma mensagem de IP com seu token de identificação 115, identificador de dispositivo 117, seu número de telefone, e a assinatura gerada pelo servidor de registro ao servidor de registro 140 na operação 7. Essa é, algumas vezes, chamada de mensagem de solicitação de validação de registro.

[0071] Ao usar a assinatura, o servidor de registro 140 valida os dados enviados pelo dispositivo cliente 110. Por exemplo, o servidor de registro 140 compara a assinatura enviada pelo dispositivo cliente 110 com a assinatura gerada durante a operação 4. Se forem equivalentes, então os dados são validados. Assumindo que os dados são válidos, o servidor de registro 140 armazena uma associação entre o token de identificação 115 e o número de telefone do dispositivo cliente 110 no armazenamento de dados de registro de sessão de comunicação online 150.

[0072] Em uma modalidade alternativa, ao invés de determinar o número de telefone do dispositivo cliente 110 através de transmissão de mensagens de SMS, é solicitado ao usuário do dispositivo inserir o número de telefone do dispositivo cliente 110. Nessas modalidades, o dispositivo cliente 110 transmite diretamente o número de telefone do dispositivo cliente 110 (como entrada pelo usuário) e seu token de identificação 115 ao servidor de registro 140, que pode associar os mesmos no armazenamento de dados de registro de sessão de comunicação online 150.

[0073] A figura 5 ilustra um armazenamento de dados de registro 150 exemplificativo de acordo com uma modalidade. Como ilustrado na figura 5, cada um dos registros identificadores de sessão de comunicação online 510 inclui um campo de token de identificação 520 e um campo de número de telefone 525. Em algumas situações, é possível que um número de telefone exclusivo seja associado com múltiplos tokens de identificação. Por exemplo, diferentes dispositivos clientes podem ter o mesmo número de telefone. Nesses casos, esses diferentes dispositivos clientes devem ter diferentes tokens de identificação. Dessa forma, quando um convite de sessão de comunicação online é enviado para um número de telefone associado com múltiplos tokens de identificação, um convite será transmitido a cada dispositivo associado ao token de identificação.

[0074] A figura 2 é um diagrama de bloco que ilustra o dispositivo cliente 110 em mais detalhes de acordo com uma modalidade. A figura 2 será descrita com referência à modalidade exemplificativa da figura 4, que é um diagrama de fluxo que ilustra operações exemplificativas para registrar um dispositivo cliente para sessões de comunicação online. Contudo, deve ser entendido que as operações da figura 4 podem ser realizadas por modalidades diferentes daquelas discutidas com referência à figura 2, e as modalidades discutidas com referência à figura 2 podem realizar operações diferentes daquelas discutidas com referência à figura 4.

[0075] Como ilustrado na figura 2, o dispositivo cliente 110 inclui o módulo de registro de sessão de comunicação online de cliente ("módulo de registro de cliente") 210, o(s) pacote(s) portador(es) 215, o token de prosseguimento 115, o identificador de dispositivo 117, o módulo de SMS 220, e o armazenamento de dados de registro de sessão de comunicação online de cliente ("armazenamento de dados de registro de cliente") 230. O módulo de registro de cliente 210 controla o registro do dispositivo cliente 110 para sessões de comunicação online. O(s) pacote(s) portador(es) 215 inclui/incluem configurações específicas para um portador que inclui o número de telefone para o dispositivo de trânsito de SMS usado para registro (por exemplo, o número para o dispositivo de trânsito de SMS 130) e outras configurações (por exemplo, configurações de Nome de Ponto de Acesso (APN), configurações de Serviço de Mensagem de Multimídia (MMS) etc.). O módulo de SMS 220 transmite e recebe mensagens de SMS. O armazenamento de dados de registro de cliente 230 armazena dados relacionados ao registro de sessão de comunicação online (por exemplo, o número de telefone do dispositivo cliente 110 uma vez determinado).

[0076] Em referência à figura 4, no bloco 410, o módulo de registro de cliente 210 detecta ou recebe um evento que aciona o registro de sessão de comunicação online. Exemplos de tais eventos incluem a energização do dispositivo cliente 110, um usuário que abre uma apli- cação de comunicação online (por exemplo, uma aplicação de video-conferência de P2P, uma aplicação de mensagens instantâneas de P2P etc.) etc. Em algumas modalidades, o processo de registro é realizado toda vez que o dispositivo cliente 410 é ligado, enquanto em outras modalidades, o processo de registro é realizado na primeira vez em que o dispositivo cliente 110 é ligado. O fluxo se move do bloco 410 para o bloco 415.

[0077] No bloco 415, o módulo de registro de cliente 210 determi na se existe um token de identificação válido para o dispositivo cliente 110. Se não existir um token de identificação, ou o token de identificação estiver expirado, então o fluxo se move para o bloco 425 em que a ação alternativa é tomada. Por exemplo, em modalidades com o uso de tokens de prosseguimento, o dispositivo cliente 110 pode iniciar um procedimento de geração de token por solicitar um token de prosseguimento que é gerado por um serviço de notificação de prosseguimento (que é tipicamente remoto do dispositivo cliente 110). O serviço de notificação de prosseguimento gera um token de prosseguimento específico ao dispositivo cliente 110 e retorna o mesmo ao dispositivo cliente 110. Se existir um token de identificação válido, então o fluxo se move para o bloco 420 em que o módulo de registro de cliente 210 acessa o token de identificação 115. O fluxo se move do bloco 420 para o bloco 428.

[0078] No bloco 428, o módulo de registro de cliente 210 acessa o identificador de dispositivo 117. O fluxo, então, se move para o bloco 430, onde o módulo de registro de cliente 210 determina o número de telefone para o dispositivo de trânsito de SMS usado no processo de registro. Por exemplo, o módulo de registro de cliente 210 acessa o(s) pacote(s) de portadora 215 para determinar o número de telefone do dispositivo de trânsito de SMS. O número de telefone pode ser um código curto ou pode ser um número de comprimento padrão. Nesse exemplo, o dispositivo de trânsito de SMS usado no processo de registro é o dispositivo de trânsito de SMS 130. O fluxo se move do bloco 430 para o bloco 435.

[0079] No bloco 435, uma mensagem de SMS que tem o token de identificação 115 e o identificador de dispositivo 117 é transmitida para o número determinado (o dispositivo de trânsito de SMS 130). Por exemplo, o módulo de registro de cliente 210 solicita que o módulo de SMS 220 transmita uma mensagem de SMS com o token de identificação 115 e o identificador de dispositivo 117 para o número determinado. O módulo de SMS 220 transmite a mensagem de SMS com o token de identificação para o número determinado. O fluxo se move do bloco 435 para o bloco 440. A mensagem de SMS será recebida pelo SMSC de portadora 125, que entrega a mesma para o dispositivo de trânsito de SMS 130.

[0080] No bloco 440, o dispositivo de trânsito de SMS 130 deter mina o número de telefone do dispositivo cliente 110 com base na mensagem de SMS recebida. Por exemplo, o dispositivo de trânsito de SMS examina o leitor da mensagem de SMS, que incluirá o número de telefone do remetente, que nesse caso é o dispositivo cliente 110. O fluxo, então, se move para o bloco 445 onde o dispositivo de trânsito de SMS 130 transmite o número de telefone do dispositivo cliente 110, o token de identificação 115 e o identificador de dispositivo 117 para o servidor de registro 140 (por exemplo, em uma mensagem de IP segura). O fluxo se move do bloco 445 para o bloco 450.

[0081] A figura 3 é um diagrama de bloco que ilustra o servidor de registro 140 em mais detalhes de acordo com uma modalidade. A figura 3 será descrita com referência à modalidade exemplificativa da figura 4. Entretanto, deve ser entendido que as operações da figura 4 podem ser realizadas por modalidades diferentes daquelas discutidas com referência à figura 3 e as modalidades discutidas com referência à figura 3 podem realizar operações diferentes daquelas discutidas com referência à figura 4. Conforme ilustrado na figura 3, o servidor de registro 140 inclui o módulo de registro de sessão de comunicação online de servidor 305, que inclui a interface de trânsito de SMS 310, o gerador de assinatura 315, a interface de dispositivo cliente 325, o módulo de validação 330, o armazenamento de dados de validação 335 e o módulo de associação 340. A interface de trânsito de SMS 310 recebe e envia mensagens para o dispositivo de trânsito de SMS 130. Por exemplo, a interface de trânsito de SMS 310 recebe tuplas de número de telefone, token de identificação e identificador de dispositivo da interface de trânsito de SMS 310 e transmite tuplas de número de telefone, token de identificação, identificador de dispositivo e assinatura (algumas vezes referidas como "tuplas de validação") para a interface de trânsito de SMS 310. A interface de dispositivo cliente 325 recebe e pode transmitir mensagens para os dispositivos clientes. Por exemplo, a interface de dispositivo cliente 325 recebe tuplas de validação a partir dos dispositivos clientes.

[0082] Referindo-se novamente à figura 4, no bloco 450, o gerador de assinatura 310 gera uma assinatura para a tupla de número de telefone, token de identificação, e identificador de dispositivo que recebeu do dispositivo de trânsito de SMS 130. A assinatura será usada para validar o emparelhamento do número de telefone e do token de identificação antes de armazenar o par no armazenamento de dados de registro 150. Em algumas modalidades, a assinatura tem base no número de telefone, token de identificação e/ou identificador de dispositivo (por exemplo, um resumo criptográfico é aplicado ao número de telefone, token de identificação e/ou identificador de dispositivo ou alguma porção dos mesmos para gerar a assinatura). Em algumas modalidades, a assinatura também tem base em um número aleatório para considerar situações em que múltiplos dispositivos clientes têm o mesmo número de telefone. O gerador de assinatura 310 armazena a assinatura e opcionalmente o número de telefone, token de identificação e/ou identificador de dispositivo no armazenamento de dados de validação 325. O fluxo, então, se move para o bloco 455, onde a interface de trânsito de SMS 310 transmite a assinatura, número de telefone, identificador de dispositivo e token de identificação para o dispositivo de trânsito de SMS 130. O fluxo se move do bloco 455 para o bloco 460.

[0083] O dispositivo de trânsito de SMS 130 recebe a assinatura, o número de telefone e o token de identificação do servidor de registro 140. No bloco 460, o dispositivo de trânsito de SMS transmite uma mensagem de SMS (através do SMSC de portadora 125) com a assinatura e o número de telefone para o dispositivo cliente 110. O fluxo, então, se move para o bloco 465.

[0084] No bloco 465, o módulo de SMS 220 recebe a mensagem de SMS com a assinatura e o número de telefone e armazena a assinatura e o número de telefone no armazenamento de dados de registro de cliente 230. O fluxo, então, se move para o bloco 470, onde o módulo de registro de cliente 210 transmite uma mensagem de IP para o servidor de registro com seu número de telefone, token de identificação 115, identificador de dispositivo 117 e assinatura. O fluxo, então, se move para o bloco 475.

[0085] A interface de dispositivo cliente 325 recebe o número de telefone, o token de identificação, o identificador de dispositivo e a as-sinatura do dispositivo cliente. As informações são passadas para o módulo de validação 330 que determina se os dados são válidos no bloco 475. Por exemplo, a mesma função de resumo que a aplicada ao gerar a assinatura é usada no número de telefone, token de identificação e/ou identificador de dispositivo recebidos do dispositivo cliente e o módulo de validação 330 compara o resultado com a assinatura que foi gerada anteriormente (armazenada no armazenamento de dados de validação 335). Se as assinaturas coincidirem, então os dados são válidos e o fluxo se move para o bloco 480.

[0086] No bloco 480, o módulo de associação 330 do servidor de registro 140 armazena uma associação do número de telefone do dispositivo cliente e o token de identificação do dispositivo cliente no armazenamento de dados de registro 150. Em algumas modalidades, o servidor de registro 140 pode transmitir uma mensagem de estado de registro para o dispositivo cliente 110 alertando o dispositivo cliente 110 se o registro foi bem sucedido.

[0087] Depois que o dispositivo cliente foi registrado, um usuário no dispositivo cliente pode iniciar e/ou aceitar um convite para uma sessão de comunicação online (por exemplo, sessão de conferên- cia/bate-papo com vídeo, sessão de mensagens instantâneas etc.). Por meio de exemplo, um usuário em um dispositivo cliente pode convidar outro(s) usuário(s) em outro(s) dispositivo(s) cliente(s) para parti- cipar(em) em uma sessão de comunicação online usando seu(s) nú- mero(s) de telefone. Em algumas modalidades, o dispositivo cliente não sabe originalmente seu próprio número de telefone. Embora as modalidades tenham descrito o uso de mensagens de SMS durante o registro, em outras modalidades outros tipos de mensagens de texto podem ser usados (por exemplo, MMS (Serviço de Mensagens Multimídia)). Registro de Endereços de Correio Eletrônico para Sessões de Comunicação Online

[0088] Embora a figura 1 tenha sido descrita em relação ao regis tro de um número de telefone como um identificador de ponto de ex-tremidade de sessão de comunicação online, em outras modalidades um endereço de correio eletrônico é usado como um identificador de ponto de extremidade de sessão de comunicação online. A figura 21 ilustra uma topologia de rede geral usada para registrar um dispositivo cliente para as sessões de comunicação online com o uso de um endereço de correio eletrônico como um identificador de ponto de extremidade de sessão de comunicação online. Os dispositivos clientes 2110A-N usam o serviço de registro 2130 para registrar para sessões de comunicação online. Por exemplo, em uma modalidade, o usuário de um dispositivo cliente 2110A usa o cliente de sessão de comunicação online 2115 para registrar um endereço de correio eletrônico para o uso como um identificador de sessão de comunicação online para comunicações online através da rede 2180 (por exemplo, a Internet).

[0089] As figuras 22A-B são fluxogramas que ilustram operações exemplificativas para registrar um endereço de correio eletrônico como um identificador de ponto de extremidade de sessão de comunicação online de acordo com uma modalidade. As figuras 22A-B serão descritas com referência à modalidade exemplificativa ilustrada na figura 21. Entretanto, deve ser entendido que as operações das figuras 22A-B podem ser realizadas por modalidades diferentes daquelas discutidas com referência à figura 21, e as modalidades discutidas com referência à figura 21 podem realizar operações diferentes daquelas discutidas com referência às figuras 22A-B.

[0090] Na operação 2210, o serviço de registro 2130 recebe uma solicitação de autenticação do dispositivo cliente 2110A. Por exemplo, com referência à figura 23, que descreve operações exemplificativas para um usuário fornecendo informações de inicialização, na operação 2310, a aplicação de sessão de comunicação online 2115 é iniciada no dispositivo cliente 2110A. O fluxo, então, se move para a operação 2315 e o dispositivo cliente 2110A recebe a entrada do usuário incluindo uma ID de usuário e senha e um ou mais endereços de correio eletrônico para registrar para o uso como identificador(es) de ponto de extremidade de sessão de comunicação online. O fluxo, então, se mo ve para operação 2320 e o dispositivo cliente 2110A transmite a ID de usuário e a senha para o serviço de registro 2130.

[0091] Embora o dispositivo cliente 2110A esteja registrando um endereço de correio eletrônico como um identificador de ponto de ex-tremidade de sessão de comunicação online e possa não incluir a fun-cionalidade de telefone, este pode enviar um convite de sessão de comunicação online com o uso de um número de telefone ao invés de um endereço de correio eletrônico. Adicionalmente a receber uma ID de usuário, senha e um ou mais endereços de correio eletrônico para registrar, em algumas modalidades, o usuário pode também fornecer informações em relação a qual país e/ou região o mesmo está atualmente localizado de modo que o código do país e/ou código da região possam ser usados se o usuário iniciar uma sessão de comunicação online para um número de telefone que não inclui um código do país e/ou código da região. Por exemplo, nos Estados Unidos, uma chamada de telefone local pode ser colocada usando-se 7 dígitos (assim, o código do país e código da região não são exigidos). O sistema de telefone subjacente determina automaticamente o código do país e da região e completa a chamada. Entretanto, em casos em que o dispositivo cliente 2110A não inclui uma funcionalidade de telefone, o dispositivo cliente 2110A não pode contar com o sistema de telefone subjacente para incluir automaticamente o código do país e/ou código da região ao convidar um usuário para uma sessão de comunicação online com o uso de um número de telefone que não inclui o código do país e/ou código da região.

[0092] Na operação 2320, o dispositivo cliente 2110A recebe a entrada do usuário em relação a qual país e/ou região (por exemplo, código de área, estado, província, cidade etc.) em que o mesmo está localizado. O fluxo, então, se move para operação 2320 onde o dispositivo cliente 2320 associa os códigos de telefone do país e/ou da regi- ão correspondentes com a aplicação de sessão de comunicação online 2115 para o uso se o usuário iniciar uma sessão de comunicação online a um número de telefone que não inclui um código do país e/ou da região. Por exemplo, se o usuário indicar que o mesmo está localizado nos Estados Unidos e o usuário convida um usuário para uma sessão de comunicação online com o uso de um número de telefone de 10 dígitos que não inclui o código do país, o dispositivo cliente 2110A adiciona automaticamente o código do país para os Estados Unidos ao número de telefone.

[0093] Com referência novamente à figura 22A, após receber a solicitação de autenticação do dispositivo cliente 2110A, um processo de autenticação é realizado com o uso do nome de usuário e senha fornecidos. Em uma modalidade, o serviço de registro 2130 realiza o processo de autenticação enquanto que em outra modalidade o serviço de diretório de usuário 2160 realiza o processo de autenticação. O serviço de diretório de usuário 2160 é um serviço centralizado que fornece conta de usuário, autenticação e outros serviços. O serviço de diretório de usuário 2160 gerencia as gravações de usuário 2165. Em uma modalidade, cada usuário autenticado é associado a uma gravação de usuário que inclui várias informações (por exemplo, um ou mais dentre uma ID de usuário, senha, endereço postal, número de telefone, nome, aniversário, país, uma lista de endereços eletrônicos associada ao usuário (que pode também indicar se o endereço de correio eletrônico é validado) etc.). Se a autenticação for bem sucedida, então o fluxo se move para a operação 2216. Se a autenticação falhar, então o fluxo se move para a operação 2214 e uma ação alternativa é tomada (por exemplo, o serviço de registro 2130 transmite uma mensagem de erro para o dispositivo cliente 2110A que indica que o nome de usuário e/ou senha não está correto).

[0094] Na operação 2216, o serviço de registro 2130 gera e/ou acessa um perfil de sessão de comunicação online associado à ID de usuário. Por exemplo, o serviço de registro 2130 pode incluir um servidor de conta de sessão de comunicação online 2140 que gerencia as gravações de perfil de sessão de comunicação online 2150. Em uma modalidade, cada usuário que está registrando ou é registrado para sessões de comunicação online tem uma gravação de perfil de sessão de comunicação online correspondente. Cada gravação de perfil de sessão de comunicação online pode incluir um conjunto de um ou mais endereços de correio eletrônico, incluindo seu estado de validação, que são associados ao perfil. Cada gravação de perfil de sessão de comunicação online pode também incluir um ou mais tokens de prosseguimento que correspondem a um ou mais dispositivos clientes respectivamente que são registrados para as sessões de comunicação online. Cada gravação de perfil pode também incluir credenciais de perfil para validar certas comunicações dos dispositivos clientes. Cada gravação de perfil pode também indicar quais dispositivos clientes (conforme indicado por tokens de prosseguimento) registraram ou estão tentando registrar quais endereços de correio eletrônicos.

[0095] O fluxo se move da operação 2216 para a operação 2218 e o serviço de registro 2130 transmite uma resposta de autenticação para o dispositivo cliente 2110A que inclui a ID de perfil (por exemplo, uma sequência que identifica o perfil associado com a ID de usuário fornecido) e as credenciais de perfil. A resposta de autenticação pode também indicar que a autenticação foi bem sucedida. O fluxo, então, se move para a operação 2220 e o serviço de registro 2130 recebe uma solicitação de validação de correio eletrônico do dispositivo cliente 2110A que inclui um ou mais endereços de correio eletrônico para validar a ID de perfil, credenciais de perfil e o token de prosseguimento do dispositivo cliente 2110A. A mensagem de solicitação de validação de correio eletrônico pode também incluir a ID de dispositivo do dispo- sitivo cliente 2110A. O serviço de registro 2130, então, determina se as credenciais de perfil são válidas para a ID de perfil na operação 2222. Se estas não forem, então o fluxo se move para a operação 2224 e uma ação alternativa é tomada (por exemplo, o serviço de registro 2130 transmite uma mensagem de erro para o dispositivo cliente 2110A). Se as credenciais de perfil forem válidas, então o fluxo se move para a operação 2223. Na operação 2223, o serviço de registro 2130 associa o token de prosseguimento ao perfil. Por exemplo, o servidor de conta de sessão de comunicação online 2140 armazena o token de prosseguimento na gravação de perfil para o usuário.

[0096] O fluxo, então, se move para operação 2226 e o serviço de registro 2130 determina se o endereço de correio eletrônico é validado. Um endereço de correio eletrônico validado é um endereço de correio eletrônico que foi validado como pertencendo à solicitação de usuário que está solicitando que esse seja registrado para uso como um identificador de ponto de extremidade de sessão de comunicação online. O servidor de conta de sessão de comunicação online 2140 acessa a gravação de perfil do usuário 2150 para determinar se o endereço de correio eletrônico é validado. Se a gravação de perfil não indicar que o endereço de correio eletrônico é validado, em algumas modalidades, o serviço de registro 2130 transmite uma solicitação de validação de endereço de correio eletrônico para o serviço de diretório de usuário 2160 para determinar se a gravação de usuário 2165 para o usuário indica que o endereço de correio eletrônico é validado. Se o endereço de correio eletrônico não for validado, então o fluxo se move para a operação 2227 e o serviço de registro 2130 faz com que uma mensagem de correio eletrônico de validação seja enviada para o en-dereço de correio eletrônico que inclui um enlace que, quando selecionado (ou quando inserido em um navegador de Internet), faz com que o endereço de correio eletrônico seja validado. Por exemplo, a seleção do enlace faz com que uma mensagem de validação de endereço de correio eletrônico seja enviada que inclui o endereço de correio eletrônico e um token de validação que são usados para validar o endereço de correio eletrônico. O serviço de registro 2130 pode também transmitir uma mensagem de validação de necessidades de endereço de correio eletrônico para o dispositivo cliente que indica que o endereço de correio eletrônico não é validado (e, assim, precisa ser validado) e pode também indicar que uma mensagem de correio eletrônico de validação foi enviada para o endereço de correio eletrônico em questão. O fluxo, então, se move para a operação 2410, que será descrita em referência à figura 24. Entretanto, se o endereço de correio eletrônico for validado, então o fluxo se move para a operação 2228.

[0097] Na operação 2228, o serviço de registro 2130 transmite uma mensagem de sucesso validada de endereço de correio eletrônico para o dispositivo cliente 2228 que indica que o endereço de correio eletrônico foi validado. O fluxo, então, se move para a operação 2230 e o serviço de registro 2130 recebe uma solicitação de correio eletrônico de ativação do dispositivo cliente 2228 que inclui o endereço de correio eletrônico, ID de perfil e credenciais de perfil. O serviço de registro 2130, então, determina se as credenciais de perfil são válidas para a ID de perfil na operação 2232. Se estas não forem, então o fluxo se move para a operação 2224 e uma ação alternativa é tomada (por exemplo, o serviço de registro 2130 transmite uma mensagem de erro para o dispositivo cliente 2110A). Se as credenciais de perfil forem válidas, então o fluxo se move para a operação 2240.

[0098] Na operação 2240, o serviço de registro 2130 gera ou acessa as credenciais de correio eletrônico para o endereço de correio eletrônico. Por exemplo, em uma modalidade, o servidor de conta de sessão de comunicação online 2140 armazena as credenciais de correio eletrônico para cada endereço de correio eletrônico validado de um usuário nessa gravação de perfil do usuário 2150. O fluxo, então, se move para operação 2242 e o serviço de registro 2130 transmite uma mensagem de sucesso de ativação para o dispositivo cliente 2110A que inclui o endereço de correio eletrônico e as credenciais de correio eletrônico.

[0099] O fluxo se move da operação 2242 para a operação 2244 e o serviço de registro 2130 recebe uma mensagem de solicitação de registro que inclui o endereço de correio eletrônico, as credenciais de correio eletrônico, a ID de perfil, as credenciais de perfil, o token de prosseguimento do dispositivo cliente 2110A e a ID de dispositivo do dispositivo cliente 2110A. Em uma modalidade, a mensagem de solicitação é recebida na sessão de comunicação online servidor de registro 2145. o servidor de registro de sessão de comunicação online gerencia a sessão de comunicação online armazenamento de dados de registro 2155. A sessão de comunicação online armazenamento de dados de registro 2155 associa um token de prosseguimento (e opcionalmente a ID de dispositivo) ao perfil que tem um conjunto de um ou mais endereços de correio eletrônico como identificador(es) de ponto de extremidade de sessão de comunicação online. Assim, cada gravação no armazenamento de dados de registro de sessão de comunicação 2155 representa que um dispositivo particular com um token de prosseguimento particular esta usando um perfil de sessão de comunicação online que tem um ou mais endereços de correio eletrônico que podem ser usados para convidar um usuário nesse dispositivo para uma sessão de comunicação online. O fluxo se move da operação 2244 para a operação 2246.

[00100] Na operação 2246, o serviço de registro 2130 (por exemplo, o servidor de registro de sessão de comunicação online 2145) determina se as credenciais de perfil são válidas. Se estas não forem válidas, então o fluxo se move para a operação 2250 e uma ação alterna- tiva é tomada (por exemplo, o serviço de registro 2130 transmite uma mensagem de erro para o dispositivo cliente 2110A). Se estas forem válidas então o fluxo se move para a operação 2248 e o serviço de registro 2130 (por exemplo, o servidor de registro de sessão de comunicação online 2145) determina se as credenciais de endereço de correio eletrônico são válidas. Se estas não forem válidas, então o fluxo se move para a operação 2250. Se estas forem válidas, então o fluxo se move para a operação 2252.

[00101] Na operação 2252, o serviço de registro 2130 (por exemplo, o servidor de registro de sessão de comunicação online 2145) associa o dispositivo cliente 2110A com seu token de prosseguimento ao perfil que tem o endereço de correio eletrônico e armazena a associação no armazenamento de dados de registro 2155. O fluxo, então, se move para operação 2254 e o serviço de registro 2130 gera um identificador de conta de sessão de comunicação online e credenciais de sessão de comunicação online e os transmite para o dispositivo cliente 2110A na operação 2256.

[00102] Há diferentes modos de validar endereços de correio eletrônico em diferentes modalidades. Com referência à figura 24, que é um fluxograma que ilustra operações exemplificativas para validar um endereço de correio eletrônico, na operação 2410, o dispositivo cliente 2110A determina se inclui um cliente de correio eletrônico que inclui uma conta para um endereço de correio eletrônico que este tentou registrar e não recebeu uma mensagem de correio eletrônico de validação positiva. Se não incluir tal cliente de correio eletrônico, então o fluxo se move para a operação 2440, de outra maneira o fluxo se move para a operação 2415.

[00103] Na operação 2415, a conta de correio eletrônico é automaticamente verificada periodicamente para uma mensagem de correio eletrônico de validação (por exemplo, a mensagem de correio eletrôni- co de validação transmitida na operação 2227). Em uma modalidade, a aplicação de sessão de comunicação online 2115 solicita periodicamente que o cliente de correio eletrônico 2120 verifique a mensagem de correio eletrônico de validação (o cliente de correio eletrônico 2120 pode nomear o servidor de correio eletrônico 2170 para verificar a mensagem de correio eletrônico de validação). A mensagem de correio eletrônico de validação é identificada por um conjunto de um ou mais critérios incluindo o campo De:, campo Para:, e um token de validação (o token de validação pode ser único para cada endereço de correio eletrônico sendo validado) que é usado para validar o endereço de correio eletrônico. O token de validação pode estar localizado no leitor ou no corpo da mensagem de correio eletrônico de validação. Se a mensagem de correio eletrônico de validação for recebida, então o fluxo se move da operação 2420 para a operação 2425, de outra maneira o fluxo se move para a operação 2435.

[00104] Na operação 2425, a mensagem de correio eletrônico de validação é retornada para a aplicação de sessão de comunicação online 2115 e esta analisa a mensagem para localizar o token de validação. Após localizar o token de validação, a aplicação de sessão de comunicação online 2115 transmite uma mensagem de validação de endereço de correio eletrônico para o serviço de registro 2130 com o token de validação, o endereço de correio eletrônico, a ID de perfil e as credenciais de perfil. Assim, nessa modalidade, o endereço de correio eletrônico é validado automaticamente sem exigir que o usuário clique em um enlace ou valide de outra maneira o endereço de correio eletrônico. Em uma modalidade, após receber a mensagem e determinar que as credenciais de perfil são válidas, o serviço de registro 2130 transmite uma mensagem validada por push de correio eletrônico (por meio do serviço de notificação de prosseguimento 640) para o dispositivo que indica que o endereço de correio eletrônico foi validado de modo bem sucedido. Assim, o fluxo se move da operação 2425 para a operação 2430 e o dispositivo cliente 2110A espera receber a mensagem validada por push de endereço de correio eletrônico.

[00105] Se uma mensagem de correio eletrônico de validação não tiver sido recebida, então o fluxo se move para a operação 2435 onde o dispositivo cliente determina se uma mensagem validada por push de correio eletrônico foi recebida que indica que o endereço de correio eletrônico que está tentando ser registrado foi validado. Se tal mensagem for recebida, então o fluxo se move para a operação 2445, de outra maneira o fluxo se move de volta para a operação 2415.

[00106] Na operação 2440 (o dispositivo cliente 2110A não inclui um cliente de correio eletrônico que inclui uma conta para o endereço de correio eletrônico que está sendo registrado), o dispositivo cliente 2110A espera para receber uma mensagem validada por push de correio eletrônico que foi recebida que indica que o endereço de correio eletrônico que está tentando ser registrado foi validado. Se tal mensagem for recebida, então o fluxo se move para a operação 2445, de outra maneira o fluxo permanece na operação 2440.

[00107] Na operação 2445, o dispositivo cliente 2110A exibe que o endereço de correio eletrônico foi validado e consulta o usuário para continuar com o processo de registro com esse endereço de correio eletrônico. Se o dispositivo cliente 2110A receber uma entrada indicando para continuar com o processo de registro, então, o fluxo se move para a operação 2455 e o dispositivo cliente 2110A transmite uma solicitação de correio eletrônico de ativação que inclui o endereço de correio eletrônico, ID de perfil e as credenciais de perfil para o servidor de registro. As operações descritas começando na operação 2230 da figura 22 são, então, realizadas. Se o dispositivo cliente 2110A receber uma entrada indicando que o usuário não quer continuar com o processo de registro, então o fluxo se move da operação 2450 para a operação 2460 e o processo é encerrado.

[00108] A figura 25 é um fluxograma que ilustra operações exempli- ficativas realizadas no serviço de registro quando um endereço de correio eletrônico foi validado de acordo com uma modalidade. Na operação 2510, o serviço de registro 2130 recebe uma mensagem de estado validada de endereço de correio eletrônico que indica que um endereço de correio eletrônico que é associado a um perfil de sessão de comunicação online foi validado. A mensagem de estado validada de endereço de correio eletrônico pode ter sido recebida como um resultado da operação 2425 ou mensagem de estado validada de endereço de correio eletrônico do endereço de correio eletrônico sendo validado de um modo diferente (por exemplo, um usuário clicando em um enlace de validação em uma mensagem de correio eletrônico de validação que faz com que o endereço de correio eletrônico seja validado, que pode ser enviada em um dispositivo diferente do dispositivo que está tentando registrar o endereço de correio eletrônico para o uso em sessões de comunicação online).

[00109] O fluxo, então, se move para a operação 2515 e o serviço de registro 2130 atualiza o estado de validação para o endereço de correio eletrônico nas gravações de perfil 2150. O fluxo, então, se move para a operação 2515 e o serviço de registro 2130 determina se há dispositivos clientes que são associados ao perfil de sessão de comunicação online que pediram para validar o endereço de correio eletrônico que não receberam uma mensagem validada de endereço de correio eletrônico. Por exemplo, o serviço de registro 2130 acesa a gravação de perfil 2150 para o perfil de sessão de comunicação online para determinar quais dispositivos clientes (por exemplo, conforme identificados por tokens de prosseguimento únicos) pediram para validar o endereço de correio eletrônico e quais não receberam uma mensagem validada de endereço de correio eletrônico para esse endereço de cor- reio eletrônico. Para cada tal dispositivo cliente, o serviço de registro transmite uma mensagem validada por push de correio eletrônico para esse dispositivo cliente que inclui a ID de perfil, as credenciais de perfil e o endereço de correio eletrônico que foi validada na operação 2525. A mensagem validada por push de correio eletrônico pode também incluir uma atualização de estado para indicar que o endereço de correio eletrônico foi validado. Se não houver nenhum dispositivo que pediu para validar o endereço de correio eletrônico que não recebeu uma mensagem validada de endereço de correio eletrônico, então o fluxo se move para a operação 2530 e o processo é encerrado. Estabelecendo Sessões de Comunicação Online

[00110] Conforme ilustrado na figura 6, uma topologia de rede geral implantada em uma modalidade pode incluir vários dispositivos clientes A-N, 670A-N, respectivamente, comunicando-se entre si e com um ou mais serviços 610, 620, 630, 640 e 650 através de uma rede 660. Embora ilustrado como uma única nuvem de rede, a rede 660 pode incluir uma variedade de componentes diferentes incluindo redes publicas tal como a Internet e redes privadas tais como redes Wi-Fi locais (por exemplo, redes sem fio domésticas 802.11n ou pontos de acesso sem fios), redes Ethernet de área local, redes de dados celulares (por exemplo, 3G, 4G, Edge etc.) e redes WiMAXs, para nomear alguns. Os dispositivos clientes 670A-N podem se conectar à rede 660 através de diferentes enlaces de rede. Por exemplo, o dispositivo cliente 670A pode ser conectado a uma rede Wi-Fi doméstica representada pelo enlace de rede 675A e o dispositivo cliente 670N pode ser conectado a uma rede 3G (por exemplo, Sistema de Telecomunicações Móveis Universal ("UMTS"), Acesso de Pacote de Enlace Ascendente de Alta Velocidade ("HSUPA") etc.) através do enlace de rede 675N. Cada um dos enlaces de rede 675A-N através dos quais os dispositivos clientes 670A-N são conectados pode ser acoplado a uma rede pública tal co- mo a Internet através de um dispositivo de porta e/ou NAT (Tradução de Endereço de Rede) (não mostrado na figura 6), através disso permitindo a comunicação entre os vários dispositivos clientes 670A-N através da rede pública. Entretanto, se dois dispositivos clientes estiverem na mesma rede local ou privada (por exemplo, a mesma rede Wi-Fi), então os dois dispositivos podem se comunicar diretamente através dessa rede local/privada, contornando a rede pública. Deve ser notado, certamente, que os princípios subjacentes da invenção não são limitados a qualquer conjunto de tipos de rede particular ou topologias de rede.

[00111] Cada um dos dispositivos clientes 670A-N pode se comunicar com um serviço de troca de dados de conexão (CDX) 610, um serviço de convite 620, um serviço de registro 630, um serviço de notificação de prosseguimento 640 e um serviço de retransmissão 650. Em uma modalidade, os serviços 610 a 650 podem ser implantados como software executado através de um ou mais dispositivos de computação físicos tal como servidores.

[00112] Em uma modalidade, o serviço de CDX 610 opera como um ponto de troca central para os dados de conexão exigidos para estabelecer as sessões de comunicação online entre dois ou mais dispositivos clientes. Especialmente, uma modalidade do serviço de CDX 610 gera dados de passagem de NAT (algumas vezes referidos como dados de "Perfuração") em resposta às solicitações de dispositivo cliente para permitir que os clientes e serviços externos se comuniquem através da NAT de cada dispositivo cliente (isto é, "perfurar" através da NAT para alcançar o dispositivo). Por exemplo, em uma modalidade, o serviço de CDX detecta a porta e o endereço de IP externo necessários para se comunicar com o dispositivo cliente e fornece essas informações para o dispositivo cliente. Em uma modalidade, o serviço de CDX também recebe e processa listas de dispositivos clientes geradas pelo serviço de convite 620 e distribui de modo eficaz e seguro os dados de conexão para cada um dos dispositivos clientes incluídos nas listas (conforme descrito em detalhes abaixo).

[00113] Os usuários dos dispositivos clientes 670A-N usam o serviço de convite 620 para convidar usuários para participarem em sessões de comunicação online colaborativas (por exemplo, conferencia de vídeo P2P, conferencia/bate-papos de mensagem instantânea P2P etc.). Por exemplo, um usuário do dispositivo cliente 670A solicita uma sessão de comunicação online com um ou mais usuários de um ou mais dispositivos clientes diferentes transmitindo-se uma solicitação de convite para o serviço de convite 620 que inclui um identificador de ponto de extremidade de sessão de comunicação online de cada um dos outros usuários. O identificador de ponto de extremidade de sessão de comunicação online pode ser diferente em modalidades diferentes (por exemplo, um número de telefone, um nome de usuário (por exemplo, uma ID da Apple), um endereço de correio eletrônico, um endereço postal, um endereço de MAC ou outro identificador). O serviço de convite 620 lê o(s) identificador(es) de ponto de extremidade de sessão de comunicação online da solicitação de convite e realiza uma pesquisa no armazenamento de dados de registro 655 para localizar o(s) dispositivo(s) cliente(s) que é(são) associado(s) com o(s) identifi- cador(es) de ponto de extremidade de sessão de comunicação online.

[00114] Os dispositivos clientes 670A-N usam o serviço de registro 630 para se registrar para sessões de comunicação online. Por exemplo, em uma modalidade, quando cada um dos dispositivos clientes 670A-N está ligado e está ativado na rede, isso faz com que seu token de identificação (por exemplo, seu token de prosseguimento) seja associado a um identificador de ponto de extremidade de sessão de comunicação online. As associações são armazenadas no armazenamento de dados de registro 655. Em uma modalidade, os dispositivos clientes 670A-N registram para a participação para o serviço de sessão de comunicação online com o uso do serviço de registro 630 conforme descrito com respeito à figura 4, enquanto em outras modalidades o processo de registro ocorre de modo diferente (por exemplo, fornecendo-se tanto seu token de prosseguimento e quanto seu identificador de ponto de extremidade de sessão de comunicação online).

[00115] O serviço de notificação de prosseguimento 640 usa os tokens de prosseguimento dos dispositivos clientes 670A-N para transmitir notificações por push para os dispositivos clientes 670A-N. Em uma modalidade, as notificações por push são usadas para transmitir os convites para as sessões de comunicação online. O serviço de retransmissão 650 estabelece as conexões de sessão de comunicação online entre os dispositivos clientes quando os tipos de NAT dos dispositivos clientes não são compatíveis ou o estabelecimento de conexão P2P falhou entre os dispositivos clientes.

[00116] Em uma modalidade, a comunicação entre os dispositivos cliente e o serviço de CDX 610 é estabelecido com o uso de um protocolo de rede relativamente leve tal como soquetes de Protocolo de Da- tagrama de Usuário ("UDP"). Conforme é conhecido por aqueles versados na técnica, as conexões de soquete de UDP não exigem diálogos de sinalização para garantir a confiabilidade de pacote, classificação ou integridade de dados e, portanto, não consomem tanta sobrecarga de processamento de pacote quanto conexões de soquete TCP. Consequentemente, a natureza apátrida e leve do UDP é útil para os servidores que respondem pequenas consultas de um vasto número de clientes. Além disso, diferente do TCP, o UDP é compatível com a difusão de pacote (em que os pacotes são enviados para todos os dispositivos em uma rede local) e a difusão seletiva (em que os pacotes são enviados para um subconjunto de dispositivos na rede local) de pacote. Conforme descrito abaixo, embora o UDP possa ser usado, a segurança pode ser mantida no serviço de CDX 610 pela criptografia dos dados de passagem de NAT com o uso de chaves de sessão.

[00117] Em contraste ao protocolo de rede leve e de sobrecarga baixa usado pelo serviço de CDX 610, em uma modalidade, a comunicação entre os dispositivos clientes 670A-N e o serviço de convite 620, serviço de registro 630, serviço de notificação de prosseguimento 640 e/ou o serviço de retransmissão 650 é estabelecida com um protocolo de rede inerentemente seguro tal como Protocolo de Transferência de Hipertexto Seguro ("HTTPS"), que se baseia nas conexões de Camada de Soquetes Segura ("SSL") ou Segurança de Camada de Transporte ("TLS"). Os detalhes associados a esses protocolos são bem conhecidos por aqueles versados na técnica.

[00118] A figura 7 é um fluxograma de dados que ilustra estabelecimento de sessão de comunicação online entre os dispositivos clientes de acordo com uma modalidade. No exemplo da figura 7, um usuário no dispositivo cliente A 710 convida um usuário no dispositivo cliente B 720 para uma sessão de comunicação online (por exemplo, uma conferência de vídeo P2P, um sistema de mensagem instantânea P2P etc.). Nesse exemplo, o dispositivo cliente A 710 é algumas vezes denominado como um dispositivo cliente iniciador, o usuário do dispositivo cliente B 720 é algumas vezes denominado como um recipiente destinado, e o dispositivo cliente B 720 é algumas vezes denominado como um dispositivo cliente de recipiente destinado. Em algumas modalidades, um convite de sessão de comunicação online é um convite cego sem presença. Por exemplo, o usuário no dispositivo cliente A 710 não sabe se o usuário no dispositivo cliente B 720 está atualmente online ou disponível para participar na sessão de comunicação online.

[00119] Enquanto as modalidades descritas tendo como referência as figuras 6 e 7 são exclusivas para usar token de prosseguimento e notificações de push, outras modalidades não são tão limitadas. Por exemplo, em outras modalidades, qualquer registro ou mapeamento dos dispositivos clientes para tokens únicos pode ser usado para associar tokens de identificação com os dispositivos clientes e para fornecer um método confiável de associação da identidade do dispositivo cliente com um token identificado de modo único.

[00120] Na operação 1, o dispositivo cliente A 710 solicita seus dados de conexão a partir da troca de dados de conexão 610. Os dados de conexão incluem informações para que os dispositivos clientes troquem com um com os outros para estabelecer uma sessão de comunicação online (por exemplo, uma sessão P2P). Os dados de conexão incluem o endereço de IP do dispositivo cliente (por exemplo, o endereço de IP público), o número de porta da solicitação, e outras informações (por exemplo, informações de prioridade etc.). A troca de dados de conexão 610 determina os dados de conexão do dispositivo cliente A 710 (por exemplo, os endereços de IP públicos/privados e as portas, tipo de NAT do dispositivo A NAT de dispositivo cliente). Na operação 2, a troca de dados de conexão 610 retorna os dados de conexão ao dispositivo cliente A 710.

[00121] Na operação 3, o dispositivo cliente A 710 transmite uma solicitação de convite de sessão de comunicação online para o serviço de convite 620 para convidar o dispositivo cliente B 720 para uma sessão de comunicação online (por exemplo, uma conferência de vídeo P2P, uma sessão de mensagens instantâneas P2P etc.). Em uma modalidade, o convite inclui os dados de conexão de dispositivo cliente A 710, que podem incluir endereços de IP públicos/privados e portas para dispositivo cliente A 710 e o tipo de NAT para o dispositivo A NAT de dispositivo cliente, e um identificador de ponto final de sessão de comunicação online associado ao usuário no dispositivo cliente B 720 (por exemplo, um número de telefone do dispositivo cliente B 720, um nome de usuário do usuário (por exemplo, uma ID da Apple), um en- dereço de correio eletrônico, um endereço postal, um endereço de MAC etc.). A solicitação de convite de sessão de comunicação online pode tomar a forma de uma solicitação HTTPS e pode incluir um certificado de cliente assinado por uma autoridade de certificado pré- especificada.

[00122] Na operação 4, o serviço de convite 620 determina o(s) to- ken(s) por push associado(s) ao identificador de ponto final de sessão de comunicação online incluído na solicitação de operação 3. Por exemplo, o serviço de convite 620 acessa o armazenamento de dados de registro 655 para determinar o(s) token(s) por push que está(ão) associado(s) ao identificador de ponto final de sessão de comunicação online. Conforme ilustrado na figura 7, o token de prosseguimento 725 é designado ao dispositivo cliente B 720 e assim, é associado ao seu identificador de ponto final de sessão de comunicação online. A figura 10 ilustra um armazenamento de dados de registro exemplificador 655 de acordo com uma modalidade. Conforme ilustrado na figura 10, cada um dentre os registros identificadores de sessão de comunicação online 1010 inclui um campo de token de prosseguimento 1015 e uma campo identificador de sessão de comunicação online 1020. Conforme ilustrado na figura 10, o mesmo identificador de sessão de comunicação online pode ser associado aos tokens de prosseguimento múltiplos. Em tal caso, convites múltiplos serão transmitidos (por exemplo, um por token de prosseguimento).

[00123] O serviço de convite 620 transmite uma mensagem de solicitação de push para o serviço de notificação de push 640. Na operação 5, o serviço de notificação de push 640 transmite uma solicitação de convite de sessão de comunicação online, na forma de uma mensagem de notificação de push, para o dispositivo cliente B 720. A solicitação inclui os dados de conexão, o identificador de ponto final de sessão de comunicação online, e o token de prosseguimento do dis- positivo cliente A 710 (o token de prosseguimento 715). A solicitação de convite também pode incluir informações específicas para a sessão de comunicação online para fornecer o usuário do dispositivo cliente B 720 com informações sobre o convite (por exemplo, o nome da pessoa que envia o convite (por exemplo, nome de usuário, nome real, número de telefone, ou alguma combinação dos mesmos), que o convite é para (por exemplo, uma conferência de vídeo P2P, uma sessão de mensagens instantâneas P2P etc.) etc.).

[00124] A solicitação de convite de sessão de comunicação online será recebida e exibida no dispositivo cliente B 720 se o mesmo é ativado e operado corretamente. A solicitação de convite inclui um mecanismo para que o usuário aceite ou negue o convite (por exemplo, um botão de aceitar e um botão de negar). O usuário no dispositivo cliente A 710 pode receber uma notificação se a solicitação de convite é negada. Assumindo que um usuário no dispositivo cliente B 720 aceite o solicitação de convite, na operação 6 o dispositivo cliente B 720 solicita seus dados de conexão a partir da troca de dados de conexão 610. A troca de dados de conexão 610 determina os dados de conexão do dispositivo cliente B 720 (por exemplo, os endereços de IP públicos/privados e as portas, tipo de NAT do dispositivo de B NAT de dispositivo cliente), e na operação 7, retorna os dados de conexão para o dispositivo cliente B 720.

[00125] O dispositivo cliente B 720 transmite então uma mensagem de aceitação ao serviço de convite 620 na operação 8. A mensagem de aceitação inclui os dados de conexão de dispositivo cliente B 720 e inclui os token de prosseguimento do dispositivo cliente A 710. A mensagem de aceitação também pode conter uma indicação se a mesma é uma repetição de uma tentativa anterior de conexão P2P direta que falhou entre o dispositivo cliente A 710 e o dispositivo cliente B 720. A mensagem de aceitação pode tomar a forma de uma mensagem de HTTPS.

[00126] Em algumas modalidades, o serviço de convite 620 determina se uma conexão P2P entre o dispositivo cliente A 710 e o dispositivo cliente B 720 é praticável. Na operação 9, o serviço de convite 620 determina se uma conexão P2P direta entre os dispositivos clientes A e B é praticável. Por exemplo, em uma modalidade, se a mensagem de aceitação recebida a partir do dispositivo cliente B 620 indicar que a mesma é uma repetição de uma tentativa anterior de conexão direta que falhou (ou um número especificado de tentativas anteriores de conexão direta que falharam), então, o serviço de convite 620 pode concluir que uma conexão P2P direta é impraticável. Para determinar a praticabilidade, o serviço de convite 620 pode comparar o tipo de dados de NAT para os dispositivos clientes A e B para determinar se os dispositivos de NAT dos dispositivos clientes A e B irão dar suporte a uma conexão P2P direta. Em uma modalidade, a mensagem de aceitação descrita acima não inclui uma indicação de tentativas anteriores que falharam. Ao invés disso, após uma tentativa anterior de conexão direta que falhou um dos dispositivos clientes de 710 a 720 pode transmitir uma solicitação de "convite de retransmissão" especial (por exemplo, em vez da solicitação de convite na operação 3 na figura 7) que indica que uma conexão de retransmissão é necessária. Em resposta, o serviço de convite pode invocar automaticamente as operações de retransmissão descritas no presente documento (conforme descrito abaixo).

[00127] Determinadas combinações de tipos de NAT são conhecidas como sendo incompatíveis para estabelecer as conexões P2P. Por exemplo, um NAT de cone completo pode ser usado com qualquer outro tipo de NAT exceto um NAT fechado/protegido por firewall para estabelecer uma conexão P2P direta. Em contraste, um NAT simétrico pode apenas ser usado com um NAT de cone completo para estabele- cer uma conexão P2P direta. A praticabilidade de combinar vários tipos de NAT em uma modalidade é estabelecida na tabela de compatibilidade de NAT1110 mostrada na figura 11, em que as colunas representam tipos de NAT de um dispositivo cliente (por exemplo, dispositivo cliente A 710) e as linhas representam os tipos de NAT do outro dispositivo cliente (por exemplo, dispositivo cliente B 720). Um "1.0" em uma célula indica que os tipos de NAT na linha e na coluna associada são compatíveis e um "0.0" indica que os tipos de NAT são incompatíveis.

[00128] Se o serviço de convite 620 determinar que uma conexão P2P direta é praticável, então, o serviço de convite 620 transmite uma solicitação de push para o serviço de notificação de push 640 para transmitir a aceitação da solicitação de convite. Assim, na operação 10B, o serviço de notificação de push 640 transmite uma mensagem de aceitação de sessão de comunicação online, na forma de uma notificação de push, para o dispositivo cliente A 710. A mensagem de aceitação inclui os dados de conexão, o identificador de ponto final de sessão de comunicação online, e o token de prosseguimento do dispositivo cliente B 720. A mensagem de aceitação será exibida no dispositivo cliente A 710. Visto que os dispositivos clientes A e B têm os dados de conexão um do outro, os dispositivos clientes A e B têm informações suficientes para estabelecer uma conexão P2P direta. Assim, na operação 11A, os dispositivos clientes A e B estabelecem uma conexão P2P direta através do uso de dados de conexão trocados. A conexão P2P direta pode ser estabelecida através de mecanismos conhecidos (por exemplo, através do uso de Estabelecimento de Conectividade de Internet (ICE) ou outros mecanismos de conectividade P2P).

[00129] Se, no entanto, o serviço de convite 620 determina qual conexão P2P direta é impraticável, então, transmite a retransmite a soli- citação na operação de pesquisa 10B paro o serviço de retransmissão 650 para determinar uma ou mais hospedagens de retransmissão para os dispositivos clientes A e B para usar para a conexão. A solicitação de pesquisa de retransmissão pode conter as informações de rede para os dispositivos clientes A e B (por exemplo, dados de percurso de NAT/conexão e/ou tipo de dados de NAT) que é usado pelo serviço de retransmissão 650 para selecionar hospedagens de retransmissão apropriadas para ambos os dispositivos clientes.

[00130] Conforme ilustrado na figura 8, em uma modalidade, o serviço de retransmissão 650 inclui um módulo de pesquisa de retransmissão 805, hospedagens de retransmissão múltiplas 815A-B, e um banco de dados de hospedagem de retransmissão 810 que contém informações de rede relacionadas a cada uma das hospedagens de retransmissão 815A-B. Enquanto a figura 8 ilustra duas hospedagens de retransmissão, deveria ser entendido que pode haver mais ou menos hospedagens de retransmissão em algumas modalidades. O serviço de convite 620 transmite uma solicitação de pesquisa de retransmissão para o módulo de pesquisa de retransmissão 805, que consulta o banco de dados de hospedagem de retransmissão 810 mediante o uso das informações de rede para os dispositivos clientes A e B. Mediante o recebimento dos resultados do banco de dados, o módulo de pesquisa de retransmissão 805 fornece uma resposta que identifica as hospedagens de retransmissão selecionadas 815A-B na operação 11B para o serviço de convite 620.

[00131] Em uma modalidade, a resposta de pesquisa de retransmissão contém um token de retransmissão gerado pelo serviço de retransmissão 650 e o endereço de rede (endereços de IP/portas) das hospedagens de retransmissão selecionadas 815A-B a ser usado pelos dispositivos clientes A e B para a conexão de retransmissão. Em uma modalidade, o token de retransmissão é associado com a sessão de retransmissão e é usado pelas hospedagens de retransmissão 815A-B para autenticar os dispositivos clientes A e B mediante a conexão ao serviço de retransmissão 650. O token pode tomar várias formas incluindo, Por exemplo, código de ID de sessão de retransmissão de ID único, um certificado digital e/ou uma chave de criptografia única associada à sessão de retransmissão.

[00132] O serviço de convite 620 transmite uma resposta de retransmissão para os dispositivos clientes A e B que indica que uma conexão de retransmissão será feita. Em uma modalidade, a resposta de retransmissão para o dispositivo cliente B pode incluir o token de retransmissão e as informações de rede para a hospedagem de retransmissão 815B. Em uma modalidade, a resposta para o dispositivo cliente B pode ser enviada diretamente (que ultrapassa o serviço de notificação de push 640) pelo fato de que a mesma está sendo enviada em resposta à mensagem de aceitação de convite B de dispositivo cliente. O serviço de convite 620 também transmite uma resposta de retransmissão para o dispositivo cliente A, que pode incluir o token de retransmissão e as informações de rede para hospedagem de retransmissão A 815A. Nesse caso, a resposta é transmitida para o dispositivo cliente A através do serviço de notificação de push 640.

[00133] Na operação 12B, o dispositivo cliente A 710 usa as informações de rede para a hospedagem de retransmissão 815A para estabelecer uma conexão com o serviço de retransmissão 650. De maneira similar, na operação 13B, o dispositivo cliente B 720 usa as informações de rede para a hospedagem de retransmissão 815B para estabelecer uma conexão com o serviço de retransmissão 650. Em cada uma dessas transações, novos furos são abertos em qualquer firewall de NAT dos dispositivos clientes A e B e dos dados de percurso de NAT/conexão para os dispositivos clientes A e B podem ser determinados pelo serviço de retransmissão 650 e retornados aos dispo- sitivos clientes A e B, respectivamente (por exemplo, mediante a de-terminação do IP público/porta para os dispositivos). Em uma modalidade, o serviço de retransmissão 650 e os dispositivos clientes A e B implantam o protocolo de NAT De Retransmissão com Uso de Percurso ("TURN"), que conforme entendido pelos versados na técnica, permite um elemento atrás de um NAT ou de um firewall para receber dados de entrada através de conexões de TCP ou UDP.

[00134] Na operação 14B, o dispositivo cliente A 710 transmite uma atualização de retransmissão para o serviço de convite 620, que é en-caminhada para o serviço de notificação de push e transmitida por push para o dispositivo cliente B 720 na operação 17B. De maneira similar, na operação 15B, o dispositivo cliente B 720 transmite uma atualização de retransmissão para o serviço de convite 620 que é encaminhada para o serviço de notificação de push 620 e transmitida por push para o dispositivo cliente A 610 na operação 16B. A atualização de retransmissão transmitida pelo dispositivo cliente A 710 pode incluir o token de sessão, cada identificador de ponto final de sessão de comunicação online do dispositivo, e os dados de percurso de NAT/conexão determinados pelo serviço de retransmissão 650.

[00135] Na operação 18B e 19B os dispositivos clientes A e B, res-pectivamente, estabelecem uma conexão de sessão de comunicação online através do serviço de retransmissão 650. Em uma modalidade, as conexões de retransmissão podem ser estabelecidas quando o dispositivo cliente A 710 envia os dados de percurso de NAT/conexão do dispositivo cliente B 720 para o serviço de retransmissão 650, e vice versa, que permite através disso o serviço de retransmissão para determinar a trajetória correta para cada hospedagem de retransmissão do par 815A-B.

[00136] Através do uso das técnicas descritas acima, o serviço de convite 620 pode ser implantado como um serviço sem monitoração de situação, que é inerentemente escalável e resiliente, até mesmo em um sistema em larga escala com um vasto número de dispositivos clientes. Por exemplo, pelo fato de que o serviço de notificação de push 640 é inerentemente capaz de localizar e enviar mediante push o conteúdo para os dispositivos clientes registrado, o serviço de convite 620 não é necessário para rastrear a localização atual de cada dispositivo. Adicionalmente, pelo fato de que os dispositivos podem transmitir os dados de percurso de NAT/conexão com solicitações e respostas, o serviço de convite 620 nunca é necessário para manter quaisquer informações de situação por conexão, que reduz através disso o armazenamento e requerimentos de processamento do serviço de convite. Tal implantação é particularmente útil em um sistema de larga escala.

[00137] Enquanto a figura 7 descreve um usuário em um dispositivo cliente que convida um usuário único para uma sessão de comunicação online, as modalidades não são tão limitadas. Por exemplo, em algumas modalidades, um usuário em um dispositivo cliente pode convidar múltiplos usuários para uma sessão de comunicação online. Por exemplo, o usuário pode transmitir uma mensagem de solicitação de convite única para o serviço de convite com múltiplos identificadores de ponto final de sessão de comunicação online para convidar múltiplos usuários em diferentes dispositivos clientes para participar em uma sessão de comunicação online.

[00138] Em algumas situações, um usuário pode ter múltiplos dispositivos clientes que estão associados ao mesmo identificador de ponto final de sessão de comunicação online. A figura 26 é um fluxo- grama de dados que ilustra as operações exemplificadoras para gerenciar os convites quando um usuário tem múltiplos dispositivos clientes que estão associados ao mesmo identificador de ponto final de sessão de comunicação online.

[00139] O dispositivo cliente A (operado pelo usuário A) 2610 transmite uma solicitação de seus dados de conexão a partir da troca de dados de conexão 610 na operação 2632. A troca de dados de conexão 610 retorna dados de conexão de dispositivo cliente A na operação 2634. O dispositivo cliente, então, transmite uma solicitação de convite de sessão de comunicação online para o serviço de convite 620 com uma ID de usuário B para convidar o usuário B para uma sessão de comunicação online (por exemplo, uma conferência de vídeo P2P, uma sessão de mensagens instantâneas P2P, uma chamada de vídeo etc.). A solicitação de convite inclui dados de conexão A.

[00140] O serviço de convite executa umas pesquisa de diretório na operação 2638 com base na ID de B incluída na mensagem de solicitação de convite. Nesse exemplo, a operação de pesquisa de diretório retorna um token de prosseguimento para o dispositivo cliente B1 e um token de prosseguimento para o dispositivo cliente B2. Assim, os dispositivos clientes B1 e B2 estão associados à ID de B. O serviço de convite 620, então, transmite uma mensagem de solicitação de push na operação 2640 para o serviço de notificação de push 640 para enviar por push a mensagem de solicitação de convites para o dispositivo cliente B1 2615 e para o dispositivo cliente B2 2620. O serviço de notificação de push 640 transmite uma solicitação de convite de sessão de comunicação online, na forma de uma mensagem de notificação de push, para o dispositivo cliente B1 2615 na operação 2642 e para o dispositivo cliente B2 2620 na operação 2644. Cada mensagem de solicitação de convite inclui os dados de conexão do dispositivo cliente A 2610, O identificador de ponto final de sessão de comunicação online usado pelo usuário A, e o token de prosseguimento do dispositivo cliente A 2610. O convite solicita também pode incluir informações específicas sobre a sessão de comunicação online (por exemplo, o nome da pessoa que envia o convite (por exemplo, nome de usuário, nome real, número de telefone, ou alguma combinação dos mesmos), e que o convite é para (por exemplo, uma conferência de vídeo P2P, uma sessão de mensagens instantâneas P2P etc.) etc.). Assim, uma solicitação de convite de sessão de comunicação online é enviada para cada um dos dispositivos que estão associados ao identificador de ponto final de sessão de comunicação online incluído na solicitação de convite original.

[00141] Em uma modalidade, o serviço de convite 620 transmite uma mensagem de situação para o dispositivo cliente que convida para indicar qual dispositivo(s) de cliente o convite foi transmitido. Assim, na operação 2646, o serviço de convite 620 transmite uma atualização de situação de convite para o dispositivo cliente A 2610 que indica que uma solicitação de convite de sessão de comunicação online foi enviada para o dispositivo cliente B1 2615 e o dispositivo cliente B2 2620. Em uma modalidade, o dispositivo cliente A 2610 rastreia quais dispositivos clientes aceitam o convite e mantém os outros dispositivos clientes notificados sobre a situação da sessão de comunicação online.

[00142] Em uma modalidade, o dispositivo cliente B1 2615 e o dispositivo cliente B2 2620 exibirão uma solicitação de convite se os mesmos estiverem ativados e capazes de receber a solicitação de convite. No exemplo ilustrado na figura 26, um usuário no dispositivo cliente B1 2615 irá aceitar o convite. Assim, na operação 2648 o dispositivo cliente B1 2615 solicita seus dados de conexão a partir da troca de dados de conexão 610. A troca de dados de conexão 610 determina os dados de conexão do dispositivo cliente B1 2615 e na operação 2650 retorna os mesmos para o dispositivo cliente B1 2615.

[00143] O dispositivo cliente B1 2615 transmite uma mensagem de aceitação para o serviço de convite 620 na operação 2652. A mensagem de aceitação inclui os dados de conexão do dispositivo cliente B1 2615 e o token de prosseguimento do dispositivo cliente A 2610. A mensagem de aceitação também pode conter uma indicação de se a mesma é uma repetição de uma tentativa anterior de conexão P2P direta que falhou entre o dispositivo cliente A 2610 e o dispositivo cliente B1 2615. Adicionalmente, a mensagem de aceitação também pode incluir o identificador de ponto final de sessões de comunicação online de A e B e o token de prosseguimento para o dispositivo cliente B 2615.

[00144] Em algumas modalidades, após receber uma mensagem de aceitação a uma sessão de comunicação online, o serviço de convite 620 determina se uma conexão P2P direta é praticável. Assim, na operação 2654, o serviço de convite 620 executa uma verificação de compatibilidade P2P direta para determinar se uma conexão P2P direta entre o dispositivo cliente A 2610 e o dispositivo cliente B1 2615 é praticável, de uma maneira similar ao previamente descrito. Se os dispositivos clientes forem compatíveis para uma conexão P2P direta, então, as operações descritas tendo como referência a figura 27 (que começam na operação 2710) são executadas. Se os dispositivos clientes não forem compatíveis com uma conexão P2P direta, então, as operações descritas tendo como referência a figura 28 (que começam na operação 2810) são executadas.

[00145] Tendo como referência a figura 27, que ilustra as operações executadas quando uma conexão P2P direta é praticável, na operação 2710 o serviço de convite 620 transmite uma solicitação de push para o serviço de notificação de push 640 para transmitir a aceitação do convite pelo dispositivo cliente B1 2615. Na operação 2712, o serviço de notificação de push 640 transmite uma mensagem de aceitação de sessão de comunicação online, na forma de uma notificação de push, para o dispositivo cliente A 2610. Essa mensagem de aceitação inclui os dados de conexão e o token de prosseguimento do dispositivo cliente B1 2615, e o identificador de ponto final de sessão de comunicação online usado pelo usuário B.

[00146] Em uma modalidade, algum tempo após receber a mensagem de aceitação que indica que o dispositivo cliente B1 2615 aceitou o convite, o dispositivo cliente A 2610 informa o dispositivo cliente B2 2620 que o dispositivo cliente A 2620 aceitou o convite. Assim, na operação 2714, o dispositivo cliente A 2610 transmite uma solicitação de atualização de convite para o serviço de convite que inclui o identificador de ponto final de sessão de comunicação online do usuário B e indica que o dispositivo cliente B1 2615 aceitou o convite. A solicitação de atualização de convite também pode instruir ou indicar para o serviço de convite 620 qual dispositivo cliente associado ao identificador de ponto final de sessão de comunicação online de usuário B deveria receber a mensagem de atualização de convite (nesse exemplo, o dispositivo cliente B2 2620 deveria receber a mensagem de atualização de convite).

[00147] O serviço de convite 620 executa uma pesquisa de diretório 2716 com base no identificador de ponto final de sessão de comunicação online do usuário B para determinar o token de prosseguimento do dispositivo cliente B2 2620. Após determinar o token de prosseguimento, o serviço de convite transmite uma solicitação de push na operação 2718 para o serviço de notificação de push 640 para enviar por push a mensagem de atualização de convite para o dispositivo cliente B2 2620. Na operação 2720, o serviço de notificação de push 640 transmite uma mensagem de atualização de convite, na forma de uma mensagem de notificação de push, para o dispositivo cliente B2 2620. A mensagem de atualização de convite indica que o dispositivo cliente B1 2615 aceitou a convite de sessão de comunicação online. O dispositivo cliente B2 2620 pode exibir a mensagem de atualização de convite e pode manter a situação da sessão de comunicação online entre o dispositivo cliente A 2610 e o dispositivo cliente B1 2615 (por exemplo, a duração da sessão de comunicação online etc.). Conforme será descrito em maiores detalhes tendo como referência a figura 30, em uma modalidade, o dispositivo cliente B2 2620 pode transmitir uma solicitação de transferência para fazer com que a sessão de comunicação online transfira a partir do dispositivo cliente B1 2615 para o dispositivo cliente B2 2620.

[00148] Algum tempo após receber o convite mensagem de aceitação na operação 2712, o dispositivo cliente A 2610 e o dispositivo cliente B1 2615 estabelece uma conexão P2P direta através do uso de dados de conexão trocados na operação 2722. A conexão P2P direta pode ser estabelecida através de mecanismos conhecidos (por exemplo, mediante o uso Estabelecimento de Conectividade de Internet (ICE) ou outros mecanismos de conectividade P2P). Deveria ser entendido que a operação 2722 pode ser executada antes ou durante as operações de 2714 a 2720.

[00149] Enquanto a figura 26 descreve um exemplo em que apenas um único dispositivo cliente aceita a mensagem de convite, em algumas situações múltiplos dispositivos clientes pode aceitar um convite para uma sessão de comunicação online direcionada a um usuário único. Por exemplo, o dispositivo cliente B1 2615 e o dispositivo cliente B2 2620 podem aceitar o convite em algumas situações. Em uma modalidade, o dispositivo cliente A 2610 estabelece uma sessão de comunicação online com o primeiro dispositivo cliente do qual o mesmo recebe uma mensagem de aceitação. O dispositivo cliente A 2610 pode fazer com que uma mensagem de cancelamento seja enviada para o(s) outro(s) dispositivo(s) de cliente (por exemplo, uma mensagem de cancelamento pode ser transmitida para o serviço de convite e assim transmitida por push, através do serviço de notificação de push, para o(s) outro(s) dispositivo(s) cliente(s)).

[00150] Voltando-se novamente à operação 2654 da figura 26, se uma conexão P2P direta não for praticável entre o dispositivo cliente A 2610 e o dispositivo cliente B1 2615, então, as operações descritas na figura 28 são executadas. A figura 28 é um fluxograma de dados que ilustra as operações exemplificadoras que são executadas quando uma conexão P2P direta é impraticável. Na operação 2810, o serviço de convite 620 transmite uma solicitação de pesquisa de retransmissão 2810 para o serviço de retransmissão 650 para determinar uma hospedagem de retransmissão a ser usada pelo dispositivo cliente A 2610 e o dispositivo cliente B1 2615. A solicitação de pesquisa de retransmissão pode conter as informações de rede para os dispositivos clientes (por exemplo, dados de percurso de NAT/conexão e/ou tipo de dados de NAT) que é usado pelo serviço de retransmissão 650 para selecionar as hospedagens de retransmissão apropriadas para os dispositivos clientes. Conforme ilustrado na figura 8, uma modalidade do serviço de retransmissão 650 inclui uma pluralidade de hospedagens de retransmissão 815A-B e um banco de dados de hospedagem de retransmissão 810 que contém as informações de rede relacionada a cada uma das hospedagens de retransmissão. Por exemplo, o serviço de convite 620 transmite uma solicitação de pesquisa de retransmis-são para um serviço de retransmissão 650, que consulta o banco de dados de hospedagem de retransmissão 810 mediante o uso das informações de rede para os dispositivos clientes. Mediante o recebimento dos resultados da pesquisa no banco de dados, o serviço de retransmissão 650 fornece uma resposta de pesquisa de retransmissão na operação 1201 que identifica as hospedagens de retransmissão selecionadas 815A-B. Em uma modalidade, a resposta de pesquisa de retransmissão contém um token de retransmissão gerado pelo serviço de retransmissão 650 e o endereço de rede (endereços de IP/portas) das hospedagens de retransmissão 815A-B a serem usadas pelos dispositivos clientes para a conexão de retransmissão. Em uma modalidade, o token de retransmissão é associado à sessão de re- transmissão e é usado pelas hospedagens de retransmissão 815A-B para autenticar o dispositivo cliente A 2610 e o dispositivo cliente B1 2615 mediante a conexão com o serviço de retransmissão 650. O token pode tomar várias formas incluindo, Por exemplo, código de ID de sessão de retransmissão de ID único, um certificado digital e/ou uma chave de criptografia única associada à sessão de retransmissão.

[00151] O serviço de convite 620, então, transmite uma resposta de retransmissão para o dispositivo cliente B1 2615 na operação 2814 que contém uma indicação de que uma conexão de retransmissão será feita. Em uma modalidade, a resposta de retransmissão pode incluir o token de retransmissão e as informações de rede para a hospedagem de retransmissão selecionada para o dispositivo cliente B1 2615. Em uma modalidade, a resposta de retransmissão pode ser enviada diretamente para o dispositivo cliente B1 2615 (que ultrapassa o serviço de notificação de push 640). O serviço de convite 620 também transmite uma resposta de retransmissão para o dispositivo cliente A 2610 na operação 2816 que inclui o token de retransmissão e as informações de rede para a hospedagem de retransmissão selecionada para o dispositivo cliente A 2610. Em algumas modalidades, a resposta de retransmissão é transmitida por push para o dispositivo móvel A através do serviço de notificação de push 640.

[00152] Na operação 2818, o dispositivo cliente A 2610, então, transmite uma solicitação de atualização de convite para o serviço de convite 620 que inclui o identificador de ponto final de sessão de comunicação online de usuário B e indica que o dispositivo cliente B1 2615 aceitou o convite. A solicitação de atualização de convite também pode instruir ou indicar para o serviço de convite 620 qual dispositivo cliente associado ao identificador de ponto final de sessão de comunicação online de usuário B deveria receber a mensagem de atualização de convite (nesse exemplo, o dispositivo cliente B2 2620 deve- ria receber a mensagem de atualização de convite).

[00153] O serviço de convite 620 executa uma pesquisa de diretório 2820 com base no identificador de ponto final de sessão de comunicação online de usuário B para determinar o token de prosseguimento do dispositivo cliente B2 2620. Após determinar o token de prosseguimento, o serviço de convite transmite uma solicitação de push na operação 2822 para o serviço de notificação de push 640 para enviar por push a mensagem de atualização de convite para o dispositivo cliente B2 2620. Na operação 2824, o serviço de notificação de push 640 transmite uma mensagem de atualização de convite, na forma de uma mensagem de notificação de push, para o dispositivo cliente B2 2620. A mensagem de atualização de convite indica que o dispositivo cliente B1 2615 aceitou o convite de sessão de comunicação online. O dispositivo cliente B2 2620 pode exibir a mensagem de atualização de convite e pode manter a situação da sessão de comunicação online entre o dispositivo cliente A 2610 e o dispositivo cliente B1 2615 (por exemplo, a duração da sessão de comunicação online etc.). Em uma modalidade, o dispositivo cliente B2 2620 pode transmitir uma solicitação de transferência para fazer com que uma sessão de comunicação online transfira a partir do dispositivo cliente B1 2615 para o dispositivo cliente B2 2620.

[00154] Na operação 2826, o dispositivo cliente A 2610 usa as informações de rede para usa hospedagem de retransmissão selecionada para estabelecer uma conexão com o serviço de retransmissão 650. De maneira similar, na operação 2828, o dispositivo cliente B1 2620 usa as informações de rede para sua hospedagem de retransmissão selecionada para estabelecer uma conexão com o serviço de retransmissão 650. Em cada uma dessas operações, novos furos podem ser abertos em qualquer firewall de NAT dos dispositivos clientes e os dados de percurso de NAT/conexão para os dispositivos clientes podem ser determinados pelo serviço de retransmissão 650 e retornados aos mesmos (por exemplo, mediante a determinação de IP públi- co/porta dos dispositivos clientes). Em uma modalidade, o serviço de retransmissão 650 e o dispositivo cliente A 2610 e o dispositivo cliente B1 2615 implanta o protocolo de NAT de retransmissão com uso de percurso ("Turn") que, conforme entendido pelos versados na técnica, permite que um elemento atrás de NAT ou de firewall possa receber dados de entrada através de conexões TCP ou UDP.

[00155] Na operação 2830, o dispositivo cliente A 2610 transmite uma atualização de retransmissão para o serviço de convite 620 que é encaminhada para o serviço de notificação de push na operação 2832 e transmitida por push para o dispositivo cliente B1 2615 na operação 2834. De maneira similar, na operação 2836 o dispositivo cliente B1 2615 transmite uma atualização de retransmissão para o serviço de convite 620 que é encaminhada para o serviço de notificação de push 640 na operação 2838 e transmitida por push para o dispositivo cliente A 2610 na operação 2840. A mensagem de atualização de retransmissão transmitida pelo dispositivo cliente A 2610 pode incluir o token de retransmissão, cada identificador de sessão de comunicação online, e os dados de percurso de NAT/conexão determinados pelo serviço de retransmissão 650 nas operações 2826 e 2828. Em uma modalidade, as operações de atualização de retransmissão são executadas visto que um ou mais do dispositivo de informações de NAT do cliente podem ser alteradas. Finalmente, nas operações 2842 e 2844, o dispositivo cliente A 2610 e o dispositivo cliente B1 2620 respectivamente, estabelecem uma conexão P2P através do serviço de retransmissão 650. Em uma modalidade, as conexões de retransmissão podem ser estabelecidas em resposta ao dispositivo cliente A 2610 transmitir os dados de percurso de NAT/conexão do dispositivo cliente B1 2615 para o serviço de retransmissão 650, e vice versa, o que permite através disso o serviço de retransmissão 650 para determinar a trajetória correta para cada hospedagem de retransmissão do ponto.

[00156] A figura 29 é um fluxograma de dados que ilustra as operações exemplificadoras executadas quando uma sessão de comunicação online termina de acordo com uma modalidade. Na operação 2910, a sessão de comunicação online entre o dispositivo cliente A 2610 e o dispositivo cliente B1 2615 terminou. Por exemplo, ou o dispositivo cliente A 2610 ou o dispositivo cliente B1 2615 terminou a sessão de comunicação online (ou a sessão de comunicação online foi de outra forma, terminada). A sessão de comunicação online pode ter sido através de uma conexão P2P direta ou através de uma retransmissão.

[00157] Algum tempo após a sessão de comunicação online ter terminado, na operação 2912, o dispositivo cliente A 2610 transmite uma solicitação de atualização de sessão de comunicação online para o serviço de convite 620. A atualização de sessão de comunicação online é enviada para notificar que o dispositivo cliente B2 2620, que não foi parte da sessão de comunicação online, sobre o término da sessão de comunicação online. A solicitação de atualização de sessão de comunicação online pode incluir B identificador de sessão de comunicação online do usuário B e pode instruir ou indicar para o serviço de convite 620 qual dispositivo cliente associado ao usuário B (por exemplo, o dispositivo cliente B2 2620) deve receber a atualização.

[00158] O serviço de convite 620 executa uma operação de pesquisa de diretório 2914 com base no identificador de ponto final de sessão de comunicação online do usuário B para determinar o token de prosseguimento do dispositivo cliente B2 2620. Após determinar o token de prosseguimento, o serviço de convite transmite uma solicitação de push na operação 2916 para o serviço de notificação de push 640 para enviar por push a mensagem de atualização para o dispositivo cliente B2 2620. Na operação 2720, o serviço de notificação de push 640 transmite uma mensagem de atualização de sessão de comunicação online, na forma de a mensagem de notificação de push, para o dispositivo cliente B2 2620. A mensagem de atualização de sessão de comunicação online indica que a sessão de comunicação online entre o dispositivo cliente A 2910 e o dispositivo cliente B1 2615 terminou.

[00159] A figura 30 é um diagrama de fluxo que ilustra operações exemplificativas executadas para transferir uma sessão de comunicação online de um dispositivo cliente para um outro dispositivo cliente de acordo com uma modalidade. No exemplo ilustrado na figura 30, considera-se que cada um dos dispositivos clientes B1 2615 e B2 2620 recebeu um convite para uma sessão de comunicação online originado pelo dispositivo cliente A 2610 (cada um compartilha o identificador de ponto final de sessão de comunicação online que foi usado no convite) e o dispositivo cliente B1 2615 aceitou e estabeleceu uma sessão de comunicação online com o dispositivo cliente A 2610 (conforme descrito nas figuras 26 e 27 ou 28). Além disso, o dispositivo cliente B2 2620 recebeu um atualização de convite que indica que o dispositivo cliente B1 2615 aceitou o convite. No exemplo ilustrado na figura 30, a sessão de comunicação online será transferida do dispositivo cliente B1 2615 para o dispositivo cliente B2 2620. Por exemplo, um usuário no dispositivo cliente B2 2620 indicou que deseja comandar a sessão de comunicações online entre os dispositivos clientes A 2610 e o dispositivo cliente B1 2620. Em uma modalidade, a aplicação de sessão de comunicação online 2115 exibe um estado da sessão de comunicação online entre o dispositivo cliente A 2610 e o dispositivo cliente B1 2615 que permite que um usuário no dispositivo cliente B2 2620 expeça uma solicitação de sessão de comunicação online de transferência (por exemplo, através de um clique ou pressionamento de um enlace ou botão virtual disponível na aplicação de sessão de comunicação online 2115 do dispositivo cliente B1 2615).

[00160] Na operação 3010, o dispositivo cliente B2 2620 solicita seus dados de conexão da troca de dados de conexão 610 e recebe os dados de conexão solicitados na operação 3012 (se já não conhece seus dados de conexão). O dispositivo cliente B2 2620 transmite, então, uma mensagem de solicitação de transferência na operação 3014 para o serviço de convite 620 que inclui o token de prosseguimento do dispositivo cliente A 2610 e os dados de conexão do dispositivo cliente B2 2620. A mensagem de solicitação de transferência também pode incluir os identificadores de ponto final de sessão de comunicação online de A e/ou B e/ou o token de prosseguimento para o dispositivo cliente A 2610.

[00161] O serviço de convite 620 transmite, então, uma solicitação de push para o serviço de notificação de push 640 na operação 3016 para fazer com que o serviço de notificação de push 640 transmita a mensagem de transferência, na forma de uma notificação de push, para o dispositivo cliente A 2610. O serviço de convite 620 também executada uma verificação de compatibilidade P2P direta na operação 3018 para determinar se uma conexão P2P direta entre o dispositivo cliente A 2610 e o dispositivo cliente B2 2620 é plausível. Para propósitos desse exemplo, uma conexão direta é plausível, entretanto, deve ficar entendido que uma transferência de sessão de comunicação online também pode ocorrer em uma situação de retransmissão.

[00162] Na operação 3020, o serviço de notificação de push transmite a mensagem de solicitação de transferência para o dispositivo cliente A 2610. A mensagem de solicitação de transferência pode incluir identificador de ponto final de sessão de comunicação online de B e os dados de conexão para o dispositivo cliente B2 2620. A mensagem de solicitação de transferência também indica qual dispositivo (isto é, dispositivo cliente B2 2620) que está solicitando a transferência de sessão de comunicação online (por exemplo, através de um ID de dispositivo e/ou token de prosseguimento do dispositivo cliente B2 2620). A mensagem de solicitação de transferência pode fazer com que a aplicação de sessão de comunicação online 2115 do dispositivo cliente A 2610 exiba a solicitação de transferência e pode permitir que o usuário aceite ou negue a solicitação de transferência. Considerando que a solicitação de transferência é aceita, o dispositivo cliente A 2610 estabelece uma conexão P2P direta com o dispositivo cliente B 2620 com o uso dos dados de conexão na operação trocados 3022. Deve ficar entendido que nesse ponto a sessão de comunicação online entre o dispositivo cliente A 2610 e o dispositivo cliente B1 2615 está ativa. O dispositivo cliente A 2610 transmite, então, uma atualização de sessão de comunicação online para o dispositivo cliente B1 2615 que indica que a sessão de comunicação online irá transferir para o dispositivo cliente B2 2620. Em uma modalidade, essa mensagem de atuali-zação é transmitida na sessão de comunicação online existente entre os dispositivos clientes. O dispositivo cliente A 2610 comuta, então, para a sessão de comunicação online com o dispositivo cliente B2 2620 na operação 3026 e acaba com a sessão de comunicação online com o dispositivo cliente B1 2615 na operação 3028.

[00163] Embora as modalidades tenham sido descritas em referência ao convite de um único usuário para uma sessão de comunicação online (que pode ou não estar associada a múltiplos dispositivos clientes), em algumas modalidades, múltiplos usuários podem ser convidados para uma sessão de comunicação online. A figura 31 é um diagrama de fluxo que ilustra operações exemplificativas para iniciar e estabelecer uma sessão de comunicação online com múltiplos usuários.

[00164] O dispositivo cliente 3110 solicita seus dados de conexão da troca de dados de conexão 610 na operação 3132 e os dados de conexão solicitados são retornados na operação 3134. Na operação 3136, o dispositivo cliente A 3110 transmite uma solicitação de convite para o serviço de convite 620 que inclui os dados de conexão do dispositivo cliente A 3110, um identificador de ponto final de sessão de comunicação online associado ao usuário B e um identificador de ponto final de sessão de comunicação online associado ao usuário C. Dessa forma, um usuário no dispositivo cliente A 3110 está convidando múltiplos usuários para uma sessão de comunicação online.

[00165] O serviço de convite 620 executa uma operação de pesquisa de diretório 3138 para determinar os tokens de prosseguimento associados ao identificador de ponto final de sessão de comunicação online de usuário B e identificador de ponto final de sessão de comunicação online de usuário C. Nesse exemplo e para propósitos de simplicidade, a pesquisa de diretório retorna um resultado do dispositivo cliente B 3115 que é associado ao identificador de ponto final de sessão de comunicação online de usuário B e ao dispositivo cliente C 3120 que é associado ao identificador de ponto final de sessão de comunicação online de usuário C. O serviço de convite 620 transmite, então, uma solicitação de push 3140 para o serviço de notificação de push 640 para solicitar que o serviço de notificação de push 640 transmita os convites, na forma de mensagens de push, para os dispositivos clientes B e C. O serviço de notificação de push 640 transmite, então, a so-licitação de convite para o dispositivo cliente B 3115 na operação 3142 e transmite a solicitação de convite para o dispositivo cliente C 3120 na operação 3144. Cada mensagem de solicitação de convite inclui os dados de conexão do dispositivo cliente A 3110, o identificador de ponto final de sessão de comunicação online usado pelo usuário A e o token de prosseguimento do dispositivo cliente A 3110.

[00166] Em uma modalidade, o serviço de convite 620 transmite uma mensagem de situação para o dispositivo cliente que convida pa ra indicar para qual(é) dispositivo(s) de cliente o convite foi transmitido. Dessa forma, na operação 3146, o serviço de convite 620 transmite uma atualização de situação de convite para o dispositivo cliente A 3110 que indica que uma solicitação de convite de sessão de comunicação online foi enviada para o dispositivo cliente B 3115 e o dispositivo cliente C 3120. Em uma modalidade, o dispositivo cliente B 3115 e o dispositivo cliente C 3120 irão exibir uma solicitação de convite se foram alimentados e capazes de receber a solicitação de convite.

[00167] No exemplo ilustrado na figura 31, cada um dos convites será aceito. Dessa forma, na operação 3148, o dispositivo cliente B 3115 solicita seus dados de conexão da troca de dados de conexão 610. A troca de dados de conexão 610 determina os dados de conexão do dispositivo cliente B 3115 e na operação 3150 os retorna para o dispositivo cliente B 3115. De modo similar, o dispositivo cliente C 3120 solicita seus dados de conexão da troca de dados de conexão 610 na operação 3152. A troca de dados de conexão 610 determina os dados de conexão do dispositivo cliente C 3120 e na operação 3154 os retorna para o dispositivo cliente C 3120. O dispositivo cliente B 3115 transmite, então, uma mensagem de aceitação para o serviço de convite 620 na operação 3156, e o dispositivo cliente C 3120 transmite uma mensagem de aceitação para o serviço de convite 620 na operação 3158. O serviço de convite 620 executa, então, uma verificação de compatibilidade P2P direta 3160 para determinar se uma conexão P2P direta é plausível entre o dispositivo cliente A 3110 e o dispositivo cliente B 3115, e entre o dispositivo cliente A 3110 e o dispositivo cliente C 3120. Para propósitos desse exemplo, uma conexão P2P direta é plausível entre os dispositivos clientes. Dessa forma, com o uso dos dados de conexão trocados, o dispositivo cliente A 3110 e o dispositivo cliente B 3115 estabelecem uma conexão P2P direta para a sessão de comunicação online na operação 3162 e o dispositivo cliente A 3110 e o dispositivo cliente B 3120 estabelecem uma conexão P2P direta para a sessão de comunicação online na operação 3164. Nesse exemplo, o dispositivo cliente A 3110 atua essencialmente como o hospedeiro da sessão de comunicação online. Dessa forma, os dados que são transmitidos entre o dispositivo cliente B 3115 e o dispositivo cliente C 3120 são retransmitidos pelo dispositivo cliente A 3110. Em outras modalidades, uma malha completa de conexões é estabelecida entre as partes. Em tal modalidade, uma outra conexão P2P seria estabelecida entre o dispositivo cliente B 3115 e o dispositivo cliente C 3120.

[00168] Embora as modalidades descritas na presente invenção descrevam um mecanismo para registrar dispositivos clientes para sessões de comunicação online, em algumas modalidades, o registro 140 pode implantar uma API para permitir que diferentes aplicações registrem o identificador de ponto final de sessão de comunicação online e os tokens de prosseguimento. A API implantada em uma modalidade é uma interface implantada por um componente de software (doravante na presente invenção "componente de software que implanta API") que permite que um componente de software diferente (doravante na presente invenção "componente de software que realizada chamada de API") acesse e use uma ou mais funções, métodos, procedimentos, estruturas de dados e/ou outros serviços fornecidos pelo componente de software que implanta API. Por exemplo, uma API permite que um desenvolvedor de um componente de software que realizada chamada de API (que pode ser um desenvolvedor terceirizado) para alavancar recursos especificados fornecidos por um componente de software que implanta API. Pode haver um componente de software que realizada chamada de API ou pode haver mais de um componente de software. Uma API pode ser uma interface de código fonte que uma biblioteca de sistema ou programa de computador fornece a fim de suportar chamadas para serviços de uma aplicação de software. Uma API pode ser especificada em termos de uma linguagem de programação que pode ser interpretativa ou compilada quando uma aplicação é construída, em vez de uma descrição de nível baixo explicito de como os dados são assentados na memória.

[00169] A API define a linguagem e os parâmetros que os componentes de software que solicitam API usam quando acessam e usam os recursos especificados do componente de software que implanta API. Por exemplo, um componente de software que realizada chamada de API acessa os recursos especificados do componente de software que implanta API através de uma ou mais chamadas de API (algumas vezes chamada de chamadas de função ou método) expostas pela API. O componente de software que implanta API pode retornar um valor através da API em resposta a uma chamada de API de um componente de software que realizada chamada de API. Embora a API defina a sintaxe e o resultado de uma chamada de API (por exemplo, como invocar a chamada de API e qual chamada de API faz isso), a API tipicamente não revela como a chamada de API realiza a função especificada pela chamada de API. Várias chamadas ou mensagens de função são transferidas através de uma ou mais interfaces de programação de aplicação entre o software solicitante (componente de software que realizada chamada de API) e um componente de software que implanta API. A transferência das chamadas ou mensagens de função pode incluir expedir, iniciar, invocar, chamar, receber, retornar ou responder às chamadas ou mensagens de função. Por conseguinte, um componente de software que realizada chamada de API pode transferir uma solicitação e um componente de software que implanta API pode transferir uma solicitação.

[00170] Por meio de exemplo, o componente de software que implanta API e o componente de software que realizada chamada de API pode ser um sistema operacional, uma biblioteca, uma unidade de dis- positivo, uma API, um programa de aplicação ou outro módulo de software (deve ficar entendido que o componente de software que implanta API e o componente de software que realizada chamada de API podem ser do mesmo tipo ou de tipos diferentes do módulo de software). O componente de software que realizada chamada de API pode ser um componente de software local (isto é, no mesmo sistema de processamento de dados que o componente de software que implanta API) ou um componente de software remoto (isto é, em um sistema de processamento de dados diferente do componente de software que implanta API) que se comunica com o componente de software que implanta API através da API por uma rede. Deve ficar entendido que um componente de software que implanta API também pode atuar como um componente de software que realizada chamada de API (isto é, pode realizar chamadas de API para uma API exposta por um componente de software que implanta API diferente) e um componente de software que realizada chamada de API também pode atuar como um componente de software que implanta API através da implantação de uma API que é exposta a um componente de software que realizada chamada de API diferente.

[00171] A API pode permitir que múltiplos componentes de software que realizada chamada de API gravados em diferentes linguagens de programação se comuniquem com o componente de software que implanta API (dessa forma, a API pode incluir recursos para traduzir solicitações e retornos entre o componente de software que implanta API e o componente de software que realizada chamada de API); entretanto, a API pode ser implantada em termos de uma linguagem de programação específica.

[00172] A figura 9 ilustra uma modalidade de uma arquitetura de API que inclui um componente de software que implanta API 910 (por exemplo, um sistema operacional, uma biblioteca, uma unidade de dispositivo, uma API, um programa de aplicação ou outro módulo de software) que implanta a API 920. A API 920 especifica uma ou mais funções, métodos, classes, objetos, protocolos, estruturas de dados, formatos e/ou outros recursos do componente de software que implanta API que podem ser usados pelo componente de software que realizada chamada de API 930. A API 920 pode especificar pelo menos uma convenção de chamada que especifica como uma função no componente de software que implanta API que recebe parâmetros do componente de software que realizada chamada de API e como a função retorna um resultado para o componente de software que realizada chamada de API. O componente de software que realizada chamada de API 930 (por exemplo, um sistema operacional, uma biblioteca, uma unidade de dispositivo, uma API, um programa de aplicação ou outro módulo de software), realiza chamadas de API através da API 920 para acessar e usar os recursos do componente de software que implanta API 910 que são especificados pela API 920. O componente de software que implanta API 910 pode retornar um valor através da API 920 para o componente de software que realizada chamada de API 930 em resposta a uma chamada de API.

[00173] Será apreciado que o componente de software que implanta API 910 pode incluir funções, métodos, classes, estruturas de dados, e/ou outro recursos adicionais que não são especificados através da API 920 e não são disponíveis para o componente de software que realizada chamada de API 930. Deve ficar entendido que o componente de software que realizada chamada de API 930 pode estar no mesmo sistema que o componente de software que implanta API 910 ou pode ser localizado remotamente e acessa o componente de software que implanta API 910 com o uso da API 920 por uma rede. Embora a figura 9 ilustre um único componente de software que realizada chamada de API 930 que interage com a API 920, deve ficar entendido que outros componentes de software que solicitam API, que podem ser gravados em diferentes linguagens (ou na mesma linguagem) que o componente de software que realizada chamada de API 930, podem usar a API 920.

[00174] O componente de software que implanta API 910, a API 920 e o componente de software que realizada chamada de API 930 podem ser armazenados em um meio legível por máquina, que inclui qualquer mecanismo para armazenar informações em uma forma legível por uma máquina (por exemplo, um computador ou outro sistema de processamento de dados). Por exemplo, um meio legível por máquina inclui discos magnéticos, discos óticos, memória de acesso aleatório; memória de apena leitura, dispositivos de memória rápida etc. Transição entre Chamadas Comutadas por Circuito e Chamadas de Vídeo

[00175] Em algumas modalidades, um dispositivo cliente pode transitar de um chamada comutada por circuito somente de áudio estabelecido para uma chamada de vídeo sem interrupção significativa de comunicação entre as partes. Por exemplo, uma parte de uma chamada comutada por circuito somente de áudio estabelecido seleciona para transitar para uma chamada de vídeo (que inclui quadros de vídeo e áudio), que faz com que uma mensagem de iniciação de chamada de vídeo (uma forma de uma mensagem de convite de sessão de comunicação online) seja enviada para o(s) outro(s) participante(s) da chamada. Se o(s) outro(s) participante(s) aceitar(em) o convite de chamada de vídeo, uma conexão P2P será estabelecida entre os dispositivos clientes do participante. Enquanto a conexão P2P está sendo negociada, os participantes são capazes de se comunicar através da chamada comutada por circuito de apenas áudio. Após a conexão P2P ser estabelecida e o vídeo ser comunicado entre as partes, os dispositivos clientes transitam para a chamada de vídeo. A chamada comutada por circuito de apenas áudio é, então, encerrada, e os participantes são capazes de se comunicar através da chamada de vídeo.

[00176] A figura 12 ilustra um dispositivo cliente 1210 exemplificati- vo e uma interface gráfica de usuário que é usada para transitar entre chamadas comutadas por circuito e chamadas de vídeo de acordo com algumas modalidades. O dispositivo cliente 1210 inclui o alto- falante 1255 (que é usado durante o modo de alto-falante do telefone), câmera voltada para frente 1260 (que captura vídeo usado para a chamada de vídeo), microfone 1265 (que captura som), o recep- tor/alto-falante 1270 (que é tipicamente usado quando um usuário mantém o dispositivo cliente 1210 em sua orelha durante uma chamada), e a tela de exibição 1275 (que é uma tela sensível ao toque em algumas modalidades). O dispositivo cliente 1210 também pode incluir um fone de cabeça/plugue de fone, um sensor de proximidade, um sensor de luz ambiente, acelerômetro(s) e outros componentes. Deve ficar entendido que a arquitetura do dispositivo cliente 1210 é exempli- ficativa e arquiteturas diferentes que incluem mais ou menos componentes podem ser usadas em modalidades.

[00177] Conforme ilustrado na figura 12, a interface gráfica de usuário 1205 está atualmente sendo exibida na tela de exibição 1275. O usuário do dispositivo cliente 1210 está atualmente participando em uma chamada de telefone de apenas áudio (com o número de telefone (408) 555-1234). A interface gráfica de usuário 1205 inclui diversas opções diferentes para o usuário durante a chamada. Por exemplo, o dispositivo cliente 1210 executa a seguinte responsiva para receber entrada de usuário (por exemplo, batida ou outros gestos predefinidos no ícone apropriado): finaliza a chamada quando a entrada é aplicada ao ícone de chamada finalizada 1250, exclui o som da chamada de áudio em resposta à entrada que está sendo aplicada ao ícone de mudo 1220, exibe um bloco de teclas numéricas (por exemplo, para adi- cionar números de telefone adicionais à chamada) em resposta à entrada que é aplicada ao ícone de bloco de teclas 1225, coloca a chamada em alto-falante do telefone em resposta à entrada que é aplicada ao ícone de alto-falante 1230 (que muda a saída de áudio para o alto-falante 1255), adiciona uma chamada em resposta à entrada que é aplicada para o ícone de adição de chamada 1235, coloca a chamada em espera em resposta à entrada que é aplicada ao ícone de espera 1240, exibe a lista de contato do usuário em resposta à entrada que é aplicada ao ícone de contatos 1245 e transita para uma chamada de vídeo em resposta à entrada que é aplicada ao ícone de chamada de vídeo 1215.

[00178] As figuras 17 a 18 são diagramas de fluxo que ilustram operações exemplificativas para transitar entre uma chamada comutada por circuito de apenas áudio e uma chamada de vídeo de acordo com uma modalidade. As figuras 17 a 18 serão descritas em referência às modalidades exemplificativas das figuras 12, 13 e 14. Entretanto, deve ficar entendido que as operações das figuras 17 a 18 podem ser executadas por modalidades da invenção além das discutidas em referência às figuras 12, 13 e 14, e as modalidades discutidas em referência às figuras 12, 13 e 14 podem executar operações diferentes daquelas discutidas em referência às figuras 17 a 18.

[00179] Conforme ilustrado na figura 17, os dispositivos clientes 1210 e 1410 são conectados através de uma chamada comutada por circuito de apenas áudio 1710 (o usuário do dispositivo cliente 1210 ou o usuário do dispositivo cliente 1410 iniciou a chamada). Dessa forma, os usuários do dispositivo cliente 1210 e 1410 podem se comunicar pela chamada de áudio comutada por circuito estabelecida. No bloco 1712, o dispositivo cliente 1210 recebe entrada para transitar para uma chamada de vídeo. Por exemplo, o usuário selecionou para transitar para uma chamada de vídeo através da batida ou execução de um outro gesto definido no ícone de chamada de vídeo 1215.

[00180] O fluxo se move, então, para o bloco 1714, em que o dispositivo cliente 1210 faz com que uma mensagem de convite de chamada de vídeo (que é uma forma de uma mensagem de solicitação de convite de sessão de comunicação online) seja enviada para o dispositivo cliente 1410 (conforme identificado pelo número de telefone do dispositivo cliente 1410). Em algumas modalidades, a mensagem de solicitação de convite de sessão de comunicação online é enviada com o uso da arquitetura descrita nas figuras 6 e 7. O fluxo se move, então, para o bloco 1716.

[00181] No bloco 1716, o dispositivo cliente 1210 determina se o áudio está presentemente sendo roteado através do alto-falante do telefone (por exemplo, o alto-falante 1255) ou através do fone de ca- beça/plugue de fone. Se sim, então, o fluxo se move para o bloco 1720. Se não, então, o fluxo se move para o bloco 1718 em que o dispositivo cliente 1210 roteia o áudio através do alto-falante do telefone do dispositivo cliente 1210 (por exemplo, o alto-falante 1255) e o fluxo se move para o bloco 1720.

[00182] No bloco 1720, o dispositivo cliente 1210 exibe uma pré- visualização de vídeo do que a câmera voltada para frente 1260 está atualmente capturando para permitir que o usuário do dispositivo cliente 1210 se prepare para a chamada de vídeo (por exemplo, para posicionar apropriadamente o dispositivo cliente 1210 para a chamada de vídeo). A figura 13 ilustra o dispositivo cliente 1210 que exibe a pré- visualização de vídeo 1310 que exibe vídeo do que a câmera voltada para frente 1260 está atualmente capturando. Embora não ilustrado na figura 13, em algumas modalidades, um botão de cancelamento também é exibido na GUI 1305 que permite que o usuário cancele o convite de chamada de vídeo. O fluxo se move do bloco 1720 para o bloco 1722.

[00183] No bloco 1726, o dispositivo cliente 1410 recebe uma mensagem de convite de chamada de vídeo que convida o usuário do dispositivo cliente 1410 para uma chamada de vídeo. O fluxo se move do bloco 1726 para o bloco 1728. Em algumas modalidades, o dispositivo cliente 1410 tem uma arquitetura que é similar ao dispositivo cliente 1210. Por exemplo, conforme ilustrado na figura 14, o dispositivo cliente 1410 inclui o alto-falante 1455 (que é usado durante o modo de alto- falante do telefone), a câmera voltada para frente 1460 (que captura o vídeo usado para a chamada de vídeo), o microfone 1465 (que captura som), o receptor/alto-falante 1470 (que é tipicamente usado quando um usuário mantém o dispositivo cliente 1210 na orelha durante uma chamada), e a tela de exibição 1475 (que é uma tela sensível ao toque em algumas modalidades). O dispositivo cliente 1410 também pode incluir um fone de cabeça/plugue de fone, um sensor de proximidade, um sensor de luz ambiente, acelerômetro(s), e outros componentes. Deve ficar entendido que a arquitetura do dispositivo cliente 1410 é exemplificativa e diferentes arquiteturas que incluem mais ou menos componentes podem ser usadas nas modalidades.

[00184] No bloco 1728, o dispositivo cliente 1410 reproduz um ou mais tons de áudio que indicam o recebimento da mensagem para alertar o usuário sobre a mensagem. Os tons de áudio podem ser diferentes em diferentes modalidades (por exemplo, os tons de áudio podem ser similares aos tons de chamada em espera usados no dispositivo cliente 1410 (embora não sejam originados pelo portador associado ao dispositivo cliente 1410), os tons de áudio podem ser exclusivos e específicos para chamadas de vídeo etc.). Em algumas modalidades, o dispositivo cliente 1410 não reproduz tons de áudio que indicam o recebimento da mensagem de convite de chamada de vídeo se o dispositivo cliente 1410 não estiver próximo à orelha do usuário (por exemplo, conforme indicado por um sensor de proximidade do disposi- tivo cliente 1410) e/ou se a chamada estiver atualmente no modo de alto-falante do telefone. O fluxo se move do bloco 1728 para o bloco 1730.

[00185] No bloco 1730, o dispositivo cliente 1410 exibe a mensagem de convite de chamada de vídeo e opcionalmente exibe uma pré- visualização de vídeo do que a câmera voltada para frente 1460 está atualmente capturando para permitir que o usuário do dispositivo cliente 1410 se prepare para a chamada de vídeo, e o fluxo se move para o bloco 1732. A figura 14 ilustra a GUI 1405 que exibe o convite de chamada de vídeo 1440. Conforme ilustrado na figura 14, o convite de chamada de vídeo 1440 inclui um botão de aceitação 1432, um botão de negação 1434 e a pré-visualização de vídeo 1430 (que mostra o que a câmera voltada para frente 1460 está atualmente capturando). Embora a figura 1410 ilustre o convite de chamada de vídeo 1440 que inclui a pré-visualização de vídeo 1430 (ou seja, a pré-visualização de vídeo 1430 é contida dentro do convite de chamada de vídeo 1440), em outras modalidades, a pré-visualização de vídeo 1430 é localizada externamente e/ou está sobrepondo o convite de chamada de vídeo 1440. O usuário do dispositivo cliente 1410 pode selecionar o botão de aceitação 1432 para aceitar o convite de chamada de vídeo (por exemplo, através da batida ou execução de um outro gesto predefinido para entrada no botão de aceitação 1432) e pode selecionar o botão de negação 1434 para negar o convite de chamada de vídeo (por exemplo, através da batida ou execução de um outro gesto predefinido para entrada no botão de negação 1434).

[00186] No bloco 1732, o dispositivo cliente 1410 determina se a entrada foi recebida para aceitar a chamada de vídeo (por exemplo, se o usuário aceitou o convite de chamada de vídeo através da seleção do botão de aceitação 1432). Se o dispositivo cliente 1410 receber a entrada para aceitar a chamada de vídeo, então, o fluxo se move para o bloco 1734, de outro modo, o fluxo se move para o bloco 1736. No bloco 1734, o dispositivo cliente 1410 faz com que uma mensagem de aceitação de chamada de vídeo seja transmitida para o dispositivo cliente 1210. Em algumas modalidades, a mensagem de aceitação é transmitida para o dispositivo cliente 1210 com o uso da arquitetura descrita nas figuras 6 e 7. O fluxo se move, então, para o bloco 1810.

[00187] No bloco 1736, é determinado se a entrada foi recebida para rejeitar a solicitação de chamada de vídeo (por exemplo, se o usuário rejeitou o convite de chamada de vídeo através da seleção do botão de negação 1434). Se o dispositivo cliente 1410 receber a entrada para negar o convite de chamada de vídeo, então, o fluxo se move para o bloco 1738, de outro modo, o fluxo se move de volta para o bloco 1732. No bloco 1738, o dispositivo cliente 1410 faz com que uma mensagem de negação de chamada de vídeo seja transmitida para o dispositivo cliente 1210. O dispositivo cliente 1410 também pode limpar o convite de chamada de vídeo 1440 e parar a exibição da pré- visualização de vídeo 1430. Em algumas modalidades, a mensagem de negação de chamada de vídeo é transmitida para o dispositivo cliente 1210 com o uso da arquitetura descrito nas figuras 6 e 7.

[00188] No bloco 1722, o dispositivo cliente 1210 determina se recebeu uma mensagem de aceitação de chamada de vídeo do dispositivo cliente 1410. Se sim, então, o fluxo se move para o bloco 1816, de outro modo, o fluxo se move para o bloco 1724 em que o dispositivo cliente 1210 determina se recebeu uma mensagem de negação de chamada de vídeo do dispositivo cliente 1410. Se sim, então, o fluxo se move para o bloco 1910, de outro modo, o fluxo se move de volta para o bloco 1722.

[00189] Em referência à figura 18, no bloco 1810 (o usuário no dispositivo cliente 1410 aceitou o convite de chamada de vídeo), o dispositivo cliente 1410 determina se o áudio está presentemente sendo ro- teado através do alto-falante do telefone (por exemplo, o alto-falante 1470) ou o fone de cabeça do dispositivo cliente 1410. Se não, então, o fluxo se move para o bloco 1812 em que a rota de áudio é alterada do alto-falante 1455 para o alto-falante do telefone (por exemplo, o alto-falante 1470), e o fluxo se move para o bloco 1814. Se o áudio já estiver sendo roteado através do alto-falante do telefone ou um fone de cabeça, então, o fluxo se move para o bloco 1814.

[00190] No bloco 1814, o dispositivo cliente 1410 exibe uma pré- visualização de vídeo do que a câmera voltada para frente 1460 está atualmente capturando. A operação no bloco 1814 é executada somente se a pré-visualização de vídeo não estiver sendo atualmente exibida como um resultado da operação no bloco 1730. O fluxo se move do bloco 1814 para o bloco 1820.

[00191] Nos blocos 1818 e 1820, os dispositivos clientes 1210 e 1410 estabelecem uma conexão P2P um com o outro. A conexão P2P pode ser estabelecida através de mecanismos conhecidos (por exemplo, com o uso de Estabelecimento de Conectividade de Internet (ICE) ou outros mecanismos de conectividade P2P conhecidos). Considerando que a conexão P2P é estabelecida com sucesso, o fluxo se move dos blocos 1818 e 1820 para os blocos 1822 e 1824 respectivamente, em que os dispositivos clientes 1210 e 1410 que estão transmitindo vídeo um para o outro pela conexão P2P (o vídeo das câmeras de vídeo voltadas para frente 1260 e 1460). Em algumas modalidades, o vídeo inclui tanto quadros de vídeo quanto áudio correspondente (capturado pelos microfones 1265 e 1465 dos dispositivos clientes 1210 e 1410 respectivamente), embora em outras modalidades, o vídeo e o áudio sejam fluxos separados comunicados ao longo da conexão P2P.

[00192] O fluxo se move do blocos 1822 e 1824 para os blocos 1826 e 1828 respectivamente. Nos blocos 1826 e 1828, os dispositivos clientes 1210 e 1410 respectivamente determinam se receberam um ou mais quadros de vídeo de seu ponto. Se sim, então, o fluxo se move dos blocos 1826 e 1828 para os blocos 1830 e 1832 respectivamente. Se não, então, o fluxo permanece nos blocos 1826 e 1828 até que um ou mais quadros de vídeo sejam recebidos.

[00193] Em algumas modalidades, os dispositivos clientes 1210 e 1410 esperam para receber quadros de vídeo um do outro por uma certa quantidade de tempo e se não trocam quadros de vídeo ao longo desse tempo, a ação alternativa é tomada. Por exemplo, em algumas modalidades, a chamada de vídeo é cancelada e uma mensagem é exibida nas telas dos dispositivos clientes 1210 e 1410 de que a chamada de vídeo não poderia ser estabelecida. A chamada de vídeo pode falhar no estabelecimento por inúmeras razões incluindo o fato de a largura de banda ser insuficiente para a chamada de vídeo, os quadros de vídeo terem falhado na transmissão ou serem recebidos etc. Embora em algumas modalidades, os dispositivos clientes esperam por um único quadro de vídeo antes de prosseguir, em outras modalidades, os dispositivos clientes esperam para recebe inúmeros quadros por um determinado período de tempo (por exemplo, um fluxo de quadros de vídeo) antes de prosseguir.

[00194] Nos blocos 1830 e 1832, os dispositivos clientes 1210 e 1410 respectivamente transitam para a chamada de vídeo. A transição para a chamada de vídeo inclui exibir o vídeo que está sendo recebido e mudar a rota de áudio da chamada de áudio comutada por circuito para a chamada de vídeo. Em algumas modalidades, a pré- visualização de vídeo (por exemplo, a pré-visualização de vídeo 1310) se move para um canto da tela (e encolhe em tamanho) e o vídeo que está sendo recebido do ponto é descrito. Dessa forma, deve ficar entendido que até que a rota de áudio tenha sido mudada da chamada de áudio comutada por circuito para chamada de vídeo, os participan- tes podem se comunicar através da chamada de áudio comutada por circuito (ou seja, a chamada de áudio comutada por circuito permanece estabelecida enquanto a chamada de vídeo está sendo negociada). Após a transição para a chamada de vídeo, a chamada de áudio comutada por circuito pode ser encerrada. Dessa forma, o fluxo se move dos blocos 1830 e 1832 para os blocos 1834 e 1836 respectivamente em que a chamada de áudio comutada por circuito é encerrada.

[00195] As figuras 15 e 16 ilustram os dispositivos clientes 1210 e 1410 respectivamente após terem sido transitados para a chamada de vídeo. Conforme ilustrado na figura 15, o dispositivo cliente 1210 exibe o vídeo 1510, que é vídeo do que está sendo capturado pela câmera voltada para frente 1460 do dispositivo cliente 1410. O dispositivo cliente 1210 também exibe o vídeo 1515, que é o vídeo do que está sendo capturado pela câmera voltada para frente 1260. A GUI 1505 também inclui botão de fim de vídeo 1520 e o botão de fim de chamada e vídeo 1625. O botão de fim de vídeo 1520 permite que o usuário finalize a chamada de vídeo e retorne para uma chamada de apenas áudio. O botão de fim de chamada e vídeo 1525 permite que o usuário finalize a chamada de vídeo completamente (por exemplo, para finalizar a conversação com o usuário no dispositivo cliente 1410). Conforme ilustrado na figura 16, o dispositivo cliente 1410 exibe o vídeo 1610, que é o vídeo do que está sendo capturado pela câmera voltada para frente 1260 do dispositivo cliente 1210. O dispositivo cliente 1410 também exibe o vídeo 1615, que é o vídeo do que está sendo capturado pela câmera voltada para frente 1460. A GUI 1605 também inclui o botão de fim de vídeo 1620 e o botão de fim de vídeo e chamada 1625.

[00196] A figura 19 é um fluxograma que ilustra operações exempli- ficadoras realizadas em um dispositivo cliente que recebeu uma mensagem de rejeição de chamada de vídeo de acordo com uma modali- dade. No bloco 1910, o dispositivo cliente 1210 recebe uma mensagem de rejeição de chamada de vídeo (o usuário no dispositivo cliente 1410 rejeitou o convite de chamada de vídeo). O fluxo se move do bloco 1910 para o bloco 1912 e o dispositivo cliente 1210 exibe uma mensagem de chamada de vídeo rejeitada e, opcionalmente, reproduz um ou mais tons de áudio que indicam o recebimento da mensagem de rejeição de chamada de vídeo. O fluxo se move, então, para o bloco 1914 onde o dispositivo cliente 1210 interrompe a exibição de sua própria pré-visualização de vídeo. O dispositivo cliente 1210 também pode solicitar que o usuário retorne para a saída de áudio original (por exemplo, através do alto-falante 1270) se a saída de áudio foi previamente alterada para o viva-voz no bloco 1718.

[00197] A figura 20 é um fluxograma que ilustra operações exempli- ficadoras realizadas em um dispositivo cliente para fazer a transição de uma chamada de vídeo para uma chamada comutada por circuito de acordo com uma modalidade. Uma chamada de vídeo 2010 é estabelecida entre os dispositivos clientes 1210 e 1410 (a chamada de vídeo pode ser estabelecida de acordo com mecanismos descritos em referência às figuras 17 e 18 ou pode ser estabelecida sem fazer a transição de uma chamada de áudio comutada por circuito). No bloco 1712, o dispositivo cliente 1210 recebe entrada para fazer a transição para uma chamada comutada por circuito apenas de áudio. Por exemplo, com referência à figura 15, o usuário do dispositivo cliente 1210 selecionou o botão de finalização de vídeo 1520 (por exemplo, ao apertar ou realizar outro gesto predefinido no botão de finalização de vídeo 1520). O dispositivo cliente 1210 transmite, então, uma mensagem para o dispositivo cliente 1410 que indica uma transição para uma chamada comutada por circuito apenas de áudio 2014.

[00198] O dispositivo cliente 1210 inicia, então, uma solicitação de chamada de áudio comutada por circuito para o dispositivo cliente 1410 (por exemplo, o dispositivo cliente 1210 chama automaticamente o número do dispositivo cliente 1410). Em algumas modalidades, isso é realizado no plano de fundo e não exige interação de usuário. A chamada é roteada através de inúmeros elementos de rede da infraes- trutura de rede de transporte (por exemplo, estações base, centros de comutação móveis etc.).

[00199] O dispositivo cliente 1410 recebe e responde a chamada comutada por circuito 2020. Em uma modalidade, o dispositivo cliente 1410 exibe uma solicitação de chamada de entrada e pode reproduzir tons de áudio que indicam a solicitação de chamada de entrada (por exemplo, tons de espera de chamada ou outros tons), e exige a intervenção de usuário para responder a chamada. Em outra modalidade, o dispositivo cliente 1410 automaticamente responde à chamada sem intervenção de usuário (e pode, ou não, reproduzir tons de áudio que indicam a solicitação de chamada de entrada). Após a chamada ser respondida, a chamada comutada por circuito apenas de áudio é estabelecida 2030 entre os dispositivos clientes 1210 e 1410.

[00200] Após a chamada comutada por circuito apenas de áudio ser estabelecida com sucesso, os dispositivos clientes 1210 e 1410 farão a transição para a chamada apenas de áudio 2032 e 2034, respectivamente. Por exemplo, fazer a transição para a chamada apenas de áudio inclui mudar a rota de áudio da chamada de vídeo para a chamada comutada por circuito, interromper a exibição do vídeo que é recebido, e interromper a transmissão do vídeo. O dispositivo cliente também pode interromper a exibição da pré-visualização de vídeo. Desse modo, deve ser compreendido que, enquanto a chamada apenas de áudio comutada por circuito esteja sendo negociada, os usuários nos dispositivos clientes 1210 e 1410 podem ser comunicar através da chamada de vídeo (ou seja, a chamada de vídeo permanece estabelecida enquanto a chamada comutada por circuito apenas de áudio é negociada). Após fazer a transição com sucesso para a chamada comutada por circuito apenas de áudio, os dispositivos clientes 1210 e 1410 finalizam a conexão P2P 2040. Os usuários nos dispositivos clientes 1210 e 1410 podem, então, se comunicar através da chamada comutada por circuito apenas de áudio.

[00201] Embora as modalidades da invenção tenham sido descritas em relação a uma chamada de vídeo que tem dois participantes, as modalidades não se limitam a isso e pode haver mais participantes na chamada de vídeo. Em tais modalidades, o dispositivo cliente pode exibir múltiplos fluxos de vídeo de cada participante diferente na conversa de vídeo.

[00202] Embora as modalidades da invenção tenham sido descritas em relação a uma chamada de vídeo que tem dois participantes onde cada participante transmite vídeo, as modalidades não se limitam a isso. Por exemplo, em algumas modalidades, apenas uma única parte pode estar transmitindo vídeo para o(s) outro(s) participante(s) e aque- le(s) outro(s) participante(s) pode(m) estar transmitindo apenas áudio. Em algumas modalidades, cada participante pode determinar quando suspender a transmissão de vídeo em qualquer ponto durante a chamada de vídeo.

[00203] Em algumas modalidades, a qualidade do vídeo transmitido durante a chamada é dinamicamente ajustada com base em condições de rede. Por exemplo, durante períodos quando a rede está congestionada, a taxa de bit do vídeo pode ser diminuída. De modo similar, durante períodos quando a rede está relativamente livre de congestionamento, a taxa de bit do vídeo pode ser aumentada. Em algumas modalidades, se as condições de rede evitam que o vídeo seja transmitido, os dispositivos clientes participante automaticamente fazem a transição para uma chamada comutada por circuito apenas de áudio. Desse modo, se a largura de banda cai abaixo de um determi- nado nível, os dispositivos clientes participante podem automaticamente fazer a transição para uma chamada comutada por circuito apenas de áudio (ou podem solicitar que o usuário retorne para uma chamada comutada por circuito apenas de áudio). Suporte de Serviços de Mãos Livres através de um Dispositivo de Mãos Livres para chamadas de vídeo de IP

[00204] Em uma modalidade, os dispositivos clientes incluem funcionalidade para suportar interação com um dispositivo de mãos livres (por exemplo, um fone, um kit para o carro) ao longo de uma WPAN (Rede de Área Pessoal Sem Fio) (por exemplo, Bluetooth, ZigBee etc.) incluindo suporte para gerenciar chamadas de vídeo de IP com a unidade de mãos livres. A figura 32 é um diagrama de bloco que ilustra um dispositivo cliente que faz interface com uma unidade de mãos livres para gerenciar chamadas de vídeo de IP de acordo com uma modalidade. O dispositivo cliente 3210 inclui a capacidade de iniciar chamadas de vídeo (por exemplo, convidar um ou mais recipientes para uma sessão de comunicação online que é uma chamada de vídeo) e a capacidade de aceitar chamadas de vídeo. Em algumas modalidades, o dispositivo cliente 3210 também inclui componentes de telefonia celular para fazer e receber chamadas de telefone celular e/ou acessar a Internet ou outra rede através de uma conexão de celular.

[00205] Conforme apresentado na figura 32, o dispositivo cliente 3210 inclui o gerenciador de chamada de vídeo de IP 3250, o gerenciador de telefonia 3260, o gerenciador de áudio 3275 e o gerenciador de mãos livres 3270. Em algumas modalidades, o dispositivo cliente 3210 também inclui o gerenciador de chamada de celular 3255. O gerenciador de chamada de vídeo de IP 3250 gerencia uma aplicação de chamada de vídeo de P2P incluindo estabelecimento de uma chamada de vídeo de P2P de IP ao longo da rede de IP 3235 através do serviço de chamada de vídeo de IP 3230 conforme anteriormente descrito no presente documento. Em uma modalidade, o serviço de chamada de vídeo de IP 3230 inclui um ou mais dentre o serviço de convite 620, o serviço de notificação push 640, o serviço de registro 630 e/ou o serviço de registro 2130, e o serviço de retransmissão 650. O gerenciador de chamada de celular 3255 gerencia os componentes de celular para fazer e receber chamadas de telefone celular apenas de áudio ao longo de uma rede de celular 3245 com o uso do serviço de chamada de áudio de celular 3240.

[00206] O gerenciador de chamada de vídeo de IP 3250 e o gerenciador de chamada de celular 3255 estão acoplados ao gerenciador de telefonia 3260. O gerenciador de telefonia 3260 gerencia as operações de telefonia para o gerenciador de chamada de vídeo de IP 3250 e o gerenciador de chamada de celular 3255 incluindo rastreamento do histórico de chamadas (para chamadas de vídeo e chamadas de celular apenas de áudio) e outras informações relacionadas às chamadas. O gerenciador de telefonia 3260 também faz interface com o gerenciador de mãos livres 3270 para fornecer serviços de mãos livres através de um dispositivo de mãos livres externo para chamadas de vídeo de IP e chamadas de celular em nome do gerenciador de chamada de vídeo de IP 3250 e do gerenciador de chamada de celular 3255. Em uma modalidade, um formato de mensagem comum é usado entre o gerenciador de chamada de vídeo de IP 3250, o gerenciador de chamada de celular 3255 e o gerenciador de telefonia 3260, a fim de for-necer suporte para os serviços de mãos livres para protocolo e tipos de chamadas diferentes (chamada de vídeo de IP e chamada de celular apenas de áudio). Desse modo, o gerenciador de telefonia 3260 fornece suporte similar para serviços de mãos livres sem considerar se os serviços de mãos livres servem para uma chamada de vídeo de IP ou uma chamada de celular apenas de áudio. Isso evita a necessidade de o gerenciador de mãos livres 3270 compreender se os serviços de mãos livres servem para uma chamada de vídeo de IP ou para uma chamada de celular apenas de áudio de tal modo que comandos padrão que são compreensíveis pelos dispositivos de mãos livres possam ser usados para fornecer serviços de mãos livres para chamadas de vídeo de IP bem como para chamadas de celular apenas de áudio.

[00207] Em uma modalidade, o gerenciador de telefonia 3260 também arbitra entre o gerenciador de chamada de vídeo de IP 3250 e o gerenciador de chamada de celular 3255. Por exemplo, o gerenciador de telefonia 3260 pode fazer com que uma chamada de vídeo de IP seja colocada em espera para comutar para uma chamada de celular apenas de áudio estabelecida e/ou fazer com que uma chamada de celular apenas de áudio seja colocada em espera para comutar para uma chamada de vídeo de IP.

[00208] O gerenciador de mãos livres 3270 fornece suporte para processamento de mãos livres. Em uma modalidade, o gerenciador de mãos livres 3270 implementa uma pilha de protocolo Bluetooth para conexão por Bluetooth a dispositivos de mãos livres compatíveis tais como um fone de Bluetooth fone e kit de carro de Bluetooth. Em uma modalidade específica, o gerenciador de mãos livres 3270 implanta um perfil de fone de Bluetooth (por exemplo, conforme definido no relatório descritivo de Headset Profile (HSP) 1.2 de 18 de dezembro de 2008) e/ou um perfil de mãos livres de Bluetooth (por exemplo, conforme definido no relatório descritivo de Hands-Free Profile 1.5 (HFP 1.5) de 25 de novembro de 2005). O gerenciador de mãos livres 3270 permite que unidade de mãos livres 3220 atue como uma retransmissão auditiva para uma chamada de vídeo de IP e para uma chamada de celular apenas de áudio ao longo de uma WPAN 3225, bem como realize outros serviços de mãos livres. Por exemplo, no caso de uma chamada de vídeo de IP, a porção de áudio da chamada pode ser roteada através da unidade de mãos livres 3220 ao invés de um alto-falante do dispositivo cliente 3210 enquanto a porção de vídeo da chamada permanece sendo exibida pelo dispositivo cliente 3210 (ou por um visor anexado). A unidade de mãos livres 3220 também inclui um microfone para capturar informações de áudio que são, então, transmitidas para o dispositivo de computação cliente 3210. Desse modo, um usuário pode usar a unidade de mãos livres 3220 para falar e/ou ouvir um áudio durante uma chamada de vídeo de IP e/ou durante uma chamada de celular apenas de áudio.

[00209] O gerenciador de mãos livres 3270 também suporta outros serviços de mãos livres que respondem ao recebimento de entrada da unidade de mãos livres 3220 incluindo a realização de uma ou mais do que segue para chamadas de vídeo de IP e/ou chamadas de celular apenas de áudio: permitir que um usuário responda uma chamada; finalizar uma chamada; colocar uma chamada e; silenciar uma chamada; aumentar/diminuir o volume de uma chamada; transferir o áudio para o dispositivo cliente; transferir o áudio para a unidade de mãos livres; estabelecer uma chamada; e rediscar a última chamada. Desse modo, um usuário pode usar a unidade de mãos livres 3220 para responder a uma chamada de vídeo de IP, finalizar uma chamada de vídeo de IP, estabelecer uma chamada de vídeo de IP em espera e/ou silenciada, aumentar/diminuir o volume de uma chamada de vídeo de IP, transferir o áudio da chamada de vídeo de IP a ser emitido para um alto-falante do dispositivo cliente 3210, transferir o áudio do dispositivo cliente 3210 para a unidade de mãos livres 3220, estabelecer uma chamada de vídeo de IP, e rediscar a última chamada de vídeo de IP.

[00210] O gerenciador de chamada de vídeo de IP 3250, o gerenciador de chamada de celular 3255 e o gerenciador de mãos livres 3270 também estão acoplados ao gerenciador de áudio 3275. O gerenciador de áudio 3275 roteia o áudio das chamadas de vídeo de IP e das chamadas de celular apenas de áudio através de diferentes fontes. Por exemplo, o gerenciador de áudio 3275 pode fazer com que o áudio seja emitido através de um alto-falante do dispositivo cliente 3210 adequado para modo em viva-voz, através de um alto-falante do dispositivo cliente 3210 usado quando um usuário prender o dispositivo cliente 3210 a sua orelha durante uma chamada, através de um fo- ne/tomada de fone de ouvido para um fone ou fone de ouvido que está plugado ao dispositivo cliente 3210, e através de uma unidade de mãos livres nivelada (como a unidade de mãos livres 3220).

[00211] A figura 33 ilustra o dispositivo cliente 3210 que recebe um convite para uma chamada de vídeo, fazendo com que o dispositivo de mãos livres toque, recebendo uma indicação de resposta do dispositivo de mãos livres, que estabelece a chamada de vídeo, e que roteia o áudio para o dispositivo de mãos livres de acordo com uma modalidade. A figura 33 será descrita com referência à modalidade exemplifica- dora da figura 32. No entanto, deve ser compreendido que as operações da figura 33 podem ser realizadas através de modalidades que não aquelas discutidas com referência à figura 32, e as modalidades discutidas com referência à figura 32 podem realizar operações diferentes daquelas discutidas com referência à figura 33.

[00212] Na operação 3310, o gerenciador de chamada de vídeo de IP 3250 recebe um convite de chamada de vídeo de IP de outro dispositivo cliente que convida o usuário do dispositivo cliente 3210 a participar de uma chamada de vídeo de IP. O convite de chamada de vídeo de IP pode ter a forma do convite conforme anteriormente descrito no presente documento. O gerenciador de chamada de vídeo de IP 3250 processa a solicitação de convite incluindo fazer com que o convite seja exibido na operação 3315. Por exemplo, a solicitação de convite pode ser exibida de uma forma similar como o convite de chamada de vídeo exemplificador 1410 ilustrado na figura 14.

[00213] Além disso, o gerenciador de chamada de vídeo de IP 3250 gera e transmite um objeto de chamada 3320 para o gerenciador de telefonia 3260. O objeto de chamada 3320 inclui um conjunto de parâmetros relacionado à chamada. Por exemplo, os parâmetros de objeto de chamada incluem uma ou mais situações da chamada (por exemplo, conexão), e um identificador de participante de chamada (por exemplo, o número de telefone, endereço eletrônico, ou outro identificador de ponto final online de sessão de comunicação), um tempo de inicialização, uma indicação se é uma chamada realizada ou recebida, e um identificador de chamada usado internamente a fim de identificar a chamada.

[00214] Em uma modalidade, o objeto de chamada 3320 é um objeto de chamada genérico que, embora os parâmetros sejam usados nas informações do convite de chamada de vídeo de IP, está em um formato que é comum para solicitações de convite de chamada de vídeo de IP e chamadas de celular apenas de áudio recebidas. Desse modo, ao receber uma chamada de celular apenas de áudio recebida, o gerenciador de chamada de celular 3255 gera um objeto de chamada recebida do mesmo formato. Desse modo, a partir da perspectiva do gerenciador de telefonia 3260, uma solicitação de convite de chamada de vídeo de IP ou uma chamada de celular apenas de áudio recebida parecem ser iguais.

[00215] O gerenciador de telefonia 3260 armazena as informações no objeto de chamada 3320 como parte de uma estrutura de histórico de chamadas. O gerenciador de telefonia 3260 também gera e envia uma mensagem de chamada recebida 3322 para o gerenciador de mãos livres 3270. Em uma modalidade, o gerenciador de telefonia 3260 apenas envia a mensagem de chamada recebida 3322 se houver um dispositivo de mãos livres como o dispositivo de mãos livres 3220 igual ao dispositivo cliente 3210 (por exemplo, o gerenciador de telefonia 3260 verifica, em primeiro lugar, se há um dispositivo de mãos li vres que está avaliado ao dispositivo cliente 3210). Em outras modalidades, o gerenciador de telefonia 3260 envia a mensagem de chamada recebida 33220 para o gerenciador de mãos livres 3270 independente se há um dispositivo de mãos livres avaliado e o gerenciador de mãos livres 3270 determina se deve deixar/ignorar a mensagem ou processá-la dependendo se há um dispositivo de mãos livres avaliado. Para os propósitos da figura 33 e figuras subsequentes, presume-se que o dispositivo de mãos livres 3220 está avaliado ao dispositivo de computação cliente 3210. Em uma modalidade, a mensagem de chamada recebida 3322 inclui o identificador de chamada.

[00216] Em resposta à recepção da mensagem de chamada recebida 3320, o gerenciador de mãos livres 3270 faz com que uma série de mensagens seja transmitida para o dispositivo de mãos livres 3220 o alertando e o usuário que há uma mensagem recebida. Conforme apresentado na figura 33, o gerenciador de mãos livres estabelece uma conexão de áudio 3325 (por exemplo, um enlace Orientado de Conexão Síncrona (SCO)) com o dispositivo de mãos livres 3220 antes de enviar uma mensagem de toque 3330 ao longo da conexão de áudio estabelecida 3325. Essa mensagem de toque é selecionada pelo dispositivo cliente 3210 e pode ser passível de personalização pelo usuário do dispositivo cliente 3210. Em uma modalidade, a mensagem de toque para chamadas de vídeo de IP é diferente do toque para chamadas de celular apenas de áudio. Em outra modalidade, uma conexão de áudio não é estabelecida até após a chamada ser atendida. Em tal modalidade, uma mensagem de alerta de toque é enviada para o dispositivo de mãos livres 3220 que, então, determina localmente a reprodução de um toque para alertar o usuário da mensagem recebida (a mensagem de alerta de toque pode também ser enviada antes de enviar a mensagem de toque 3330). Em tal modalidade, a mensagem de alerta de toque pode ser enviada múltiplas vezes para o dispositivo de mãos livres 3220 até que a chamada seja atendida ou finalizada.

[00217] Algum tempo após receber a mensagem de alerta de toque e/ou a mensagem de toque 3330, o dispositivo de mãos livres 3220 transmite a mensagem atendida 3335 que indica que um usuário atendeu a chamada. Por exemplo, o usuário pressionou um botão de atendimento em seu dispositivo de mãos livres 3220 ou, de outra forma, acionou o dispositivo de mãos livres 3220 para atender a chamada. O gerenciador de mãos livres 3270 recebe a mensagem atendida 3335 e transmite uma mensagem atendida 3340 para o gerenciador de telefonia 3260. Em uma modalidade, a mensagem atendida 3340 inclui o identificador de chamada. Embora não ilustrado na figura 33, o gerenciador de mãos livres 3270 pode também transmitir uma mensagem de reconhecimento para o dispositivo de mãos livres 3220 em resposta ao recebimento da mensagem atendida 3335.

[00218] O gerenciador de telefonia 3260 determina que a mensagem de chamada atendida 3340 pertence à chamada indicada no objeto de chamada 3320 (por exemplo, ao comparar o identificador de chamada incluído na mensagem 3340 às informações armazenadas do objeto de chamada 3320) e transmite uma mensagem 3345 para o gerenciador de chamada de vídeo de IP 3250 que indica que a chamada foi atendida. Em resposta à recepção dessa mensagem, o gerenciador de chamada de vídeo de IP 3250 estabelece uma chamada de vídeo de IP em uma operação 3350. Por exemplo, o gerenciador de chamada de vídeo de IP 3250 faz com que uma mensagem de aceitação de chamada de vídeo de IP seja enviada para um serviço de convite conforme anteriormente descrito no presente documento e uma conexão P2P seja estabelecida (de forma direta ou através de uma retransmissão) com o dispositivo de computação que transmitiu o convite.

[00219] Algum tempo após a chamada de vídeo de IP ter sido esta- belecida, o gerenciador de chamada de vídeo de IP 3250 transmite um objeto de chamada 3355 para o gerenciador de telefonia 3260. O objeto de chamada 3355 inclui um conjunto similar de parâmetros ao objeto de chamada 3320 com a exceção que a situação mudou de conectando para conectado. Em uma modalidade, o objeto de chamada 3355 é um objeto de chamada genérico que está em um formato que é comum para as chamadas de vídeo de IP estabelecidas e chamadas de celular apenas de áudio conectadas.

[00220] Além disso, às vezes após a chamada de vídeo de IP ter sido estabelecida, o gerenciador de áudio 3275 roteia a porção de áudio da chamada de vídeo de IP estabelecida através do dispositivo de mãos livres 3220. Em uma modalidade, o gerenciador de chamada de vídeo de IP 3250 ou o gerenciador de telefonia 3260 solicita que o gerenciador de áudio 3275 roteie o áudio através do dispositivo de mãos livres. O gerenciador de áudio 3275 pode também transmitir uma mensagem 3360 para o gerenciador de mãos livres 3270 que indica que a rota de áudio será mudada para atravessar o dispositivo de mãos livres 3220. Se uma conexão de áudio ainda não estiver estabelecida, o gerenciador de mãos livres 3270 estabelecerá uma conexão de áudio com o dispositivo de mãos livres 3220. Presumindo que haja uma conexão de áudio estabelecida, a porção de áudio 3365 da chamada de vídeo é roteada para o dispositivo de mãos livres 3220. Desse modo, a porção de áudio da chamada de vídeo é gerenciada através do dispositivo de mãos livres 3220 enquanto a porção de vídeo da chamada de vídeo é exibida no dispositivo cliente 3210.

[00221] A figura 34 ilustra o dispositivo cliente 3210 que inicia uma chamada de vídeo e roteia o áudio para a chamada de vídeo estabelecida através de um dispositivo de mãos livres de acordo com uma modalidade. A figura 34 será descrita com referência à modalidade exemplificadora da figura 32. No entanto, deve ser compreendido que as operações da figura 34 podem ser realizadas por modalidades que não aquelas discutidas com referência à figura 32, e as modalidades discutidas com referência à figura 32 podem realizar operações diferentes daquelas discutidas com referência à figura 34.

[00222] Na operação 3410, o gerenciador de chamada de vídeo de IP 3250 faz com que uma ou mais mensagens de convite de chamada de vídeo de IP sejam enviadas para o(s) outro(s) dispositivo(s) clien- te(s) para convidar o(s) usuário(s) para uma chamada de vídeo de IP. A(s) mensagem(s) de convite de chamada de vídeo de IP pode(m) assumir a forma do convite conforme anteriormente descrito no presente documento. O gerenciador de chamada de vídeo de IP 3250 gera e transmite um objeto de chamada 3415 para o gerenciador de telefonia 3260. Similar ao objeto de chamada 3320, o objeto de chamada 3415 inclui um conjunto de parâmetros em relação à chamada e está em um formato genérico. O gerenciador de telefonia 3260 armazena as informações no objeto de chamada 3415 como parte de uma estrutura de histórico de chamadas.

[00223] Em uma modalidade, o gerenciador de telefonia 3260 também gera e envia uma mensagem de chamada realizada 3420 para o gerenciador de mãos livres 3270 que indica que há uma chamada realizada. Em resposta a essa mensagem, o gerenciador de mãos livres 3270 estabelece uma conexão de áudio 3425 com o dispositivo de mãos livres 3220 (se um toque na faixa personalizado deve ser enviado) e transmite, então, uma mensagem de toque 3430 para o dispositivo de mãos livres 3220. Em outra modalidade, o gerenciador de mãos livres 3270 transmite apenas uma mensagem de alerta de toque para o dispositivo de mãos livres 3220 ao invés de estabelecer uma conexão de áudio e transmitir um toque em banda.

[00224] Algum tempo após enviar o convite de chamada de vídeo de IP, o gerenciador de chamada de vídeo de IP 3250 recebe uma mensagem de aceitação de chamada de vídeo de IP 3435, que pode tomar a forma de uma mensagem de aceitação de chamada de vídeo conforme anteriormente descrito no presente documento. Após receber essa mensagem, uma chamada de vídeo de IP de P2P é estabelecida com o dispositivo cliente na operação de aceitação 3440 (por exemplo, uma conexão P2P (de modo direto ou através de uma retransmissão) é estabelecida com o dispositivo de computação que aceitou o convite).

[00225] Algum tempo após a chamada de vídeo de IP ter sido estabelecida, o gerenciador de chamada de vídeo de IP 3250 transmite um objeto de chamada 3445 para o gerenciador de telefonia 3260. O objeto de chamada 3445 inclui um conjunto similar de parâmetros como o objeto de chamada 3415 com a exceção que a situação mudou de conectando para conectado. O objeto de chamada 3445 está também em um formato genérico. Além disso, às vezes após a chamada de vídeo de IP ter sido estabelecida, o gerenciador de áudio 3275 roteia a porção de áudio da chamada de vídeo de IP estabelecida através do dispositivo de mãos livres 3220. Em uma modalidade, o gerenciador de chamada de vídeo de IP 3250 ou o gerenciador de telefonia 3260 solicita que o gerenciador de áudio 3275 roteie o áudio através do dispositivo de mãos livres. O gerenciador de áudio 3275 pode também transmitir uma mensagem 3455 para o gerenciador de mãos livres 3270 que indica que a rota de áudio será mudada para atravessar o dispositivo de mãos livres 3220. Se uma conexão de áudio não estiver sido estabelecida, o gerenciador de mãos livres 3270 estabelecerá uma conexão de áudio com o dispositivo de mãos livres 3220. Ao presumir que há uma conexão de áudio estabelecida, a porção de áudio 3460 da chamada de vídeo é roteada para o dispositivo de mãos livres 3220. Desse modo, a porção de áudio da chamada de vídeo é gerenciada através do dispositivo de mãos livres 3220 enquanto a porção de vídeo da chamada de vídeo é exibida no dispositivo cliente 3210.

[00226] A figura 35 ilustra o dispositivo cliente 3210 que inicia uma chamada de vídeo em resposta à recepção de uma solicitação de chamada do dispositivo de mãos livres 3220 de acordo com uma modalidade. A figura 35 será descrita com referência à modalidade exemplificadora da figura 32. No entanto, deve ser compreendido que as operações da figura 35 podem ser realizadas por modalidades que não aquelas discutidas com referência à figura 32, e as modalidades discutidas com referência à figura 32 podem realizar operações diferentes daquelas discutidas com referência à figura 35.

[00227] O gerenciador de mãos livres 3270 recebe uma solicitação de chamada 3510 do dispositivo de mãos livres 3220. A solicitação de chamada 3510 pode ser gerada em resposta a um usuário que seleciona um número de telefone ou outro identificador de ponto final online de sessão de comunicação a ser chamado. Por exemplo, o usuário pode selecionar um botão para rediscar no dispositivo de mãos livres 3220 que solicita que a última chamada seja rediscada. O gerenciador de mãos livres 3270 transmite uma mensagem de solicitação de chamada 3520 para o gerenciador de telefonia 3260. O gerenciador de telefonia 3260 determina se a mensagem de solicitação de chamada 3520 está solicitando uma chamada para um identificador que está associado a uma chamada de vídeo (e, deste modo, a mensagem de solicitação de chamada deveria ser enviada para o gerenciador de chamada de vídeo de IP 3250) ou associada a um número de telefone para uma chamada de celular apenas de áudio (e, desse modo, deveria ser enviada para o gerenciador de chamada de celular 3255). Por exemplo, no caso em que a solicitação de chamada 3520 é uma solicitação de rediscagem, o gerenciador de telefonia 3260 acessa a última chamada discada, que pode ser uma chamada de vídeo de IP ou uma chamada de celular apenas de áudio, para determinar onde enviar a solicitação de chamada. Conforme apresentado na figura 35, o gerenciador de telefonia envia a mensagem de solicitação de chamada 3525 para o gerenciador de chamada de vídeo de IP 3250. A mensagem de solicitação de chamada 3525 inclui o identificador do participante solicitado para a chamada de vídeo (por exemplo, um número de telefone, um endereço eletrônico, ou outro identificador de ponto final online de sessão de comunicação). Em resposta ao recebimento da mensagem de solicitação de chamada 3525, o gerenciador de chamada de vídeo de IP 3250 faz com que uma mensagem de convite de chamada de vídeo de IP seja enviada para o participante indicado na operação 3410 conforme descrito na figura 34. As operações remanescentes apresentadas na figura 35 são realizadas conforme descrito em referência à figura 34. Desse modo, o dispositivo cliente 3210 suporta o estabelecimento de uma chamada de vídeo de IP como um resultado de ação de usuário em um dispositivo de mãos livres em par.

[00228] A figura 36 ilustra o dispositivo cliente 3210 que roteia um áudio de uma chamada de vídeo estabelecida para o dispositivo de mãos livres 3220 de acordo com uma modalidade. Há uma chamada de vídeo de IP estabelecida 3610 entre o dispositivo cliente 3210 e um ou mais outros dispositivos clientes. A porção de áudio dessa chamada é atualmente emitida por um alto-falante do dispositivo cliente 3210 ou através de fones que estão plugados no dispositivo cliente 3210. Na operação 3615, o gerenciador de chamada de vídeo de IP 3250 recebe entrada para transferir o áudio para o dispositivo de mãos livres 3220. Por exemplo, um usuário do dispositivo cliente 3210 forneceu entrada para a aplicação de chamada de vídeo de IP para transferir o áudio para um dispositivo de mãos livres em par. Em resposta ao recebimento de tal entrada, o gerenciador de chamada de vídeo de IP 3250 envia uma solicitação de rota de áudio 3620 para o gerenciador de áudio 3275 para rotear a porção de áudio da chamada de vídeo através do dispositivo de mãos livres 3220. O gerenciador de áudio 3275 pode transmitir uma mensagem 3625 para o gerenciador de mãos livres 3270 que indica que a rota de áudio será mudada para atravessar o dispositivo de mãos livres 3220. Se uma conexão de áudio ainda não estiver estabelecida, o gerenciador de mãos livres 3270 estabelecerá uma conexão de áudio 3630 com o dispositivo de mãos livres 3220. Ao presumir que há uma conexão de áudio estabelecida, a porção de áudio 3635 da chamada de vídeo é roteada para o dispositivo de mãos livres 3220. Desse modo, após uma chamada de vídeo de IP ser estabelecida, o dispositivo cliente 3210 permite que o usuário transferira o áudio para um dispositivo de mãos livres.

[00229] Embora a figura 36 ilustre a transferência de um áudio para um dispositivo de mãos livres em resposta ao recebimento de uma entrada direta no dispositivo cliente, em outras modalidades, o usuário pode fazer com que o áudio seja transferido para o dispositivo de mãos livres 3220 através de uma entrada no dispositivo de mãos livres 3220. Em tais modalidades, o gerenciador de mãos livres 3270 recebe um comando do dispositivo de mãos livres 3220 para transferir o áudio. O gerenciador de mãos livres 3270 envia, então, a solicitação para o gerenciador de áudio 3275 que, então, roteia novamente o áudio.

[00230] Além disso, embora a figura 36 ilustre a transferência de áudio para um dispositivo de mãos livres, em algumas modalidades, o áudio pode também ser transferido do dispositivo de mãos livres para um alto-falante (ou fones) do dispositivo cliente 3210. Isso pode ser iniciado no dispositivo cliente 3210 e/ou no dispositivo de mãos livres 3220. Em tais modalidades, o gerenciador de áudio 3275 recebe a solicitação de áudio de rota (ou do gerenciador de chamada de vídeo de IP 3250 ou do gerenciador de mãos livres 3270) para rotear o áudio para o dispositivo cliente 3210 e atua em conformidade.

[00231] A figura 37 ilustra o dispositivo cliente 3210 que finaliza uma chamada de vídeo em resposta ao recebimento de uma solicitação de finalização de chamada do dispositivo de mãos livres 3220 de acordo com uma modalidade. O gerenciador de mãos livres 3270 recebe uma mensagem de finalização de chamada 3710 do dispositivo de mãos livres 3220 em resposta a um usuário que seleciona finalizar uma chamada (por exemplo, um botão de finalização foi selecionado no dispositivo de mãos livres 3220) no dispositivo de mãos livres 3220. O gerenciador de mãos livres 3270 transmite a solicitação de finalização de chamada 3715 para o gerenciador de telefonia 3260. Em uma modalidade, a solicitação de finalização de chamada 3715 inclui um identificador de chamada para indicar qual chamada finalizar (caso haja diversas chamadas). O gerenciador de telefonia 3260 determina que a chamada a ser finalizada está associada ao gerenciador de chamada de vídeo de IP 3250 e envia a mensagem de finalização de chamada 3720 para o gerenciador de chamada de vídeo de IP 3250. Em resposta ao recebimento da mensagem de finalização de chamada 3720, o gerenciador de chamada de vídeo de IP 3250 faz com que a chamada de vídeo de IP seja finalizada e faz com que o dispositivo cliente 3210 se desconecte da conexão P2P. Desse modo, o dispositivo cliente 3210 suporta permitir que o usuário finalize uma chamada de vídeo de IP com o uso de um dispositivo de mãos livres em par.

[00232] A figura 38 é um diagrama de bloco que ilustra um sistema de computador exemplificador que pode ser usado em algumas modalidades. Por exemplo, a arquitetura exemplificadora do sistema de computador 3800 pode ser incluída nos dispositivos clientes 110, 1210, 1410, 2110, 2610, 3210 etc. ou outros dispositivos de computação descritos no presente documento. Deve ser compreendido que, embora a figura 38 ilustre vários componentes de um sistema de computador, não se limita a representar qualquer arquitetura ou maneira particular de interconexão dos componentes já que tais detalhes não são pertinentes à presente invenção. Será observado que outros sistemas de computador que têm poucos componentes ou mais componentes também podem ser usados.

[00233] Conforme ilustrado na figura 38, o sistema de computador 3800, que está sob a forma de um sistema de processamento de dados, inclui o(s) barramento(s) 3850 que está acoplado ao sistema de processamento 3820, ao abastecimento de potência 3825, à memória 3830 e à memória não volátil 3840 (por exemplo, um disco rígido, memória flash, Memória de Mudança de Fase (PCM) etc.). O(s) barra- mento(s) 3850 pode(m) ser conectados um ao outro através de várias pontes, controladores, e/ou adaptadores como é bem conhecido na técnica. O sistema de processamento 3820 pode recuperar instru- ção(s) da memória 30 e/ou da memória não volátil 3840, e executar as instruções para realizar operações conforme descrito acima. O barra- mento 3850 interconecta os componentes acima juntamente e também interconecta esses componentes à plataforma opcional 3860, o controlador de exibição & dispositivo de exibição 3870, dispositivos de En- trada/Saída 3880 (por exemplo, NIC (Cartão de Interface de Rede), um controle de cursor (por exemplo, mouse, tela sensível ao toque, mesa sensível ao toque etc.), um teclado etc.), e o(s) transceptor(s) sem fio opcional(s) 3890 (por exemplo, Bluetooth, WiFi, Infravermelho etc.).

[00234] A figura 39 é um diagrama de bloco que ilustra um sistema de processamento de dados exemplificador que pode ser usado em algumas modalidades. Por exemplo, o sistema de processamento de dados 3900 pode ser um computador portátil, um assistente digital pessoal (PDA), um telefone móvel, um sistema de jogo portátil, um reprodutor de mídia portátil, um tablet ou um dispositivo de computação portátil que pode incluir um telefone móvel, um reprodutor de mídia, e/ou um sistema de jogo. Como outro exemplo, o sistema de processamento de dados 3900 pode ser um computador de rede ou um dis- positivo de processamento embutido em outro dispositivo.

[00235] De acordo com uma modalidade, a arquitetura exemplifica- dora do sistema de processamento de dados 3900 pode ser incluída nos dispositivos clientes 110, 1210, 1410, 2110, 2610, 3210 etc. ou outros dispositivos de computação descritos no presente documento. O sistema de processamento de dados 3900 inclui o sistema de processamento 3920, que pode incluir um ou mais microprocessadores e/ou um sistema em um circuito integrado. O sistema de processamento 3920 está acoplado a uma memória 3910, um abastecimento de potência 3925 (que inclui uma ou mais baterias), uma entrada/saída de áudio 3940, um dispositivo de exibição e controlador de exibição 3960, entrada/saída opcional 3950, dispositivo(s) de entrada 3970, e transceptor(es) sem fio 3930. Será observado que componentes adici-onais, não mostrados na figura 39, também podem ser parte do sistema de processamento de dados 3900 em certas modalidades, e, em certas modalidades, um número menor de componentes que mostrado na figura 39 pode ser usado. Além disso, será observado que um ou mais barramentos, não mostrado na figura 39, podem ser usados para interconectar os vários componentes como é bem conhecido na técnica.

[00236] A memória 3910 pode armazenar dados e/ou programas para execução pelo sistema de processamento de dados 3900. A en- trada/saída de áudio 3940 pode incluir um microfone e/ou um alto- falante, por exemplo, para reproduzir música e/ou fornecer funcionalidade de telefonia através do alto-falante e microfone. O dispositivo de exibição e controlador de exibição 3960 pode incluir uma interface de usuário gráfica (GUI). Os transceptores sem fio (por exemplo, RF) 3930 (por exemplo, um transceptor WiFi, um transceptor infravermelho, um transceptor Bluetooth, um transceptor de telefonia celular sem fio etc.) podem ser usados para se comunicar com outros sistemas de processamento de dados. O um ou mais dispositivos de entrada 3970 permitem que um usuário forneça entrada para o sistema. Esses dispositivos de entrada podem ser um teclado numérico, teclado, painel sensível ao toque, painel sensível a múltiplos toques etc. A outra en- trada/saída opcional adicional 3950 pode ser um conector para uma doca.

[00237] As técnicas mostradas nas figuras podem ser implantadas com o uso de códigos e dados armazenados e executados em um ou mais dispositivos de computação (por exemplo, dispositivos clientes, servidores etc.). Tais dispositivos de computação armazenam e transmitem (internamente e/ou com outros dispositivos de computação ao longo de uma rede) códigos (compostos de instruções de software) e dados com o uso de meio legível por máquina, como meio legível por máquina tangível não transitório (por exemplo, meio de armazenamento legível por máquina como discos magnéticos; discos óticos; memória apenas de leitura; dispositivos de memória flash) e sinais de propagação transitória (por exemplo, sinais elétricos, óticos, acústicos ou outra forma de sinais propagados - como ondas portadoras, sinais infravermelhos, sinais digitais etc.). Além disso, tais dispositivos de computação incluem tipicamente um conjunto de um ou mais processadores acoplado a um ou mais outros componentes, como um ou mais meio legível por máquina tangível não transitório (para armazenar códigos e/ou dados), dispositivos de entrada/saída de usuário (por exemplo, um teclado, uma tela sensível ao toque, e/ou um visor), e conexões de rede (para transmitir códigos e/ou dados com o uso de sinais de propagação transitória). O acoplamento do conjunto de processadores e outros componentes se dá tipicamente através de um ou mais barramentos e pontes (também denominado controladores de barramento). Desse modo, um meio legível por máquina não transitório de um dado dispositivo de computação armazena tipicamente ins- truções para execução em um conjunto de um ou mais processadores daquele dispositivo de computação. Uma ou mais partes de uma modalidade podem ser implantadas com o uso de diferentes combinações de software, firmware e/ou hardware.

[00238] Embora as operações tenham sido descritas no presente documento com referência à validação automática de um endereço eletrônico sem exigir que um usuário clique em um enlace incluído em uma mensagem de endereço eletrônico de validação em relação à validação de um endereço eletrônico pra uso como um identificador de ponto final online de sessão de comunicação, as modalidades não são limitadas. Por exemplo, em algumas modalidades, as operações descritas com referência à validação automática de um endereço eletrônico são realizadas quando um endereço eletrônico precisa ser validado por outras razões. Por exemplo, um usuário pode estar registrando um serviço que exige que um endereço eletrônico seja validado como pertencendo àquele usuário como uma parte do processo de registro. O usuário fornece o endereço eletrônico para o serviço e recebe uma mensagem (por exemplo, através da exibição de uma página da web do serviço) que indica que o endereço eletrônico precisa ser validado e que uma mensagem de endereço eletrônico de validação foi enviada ou será enviada para o endereço eletrônico que foi fornecido (a mensagem de endereço eletrônico de validação pode ou pode não incluir um enlace de validação). Uma aplicação no dispositivo cliente pode verificar automaticamente uma conta de endereço eletrônico que corresponde ao endereço eletrônico para a mensagem de validação e quando é localizado, avalia automaticamente a mensagem para localizar o sinal de validação e transmitir uma mensagem de validação de endereço eletrônico que inclui o endereço eletrônico e o sinal de validação para um servidor de validação de endereço eletrônico associado ao serviço para validar o endereço eletrônico. Embora os fluxogra- mas nas figuras mostrem uma ordem particular de operações realizadas por certas modalidades, deve ser compreendido que tal ordem é exemplificadora (por exemplo, modalidades alternativas podem realizar as operações em uma ordem diferente, combinar certas operações, sobrepor certas operações etc.).

[00239] Embora a invenção tenha sido descrita em termos de diversas modalidades, aquele versado na técnica reconhecerá que a invenção não se limita às modalidades descritas, e pode ser praticada com modificações e alterações no espírito e escopo das concretizações. A descrição deve, desse modo, ser considerada ilustrativa ao invés de limitadora.

Claims

1. Método para registrar um dispositivo de computação cliente para sessões de comunicação online caracterizado pelo fato de que compreende as etapas de: receber uma mensagem, que tem um token de prosseguimento que é exclusivo para o dispositivo de computação cliente e um número de telefone daquele dispositivo de computação cliente, a partir de um dispositivo de trânsito de SMS (serviço de mensagem curta) que recebeu uma mensagem de SMS que tem o token de prosseguimento (push token) do dispositivo de computação cliente e que determinou o número de telefone do dispositivo de computação cliente; gerar uma assinatura com base em um ou mais do token de prosseguimento e do número de telefone; transmitir uma mensagem incluindo a assinatura, o token de prosseguimento e o número de telefone para o dispositivo de trânsito de SMS para entrega ao dispositivo de computação cliente; receber uma mensagem tendo a assinatura, o token de prosseguimento e o número de telefone a partir do dispositivo de com-putação cliente; validar o token de prosseguimento e o número de telefone recebidos a partir do dispositivo de computação cliente; associar o token de prosseguimento e o número de telefone; e armazenar a associação.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a mensagem do dispositivo de trânsito de SMS foi transmitida em resposta à energização do dispositivo de computação cliente e à transmissão automática da mensagem de SMS que tem o token de prosseguimento do dispositivo de computação cliente.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o token de prosseguimento identifica exclusivamente o dispositivo de computação cliente e contém informações que permitem que um serviço de notificação de prosseguimento localize e transmita mensagens de notificação de prosseguimento para o dispositivo de computação cliente.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente fornecer a associação entre o token de prosseguimento e o número de telefone para um serviço de convite de sessão de comunicação online a ser usado ao transmitir convites de sessão de comunicação online para o dispositivo de computação cliente.

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o dispositivo de trânsito de SMS é uma porta de comunicação de SMS ou um agregador de SMS.

6. Servidor de registro para registrar dispositivos de computação clientes para sessões de comunicação online caracterizado pelo fato de que compreende: uma interface de trânsito de SMS (serviço de mensagem curta) para receber mensagens de solicitação de registro de um dispositivo de trânsito de SMS que recebe mensagens de SMS de dispositivos de computação clientes, sendo que cada mensagem de solicitação de registro que inclui um token de prosseguimento que é exclusivo para um dispositivo de computação cliente e um número de telefone daquele dispositivo de computação determinado pelo dispositivo de trânsito de SMS; e um módulo de associação para associar tokens de prosse-guimento e números de telefone e armazenar os tokens de prosseguimento e números de telefone associados em um armazenamento de dados de registro de sessão de comunicação online; um módulo de geração de assinatura para gerar uma assi- natura para cada par de token de prosseguimento e número de telefone recebidos do dispositivo de trânsito de SMS; e em que a interface de trânsito de SMS para transmitir mensagens de resposta de registro para o dispositivo de trânsito de SMS, cada mensagem de resposta de registro incluindo uma assinatura, um token de prosseguimento e número de telefone para um dispositivo de computação cliente; uma interface de dispositivo cliente para receber mensagens de solicitação de validação de registro a partir de dispositivos clientes, cada mensagem de solicitação de validação de registro incluindo uma assinatura, token prosseguimento e número de telefone de um dispositivo de computação cliente; e um módulo de validação para validar tokens de prosseguimento e números de telefone para dispositivos de computação do cliente antes de armazená-los no armazenamento de dados de registro de sessão de comunicação online.

7. Servidor de registro de acordo com a reivindicação 6, ca-racterizado pelo fato de que um token de prosseguimento identifica exclusivamente um dispositivo de computação cliente e contém informações que permitem que um serviço de notificação de prosseguimento localize e transmita mensagens de notificação de prosseguimento para aquele dispositivo de computação cliente.

8. Servidor de registro, de acordo com a reivindicação 6, caracterizado pelo fato de que o dispositivo de trânsito de SMS é uma porta de comunicação de SMS ou um agregador de SMS.

9. Meio de armazenamento legível por máquina não transitório caracterizado pelo fato de que fornece instruções que, quando executadas por um processador, farão com que o dito processador realize um método para registrar um dispositivo de computação cliente para sessões de comunicação online, conforme definido em qualquer uma das reivindicações 1 a 5.

10. Sistema de registro de sessão de comunicação online caracterizado pelo fato de que compreende: um dispositivo de trânsito de SMS (serviço de mensagem curta) que recebe mensagens de SMS de dispositivos de computação clientes que têm tokens de prosseguimento dos dispositivos de computação clientes e determina números de telefone dos dispositivos de computação clientes a partir das mensagens de SMS, em que o dispositivo de trânsito de SMS transmite, ainda, pares de token de prosseguimento e número de telefone para um servidor de registro; e o servidor de registro associa pares de token de prosseguimento e número de telefone e armazena os tokens de prosseguimento e números de telefone associados em um armazenamento de dados de registro de sessão de comunicação online e o registro gera ainda uma assinatura para cada par de token de prosseguimento e número de telefone recebidos a partir do dispositivo de trânsito de SMS e transmite mensagens para o dispositivo de trânsito de SMS tendo uma assinatura, token de prosseguimento e número de telefone para um dispositivo de computação cliente.

11. Sistema, de acordo com a reivindicação 10, caracterizado pelo fato de que cada token de prosseguimento identifica exclusivamente um dispositivo de computação cliente e contém informações que permitem que um serviço de notificação de prosseguimento localize e transmita mensagens de notificação de prosseguimento para aquele dispositivo de computação cliente.

12. Sistema, de acordo com a reivindicação 10, caracterizado pelo fato de que o dispositivo de trânsito de SMS transmite adicionalmente mensagens de SMS para os dispositivos de computação clientes, sendo que cada mensagem tem uma assinatura gerada pelo servidor de registro e um número de telefone para aquele dispositivo de computação cliente.

13. Sistema, de acordo com a reivindicação 12, caracterizado pelo fato de que o servidor de registro recebe adicionalmente mensagens de dispositivos de computação clientes, sendo que cada mensagem inclui uma assinatura, um número de telefone e um token de prosseguimento; e em que o servidor de registro valida adicionalmente os pares de tokens de prosseguimento e número de telefone recebidos dos dispositivos de computação clientes com base na assinatura recebida do dispositivo de computação cliente e na assinatura gerada no servidor de registro.