BR112012025358A2

BR112012025358A2 - estabelecimento de sessões de comunicação online entre dispositivos de computação cliente

Info

Publication number: BR112012025358A2
Application number: BR112012025358-1A
Authority: BR
Inventors: Justin Santamaria; Justin Wood; Berkat S. Tung; Joe Abuan; Patrick Gates; Jeremy Werner; Andrew H. Vyrros
Original assignee: Apple Inc.
Priority date: 2010-04-07
Filing date: 2010-09-23
Publication date: 2021-08-17
Also published as: US20130231146A1; EP2556639B1; AU2010350744B2; BR112012025379A2; GB2495814B; TWI551112B; JP2013524683A; DE112010005457B4; WO2011126506A1; GB2495814A; MX2012011624A; US8948797B2; CN102893572B; KR101436225B1; CN102893572A; AU2010350744A1; US20110250909A1; ES2469852T3; US20110249079A1; GB201217440D0

Abstract

ESTABELECIMENTO DE SESSÕES DE COMUNICAÇÃO ONLINE ENTRE DISPOSITIVOS DE COMPUTAÇÃO CLIENTE. A presente invenção refere-se a um método e um aparelho para auxiliar no estabelecimento de uma sessão de comunicação online entre dispositivos de computação cliente. Uma mensagem de solicitação de convite de sessão de comunicação online é recebida a partir de um dispositivo de computação cliente de iniciação, a mensagem inclui dados de conexão do dispositivo de computação de iniciação e um identificador de ponto de extremidade de sessão de comunicação online para um destinatário predeterminado. Um conjunto de um ou mais push tokens que são associados ao identificador é determinado, onde cada um dos push tokens identifica um dispositivo de computação cliente. Uma mensagem de convite de sessão de comunicação online que inclui os dados de conexão do dispositivo de computação cliente de iniciação é transmitida para um conjunto de dispositivos de computação cliente de destinatário pretendido que corresponde ao conjunto de push tokens. Uma mensagem de convite de aceitação é recebida a partir de pelo menos um entre o conjunto de dispositivos de computação cliente de destinatário pretendido que inclui dados de conexão daquele dispositivo de computação. Uma mensagem de convite de aceitação é transmitida para o dispositivo de computação de iniciação que inclui os dados de conexão de cada dispositivo de computação de aceitação para permitir que o dispositivo de computação de iniciação e cada dispositivo de computação de aceitação estabeleçam uma sessão de comunicação online ponto a ponto direta.

Description

Relatório Descritivo da Patente de Invenção para "ESTABELE- CIMENTO DE SESSÕES DE COMUNICAÇÃO ONLINE ENTRE DISPOSI- TIVOS DE COMPUTAÇÃO CLIENTE". Referência Cruzada a Pedidos Relacionados Este pedido reivindica prioridade ao pedido de patente U.S. nú- mero 12/886.485, depositado em 20 de setembro de 2010 e, também, rei- vindica o benefício ao pedido de patente provisório U.S. número 61/382.479, depositado em 13 de setembro de 2010, pedidos provisórios U.S. números 61/378.924 e 61/378.926, depositados em 31 de gosto de 2010, pedido de patente provisório U.S. número 61/351.814, depositado em 4 de junho de 2010 e pedidos provisórios U.S. números 61/321.865 e 61/321.866, deposi- tados dia 7 de abril de 2010, que são incorporados no presente documento a título de referência. " Este pedido pode incluir o assunto em questão relacionado ao Y 15 pedidode patente provisório U.S. copendente, cedido à mesma requerente " número 61/321.832, depositado em 7 de abril de 2010, e intitulado: Appara- tus and Method For Inviting Users to Online Sessions, que é incorporado a título de referência no presente documento. A invenção a ser descrita e reivindicada neste pedido foi apre- sentada prematuramente e sem a autorização da Apple ao público quando um protótipo do iPhone 4 da Apple foi aparentemente roubado de um enge- nheiro da Apple em 25 de março de 2010. O pedido de prioridade U.S., no qual este pedido se baseia, não foi depositado antes do aparente roubo. Antecedentes Campo As modalidades da invenção referem-se ao campo de rede de computador e; mais especificamente, estabelecem sessões de comunicação online entre dispositivos de computação cliente. Antecedentes Muitas implementações que proporcionam sessões de comuni- cação online (por exemplo, mensagens instantâneas, videoconferência etc.) requerem que os usuários de dispositivos de computação instalem um soft-

NEED ware e/ou se registrem no serviço.

Deste modo, como um pré-requisito para um usuário estabelecer uma sessão de comunicação online com outro usuá- rio, ambos os usuários devem ser registrados e/ou terem o mesmo software instalado.

Muitas implementações também mantêm a presença (por exem- plo, uma listade amigos) que permite que os usuários determinem o estado de outros usuários (por exemplo, online, offline, away (em outro lugar) etc.). Redes públicas grândes, tais como, a Internet, frequentemente têm conexões para redes privadas menores, tais como aquelas mantidas por uma corporação, provedor de serviço de Internet, ou mesmo aparelhos do- —mésticos individuais.

Pela sua própria natureza, as redes públicas devem ter uma alocação comumente acordada de endereços de rede, isto é, endere- ços públicos.

Por uma variedade de razões, os mantenedores de redes pri- vadas muitas vezes escolhem usar endereços de rede privada para as redes ” privadas que não fazem parte da alocação comumente acordada.

Deste mo- T 15 do,paraque o tráfego de rede a partir da rede privada seja capaz de atra- - vessar a rede pública, alguma forma de tradução de endereço de rede priva- da/pública ("NAT") é requerida.

Um dispositivo que realiza operações NAT altera os pacotes de dados que estão sendo enviados para fora da rede privada para cumprir com o esquema de endereçamento da rede pública.

Particularmente, o tradutor de endereço de rede substitui o endereço privado de origem e o número de portas de um pacote com seu próprio endereço público e um número de por- tas.

Um tradutor de endereço de rede também altera os pacotes de dados que são recebidos para os computadores na rede privada para substituir o endereço público e o número de portas de destino pelo endereço privado e o número de portas correto do destinatário pretendido.

Conforme usado no presente documento, o termo endereço deve ser construído incluído tanto um endereço como um número de portas, se apropriado no contexto, con- forme pode ser entendido por alguém de conhecimento comum na técnica.

A NAT vem se tornando crescentemente comum na computação de rede moderna.

Uma vantagem da NAT consiste no fato de que esta reduz a depleção de espaço de endereço de rede pública.

Por exemplo, o endere- Ummpmpmmm—m——

çamento TCP/IP, que é usado na Internet, compreende quatro cadeias de três dígitos cada que proporciona, deste modo, um espaço de endereço fini- to. De maneira adicional, determinadas porções deste espaço de endereço são reservadas para uso ou usuários particulares que esgotam adicional- menteo número real de endereços disponíveis. Entretanto, se NAT for usa- da, uma rede privada ou sub-rede pode usar um número arbitrário de ende- reços e, ainda apresentar apenas um único endereço público padronizado para o mundo externo. Isto torna o número de endereços disponíveis prati- camente ilimitado, porque cada rede privada pode, teoricamente, usar exa- tamente os mesmos endereços privados.

Uma vantagem proporcionada pela NAT é segurança aumenta- da que surge do fato de que aquela na rede pública não pode determinar o endereço de rede real (isto é, privado) de um computador em uma rede pri- " vada. Isto ocorre porque apenas o endereço público é proporcionado na re- * 15 de pública pelo tradutor de endereço de rede. De maneira adicional, este r endereço público pode corresponder a qualquer número de computadores na rede privada. . Diferentes tipos de NAT empregam diferentes níveis de segu- rança. Por exemplo, com uma "NAT de cone completo", uma vez que um endereço interno (iAddr:iPort) é mapeado em um endereço externo (eAd- dr:ePort), qualquer host externo pode enviar pacotes para iAddr:iPort ao en- viar os pacotes para eAddr:ePort. Com uma "NAT de cone restrito", um host p externo com um endereço hAddr pode enviar pacotes para iAddr:iPort ao enviar os pacotes para eAddr:ePort apenas se iAddr:iPort tiver enviado pre- viamente um pacote para hAddr. A porta do host externo é irrelevante. Com uma "NAT de Cone de Porta Restrita", um host externo que tem um endere- ço/porta haAddr:hPort pode enviar pacotes para iAddr:iPort ao enviar os paco- tes para eAddr:ePort apenas se iAddr:iPort tiver enviado previamente um pacote para hAddr:hPort. Finalmente, com uma NAT Simétrica, cada solici- tação a partirdamesma iAddr:iPort para um endereço IP de destino especí- fico e a porta é mapeada em uma eAddr:ePort exclusiva. Se os mesmo host interno enviar um pacote para um destino diferente, um endereço externo e E—— “ O mapeamento de porta diferente são usados. Apenas um host externo que recebe um pacote a partir de um host interno pode enviar um pacote de volta para o host interno.

Computação ponto a ponto ("P2P") refere-se a uma arquitetura de rede distribuída compreendida por 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 os canais de comunicação direta uns com os outros e atuam tanto como clientes como servidores, em contraste com o modelo cliente-servidor tradicional no qual os servidores fornecem recursos e os clientes consomem os recursos.

As operações NAT descritas acima apresentam problemas nu- merosos para as conexões P2P. Por exemplo, o estabelecimento de uma conexão direta entre dois pontos se torna crescentemente difícil se um ou . ambos os pontos se situarem atrás de um ou mais tipos de NAT descritos acima. Este problema é exacerbado pelo fato de que os dispositivos clientes, a tais como, Apple iPod Touchº, Apple iPhone, Apple iPadº e diversos outros dispositivos (por exemplo, dispositivos RIM Blackberry", dispositivos Palm Preº etc.) são frequentemente movidos entre as redes que têm implementa- ções NAT diferentes. Por exemplo, o Apple iPhoneº é capaz de se comuni- car através de redes Wi-Fi (por exemplo, redes 802.11b, g, n); redes 3G (por exemplo, redes de Sistema de Telecomunicações Móvel Universal (CUMTS"), redes de Acesso de Pacote de Uplink de Alta Velocidade ("HSU- PA") etc.); e redes Bluetooth (conhecidas como redes de área pessoal ("PANs")). Os futuros dispositivos clientes serão capazes de se comunicar através de canais de comunicação adicionais, tais como, WiMAX, Teleco- municação Móvel Internacional ("IMT") Evolução de Longo Prazo Avançada ("LTE"), para citar alguns.

As unidades de mãos livres (por exemplo, fones de ouvido, kits para carro) são tipicamente usadas para se emparelhar com um dispositivo de computação para serviços de mãos livres. Por exemplo, é comum que um dispositivo de computação que inclua funcionalidade de telefonia celular pa- ra incluir a capacidade de se emparelhar com uma unidade de mãos livres Uuppnp——————

i 5/86 que atua como uma retransmissão auditiva entre a unidade de mãos livres e o dispositivo de computação.

SumárioDescrevem-se um método e aparelho para auxiliar no estabelecimento de uma sessão de comunicação online entre dispositivos de — computação cliente.

Uma mensagem de solicitação de convite de sessão de comunicação online é recebida a partir de um dispositivo de computação cliente de iniciação, a mensagem inclui dados de conexão do dispositivo de computação de iniciação e um identificador de ponto de extremidade de ses- são de comunicação online para um destinatário pretendido.

Um conjunto de um oumais push tokens que são associados ao identificador é determinado, onde cada um dos push tokens identifica um dispositivo de computação cli- ente.

Uma mensagem de convite de sessão de comunicação online que in- clui os dados de conexão do dispositivo de computação cliente de iniciação - é transmitida para um conjunto de dispositivos de computação cliente de destinatário pretendido que corresponde ao conjunto de push tokens.

Uma , mensagem de convite de aceitação é recebida a partir de pelo menos um dos conjuntos de dispositivos de computação cliente de destinatário preten- didos que inclui dados de conexão daquele dispositivo de computação.

Uma mensagem de convite de aceitação é transmitida para o dispositivo de com- putação de iniciação que inclui os dados de conexão de cada dispositivo de computação de aceitação para permitir que o dispositivo de computação de iniciação e cada dispositivo de computação de aceitação estabeleçam uma sessão de comunicação online ponto a ponto direta.

Breve Descrição dos Desenhos A invenção pode ser mais bem entendida referindo-se à seguinte descrição e desenhos em anexo que são usados para ilustrar as modalida- des da invenção.

Nos desenhos: 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 comuma modalidade; a figura 2 é um diagrama em bloco que ilustra o dispositivo clien- te da figura 1 em mais detalhes, de acordo com uma modalidade; Vnp—nnn a figura 3 é um diagrama em bloco que ilustra o servidor de re- gistro da figura 1 em mais detalhes, de acordo com uma modalidade; a figura 4 é um fluxograma que ilustra operações exemplificati- vas para registrar um dispositivo cliente para sessões de comunicação onli- ne,deacordocom uma modalidade; .

a figura 5 ilustra um repositório de dados de registro exemplifica- tivo, de acordo com uma modalidade; a figura 6 ilustra uma topologia de rede geral de uma modalida- de; a figura 7 é um diagrama de fluxo de dados que ilustra o estabe- lecimento de sessão de comunicação online entre dispositivos clientes, de acordo com uma modalidade; a figura 8 é um diagrama em bloco que ilustra um serviço de re- N transmissão exemplificativo, de acordo com uma modalidade; a figura 9 ilustra uma modalidade de uma arquitetura API, de a- É cordo com uma modalidade; a figura 10 ilustra um repositório de dados de registro exemplifi- cativo, de acordo com uma modalidade; a figura 11 ilustra uma tabela de compatibilidade NAT exemplifi- cativa, de acordo com uma modalidade; a figura 12 ilustra um dispositivo cliente exemplificativo e uma in- terface gráfica de usuário que é usada para transição entre chamadas comu- tadas por circuito e chamadas de vídeo, de acordo com álgumas modalida- des; a figura 13 ilustra o dispositivo cliente da figura 12 que exibe uma visualização de vídeo, de acordo com uma modalidade; a figura 14 ilustra um dispositivo cliente exemplificativo e interfa- ce gráfica de usuário que é usada para aceitar ou negar convites de chama- da de vídeo, de acordo com uma modalidade; as figuras 15 e 16 ilustram dispositivos clientes após efetuarem a transição para uma chamada de vídeo, de acordo com uma modalidade; as figuras 17 e 18 são fluxogramas que ilustram operações e- VRpppm—

i 7/86 xemplificativas para efetuar a transição entre uma chamada de telefone co- mutada por circuito apenas de áudio para uma chamada de vídeo, de acordo com uma modalidade;

a figura 19 é um fluxograma que ilustra operações exemplificati-

vas realizadas em um dispositivo cliente que recebeu uma mensagem de rejeição de chamada de vídeo de acordo com uma modalidade;

a figura 20 é um fluxograma que ilustra operações exemplificati- vas realizadas em um dispositivo cliente para efetuar a transição de uma chamada de vídeo para uma chamada comutada por circuito, de acordo com uma modalidade;

a figura 21 ilustra a topologia de rede geral usada para registrar um dispositivo cliente para sessões de comunicação online que usam um endereço de email como um identificador de ponto de extremidade de ses-

- são de comunicação online, de acordo com uma modalidade; as figuras 22A-B são fluxogramas que ilustram operações e- ' xemplificativas para registrar um endereço de email como um identificador de ponto de extremidade de sessão de comunicação online, de acordo com uma modalidade;

a figura 23 é um fluxograma que ilustra operações exemplificati-

vas paraum usuário proporcionar informações de inicialização para registrar um endereço de email como um identificador de ponto de extremidade de sessão de comunicação online de, acordo com uma modalidade;

a figura 24 ilustra operações exemplificativas para validar um endereço de email, de acordo com uma modalidade;

a figura 25 é um fluxograma que ilustra operações exemplificati- vas realizadas em um serviço de registro quando um endereço de email tiver sido validado, de acordo com uma modalidade;

a figura 26 é um diagrama de fluxo de dados que ilustra opera- ções exemplificativas para gerenciar convites quando um usuário tiver múlti-

plos dispositivos clientes que são associados ao mesmo identificador de ponto de extremidade de sessão de comunicação online, de acordo com uma modalidade;

VUa—

| 8/86 a figura 27 é um fluxograma de dados que ilustra operações e- xemplificativas que são realizadas quando uma conexão P2P direta for prati- cável, de acordo com uma modalidade;

a figura 28 é um diagrama de fluxo de dados que ilustra opera-

ções exemplificativas que são realizadas quando uma conexão P2P direta for impraticável, de acordo com uma modalidade;

a figura 29 é um fluxograma de dados que ilustra operações e- xemplificativas realizadas quando uma sessão de comunicação online encer- rar, de acordo com uma modalidade;

a figura 30 é um fluxograma que ilustra operações exemplificati- vas realizadas para transferir uma sessão de comunicação online a partir de um dispositivo cliente para outro dispositivo cliente, de acordo com uma mo- dalidade;

- a figura 31 é um fluxograma que ilustra operações exemplificati-

vas para iniciar e estabelecer uma sessão de comunicação online com múl-

' tiplos usuários, de acordo com uma modalidade;

a figura 32 é um diagrama em bloco que ilustra um dispositivo de computação cliente que faz interface com uma unidade de mãos livres, de acordo com uma modalidade;

a figura 33 ilustra um dispositivo de computação cliente que re- cebe um convite para uma chamada de vídeo, que faz com que um disposi- tivo de mãos livres toque, receba uma indicação de resposta a partir do dis- positivo de mãos livres, estabeleça a chamada de vídeo, e roteie o áudio para o dispositivo de mãos livres, de acordo com uma modalidade;

a figura 34 ilustra um dispositivo de computação cliente que ini- cia uma chamada de vídeo e roteia o áudio para a chamada de vídeo esta- belecida através de um dispositivo de mãos livres, de acordo com uma mo- dalidade;

a figura 35 ilustra um dispositivo de computação cliente que ini-

ciauma chamada de vídeo em resposta ao recebimento de uma solicitação de chamada a partir de um dispositivo de mãos livres, de acordo com uma modalidade;

VU——

| 9/86 a figura 36 ilustra um dispositivo de computação cliente que ro- teia o áudio de uma chamada de vídeo estabelecida para um dispositivo de mãos livres, de acordo com uma modalidade; a figura 37 ilustra um dispositivo de computação cliente que ter- minauma chamada de vídeo em resposta ao recebimento de uma solicita- ção de chamada de encerramento a partir de um dispositivo de mãos livres, de acordo com uma modalidade; a figura 38 é um diagrama em bloco que ilustra um sistema de computador exemplificativo que pode ser usado em algumas modalidades; e 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 - Na descrição a seguir, inúmeros detalhes específicos são esta- belecidos. Entretanto, entende-se que as modalidades da invenção podem ' ser praticadas sem estes detalhes específicos. Em outras instâncias, circui- . tos, estruturas e técnicas bem conhecidos não foram mostrados em deta- lhes, a fim de não obscurecer o entendimento desta descrição. Aqueles de conhecimento comum na técnica, com as descrições incluídas, serão capa- zesdeimplementar a funcionalidade apropriada sem experimentação.

As referências no relatório descritivo a "uma modalidade", "uma modalidade exemplificativa" etc., indicam que a modalidade descrita pode incluir um recurso, estrutura ou característica particular, porém, cada moda- lidade pode não incluir necessariamente o recurso, estrutura ou característi- ca particular. Além disso, tais frases não se referem necessariamente à mesma modalidade. Ademais, quando um recurso, estrutura ou característi- ca particular for descrito em conexão com uma modalidade, este é submeti- do ao conhecimento de uma pessoa versada na técnica para efetuar tal re- curso, estrutura ou característica em conexão com outras modalidades quer explicitamente descritas ou não.

Na descrição e reivindicações a seguir, os termos "acoplado" e "conectado", junto com seus derivados podem ser usados. Deve-se entender V——n que estes termos não são pretendidos como sinônimos entre si. O termo "acoplado" é usado para indicar que dois ou mais elementos, que podem ou não ficar em contato físico direto ou elétrico uns com os outros, cooperam ou interagem uns com os outros. O termo "conectado" é usado para indicar o estabelecimento da comunicação entre dois ou mais elementos que são a- coplados uns aos outros.

Registro Automático para Sessões de Comunicação Online Um método e aparelho para registrar automaticamente um dis- positivo de computação cliente ("dispositivo cliente") (por exemplo, uma es- 1o tação de trabalho, um laptop, um palmtop, um telefone celular, um smart- phone, um telefone multimídia, um tablet, um tocador de mídia portátil, uma unidade GPS, um sistema de jogos etc.) para sessões de comunicação onli- ne (por exemplo, videoconferência P2P, mensagens instantâneas P2P etc.) F são descritos. Em uma modalidade, em um evento em um dispositivo de computação (por exemplo, a ligação do dispositivo de computação), o dispo- : sitivo cliente começa automaticamente um processo de registro para ses- sões de comunicação online. O processo de registro automático inclui o dis- positivo cliente que transmite uma mensagem SMS (serviço de mensagens curtas) com um token de identificação (por exemplo, seu push token) e um dispositivo cliente identificador para um dispositivo de trânsito de SMS (por exemplo, uma porta de SMS ou um agregador de SMS). O token de identifi- cação identifica exclusivamente um dispositivo cliente para as mensagens de sessão de comunicação online (por exemplo, mensagens de solicitação de convite e convite de aceitação) e, em uma modalidade, um push token que pode conter informações que permitem que um serviço de notificação por push localize o dispositivo cliente. O token de identificação na modalida- de de serviço de notificação por push também é usado como um modo de estabelecer confiança de que uma notificação particular é legítima. Em ou- tras modalidades, qualquer registro ou mapeamento de dispositivos clientes paratokens exclusivos pode ser usado para associar tokens de identificação aos dispositivos clientes e proporcionar um método confiável de associar a identidade do dispositivo cliente a um token exclusivamente identificado. O m———

