BRPI0720651B1

BRPI0720651B1 - sistema e método para fornecer serviços combinatórios aos chamadores anônimos

Info

Publication number: BRPI0720651B1
Application number: BRPI0720651A
Authority: BR
Inventors: K Salkintzis Apostolis; F Coulas Michael
Original assignee: Google Technology Holdings LLC; Motorola Mobility Llc; Motorola Mobility Inc; Motorola Solutions Inc; Motorola Inc
Priority date: 2006-12-28
Filing date: 2007-12-21
Publication date: 2020-01-28
Also published as: CN101573939B; WO2008083060A2; EP2130347B1; BRPI0720651B8; WO2008083060A3; WO2008083060A4; CN101573939A; BRPI0720651A2; EP2130347A2; KR20090083953A

Abstract

sistema e método para fornecer serviços combinatórios aos chamadores anônimos um sistema e método no qual uma notificação é recebida de uma chamada a partir de um primeiro dispositivo para um segundo dispositivo em um primeiro domínio. um contexto é criado para o primeiro tipo de chamada. uma notificação é recebida sobre a iniciação de uma chamada a partir do segundo dispositivo para o primeiro dispositivo em um segundo domínio. o contexto de chamada é utilizado para notificar o primeiro dispositivo sobre a iniciação da chamada a partir do segundo dispositivo para o primeiro dispositivo.

Description

SISTEMA E MÉTODO PARA FORNECER SERVIÇOS COMBINATÓRIOS AOS CHAMADORES ANÔNIMOS

ANTECEDENTES

Os consumidores atualmente utilizam um grande número de serviços de comunicações móveis. Tais serviços incluem, mas não são limitados aos tradicionais serviços de voz, compartilhamento de vídeo, compartilhamento de arquivos, troca de mensagens de multimídia, troca de mensagens instantâneas, lousa interativa, e semelhante.

Muito frequentemente, os consumidores desejam utilizar dois ou mais serviços ao mesmo tempo. Duas partes podem desejar ter uma chamada de vez enquanto assistindo a um vídeo compartilhado ou colaborando em um documento compartilhado. Os consumidores também desejam poder se deslocar facilmente entre serviços. Por exemplo, duas partes tendo uma chamada de voz tradicional poderiam desejar mudar a chamada para uma chamada de vídeo. Muito frequentemente, contudo, o presente estado da tecnologia torna impossível tais mudanças.

Por exemplo, uma parte poderia não conhecer a identidade de outra parte devido à invocação de Restrição de Identificação de Linha de Chamada (CLIR) durante o estabelecimento de uma chamada de voz CS. Se isso ocorrer, a parte chamada não saberá a identidade da parte chamadora. A parte chamada não será capaz de invocar uma seção IMS com a parte que chama porque a parte chamada não será capaz de enviar uma mensagem de convite para a parte que chama. Em outro caso, um usuário poderia chamar um serviço de assistência rodoviária mediante estabelecimento de uma chamada CS normal para um número de serviço. O sistema de

Petição 870170095015, de 06/12/2017, pág. 6/36

2/28 assistência rodoviária então seleciona dinamicamente um terminal disponível (agente) para terminar a chamada CS. Se o usuário desejar estabelecer uma seção IMS (digamos uma seção de Compartilhamento de Vídeo ou de Lousa Interativa) com o representante da assistência rodoviária, o usuário tentará iniciar uma seção IMS com o serviço de assistência rodoviária (por exemplo, sip:1154operator.com). Contudo, devido ao fato do usuário não conhecer a identidade do terminal exato do operador, o serviço IMS não será estabelecido. Em outro caso, um usuário poderia desejar comutar uma camada CS para uma rede IMS, mas seu usuário não conhece a identidade da outra parte, tal comutação não será possível. Consequentemente, o que é necessário é uma abordagem através da qual os serviços em um primeiro domínio são acoplados aos serviços em um segundo domínio.

Um documento apresentado pela Motorola intitulado “Origem CSI para números de serviço público, 3GPP TSG AS WG2#55, S2-063790, 23 -27 outubro 2006, divulga problemas de condução de serviços combinacionais (por exemplo chamada de voz CS e sessão IMS) com números de serviço público (por exemplo com números que não identificam de maneira exclusiva um único ponto final).

SUMÁRIO

De acordo com os aspectos da invenção, são fornecidos um método e um sistema, conforme descritos nas reivindicações anexas.

DESCRIÇÃO RESUMIDA DOS DESENHOS

Com o propósito de facilitar um entendimento da matéria em estudo que se pretende proteger, há modalidades ilustrativas no desenho anexo, a partir de uma inspeção da

Petição 870170095015, de 06/12/2017, pág. 7/36

3/28

qual, quando considerado	em	conexão com	a descrição	e
reivindicações a	seguir,	a	matéria em	estudo que	se
procurou proteger,	sua construção e operação, e muitas	de
suas vantagens	deve	ser	facilmente	entendidas	e
consideradas.
A Figura 1	ilustra	uma	modalidade	exemplar de	um

sistema incluindo um primeiro dispositivo e um segundo dispositivo que são capazes de uma troca de dados tanto no primeiro domínio como no segundo domínio.

A Figura 2 mostra o sistema na Figura 1 com o segundo domínio mostrado em maior detalhe.

A Figura 3 é um diagrama funcional exemplar de blocos do servidor de aplicação da Figura 2.

A Figura 4 é um fluxograma descrevendo a operação exemplar do sistema da Figura 1.

A Figura 5 é um fluxograma proporcionando uma descrição exemplar da criação de contexto de chamada no sistema da Figura 1.

A Figura 6 ilustra outra modalidade exemplar do sistema da Figura 1.

A Figura 7 é um diagrama de sinal proporcionando a descrição de operação exemplar do sistema da Figura 6.

DESCRIÇÃO DETALHADA

Em um exemplo, é provido um método. Uma solicitação é recebida a partir de um dispositivo em um segundo domínio quando uma chamada é estabelecida em um primeiro domínio. Um estabelecimento de uma chamada é detectado no primeiro domínio. Uma notificação é enviada ao dispositivo no segundo domínio quando a chamada é estabelecida no primeiro domínio.

Petição 870170095015, de 06/12/2017, pág. 8/36

4/28