dispositivo identificador identifica exclusivamente o dispositivo cliente e se baseia tipicamente em um ou mais identificadores de hardware (por exem- plo, um número de série do disposítivo, um ICC-ID (ID de Cartão de Circuito Integrado) de um cartão SIM (Módulo de Identidade de Assinante) etc.).

O dispositivo de trânsito de SMS determina o número de telefo- ne do dispositivo cliente (por exemplo, examinando-se o cabeçalho da men- sagem SMS) e transmite uma mensagem de IP (Protocolo de Internet) para um . servidor de registro com o token de identificação, dispositivo identificador e o número de telefone. O servidor de registro gera uma assinatura baseada notoken de identificação, dispositivo identificador, e no número de telefone, e transmite estes para o dispositivo de trânsito de SMS para distribuição pa- ra o dispositivo cliente. O dispositivo de trânsito de SMS transmite uma men- sagem SMS para o dispositivo cliente que inclui a assinatura e o número de - telefone. O dispositivo cliente, então, transmite uma mensagem de IP para o servidor de registro com a assinatura, dispositivo identificador, token de iden- ' tificação e número de telefone.

O servidor de registro valida as informações do dispositivo clien- te e armazena uma associação entre o token de identificação e o número de telefone em um repositório de dados de registro de sessão de comunicação online Em conjunto, o par associado do token de identificação e do número de telefone identificam 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 coinvite para uma sessão de comunicação online (por exemplo, sessão de chat de vídeo/confe- rê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 de extremidade de sessão de comunicação online de uma sessão de comunicação online. Por meio de exemplo, um usuário em um dispositivo cliente pode convidar outros usuários em outros dispositivos clientes para participar de uma sessão de comunicação online usando seus números de telefone. Em algumas modalidades, o dispositivo cliente não sabe original- mente seu próprio número de telefone.

V——nn—

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 repositório de dados de sistema de mensagens |P 150. O dispositivo cliente 110 (por exemplo, uma estação de trabalho, um laptop, um palmtop, um telefone de computação, um smartpho- ne, um telefone multimídia, um tablet, um tocador de mídia portátil, uma uni- dade GPS, um sistema de jogos etc.) inclui o token de identificação 115 (que pode ser um push token 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 (negação) de convite, que será posteri- ormente descrito em mais detalhes no presente documento.

O dispositivo identificador 117 identifica exclusivamente o dispositivo cliente e se baseia - tipicamente 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 Integra- ' do) de um cartão SIM (Módulo de Identidade de Assinante) etc.). O dispositi- vo cliente 110 inclui a capacidade de transmitir e receber mensagens SMS,

assim como a capacidade de conectar e enviar/receber mensagens de IP.

Após se registrar para sessões de comunicação online, o dispo- sitivo cliente 110 pode convidar e/ou aceitar convites para sessões de co- municação online.

O dispositivo cliente 110 é identificado nas sessões de comunicação online através de um identificador de ponto de extremidade de sessão de comunicação online.

Embora em uma modalidade, o identificador de ponto de extremidade de sessão de comunicação online seja um número detelefone do dispositivo cliente 110, em outras modalidades, o identificador de ponto de extremidade de sessão de comunicação, online é um identifica- dor diferente (por exemplo, um nome de usuário (por exemplo, um ID da Ap- ple), um endereço de email, um endereço para correspondência, um ende-

reço MAC, ou outro identificador). A rede de SMS 120, que inclui a portadora SMSC (Centro de Serviço de Mensagens Curtas) 125 e o dispositivo de trânsito de SMS 130 (por exemplo, uma porta de SMS ou um agregador de SMS). A portadora nn,

SMSC 125 é uma portadora de computação específica e recebe e distribui mensagens SMS.

Por exemplo, a portadora SMSC 125 distribui mensagens SMS enviadas a partir do dispositivo cliente 110 para o dispositivo de trânsi- to de SMS 130, e distribui mensagens SMS enviadas a partir do dispositivo detrânsito de SMS 130 para o dispositivo cliente 110. O dispositivo de trân- sito de SMS 130 separa a rede móvel e a rede IP.

O servidor de registro 140 registra dispositivos clientes, tal como, 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 ao número de telefone do dispo- sitivo (ou outro identificador de ponto de extremidade de sessão de comuni- cação online). As associações entre tokens de identificação e identificadores de extremidade de sessão de comunicação online são armazenados no re- . positório de dados de registro de sessão de comunicação online 150. Mediante um evento que ocorre no dispositivo cliente 110 (por ' exemplo, a ligação do dispositivo cliente, um aplicativo de sessão de comu- nicação online (por exemplo, um aplicativo de videoconferência P2P, um ' aplicativo de mensagens instantâneas P2P etc.) inicialização etc.), o disposi- tivo cliente 110 começa um processo de registro para sessões de comunica- ção online Em uma modalidade, o processo de registro começa automati- camente (sem interação do usuário) enquanto em outras modalidades o pro- cesso de registro começa após um usuário selecionar o registro do dispositi- vo cliente para sessões de comunicação online.

Nas modalidades onde o número de telefone do dispositivo cli- ente 110é usado como o identificador de ponto de extremidade de sessão de comunicação online, e, deste modo, será associado ao token de identifi- | cação 115 do dispositivo cliente 110 no repositório de dados de registro 150, o número de telefone do dispositivo cliente 110 deve ser determinado.

Uma vez que o dispositivo cliente 110 não sabe originalmente 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 SMS.

Por exemplo, na operação 1, o dispositivo cliente 110 U—“

transmite uma mensagem SMS com seu token de identificação 115 e o dis- positivo identificador 117 para o dispositivo de trânsito de SMS 130 através da portadora SMSC 125. Em algumas modalidades, a mensagem SMS é endereçada a um número de telefone, que pode ser um número de compri- mento padrão ou um código curto (um tipo de número de telefone que é de maneira típica significativamente mais curto que um número de telefone completo), que é especificamente estabelecido para o registro de sessão de comunicação online. O número de telefone ao qual a mensagem SMS é en- dereçada é armazenado no dispositivo cliente (por exemplo, em um grupo de portadoras).

A portadora SMSC 125 recebe a mensagem SMS e distribui a mesma para o 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ça- lhodamensagem SMS para determinar 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 para o servidor de registro 140 com o número de telefone do dispositivo cliente 110, o token de identificação 115 e o dispositivo identificador 117. Isto algumas vezes é referido como uma mensagem de solicitação de registro.

O servidor de registro 140 recebe a mensagem de IP do disposi- tivo de trânsito de SMS que inclui o número de telefone do dispositivo cliente : 110, o token de identificação 115 e o dispositivo identificador 117, e cria uma assinatura. A assinatura pode se basear no número de telefone do dispositi- vocliente 110, no token de identificação 115 e/ou no dispositivo identificador 117, e é usada para propósitos de validação (que serão posteriormente des- critos em maiores detalhes no presente documento). Em algumas modalida- des, um número aleatório também é usado quando a geração da assinatura representa situações onde múltiplos dispositivos clientes têm o mesmo nú- mero de telefone. O servidor de registro 140 transmite a assinatura, número de telefone, dispositivo identificador, e o token de volta para o dispositivo de trânsito de SMS 130 na operação 5 (por exemplo, em uma mensagem de VUR————

IP). Isto algumas vezes é referido como uma mensagem de resposta de re- gistro.

O dispositivo de trânsito de SMS 130 recebe a assinatura, núme- ro de telefone, dispositivo identificador e o token do servidor de registro 140 egeraumamensagem SMS com a assinatura e o número de telefone para o dispositivo cliente 110. O dispositivo de trânsito de SMS 130 transmite a mensagem SMS para o dispositivo cliente 110 com a assinatura e o número de telefone na operação 6 (através da portadora SMSC 125). O dispositivo cliente 110 recebe e processa a mensagem SMS queincluio armazenamento de seu número de telefone.

O dispositivo cliente 110 transmite uma mensagem de IP com seu token de identificação 115, dispositivo identificador 117, seu número de telefone, e a assinatura gerada pelo servidor de registro para o servidor de registro 140 na operação 7. Isto 7 algumas vezes é referido como uma mensagem de solicitação de validação deregistro. ' Usando-se a assinatura, o servidor de registro 140 valida os da- dos enviados pelo dispositivo cliente 110. Por exemplo, o servidor de registro 140 compara a assinatura enviada pelo dispositivo cliente 110 com a assina- tura gerada durante a operação 4. Se elas forem compatíveis, então, os da- dos são validados.

Supondo que os dados sejam válidos, o servidor de re- gistro 140 armazena uma associação entre o token de identificação 115 e o número de telefone do dispositivo cliente 110 no repositório de dados de re- gistro de sessão de comunicação online 150. Em uma modalidade alternativa, em vez de determinar o número de telefone do dispositivo cliente 110 através da transmissão de mensagens SMS, o usuário do dispositivo é solicitado a inserir o número de telefone do dispositivo cliente 110. Nestas modalidades, o dispositivo cliente 110 trans- mite diretamente o número de telefone do dispositivo cliente 110 (à medida que inserido pelo usuário) e seu token de identificação 115 para o servidor de registro 140, que pode associar estes no repositório de dados de registro de sessão de comunicação online 150. A figura 5 ilustra um repositório de dados de registro exemplifica- V———

tivo 150, de acordo com uma modalidade. Conforme 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 único número de telefone seja associado a múltiplos tokens de identificação. Por exemplo, dispositivos clientes diferentes podem ter o mesmo número de telefone. Nes- tes casos, estes dispositivos clientes diferentes podem ter tokens de identifi- cação diferentes. Deste modo, quando um convite de sessão de comunica- ção online for enviado para um número de telefone associado a múltiplos tokens de identificação, um convite será transmitido para cada dispositivo associado ao token de identificação.

A figura 2 é um diagrama em bloco que ilustra o dispositivo clien- te 110 em mais detalhes, de acordo com uma modalidade. A figura 2 será . descrita com referência à modalidade exemplificativa da figura 4, que é um fluxograma que ilustra operações exemplificativas para registrar um disposi- í tivo cliente para sessões de comunicação online. Entretanto, deve-se enten- der que as operações da figura 4 podem ser realizadas por modalidades di- ferentes 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.

Conforme ilustrado na figura 2, o dispositivo cliente 110 inclui o módulo de registro de sessão de comunicação online cliente ("módulo de registro de cliente") 210, o grupo de portadoras 215, o push token 115, o dispositivo identificador 117, o módulo de SMS 220, e o repositório de dados de registro de sessão de comunicação online cliente ("repositório 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 grupo de portadoras 215 inclui configurações específicas para uma portado- ra que inclui o número de telefone para o dispositivo de trânsito de SMS u- sado 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 troca de mensagens V———nn multimídia (MMS) etc.). O módulo de SMS 220 transmite e recebe mensa- gens SMS. O repositório de dados de registro de cliente 230 armazena da- dos relacionados ao registro de sessão de comunicação online (por exem- plo, o número de telefone do dispositivo cliente 110 uma vez determinado).

Referindo-se à 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. Os exemplos de tais eventos incluem a ligação do dis- positivo cliente 110, um usuário que abre um aplicativo de comunicação on- line (por exemplo, um aplicativo de videoconferência P2P, um aplicativo de mensagens instantâneas P2P etc.) etc. Em algumas modalidades, o proces- so de registro é realizado toda vez que o dispositivo cliente 410 liga, enquan- : to em outras modalidades o processo de registro é realizado a primeira vez que o dispositivo cliente 110 é ligado. O fluxo se move a partir do bloco 410 . até o bloco 415.

No bloco 415, o módulo de registro de cliente 210 determina 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 tiver expirado, então, o fluxo se move até o bloco 425 onde a ação alternativa é adotada. Por exemplo, em modalidades que usam push tokens, o dispositivo cliente 110 pode iniciar um procedimento de geração de token solicitando-se que um push token seja gerado por um serviço de notificação por push (que é tipicamente remoto do dispositivo cliente 110). O serviço de notificação por push gera um push token específico para o dispositivo cliente 110 e retorna o mesmo para o dispositivo cliente 110. Se existir um token de identificação válido, então, o fluxo se move até o bloco 420 onde o módulo de registro de cliente 210 acessa o token de identificação 115. O fluxo se move a partir do bloco 420 até o bloco 428. No bloco 428, o módulo de registro de cliente 210 acessa o dis- positivo identificador 117. O fluxo, então, se move até o bloco 430, onde o “30 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 grupo de portadoras 215 para V——

determinar o número de telefone do dispositivo de trânsito de SMS. O núme- ro de telefone pode ser um código curto ou pode ser um número de compri- mento padrão. Neste 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 a partirdo bloco 430 até o bloco 435.

No bloco 435, uma mensagem SMS que tem o token de identifi- cação 115 e o dispositivo identificador 117 é transmítida para o número de- ' terminado (o dispositivo de trânsito de SMS 130). Por exemplo, o módulo de registro de cliente 210 solicita o módulo de SMS 220 para transmitir uma mensagem SMS com o token de identificação 115 e o dispositivo identifica- dor 117 para o número determinado. O módulo de SMS 220 transmite a mensagem SMS com o token de identificação para o número determinado. O fluxo se move a partir do bloco 435 até o bloco 440. A mensagem SMS - será recebida pela portadora SMSC 125, que distribui a mesma para o dis- positivo de trânsito de SMS 130.

: No bloco 440, o dispositivo de trânsito de SMS 130 determina o número de telefone do dispositivo cliente 110 com base na mensagem SMS recebida. Por exemplo, o dispositivo de trânsito de SMS examina o cabeça- lho da mensagem SMS, que irá incluir o número de telefone do remetente que, neste caso, é o dispositivo cliente 110. O fluxo, então, se move até 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 dispositi- vo identificador 117 para o servidor de registro 140 (por exemplo, em uma : mensagem de IP protegida). O fluxo se move a partir do bloco 445 até o blo- co450.

A figura 3 é um diagrama em bloco que ilustra o servidor de re- gistro 140 em mais detalhes, de acordo com uma modalidade. A figura 3 se- rá descrita com referência à modalidade exemplificativa da figura 4. Entre- tanto, deve-se entender 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 ilus- pDpDpDmD———

trado 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 repositório de dados de validação 335,eomódulode associação 340. A interface de trânsito de SMS 310 re- cebe e envia mensagens para o dispositivo de trânsito de SMS 130. Por e- xemplo, a interface de trânsito de SMS 310 recebe as tuplas de número de telefone, token de identificação e de dispositivo identificador a partir da inter- face de trânsito de SMS 310, e transmite as tuplas de número de telefone, token de identificação, dispositivo identificador 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 mensa- gens para os dispositivos clientes. Por exemplo, a interface de dispositivo . cliente 325 recebe tuplas de validação a partir dos dispositivos clientes. Referindo-se novamente à figura 4, no bloco 450, o gerador de ' assinatura 310 gera uma assinatura para a tupla de número de telefone, to- ken de identificação, e dispositivo identificador que este recebeu a partir do dispositivo de trânsito de SMS 130. A assinatura será usada para validar a correspondência do número de telefone e do token de identificação antes de armazenar o par no repositório de dados de registro 150. Em algumas moda- lidades, a assinatura baseia-se no número de telefone, token de identífica- ção e/ou dispositivo identificador (por exemplo, um hash criptográfico é apli- cado ao número de telefone, token de identificação e/ou dispositivo identifi- cador, ou alguma porção destes, para gerar a assinatura). Em algumas mo- —dalidades, a assinatura também se baseia em um número aleatório que re- presenta situações onde múltiplos dispositivos clientes têm o mesmo número de telefone. O gerador de assinatura 310 armazena a assinatura e opcio- nalmente o número de telefone, token de identificação e/ou dispositivo identi- ficador no repositório de dados de validação 325. O fluxo, então, se move atéobloco455, onde a interface de trânsito de SMS 310 transmite a assina- tura, número de telefone, dispositivo identificador e token de identificação para o dispositivo de trânsito de SMS 130. O fluxo se move a partir do bloco V———n——

455 até o bloco 460.

O dispositivo de trânsito de SMS 130 recebe a assinatura, núme- ro de telefone e token de identificação do servidor de registro 140. No bloco 460, o dispositivo de trânsito de SMS transmite uma mensagem SMS (atra- vésda portadora SMSC 125) com a assinatura é o número de telefone para o dispositivo cliente 110. A seguir, o fluxo se move até o bloco 465.

No bloco 465, o módulo de SMS 220 recebe a mensagem SMS com a assinatura e o número de telefone e armazena a assinatura e o núme- ro de telefone no repositório de dados de registro de cliente 230. O fluxo, então, se move até 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, dispositivo identificador 117 e assi- natura. O fluxo, então, se move até o bloco 475.

- A interface de dispositivo cliente 325 recebe o número de telefo- ne, token de identificação, dispositivo identificador e assinatura do dispositi- ' vo 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 hash conforme aplicada quando gera a assinatura é usada no núme- ro de telefone, token de identificação e/ou dispositivo identificador recebido a partirdo dispositivo cliente, e o módulo de validação 330 compara o resulta- do com a assinatura que foi previamente gerada (armazenada no repositório de dados de validação 335). Se as assinaturas forem compatíveis, então, os dados são válidos e o fluxo se move até o bloco 480.

No bloco 480, o módulo de associação 330 do servidor de regis- tro 140 armazena uma associação do número de telefone do dispositivo cli- ente e do token de identificação do dispositivo cliente no repositório de da- dos de registro 150. Em algumas modalidades, o servidor de registro 140 pode transmitir uma mensagem de estado de registro para o dispositivo cli- ente 110 que alerta o dispositivo cliente 110 se o registro foi bem sucedido.

Após o dispositivo cliente ter sido registrado, um usuário no dis- positivo cliente pode iniciar e/ou aceitar um convite para uma sessão de co- municação online (por exemplo, sessão de chat de vídeo/conferência, ses- Vpnp—n—n—

são de mensagens instantâneas etc.). Por meio de exemplo, um usuário em um dispositivo cliente pode convidar outros usuários em outros dispositivos clientes para participar de uma sessão de comunicação online usando seus números de telefones.

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 SMS durante o registro, em outras modalidades, outros tipos de troca de mensagens de texto podem ser usa- dos (por exemplo, MMS (Serviço de Troca de Mensagens Multimídia)). Registros de Endereços de Email para Sessões de Comunicação Online Embora a figura 1 tenha sido descrita em relação ao registro de um número de telefone como um identificador de ponto de extremidade de sessão de comunicação online, em outras modalidades um endereço de email é 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 sessões de comunicação online á usando um endereço de email como um identificador de ponto de extremi- dade de sessão de comunicação online.

Os dispositivos clientes 2110A-N usam o serviço de registro 2130 para se registrar em sessões de comunica- ção online.

Por exemplo, em uma modalidade, o usuário de um dispositivo cliente2110A usa o cliente de sessão de comunicação online 2115 para re- gistrar um endereço de email para uso como um identificador de sessão de comunicação online para comunicações online através da rede 2180 (por exemplo, a Internet). As figuras 22A-B são fluxogramas que ilustram operações e- xemplificativas para registrar um endereço de email 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 à modali- dade exemplificativa ilustrada na figura 21. Entretanto, deve-se entender que as operações das figuras 22A-B podem ser realizadas por modalidades dife- rentes daquelas discutidas com referência à figura 21, e as modalidades dis- cutidas com referência à figura 21 podem realizar operações diferentes da- quelas discutidas com referência às figuras 22A-B.

V———

Na operação 2210, o serviço de registro 2130 recebe uma solici- tação de autenticação a partir do dispositivo cliente 2110A.

Por exemplo, com referência à figura 23, que descreve operações exemplificativas para um usuário proporcionar informações de inicialização, na operação 2310, o aplicativo de sessão de comunicação online 2115 é iniciado no dispositivo cliente 2110A.

O fluxo, então, se move até a operação 2315 e o dispositivo cliente 2110A recebe a entrada a partir do usuário que inclui um ID e senha de usuário e um ou mais endereços de email para registro para uso como identificador de ponto de extremidade de sessão de comunicação online.

O fluxo, então, se move até a operação 2320 e o dispositivo cliente 2110A transmite o ID e senha de usuário para o serviço de registro 2130. Embora o dispositivo cliente 2110A registre um endereço de email como um identificador de ponto de extremidade de sessão de comuni- . cação online e possa não incluir funcionalidade de telefone, este pode enviar um convite de sessão de comunicação online usando um número de telefo- á ne em vez de um endereço de email.

Além de receber um ID de usuário, senha e um ou mais endereços de email no registro, em algumas modalida- des, o usuário também pode proporcionar informações que se referem a qual país e/ou região ele se situa atualmente, de modo que um código de país e/ou código de região correspondente possa ser usado se o usuário iniciar uma sessão de comunicação online com um número de telefone que não inclui um código de país e/ou código de região.

Por exemplo, nos Esta- dos Unidos, uma chamada telefônica local pode ser estabelecida usando-se 7 dígitos (deste modo, o código de país e código de área não são requeri- dos). O sistema telefônico subjacente automaticamente determina o código de país e de área e completa a chamada.

Entretanto, nos casos em que o dispositivo cliente 2110A não inclui funcionalidade de telefone, o dispositivo cliente 2110A não pode depender do sistema telefônico subjacente para in- cluir automaticamente o código de país e/ou código de região quando convi- daum usuárioparauma sessão de comunicação online usando um número de telefone que não inclui o código de país e/ou código de região.

Na operação 2320, o dispositivo cliente 2110A recebe entrada a Vn——nn partir do usuário que se refere a qual país e/ou região (por exemplo, código de área, estado, província, cidade etc.) ele se situa. O fluxo, então, se move até a operação 2320 onde o dispositivo cliente 2320 associa os códigos de telefone de pais e/ou região correspondente ao aplicativo de sessão de co- municação online 2115 para uso se o usuário iniciar uma sessão de comuni- cação online com um número de telefone que não inclui um código de país e/ou código de região. Por exemplo, se o usuário indicar que ele se situa nos Estados Unidos e o usuário convidar um usuário para uma sessão de comu- nicação online usando um número de telefone de 10 dígitos que não inclui o código de país, o dispositivo cliente 2110A adiciona automaticamente o có- digo de país dos Estados Unidos ao número de telefone.

Referindo-se novamente à figura 22A, após receber a solicitação de autenticação do dispositivo cliente 2110A, um processo de autenticação é . realizado usando o nome e senha de usuário proporcionada. Em uma moda- lidade, o serviço de registro 2130 realiza o processo de autenticação, en- ' quanto 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 ser- viço centralizado que proporciona ao usuário contabilidade, autenticação e outros serviços. O serviço de diretório de usuário 2160 gerencia os registros deusuário2165. Em uma modalidade, cada usuário autenticado é associado a um registro de usuário que inclui diversas informações (por exemplo, um ou mais entre um ID de usuário, senha, endereço para correspondência, número de telefone, nome, aniversário, país, uma lista de emails associados ao usuário (que também pode indicar se o endereço de email é validado) etc). Sea autenticação for bem sucedida, então, o fluxo se move até a ope- ração 2216. Se a autenticação falhar, então, o fluxo se move até a operação 2214 e a ação alternativa é adotada (por exemplo, o serviço de registro 2130 transmite uma mensagem de erro para o dispositivo cliente 2110A que indica que o nome e/ou senha de usuário não está correto).

Na operação 2216, o serviço de registro 2130 gera e/ou acessa um perfil de sessão de comunicação online associado ao ID de usuário. Por exemplo, o serviço de registro 2130 pode incluir um servidor de conta de

VU sessão de comunicação online 2140 que gerencia os registros de perfil de sessão de comunicação online 2150. Em uma modalidade, cada usuário que está se registrando ou se registrou para sessões de comunicação online tem um registro de perfil de sessão de comunicação online correspondente.

Ca- da registro de perfil de sessão de comunicação online pode incluir um con- junto de um ou mais endereços de email, que inclui seu estado de validação, que são associados ao perfil.

Cada registro de perfil de sessão de comuni- cação online também pode incluir um ou mais push tokens que correspon- dem a um ou mais dispositivos clientes que são respectivamente registrados para sessões de comunicação online.

Cada registro de perfil também pode incluir credenciais de perfil que são usadas para validar determinadas comu- nicações a partir dos dispositivos clientes.

Cada registro de perfil também pode indicar que os dispositivos clientes (conforme indicados por push to- . kens) registraram ou estão tentando registrar estes endereços de email.

O fluxo se move a partir da operação 2216 até a operação 2218 Ú e o serviço de registro 2130 transmite uma resposta de autenticação para o dispositivo cliente 2110A que inclui o ID de perfil (por exemplo, uma cadeia que identifica o perfil associado ao ID de usuário proporcionado) e as cre- denciais de perfil.

A resposta de autenticação também pode indicar que a autenticação foi bem sucedida.

O fluxo, então, se move até a operação 2220 e o serviço de registro 2130 recebe uma solicitação de validação de email do dispositivo cliente 2110A que inclui um ou mais endereços de email para validar, ID de perfil, credenciais de perfil e o push token do dispositivo cliente 2110A.

A mensagem de solicitação de validação de email! também pode in- cluiroID de dispositivo do dispositivo cliente 2110A.

O serviço de registro 2130, então, determina se as credenciais de perfil são válidas para o ID de perfil na operação 2222. Se elas não forem, então, o fluxo se move até a operação 2224 e a ação alternativa é adotada (por exemplo, o serviço de registro 2130 transmite uma mensagem de erro para o dispositivo cliente 2110A). Se suas credenciais de perfil forem válidas, então, o fluxo se move até a operação 2223. Na operação 2223, o serviço de registro 2130 associa o push token ao perfil.

Por exemplo, o servidor de conta de sessão de co- V—

municação online 2140 armazena o push token no registro de perfil para o usuário. O fluxo, então, se move até a operação 2226 e o serviço de re- gistro 2130 determina se o endereço de email é validado. Um endereço de emailvalidadoé um endereço de email que foi validado pertencendo à solici- tação do usuário que está solicitando que este seja registrado para uso co- mo 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 o registro de perfil do usuário 2150 para determinar se o endereço de email é validado. Se o registro de perfil não indicar que o endereço de email é vali- dado, em algumas modalidades, o serviço de registro 2130 transmite um endereço de solicitação de validação de email para o serviço de diretório de . —usuário 2160 para determinar se o registro de usuário 2165 para o usuário - indica que o endereço de email é validado. Se o endereço de email não for validado, então, o fluxo se move até a operação 2227 e o serviço de registro í 2130 faz com que uma mensagem de email de validação seja enviada para o endereço de email que inclui um link que quando selecionado (ou quando inserido em um navegador de Internet) faz com que o endereço de email seja validado. Por exemplo, a seleção do link faz com que uma mensagem de validação de endereço de email seja enviada que inclui o endereço de email e um token de validação que são usados para validar o endereço de email. O serviço de registro 2130 também pode transmitir uma mensagem de validação de necessidade de endereço de email para o dispositivo cliente que indica que o endereço de email não é validado (e, deste modo, precisa ser validado) e também pode indicar que uma mensagem de email de vali- dação foi enviada para o endereço de email em questão. O fluxo, então, se move até a operação 2410, que será descrito com referência à figura 24. Entretanto, se o endereço de email for validado, então, o fluxo se move até a operação 2228.

Na operação 2228, o serviço de registro 2130 transmite uma mensagem de sucesso de endereço de email validado para o dispositivo cliente 2228 que indica que o endereço de email foi validado. O fluxo, então, VU——n se move até a operação 2230 e o serviço de registro 2130 recebe uma solici- tação de ativação de email do dispositivo cliente 2228 que inclui o endereço de email, ID de perfil e credenciais de perfil. O serviço de registro 2130 de- termina, então, se as credenciais de perfil são válidas para o ID de perfil na operação 2232. Se elas não forem, então, o fluxo se move até a operação 2224 e a ação alternativa é adotada (por exemplo, o serviço de registro 2130 transmite uma mensagem de erro para o dispositivo cliente 2110A). Se suas credenciais de perfil forem válidas, então, o fluxo se move até a operação

2240.

Na operação 2240, o serviço de registro 2130 gera ou acessa credenciais de email para o endereço de email. Por exemplo, em uma moda- lidade, o servidor de conta de sessão de comunicação online 2140 armaze- na as credenciais de email para cada endereço de email validado de um u- - suário naquele registro de perfil do usuário 2150. O fluxo, então, se move até a 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 email e as credenciais de email.

O fluxo se move a partir da operação 2242 até a operação 2244 e o serviço de registro 2130 recebe uma mensagem de solicitação de regis- troque inclui o endereço de email, as credenciais de email, o ID de perfil, as credenciais de perfil, o push token do dispositivo cliente 2110A e o ID de : dispositivo do dispositivo cliente 2110A. Em uma modalidade, a mensagem de solicitação é recebida no servidor de registro de sessão de comunicação online 2145. O servidor de registro de sessão de comunicação online geren- ciao repositório de dados de registro de sessão de comunicação online

2155. O repositório de dados de registro de sessão de comunicação online 2155 associa um push token (e opcionalmente o ID de dispositivo) ao perfil que tem um conjunto de um ou mais endereços de email como o identífica- dor de ponto de extremidade de sessão de comunicação online. Deste mo- do, cada registro no repositório de dados de registro de sessão de comuni- cação 2155 representa que um dispositivo particular com um push token par- ticular está usando um perfil de sessão de comunicação online que tem um V——

ou mais endereços de email que podem ser usados para convidar um usuá- rio naquele dispositivo para uma sessão de comunicação online.

O fluxo se move a partir da operação 2244 até a operação 2246. 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 elas não forem válidas, então, o fluxo se move até a operação 2250 e a ação alternativa é adotada (por exemplo, o serviço de registro 2130 transmite uma mensagem de erro para o dispositivo cliente 2110A). Se elas forem válidas, então, o fluxo se move até a operação 2248eo serviço de registro 2130 (por exemplo, o servidor de registro de sessão de comunicação online 2145) determina se as credenciais de ende- reço de email são válidas.

Se elas não forem, então, o fluxo se move até a operação 2250. Se elas forem válidas, então, o fluxo se move até a opera- . ção 2252. 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 dis- positivo cliente 2110A ao seu push token com o perfil que tem o endereço de email e armazena a associação no repositório de dados de registro 2155. O fluxo, então, se move até a 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 transmite os mesmos para o dispositivo cliente 2110A na operação 2256. Existem maneiras diferêntes para validar endereços de email em modalidades diferentes.

Com referência à figura 24, que é um fluxograma queilustraoperações exemplificativas para validar um endereço de email, na operação 2410, o dispositivo cliente 2110A determina se este inclui um clien- te de email que inclui uma conta para um endereço de email que este tentou registrar e não receber uma mensagem de email de validação positiva.

Se este não incluir tal cliente de email, então, o fluxo se move até a operação 2440,de outro modo, o fluxo se move até a operação 2415. Na operação 2415, a conta de email é verificada de maneira au- tomaticamente periódica para uma mensagem de email de validação (por V—nn exemplo, a mensagem de email de validação transmitida na operação 2227). Em uma modalidade, o aplicativo de sessão de comunicação online 2115 solicita de maneira periódica que o cliente de email 2120 verifique a mensa- gem de email de validação (o cliente de email 2120 pode nomear o servidor de email2170 para verificar a mensagem de email de validação). A mensa- gem de email de validação é identificada por um conjunto de um ou mais critérios que incluem a partir de: campo, para: campo, e um token de valida- ção (o token de validação pode ser exclusivo para cada endereço de email que é validado) que é usado para validar o endereço de email. O token de validação pode se situar no cabeçalho ou no corpo da mensagem de email de validação. Se a mensagem de email de validação for recebida, então, o fluxo se move a partir da operação 2420 até a operação 2425, de outro mo- do, o fluxo se move até a operação 2435.

- Na operação 2425, a mensagem de email de validação é retor- 15 . nada para o aplicativo de sessão de comunicação online 2115 e este analisa a mensagem para localizar o token de validação. Após localizar o token de validação, o aplicativo de sessão de comunicação online 2115 transmite uma mensagem de validação de endereço de email para o serviço de registro 2130 com o token de validação, o endereço de email, o ID de perfil e as cre- denciais de perfil. Deste modo, nesta modalidade, o endereço de email é automaticamente validado sem requerer que o usuário clique em um link ou, de outro modo, valide o endereço de email. Em uma modalidade, após rece- ber a mensagem e determinar que as credenciais de perfil são válidas, o serviço de registro 2130 transmite uma mensagem push validada por email (através do serviço de notificação por push 640) para o dispositivo que indica que o endereço de email foi validado de maneira bem sucedida. Deste mo- do, O fluxo se move a partir da operação 2425 até a operação 2430 e o dis- positivo cliente 2110A espera para receber a mensagem push validada por endereço de email.

Se uma mensagem de email de validação não tiver sido recebi- da, então, o fluxo se move até a operação 2435, onde o dispositivo cliente determina se uma mensagem push validada por email foi recebida, que indi- Upp——

ca que o endereço de email que esta tentando ser registrado foi validado. Se tal mensagem for recebida, então, o fluxo se move até a operação 2445, de outro modo, o fluxo se move de volta para a operação 2415. Na operação 2440 (o dispositivo cliente 2110A não inclui um cli- entede email que inclui uma conta para o endereço de email que está sendo registrado), o dispositivo cliente 2110A espera para receber uma mensagem push validada por email que foi recebida que indica que o endereço de email que está tentando ser registrado foi validado. Se tal mensagem for recebida, então, o fluxo se move até a operação 2445, de outro modo, o fluxo perma- necena operação 2440.

Na operação 2445, o dispositivo cliente 2110A mostra que o en- dereço de email foi validado e pede que o usuário continue com o processo de registro com aquele endereço de email. Se o dispositivo cliente 2110A - recebe a entrada que indica para continuar com o processo de registro, en- tão, o fluxo se move até a operação 2455 e o dispositivo cliente 2110A ] transmite uma solicitação de email ativa que inclui o endereço de email, o D de perfil e as credenciais de perfil para o servidor de registro. As operações descritas que começam na operação 2230 da figura 22, então, são realiza- das. Se o dispositivo cliente 2110A recebe a entrada que indica que o usuá- rionão deseja continuar com o processo de registro, então, o fluxo se move a partir da operação 2450 até a operação 2460 e o processo sai.

A figura 25 é um fluxograma que ilustra operações exemplificati- vas realizadas no serviço de registro quando um endereço de email tiver si- do validado, de acordo com uma modalidade. Na operação 2510, o serviço deregistro 2130 recebe uma mensagem de estado validada de endereço de email que indica que um endereço de email que é associado a um perfil de sessão de comunicação online foi validado. A mensagem de estado validada de endereço de email pode ter sido recebida como um resultado da opera- ção 2425, ou pode ter sido recebida como um resultado do endereço de e- mail queé validado de uma maneira diferente (por exemplo, um usuário que clica em um link de validação em uma mensagem de email de validação que faz com que o endereço de email seja validado, que pode ser enviado em V——n um dispositivo diferente do dispositivo que está tentando registrar o endere- ço de email para uso nas sessões de comunicação online). O fluxo, então, se move até a operação 2515 e o serviço de re- gistro 2130 atualiza o estado de validação para o endereço de email nos re- gistros de perfil 2150. O fluxo, então, se move até a operação 2515 e o ser- viço de registro 2130 determina se existem dispositivos clientes que são as- sociados ao perfil de sessão de comunicação online que foi solicitado para validar o endereço de email que não recebeu uma mensagem validada de - endereço de email.

Por exemplo, o serviço de registro 2130 acessa o regis- trode perfil 2150 para o perfil de sessão de comunicação online para deter- minar quais dispositivos clientes (por exemplo, conforme identificados por push tokens exclusivos) foram convidados a validar o endereço de email e quais não receberam uma mensagem de validação de endereço de email ' para este endereço de email.

Para cada tal dispositivo cliente, o serviço de registro transmite uma mensagem push validada por email para aquele dis- í positivo cliente que inclui o ID de perfil, credenciais de perfil e o endereço de email que foi validado na operação 2525. A mensagem push validada por | email também pode incluir uma atualização de estado que indica que o en- dereço de email foi validado.

Se não existirem dispositivos que foram solici- tados a validar o endereço de email que não recebeu uma mensagem vali- dada de endereço de email, então, o fluxo se move até a operação 2530 e o processo sai.

Estabelecimento de Sessões de Comunicação Online Conforme ilustrado na figura 6, uma topologia de rede geral im- —plementada em uma modalidade pode incluir inúmeros dispositivos clientes A-N, 670A-N, respectivamente, que se comunicam uns com os outros e com um ou mais serviços 610, 620, 630, 640 e 650 ao longo de uma rede 660. Embora ilustrada como uma única nuvem de rede, a rede 660 pode incluir uma variedade de componentes diferentes que incluem redes públicas, tal como, a |lnternete redes privadas, tais como, as redes Wi-Fi locais (por e- xemplo, redes sem fio domiciliares 802.11n ou pontos de acesso sem fio), redes de Ethernet de área local, redes de dados de celular (por exemplo,

3G, 4G, Edge etc.) e redes WiMAXs, para citar algumas. Os dispositivos cli- entes 670A-N podem se conectar à rede 660 através de links de rede dife- rentes. Por exemplo, o dispositivo cliente 670A pode ser conectado a uma rede Wi-Fi domiciliar representada pelo link de rede 675A e o dispositivo cli- ente670N pode ser conectado a uma rede 3G (por exemplo, Sistema Uni- versal de Telecomunicações Móveis ("UMTS"), Acesso de Pacotes de Uplink de Alta Velocidade ("HSUPA") etc.) através do link de rede 675N. Cada um dos links de rede 675A-N através do qual os dispositivos clientes 670A-N são conectados pode ser acoplado a uma rede pública, tal como, a Internet, através uma porta e/ou dispositivo NAT (Tradução de Endereço de Rede) (não mostrado na figura 6) que permite, deste modo, a comunicação entre os diversos dispositivos clientes 670A-N através da rede pública. Entretanto, se dois dispositivos clientes se encontrarem no mesmo local ou rede privada - (por exemplo, a mesma rede Wi-Fi), então, os dois dispositivos podem se comunicar diretamente através daquele local/rede privada, ignorando a rede í pública. Deve-se notar, certamente, que os princípios subjacentes da inven- ção não se limitam a nenhum conjunto particular de tipos de rede ou topolo- | gias de rede. Cada um dos dispositivos clientes 670A-N pode se comunicar comum 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 por push 640 e um serviço de retransmissão 650. Em uma modalidade, os serviços 610-650 podem ser implementados como software executado ao longo de um ou mais dispositivos de computação físicos, tais como, servidores.

Em uma modalidade, o serviço CDX 610 opera como um ponto de troca central para dados de conexão requeridos para estabelecer as ses- sões de comunicação online entre dois ou mais dispositivos clientes. De ma- neira específica, uma modalidade do serviço CDX 610 gera dados NAT tra- versais (algumas vezes referidos como dados de "Perfuração") em resposta às solicitações de dispositivo cliente para permitir que os serviços e clientes externos se comuniquem através da NAT de cada dispositivo cliente (isto é, "perfurar um furo" através da NAT para atingir o dispositivo). Por exemplo, Nin em uma modalidade, o serviço CDX detecta o endereço de IP externo e por- ta necessária para se comunicar com o dispositivo cliente e proporciona es- tas informações para o dispositivo cliente. Em uma modalidade, o serviço CDX também recebe e processa as listas de dispositivos clientes gerados pelo serviço de convite 620 e distribui de maneira eficiente e segura os da- dos de conexão para cada um dos dispositivos clientes incluídos nas listas (conforme descrito em detalhes abaixo).

Os usuários dos dispositivos clientes 670A-N usam o serviço de convite 620 para convidar os usuários para participar de sessões de comuni- cação online colaborativas (por exemplo, videoconferência P2P, chats/confe- rência de mensagens instantâneas 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 através da - transmissão de 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 S online de cada um dos outros usuários. O identificador de ponto de extremi- dade 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, um ID da Apple), um endereço de email, um endereço para cor- respondência, um endereço MAC, ou outro identificador). O serviço de convi- te 620 lê o identificador de ponto de extremidade de sessão de comunicação online a partir da solicitação de convite e realiza uma pesquisa no repositório de dados de registro 655 para localizar o(s) dispositivo(s) cliente(s) que é(são) associado(s) ao identificador de ponto de extremidade de sessão de comunicação online.

Os dispositivos clientes 670A-N usam o serviço de registro 630 para registrar as sessões de comunicação online. Por exemplo, em uma modalidade, quando cada um dos dispositivos clientes 670A-N é ligado e ativado na rede, este faz com que seu token de identificação (por exemplo, seu push token) seja associado a um identificador de ponto de extremidade de sessão de comunicação online. As associações são armazenadas no re- positório de dados de registro 655. Em uma modalidade, os dispositivos cli- Vpm——

entes 670A-N se registram para participar do serviço de sessão de comuni- cação online usando o serviço de registro 630, conforme descrito em relação à figura 4, enquanto em outras modalidades, o processo de registro ocorre de maneira diferente (por exemplo, proporcionando-se tanto seu push token como seu identificador de ponto de extremidade de sessão de comunicação online).

O serviço de notificação por push 640 usa os push tokens dos dispositivos clientes 670A-N para transmitir notificações de push para os dispositivos clientes 670A-N. Em uma modalidade, as notificações de push são usadas para transmitir os convites para as sessões de comunicação on- line. O serviço de retransmissão 650 estabelece as conexões de sessão de comunicação online entre dispositivos clientes quando os tipos NAT dos dis- positivos clientes não forem compatíveis ou o estabelecimento de conexão - P2P tiver falhado entre os dispositivos clientes. Em uma modalidade, a comunicação entre os dispositivos clien- S tes e o serviço CDX 610 é estabelecida usando um protocolo de rede relati- vamente leve, tal como, os soquetes de Protocolo de Datagrama de Usuário | ("UDP"). Coforme conhecido por aqueles versados na técnica, as conexões de soquete UDP não requerem diálogos de aperto de mão para garantir a confiabilidade de pacote, ordenação, ou integridade de dados e, portanto, não consomem tanto overhead de processamento de pacote quanto as co- nexões de soquete TCP. Consequentemente, a natureza sem estado leve do j UDP é útil para servidores que respondem pequenas perguntas a partir de um vasto número de clientes. Além disso, diferente do TCP, o UDP é com- —patível com a radiodifusão de pacote (na qual os pacotes são enviados para todos os dispositivos em uma local rede) e difusão múltipla (na qual os paco- tes são enviados para um subconjunto de dispositivos na rede local). Con- forme descrito abaixo, mesmo que o UDP possa ser usado, a segurança . pode ser mantida no CDX 610 criptografando-se dados NAT traversal que usam chaves de sessão.