Em outro exemplo, é provido um sistema. Um componente de interface recebe uma solicitação de uma subscrição a partir de um dispositivo em um segundo domínio para notificar o dispositivo quando uma chamada for estabelecida em um primeiro domínio. Um componente de processamento detecta um estabelecimento da chamada no primeiro domínio. Um componente de notificação que notifica o dispositivo quando a chamada é estabelecida.

Com referência à Figura 1, um sistema 10 em um exemplo compreende primeiro dispositivo 11, um segundo dispositivo 12, um primeiro domínio 13, e um segundo domínio 14.

Os dispositivos 11 e 12 em um exemplo são quaisquer dispositivos adequados operativos para enviar e receber dados de acordo com a operação de um sistema de comunicação sem fio. Exemplos de dispositivos 11, 12 incluem, mas não são limitados a: telefones celulares, telefones móveis, pagers, rádios, assistentes pessoais digitais (PDAs), terminais móveis de dados, computadores laptop, dispositivos de jogos de aplicação específica, dispositivos de videogame incorporando modems sem fio, e combinações ou subcombinações desses dispositivos. Tais dispositivos geralmente incluem componentes tais como processadores, controladores, componentes de memória, dispositivos de interface de usuário, lógica de transmissão de dados, interfaces de rede, antenas, e semelhantes. O modelo e operação desses dispositivos são bem conhecidos de modo que será omitida uma descrição detalhada de cada possibilidade.

Cada um dos domínios 13, 14 se refere a um ambiente no qual ao menos um serviço é provido. Cada domínio 13, 14 poderia ser compreendido de uma ou mais redes. Tais redes

Petição 870170095015, de 06/12/2017, pág. 9/36

5/28 incluem, mas não são limitadas a redes GSM, GPRS, CDMA, IDEN, 2.5G, 3G, e WiMAX (802.16e) . Além disso, os domínios 13, 14 poderiam constituir parte da mesma rede.

Para os propósitos dessa revelação, cada domínio 13, 14 será descrito como proporcionando ao menos um serviço que é distinto do outro domínio. Por exemplo, o domínio 13 poderia ser uma rede de comutação de circuito (CS) na qual serviço de voz CS tradicional é provido, e o domínio 14 poderia ser uma rede de Subsistema de Multimídia IP (IMS) na qual são providos os serviços, tal como, compartilhamento de vídeo e lousa interativa. O domínio 13 poderia ser compreendido de uma pluralidade de redes que proporcionam serviço de voz CS, e o domínio 14 poderia ser compreendido de uma pluralidade de redes que proporcionam serviço IMS. Além disso, os domínios 13, 14 poderiam fazer parte de uma única rede, tal como uma rede GSM, que suporta os serviços CS assim como os serviços IMS (isto é, o domínio 13 é um domínio CS, dentro de uma rede GMS; e o domínio 14 é um domínio IMS dentro da mesma rede GSM).

Com referência à Figura 2, uma descrição mais detalhada, ainda assim exemplar do sistema 10 será agora provida com propósitos de ilustração. Uma vez mais, com propósitos de ilustração, o domínio 13 será referido como um domínio CS, e o domínio 14 será referido como um domínio IMS. Contudo, tal descrição não deve ser considerada como limitando a presente aplicação a essa modalidade.

Com referência adicionalmente à Figura 2, o domínio IMS 14 inclui um servidor de aplicação 21 e um servidor de função de controle 22. Em um exemplo, o servidor de aplicação 21 é um Servidor de Aplicação de Identidade de

Petição 870170095015, de 06/12/2017, pág. 10/36

6/28

Comutação de Serviço (CSI-AS) e o servidor de função de controle 22 é um servidor de Função de Controle de Sessão de Chamada de Servidor (S-CSCF).

Como será discutido adicionalmente aqui, o CSI-AS 21 recebe notificações, a partir do domínio CS 13, das chamadas de voz envolvendo o dispositivo 12 e cria contextos para as chamadas que permitem que o dispositivo 12 invoque serviços no domínio IMS 14 que são estreitamente acoplados às chamadas de voz no domínio CS 13.

Em um exemplo, o servidor S-CSCF 22 e um servidor de protocolo de iniciação de sessão (SIP). S-CSCF provê controle para usuários do domínio IMS 14. Ele interage com a rede em nome do usuário e é alocado ao usuário durante o processo de registro SIP.

O servidor de aplicação 21 e o servidor de função de controle 22, em um exemplo, são formados de um ou mais componentes lógicos de software e/ou hardware de computador. Alguns de tais componentes podem ser combinados ou divididos. Em um exemplo, um componente exemplar de cada dispositivo emprega e/ou compreende uma série de instruções de computador gravadas em, ou implementadas com qualquer uma de algumas linguagens de programação, como será considerado por aqueles versados na técnica.

Com referência à Figura 3, os componentes exemplares de CSI-AS 21, incluem componentes de interface 31, 32, uma ou mais instâncias do componente de processador 33, uma ou mais instâncias do componente de memória 34, estrutura de dados 35, componente de criação de contexto 36, componente de notificação 37, e componente de comunicação de referência de chamada 38.

Petição 870170095015, de 06/12/2017, pág. 11/36

7/28

O componente de interface 31 em um exemplo é utilizado pelo CSI-AS 21 para enviar dados para/a partir do primeiro domínio 13. O componente de interface 32 em um exemplo é utilizado para enviar dados para/a partir do S-CSCF 22. O componente de processador 33 controla e realiza a funcionalidade do CSI-AS 21 mediante execução de código incorporado em hardware e/ou software. O componente de memória 34 provê meio de armazenamento no qual os dados, instruções, rotinas de software, conjuntos de código, bancos de dados, etc. podem ser armazenados. A estrutura de dados 35 em um exemplo é utilizada para armazenar informação de contexto de chamada gerada quando os dispositivos 11, 12 se engajam em chamadas no domínio CS

13. A estrutura de dados 35 pode ser armazenada na memória 34 ou pode ser um elemento autônomo. O componente de criação de contexto 36 é utilizado para criar um contexto de chamada quando o dispositivo 11 faz uma chamada CS para o dispositivo 12. O componente de notificação 37 é utilizado para notificar o dispositivo 11 quando o dispositivo 12 faz uma chamada para o dispositivo 11 através do segundo domínio 14. O componente de comunicação de referência de chamada 38 é utilizado para enviar uma referência de chamada para o dispositivo 12 após um contexto de chamada ser criado. O componente de criação de contexto 36, componente de notificação 37, e o componente de comunicação de referência de chamada 38 em um exemplo são executados no processador 33 e podem ser armazenados na memória 34, ou em outro local.