Em contraste com protocolo de rede leve de overhead baixo u- sado pelo serviço CDX 610, em uma modalidade, a comunicação entre os nm—

dispositivos clientes 670A-N e o serviço de convite 620, o serviço de registro 630, o serviço de notificação por push 640, e/ou o serviço de retransmissão 650 é estabelecido com um protocolo de rede inerentemente seguro, tal co- mo, Protocolo de Transferência de Hipertexto Seguro ("HTTPS"), que de- pende das conexões de Camada de Sockets Protegida ("SSL") ou Seguran- ça de Camada de Transporte ("TLS"). Os detalhes associados a estes proto-

colos são bem conhecidos por aqueles versados na técnica.

A figura 7 é um diagrama de fluxo de dados que ilustra o estabe- lecimento de sessão de comunicação online entre dispositivos clientes.

De acordo com uma modalidade.

No exemplo da figura 7, um usuário no dispo- sitivo cliente A 710 convida um usuário no dispositivo cliente B 720 para uma sessão de comunicação online (por exemplo, uma videoconferência P2P, um sistema de mensagens instantâneas P2P etc.). Neste exemplo, o dispositivo . cliente A 710 algumas vezes é referido como um dispositivo cliente de inicia- ção, o usuário do dispositivo cliente B 720 algumas vezes é referido como É um destinatário pretendido e o dispositivo cliente B 720 algumas vezes é referido como um dispositivo cliente de destinatário pretendido.

Em algumas | modalidades, um convite de sessão de comunicação online é um convite oculto sem presença.

Por exemplo, o usuário no dispositivo cliente A 710 nãosabe se o usuário no dispositivo cliente B 720 está atualmente online ou disponível para participar da sessão de comunicação online.

Embora as modalidades descritas com referência às figuras 6 e 7 sejam específicas ao uso de push tokens e notificações de push, outras modalidades não são tão limitadas.

Por exemplo, em outras modalidades, — qualquer registro ou mapeamento de dispositivos clientes para tokens exclu- sivos pode ser usado para associar tokens de identificação aos dispositivos clientes e proporcionar um método confiável de associar a identidade do dis-

positivo cliente a um token exclusivamente identificado.

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 os dispositivos clientes trocarem entre si para es- tabelecer uma sessão de comunicação online (por exemplo, uma sessão V——

! 35/86 P2P). Os dados de conexão incluem o endereço IP do dispositivo cliente (por exemplo, endereço IP público), o número de portas 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 A7I1O (por exemplo, os endereços e portas IP públicas/privadas, o tipo NAT do dispositivo NAT do dispositivo cliente). Na operação 2, a troca de dados de conexão 610 retorna os dados de conexão para o dispositivo cliente A

710.

Na operação 3, o dispositivo cliente A 710 transmite uma solici- “10 taçãode 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 videoconferência P2P, uma sessão de men- sagens instantâneas P2P etc.). Em uma modalidade, o convite inclui os da- . dos de conexão do dispositivo cliente A 710, que podem incluir endereços e portas|P públicas/privadas para o disposítivo cliente A 710 e o tipo NAT para ' o dispositivo NAT do dispositivo cliente A, e um identificador de ponto de . extremidade de sessão de comunicação online associado ao usuário no dis- positivo 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, um ID da Ap- ple), um endereço de email, um endereço para correspondência, um ende- reço MAC etc.). A solicitação de convite de sessão de comunicação online pode assumir a forma de uma solicitação HTTPS e pode incluir um certifica- do de cliente assinado por uma autoridade de certificado pré-especificada. Na operação 4, o serviço de convite 620 determina o(s) push to- ken(s) associado(s) ao identificador de ponto de extremidade de sessão de comunicação online incluído(s) na solicitação de operação 3. Por exemplo, o serviço de convite 620 acessa o repositório de dados de registro 655 para determinar os push tokens que são associados ao identificador de ponto de extremidade de sessão de comunicação online. Conforme ilustrado na figura 7,0 push token 725 é atribuído ao dispositivo cliente B 720 e, deste modo, é associado ao seu identificador de ponto de extremidade de sessão de co- municação online. A figura 10 ilustra um repositório de dados de registro e- —————

' 36/86 xemplificativo 655, de acordo com uma modalidade.

Conforme ilustrado na figura 10, cada um dos registros identificadores de sessão de comunicação online 1010 inclui um campo de push token 1015 e um campo de identifica- dor de sessão de comunicação online 1020. Conforme ilustrado na figura 10, omesmo identificador de sessão de comunicação online pode ser associado a múltiplos push tokens.

Em tal caso, múltiplos convites serão transmitidos (por exemplo, um por push token). O serviço de convite 620 transmite uma mensagem de solicita- ' ção de push para o serviço de notificação por push 640. Na operação 5, o serviço de notificação por 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 de extremidade de sessão de comunica- . ção online, e o push token do dispositivo cliente A 710 (o push token 715). À solicitação de convite também pode incluir informações específicas para a ' sessão de comunicação online dotar o usuário do dispositivo cliente B 720 : de 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 destes), para que o convite serve (por exemplo, uma videoconferência P2P, uma sessão de mensagens instantâneas P2P etc.) etc.). A solicitação de convite de sessão de comunicação online será recebida e exibida no dispositivo cliente B 720 se este estiver ligado e ope- rando corretamente.

A solicitação de convite inclui um mecanismo para o usuário aceitar ou recusar o convite (por exemplo, um botão aceitar e um botão recusar). O usuário no dispositivo cliente A 710 pode receber uma no- tificação se a solicitação de convite for negada.

Supondo que um usuário no dispositivo cliente B 720 aceite a solicitação de convite, na operação 6 o dis- positivo 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 da- dos de conexão do dispositivo cliente B 720 (por exemplo, os endereços e portas IP públicas/privadas, tipo NAT do dispositivo NAT do dispositivo clien- UuDmDpDmDmDm———

te B) e, na operação 7, retorna os dados de conexão para o dispositivo clien- te B 720. O dispositivo cliente B 720, então, transmite uma mensagem de aceitação para o serviço de convite 620 na operação 8. A mensagem de a- ceitação inclui os dados de conexão do dispositivo cliente B 720 e inclui o push token do dispositivo cliente A 710. A mensagem de aceitação também pode conter uma indicação se isto é uma repetição de uma tentativa de co- nexão P2P direta de falha anterior entre o dispositivo cliente A 710 e o dis- positivo cliente B 720. A mensagem de aceitação pode assumir a forma de umamensagem HTTPS.

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 e- xemplo, em uma modalidade, se a mensagem de aceitação recebida a partir ' do dispositivo cliente B 620 indica que esta é uma repetição de uma tentativa : de conexão direta de falha anterior (ou um número especificado de tentati- vas de conexão direta de falha anterior), então, o serviço de convite 620 po- ' de concluir que uma conexão P2P direta é impraticável.

Para determinar a praticabilidade, o serviço de convite 620 pode comparar os dados do tipo NAT para os dispositivos clientes A e B para determinar se os dispositivos NAT dos dispositivos clientes A e B irão suportar uma conexão P2P direta.

Em uma modalidade, a mensagem de aceitação descrita acima não inclui uma indicação de tentativas de falhas anteriores.