Por exemplo, em um exemplo, o sistema 10 inclui ao menos um meio portador de sinal legível por computador 39.

Petição 870170095015, de 06/12/2017, pág. 12/36

8/28

Um exemplo de um meio portador de sinal legível por computador 39 é um meio de armazenamento de dados gravável tal como um meio de armazenamento de dados de escala magnética, ótica, e/ou atômica. Em outro exemplo, um meio portador de sinal legível por computador 39 é um sinal de portadora, modulado, transmitido através de uma rede acoplada ao CSI-AS 21. Um meio portador de sinal legível por computador 39 pode armazenar componentes lógicos de software que podem ser empregados para realizar a funcionalidade aqui descrita.

Com referência à Figura 4, um método exemplar 400 de operação do sistema 10 será descrito agora para fins de exemplo.

Na etapa 401, o CSI-AS 21 recebe uma notificação a partir do domínio CS 13 de que o dispositivo 11 estabeleceu uma chamada CS para o dispositivo 12 no primeiro domínio 13. Em um exemplo, o domínio CS 13 é uma rede GSM. A sinalização de estabelecimento de chamada CC GSM no MSC de terminação (aquele servindo o dispositivo 12, mas não mostrado) ativa uma mensagem DP inicial de Aplicações Customizadas para Lógica Otimiza de Rede Móvel (CAMEL) em direção à Função de Controle de Serviço GSM (gsmSCF) do CSI-AS 21. Por sua vez, a gsmSCF envia uma resposta CAMEL direcionando o MSC para continuar o estabelecimento de chamada.

Em resposta à sinalização CAMEL, o CSI-AS 21 cria um contexto para a chamada CS na etapa 403. Com referência à Figura 5, na etapa 501, CSI-AS 21 extrai o ID do primeiro dispositivo 11 a partir da notificação recebida a partir do primeiro domínio 13. Em um exemplo, essa é informação de

Petição 870170095015, de 06/12/2017, pág. 13/36

9/28 identificação de chamador (CLID) a partir da chamada CS a partir do primeiro dispositivo 11 para o segundo dispositivo. Deve ser observado que se o dispositivo 11 invocou CLIR, a informação CLID não estará disponível para o dispositivo 12. Ainda assim, a informação CLID estará disponível para a rede do primeiro domínio 13. Consequentemente, o MSC de terminação proporcionará a informação CLID ao CSI AS 21.

Na etapa 503, o CSI-AS 21 cria uma referência de chamada. Em um exemplo, a referência de chamada é gerada pelo CSI-AS 21 utilizando um Nome de Recurso Uniforme (URN) de Identificador Universalmente Único (UUID), conforme especificado em Solicitação para Comentários (RFC) 4122, que é aqui incorporado mediante referência. O URN de UUID permite computação não-centralizada de um URN com base em tempo, nomes únicos, ou um gerador de número aleatório e garante singularidade através de espaço e tempo. Uma referência de chamada exemplar é: urn:uuid:f81d4fae-7dec11d0-a765-00a0c91e6bf6.

O contexto de chamada não é limitado a uma referência de chamada e a um identificador. Informação adicional poderia ser acrescentada ao contexto de chamada. Por exemplo, a informação de chamada, tal como números telefônicos da parte chamadora e da parte chamada, um número telefônico da parte de redirecionamento, status de invocação de CLIR, informação contida nos IEs de usuáriousuário, e qualquer outra informação importante contida nas mensagens de sinalização CC. Essa informação adicional poderia ser obtida pelo CSI-AS 21 através de sinalização CAMEL. Também pode ser possível para o CSI-AS 21 obter

Petição 870170095015, de 06/12/2017, pág. 14/36

10/28 informação adicional a partir de outros Servidores de Aplicação IMS que armazenam informação de chamada CS, tal como AS de Continuidade de Chamada de Voz (VCC) , por exemplo.

Com referência adicionalmente à etapa 505, o contexto de chamada em um exemplo é armazenado na estrutura de dados 35 de tal modo que a referência de chamada corresponde ao identificador para o primeiro dispositivo 11. Por exemplo, a referência de chamada e o identificador poderiam ser armazenados em uma tabela de dados.

Com referência agora à Figura 4, na etapa 405, a referência de chamada é enviada ao segundo dispositivo 12. Consequentemente, se o dispositivo 12 desejar invocar uma chamada IMS para o dispositivo 11, o dispositivo 12 não precisa conhecer a identidade do dispositivo 11. Mais propriamente, o dispositivo 12 pode iniciar uma chamada IMS através de CSI-AS 21 a qual realizou referência cruzada da identidade do dispositivo 11 com a referência de chamada.

CSI-AS 21 pode implementar a etapa 405 de diversas formas. Em um exemplo, o CSI-AS 21 inicia uma sessão de Dados de Serviço Suplementar Não-estruturado (USSD) com o dispositivo 12 e envia a referência de chamada dentro da sessão. Em outro exemplo, o CSI-AS 21 envia a referência de chamada para o segundo dispositivo 12 em uma mensagem de serviço de mensagens curtas (SMS). Em um exemplo adicional, o segundo dispositivo 12 solicita a referência de chamada a partir do CSI-AS 21 através da Internet por intermédio de uma interface de Rede (por exemplo, uma interface WAP). Em ainda um exemplo adicional, o pacote de evento SIP pode ser utilizado de tal modo que o segundo dispositivo 12 recebe

Petição 870170095015, de 06/12/2017, pág. 15/36

11/28 uma mensagem SIP NOTIFY a partir do CSI-AS que inclui referência de chamada. Uma discussão mais detalhada do pacote de eventos SIP será realizada aqui adicionalmente.

Com referência adicionalmente à Figura 4, como outra alternativa, mais propriamente do que enviar a referência de chamada para o segundo dispositivo 12, o segundo dispositivo 12 e o CSI-AS 21 poderiam individualmente gerar uma referência de chamada utilizando o mesmo conjunto de regras. Por exemplo, a referência de chamada poderia conter a seguinte informação: (1) A identidade do aparelho móvel (por exemplo, TMSI ou IMSI) atualmente em uso pela parte chamada quando ela aceitou a chamada (por exemplo, em PAGING REQUEST); e (2) O ID de Transação DTAP CC (TI) gerado pela rede e incluído na solicitação de CC Setup enviada à parte chamada (identifica a chamada CS específica para o aparelho móvel).

Continuando com referência à Figura 4, na etapa 407, o CSI-AS 21 recebe uma notificação de que o segundo dispositivo 12 deseja iniciar uma chamada IMS para o primeiro dispositivo 11.

Em um exemplo, o dispositivo 12 envia a solicitação para o CSI-AS 21 mediante endereçamento de uma solicitação SIP para a referência de chamada da chamada CS. Tal solicitação SIP pode ser gerada mediante uso de um SIP URI (por exemplo, SIP:combinational.operator.com) com um parâmetro callref=<callreference> para identificar a referência de chamada. (Por exemplo, SIP:combinational.operator.com;callref=<callreference>). O S-CSCF 22 no domínio IMS 14 aplica Critérios de Filtro Inicial (iFC) para P-Afirmada-Identidade para a solicitação

Petição 870170095015, de 06/12/2017, pág. 16/36

12/28

SIP e a partir da combinação com SIP URI, envia a solicitação SIP para o CSI-AS 21. O CSI-AS 21 então digita <callreference> e redireciona a solicitação para o número telefônico do dispositivo 11.

Em outro exemplo, o segundo dispositivo 12 endereça uma solicitação ao PSI do CSI-AS 21 com um parâmetro callref=<callreference> para identificar a referência de chamada em um parâmetro combinatório ou parte remota” para indicar que a parte remota da chamada CS está sendo endereçada. Por exemplo,

SIP:<CSI_AS_PSI>.operator.com;callref=<callreference>; combinational ou

SIP:<CSI_AS_PSI>.operator.com;callref=<callreference>; remote-party

Nesse caso, a solicitação SIP é encaminhada diretamente para o CSI-AS 21 (não há necessidade para iFC). O CSI-AS 21 então digita <callreference> e redireciona a solicitação para o número telefônico do dispositivo 11. Um AS PSI deve ser aprovisionado no terminal.

Em outro exemplo, a referência de chamada é integrada em um PSI curinga gerenciado pelo CSI-AS 21. A solicitação é então endereçada ao PSI curinga com um parâmetro combinatório ou parte remota para indicar que a parte remota da chamada CS está sendo endereçada. Por exemplo:

SIP:<CALL_REF_PSI>.operator . com;combinational ou

SIP:<CALL_REF_PSI>.operator . com;remote-party

Nesse caso, a solicitação SIP é encaminhada diretamente para o CSI-AS 21 onde o PSI curinga é gerenciado. O CSI-AS

Petição 870170095015, de 06/12/2017, pág. 17/36

13/28 então digita a chamada CS referenciada pelo PSI curinga e redireciona a solicitação para o número telefônico do dispositivo 11.

Finalmente, deve ser observado que o CSI-AS 21 deleta a chamada quando as partes terminam a chamada CS e o domínio CS 13 libera a chamada CS. Por exemplo, em uma rede GSM, a sinalização de liberação de chamada GSM CC no MSC de terminação inicia a sinalização CAMEL para a função gsmSCF do CSI-AS 21. Em resposta à sinalização CAMEL, o CSI-AS 21 deleta o contexto para a chamada do CS.

Com referência à Figura 6, um pacote de eventos SIP será descrito aqui agora. Outra modalidade do sistema 10 é mostrada na qual um ou mais dispositivos IMS 15 podem subscrever para um pacote de eventos SIP, o qual notificará os dispositivos IMS 15 quando um ou mais dispositivos CS engajarem em uma chamada. O sistema 10 é mostrado na Figura 6, como incluindo o dispositivo IMS 15, em adição ao primeiro dispositivo 11 e segundo dispositivo 12. Uma vez mais, o domínio 13 é descrito como um domínio CS; e o domínio 14 é descrito como um domínio IMS. Contudo, a presente aplicação deve ser considerada como limitada a essa modalidade.

O primeiro dispositivo, 11, e o segundo dispositivo 12 são mostrados como conectados ao domínio CS e o dispositivo 15 é mostrado como um dispositivo IMS conectado ao domínio IMS 14. Deve ser observado que esse arranjo é provido apenas com finalidades de ilustração. Diferentes combinações e subcombinações dos dispositivos 11, 12 e 15 são consideradas. Por exemplo, cada um dos dispositivos 11, 12 poderia incluir capacidade IMS e o dispositivo 15

Petição 870170095015, de 06/12/2017, pág. 18/36

14/28 poderia incluir capacidade CS. Consequentemente, o pacote de eventos SIP descreve a seguir os dispositivos, 11 e 12. Contudo, com o propósito de clareza, o pacote de eventos SIP será descrito com relação ao dispositivo 15. Adicionalmente, deve ser observado que os usuários do primeiro domínio 13 e do segundo domínio 14 poderiam ter individualmente múltiplos dispositivos IMS, os quais subscrevem para o pacote de eventos SIP aqui descrito, para um ou mais dispositivos CS possuídos, mas com a finalidade de brevidade, apenas os dispositivos 11, 12 e 15 são mostrados.

O pacote de eventos SIP é um exemplo de um Pacote de Eventos de Serviços de Chamada CS para o qual um usuário de um dispositivo IMS (por exemplo, dispositivo 15) pode subscrever. Mediante subscrição para o Pacote de Eventos de Serviço de Chamada SIP (referida em seguida como “o pacote SIP”), o usuário do dispositivo 15 pode informar o segundo domínio CSI-AS 21 para notificar o dispositivo 15 quando serviços específicos são iniciados no primeiro domínio 13. Por exemplo, o dispositivo 15 pode solicitar que o CSI-AS 21 notifique o dispositivo 15 quando uma chamada de voz CS é terminada para um dispositivo específico (por exemplo, dispositivo 11 ou dispositivo 12). O CSI-AS 21 identificará então e manterá a informação sobre a chamada CS e proporcionará a informação de chamada CS ao usuário do dispositivo 15.

Deve ser observado que se o dispositivo 15 e o dispositivo de interesse no domínio CS (por exemplo, dispositivo 11 ou dispositivo) for de propriedade do mesmo usuário, então subscrever para o pacote SIP é direto do

Petição 870170095015, de 06/12/2017, pág. 19/36