De preferência, após uma tentativa de conexão direta falhar, cada um dos dispositivos clientes 710-720 pode transmitir uma solicitação de "convite de retransmissão" especial (por exemplo, no lugar 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 ser- viço de convite pode invocar automaticamente as operações de retransmis- são descritas no presente documento (conforme descrito abaixo). Determinadas combinações de tipos NAT são conhecidas por serem incompatíveis para estabelecer conexões P2P.

Por exemplo, um NAT V——n—

: 38/86 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 contrapartida, um NAT simétrico pode ser usado apenas com um NAT de cone completo para estabelecer uma conexão P2P direta.

A pratica- —bilidadede combinar diversos tipos de NAT em uma modalidade é estabele- cida na tabela de compatibilidade NAT 1110 mostrada na figura 11, na qual as colunas representam os tipos de NAT de um dispositivo cliente (por e- xemplo, dispositivo cliente A 710) e as linhas representam os tipos de NAT do outro dispositivo cliente (por exemplo, dispositivo cliente B 720). "1,0" em uma célula indica que os tipos de NAT na linha e coluna associada são compatíveis e "0,0" indica que os tipos de NAT são incompatíveis.

Se o serviço de convite 620 determina que uma conexão P2P di- reta é praticável, então, o serviço de convite 620 transmite uma solicitação . de push para o serviço de notificação por push 640 para transmitir a aceita- ção da solicitação de convite.

Deste modo, na operação 10B, o serviço de ' notificação por 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 dispo- sitivo cliente A 710. A mensagem de aceitação inclui os dados de conexão, o ' identificador de ponto de extremidade de sessão de comunicação online, e o push token do dispositivo cliente B 720. A mensagem de aceitação será exi- bida no dispositivo cliente A 710. Uma vez que os dispositivos clientes A e B têm os dados de conexão uns dos outros, os dispositivos clientes A e B têm informações suficientes para estabelecer uma conexão P2P direta.

Deste modo, na operação 11A, os dispositivos clientes A e B estabelecem uma conexão P2P direta usando os dados de conexão trocados.

A conexão P2P direta pode ser estabelecida através de mecanismos conhecidos (por exem- plo, usando o Estabelecimento de Conectividade de Internet (ICE) ou outros mecanismos de conectividade P2P conhecidos). Entretanto, se o serviço de convite 620 determinar que a cone- xãoP2P direta é impraticável, então, este transmite uma solicitação de pes- quisa de retransmissão na operação 10B para o serviço de retransmissão 650 determinar um ou mais hosts de retransmissão para os dispositivos cli-

| 39/86 entes A e B para uso para a conexão.

A solicitação de pesquisa de retrans- missão pode conter as informações de rede para os dispositivos clientes A e B (por exemplo, dados NAT traversal/de conexão e/ou dados do tipo NAT) que são usadas pelo serviço de retransmissão 650 para selecionar os hosts deretransmissão para ambos os dispositivos clientes.

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, múltiplos hosts de retransmissão 815A-B, e um banco de dados de host de retransmissão 810 que contém informações de rede relacionadas a cada um dos hosts de retransmissão 815A-B.

Embora a figura 8 ilustre dois hosts de retransmissão, deve-se entender que podem existir mais ou menos hosts 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 host de retransmissão 810 usando as informações de rede para os dispositivos clientes A e B.

Me- diante o recebimento dos resultados de banco de dados, o módulo de pes- ó quisa de retransmissão 805 proporciona uma resposta que identifica os hosts de retransmissão selecionados 815A-B na operação 11B para o servi- h ço de convite 620. 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 pelos endereços de rede (endereços/portas IP) dos hosts de retrans- missão selecionados 815A-B para serem usados pelos dispositivos clientes A e B para a conexão de retransmissão.

Em uma modalidade, o token de retransmissão é associado à sessão de retransmissão e é usado pelos hosts de retransmissão 815A-B para autenticar os dispositivos clientes A e B me- diante a conexão com o serviço de retransmissão 650. O token pode assu- mir diversas formas que incluem, por exemplo, código de ID de sessão de retransmissão de ID exclusivo, um certificado digital e/ou uma chave de crip- tografia exclusiva associada à sessão de retransmissão.

O serviço de convite 620 transmite uma resposta de retransmis- são para os dispositivos clientes A e B que indicam que uma conexão de DD eee

' 40/86 retransmissão será efetuada. Em uma modalidade, a resposta de retrans- missão para o dispositivo cliente B pode incluir o token de retransmissão e as informações de rede para o host de retransmissão 815B. Em uma moda- lidade, a resposta para o dispositivo cliente B pode ser diretamente enviada (ignorando o serviço de notificação por push 640) porque esta está sendo enviada em resposta à mensagem de aceitação de convite do dispositivo cliente B. O serviço de convite 620 também transmite uma resposta de re- transmissão para o dispositivo cliente A, que pode incluir o token de re- transmissão e as informações de rede para o host de retransmissão A 815A. Á Nesta instância, a resposta é avançada para o dispositivo cliente A através do serviço de notificação por push 640.

Na operação 12B, o dispositivo cliente A 710 usa as informações de rede para o host de retransmissão 815A estabelecer uma conexão com o . serviço de retransmissão 650. De maneira similar, na operação 13B, o dis- positivo cliente B 720 usa as informações de rede para o host de retransmis- são 815B estabelecer uma conexão com o serviço de retransmissão 650.

. Em cada uma destas transações, novos orifícios são abertos em quaisquer NAT firewalls dos dispositivos clientes A e B e os dados de NAT transver- ' sal/de conexão para os dispositivos clientes A e B podem ser determinados pelo serviço de retransmissão 650 e retornados para os dispositivos clientes A e B, respectivamente (por exemplo, determinando-se o IP/porta pública para os dispositivos). Em uma modalidade, o serviço de retransmissão 650 e os dispositivos clientes A e B implementam o protocolo Traversal Usando o Relé NAT ("Volta"), que, conforme entendido por aqueles versados na técni- ca,permite que um elemento atrás de um NAT ou firewall receba dados de entrada através de conexões TCP ou UDP.

Na operação 14B, o dispositivo cliente A 710 transmite uma atu- alização de retransmissão para o serviço de convite 620, que é encaminha- da para o serviço de notificação por push e avançada para o dispositivo cli- enteB720na operação 17B. De maneira similar, na operação 15B, o dispo- sitivo 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 por push Um mm 41/86 620 e avançada para o dispositivo cliente A 610 na operação 16B. A atuali- zação de retransmissão transmitida pelo dispositivo cliente A 710 pode inclu- ir um token de sessão, cada identificador de ponto de extremidade de ses- são de comunicação online do dispositivo, e os dados NAT traversal/de co- nexão determinados pelo serviço de retransmissão 650.

Na operação 18B e 19B, os dispositivos clientes A e B, estabe- lecem, respectivamente, uma sessão de comunicação online conexão atra- vé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 enviaosdados NAT traversal/de conexão do dispositivo cliente B 720 para o serviço de retransmissão 650, e vice versa, permitindo, deste modo, que o serviço de retransmissão determine o caminho correto para cada host de retransmissão do ponto 815A-B.

. Usando as técnicas descritas acima, o serviço de convite 620 pode ser implementado como um serviço sem estado, que é inerentemente escalonável e resiliente, mesmo em um sistema de larga escala com um : vasto número de dispositivos clientes. Por exemplo, devido ao fato de o ser- viço de notificação por push 640 ser inerentemente capaz de localizar e a- ' vançar o conteúdo para os dispositivos clientes registrados, o serviço de convite620 não é requerido para rastrear a localização atual de cada dispo- sitivo. De maneira adicional, devido ao fato de os dispositivos poderem transmitir os dados NAT traversal/de conexão com solicitações e respostas, o serviço de convite 620 nunca é requerido para manter quaisquer informa- ções de estado por conexão reduzindo, deste modo, os requisitos de arma- zenamento e processamento do serviço de convite. Tal implementação é particularmente útil em um sistema de larga escala.

Embora a figura 7 descreva um usuário em um dispositivo clien- te que convida um único usuário para uma sessão de comunicação online, as modalidades não são tão limitadas. Por exemplo, em algumas modalida- des, 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 única mensagem de solicitação de convite para o serviço de UummmDmmm—m——n mr 42/86 convite com múltiplos identificadores de ponto de extremidade de sessão de comunicação online para convidar múltiplos usuários em diferente dispositi- vos clientes para participar de uma sessão de comunicação online.

Em algumas situações, um usuário pode ter múltiplos dispositi- vos clientes que são associados ao mesmo identificador de ponto de extre- midade de sessão de comunicação online. A figura 26 é um diagrama de fluxo de dados que ilustra operações exemplificativas para gerenciar convi- tes quando um usuário tiver múltiplos dispositivos clientes que são associa- dos ao mesmo identificador de ponto de extremidade de sessão de comuni- cação online.

O dispositivo cliente A (operado pelo usuário A) 2610 transmite uma solicitação para 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 ' os dados de conexão do dispositivo cliente A na operação 2634. O dispositi- vocliente, então, transmite uma solicitação de convite de sessão de comuni- É cação online para o serviço de convite 620 com um ID de usuário B para ' convidar o usuário B para uma sessão de comunicação online (por exemplo, uma videoconferência P2P, uma sessão de mensagens instantâneas P2P, ' uma chamada de vídeo etc.). A solicitação de convite inclui os dados de co- nexãodeaA. .

O serviço de convite realiza uma pesquisa de diretório na opera- ção 2638 com base no ID de B incluído na mensagem de solicitação de con- vite. Neste exemplo, a operação de pesquisa de diretório retorna um push token para o dispositivo cliente B1 e um push token para o dispositivo cliente B2.Destemodo, os dispositivos clientes B1 e B2 são associados ao 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 por push 640 para a- vançar as mensagens de solicitação de convite para o dispositivo cliente B1 2615 e o dispositivo cliente B2 2620. O serviço de notificação por 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 VR——&————

mr 43/86

2644. Cada mensagem de solicitação de convite inclui os dados de conexão do dispositivo cliente A 2610, o identificador de ponto de extremidade de sessão de comunicação online usado pelo usuário A, e o push token do dis- positivo cliente A 2610. As solicitações de convites também podem incluir informações específicas para a sessão de comunicação online (por exemplo, o nome da pessoa que envia o convite (por exemplo, nome de usuário, no- me real, número de telefone ou alguma combinações destes), para que o convite serve (por exemplo, uma videoconferência P2P, uma sessão de mensagens instantâneas P2P etc.) etc.). Deste modo, uma solicitação de convitede sessão de comunicação online é enviada para cada um dos dis- positivos que são associados ao identificador de ponto de extremidade de sessão de comunicação online incluído na solicitação de convite original. Em uma modalidade, o serviço de convite 620 transmite uma ' mensagem de estado para o dispositivo cliente de convite para indicar para qual dispositivo cliente o convite foi transmitido. Deste modo, na operação 2646, o serviço de convite 620 transmite um convite atualização de estado : 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 disposítivo cliente B1 " 2615 e o dispositivo cliente B2 2620. Em uma modalidade, o dispositivo cli- “20 enteA 2610 rastreia quais dispositivos clientes aceitaram o convite e man- tém os outros dispositivos clientes informados sobre o estado da sessão de comunicação online. Em uma modalidade, o dispositivo cliente B1 2615 e o dispositi- vo cliente B2 2620 irão exibir uma solicitação de convite se eles estiverem ligados e forem 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. Deste modo, 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 clienteB1 2615 e na operação 2650 retorna os mesmos para o dispositivo cliente B1 2615. O dispositivo cliente B1 2615, então, transmite uma mensagem VUR—n e 44/86 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 push token do dispositivo cliente A 2610. A mensagem de aceitação também pode conter uma indicação se esta é uma repetição de uma tentativa de co- nexãoP2P direta de falha anterior entre o dispositivo cliente A 2610 e o dis- positivo cliente B1 2615. Além disso, a mensagem de aceitação também po- de incluir os identificadores de ponto de extremidade de sessão de comuni- cação online de A e B e o push token para o dispositivo cliente B 2615. Em algumas modalidades, após receber uma mensagem de a- ceitação para uma sessão de comunicação online, o serviço de convite 620 determina se uma conexão P2P direta é praticável. Deste modo, na opera- ção 2654, o serviço de convite 620 realiza uma verificação de compatibilida- de P2P direta para determinar se uma conexão P2P direta entre o dispositi- vo cliente A 2610 e o dispositivo cliente B1 2615 é praticável, de uma manei- ra similar, conforme previamente descrito. Se os dispositivos clientes forem compatíveis com uma conexão P2P direta, então, as operações descritas : com referência à figura 27 (iniciando na operação 2710) são realizadas. Se os dispositivos clientes não forem compatíveis com uma conexão P2P direta, ' então, as operações descritas com referência à figura 28 (iniciando na ope- ração2810)são realizadas.

Com referência à figura 27, que ilustra as operações realizadas quando uma conexão P2P direta for 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 por push 640 para transmitir a aceitação do convite pelo dispositivo cli- ente B1 2615. Na operação 2712, o serviço de notificação por 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. Esta mensagem de aceitação inclui os dados de conexão e o push token do dis- positivo cliente B1 2615, e o identificador de ponto de extremidade de ses- sãode comunicação online usado pelo usuário B.

Em uma modalidade, algum tempo após receber a mensagem de aceitação que indica que o dispositivo cliente B1 2615 aceitou o convite, Van o 45/86 o dispositivo cliente A 2610 informa ao dispositivo cliente B2 2620 que o dis- positivo cliente A 2620 aceitou o convite. Deste modo, na operação 2714, o dispositivo cliente A 2610 transmite uma solicitação de atualização de convi- te para o serviço de convite que inclui o identificador de ponto de extremida- dede 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 que o disposi- tivo cliente associado ao identificador de ponto de extremidade de sessão de comunicação online do usuário B deve receber a mensagem de atualização de convite (neste exemplo, o dispositivo cliente B2 2620 deve receber a mensagem de atualização de convite). O serviço de convite 620 realiza uma pesquisa de diretório 2716 com base no identificador de ponto de extremidade de sessão de comunica- ' ção online do usuário B para determinar o push token do dispositivo cliente B22620. Após determinar o push token, o serviço de convite transmite uma solicitação de push na operação 2718 para o serviço de notificação por push . 640 para avançar a mensagem de atualização de convite para o dispositivo cliente B2 2620. Na operação 2720, o serviço de notificação por push 640 fi transmite uma mensagem de atualização de convite, na forma de a mensa- gemde 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 po- de exibir a mensagem de atualização de convite e pode manter o estado da sessão de comunicação online entre o dispositivo cliente A 2610 e o disposi- tivo cliente B1 2615 (por exemplo, a duração da sessão de comunicação online etc.). Conforme será descrito em maiores detalhes com referência à figura 30, em uma modalidade, o dispositivo cliente B2 2620 pode transmitir uma solicitação de transferência que faz com que a sessão de comunicação online transfira do dispositivo cliente B1 2615 para o dispositivo cliente B2

2620. Algum tempo após receber a mensagem de aceitação de convite na operação 2712, o dispositivo cliente A 2610 e o dispositivo cliente B1 Van nm 46/86 2615 estabelecem uma conexão P2P direta usando os dados de conexão trocados na operação 2722. A conexão P2P direta pode ser estabelecida através de mecanismos conhecidos (por exemplo, usando o Estabelecimen- to de Conectividade de Internet (ICE) ou outros mecanismos de conectivida- deP2P conhecidos). Deve-se entender que a operação 2722 pode ser reali- zada antes ou durante as operações 2714-2720.

Embora a figura 26 descreva um exemplo onde apenas um úni- co dispositivo cliente aceite a mensagem de convite, em algumas situações, múltiplos dispositivos clientes podem aceitar um convite para uma sessão de comunicação online direcionada a um único usuário. Por exemplo, o disposi- tivo 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 a partir do qual este recebe uma mensagem de aceitação. O disposi- tivo cliente A 2610 pode fazer com que uma mensagem de cancelamento í seja enviada para o outro dispositivo cliente (por exemplo, a mensagem de ' cancelamento pode ser transmitida para o serviço de convite e, então, avan- çada, através do serviço de notificação por push, para outros dispositivos ' clientes).

Referindo-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 realizadas. A figura 28 é um diagrama de fluxo de dados que ilustra opera- ções exemplificativas que são realizadas quando uma conexão P2P direta for 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 retransmis- são 650 determinar que um host de retransmissão seja usado pelo dispositi- vo 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 NAT traversal/de conexão e/ou tipos de dados NAT) que são usados pelo serviço de retransmissão 650 para selecionar os hosts de retransmissão apropriados para os dispositivos clientes. Conforme Van

NE, 47/86 ilustrado na figura 8, uma modalidade do serviço de retransmissão 650 inclui uma pluralidade de hosts de retransmissão 815A-B e um banco de dados de host de retransmissão 810 que contém informações de rede relacionadas a cada dos hosts de retransmissão. Por exemplo, o serviço de convite 620 transmite uma solicitação de pesquisa de retransmissão para um serviço de retransmissão 650, que consulta o banco de dados de host de retransmissão 810 usando as informações de rede para os dispositivos clientes. Mediante o recebimento dos resultados de pesquisa de banco de dados, o serviço de retransmissão 650 proporciona uma resposta de pesquisa de retransmissão na operação 1201 que identifica os hosts de retransmissão selecionados 815A-B. Em uma modalidade, a resposta de pesquisa de retransmissão con- tém um token de retransmissão gerado pelo serviço de retransmissão 650 e os endereços de rede (endereços/portas IP) dos hosts de retransmissão ' 815A-B a serem usados pelos dispositivos clientes para a conexão de re- transmissão. Em uma modalidade, o token de retransmissão é associado à sessão de retransmissão e é usado pelos hosts de retransmissão 815A-B ' para autenticar o dispositivo cliente A 2610 e o dispositivo cliente B1 2615 ao se conectar ao serviço de retransmissão 650. O token pode assumir diversas í formas que incluem, por exemplo, código de ID de sessão de retransmissão delD exclusivo, um certificado digital e/ou uma chave de criptografia exclu- siva associada à sessão de retransmissão.

O serviço de convite 620, então, transmite uma resposta de re- transmissão para o dispositivo cliente B1 2615 na operação 2814 que con- tém uma indicação que uma conexão de retransmissão será efetuada. Em uma modalidade, a resposta de retransmissão pode incluir o token de re- transmissão e as informações de rede para o host de retransmissão selecio- nado para o dispositivo cliente B1 2615. Em uma modalidade, a resposta de retransmissão pode ser enviada diretamente para o dispositivo cliente B1 2615 (ignorando o serviço de notificação por 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 o host de retransmissão selecionado para o dispo- Uummm—

[— 48/86 sítivo cliente A 2610. Em algumas modalidades, a resposta de retransmissão é avançada para o dispositivo móvel A através do serviço de notificação por push 640. 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 de extremidade de sessão de comunicação online do usuário B e indica que o dispositivo cliente B1 2615 aceitou o con- vite.

A solicitação de atualização de convite também pode instruir ou indicar para o serviço de convite 620 que o dispositivo cliente associado ao identifi- cadorde ponto de extremidade de sessão de comunicação online do usuário B deve receber uma mensagem de atualização de convite (neste exemplo, o dispositivo cliente B2 2620 deve receber uma mensagem de atualização de convite). O serviço de convite 620 realiza uma pesquisa de diretório 2820 baseada no identificador de ponto de extremidade de sessão de comunica- ção online do usuário B para determinar o push token do dispositivo cliente . B2 2620. Após determinar o push token, o serviço de convite transmite uma solicitação de push na operação 2822 para o serviço de notificação por push ' 640 para avançar a mensagem de atualização de convite para o dispositivo cliente B2 2620. Na operação 2824, o serviço de notificação por push 640 transmite uma mensagem de atualização de convite, na forma de uma men- sagem de notificação de push, para o dispositivo cliente B2 2620. A mensa- gem de atualização de convite indica que o dispositivo cliente B1 2615 acei- tou 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 o estado 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 comuni- cação online etc.). Em uma modalidade, o dispositivo cliente B2 2620 pode transmitir uma solicitação de transferência que faz com que uma sessão de comunicação online transfira do dispositivo cliente B1 2615 para o dispositi- vo cliente B2 2620. Na operação 2826, o dispositivo cliente A 2610 usa as informa- Van mn 49/86 ções de rede para seu host de retransmissão selecionado 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 seu host de retransmissão selecionado estabelecer uma conexão com o serviço deretransmissão 650. Em cada destas operações, novos orifícios podem ser abertos em quaisquer firewalls NAT dos dispositivos clientes e os dados NAT traversal/de conexão para os dispositivos clientes podem ser determi- nados pelo serviço de retransmissão 650 e retornados para os mesmos (por exemplo, determinando-se o IP/porta pública 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 implementam o protocolo Traversal U- sando o Relé NAT ("Volta") que, conforme entendido por aqueles versados na técnica, permitem que um elemento atrás de um NAT ou firewall receba

' . dados de entrada através de conexões TCP ou UDP.

Na operação 2830, o dispositivo cliente A 2610 transmite uma atualização de retransmissão para o serviço de convite 620 que é encami- ' nhado para o serviço de notificação por push na operação 2832 e avançada 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 é encaminhado para o ser- viço de notificação por push 640 na operação 2838 e avançada para o dis- positivo cliente A 2610 na operação 2840. A atualização de retransmissão mensagem 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 NAT traversal/de conexão determinados pelo serviço de retransmis- são 650 nas operações 2826 e 2828. Em uma modalidade, as operações de atualização de retransmissão são realizadas uma vez que uma ou mais in- formações NAT do dispositivo cliente podem ser alteradas.

Finalmente, nas operações 2842 e 2844, o dispositivo cliente A 2610 e o dispositivo cliente B12620 estabelecem respectivamente 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 disposítivo cliente A 2610 que VUR—

UN 50/86 transmite os dados NAT traversal/de conexão do dispositivo cliente B1 2615 para o serviço de retransmissão 650, e vice versa, permitindo, deste modo, que o serviço de retransmissão 650 determine o caminho correto para cada host de retransmissão do ponto.

A figura 29 é um fluxograma de dados que ilustra operações e- xemplificativas realizadas quando uma sessão de comunicação online encer- ra, de acordo com uma modalidade. Na operação 2910, a sessão de comu- nicação online entre o dispositivo cliente A 2610 e o dispositivo cliente B1 2615 encerrou. Por exemplo, 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 terminada de outro modo). A sessão de comunicação online pode ser através de uma conexão P2P direta ou através de um relé.

Algum tempo após a sessão de comunicação online ter encerra- f do, 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 ' o dispositivo cliente B2 2620, que não era 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 o 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) irá receber a atualização.

O serviço de convite 620 realiza uma operação de pesquisa de diretório 2914 baseada no identificador de ponto de extremidade de sessão de comunicação online do usuário B para determinar o push token do dispo- sitivo cliente B2 2620. Após determinar o push token, o serviço de convite transmite uma solicitação de push na operação 2916 para o serviço de noti- ficação por push 640 para avançar a mensagem de atualização para o dis- positivo cliente B2 2620. Na operação 2720, o serviço de notificação por pu- —sh640 transmite uma mensagem de atualização de sessão de comunicação online, na forma de uma mensagem de notificação de push, para o dispositi- vo cliente B2 2620. A mensagem de atualização de sessão de comunicação VUm—n

[mr 51/86 online indica que a sessão de comunicação online entre o dispositivo cliente A 2910 e o dispositivo cliente B1 2615 encerrou.

A figura 30 é um fluxograma que ilustra operações exemplificati- vas realizadas para transferir uma sessão de comunicação online a partir de um dispositivo cliente para outro dispositivo cliente, de acordo com uma mo- dalidade. No exemplo ilustrado na figura 30, supõe-se que cada dos disposi- tivos clientes B1 2615 e B2 2620 recebeu um convite para uma sessão de comunicação online originada pelo dispositivo cliente A 2610 (cada um deles compartilha o identificador de ponto de extremidade de sessão de comuni- "cação online que foi usado no convite) e o dispositivo cliente B1 2615 acei- tou e estabeleceu uma sessão de comunicação online com o dispositivo cli- ente A 2610 (conforme descrito nas figuras 26 e 27 ou 28). Além disso, o dispositivo cliente B2 2620 recebeu uma 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 a partir do dispo- sitivo cliente B1 2615 para o dispositivo cliente B2 2620. Por exemplo, um . usuário no dispositivo cliente B2 2620 indicou que este deseja assumir a sessão de comunicações online entre os dispositivos clientes A 2610 e o " dispositivo cliente B1 2620. Em uma modalidade, o aplicativo de sessão de comunicação online 2115 exibe um estado da sessão de comunicação onli- ne entre o dispositivo cliente A 2610 e o dispositivo cliente B1 2615 que permite que um usuário no dispositivo cliente B2 2620 emita uma solicitação de sessão de comunicação online de transferência (por exemplo, através de um clique ou pressionamento de um link ou botão virtual disponível no apli- cativo de sessão de comunicação online 2115 do dispositivo cliente B1 2615).

Na operação 3010, o dispositivo cliente B2 2620 solicita seus dados de conexão a partir da troca de dados de conexão 610 e recebe os dados de conexão solicitados na operação 3012 (se esta ainda não conhe- cerseus dados de conexão). O dispositivo cliente B2 2620, então, transmite uma mensagem de solicitação de transferência na operação 3014 para o serviço de convite 620 que inclui o push token do dispositivo cliente A 2610 e

VU

ENA 52/86 os dados de conexão do dispositivo cliente B2 2620. A mensagem de solici- tação de transferência também pode incluir os identificadores de ponto de extremidade de sessão de comunicação online de A e/ou B e/ou o push to- ken para o dispositivo cliente A 2610.

O serviço de convite 620, então, transmite uma solicitação de push para o serviço de notificação por push 640 na operação 3016 que faz com que o serviço de notificação por push 640 transmita a mensagem de transferência, na forma de uma notificação de push, para o dispositivo clien- te A 2610. O serviço de convite 620 também realiza uma verificação de compatibilidade P2P direta na operação 3018 para determinar se uma cone- xão P2P direta entre o dispositivo cliente A 2610 e o dispositivo cliente B2 2620 é praticável. Para os propósitos deste exemplo, uma conexão direta é praticável, entretanto, deve-se entender que uma transferência de sessão de É comunicação online também pode ocorrer em uma situação de retransmis- são.

Á Na operação 3020, o serviço de notificação por 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 o identificador de ' ponto de extremidade 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 é, o 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 push token do dispositivo cliente B2 2620). A mensagem de solicitação de transferência pode fazer com que o aplicativo 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 e negue a solicitação de transferência. Supondo que a solici- tação de transferência seja aceita, o disposítivo cliente A 2610 estabelece uma conexão P2P direta com o dispositivo cliente B 2620 usando os dados de conexão trocados na operação 3022. Deve-se entender que, neste ponto, a sessão de comunicação online entre o dispositivo cliente A 2610 e o dis- positivo cliente B1 2615 é ativa. O dispositivo cliente A 2610, então, transmi-

nm 53/86 te uma atualização de sessão de comunicação online para o dispositivo cli- ente B1 2615 que indica que a sessão de comunicação online irá transferir para o dispositivo cliente B2 2620. Em uma modalidade, esta mensagem de atualização é transmitida na sessão de comunicação online existente entre os dispositivos clientes. O dispositivo cliente A 2610, então, muda para a sessão de comunicação online com o dispositivo de cliente B2 2620 na ope- ração 3026 e derruba a sessão de comunicação online com o dispositivo cliente B1 2615 na operação 3028. Embora as modalidades tenham sido descritas com referência ao convite de um único usuário para uma sessão de comunicação online (que pode ou não ser associada a múltiplos dispositivos clientes), em algu- mas modalidades, múltiplos usuários podem ser convidados para uma ses- são de comunicação online. A figura 31 é um fluxograma que ilustra opera- ' ções exemplificativas para iniciar e estabelecer uma sessão de comunicação onlinecom múltiplos usuários. O dispositivo cliente 3110 solicita seus dados de conexão a par- R tir da troca de dados de conexão 610 na operação 3132 e os dados de co- nexã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 convite620 que inclui os dados de conexão do dispositivo cliente A 3110, um identificador de ponto de extremidade de sessão de comunicação online associado ao usuário B e um identificador de ponto de extremidade de ses- são de comunicação online associado ao usuário C. Deste modo, um usuá- rio no dispositivo cliente A 3110 convida múltiplos usuários para uma sessão de comunicação online.

O serviço de convite 620 realiza uma operação de pesquisa de diretório 3138 para determinar os push tokens associados ao identificador de ponto de extremidade de sessão de comunicação online do usuário B e ao identificador de ponto de extremidade de sessão de comunicação online do usuário C. Neste 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 de extremidade de sessão de comunicação online Un

A 54/86 do usuário B e do dispositivo cliente C 3120 que é associado ao identificador de ponto de extremidade de sessão de comunicação online do usuário C. O serviço de convite 620 então transmite uma solicitação de push 3140 para o serviço de notificação por push 640 para solicitar que o serviço de notifica- ção por push 640 transmita os convites, na forma de push mensagens, para os dispositivos clientes B e C. O serviço de notificação por push 640, então, transmite a solicitaçã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 de extremidade de sessão de comunicação online usado pelo usuário A, e o push token do dispositivo cliente A 3110. Em uma modalidade, o serviço de convite 620 transmite uma f mensagem de estado para o dispositivo cliente convidado que indica para — 15 quais dispositivos clientes o convite foi transmitido. Deste modo, na opera- ção 3146, o serviço de convite 620 transmite um convite atualização de es- ' tado 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 cli- ' ente B 3115 e o dispositivo cliente C 3120. Em uma modalidade, o dispositi- voclienteB3115e o dispositivo cliente C 3120 irão exibir uma solicitação de convite se eles estiverem ligados e capazes de receber a solicitação de con- vite. No exemplo ilustrado na figura 31, cada um dos convites será aceito. Deste modo, na operação 3148, o dispositivo cliente B 3115 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 3115 e, na operação 3150, retorna os mesmos para o dispositivo cliente B 3115. De maneira similar, o dispositivo cliente C 3120 solicita seus dados de conexão a partir 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, retorna os mesmos para o dispositivo cliente C 3120. O dispositivo cliente B 3115, então, transmite uma Van n— 55/86 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, então, realiza uma verificação de compatibilidade P2P direta 3160 que determina seaconexãoP2P direta é praticável entre o dispositivo cliente A 3110e o dispositivo cliente B 3115, e entre o dispositivo cliente A 3110 e o dispositivo cliente C 3120. Para os propósitos deste exemplo, uma conexão P2P direta é praticável entre os dispositivos clientes. Deste modo, usando os 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 estabelece uma conexão P2P direta para a sessão de comunicação online na operação 3164. Neste exemplo, o dispositivo cliente A 3110 atua f basicamente como o host da sessão de comunicação online. Deste modo, osdados que são transmitidos entre o dispositivo cliente B 3115 e o disposi- tivo 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, outra conexão P2P pode ser estabelecida en- " tre o dispositivo cliente B 3115 e o dispositivo cliente C 3120.

Embora as modalidades descritas no presente documento des- crevam um mecanismo para registrar dispositivos clientes para sessões de comunicação online, em algumas modalidades, o registro 140 pode imple- mentar uma API para permitir que diferente aplicativos registrem o identifica- dor de ponto de extremidade de sessão de comunicação online e push to- kens.A API implementada em uma modalidade, é uma interface implemen- tada por um componente de software (daqui por diante no presente docu- mento, "componente de software de implementação de API") que permite que um componente de software diferente (daqui por diante no presente do- cumento, "componente de software de chamada de API") acesse e use uma ou maisfunções, métodos, procedimentos, estruturas de dados, e/ou outros serviços proporcionados pelo componente de software de implementação de API. Por exemplo, uma API permite que um desenvolvedor de um compo- Van na 56/86 nente de software de chamada de API (que pode ser um desenvolvedor ter- ceirizado) otimize os recursos específicos proporcionados por um compo- nente de software de implementação de API.

Pode existir um componente de software de chamada de API ou mais de um componente de software.

Uma API pode ser uma interface de código-fonte que um sistema de compu- tador ou biblioteca de programa proporciona, a fim de suportar solicitações para serviços a partir de um aplicativo de software.

Uma API pode ser espe- cificada em termos de uma linguagem de programação que pode ser inter- pretativa ou compilada quando um aplicativo for desenvolvido, em vez de uma descrição de nível baixo explicita de como os dados são dispostos na memória.

A API define a linguagem e os parâmetros que os componentes de software de chamada de API usam quando acessam e usam recursos f específicos do componente de software de implementação de API.

Por e- 2 15 xemplo, um componente de software de chamada de API acessa os recur- sos específicos do componente de software de implementação de API atra- . vés de uma ou mais chamadas de API (algumas vezes referidas como cha- madas de função ou método) expostas pela API.

O componente de software " de implementação de API pode retornar um valor através da API em respos- taauma chamada de API a partir de um componente de software de cha- mada 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 o que a chamada de API faz), a API tipicamente não revela como a chamada de AP! realiza a função especificada pela chamada de API.

Diversas chamadas ou mensa- gens de função são transferidas através de uma ou mais interfaces de pro- gramação de aplicativo entre o software de chamada (componente de soft- ware de chamada de API) e um componente de software de implementação de API.

A transferência das chamadas ou mensagens de função pode incluir emitir, iniciar, invocar, chamar, receber, retornar ou responder as chamadas oumensagens de função.

Portanto, um componente de software de chama- da de API pode transferir uma chamada e um componente de software de implementação de API pode transferir uma chamada.

Vu

SN 57/86 Por meio de exemplo, o componente de software de implemen- tação de API e o componente de software de chamada de API podem ser um sistema de operação, uma biblioteca, um driver de dispositivo, uma API, um programa aplicativo, ou outro módulo de software (deve-se entender que o componente de software de implementação de API e o componente de software de chamada de API podem ser do mesmo tipo ou de um tipo de módulo de software diferente uns dos outros). O componente de software de chamada de API pode ser um componente de software local (isto é, no mesmo sistema de processamento de dados que o componente de software de implementação de API) ou um componente de software remoto (isto é, em um sistema de processamento de dados diferente do componente de software de implementação de API) que se comunica com o componente de software de implementação de API através da API ao longo de uma rede.

' Deve-se entender que um componente de software de implementação de . 15 API também pode atuar como um componente de software de chamada de API (isto é, este pode efetuar chamadas de API em uma API exposta por um ' componente de software de implementação de API diferente) e um compo- nente de software de chamada de API também pode atuar como um compo- Á nente de software de implementação de API através da implementação de uma API que é exposta a um componente de software de chamada de API diferente.

A API pode permitir que múltiplos componentes de software de chamada de API gravados em linguagens de programação diferentes se comuniquem com o componente de software de implementação de API (des- temodo, a API pode incluir recursos para traduzir chamadas e retornos entre o componente de software de implementação de API e o componente de software de chamada de API); entretanto, a API pode ser implementada em termos de uma linguagem de programação específica.

A figura 9 ilustra uma modalidade de uma arquitetura API que inclui um componente de software de implementação de API 910 (por exem- plo, um sistema de operação, uma biblioteca, um driver de dispositivo, uma API, um programa aplicativo, ou outro módulo de software) que implementa UupDmmEmD—E—m—m—

E 58/86 a API 920. A API 920 específica uma ou mais funções, métodos, classes, objetivos, protocolos, estruturas de dados, formatos e/ou outros recursos do componente de software de implementação de API que podem ser usados pelo componente de software de chamada de API 930. A API 920 pode es- pecificar pelo menos uma convenção de chamada que específica como uma função no componente de software de implementação de API recebe os pa- râmetros do componente de software de chamada de API e como a função retorna um resultado para o componente de software de chamada de API.

O componente de software de chamada de API 930 (por exemplo, um sistema de operação, uma biblioteca, um driver de dispositivo, uma API, um progra- ma aplicativo, ou outro módulo de software), faz chamadas de APIs através da API 920 para acessar e usar os recursos do componente de software de implementação de API 910 que são especificados pela API 920. O compo- ar nente de software de implementação de API 910 pode retornar um valor a- — 15 través da API 920 para o componente de software de chamada de API 930 em resposta a uma chamada de API. e Será avaliado que o componente de software de implementação de API 910 pode incluir funções, métodos, classes, estruturas de dados, " e/ou outros recursos adicionais que não são especificados através da API 920e não são disponíveis para o componente de software de chamada de API 930. Deve-se entender que o componente de software de chamada de API 930 pode se encontrar no mesmo sistema que o componente de softwa- re de implementação de API 910 ou pode ser remotamente localizado e a- cessar o componente de software de implementação de API 910 usando a API 920 ao longo de uma rede.

Embora a figura 9 ilustre um único compo- nente de software de chamada de API 930 que interage com a API 920, de- ve-se entender que outros componentes de software de chamada de API, que podem ser gravados em linguagens diferentes (ou na mesma lingua- gem) do componente de software de chamada de API 930, podem usar a

APIS2O.

O componente de software de implementação de API 910, a API 920, e o componente de software de chamada de API 930 podem ser arma- uppmmm—

mm 59/86 zenados 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, óticdis- cosóticos, memória de acesso aleatório; memória somente leitura, dispositi- vos de memória flash etc. Transição entre Chamadas Comutadas por Circuito e Chamadas de Vídeo Em algumas modalidades, um dispositivo cliente pode mudar de uma chamada comutada por circuito apenas de áudio estabelecido para uma chamada de vídeo sem interromper significativamente a comunicação entre as partes. Por exemplo, uma parte de uma chamada comutada por circuito apenas de áudio estabelecido seleciona a transição para uma chamada de vídeo (que inclui quadros de áudio e vídeo), que faz com que uma mensa- É gem de iniciação de chamada de vídeo (uma forma de uma mensagem de 2 15 convite de sessão de comunicação online) seja enviada para outros partici- pantes da chamada. Se os outros participantes aceitam o convite de chama- I da de vídeo, uma conexão P2P será estabelecida entre os dispositivos clien- tes do participante. Enquanto a conexão P2P está sendo negociada, os par- ii ticipantes são capazes de se comunicar através da chamada comutada por circuito apenas de áudio. Após a conexão P2P ser estabelecida e o vídeo ser comunicados entre as partes, os dispositivos clientes mudam para a chamada de vídeo, A chamada comutada por circuito apenas de áudio, en- tão, é ignorada, e os participantes são capazes de se comunicar através da chamada de vídeo.

A figura 12 ilustra um dispositivo cliente exemplificativo 1210 e uma interface gráfica de usuário que são usados para mudar entre chama- das comutadas por circuito e chamadas de vídeo, de acordo com algumas modalidades. O dispositivo cliente 1210 inclui o alto-falante 1255 (que é u- sado durante o modo viva-voz), câmera de frente 1260 (que captura o vídeo usado para a chamada de vídeo), microfone 1265 (que captura o som), o receptor/alto-falante 1270 (que é tipicamente usado quando o usuário segura o dispositivo cliente 1210 em sua orelha durante a chamada), e a tela de Un

EN 60/86 exibição 1275 (que é uma tela sensível ao toque em algumas modalidades). O dispositivo cliente 1210 também pode incluir um fone de ouvido/tomada para auricular, um sensor de proximidade, um sensor de luz ambiente, ace- lerômetros e outros componentes. Deve-se entender que a arquitetura do dispositivo cliente 1210 é exemplificativa e arquiteturas diferentes que inclu- em mais ou menos componentes podem ser usadas nas modalidades.

Conforme ilustrado na figura 12, a interface gráfica de usuário 1205 está sendo atualmente exibida na tela de exibição 1275. O usuário do dispositivo cliente 1210 está participando atualmente em uma chamada tele- fônica apenas de áudio (com o número de telefone (408) 555-1234). A inter- face gráfica de usuário 1205 inclui diversas opções diferentes para o usuário durante a chamada. Por exemplo, o dispositivo cliente 1210 realiza a seguin- te entrada de usuário de chamada responsiva a receptiva (por exemplo, to- ' que ou outros gestos predefinidos no ícone apropriado): encerra a chamada 2 15 quandoa entrada for aplicada ao ícone encerrar chamada 1250, desliga o som da chamada de áudio em resposta à entrada que é aplicada ao ícone . mudo 1220, exibe um teclado numérico (por exemplo, para adicionar núme- ros de telefone adicionais à chamada) em resposta à entrada que é aplicada ' ao ícone teclado numérico 1225, coloca a chamada em viva-voz em respos- taàentrada que é aplicada ao ícone alto-falante 1230 (que muda a saída de áudio para o alto-falante 1255), adiciona uma chamada em resposta à entra- da que é aplicada ao ícone adicionar chamada 1235, coloca a chamada em espera em resposta à entrada que é aplicada ao ícone espera 1240, exibe a lista de contato do usuário em resposta à entrada que é aplicada ao ícone contatos 1245, e muda para uma chamada de vídeo em resposta à entrada que é aplicada ao ícone de chamada de vídeo 1215.

As figuras 17-18 são fluxogramas que ilustram operações exem- plificativas para efetuar uma transição entre uma chamada comutada por circuito apenas de áudio para uma chamada de vídeo, de acordo com uma modalidade. As figuras 17-18 serão descritas com referência às modalidades exemplificativas das figuras 12, 13 e 14. Entretanto, deve-se entender que as operações das figuras 17-18 podem ser realizadas pelas modalidades da VUuDmmmmmm—n

SE. 61/86 invenção diferentes daquelas discutidas com referência às figuras 12, 13 e 14, e as modalidades discutidas com referência às figuras 12, 13 e 14 po- dem realizar operações diferentes daquelas discutidas com referência às figuras 17-18.

Conforme ilustrado na figura 17, os dispositivos clientes 1210 e 1410 são conectados através de uma chamada comutada por circuito ape- nas de áudio 1710 (o usuário do dispositivo cliente 1210 ou o usuário do dis- positivo cliente 1410 iniciou a chamada). Deste modo, os usuários do dispo- sitivo cliente 1210 e 1410 podem se comunicar através da chamada de áu- dio comutada por circuito estabelecido. No bloco 1712, o dispositivo cliente 1210 recebe a entrada para mudar para uma chamada de vídeo. Por exem- plo, o usuário selecionou a transição para uma chamada de vídeo ao tocar ou realizar outro gesto definido no ícone de chamada de vídeo 1215.

' O fluxo, então, se move até o bloco 1714, onde o dispositivo cli- ente 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 algu- : mas modalidades, a mensagem de solicitação de convite de sessão de co- municação online é enviada usando a arquitetura descrita nas figuras 6 e 7. O fluxo, então, se move até o bloco 1716.

No bloco 1716, o dispositivo cliente 1210 determina se o áudio está sendo presentemente roteado através do viva-voz (por exemplo, o alto- falante 1255) ou através do fone de ouvido/tomada para auricular. Em caso positivo, então, o fluxo se move até o bloco 1720. Em caso negativo, então, o fluxo se move até o bloco 1718, onde o dispositivo cliente 1210 roteia o áudio através do viva-voz do dispositivo cliente 1210 (por exemplo, o alto- falante 1255) e o fluxo se move até o bloco 1720.

No bloco 1720, o dispositivo cliente 1210 exibe uma visualização de vídeo de qual câmera de frente 1260 está capturando atualmente, para permitir que o usuário do dispositivo cliente 1210 prepare a chamada de ví- deo (por exemplo, posicionar apropriadamente o dispositivo cliente 1210 pa- Un

Ma 62/86 ra a chamada de vídeo). A figura 13 ilustra o dispositivo cliente 1210 que exibe a visualização de vídeo 1310 que exibe o vídeo de qual câmera de frente 1260 está capturando atualmente. Embora não ilustrado na figura 13, em algumas modalidades, um botão cancelar também é exibido na GUI 1305 que permite que o usuário cancele o convite de chamada de vídeo. O fluxo se move a partir do bloco 1720 até o bloco 1722.

No bloco 1726, o dispositivo cliente 1410 recebe uma mensa- gem 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 a partir do bloco 1726 até 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 viva-voz), câmera de frente 1460 (que ' captura o vídeo usado para a chamada de vídeo), microfone 1465 (que cap- 215 turao som), o receptor/alto-falante 1470 (que é tipicamente usado quando um usuário segura o dispositivo cliente 1210 em sua 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 ouvido/tomada para auricular, um sensor de proximidade, um sensor de luz ambiente, acelerômetros e outros componentes. Deve-se entender que a arquitetura do dispositivo cliente 1410 é exemplificativa e arquiteturas diferentes que incluem mais ou menos componentes podem ser usadas nas modalidades.

No bloco 1728, o dispositivo cliente 1410 toca um ou mais tons de áudio que indicam o recebimento da mensagem para alertar o usuário da mensagem. Os tons de áudio podem ser diferentes em modalidades diferen- tes (por exemplo, os tons de áudio podem ser similares aos tons de espera de chamada usados no dispositivo cliente 1410 (embora eles não sejam ori- ginados pela portadora associada 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 toca tons de áudio que . indicam o recebimento da mensagem de convite de chamada de vídeo se o nn er 63/86 dispositivo cliente 1410 não estiver próximo à orelha do usuário (por exem- plo, conforme indicado por um sensor de proximidade do dispositivo cliente 1410) e/ou se a chamada estiver atualmente no modo viva-voz. O fluxo se move a partir do bloco 1728 até o bloco 1730.

No bloco 1730, o dispositivo cliente 1410 exibe a mensagem de convite de chamada de vídeo e exibe opcionalmente uma visualização de vídeo de qual câmera de frente 1460 está capturando atualmente, para per- mitir que o usuário do dispositivo cliente 1410 se prepare para a chamada de vídeo, e o fluxo se move até o bloco 1732. A figura 14 ilustra a GUI 1405 que exibea convite de chamada de vídeo 1440. Conforme ilustrado na figura 14, a convite de chamada de vídeo 1440 inclui um botão aceitar 1432, um botão negar 1434, e a visualização de vídeo 1430 (que mostra qual câmera de frente 1460 está capturando atualmente). Embora a figura 1410 ilustre o f convite de chamada de vídeo 1440 que inclui a visualização de vídeo 1430 (ou seja, a visualização de vídeo 1430 é contida dentro do convite de cha- mada de vídeo 1440), em outras modalidades, a visualização de vídeo 1430 BR se situa fora e/ou sobrepõe o convite de chamada de vídeo 1440. O usuário do dispositivo cliente 1410 pode selecionar o botão aceitar 1432 para aceitar ' o convite de chamada de vídeo (por exemplo, ao tocar ou realizar outro ges- to predefinido para inserir o botão aceitar 1432) e pode selecionar o botão negar 1434 para negar o convite de chamada de vídeo (por exemplo, ao to- car ou realizar outro gesto predefinido para inserir o botão negar 1434). No bloco 1732, o dispositivo cliente 1410 determina se entrada foi recebida para aceitar a chamada de vídeo (por exemplo, se o usuário a- ceitou o convite de chamada de vídeo selecionando-se o botão aceitar 1432). Se o dispositivo cliente 1410 receber a entrada para aceitar a chama- da de vídeo, então, o fluxo se move até o bloco 1734, de outro modo, o fluxo se move até 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 parao dispositivo cliente 1210. Em algumas modalidades, a mensagem de aceitação é transmitida para o dispositivo cliente 1210 usando a arquitetura descrita nas figuras 6 e 7. O fluxo, então, se move até o bloco 1810. —

E 64/86 No bloco 1736, se determina se a entrada foi recebida para rejei- tar a solicitação de chamada de vídeo (por exemplo, se o usuário rejeitou o convite de chamada de vídeo selecionando o botão de negar 1434). Se o dispositivo cliente 1410 receber a entrada para negar o convite de chamada de vídeo, então, ofluxose move até 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 trans- miítida para o dispositivo cliente 1210. O dispositivo cliente 1410 também pode limpar o convite de chamada de vídeo 1440 e interromper a exibição da 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 usando a arquitetura descrita nas figuras 6 e 7.

No bloco 1722, o dispositivo cliente 1210 determina se este re- " cebeu uma mensagem de aceitação de chamada de vídeo a partir do dispo- sitivo cliente 1410. Em caso positivo, então, o fluxo se move até o bloco 1816, de outro modo, o fluxo se move até o bloco 1724, onde o dispositivo . cliente 1210 determina se este recebeu uma mensagem de negação de chamada de vídeo a partir do dispositivo cliente 1410. Em caso positivo, en- ' tão, o fluxo se move até o bloco 1910, de outro modo, o fluxo se move de —voltaparao bloco 1722.

Com referência à figura 18, no bloco 1810 (o usuário no disposi- tivo cliente 1410 aceitou o convite de chamada de vídeo), o dispositivo clien- te 1410 determina se áudio está sendo presentemente roteado através do viva-voz (por exemplo, o alto-falante 1470) ou do fone de ouvido do disposi- tivo cliente 1410. Em caso negativo, então, o fluxo se move até o bloco 1812, onde a rota de áudio é alterada do alto-falante 1455 para o viva-voz (por exemplo, o alto-falante 1470), e o fluxo se move até o bloco 1814. Se o áudio já estiver sendo roteado através do viva-voz ou de um fone de ouvido, então, o fluxo se move até o bloco 1814.

No bloco 1814, o dispositivo cliente 1410 exibe uma visualização de vídeo de qual câmera de frente 1460 está capturando atualmente. A ope- ração no bloco 1814 é realizada apenas se a visualização de vídeo não esti- Van nm 65/86 ver sendo atualmente exibida como um resultado da operação no bloco

1730. O fluxo se move a partir do bloco 1814 até o bloco 1820. Nos blocos 1818 e 1820, os dispositivos clientes 1210 e 1410 estabelecem uma conexão P2P entre si. A conexão P2P pode ser estabele- cida através de mecanismos conhecidos (por exemplo, usando o Estabele- cimento de Conectividade de Internet (ICE) ou outros mecanismos de conec- tividade P2P conhecidos). Supondo que a conexão P2P seja estabelecida de maneira bem sucedida, o fluxo se move a partir dos blocos 1818 e 1820 até os blocos 1822 e 1824, respectivamente, onde os dispositivos clientes 1210 e1410começam a transmitir vídeo entre si através da conexão P2P (o vídeo das câmeras de vídeo de frente 1260 e 1460). Em algumas modalidades, o vídeo inclui tanto quadros de vídeo, como áudio correspondente (capturados pelos microfones 1265 e 1465 dos dispositivos clientes 1210 e 1410, respec- 7 tivamente), enquanto, em outras modalidades, o vídeo e o áudio são fluxos separados comunicados através da conexão P2P. O fluxo se move a partir dos blocos 1822 e 1824 até os blocos . 1826 e 1828, respectivamente. Nos blocos 1826 e 1828, os dispositivos cli- entes 1210 e 1410 determinam respectivamente se eles receberam um ou , mais quadros de vídeo a partir de seu ponto. Em caso positivo, então, o fluxo semove apartir dos blocos 1826 e 1828 até os blocos 1830 e 1832, respec- tivamente. Em caso negativo, então, o fluxo permanece nos blocos 1826 e 1828 até um ou mais quadros de vídeo ter sido recebido. Em algumas modalidades, os disposítivos clientes 1210 e 1410 esperam receber quadros de vídeo entre si por um determinado período de tempoe se eles não trocarem os quadros de vídeo ao longo deste tempo, a ação alternativa é adotada. Por exemplo, em algumas modalidades, a cha- mada de vídeo é cancelada e uma mensagem é exibida nas telas dos dispo- sitivos clientes 1210 e 1410 que a chamada de vídeo não pode ser estabele- cida. A chamada de vídeo pode falhar para estabelecer por inúmeras razões queincluem o fato de que a largura de banda é insuficiente para a chamada de vídeo, os quadros de vídeo falharam para transmitir ou serem recebidos etc. Embora em algumas modalidades os dispositivos clientes esperem por V———

e 66/86 um único quadro de vídeo antes de prosseguir, em outras modalidades, os dispositivos clientes esperam para receber inúmeros quadros ao longo de um determinado período de tempo (por exemplo, um fluxo de quadros de vídeo) antes de prosseguir.

Nos blocos 1830 e 1832, os dispositivos clientes 1210 e 1410 mudam respectivamente para a chamada de vídeo. A transição para a cha- mada de vídeo inclui exibir o vídeo que está sendo recebido e alterar a rota de áudio da chamada de áudio comutada por circuito para a chamada de vídeo. Em algumas modalidades, a visualização de vídeo (por exemplo, a visualização de vídeo 1310) se move até um canto da tela (e diminui de ta- manho) e o vídeo que é recebido a partir do ponto é revelado. Deste modo, deve-se entender que até a rota de áudio ter sido alterada da chamada de áudio comutada por circuito para a chamada de vídeo, os participantes po- ' dem 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 estiver sendo negociada). Após mudar para a . chamada de vídeo, a chamada de áudio comutada por circuito pode ser ig- norada. Deste modo, o fluxo se move a partir dos blocos 1830 e 1832 até os : blocos 1834 e 1836, respectivamente, onde a chamada de áudio comutada porcircuito é ignorada.

As figuras 15 e 16 ilustram os dispositivos clientes 1210 e 1410, respectivamente, após eles terem mudado para a chamada de vídeo. Con- forme ilustrado na figura 15, o dispositivo cliente 1210 exibe o vídeo 1510, que é o vídeo do que está sendo capturado pela câmera de 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 de frente

1260. A GUI 1505 também inclui o botão de vídeo de encerramento 1520 e o botão de vídeo e chamada de encerramento 1625. O botão de vídeo de en- cerramento 1520 permite que o usuário encerre a chamada de vídeo e retor- ne parauma chamada de áudio apenas. O botão de vídeo e chamada de encerramento 1525 permite que o usuário encerre a chamada de vídeo completamente (por exemplo, para encerrar a conversação com o usuário no Umm———

o 67/86 dispositivo cliente 1410). Conforme ilustrado na figura 16, o dispositivo clien- te 1410 exibe o vídeo 1610, que é o vídeo do que está sendo capturado pela câmera de 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 pe- la câmera de frente 1460. A GUI 1605 também inclui o botão de encerra- mento de vídeo 1620 e o botão encerramento de vídeo e chamada 1625.

A figura 19 é um fluxograma que ilustra operações exemplificati- vas realizadas em um dispositivo cliente que receberam uma mensagem de rejeição de chamada de vídeo, de acordo com uma modalidade. No bloco 1910, o dispositivo cliente 1210 recebe uma mensagem de rejeição de cha- mada de vídeo (o usuário no dispositivo cliente 1410 rejeitou o convite de chamada de vídeo). O fluxo se move a partir do bloco 1910 até o bloco 1912 e o dispositivo cliente 1210 exibe uma mensagem rejeitada de chamada de ' vídeo 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, então, Í se move até o bloco 1914, onde o dispositivo cliente 1210 para de exibir sua . própria visualização de vídeo. O dispositivo cliente 1210 também pode avisar o usuário para retornar para a saída de áudio original (por exemplo, através ' do alto-falante 1270) se a saída de áudio tiver alterado previamente para o viva-voz no bloco 1718.

A figura 20 é um fluxograma que ilustra operações exemplificati- vas realizadas em um dispositivo cliente para efetuar uma transição de uma chamada de vídeo para uma chamada comutada por circuito, de acordo com uma modalidade. A chamada de vídeo 2010 é estabelecida entre os disposi- tivos clientes 1210 e 1410 (a chamada de vídeo pode ser estabelecida de acordo com os mecanismos descritos com referência às figuras 17 e 18 ou pode ser estabelecida sem mudar de uma chamada de áudio comutada por circuito). No bloco 1712, o dispositivo cliente 1210 recebe entrada para mu- dar para uma chamada comutada por circuito apenas de áudio. Por exem- plo, com referência à figura 15, o usuário do dispositivo cliente 1210 selecio- nou o botão de vídeo de encerramento 1520 (por exemplo, ao tocar ou reali- zar outro gesto predefinido no botão de vídeo de encerramento 1520). O

VR

' 68/86 dispositivo cliente 1210, então, transmite uma mensagem para o dispositivo cliente 1410 que indica uma transição para uma chamada comutada por cir- cuito apenas de áudio 2014. O dispositivo cliente 1210, então, inicia uma solicitação de cha- mada de áudio comutada por circuito para o dispositivo cliente 1410 (por exemplo, o dispositivo cliente 1210 liga automaticamente para o número do dispositivo cliente 1410). Em algumas modalidades isto é realizado no plano de fundo e não requer interação de usuário.

A chamada é roteada através de inúmeros elementos de rede da infraestrutura de rede portadora (por exem- plo, estações de base, centros de comutação móveis etc.). O dispositivo cliente 1410 recebe e responde a chamada comu- tada por circuito 2020. Em uma modalidade, o dispositivo cliente 1410 exibe a 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 requer a intervenção de usuário para respon- der a chamada.

Em outra modalidade, o dispositivo cliente 1410 responde & automaticamente a chamada sem a 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. Após a chamada comutada por circuito apenas de áudio ser es- tabelecida de maneira bem sucedida, os dispositivos clientes 1210 e 1410 mudam para a chamada apenas de áudio 2032 e 2034, respectivamente.

Por exemplo, a transição para a chamada apenas de áudio inclui alterar a rotade áudio da chamada de vídeo para a chamada comutada por circuito, interromper a exibição do vídeo que está sendo recebido, e interromper a transmissão de vídeo.

O dispositivo cliente também pode para de exibir a visualização de vídeo.

Deste modo, deve-se entender que embora a chama- da apenas de áudio comutada por circuito esteja sendo negociada, os usuá- rios nos dispositivos clientes 1210 e 1410 podem se 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 está sendo ne- Uumm——

no 69/86 gociada). Após mudar de maneira bem sucedida para a chamada comutada por circuito apenas de áudio, os dispositivos clientes 1210 e 1410 encerram a conexão P2P 2040. Os usuários nos dispositivos clientes 1210 e 1410, então, podem se comunicar através da chamada comutada por circuito ape- nasdeáudio.

Embora as modalidades da invenção tenham sido descritas em relação a uma chamada de vídeo que tem dois participantes, as modalida- des não são tão limitadas, à medida que podem existir mais participantes na chamada de vídeo. Em tais modalidades, o dispositivo cliente pode exibir múltiplos fluxos de vídeo a partir de cada participante diferente no chat de vídeo.

Embora as modalidades da invenção tenham sido descritas em relação a uma chamada de vídeo que tem dois participantes, onde cada par- ' ticipante transmite vídeo, as modalidades não são tão limitadas. Por exem- plo, em algumas modalidades apenas uma única parte pode estar transmi- tindo vídeo para os outros participantes e estes outros participantes podem . estar transmitindo apenas áudio. Em algumas modalidades cada participante pode determinar se deve suspender a transmissão de vídeo em qualquer : ponto durante a chamada de vídeo. Em algumas modalidades, a qualidade do vídeo transmitido du- rante uma chamada é dinamicamente ajustada com base nas condições de rede. Por exemplo, durante períodos em que a rede está congestionada, a taxa de bits do vídeo pode ser reduzida. De maneira similar, durante perío- dos em que a rede é relativamente livre de congestionamento, a taxa de bits do vídeo pode ser aumentada. Em algumas modalidades, se as condições de rede impedem que o vídeo seja transmitido, os dispositivos clientes parti- cipantes automaticamente mudam para uma chamada comutada por circuito apenas de áudio. Deste modo, se a largura de banda cair abaixo de um de- terminado nível, os dispositivos clientes participantes podem mudar automa- ticamente para uma chamada comutada por circuito apenas de áudio (ou pode avisar ao usuário para mudar 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 li- vres para chamadas de vídeo de IP Em uma modalidade, os dispositivos clientes incluem funcionali- dade para suportar a interação com um dispositivo de mãos livres (por e- xemplo, um fone de ouvido, um Kit para carro) através de uma WPAN (Rede de Área Pessoal Sem Fio) (por exemplo, Bluetooth, ZigBee etc.) que inclui suporte para gerenciar chamadas de vídeo IP com a unidade de mãos livres.

A figura 32 é um diagrama em bloco que ilustra um dispositivo cliente que faz interface com uma unidade de mãos livres para gerenciar chamadas de vídeolP,de acordo com uma modalidade.

O dispositivo cliente 3210 inclui a capacidade de iniciar chamadas de vídeo (por exemplo, convidar um ou mais destinatários para uma sessão de comunicação online que é uma cha- mada de vídeo) e a capacidade de aceitar as chamadas de vídeo.

Em algu- : mas modalidades, o dispositivo cliente 3210 também inclui componentes de —15 telefonia celular para efetuar e receber chamadas de telefone celular e/ou acessar a Internet ou outra rede através de uma conexão via celular. - Conforme mostrado na figura 32, o dispositivo cliente 3210 inclui o gerenciador de chamada de vídeo 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 geren- ciador de chamada de celular 3255. O gerenciador de chamada de vídeo IP 3250 gerencia um aplicativo de chamada de vídeo P2P que inclui estabele- cer uma chamada de vídeo IP P2P através da rede IP 3235 através do ser- viço de chamada de vídeo IP 3230, conforme previamente descrito no pre- sente documento.

Em uma modalidade, o serviço de chamada de vídeo |P 3230 inclui um ou mais entre o serviço de convite 620, o serviço de notífica- ção por 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 efetuar e receber chamadas de telefone celular apenas de áudio através da rede de celular 3245 que usa o serviço de chamada de áudio de celular 3240. O gerenciador de chamada de vídeo IP 3250 e o gerenciador de e 71/86 chamada de celular 3255 são acoplados ao gerenciador de telefonia 3260. O gerenciador de telefonia 3260 gerencia as operações de telefonia tanto para o gerenciador de chamada de vídeo IP 3250 como para o gerenciador de chamada de celular 3255 que inclui rastrear o histórico de chamada (tanto parachamadas de vídeo como para 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 pro- porcionar serviços de mãos livres através de um dispositivo de mãos livres externo para chamadas de vídeo IP e chamadas de celular em nome do ge- renciador de chamada de vídeo IP 3250 e do gerenciador de chamada de celular 3255. Em uma modalidade um formato de mensagem comum é usa- do entre o gerenciador de chamada de vídeo IP 3250, o gerenciador de chamada de celular 3255, e o gerenciador de telefonia 3260, para proporcio- ' nar suporte para os serviços de mãos livres para tipos de protocolo e cha- mada muito diferentes (chamada de vídeo IP e chamada de celular apenas de áudio). Deste modo, o gerenciador de telefonia 3260 proporciona suporte - similar para serviços de mãos livres independente se os serviços de mãos livres são para uma chamada de vídeo IP ou uma de celular apenas de áu- ] dio. Isto também evita a necessidade de o gerenciador de mãos livres 3270 entender se os serviços de mãos livres são para uma chamada de vídeo |P ou para uma chamada de celular apenas de áudio, de modo que os coman- dos padrão que são passíveis de entendimento pelos dispositivos de mãos livres possam ser usados. para proporcionar serviços de mãos livres para chamadas de vídeo IP, assim como, para chamadas de celular apenas de áudio.

Em uma modalidade, o gerenciador de telefonia 3260 também media entre o gerenciador de chamada de vídeo IP 3250 e o gerenciador de chamada de celular 3255. Por exemplo, o gerenciador de telefonia 3260 po- de fazer com que uma chamada de vídeo IP seja colocada em espera para mudar para uma chamada de célula apenas de áudio estabelecida e/ou fa- zer com que uma chamada de célula apenas de áudio seja colocada em es- pera para mudar para uma chamada de vídeo |P.

— pn

: ' 72/86 O gerenciador de mãos livres 3270 proporciona suporte para o processamento de mãos livres. Em uma modalidade, o gerenciador de mãos livres 3270 implementa uma pilha de protocolo Bluetooth para conexão com dispositivos de mãos livres compatíveis com Bluetooth, tais como, fone de ouvido Bluetooth e kits para carro Bluetooth. Em uma modalidade específica, o gerenciador de mãos livres 3270 implementa um perfil de fone de ouvido Bluetooth (por exemplo, conforme definido no Perfil de Fone de Ouvido (HSP) 1.2, especificação de 18 de dezembro de 2008) e/ou um perfil de mãos livres Bluetooth (por exemplo, conforme definido no Perfil de Mãos Livres 1.5(HFP 1.5), especificação de 25 de novembro de 2005). O gerenci- ador de mãos livres 3270 permite que a unidade de mãos livres 3220 atue como uma retransmissão auditiva para uma chamada de vídeo IP e para uma chamada de celular apenas de áudio através da WPAN 3225, assim ' como, realizar outros serviços de mãos livres. Por exemplo, no caso de uma -—15 chamada de vídeo |P,a porção de áudio da chamada pode ser roteada atra- vés da unidade de mãos livres 3220 em vez 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 uma tela conectada). A unidade ' de mãos livres 3220 também inclui um microfone para capturar informações de áudio que, então, são transmiítidas para o dispositivo de computação cli- ente 3210. Deste modo, um usuário pode usar a unidade de mãos livres 3220 para falar ou escutar o áudio durante uma chamada de vídeo IP e/ou durante uma chamada de celular apenas de áudio.

O gerenciador de mãos livres 3270 também suporta outros ser- = viçosde mãos livres em resposta à entrada de recepção da unidade de mãos livres 3220 que inclui realizar um ou mais do seguinte para chamadas de vídeo IP e/ou chamadas de celular apenas de áudio: permitir que um u- suário responda uma chamada; encerrar uma chamada; colocar uma cha- mada em espera; interromper o som de uma chamada; aumentar/diminuir o volume de uma chamada; transferir o áudio para o dispositivo cliente; trans- ferir o áudio para a unidade de mãos livres; fazer uma chamada; e rediscar a última chamada. Deste modo, um usuário pode usar a unidade de mãos |i-

ma 73/86 vres 3220 para responder uma chamada de vídeo IP, encerrar uma chama- da de vídeo IP, colocar uma chamada de vídeo IP em espera e/ou em mudo, aumentar/diminuir o volume de uma chamada de vídeo IP, transferir o áudio da chamada de vídeo IP para ser produzido em um alto-falante do dispositi- vocliente 3210, transferir o áudio do dispositivo cliente 3210 para a unidade de mãos livres 3220, fazer uma chamada de vídeo IP, e rediscar a última chamada de vídeo |P. O gerenciador de chamada de vídeo IP 3250, o gerenciador de chamada de celular 3255, e o gerenciador de mãos livres 3270 também são acoplados ao gerenciador de áudio 3275. O gerenciador de áudio 3275 ro- teia o áudio das chamadas de vídeo IP e das chamadas de celular apenas de áudio através de fontes diferentes. Por exemplo, o gerenciador de áudio 3275 pode fazer com que o áudio seja produzido através de um alto-falante do dispositivo cliente 3210 adequado ao modo viva-voz, através de um alto- .—15 falantedo dispositivo cliente 3210 usado quando um usuário segura o dispo- sitivo cliente 3210 em sua orelha durante uma chamada, através de um fone . de ouvido/toma auricular para um fone de ouvido ou fone de ouvido que é conectado ao dispositivo cliente 3210, e através de uma unidade de mãos ' livres emparelhada (tal como, a unidade de mãos livres 3220).

A figura 33 ilustra o dispositivo cliente 3210 que recebe um con- vite para uma chamada de vídeo, que faz com que o dispositivo de mãos livres toque, receba uma indicação de resposta do dispositivo de mãos |i- vres, estabeleça a chamada de vídeo, e roteie o áudio para o dispositivo de mãos livres, de acordo com uma modalidade. A figura 33 será descrita com referência à modalidade exemplificativa da figura 32. Entretanto, deve-se entender que as operações da figura 33 podem ser realizadas por modalida- des diferentes daquelas discutidas com referência à figura 32, e as modali- dades discutidas com referência à figura 32 podem realizar operações dife- rentes daquelas discutidas com referência à figura 33.

Na operação 3310, o gerenciador de chamada de vídeo IP 3250 recebe um convite de chamada de vídeo IP de outro dispositivo cliente que convida o usuário do dispositivo cliente 3210 a participar de uma chamada

! Í 74/86 de vídeo IP. O convite de chamada de vídeo IP pode assumir a forma do convite, conforme previamente descrito no presente documento. O gerencia- dor de chamada de vídeo IP 3250 processa a solicitação de convite que in- clui fazer com que o convite seja exibido na operação 3315. Por exemplo, a solicitação de convite pode ser exibida de uma maneira similar como o con- vite de chamada de vídeo exemplificativo 1410 ilustrado na figura 14. | Além disso, o gerenciador de chamada de vídeo 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 que se refere à chamada. Por exemplo, os parâmetros de objeto de chamada incluem um ou mais de um estado da chamada (por exemplo, conexão), e identificador de participante de chamada (por exemplo, o número de telefone, endereço de email, ou outro identificador de ponto de extremidade de sessão de comuni- S cação online), um tempo de partida, uma indicação se esta é uma chamada . 15 de saída ou de entrada, e um identificador de chamada usado internamente para identificar a chamada. - Em uma modalidade, o objeto de chamada 3320 é um objeto de chamada genérico que, embora os parâmetros sejam baseados nas infor- ' mações do convite de chamada de vídeo IP, se encontra em um formato .que é comum tanto para as solicitações de convite de chamada de vídeo IP co- mo para as chamadas de célula apenas de áudio de entrada. Deste modo, ao receber uma chamada de celular apenas de áudio de entrada, o gerenci- ador de chamada de celular 3255 gera um objeto de chamada de entrada do mesmo formato. Deste modo, a partir da perspectiva do gerenciador de tele- fonia 3260, um convite de solicitação de chamada de vídeo IP ou uma cha- mada de celular apenas de áudio de entrada parecem iguais.

O gerenciador de telefonia 3260 armazena as informações no objeto de chamada 3320 como parte de uma estrutura de histórico de cha- mada. O gerenciador de telefonia 3260 também gera e envia uma mensa- gemde chamada de entrada 3322 para o gerenciador de mãos livres 3270. Em uma modalidade, o gerenciador de telefonia 3260 apenas envia a men- sagem de chamada de entrada 3322 se existir um dispositivo de mãos livres,

no 75/86 tal como, o dispositivo de mãos livres 3220 emparelhado com o dispositivo cliente 3210 (por exemplo, o gerenciador de telefonia 3260 verifica primeiro se existe um dispositivo de mãos livres que é emparelhado com o dispositivo cliente 3210). Em outras modalidades, o gerenciador de telefonia 3260 envia a mensagem de chamada de entrada 33220 para o gerenciador de mãos livres 3270 independente se existe um dispositivo de mãos livres empare- lhado e o gerenciador de mãos livres 3270 determina se deve descar- tarfignorar a mensagem ou processar a mesma dependendo se existe um dispositivo de mãos livres emparelhado.

Para os propósitos da figura 33 e figuras subsequentes, supõe-se que o dispositivo de mãos livres 3220 seja emparelhado com o dispositivo de computação cliente 3210. Em uma moda- lidade, a mensagem de chamada de entrada 3322 inclui o identificador de chamada. ' ' Em resposta ao recebimento da mensagem de chamada de en- . 15 trada 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 que aler- . ta este e o usuário que existe uma chamada de entrada.

Conforme mostrado na figura 33, o gerenciador de mãos livres estabelece uma conexão de áudio ' 3325 (por exemplo, um enlace Síncrono Orientado a Conexão (SCO)) com o dispositivo de mãos livres 3220 antes de enviar uma mensagem de tom de chamada 3330 através da conexão de áudio estabelecida 3325. Esta men- sagem de tom de chamada é selecionada pelo dispositivo cliente 3210 e po- de ser padronizável pelo usuário do dispositivo cliente 3210. Em uma moda- lidade, a mensagem de tom de chamada para chamadas de vídeo IP é dife- rente do tom de chamada para chamadas de celular apenas de áudio.

Em outra modalidade, uma conexão de áudio não é estabelecida até após a chamada ser respondida.

Em tal modalidade, uma mensagem de alerta de chamada é enviada para o dispositivo de mãos livres 3220 que, então, de- termina localmente se deve reproduzir um tom de chamada para alertar o usuárioda chamada de entrada (a mensagem de alerta de chamada tam- bém pode ser enviada antes do envio da mensagem de tom de chamada 3330). Em tal modalidade, a mensagem de alerta de chamada pode ser en-

Ea 76/86 viada múltiplas vezes para o dispositivo de mãos livres 3220 até a chamada ser respondida ou terminada. Algum tempo após receber a mensagem de alerta de chamada e/ou a mensagem de chamada 3330, o dispositivo de mãos livres 3220 transmite a mensagem de respondida 3335 que indica que um usuário res- pondeu a chamada. Por exemplo, o usuário pressionou um botão de respos- ta em seu dispositivo de mãos livres 3220 ou, de outro modo, adotou a ação no dispositivo de mãos livres 3220 para responder a chamada. O gerencia- dor de mãos livres 3270 recebe a mensagem de respondida 3335 e transmi- . te uma mensagem de respondida 3340 para o gerenciador de telefonia

3260. Em uma modalidade, a mensagem de respondida 3340 inclui o identi- ficador de chamada. Embora não ilustrado na figura 33, o gerenciador de * mãos livres 3270 também pode transmitir uma mensagem de confirmação ' para o dispositivo de mãos livres 3220 em resposta ao recebimento da men- . 15 sagem de respondida 3335. O gerenciador de telefonia 3260 determina que a mensagem de chamada respondida 3340 pertence à chamada indicada no objeto de cha- mada 3320 (por exemplo, comparando-se o identificador de chamada incluí- Ú do na mensagem 3340 com as informações armazenadas do objeto de chamada 3320) e transmite uma mensagem 3345 para o gerenciador de chamada de vídeo IP 3250 que indica que a chamada foi respondida. Em resposta ao recebimento desta mensagem, o gerenciador de chamada de vídeo IP 3250 estabelece uma chamada de vídeo IP em uma operação

3350. Por exemplo, o gerenciador de chamada de vídeo IP 3250 faz com queuma mensagem de aceitação de chamada de vídeo |P seja enviada pa- ra um serviço de convite, conforme previamente descrito no presente docu- mento e uma conexão P2P é estabelecida (direta ou através de uma re- transmissão) com o dispositivo de computação que transmitiu o convite. Algum tempo após a chamada de vídeo IP ter sido estabelecida, ogerenciador de chamada de vídeo IP 3250 transmite um objeto de chama- da 3355 para o gerenciador de telefonia 3260. O objeto de chamada 3355 inclui um conjunto de parâmetros similar ao objeto de chamada 3320, exceto am 77/86 pelo fato de que o estado alterou de conectando para conectado. Em uma modalidade, o objeto de chamada 3355 é um objeto de chamada genérico que tem um formato que é comum tanto para as chamadas de vídeo |P es- tabelecidas como chamadas de celular apenas de áudio conectadas. Além disso, algum tempo após a chamada de vídeo IP ter sido | estabelecida, o gerenciador de áudio 3275 roteia a porção de áudio da cha- mada de vídeo IP estabelecida através do dispositivo de mãos livres 3220. Em uma modalidade, o gerenciador de chamada de vídeo IP 3250 ou o ge- renciador 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 também pode transmitir uma mensagem 3360 para o gerenciador de mãos livres 3270 que indica que a rota de áudio será alterada para atravessar o dispositivo de mãos livres 3220. Se uma conexão de áudio ainda não foi es- S tabelecida, o gerenciador de mãos livres 3270 irá estabelecer uma conexão .15 de áudiocom o dispositivo de mãos livres 3220. Supondo que exista uma conexão de áudio estabelecida, a porção de áudio 3365 da chamada de ví- FR deo é roteada para o dispositivo de mãos livres 3220. Deste modo, a porção de áudio da chamada de vídeo é manipulada 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. A figura 34 ilustra o dispositivo cliente 3210 que inicia uma cha- mada de vídeo e roteia o áudio para a chamada de vídeo estabelecida atra- vés de um dispositivo de mãos livres, de acordo com uma modalidade. A figura 34 será descrita com referência à modalidade exemplificativa da figura

32. Entretanto, deve-se entender que as operações da figura 34 podem ser realizadas por modalidades diferentes daquelas 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. Na operação 3410, o gerenciador de chamada de vídeo IP 3250 faz com que uma ou mais mensagens de convite de chamada de vídeo IP seja enviadas para outro dispositivo cliente para convidar usuário(s) para uma chamada de vídeo IP. A mensagem de convite de chamada de vídeo IP —

ms 78/86 pode assumir a forma do convite, conforme previamente descrito no presen- te documento.

O gerenciador de chamada de vídeo 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 que se refere à chamada e tem um formato genérico.

O ge- renciador de telefonia 3260 armazena as informações no objeto de chamada 3415 como parte de uma estrutura de histórico de chamada.

Em uma modalidade, o gerenciador de telefonia 3260 também gera e envia uma mensagem de chamada de saída 3420 para o gerenciador de mãos livres 3270 que indica que existe uma chamada de saída.

Em res- posta a esta 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 tom de chamada em banda padronizado for enviado ) e, então, transmite uma men- : sagem de tom de chamada 3430 para o dispositivo de mãos livres 3220. Em . 15 outramodalidade, o gerenciador de mãos livres 3270 transmite apenas uma mensagem de alerta de tom de chamada para o dispositivo de mãos livres - 3220 em vez de estabelecer uma conexão de áudio e transmitir um tom de chamada em banda. ' Algum tempo após enviar o convite de chamada de vídeo IP, o gerenciador de chamada de vídeo IP 3250 recebe uma mensagem de acei- tação de chamada de vídeo IP 3435, que pode assumir a forma de uma mensagem de aceitação de chamada de vídeo, conforme previamente des- crito no presente documento.

Após receber esta mensagem, uma chamada de vídeo IP P2P é estabelecida com o dispositivo cliente de aceitação na operação 3440 (por exemplo, uma conexão P2P (direta ou através de uma retransmissão) é estabelecida com o dispositivo de computação que aceitou o convite). Algum tempo após a chamada de vídeo IP ter sido estabelecida, o gerenciador de chamada de vídeo IP 3250 transmite um objeto de chama- da 3445 para o gerenciador de telefonia 3260. O objeto de chamada 3445 inclui um conjunto de parâmetros similar ao objeto de chamada 3415, exceto pelo fato de que o estado alterou de conectando para conectado.

O objeto V——

Na 79/86 de chamada 3445 também tem um formato genérico. Além disso, algum tempo após a chamada de vídeo IP ter sido estabelecida, o gerenciador de áudio 3275 roteia a porção de áudio da chamada de vídeo estabelecida IP através do dispositivo de mãos livres 3220. Em uma modalidade, o gerenci- adorde chamada de vídeo IP 3250 ou o gerenciador de telefonia 3260 solici- ta que o gerenciador de áudio 3275 roteie o áudio através do dispositivo de mãos livres. O gerenciador de áudio 3275 também pode transmitir uma mensagem 3455 para o gerenciador de mãos livres 3270 que indica que a rota de áudio será alterada para atravessar o dispositivo de mãos livres |

3220. Se uma conexão de áudio ainda não foi estabelecida, o gerenciador de mãos livres 3270 irá estabelecer uma conexão de áudio com o dispositivo de mãos livres 3220. Supondo que exista uma conexão de áudio estabeleci- da, a porção de áudio 3460 da chamada de vídeo é roteada para o dispositi- vo de mãos livres 3220. Deste modo, a porção de áudio da chamada de ví- .15 deoé manipulada 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.

- A figura 35 ilustra o dispositivo cliente 3210 que inicia uma cha- mada de vídeo em resposta ao recebimento 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 exemplificativa da figura 32. Entretanto, deve-se entender que as operações da figura 35 podem ser rea- lizadas por modalidades diferentes daquelas 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. 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 de extremidade de sessão de comunicação online a ser chamado. Por exemplo, o usuário pode selecionar um botão rediscar no dispositivo de mãos livres 3220 que solicita que a últi- ma chamada seja rediscada. O gerenciador de mãos livres 3270 transmite uma mensagem de solicitação de chamada 3520 para o gerenciador de tele-

nm 80/86 fonia 3260. O gerenciador de telefonia 3260 determina se a mensagem de solicitação de chamada 3520 está solicitando uma chamada para um identi- ficador que é associada a uma chamada de vídeo (e, deste modo, a mensa- gem de solicitação de chamada deve ser enviada para o gerenciador de chamada de vídeo IP 3250) ou associada a um número de telefone para uma chamada de celular apenas de áudio (e, deste modo, deve 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 ge- renciador de telefonia 3260 acessa a última chamada discada, que pode ser uma chamada de vídeo IP ou uma chamada de celular apenas de áudio, para determinar para onde enviar a solicitação de chamada.

Conforme mos- trado na figura 35, o gerenciador de telefonia envia a mensagem de solicita ção de chamada 3525 para o gerenciador de chamada de vídeo IP 3250. A ' mensagem de solicitação de chamada 3525 inclui o identificador do partici- .15 pante solicitado para a chamada de vídeo (por exemplo, um número de tele- fone, um endereço de email, ou outro identificador de ponto de extremidade - de sessão de comunicação online). Em resposta ao recebimento da mensa- gem de solicitação de chamada 3525, o gerenciador de chamada de vídeo ' IP 3250 faz com que uma mensagem de convite de chamada de vídeo IP seja enviada para o participante indicado na operação 3410, conforme des- crito na figura 34. As operações restantes mostradas na figura 35 são reali- zadas, conforme descrito com referência à figura 34. Deste modo, o disposi- tivo cliente 3210 suporta o estabelecimento de uma chamada de vídeo |P, como um resultado da ação do usuário em um dispositivo de mãos livres emparelhado.

A figura 36 ilustra o dispositivo cliente 3210 que roteia o áudio de uma chamada de vídeo estabelecida para o dispositivo de mãos livres 3220, de acordo com uma modalidade.

Existe uma chamada de vídeo estabelecida IP 3610 entre o dispositivo cliente 3210 e um ou mais outros dispositivos clientes.

A porção de áudio desta chamada está sendo atualmente emitida por um alto-falante do dispositivo cliente 3210 ou através de fones de ouvido que são conectados no dispositivo cliente 3210. Na operação 3615, o geren-

. | 81/86 ciador de chamada de vídeo IP 3250 recebe entrada para transferir o áudio para o dispositivo de mãos livres 3220. Por exemplo, um usuário do disposi- tivo cliente 3210 proporcionou entrada para o aplicativo de chamada de vi- deo IP transferir o áudio para um dispositivo de mãos livres emparelhado.

Em resposta ao recebimento de tal entrada, o gerenciador de chamada de vídeo IP 3250 envia uma solicitação de rota de áudio 3620 para o gerencia- dor de áudio 3275 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 transmi- tir uma mensagem 3625 para o gerenciador de mãos livres 3270 que indica quea rota de áudio será alterada para atravessar o dispositivo de mãos |i- vres 3220. Se uma conexão de áudio ainda não foi estabelecida, o gerencia- dor de mãos livres 3270 irá estabelecer uma conexão de áudio 3630 com o dispositivo de mãos livres 3220. Supondo que exista uma conexão de áudio i : estabelecida, a porção de áudio 3635 da chamada de vídeo é roteada para o .15 dispositivo de mãos livres 3220. Deste modo, após uma chamada de vídeo IP ser estabelecida, o dispositivo cliente 3210 permite que o usuário transfira - o áudio para um dispositivo de mãos livres.

Embora a figura 36 ilustre a transferência de áudio para um dis- ' positivo de mãos livres em resposta ao recebimento de 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 da en- trada no dispositivo de mãos livres 3220. Em tais modalidades, o gerencia- dor de mãos livres 3270 recebe um comando a partir do dispositivo de mãos livres 3220 para transferir o áudio.

O gerenciador de mãos livres 3270, en- tão, envia a solicitação para o gerenciador de áudio 3275 que, então, roteia novamente o áudio.

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 tam- . bém pode ser transferido a partir do dispositivo de mãos livres para um alto- falante (ou fones de ouvido) do dispositivo cliente 3210. Isto pode ser inicia- do no dispositivo cliente 3210 e/ou no disposítivo de mãos livres 3220. Em tais modalidades, o gerenciador de áudio 3275 recebe a solicitação de áudio

: i 82/86 de rota (a partir do gerenciador de chamada de vídeo IP 3250 ou do geren- ciador de mãos livres 3270) para rotear o áudio para o dispositivo cliente 3210 e agir de maneira correspondente.

A figura 37 ilustra o dispositivo cliente 3210 que termina uma chamada de vídeo em resposta ao recebimento de uma solicitação de cha- mada de encerramento a partir do dispositivo de mãos livres 3220, de acor- do com uma modalidade.

O gerenciador de mãos livres 3270 recebe uma mensagem de chamada de encerramento 3710 a partir do dispositivo de mãos livres 3220 em resposta a uma seleção de usuário para encerrar uma chamada (por exemplo, um botão encerrar 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 chamada de encerramento 3715 para o gerenciador de telefonia 3260. Em uma modalidade, a solicitação de Á chamada de encerramento 3715 inclui um identificador de chamada que in- .-15 dicaqualchamada deve encerrar (neste caso, existem múltiplas chamadas). O gerenciador de telefonia 3260 determina que a chamada a encerrar é as- - sociada ao gerenciador de chamada de vídeo IP 3250 e envia a mensagem de chamada de encerramento 3720 para o gerenciador de chamada de ví- Á deo IP 3250. Em resposta ao recebimento da mensagem de chamada de encerramento 3720, o gerenciador de chamada de vídeo IP 3250 faz com que a chamada de vídeo IP seja terminada e faz com que o dispositivo clien- te 3210 se desconecte da conexão P2P.

Deste modo, o dispositivo cliente 3210 suporta permitir que o usuário encerre uma chamada .de vídeo IP u- sando um dispositivo de mãos livres emparelhado.

A figura 38 é um diagrama em bloco que ilustra um sistema de : computador exemplificativo que pode ser usado em algumas modalidades. + Por exemplo, a arquitetura exemplificativa 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 docu- mento.

Deve-se entender, que embora a figura 38 ilustre diversos compo- * nentes de um sistema de computador, não se pretende representar nenhu- ma arquitetura ou maneira particular de interconexão dos componentes, co- UR————

. ' 83/86 mo tal, os detalhes não são relevantes para a presente invenção. Será avali- ado que outros sistemas de computador que têm menos componentes ou mais componentes também podem ser usados. Conforme ilustrado na figura 38, o sistema de computador 3800, queé uma forma de um sistema de processamento de dados, inclui o bar- ramento 3850 que é acoplado ao sistema de processamento 3820, fonte de alimentação 3825, memória 3830, e memória não volátil 3840 (por exemplo, um disco rígido, memória flash, Memória de Alteração de Fase (PCM) etc.). Os barramentos 3850 podem ser conectados uns aos outros através de di- versas pontes, controladores e/ou adaptadores, conforme bem conhecido na técnica. O sistema de processamento 3820 pode recuperar instruções a par- tir 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 barramento 3850 inter- ' conecta os componentes acima entre si e também interconecta estes com- . 15 ponentes à plataforma opcional 3860, o controlador de exibição e dispositivo de exibição 3870, Dispositivos de entrada/saída 3880 (por exemplo, NIC - (Cartão de Interface de Rede), um controle de cursor (por exemplo, mouse, tela sensível ao toque, touchpad etc.), um teclado etc.), e transceptores sem ' fio opcionais 3890 (por exemplo, Bluetooth, WiFi, Infravermelho etc.).

A figura 39 é um diagrama em bloco que ilustra um sistema de processamento de dados exemplificativo que pode ser usado em algumas modalidades. Por exemplo, o sistema de processamento de dados 3900 po- de ser um computador portátil, um assistente digital pessoal (PDA), um tele- fone celular, um sistema de jogos portátil, um tocador de mídia portátil, um tabletou um dispositivo de computação portátil, que pode incluir um telefone celular, um tocador de mídia e/ou um sistema de jogos. Como outro exem- plo, o sistema de processamento de dados 3900 pode ser uma rede compu- i tador ou um dispositivo de processamento embutido em outro dispositivo. De acordo com uma modalidade, a arquitetura exemplificativa 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 UppDpmmE—

. | 84/86 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 é acoplado a uma memória 3910, uma fon- te de alimentação 3925 (que inclui uma ou mais baterias), uma entrada/saí- dade áudio 3940,um controlador de exibição e dispositivo de exibição 3960, entrada/saída opcional 3950, dispositivo de entrada 3970 e transceptores sem fio 3930. Será avaliado que os componentes adicionais, não mostrados na figura 39, também podem fazer parte do sistema de processamento de dados 3900, em determinadas modalidades, e em determinadas modalida- des, menos componentes que o mostrado na figura 39 podem ser usados.

Além disso, será avaliado que um ou mais barramentos, não mostrados na figura 39, podem ser usados para interconectar os diversos componentes, conforme é bem conhecido na técnica. ' A memória 3910 pode armazenar dados e/ou programas para . 15 execução através do sistema de processamento de dados 3900. A entra- da/saída de áudio 3940 pode incluir um microfone e/ou um alto-falante, por - exemplo, para reproduzir música e/ou proporcionar funcionalidade de telefo- nia através do alto-falante e do microfone.

O controlador de exibição e o dis- í positivo de exibição 3960 podem incluir uma interface gráfica de usuário (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.

Um ou mais dispositivos de entrada 3970 permitem que um usuário proporcione entrada paraosistema.

Estes dispositivos de entrada podem ser um teclado numéri- co, teclado, painel sensível ao toque, painel de múltiplos toques etc.

A outra entrada/saída opcional 3950 pode ser um conector para uma plataforma.

As técnicas mostradas nas figuras podem ser implementadas usando códigos de dados armazenados e executados em um ou mais dispo- sitivos 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 através de uma rede) códigos VUp———

. Í 85/86 (compostos por instruções de software) e dados que usam meios legíveis por máquina, tais como, meios legíveis por máquina tangíveis não transitó- rios (por exemplo, meios de armazenamento legíveis por máquina, tais co- mo, discos magnéticos; discos óticos; memória somente leitura; dispositivos de memória flash) e sinais de propagação transitórios (por exemplo, elétri- cos, óticos, acústicos ou outra forma de sinais propagados — tais como, on- das portadoras, sinais infravermelhos, sinais digitais etc.). Além disso, tais dispositivos de computação incluem tipicamente um conjunto de um ou mais processadores acoplados a um ou mais outros componentes, tais como, um oumaismeios legíveis por máquina tangíveis não transitórios (para armaze- nar códigos e/ou dados), dispositivos de entrada/saída de usuário (por e- xemplo, um teclado, uma tela sensível ao toque, e/ou uma tela), e conexões de rede (para transmitir códigos e/ou dados usando sinais de propagação ' transitórios). O acoplamento do conjunto de processadores e outros compo- . 15 nentes ocorre tipicamente através de um ou mais barramentos e pontes (também chamados de controladores de barramento). Deste modo, um meio - legível por máquina não transitório de um determinado dispositivo de compu- tação armazena tipicamente instruções para execução no conjunto de um ou ' mais processadores daquele dispositivo de computação. Uma ou mais par- tesde uma modalidade podem ser implementadas usando combinações di- ferentes de software, firmware, e/ou hardware. Embora as operações tenham sido descritas no presente docu- * mento com referência à validação automática de um endereço de email sem requerer que um usuário clique em um link incluído em uma mensagem de email de validação em relação à validação de um endereço de email para uso como um identificador de ponto de extremidade de sessão de comuni- cação online, as modalidades não são tão limitadas. Por exemplo, em algu- mas modalidades, as operações descritas com referência à validação auto- mática de um endereço de email são realizadas quando um endereço de emailprecisa ser validado por outras razões. Por exemplo, um usuário pode ser registrado para um serviço que requer que um endereço de email seja validado, à medida que pertence aquele usuário como uma parte do proces-

VW

. i 86/86 so de registro.

O usuário proporciona o endereço de email 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 de email precisa ser validado e que uma mensagem de email de validação foi enviada ou será enviada para oendereçode email que foi proporcionado (a mensagem de email de valida- ção pode ou não incluir um link de validação). Um aplicativo no dispositivo cliente pode verificar automaticamente uma conta de email que corresponde ao endereço de email para a mensagem de validação e quando for localiza- do, analisa automaticamente a mensagem para localizar um token de valida- çãoe transmitir uma mensagem de validação de endereço de email que in- clui o endereço de email e o token de validação para um servidor de valida- ção de email associado ao serviço para validar o endereço de email.

Embora os fluxogramas nas figuras mostrem uma ordem particular de operações rea- ' lizadas por determinadas modalidades, deve-se entender que tal ordem é .15 exemplificativa (por exemplo, modalidades alternativas podem realizar as operações em uma ordem diferente, combinar determinadas operações, so- - brepor determinadas operações etc.). . Embora a invenção tenha sido descrita em termos de diversas ' modalidades, aqueles versados na técnica irão reconhecer que a invenção nãoselimitaàs modalidades descritas, e pode ser praticada com modifica- ção e alteração dentro do espírito e escopo das reivindicações em anexo.

A descrição, deste modo, deve ser referida como ilustrativa em vez de limi- tante.

Claims

REIVINDICAÇÕES

1. Método para auxiliar no estabelecimento de uma sessão de comunicação online entre dispositivos de computação cliente, que compre- ende: receber a partir de um dispositivo de computação cliente de ini- ciação uma mensagem de solicitação de convite para uma sessão de comu- nicação online que inclui dados de conexão do dispositivo de computação de iniciação e um identificador de ponto de extremidade de sessão de comuni- cação online para um destinatário pretendido; determinar um conjunto de um ou mais push tokens que são as- sociados ao identificador de ponto de extremidade de sessão de comunica- ção online, em que cada conjunto de push tokens identifica um dispositivo de computação cliente; transmitir uma mensagem de convite de sessão de comunicação online que inclui os dados de conexão do dispositivo de computação cliente de iniciação para um conjunto de um ou mais dispositivos de computação ã cliente de destinatário pretendido que correspondem ao conjunto de um ou í mais push tokens; receber uma mensagem de convite de aceitação a partir de pelo menos um conjunto de dispositivos de computação cliente de destinatário pretendido que inclui dados de conexão daquele dispositivo de computação de aceitação; e transmitir uma mensagem de convite de aceitação para o dispo- sitivo de computação de iniciação que inclui os dados de conexão de cada dispositivo de computação de aceitação para permitir que o dispositivo de computação de iniciação e cada dispositivo de computação de aceitação estabeleçam uma sessão de comunicação online ponto a ponto direta.

2. Método de acordo com a reivindicação 1, em que o identifica- dor de ponto de extremidade de sessão de comunicação online é seleciona- doa partirdogrupo que compreende: um número de telefone, um endereço de email, um nome de usuário, e qualquer combinação destes.

3. Método de acordo com a reivindicação 1, em que cada push DU———

Poa i 23 token permite que um serviço de notificação por push localize e transmita mensagens de notificação por push para o dispositivo de computação cliente de destinatário pretendido correspondente.

4. Método de acordo com a reivindicação 1, em que a mensa- gem de convite para a sessão de comunicação online é um convite oculto, de modo que um usuário no dispositivo de computação cliente de iniciação não saiba se o destinatário pretendido está online.

5. Método de acordo com a reivindicação 1, em que os dados de conexão do dispositivo de computação cliente de iniciação e os dispositivos de computação cliente de destinatário pretendido de aceitação incluem um endereço IP (Protocolo de Internet) público, tipo NAT (Tradução de Endere- ço de Rede) de um dispositivo NAT, e um número de porta pública do dispo- sitivo de computação cliente de iniciação e dos dispositivos de computação cliente de destinatário pretendido de aceitação, respectivamente.

6. Método de acordo com a reivindicação 1, que compreende a- dicionalmente: a determinar que a sessão de comunicação online ponto a ponto fc direta falhou para estabelecer e realizar o seguinte: identificar informações de rede associadas a um serviço de re- ' 20 transmissão, as informações de rede utilizáveis pelo dispositivo de computa- ção cliente de iniciação e pelos dispositivos de computação cliente de desti- natário pretendido de aceitação para estabelecer uma conexão através do serviço de retransmissão, e ' transmitir as informações de rede, ou partes destas, para o dis- positivo de computação cliente de iniciação e os dispositivos de computação cliente de destinatário pretendido de aceitação para permitir que estes esta- beleçam uma sessão de comunicação online através do serviço de retrans- missão.

7. Método de acordo com a reivindicação 6, em que determinar quea sessão de comunicação online ponto a ponto direta falhou para se estabelecer inclui receber uma indicação a partir de pelo menos um dos dis- positivos de computação cliente em que a tentativa de conexão ponto a pon- r—

2a É 3/3 to não foi bem sucedida.

8. Método de acordo com a reivindicação 6, em que as informa- | ções de rede associadas ao serviço de retransmissão incluem um primeiro endereço de host de retransmissão a ser usado pelo dispositivo de compu- tação cliente de iniciação e um segundo endereço de host de retransmissão a ser usado pelos dispositivos de computação cliente de destinatário preten- dido de aceitação.

9. Meio de armazenamento legível por máquina não transitório que proporciona instruções que, quando executadas por um processador, irãofazer com que o dito processador realize um método como definido em qualquer uma das reivindicações de 1 a 8.

10. Aparelho para auxiliar no estabelecimento de sessões de comunicação online entre dispositivos de computação cliente, que compre- ende: uma memória para armazenar código de programa; um processador acoplado à memória para processar o código de a programa para realizar um método como definido em qualquer uma das rei- r vindicações de 1 a 8.