15/28 ponto de vista de segurança. Similarmente, se o dispositivo de interesse e o dispositivo 15 forem o mesmo dispositivo (por exemplo, uma unidade móvel com capacidade CS e capacidade IMS), então subscrever para o pacote SIP seria direto da perspectiva de segurança. Contudo, se o dispositivo de interesse e o dispositivo 15 forem dispositivos separados e de propriedade de usuários separados, então um ponto de vista de segurança, valeria à pena prover um mecanismo para verificar se o dispositivo 15 está autorizado a se descrever para informação de chamada CS relacionada ao dispositivo de interesse. Por exemplo, uma senha poderia ser exigida para uma subscrição ser efetiva, ou o proprietário do dispositivo em questão poderia ter que prover o sistema com uma autorização explícita para permitir que o dispositivo 15 subscreva, ou o proprietário do dispositivo poderia ter uma opção de ativar ou desativar configurações de segurança, e assim por diante.

O pacote SIP provê uma aplicação concreta da estrutura de eventos SIP especificada em RFC 3265, que é aqui incorporada mediante referência, e define os eventos e informação relacionada às chamadas CS do usuário para a qual um usuário IMS pode subscrever. O pacote de eventos de Serviços de Chamada CS pode notificar um assinante dos eventos, tal como uma chamada CS envolvendo o assinante sendo estabelecida (nesse caso, informação sobre a chamada também é transferida, por exemplo, a geração, terminação, do tipo de chamada, o modo de chamada, a referência de chamada no CSI-AS, etc.); um CS envolvendo o assinante sendo liberado; uma mudança de estado de chamada (por

Petição 870170095015, de 06/12/2017, pág. 20/36

16/28 exemplo, retenção de chamada); e outros eventos relacionados à CS (nova chamada CS em espera, etc.).

Essas notificações não necessariamente duplicam a informação que já está transmitida para o assinante através do domínio CS, mas, mais propriamente transmite ao usuário informação extra sobre esses eventos que podem ser usados no domínio IMS (por exemplo, uma referência de chamada). O assinante pode escolher não subscrever para todos os eventos possíveis. Por exemplo, o assinante pode escolher subscrever apenas para o evento “estabelecido por CS” (em cujo caso ele não será notificado quando a chamada é liberada ou seu status é mudado). Essa escolha pode ser especificada mediante inclusão de um documento de filtro no corpo de uma solicitação SIP SUBSCRIBE.

Exemplos do uso de pacote SIP no sistema 10 incluem, mas não são limitados aos seguintes: Um único assinante IMS poderia ter múltiplos dispositivos com capacidade IMS. Cada dispositivo pode obter informação sobre as chamadas CS estabelecidas nos dispositivos CS e usar essa informação para iniciar serviços IMS relacionadas a essas chamadas CS. Um dispositivo WLAN/VoIP pode solicitar receber uma chamada de voz simultaneamente ativa em um dispositivo GSM. Um usuário pode iniciar uma sessão de vídeo IMS com um dispositivo anônimo. Um usuário pode iniciar chamadas combinatórias para centros de chamada mesmo se o terminal, ao qual o usuário está conectado, for anônimo (vide o centro de assistência rodoviária descrito acima).

Com referência adicionalmente à Figura 6, em um exemplo, o CSI-AS 21 identifica e mantém informação de uma maneira similar àquela da etapa 403 do método 400. Por

Petição 870170095015, de 06/12/2017, pág. 21/36

17/28 exemplo, o CSI-AS 21 cria um contexto de chamada que contém uma referência de chamada e um identificador para o primeiro dispositivo. Em adição a esses elementos, o contexto de chamada poderia conter informação adicional, tal como números de telefone de parte que chama e de parte chamada, um número de telefone de parte de redirecionamento, status de invocação CLIR, informação contida nos IEs de usuário-usuário, e qualquer outra informação importante contidas nas mensagens de sinalização CC. Em outro exemplo, o CSI-AS 21 poderia obter informação adicional a partir de outros Servidores de Aplicações IMS que armazenam informação de chamada CS, tal como a AS de Continuidade de Chamada de Voz (VCC).

Em um exemplo, quando uma chamada CS de geração ou terminação está sendo estabelecida com um dos dispositivos 11, 12, procedimentos CAMEL são invocados para encaminhar as mensagens de controle de chamada CS para o CSI-AS 21 que estabelece e armazena o contexto de chamada. Como com o sistema mostrado na Figura 1, o mesmo mecanismo é utilizado quando uma chamada CS é liberada. Um procedimento CAMEL é invocado pelo MSC do domínio CS para enviar uma notificação para o CSI-AS 21. O CSI-AS 21 então remove o contexto de chamada CS.

Com referência agora à Figura 7, o pacote SIP será descrito agora em maior detalhe para fins ilustrativos.

O dispositivo 15, em um exemplo, é um terminal IMS. O dispositivo 15 subscreve para o pacote SIP mediante envio de uma mensagem SUBSCREVER 701 para o CSI-AS 22 através do S-CSCF 21. A subscrição (solicitação SUBSCREVER) é atendida pelo CSI-AS 21. Após receber a solicitação SUBSCREVER, o

Petição 870170095015, de 06/12/2017, pág. 22/36

18/28

CSI-AS 22 envia uma mensagem de resposta OK 703 ao dispositivo 15 através do S-CSCF 21.

O pacote SIP habilita o CSI-AS 21 a prover o usuário do dispositivo 15 com informação sobre chamadas CS em andamento com os dispositivos no domínio CS. As notificações de evento de pacote SIP (isto é, solicitação NOTIFICAR SIP) podem prover várias informações para cada chamada CS com a qual o assinante está conectado: uma referência de chamada identificando singularmente a chamada na rede IMS; os números telefônicos da parte que chama e da parte chamada; um número de telefone de parte de redirecionamento; um status de invocação CLIR; informação contida nos IEs Usuário-usuário; outra informação importante contida nas mensagens de sinalização CC.

Uma descrição exemplar do formato do pacote de evento é como a seguir:

Nome de Pacote de Evento: cs-chamando-serviço

NOTIFICAR: documento XML

Nome de tipo de mídia MIME: aplicação

Nome de subtipo MIME: cscallinfo+xml

URI-Solicitação SOBRESCREVER: TEL URL ou TelURL no formato SIP URI. Deve ser uma IMPU registrada.

Cabeçalho SUBSCREVER para: O mesmo que URI Solicitação.

A solicitação SUBSCREVER é endereçada a um TEL URL registrado ou TEL URL no formato SIP URI (isto é, IMPU registrada). Critérios de filtro associados com TEL URL encaminham a solicitação SUBSCREVER inicial para o CSI-AS 21. O CSI-AS 21 utiliza a IMPU endereçada na URISolicitação como uma chave para acessar os contextos de

Petição 870170095015, de 06/12/2017, pág. 23/36

19/28 chamada CS para aquele usuário.

No caso onde um único assinante IMS tem múltiplos dispositivos com capacidade IMS utilizando a mesma IMPU de número telefônico, então subscrições para pacote de evento SIP podem ser estabelecidos a partir de qualquer um desses dispositivos. Isso permite que um usuário obtenha informação sobre as chamadas CS estabelecidas em outros dispositivos e potencialmente use essa informação para iniciar serviços IMS relacionados àquelas chamadas CS a partir de um dispositivo diferente.

Uma solicitação de subscrição exemplar 701, para informação relacionada a um número telefônico (35850482137) é agora provida para fins de ilustração:

SUBSCREVER te.:+35850482137 SIP/2.0

Via: SIP/2.0/UDP 192.0.2.3:1357; comp=sigcomp; branch=z9hG4bKnashds7

Max-Envio: 70

Rota:<sip:pcscf1.visited1.net:7531;1r;comp=sigcomp>

Rota:<sip:orig@scscf1.home1.net;1r>

P-Preferida-Identidade: “Dr John” <tel:+35850482137>

P-Acesso-Rede-Info:3GPP-UTRAN-TDD;utran-cell-id3gpp=234151D0FCE11

Privacidade: nenhuma

A partir de: <tel:35850482137> Indicador=31415

Para: <tel:35850482137>

ID de Chamada:b89rjhnedlrfjflslj40a222

Requer: sec-concordância

Proxy-Requer: sec-concordância

CSeq: 61 SUBSCRIBE

Evento> cs-chamando-serviço

Petição 870170095015, de 06/12/2017, pág. 24/36

20/28

Expira: 3600

Aceitar : application/cscallinfo+xml

Segurança-Verificar: ipsec-3gpp; q=0.1; alg=hmac-sha1-96; spi-c=98765432; spi-s=87654321; port-c=8642;ports=7531

Contato: <sip:192.0.2.3:1357;comp=sigcomp>

Conteúdo-Extensão: 0

Com referência outra vez à Figura 7, periodicamente, o SCI-AS 22 enviará mensagens NOTIFICAR 703 através do S-CSCF 21 para o dispositivo 15 indicando que nenhuma informação de chamada CS foi gerada. O dispositivo 15 enviará mensagens de confirmação OK 704 de volta para CSI-AS 21.

Quando uma chamada é estabelecida ou no dispositivo 11 ou no dispositivo 12 no domínio CS 13, o MSC do domínio CS 13 enviará uma mensagem CAMEL 705 para o CSI-AS 22 notificando a ele que uma chamada CS foi estabelecida. CSIAS 22 enviará uma mensagem NOTIFICAR 706 através do S-CSCF 21 para o dispositivo 15. O dispositivo 15 responderá com mensagens de confirmação OK 707.

Se uma segunda chamada for estabelecida no dispositivo 12 no domínio CS 13, o MSC do domínio CS 13 enviará uma mensagem CAMEL 708 para o CSI-AS 22 notificando a ele que uma chamada CS foi estabelecida. O CSI-AS 22 enviará uma mensagem NOTIFICAR 709 através do S-CSCF 21 para o dispositivo 15. O dispositivo 15 responderá com uma mensagem de confirmação OK 710.

Uma mensagem SIP exemplar, mensagem NOTIFICAR 709 enviada pelo CSI-AS 22 ao dispositivo 15 quando uma segunda chamada CS é estabelecida para um número telefônico exemplar (35850482137) é mostrada para fins ilustrativos.

Petição 870170095015, de 06/12/2017, pág. 25/36

21/28

SIP NOTIFICAR: 192.0.2.3:1357;;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP pcscfl.visited1.net:7531;comp=sigcomp;branch=z9hG4bK240f34.

1,

SIP/2.0/UDP scscf1.home1.net;branch= z9hG4bK332b23.1,

SIP/2.0/UDP csi-as.home1.net;branch= z9hG4bK846ht53.1, Max-Envios: 69

A partir do: <tel:+35850482137> indicador=151170

Para: <tel:+35850482137> indicador= 31415

ID de Chamada: b89rjhnedlrfjflslj40a222

CSeq:42 NOTIFY

Subscrição-Estado: ativo; expira=1580

Evento: cs-chamando-serviços Conteúdo-Tipo: aplicação/cscallinfo+xml Contato:<sip:csi-as.home1net>

Conteúdo-Comprimento (---) <?xml version=1.0?>

<cscallinfo .......

<informação relacionada a chamada CS n°1>

<informação relacionada a chamada CS n°2> </cscallinfo>

Se a segunda chamada for liberada, uma mensagem CAMEL 711 é enviada a partir do domínio CS 13 para CSI-AS 22. CSI-AS 22 enviará uma mensagem NOTIFICAR 712 através de SCSCF 21 ao dispositivo 15. O dispositivo 15 responderá com mensagens de confirmação OK 713.

Se a primeira chamada for liberada, uma mensagem CAMEL 714 é enviada a partir do domínio CS 13 para CSI-AS 22. CSI-AS 22 enviará uma mensagem NOTIFICAR 715 através de SPetição 870170095015, de 06/12/2017, pág. 26/36

22/28

CSCF 21 ao dispositivo 15. O dispositivo 15 responderá com mensagens de confirmação OK 716.

Com referência adicionalmente à Figura 7, durante a primeira ou segunda chamada CS, o usuário do dispositivo IMS 15 poderia usar a informação provida nas notificações de pacote SIP para invocar serviços IMS que estão estreitamente acoplados às chamadas CS, específicas. Esses serviços podem ser direcionados para a própria chamada CS ou podem ser direcionados para a parte remota da chamada CS. Para suportar o direcionamento de invocações de serviço IMS para chamadas CS específicas identificadas nas notificações de pacote de eventos de Serviços de Chamada CS, um parâmetro SIP URI denominado callref” é usado. Esse parâmetro tem a seguinte sintaxe:

callref=<call reference>, onde <call reference> é a referência de chamada retornada nos Serviços de Chamada CS. Uma referência de chamada exemplar é:

callref=urn:uuid:f81d4fae-7dec-11d0765-00a0c91e6bf6.

Como uma alternativa, a referência de chamada poderia ser integrada em um PSI curinga gerado pelo CSI-AS e provido ao usuário IMS nas notificações de pacote de eventos de Serviços de Chamada CS. Nesse caso, em vez de usar o parâmetro callref, a solicitação SIP seria endereçada diretamente ao PSI curinga.

Exemplos ilustrando o uso do Pacote de Eventos de Chamada CS serão providos agora com propósitos ilustrativos.

Uma chamada CS, com CLIR invocado é estabelecida e a parte chamada deseja iniciar um serviço combinatório, mas ele não pode porque o número telefônico da parte que chama

Petição 870170095015, de 06/12/2017, pág. 27/36

23/28 é desconhecido. Consequentemente, ele endereça uma solicitação SIP para a referência de chamada indicando serviço combinatório. Em um exemplo, a parte chamada utiliza um SIP URI indicando acesso ao contexto de chamada CS armazenado (por exemplo, SIP:csi-service.operator.com) com um parâmetro callref para identificar a referência de chamada e um parâmetro combinatório ou “parte remota” para indicar que a parte remota da chamada CS está sendo endereçada. Exemplo:

SIP:csi-service.operator.com;callref=<callreference>; combinational ou

SIP:csiervice.operator.com;callref=<callreference>;remote-party

Se iFC para P-Afirmada-Identidade for aplicado à solicitação SIP na rede IMS de origem (rede IMS da parte chamada) e a partir da combinação do SIP URI, a solicitação SIP é enviada para o CSI-AS. O CSI-AS então digita <callreference> e redireciona a solicitação para o número telefônico da parte que chama.

Em outro exemplo, a parte chamada utiliza um SIP URI indicando serviço combinatório (por exemplo, SIP:combinational.operator.com ou SIP:remoteparty.operator.com) com um parâmetro callref para identificar a referência de chamada. Exemplo:

SIP:csicombinational.operator.com;callref=<callreference> ou

SIP:csiremoteparty.operator.com;callref=<callreference>

Petição 870170095015, de 06/12/2017, pág. 28/36

24/28

O iFC para P-Afirmada-Identidade é aplicado à solicitação SIP na rede IMS de origem (rede IMS da parte chamada) e a partir da combinação do SIP URI, a solicitação SIP é enviada ao CSI-AS. O CSI-AS 21 então digita <callreference> e redireciona a solicitação para o número telefônico da parte que chama.

Em outro exemplo, uma solicitação é endereçada ao PSI do CSI-AS 21 com um parâmetro callref=<callreference> para identificar a referência de chamada e um parâmetro combinatório ou parte remota” para indicar que a parte remota da chamada CS está sendo endereçada. Exemplo:

SIP:<CSI_AS_PSI>.operator.com;callref=<callreference>; combinational ou

SIP:<CSI_AS_PSI>.operator.com;callref=<callreference>; remote-party

O CSI-AS 21 então digita <callreference> e redireciona a solicitação para o número telefônico da parte que chama. Um CSI-AS PSI deve ser aprovisionado no terminal.

Como uma alternativa ao uso do parâmetro callref, o usuário IMS também pode endereçar a invocação de serviço IMS diretamente a um PSI curinga com base na referência de chamada. Esse CALL_REF_PSI seria incluído nas notificações de eventos Serviços de Chamada CS para o usuário. A referência de chamada é integrada em um PSI curinga gerenciado pelo CSI-AS 21. A solicitação é então endereçada ao PSI curinga com um parâmetro combinatório ou parte remota para indicar que a parte remota da chamada CS está sendo endereçada. Exemplo:

SIP:<CALL_REF_PSI>.operator.com;combinational

Petição 870170095015, de 06/12/2017, pág. 29/36

25/28 ou

SIP:<CALL_REF_PSI>.operator . com;remote·	-party
Nesse	caso,	a	Solicitação SIP	é	encaminhada
diretamente	para	o	SCI-AS 21 onde o	PSI	curinga é
gerenciado.	O CSI-AS	21 então digita	a	chamada CS
referenciada	pelo	PSI	curinga e redireciona a	solicitação

para o número telefônico da parte que chama. Observar que o serviço combinatório pode ser iniciado a partir de um dispositivo diferente do dispositivo hospedando a chamada CS se ambos os dispositivos compartilharem o mesmo TEL URL IMPU registrado.

Em outro exemplo, um usuário IMS com uma chamada CS estabelecida decide comutar a chamada para o domínio IMS. Consequentemente, ele endereça uma solicitação SIP para a referência de chamada indicando comutação. Várias abordagens alternativas são propostas.

O usuário envia um SIP URI indicando acesso ao contexto de chamada CS armazenado (por exemplo, SIP:csiservice.operator.com) com um parâmetro callref para identificar a referência de chamada e um parâmetro comutação para indicar que a chamada CS deve ser handed off para o IMS. Exemplo:

SIP:csiervice.operator.com;callref=<callreference>;handoff

O iFC para P-Afirmada-Identidade é aplicado à solicitação SIP na rede SIP de origem e a partir da combinação do SIP URI, a solicitação SIP é enviada ao CSIAS 21. O CSI-AS 21 então digita <callreference> e o parâmetro comutação e re-encaminha a solicitação para o VCC AS (isto é, CCCF/NeDS)(O VCC AS e o CSI-AS poderiam ser

Petição 870170095015, de 06/12/2017, pág. 30/36

26/28 co-localizados. Se não forem, então um mecanismo para correlacionar as referências de chamada CS através de ambos os servidores poderia ser exigido) onde o procedimento de comutação é executado.

O usuário envia um SIP URI indicando serviço VCC (por exemplo, SIP:vcc.operator.com) com um parâmetro callref para identificar a referência de chamada e um parâmetro comutação para indicar que a chamada CS deve ser handed off para o IMS. Exemplo:

SIP:vcc.operator.com;callref=<callreference>;handoff

O iFC para P-Afirmada-Identidade é aplicado à Solicitação SIP na rede SIP de origem e a partir da combinação do SIP URI, a solicitação SIP é enviada ao CSIAS 21. O CSI-AS 21 então digita <callreference> e reencaminha a solicitação ao VCC AS (isto é, CCCF/NeDS) onde o procedimento de comutação é executado.

O usuário endereça uma solicitação ao PSI do CSI-AS 21 com um parâmetro callref=<callreference para identificar a referência de Chamada e um parâmetro comutação para indicar que a chamada CS deve ser handed off para o IMS. Exemplo:

SIP:<CSI_AS_PSI>.operator.com;callref=<callreference>; handoff

A solicitação encaminhada diretamente ao CSI-AS 21, o qual então digita <callreference> e re-encaminha a solicitação para o VCC AS (isto é, CCCF/NeDS) onde o procedimento de comutação é executado. Um CSI-AS PSI deve ser aprovisionado no terminal.

Como uma alternativa ao uso do parâmetro callref, o usuário IMS também pode endereçar a invocação de serviço

Petição 870170095015, de 06/12/2017, pág. 31/36

27/28

IMS diretamente a um PSI curinga com base na referência de chamada. Essa CALL_REF_PSI seria incluída nas modificações de eventos Serviços de Chamada CS para o usuário. A referência de chamada é embutida em um PSI curinga gerenciado pelo CSI-AS. A solicitação é então endereçada ao PSI curinga com um parâmetro comutação para indicar que a chamada CS deve ser handed off para o IMS. Exemplo:

SIP:<CALL_REF_PSI>.operator . com;handoff

Nesse caso, a Solicitação SIP é encaminhada diretamente ao CSI-AS 21 onde o PSI curinga é gerenciado. O CSI-AS então digita a chamada CS referenciada pelo PSI curinga e re-encaminha a solicitação ao VCC AS (isto é, CCCF/NeDS) onde o procedimento de comutação é executado. Observar que a comutação pode ser iniciada a partir de um dispositivo diferente do dispositivo hospedando a chamada CS se ambos os dispositivos compartilharem o mesmo TEL URL IMPU registrado.

Deve ser observado que a descrição precedente do pacote SIP incluiu nomes de parâmetro, por exemplo, callref, parte-remota, comutação, etc. Esses nomes foram fornecidos apenas para fins ilustrativos. Outros nomes podem ser substituídos desde que o significado (ou seja, o contexto dentro do pacote SIP) permaneça conforme estabelecido neste documento.

Embora formas de realização especificas tenham sido mostradas e descritas, será evidente para um técnico no assunto que mudanças e modificações podem ser feitas sem se afastarem dos princípios aqui estabelecidos. A matéria estabelecida no relatório descritivo acima e os desenhos anexos são oferecidos apenas a título de ilustração e não

Petição 870170095015, de 06/12/2017, pág. 32/36

28/28 como uma limitação.

Claims

REIVINDICAÇÕES

1. Método, caracterizado por compreender:

receber uma solicitação em um domínio de telefonia IP partir de um dispositivo para notificar o dispositivo quando uma chamada for estabelecida em um domínio CS com pelo menos um outro dispositivo, criando um contexto de chamada no domínio de telefonia IP sobre a chamada estabelecida no domínio CS;

enviar uma notificação, baseada no contexto da chamada, no domínio de telefonia IP ao dispositivo quando a chamada for estabelecida no domínio CS;

iniciar uma sessão IP no domínio de telefonia IP entre o dispositivo e o pelo menos um outro dispositivo em resposta à notificação.
2. Método, de acordo com a reivindicação 1, caracterizado por compreender ainda:

detectar o estabelecimento da chamada no domínio CS.
3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a etapa de criar o contexto de chamada compreende:

gerar uma referência de chamada; e armazenar a referência de chamada em um componente de memória do domínio de telefonia IP.
4. Método, de acordo com a reivindicação 3, caracterizado por compreender ainda:

enviar a referência de chamada para o dispositivo.
5. Método, de acordo com a reivindicação 4, caracterizado pelo fato da etapa de enviar compreender:

enviar uma mensagem do Serviço de Mensagens Curtas (SMS) para o dispositivo que inclui a referência de

Petição 870170095015, de 06/12/2017, pág. 34/36

2/3 chamada.
6. Método, de acordo com a reivindicação 4, caracterizado por compreender:

enviar uma mensagem de NOTIFICAR de Protocolo de Iniciação de Sessão (SIP) para o dispositivo que inclui a referência de chamada.
7. Sistema, caracterizado por compreender:

um componente de interface que está configurado para receber uma solicitação de subscrição em um domínio de telefonia IP a partir de um dispositivo para notificar o dispositivo quando uma chamada for estabelecida em um domínio CS com pelo menos um outro dispositivo;

um componente de criação de contexto que está configurado para criar um contexto de chamada no domínio de telefonia IP sobre a chamada estabelecida no domínio CS; e um componente de notificação que está configurado para notificar o dispositivo, no domínio de telefonia IP, sobre o contexto da chamada quando a chamada for estabelecida no domínio CS, em que o componente de interface está configurado para iniciar uma sessão de IP no domínio de telefonia IP entre o dispositivo e o pelo menos um outro dispositivo em resposta à notificação do componente de notificação.
8. Sistema, de acordo com a reivindicação 7, caracterizado pelo fato de que o componente de criação de contexto compreende ainda:

um componente de geração de referência de chamada que está configurado para gerar uma referência de chamada para a chamada, em que o sistema compreende ainda um componente de memória para armazenar a referência de chamada.

Petição 870170095015, de 06/12/2017, pág. 35/36

3/3
9. Sistema, de acordo com a reivindicação 8, caracterizado por compreender ainda:

um componente de comunicação de referência de chamada que está configurado para enviar a referência de chamada 5 para o dispositivo no domínio de telefonia IP.
10. Sistema, de acordo com a reivindicação 9, caracterizado pelo fato de que o componente de comunicação de referência de chamada compreende:

um componente de processamento que está configurado

10 para enviar uma mensagem de Serviço de Mensagens Curtas (SMS) ao dispositivo que inclui a referência de chamada.
11. Sistema, de acordo com a reivindicação 9, caracterizado pelo fato de que o componente de comunicação de referência de chamada compreende:
15 um componente de protocolo de iniciação de sessão (SIP) que está configurado para enviar uma mensagem de NOTIFICAR SIP ao dispositivo que inclui a referência de chamada.