BRPI0520075B1

BRPI0520075B1 - método e aparelho para obter informação de contexto proveniente de um servidor de contexto

Info

Publication number: BRPI0520075B1
Application number: BRPI0520075A
Authority: BR
Inventors: Hjelm Johan; Lidström Mattias; Kanter Theo
Original assignee: Ericsson Telefon Ab L M
Priority date: 2005-04-26
Filing date: 2005-10-04
Publication date: 2018-12-26
Also published as: BRPI0520075A2; CN101167335A; KR20080013870A; JP2008539500A; KR101126974B1; EP1875719B1; EP1875719A1; US8341174B2; CN101167335B; JP4809421B2; ZA200708898B; US20090132540A1; WO2006115442A1

Abstract

método e aparelho para obter informação de contexto proveniente de um servidor de contexto. um método e aparelho para obter informação de contexto de um servidor de contexto (318) mantendo um contexto para um objeto de interesse (306a), em uma rede de telecomunicação. o servidor de contexto recebe dados de contexto brutos de sensores (306) associados com o objeto de interesse. uma solicitação é recebida proveniente de uma parte solicitante para informação de contexto refinada com referência ao objeto de interesse. dados de contexto individuais são coletados de pelo menos uma entidade individual (316) da parte solicitante. uma regra customizada é criada com base nos dados de contexto individuais recebidos. a regra define condições em uma solicitação adaptada para informação de contexto refinada considerando o objeto de interesse, que é enviada, incluindo a regra customizada, para o servidor de contexto do objeto de interesse. dados de contexto refinados de acordo com a regra de customização são então recebidos provenientes do servidor de contexto.

Description

“MÉTODO E APARELHO PARA OBTER INFORMAÇÃO DE CONTEXTO PROVENIENTE DE UM SERVIDOR DE CONTEXTO” CAMPO TÉCNICO [001] A presente invenção geralmente se refere a um método e arranjo para fornecer ou obter informação de contexto solicitada em uma rede de telecomunicação. Em particular, a invenção está preocupada com fornecer ou obter informação de contexto de acordo com especificações da parte solicitante.

FUNDAMENTO DA INVENÇÃO E ARTE ANTERIOR [002] Com o advento da telefonia móvel de 3G, novas tecnologias de comunicação baseada em pacotes foram desenvolvidas para comunicar conteúdo de multimídia. Por exemplo, tecnologias de GPRS (Serviço de Rádio de Pacote Geral) e de WCDMA (Acesso Múltiplo por Divisão de Código de Banda Larga) suportam serviços de telefonia de multimídia sem fio envolvendo comunicação de dados por comutação de pacote representando imagens, texto, documentos, animações, arquivos de áudio, clipes de vídeo, etc., em adição as chamadas de voz por comutação de circuito. Adicionalmente, novos terminais de rádio móvel também estão emergindo no mercado, equipados com funcionalidades para tratar os novos serviços, incluindo mostradores coloridos de alta resolução e múltiplos codecs (codificadores/decodificadores) para diferentes formatos. Estes terminais são também tipicamente capazes de tecnologias de acesso diferentes, dependendo da configuração de rede e características da célula.

[003] Recentemente, uma arquitetura de rede de serviço chamada “Sistema de Multimídia de PI” (IMS) foi desenvolvida pela 3^rf Generation Partnership Project (3GPP) como um padrão opcional, para fornecer serviços de multimídia para clientes de rádio móvel no domínio do pacote. Geralmente, IMS é uma plataforma para permitir serviços baseados em transporte do IP, mais ou menos independente da tecnologia de acesso usada e

Petição 870180071254, de 15/08/2018, pág. 10/44

2/30 basicamente não restrita a qualquer conjunto limitado de serviços específicos. [004] Uma especificação ara estabelecimento de sessão foi definida chamada “SIP” (Protocolo de Iniciação de Sessão, de acordo com o padrão IETF RFC 3261 et al., que é um protocolo de sinalização de camada de aplicação para controlar (e. g. criar, modificar e terminar) sessões sob uma lógica de comutação de pacote. SIP é geralmente usado por redes de IMS para tratar sessões de multimídia. Também, extensões do protocolo SIP básico podem ser usadas, referenciadas como “Simples”, para tratar alguns serviços. [005] Fig. 1 ilustra esquematicamente um favorito cenário de comunicação básico simplificado para fornecer serviços de multimídia por meio de uma rede serviço de IMS. Deve ser observado que a figura somente mostra uma seleção de elementos de rede úteis para entender a tecnologia do fundamento para a presente invenção. Brevemente descrita, um terminal de rádio móvel A chamando é conectado a uma primeira rede de acesso via rádio 100 e se comunica com um terminal de rádio móvel B chamado conectado a uma segunda rede de acesso via rádio 102, em uma sessão de comunicação S envolvendo um ou mais serviços de multimídia. Altemativamente, terminal A pode se comunicar com um terminal fixo ou computador, ou com um servidor de conteúdo despachando algum conteúdo de multimídia para o terminal, tal com uma peça de música, um filme ou um jogo. Os terminais A, B podem também se comunica com servidores na rede de IMS fornecendo serviços de informação, a ser descrita abaixo.

[006] Uma rede de IMS 104 é mostrada conectada à primeira rede de acesso via rádio 100 e trata a sessão de multimídia S com relação ao terminal A. Assim sendo, a rede de IMS 104 recebe e processa qualquer solicitação de serviço proveniente do terminal A. Similarmente, uma rede de IMS 104 correspondente trata a sessão S em nome do terminal B, e as duas redes de IMS 104 e 106 podem ser controladas por diferentes operadores. Altemativamente, terminais A, B podem naturalmente ser conectados a

Petição 870180071254, de 15/08/2018, pág. 11/44

3/30 mesma rede de acesso e/ou podem ser atendidos pela mesma rede de IMS.

[007] A sessão S ilustrada é controlada, usando sinalização de SIP, através de vários nós de gerenciamento de sessão adequados, geralmente indicados por um bloco 108. Tipicamente, os tipos de nós de gerenciamento de sessão incluem S_CSCF (Função de Controle de Sessão de Chamada de Serviço), I-CSCF (Função de Controle de Sessão de Chamada de Interrogação) e P-CSCF (Função de Controle de Sessão de Chamada de Proxy). Serviços de multimídia invocados são permitidos e executados através de uma grande quantidade de servidores de aplicação 110. Adicionalmente, um elemento de banco de dados principal HSS (Servidor de Assinante Doméstico) 112 armazena dados de assinante e de autenticação assim como informação de serviço, entre outras coisas, que os servidores de aplicação 110 podem pegar para executar serviços ao cliente. As várias funções dos elementos de rede de IMS 108-112 não são necessárias descrever aqui para entender a presente invenção. Naturalmente, a rede de IMS 104 também contém numerosos outros nós e funções, que não são mostrados aqui por motivo de simplicidade.

[008] Um exemplo de serviços que podem ser empregados por meio de uma rede de IMS são os assim chamados serviços de “Presença”. Nestes tipos de serviços, “Presença” é basicamente um estado de perfil variável e dinâmico de um cliente, e os serviços de presença basicamente envolvem a divulgação de “dados de presença” de um cliente para fazê-lo disponível para outros usuários e aplicações, que também podem, por sua vez, serem usados para controlar outros serviços. Dados de presença basicamente definem o estado ou situação de um cliente e seu equipamento em alguma relação predefinida. Assim sendo o termo “presença” é aqui dado com um bem largo significado, e os dados de presença podem incluir e. g., aos seguintes “estados de cliente”:

- Um estado de cliente, e. g. disponível, ocupado, em uma

Petição 870180071254, de 15/08/2018, pág. 12/44

4/30 reunião, de férias, etc.

- Um estado de terminal, e. g. ligado sim/não, acionado, fora de cobertura, etc.

- Uma localização geográfica do cliente/terminal.

- Capacidades e seleções do terminal, e. g. funcionalidade para SMS, MMS, bate-papo, jogos, vídeo, etc.

- Outra informação de cliente pessoal, e. g. interesses, ocupações, características pessoais, humor, etc.

[009] Esta informação, ou qualquer parte selecionada delas, é armazenada em um servidor de aplicação na rede de IMS, baseada na assim chamada “publicações de eventos” recebida proveniente da rede ou de um cliente, sempre que o cliente muda qualquer de seus dados de presença. Um cliente também pode assinar por dados de presença selecionados de um ou mais outros usuários, e. g. de acordo com a lista de usuários. Tais assinaturas de presença são tipicamente também tratadas por um servidor de aplicação na rede de IMS. O cliente assinante pode então receber notificações considerando dados de presença correntes, ou automaticamente ou sob solicitação. No SIP, uma mensagem chamada “SIP PUBLISH” pode ser usada por clientes para fornecer dados dinâmicos para um servidor de aplicação na rede de IMS. Adicionalmente, uma outra mensagem de SIP chamada “SIP SIBSCRIBE” pode ser usada por clientes para assinar por dados dinâmicos de outros clientes, como tratada pelo servidor de aplicação.

[0010] Em sistema de telecomunicação tradicional, canais de comunicação são mais ou menos fixos e estáticos com taxas de bits e protocolos prognosticáveis. Usando as novas tecnologias de aceso, contudo, o ambiente de rede se toma mais dinâmico e heterogêneo para os usuários, com grandes variações dos recursos de comunicação disponíveis nas redes sem fio, já que tipos diferentes de conexões podem ser usados, mesmo dentro de uma sessão de chamada. Como um resultado, taxas de bits e modulação e

Petição 870180071254, de 15/08/2018, pág. 13/44

5/30 esquemas de codificação se tomam altamente variáveis. Ainda, usuários se movendo dentro e entre redes esperam serem capazes de acessar e utilizar uma variedade de serviços apesar de tais variações. É, por conseguinte, desejável desenvolver serviços que podem ser adaptados, ou “sob medida”, para a situação de usuário e ambiente de rede correntes.

[0011] Recentemente, um conceito foi desenvolvido para fornecer informação refinada sobre objetos para aumentar a usabilidade de aplicações por serviços invocados, dependendo da situação corrente do objeto. Um “objeto” neste respeito é tipicamente um usuário humano, mas também pode ser um dispositivo físico ou aparelho, ou uma empresa oferecendo mercadorias ou serviços para clientes. O termo “objeto de interesse” será usado nesta descrição para representar qualquer desses objetos. Este novo conceito é geralmente referenciado como a distribuição de informação de “contexto”, que pode ser implementada usando mecanismo similares como dos serviços de presença descritos acima. É, por conseguinte, desejável desenvolver aplicações “a par de contexto” para realizar serviços otimamente adaptado a circunstâncias prevalecentes.

[0012] Isto pode ser ilustrado por um simples exemplo quando um serviço de telecomunicação envolvendo um auxílio à navegação, foi invocado por um usuário de rádio móvel. Um contexto pode então ser definido em um servidor de IMS para aquele usuário, sendo o objeto de interesse neste caso. O contexto pode ser mantido no servidor e. g., para, enquanto o usuário estiver conectado ou ele/ela for um assinante na rede serviço de IMS. Uma aplicação usada para este serviço pode então investigar o contexto corrente do usuário e fornecer um mapa ao usuário, adaptado para incluir ou excluir certas características dependendo da, e. g., as preferências do usuário, posição corrente e tipo corrente de conexão de comunicação, conforme sendo dada pelo contexto. Neste caso, a informação de contexto refletindo a situação do usuário pode assim ser usada para criar um formato de apresentação ótimo, i.

Petição 870180071254, de 15/08/2018, pág. 14/44

6/30

e. o mapa exibido.

[0013] Fig. 2 ilustra uma configuração de servidor proposta previamente para fornecer informação de contexto sobre um objeto de interesse para uma entidade solicitante, ou “consumidor de contexto”. Um servidor de contexto 200 é mostrado adaptado para fornecer informação de contexto, para qualquer usuário, dispositivo ou aplicação autorizados, ilustrado aqui de forma geral, como uma “parte solicitante” 202. Deve ser observado que o objeto de interesse para o qual a informação de contexto é mantida pode ser uma pessoa, dispositivo, aparelho, sistema, etc. Adicionalmente, a parte solicitante 202 pode provavelmente ser uma pessoa, e. g. um assinante de presença como descrito acima, ou um dispositivo. A parte solicitante 202 pode também ser uma aplicação sendo usada para permitir um serviço, tal como o serviço de auxilio à navegação descrito acima.

[0014] O servidor de contexto 200 inclui um gerenciador de contexto

204, um anunciante 206 e uma função de controle de admissão 208, a serem descritos abaixo. O gerenciador de contexto 204 continuamente coleta informação sobre o objeto de interesse aqui esquematicamente ilustrado como uma caixa tracejada 210a, recebendo dados de objeto proveniente de várias fontes, indicados como sensores S 210. Os sensores 210 são adaptados para medir ou registrar várias “variáveis” ou o similar caracterizando o estado corrente, estado ou situação do objeto 210a. Por exemplo, os sensores podem ser adaptados para medir características físicas tal como temperatura, ou para registrar algum estado de objeto corrente tal com qualquer dos mencionados estados de cliente acima para serviços de presença. Em um outro exemplo tangível, o objeto de interesse pode ser uma chave de energia e um sensor único pode então ser adaptado para simplesmente registrar se a chave está ligada ou não.

[0015] Dados de contexto brutos provenientes dos sensores 210 são

Petição 870180071254, de 15/08/2018, pág. 15/44

7/30 recebidos e armazenados em uma unidade de armazenamento de contexto 212 no gerenciador de contexto 204. Os dados de contexto brutos podem então ser processados e refinados em um refinador de contexto 214 aplicando regras predefinidas 216 nos dados brutos, de modo a derivar ou calcular novas informações de contexto refinadas a partir dos dados brutos. As regras predefinidas 216 podem incluir algoritmos ou o similar que calcula certos parâmetros, conclusões brutas ou criar compilações a partir dos dados brutos. Por exemplo, no caso da mencionada chave de energia acima, regras podem ser definidas para derivar vários parâmetros estatísticos. Uma regra pode calcular a quantidade total do tempo que a chave esteve ligada e desligada, respectivamente. Outras regras podem calcular, a duração máxima, a mínima ou a média dos períodos, que ela ficou ligada e desligada, respectivamente, e assim por diante.

[0016] O contexto refinado pode então ser distribuído corretamente para qualquer parte solicitante pode meio de um distribuidor 218. A parte solicitante 202 pode primeiro descobrir que informação de contexto pode ser obtida proveniente do servidor de contexto checando propagandas e anúncios fornecidos por meio de algum mecanismo de “exposição” de acordo com informação adequada proveniente do anunciante 206. Por exemplo, propagandas e anúncios considerando informação de contexto disponível, podem ser expostos, como indicado na figura por uma linha tracejada, por meio de um servidor separado ou o similar. Então, a parte solicitante 202 pode fazer uma solicitação por informação de contexto que é recebida na unidade de controle de admissão 208. Esta unidade 208 é adaptada para aplicar uma política sobre a solicitação de contexto para determinar se a parte solicitante 202 está autorizada a receber informação de contexto do objeto de interesse. A política foi definida basicamente prelo proprietário do contexto, e. g. um operador de rede. Se sim, a unidade de controle de admissão 208 dispara o distribuidor 218 para fornecer a última informação de contexto para

Petição 870180071254, de 15/08/2018, pág. 16/44

8/30 a parte solicitante 202. A política pode também ditar que a um solicitador particular seja permitido receber somente alguma parte da informação de contexto disponível. Deve ser observado que a solicitação de contexto pode ser uma solicitação por uma assinatura para receber informação de contexto proveniente do servidor de contexto em uma forma mais ou menos contínua. [0017] Tipicamente, a informação de contexto pertence a um objeto individual, e. g. uma pessoa. Contudo, um objeto pode também pertencer a um grupo de objetos, e. g. pessoas, tendo um perfil agregado compartilhado por seus membros. Um membro de um grupo pode por si só ser considerado com um parâmetro em um contexto individual. Por exemplo, membros de uma família, cada um, ter um contexto individual enquanto a família pode ter um contexto comum com um perfil agregado compartilhado por seus membros. Hoje, nenhum mecanismo está disponível para criar um contexto, agregado para um grupo de indivíduos ou dispositivos.

[0018] Usando a solução descrita acima da Fig. 2, as regras criando a informação de contexto refinada são predefinidas e fixas, e a informação de contexto refinada pode ser fornecida para qualquer parte solicitante autorizada. Desta maneira, a parte solicitante pode somente receber contexto de acordo com sua forma predefinida, que é algumas vezes um problema já que isto pode não ser exatamente o que a parte solicitante necessita ou deseja. Contudo, nenhuma solução flexível está disponível hoje para ir de encontro as necessidades particulares de uma parte solicitante, sendo limitada somente aos refinamentos de contexto predefinidos. A parte solicitante também receberá toda informação de contexto disponível, algumas vezes limitada pela política, mesmo que embora partes delas podem não ser necessária.

[0019] Mais ainda, membros de grupo somente podem ser expressos hoje como um parâmetro em contextos individuais. Contudo, um grupo pode existir não importando se seus membros estão ou não ativos e pode persistir mesmo quando seus membros realmente deixam o grupo. Isto pode causar

Petição 870180071254, de 15/08/2018, pág. 17/44

9/30 problemas quando um membro de grupo é um parâmetro em um contexto individual, já que o perfil agregado daquele contexto do grupo é desconsiderado em um contexto individual.

[0020] É também algumas vezes desejável para um grupo de usuário, coletivamente, obter informação de contexto, que pode ser um procedimento tedioso usando a solução existente a que seus membros podem ter necessidades e preferências diferentes. Em um outro exemplo prático, um grupo de usuários pretende visitar um restaurante em conjunto e podem invocar um serviço de telecomunicação fornecendo informação sobre restaurantes disponíveis e seus menus, e. g. baseado nas localizações e preferências do usuário, Cada usuário no grupo pode então invocar tal um serviço e tipicamente receber resultados diferentes dependendo das diferenças

s.

em localização e preferências. E então decisão do usuário coordenar os resultados e acordar sobre um restaurante que satisfaça todos os usuários no grupo, que naturalmente pode ser difícil e perda de tempo.

[0021] Para concluir, mais flexibilidade em servidores de contexto é desejável quando fornecendo informação de contexto, e é também desejável tratar contextos de grupo mais eficientemente. Adicionalmente, uma solução útil é necessária para fornecer informação de contexto relevante sobre um objeto de interesse para um grupo requerendo um mínimo de esforço de seus membros.

SUMÁRIO DA INVENÇÃO [0022] O objeto da presente invenção é reduzir ou eliminar o problema evidenciado acima. Em particular, é um objeto da presente invenção fornecer uma solução para ir de encontro às necessidades e requisitos específicos de uma parte solicitante quando obtendo informação de contexto proveniente de um servidor de contexto.

[0023] Este objeto e outros são alcançados primariamente fornecendo um método e aparelho para obter informação de contexto proveniente de um

Petição 870180071254, de 15/08/2018, pág. 18/44

10/30 servidor de contexto mantendo um contexto para um objeto de interesse em uma rede de telecomunicação, mencionado servidor de contexto recebendo dados de contexto brutos proveniente de sensores associados com o objeto de interesse.

[0024] No método inventivo, uma solicitação por informação de contexto refinada com referência ao mencionado objeto de interesse é recebida proveniente de uma parte solicitante. Dados de contexto individuais são coletados por pelo menos uma entidade individual, e uma regra customizada é criada com base nos dados de contexto individuais recebidos. A regra define condições em uma solicitação adaptada por informação de contexto refinada considerando o objeto de interesse. Finalmente, dados de contexto refinados de acordo com a regra são recebidos provenientes do servidor de contexto.

[0025] Os dados de contexto individuais são preferencialmente coletados de pelo menos um gerenciador de contexto mantendo um contexto para mencionada entidade ou entidades individuais. Se a parte solicitante é um grupo de várias entidades individuais, dados de contexto individuais para cada uma das entidades individuais, os dados de contexto individuais recebidos são agregados em um contexto de grupo, e a regra customizada é criada a partir do contexto de grupo.

[0026] Preferencialmente, uma estrutura de gabarito de contexto é usada para coletar os dados de contexto individuais. O gabarito compreende campos de dados predefinidos para parâmetros de relevância para a parte solicitante que são preenchidos com dados de contexto correntes da parte solicitante. O gabarito de contexto pode ser apresentado como um documento XDM comunicado por meio de uma interface de IMS usando um protocolo SlP/Simple. O gabarito de contexto pode ser criado estendendo um gabarito genérico, compreendendo os campos padrão para dados básicos definindo uma parte solicitante em geral, em um gabarito aplicado também

Petição 870180071254, de 15/08/2018, pág. 19/44

11/30 compreendendo campos para os parâmetros de contexto. No caso, quando a parte solicitante é um grupo de várias entidades individuais, o gabarito genérico pode incluir campos padrão para uma identidade de grupo, membros de grupo e opcionalmente um administrador de grupo, se usado. O gabarito aplicado pode também incluir campos de parâmetros para cada uma das entidades individuais.

[0027] O aparelho inventivo compreende meios para receber, proveniente de uma parte solicitante, uma solicitação para informação de contexto refinada cm referência ao mencionado objeto de interesse. O aparelho também compreende uma unidade de junção de contexto adaptada para coletar dados de contexto individuais para pelo menos uma entidade individual da parte solicitante. O aparelho também compreende uma unidade de agregação de contexto adaptada para criar uma regra customizada com base nos dados de contexto individuais recebidos. A regra define condições em uma solicitação adaptada para informação de contexto refinada considerando o objeto de interesse. O aparelho também compreende meios para enviar a solicitação adaptada incluindo a regra customizada para o servidor de contexto do objeto de interesse, e meios para receber, proveniente do servidor de contexto, dados de contexto refinados de acordo com aquela regra.

[0028] A unidade de junção de contexto é preferencialmente também adaptada para coletar dados de contexto individual de pelo menos um gerenciador de contexto mantendo um contexto para mencionada entidade ou entidades individuais. No caso quando a parte solicitante é um grupo de várias entidades individuais, a unidade de junção de contexto é também preferencialmente adaptada para coletar dados de contexto individual para cada uma das entidades individuais. A unidade de agregação de contexto é também preferencialmente adaptada para agregar os dados de contexto individuais recebidos, em um contexto de grupo e para criar a regra

Petição 870180071254, de 15/08/2018, pág. 20/44

12/30 customizada a partir do contexto de grupo.

[0029] A unidade de junção de contexto pode também ser adaptada para usar uma estrutura de gabarito de contexto para coletar os dados de contexto individual. O gabarito compreende campos de dados predefinidos para parâmetros de relevância para a parte solicitante a serem preenchidos com dados de contexto correntes da parte solicitante. A unidade de junção de contexto é preferencialmente também adaptada para usar um documento XDM como o gabarito de contexto comunicado por meio de uma interface de IMS usando um protocolo SlP/Simple. A unidade de junção de contexto pode ser também adaptada para criar o gabarito de contexto estendendo um gabarito genérico, compreendendo os campos padrão para dados básicos definindo uma parte solicitante em geral, em um gabarito aplicado também compreendendo campos para os parâmetros de contexto. No caso, quando a parte solicitante é um grupo de várias entidades individuais, o gabarito genérico pode incluir campos padrão para uma identidade de grupo, membros de grupo e opcionalmente um administrador de grupo, se usado. O gabarito aplicado pode também incluir campos de parâmetros para cada uma das entidades individuais.

[0030] A presente invenção também adota um aparelho correspondente para fornecer informação de contexto proveniente de um servidor de contexto mantendo um contexto para um objeto de interesse em uma rede de telecomunicação, o servidor de contexto recebendo dados de contexto brutos proveniente de sensores associados com o objeto de interesse. O último aparelho compreende meios para receber uma solicitação adaptada originando de uma parte solicitante para informação de contexto refinada considerando o objeto de interesse. A solicitação adaptada inclui uma regra customizada que foi criada com base nos dados de contexto individual coletados, para pelo menos uma entidade individual da parte solicitante, a regra definindo condições na solicitação adaptada. O último aparelho também

Petição 870180071254, de 15/08/2018, pág. 21/44

13/30 compreende meios para refinar os dados de contexto brutos aplicando a regra customizada recebida, e meios para fornecer a informação de contexto refinada para entregar a mencionada parte solicitante. A regra customizada recebida pode ter sido derivada de um contexto de grupo agregado de uma grande quantidade de contextos individuais de membros de grupo.

[0031] Deve ser apreciado da seguinte descrição das modalidades preferidas que o último aparelho para fornecer informação de contexto proveniente de um servidor de contexto pode trabalhar junto com o aparelho anterior para obter informação de contexto proveniente de um servidor de contexto, assim como formar um conceito inventivo mútuo. O mesmo se aplica também para o último método de fornecer informação de contexto proveniente de um servidor de contexto e o método anterior de obter informação de contexto proveniente de um servidor de contexto. Características preferidas adicionais e benefícios da presente invenção se tomarão aparentes a partir da descrição detalhada abaixo.

DESCRIÇÃO BREVE DOS DESENHOS [0032] A presente invenção será agora descrita em mais detalhes por meio das modalidades preferidas e com referência aos desenhos anexos, nos quais:

- Fig. 1 é uma configuração de rede básica para comunicar multimídia, de acordo com a arte anterior

- Fig. 2 é um diagrama de bloco de um servidor de contexto geralmente fornecendo informação de contexto refinada para uma parte solicitante, de acordo com a arte anterior.

- Fig. 3 é um diagrama de bloco de um cenário de comunicação quando informação de contexto refinada é obtida para um grupo de indivíduos, proveniente de um servidor de contexto, de acordo com uma modalidade.

- Fig. 4 é um diagrama de bloco de um cenário de

Petição 870180071254, de 15/08/2018, pág. 22/44

14/30 comunicação quando informação de contexto refinada é obtida para um grupo de indivíduos, proveniente de um servidor de contexto, de acordo com uma outra modalidade.

- Fig. 5 é um diagrama de estado para um grupo de indivíduos como tratado por um gerenciador de grupo quando obtendo informação de contexto refinada para grupo mencionado, de acordo com ainda uma outra modalidade.

- Fig. 6 é um diagrama de bloco de um cenário de comunicação quando informação de contexto refinada é obtida para um indivíduo único, proveniente de um servidor de contexto, de acordo com ainda uma outra modalidade.

- Fig. 7a e 7b ilustram um gabarito genérico e um gabarito aplicado, respectivamente, que podem ser usados para cria uma regra customizada para obter informação de contexto refinada, de acordo com ainda uma outra modalidade.

- Fig. 8 ilustra como um gabarito é tratado dentro de uma função de contexto agregado, de acordo com ainda uma outra modalidade.

- Fig. 9 é um fluxograma ilustrando um procedimento para obter informação de contexto desejada, proveniente de um servidor de contexto, mantendo um contexto para um objeto de interesse, como executado por uma função de contexto agregado.

- Fig. 10 é um fluxograma ilustrando um procedimento para fornecer informação de contexto desejada, como executada por um servidor de contexto, mantendo um contexto para um objeto de interesse. DESCRIÇÃO DAS MODALIDADES PREFERIDAS [0033] Descrita resumidamente, a presente invenção fornece uma solução onde necessidades particulares de uma parte solicitante podem ser encontradas quando fornecendo informação de contexto relevante adaptada a elas. Nesta solução, uma regra “customizada” pode ser criada para a parte

Petição 870180071254, de 15/08/2018, pág. 23/44

15/30 solicitante definindo condições para informação de contexto refinada adaptada a seus próprios requisitos e necessidades considerando um objeto de interesse específico. Como usado aqui, o termo “regra” pode representar qualquer algoritmo ou o similar que calcula certos parâmetros, conclusões brutas ou criar compilações a partir dos dados brutos. Preferencialmente, após receber uma solicitação para informação de contexto refinada proveniente de uma parte solicitante, a regra customizada pode ser definida por meio de um gabarito de contexto compreendendo campos de dados predefinidos para parâmetros de relevância para a parte solicitante, de acordo com a solicitação. Os campos de parâmetros vazios no gabarito podem então ser preenchidos com dados de contexto corrente da parte solicitante.

[0034] Uma solicitação adaptada para informação de contexto refinada, inclui a regra customizada com criada do gabarito preenchido, é então submetida a um servidor de contexto do objeto de interesse, e. g. como aquele descrito na Fig. 2. O servidor de contexto então aplicará a nova regra para refinar os dados de contexto brutos recebidos, de modo a fornecer informação de contexto na forma desejada para a parte solicitante. Por meio disso, a parte solicitante não será limitada aos refinamentos e regras de contexto fixa e predefinidas, mas pode solicitar por informação de contexto sob medida para suas próprias necessidades e requisitos. A presente invenção pode ser usada quando a parte solicitante é ou um indivíduo único ou uma grande quantidade de indivíduos juntos compondo um grupo, que será descrito em mais detalhes abaixo.

[0035] O procedimento e arranjo inventivo para obter informação de contexto desejada proveniente de um servidor de contexto serão agora descritos por meio de modalidades exemplares, inicialmente com referência a Fig. 3. Nesta modalidade, um servidor de contexto 300 é basicamente configurado como o servidor de contexto da arte anterior 200 mostrado na Fig. 2, assim sendo tendo um gerenciador de contexto 302 e uma função de

Petição 870180071254, de 15/08/2018, pág. 24/44

16/30 controle de admissão 304 baseada em uma política predefinida. Nenhuma função de anunciador é mostrada nesta figura embora esta pode ser incluída aqui da mesma forma. Do mesmo modo, o gerenciador de contexto 302 inclui uma unidade de armazenamento de contexto 308 recebendo e armazenando dados de contexto brutos vindo dos sensores 306 associados com o objeto de interesse 306a. Os dados brutos armazenados são então processados em um refinador de contexto 310 de acordo com regras predefinidas 312, de modo a produzir informação de contexto refinada, basicamente na mesma maneira como descrito para a Fig. 2, a ser fornecida para qualquer parte solicitante autorizada pode mio de um distribuidor 314.

[0036] Neste exemplo, uma parte solicitante é composta de um grupo de indivíduos 316, aqui mostrado como entidades A, B, C...., e um contexto de grupo válido para seus membros é criado por meios de uma “função de contexto agregado” 318, que pode ser implementada em um servidor ou o similar em uma rede de serviço, e. g. uma rede de IMS. Contudo, o mecanismo descrito abaixo podería ser usado da mesma forma para uma entidade solicitante única. Nas modalidades descritas aqui, a função de contexto agregado geralmente será considerada com um nó.

[0037] Cada indivíduo A, B, C,... tem, por sua vez, um gerenciador de contexto associado CMa, CMb, CMc,... 320 mantendo um contexto em nome de seus indivíduos associados, basicamente na mesma maneira como o servidor de contexto 302 faz em nome do objeto de interesse 306a. Por exemplo, se os indivíduos A, B, C,... são usuários de rádio móvel, seus contextos podem incluir específicos considerando suas capacidades de terminais, estado corrente, preferências pessoais e posição corrente, embora a presente invenção não seja limitada a esse respeito. Conseqüentemente, cada gerenciador de contexto 320 recebe dados de contexto brutos provenientes dos sensores, não mostrados, associados com os respectivos indivíduos 316.

[0038] Na presente solução, a função de contexto agregado 318 cria

Petição 870180071254, de 15/08/2018, pág. 25/44

17/30 um contexto de grupo agregado que é coletivamente válido para todos os membros 316 do grupo, pelo menos em alguns aspectos, e. g. que os membros concordaram quando da formação do grupo. Altemativamente, um grupo existente pode ser importado onde os membros do grupo são já fixos. Aqui, é assumido que o grupo foi formado, e que a função de contexto agregado 318 recebeu a solicitação para informação de contexto do grupo, que será descrita mais tarde abaixo em mais detalhes. Em um primeiro passo ilustrado 3:1, a função de contexto agregado 318 coleta informação de contexto individual de cada uma dos gerenciadores de contexto CMa, CMb, CMc,... 320. No caso de um grupo muito grande, um procurador (não mostrado) pode ser usado para receber numerosas atualizações de contexto provenientes dos gerenciadores de contexto 320 dos indivíduos do grupo, de modo a evitar sobrecarga da função de contexto agregado 318. O procurador pode então selecionar e passar adiante somente atualizações com mudanças significantes para aos interesses do grupo, e por meio disso atuar como um filtro. O procurador pode assim ser configurado para somente passar adiante mudanças de contexto ‘ importantes” para a solicitação feita, como por exemplo mudanças da posição do usuário excedendo um certo limite.

[0039] Um contexto de grupo agregado é então criado na função de contexto agregado 318 com base nos contextos individuais recebidos no passo 3:1, preferencialmente usando um gabarito de contexto como mencionado acima que também será descrito mais tarde abaixo em mais detalhes. Uma regra customizada correspondente é então definida e envia ao servidor de contexto 300 como uma solicitação adaptada para informação de contexto refinada, em um próximo passo 3:2. Esta regra é assim um resultado combinado do contexto de grupo agregado e da solicitação recebida inicialmente da parte solicitante. A regra customizada assim sendo representa com efeito uma solicitação para o servidor de contexto 300 para informação de contexto refinada em uma forma adaptada aos requisitos e necessidades

Petição 870180071254, de 15/08/2018, pág. 26/44

18/30 dos membros do grupo como ditado por seus contextos.

[0040] Se esta solução é implementada em uma rede de IMS, a regra/gabarito pode preferencialmente ser apresentada como um documento de XDM (XML Data Management) que é uma linguagem específica para o gerenciamento de listas em ambientes de IMS. O XDM define regras que podem então ser comunicadas por meio de uma interface de IMS usando um protocolo SlP/Simple entre a função de contexto agregado 318 e o servidor de contexto 300, embora outros meios de transporte são também possíveis. Adicionalmente, a função de contexto agregado 318 pode ser implementada em um servidor de Presence and Group Management (PGM) com definido para redes de IMS.

[0041] Em um outro exemplo tangível, uma regra customizada pode ser definida como condições em uma solicitação proveniente de um grupo de usuários de rádio móvel para uma refeição adequada em um restaurante. A regra deve então ser definida para satisfazer as preferências de todos os membros do grupo, ou pelo menos a quantos for possível, e pode ser derivada da agregação de seus contextos individuais. Por exemplo, um primeiro membro pode ser alérgico a amendoins, um segundo membro pode preferi arroz e um terceiro membro pode rejeitar comida apimentada, etc. A regra criada pode então incluir a seguinte solicitação com condições “Propor qualquer refeição não apimentada contendo arroz, mas não amendoins”. Preferências adicionais considerando um parâmetro limitante de custo podem incluir membro A: máximo de 200 SEK, membro B: máximo de 250 SEK, membro C: máximo de 300 SEK, etc. No contexto de grupo agregado, o parâmetro de custo se tomaria: máximo de 200SEK, satisfazendo todos os membros A - C.

[0042] Informação de localização sobre os membros individuais pode também ser usada para adicionalmente definir um requisito na regra para localização de restaurante, e. g., “Propor restaurantes que preencham a

Petição 870180071254, de 15/08/2018, pág. 27/44

19/30 condição acima localizada dentro de 500 metros a partir de certo ponto”. Como um serviço, é então invocado, usando um servidor de contexto fornecendo informação sobre restaurantes disponíveis e seus menus, a regra criada é submetida a eles. A resposta do servidor de contexto pode então compreender uma lista de quaisquer restaurantes, preferencialmente incluindo menus, preenchendo as condições estabelecidas pela regra customizada.

[0043] Deve ser entendido dos exemplos dados acima que uma pessoa com habilidade na arte seria capaz de produzir uma lógica para agregar contextos individuais coletados em um contexto de grupo e uma regra customizada, com relação aos parâmetros relevantes para a solicitação.

[0044] Voltando à Fig. 3, a regra customizada criada enviada ao servidor de contexto 300 no passo 3:2 é verificada na função de controle de admissão 304 para determinar se a solicitação está autorizada de acordo com uma política prevalecente. Assumindo que este é o caso, a nova regra 312a é adicionada às regras existentes 312 no gerenciador de contexto 302 em um passo 3:3, de modo a produzir informação de contexto refinada de acordo coma s condições e requisitos na regra 312a. Regra 312a 'então aplicada no refinador de contexto 310 em um passo 3:4, e o distribuidor 314 então fornece o contexto refinado, como sendo preparado de acordo com a regra 312a, como uma resposta a função de contexto agregado 318, em um passo adicional 3:5. A função de contexto agregado 318 pode então finalmente transmitir o resultado de informação para qualquer das entidades 316, e. g. de acordo com um esquema pré-determinado, em um passo final 3:6. Os resultados podem ser também conduzidos a um servidor de aplicação separado 322 ou o similar que pode ser acessado por qualquer entidade individual 316 para obter mencionados resultados.

[0045] Fig. 4 ilustra um procedimento e arranjo para obter informação de contexto refinada proveniente de um servidor de contexto, como igual ao cenário da Fig. 3, com a função de contexto agregado 400 sendo ilustrada em

Petição 870180071254, de 15/08/2018, pág. 28/44

20/30 mais detalhes. Como na Fig. 3, a função de contexto agregado 400 coleta contextos individuais proveniente dos gerenciadores de contexto 402 associados com um grupo de entidades individuais 404, e envia uma regra customizada para o servidor de contexto 406. Nesta modalidade, a função de contexto agregado 400 inclui um gerenciador de grupo 408, uma unidade de junção de contexto 410 e uma unidade de agregação de contexto 412, a serem descritos abaixo.

[0046] Em um primeiro passo 4:1, uma entidade A fora de um grupo entidades individuais 404 envia uma solicitação para informação de contexto com referência a um objeto de interesse, em nome de um grupo especificado, para a função de contexto agregado 400. A solicitação pode ser variada dependendo do que é oferecido, e. g. de um mecanismo de exposição como descrito para a Fig. 2, ou dependendo do que pode geralmente ser do interesse para o grupo. Como mencionado acima, o grupo pode ser um novo ou um existente importado. Se os indivíduos 404 são usuários de rádio móvel, um deles pode tomar a iniciativa de fazer uma solicitação para um grupo tendo interesses mútuos em alguns aspectos, e. g. para ter uma refeição, juntos na hora do almoço. Altemativamente, uma unidade de gerenciamento de serviço separada, ou administrador, não pretendido para ser um próprio membro do grupo, pode enviar a solicitação de informação de contexto, e. g. se as entidades individuais 404 são aplicações correlacionadas para permitir um serviço de comunicação ou o similar.

[0047] Em qualquer caso, a solicitação por informação de contexto para um grupo é recebida por um gerenciador de grupo 408 que define e mantém o grupo em uma estrutura de dados 408a, e. g. compreendendo uma lista de membros ou o similar. Quaisquer parâmetros determinando um contexto para o grupo podem também ser definido no gerenciador de grupo 408, tal como estados e preferências correntes. Preferencialmente, somente parâmetros relevantes à solicitação de informação de contexto são definidos.

Petição 870180071254, de 15/08/2018, pág. 29/44

21/30

Em uma modalidade, uma estrutura de gabarito de contexto pode ser definida com campos para esses parâmetros, a serem preenchidos com informação de contexto corrente, os quais serão também descritos abaixo mais tarde.

[0048] Em um próximo passo 4:2, a solicitação de informação de contexto é conduzida a unidade de agregação de contexto 412 para ser usada mais tarde, como será descrito abaixo. Como o grupo foi criado e ativado pelo gerenciador de grupo 408, a unidade de junção de contexto 410 coleta dados de contexto individuais correntes provenientes dos gerenciadores de contexto CMa, CMb, CMc,... 402 associados com seus respectivos indivíduos 404, em um passo seguinte 4:3, assim como no passo 3:1 da Fig. 3. Deve ser notado que a ordem dos passos 4:2 e 4:3 pode ser inversa.

[0049] Os contextos juntados são então conduzidos à unidade de agregação de contexto 412, em um passo 4:4, que então agrega os contextos individuais em um contexto de grupo comum. Combinado com a solicitação de informação de contexto conduzida no passo 4:2, o contexto de grupo pode ser traduzido em condições de uma solicitação adaptada de informação de contexto refinada proveniente do servidor de contexto 406. Estas condições podem ser expressas com uma regra customizada que a unidade 412 cria. A unidade de agregação de contexto 412 então envia a regre 414 como uma solicitação ao servidor de contexto 406, em um próximo passo 4:5, a regra assim definindo as condições para solicitação. Após refinar dados de contexto brutos, basicamente como descrito para o passo 3:4 na Fig. 3, o servidor de contexto 406 fornece informação de contexto refinada de acordo com as regras submetidas 414, de volta para o gerenciador de grupo 408, em um passo 4:6. Finalmente, como ilustrado em um passo 4:7, o gerenciador de grupo 408 pode enviar os resultados de informação para qualquer das entidades individuais 404, e. g. de acordo com algum esquema predefinido, ou para um servidor de aplicação acessível ou o similar, embora a presente invenção não está limitada a esse respeito.

Petição 870180071254, de 15/08/2018, pág. 30/44

22/30 [0050] Fig. 5 é um diagrama de estado para um grupo de acordo com uma outra modalidade. O grupo pode preferencialmente ser mantido pelo gerenciador de grupo 408 mostrado na Fig. 4. Em um primeiro estado 500, o grupo é criado em resposta a um acionamento de formação de grupo 5:1, que pode ser uma solicitação de informação de contexto para um grupo especificado proveniente de um usuário, de um administrador de grupo designado ou de um gerenciador de aplicação de serviço, como mencionado acima. Criação de grupo inclui especificar seus membros e definir parâmetros de interesse, etc.

[0051] Quando o processo de criar o grupo é completado, o grupo entra em um estado ativo 502 onde dados de contexto individuais correntes podem ser recebidos e atualizados, como indicado por setas 5:2. Os parâmetros de grupo também podem ser modificados no estado ativo a qualquer hora durante o tempo de vida do grupo, como indicativo por setas 5:3, e. g. quando membros mudam para o grupo conforme membros deixam ou se juntam ao grupo, ou quando o perfil do grupo ou os parâmetros são atualizados por seus membros ou por um administrador de grupo, e. g., considerando as preferências e políticas etc.

[0052] O grupo pode em qualquer ponto durante seu tempo de vida, entrar em estado inativo 504 em resposta a um acionamento de inativação 5:4. No estado inativo, nenhum dado de contexto ou modificações pode ser recebido e o grupo fica adormecido até ser acordado por um acionamento de ativação 5:5. O acionamento de inativação 5:4 pode vir de um membro do grupo ou administrador ou pode ser o término de um limite de tempo predefinido, e. g. um tempo de vida total limitado do grupo ou o tempo desde que o grupo recebeu os últimos novos dados de contexto ou modificação. O acionamento de ativação 5:5 pode tipicamente vir de um membro do grupo ou administrador. Um acionamento de ativação pode também ser o preenchimento de uma condição de contexto predefinida, e. g. quando um

Petição 870180071254, de 15/08/2018, pág. 31/44

23/30 certo numero de membros do grupo estão localizados dentro de um raio predeterminado, etc. Se esta condição é preenchida para somente alguns dos membros do grupo, um subgrupo desses membros pode ser definido em uma função de contexto agregado com sendo ativo.

[0053] O grupo pode finalmente ser resolvido em resposta a um acionamento de eliminação 5:6, tipicamente proveniente de um membro ou de um administrador tendo determinado que o grupo se tomou obsoleto. Um estado de eliminação de grupo 506 é então entrado que é final. Altemativamente, o acionamento de eliminação pode ser um parâmetro de tempo a expirar igual ao acionamento de inativação 5:4 descrito acima. A principal diferença é que o estado ativo 502 pode ser entrada a partir do estado inativo 504, mas não a partir do estado de eliminação 506.

[0054] Será agora descrito como informação de contexto refinada sobre um objeto de interesse pode ser obtida proveniente de um servidor de contexto associado com isso, quando a parte solicitante é um indivíduo único, com referência à Fig. 6. Uma função de contexto agregado 600 é mostrada basicamente compreendendo os mesmos componentes da função 400 na Fig. 4, a saber um gerenciador de grupo 602, uma unidade de junção de contexto 604 e uma unidade de agregação de contexto 606.

[0055] Uma solicitação por informação de contexto refinada com referência ao objeto de interesse é recebida proveniente do indivíduo único A 608, em um primeiro passo 6:1. Neste caso da mesma foram, a solicitação de informação de contexto pode ser recebida de uma unidade separada de gerenciamento de serviço ou de um administrador, não mostrados. Já que nenhum grupo é para ser criado e mantido para o indivíduo único 608, o gerenciador de grupo 602 pode pulado, e a solicitação pode ser diretamente conduzida para a unidade de junção de contexto 604. em resposta a isto, a unidade de junção de contexto 604 coleta dados de contexto individuais de um gerenciador de contexto CMa 610 associado com o indivíduo 608, como

Petição 870180071254, de 15/08/2018, pág. 32/44

24/30 ilustrado por um passo 6:2.

[0056] Parâmetros relevantes à solicitação de informação de contexto são também definidos pela unidade de junção de contexto 604, preferencialmente usando uma estrutura de gabarito de contexto com campos de parâmetros que são preenchidos com os dados de contexto coletados no passo 6:2. Estruturas de gabarito de contexto exemplares serão descritas em mais detalhes abaixo.

[0057] Em um passo 6:3, a informação de contexto coletada é conduzida a unidade de agregação de contexto 606, preferencialmente apresentada como um gabarito preenchido, junto com a solicitação de informação de contexto recebida no passo 6:1. Unidade 606 agora agrega o contexto individual recebido e a solicitação de informação de contexto criando uma regra customizada 612 contendo condições resultantes, como uma solicitação adaptada para informação de contexto proveniente do servidor de contexto 614. A unidade de agregação de contexto 606 então envia a regra 612 com uma solicitação ao servidor de contexto 614, em um próximo passo 6:4, a regra assim sendo definindo as condições para a solicitação.

[0058] Após refinar dados de contexto brutos de acordo com a regra

612 recebida, o servidor de contexto 614 fornece informação de contexto refinada, de volta a unidade de junção de contexto 604, em um passo 6:5. Deve ser observado que o gerenciador de grupo 602 pode uma vez mais ser pulado, conforme comparado com o exemplo da Fig. 4, acima descrito, e é basicamente transparente através do processo. Em um passo final ilustrado 6:6, a unidade de junção de contexto 604 pode enviar os resultados de informação para o indivíduo 608, ou para um servidor de aplicação acessível ou o similar.

[0059] Como mencionado acima, uma estrutura de gabarito de contexto pode preferencialmente ser definida com campos para parâmetros

Petição 870180071254, de 15/08/2018, pág. 33/44

25/30 relevantes à uma solicitação de informação de contexto recebida. Estes campos de parâmetros podem assim sendo ser usados para coletar e registrar contextos individuais correntes de membros em um grupo criado, ou o contexto de um indivíduo único quando aplicável. Os campos de parâmetros são então preenchidos com dados correspondentes de cada um dos contextos coletados. Fig. 7a e 7b ilustram uma estrutura de gabarito genérica e uma estrutura de gabarito aplicada, respectivamente, de acordo com uma modalidade preferida, aqui mostrada como um documento de XDM usando XML.

[0060] Uma estrutura de dados de “gabarito genérico” compreende campos padrão para dados básicos definindo uma parte solicitante em geral. O gabarito genérico 700 mostrado na Fig. 7a compreende tais campos padrão para uma entidade de grupo, membros de grupo (aqui mostrado como campos para membros A, B e C) e opcionalmente um administrador de grupo, se usado. Os campos para membros e administrador devem preferencialmente acomodar identidades adequadas e endereços de rede para comunicação.

[0061] Quando uma regra customizada é para ser criada em nome de uma parte solicitante, de modo a obter informação de contexto refinada proveniente de um servidor de contexto como descrito acima, parâmetros relevantes à solicitação de informação de contexto são para ser definidos. Isto pode ser feito estendendo o gabarito genérico 700 para se tomar um “gabarito aplicado” 702 mostrado na Fig. 7b, adicionando uma parte especifica de aplicação 704 para uma aplicação usada para aa solicitação. Parte 704 inclui um nome e campos de aplicação 706 para um ou mais parâmetros de contexto definidos 1, 2, 3... relevantes para aquela aplicação e para a solicitação. No gabarito aplicado 702, os campos de parâmetros vazios 706 agora podem ser preenchidos com informação de contexto coletada para cada membro durante o processo de junção de contexto, e. g. como descrito para o passo 4:3 na Fig. 4 ou passo 6:2 na Fig. 6.

Petição 870180071254, de 15/08/2018, pág. 34/44

26/30 [0062] Fig. 8 ilustra um exemplo de como tal estrutura de gabarito pode ser usada em uma função de contexto agregado 800, igual àquela denotada por 400 na Fig. 4, compreendendo um gerenciador de grupo 802, uma unidade de junção de contexto 804 e uma unidade de agregação de contexto 806. Em um primeiro passo 8:1, gerenciador de grupo 802 recebe uma solicitação de informação de contexto proveniente de uma parte solicitante 808, neste caso um grupo de vários indivíduos A, B, C... dos quais A faz a solicitação. Após definir parâmetros relevantes para a solicitação de informação de contexto, gerenciador de contexto 802 pega um gabarito genérico, mostrado na Fig. 7a, como um ponto de partida para criar uma estrutura de gabarito aplicada 812 incluindo, para cada membro do grupo, campos para os parâmetros definidos, que estão inicialmente vazios, como mostrado.

[0063] O gabarito aplicado 812 é então conduzido para a unidade de junção de contexto 804, em um passo 8:2. Adicionalmente, a solicitação de informação de contexto recebida no passo 8:1 é também conduzida para a unidade de agregação de contexto 806, em um passo 8:3. A unidade de junção de contexto 804 agora coleta contextos individuais provenientes dos gerenciadores de contexto 810 associados com os membros do grupo, em um próximo passo 8:4. Quando fazendo isso, isto preenche os campos de parâmetros do gabarito aplicado com o contexto coletado para cada membro do grupo. Deve ser observado que pode acontecer que nem todos parâmetros estão disponíveis para algumas entidades individuais, tal que alguns campos permanecerão vazios de informação, é também possível definir alguns parâmetros como “obrigatórios” e outros como ‘ opcionais”. Se qualquer entidade falha em fornecer informação de contexto para um obrigatório, o comportamento resultante pode depender da situação e/ou aplicação usada. Quando o processo de coleta de contexto é completado, o gabarito preenchido 814 é conduzido para a unidade de agregação de contexto 806, em um

Petição 870180071254, de 15/08/2018, pág. 35/44 /30 próximo passo 8:5.

[0064] Em um passo final 8:6, unidade 806 cria uma regra customizada 816 com base na informação de contexto no gabarito 814 recebido no passo 8:5 e a solicitação recebida no passo 8:3. A regra 816 pode então ser submetida ao servidor de contexto de modo a obter informação de contexto refinada dele, basicamente na maneira descrita para a Fig. 3.

[0065] De acordo com um aspecto da presente invenção, um método é fornecido para obter informação de contexto proveniente de um servidor de contexto, e. g. 300, 406 ou 614, mantendo um contexto para um objeto de interesse, e. g. 306a, em uma rede de telecomunicação. Um procedimento geral para isso, como efetuado por um servidor de contexto agregado descrito para as Figuras 3, 4, 6 e 8, será agora descrito, com referência a um fluxograma mostrado na Fig. 9. E assumido que o servidor de contexto recebe dados de contexto brutos provenientes dos sensores, e. g. 306, associados com o objeto de interesse.

[0066] Em um primeiro passo 900, uma solicitação para informação de contexto refinada considerando um objeto de interesse, é recebida proveniente de uma parte solicitante representando, ou um indivíduo único ou um grupo com vários indivíduos.

[0067] Em um próximo passo 902, dados de contexto individual são coletados por pelo menos uma entidade individual da parte solicitante, preferencialmente proveniente de ou um servidor de conteúdo de um indivíduo único ou de vários servidores de conteúdo de indivíduos em um grupo. Preferencialmente, uma estrutura de gabarito de contexto é usada compreendendo campos de dados predefinidos para parâmetros de relevância para a parte solicitante de acordo com a solicitação. Os campos de parâmetros são então preenchidos com dados de contexto corrente, da parte solicitante para cada indivíduo.

[0068] Em um próximo passo 904, uma regra customizada é criada

Petição 870180071254, de 15/08/2018, pág. 36/44

28/30 baseada nos dados de contexto individual coletados, e também com respeito a solicitação recebida no passo 900. Como descrito acima, uma regra customizada pode ser criada por meio do gabarito preenchido.

[0069] Em um próximo passo 906, uma solicitação adaptada para informação de contexto refinada considerando o objeto de interesse, incluindo a regra customizada, é enviada para o servidor de contexto mantendo o contexto para o objeto de interesse.

[0070] Em um passo final 908, dados de contexto refinados de acordo com a mencionada regra são recebidos provenientes de um servidor de contexto, para ser entregue a parte solicitante.

[0071] De acordo com um outro aspecto da presente invenção, um método é fornecido para fornecer informação de contexto proveniente de um servidor de contexto, mantendo um contexto para um objeto de interesse, e. g. 306a, em uma rede de telecomunicação. Um procedimento geral para isso, como efetuado por um servidor de contexto, e. g. 300, 406 ou 614, como descrito para as Figuras 3, 4, 6 e 8, respectivamente, será agora descrito, com referência a um segundo fluxograma mostrado na Fig. 10. O servidor de contexto recebe dados de contexto brutos provenientes dos sensores, e. g. 306, associados com o objeto de interesse.

[0072] Em um primeiro passo 1000, uma solicitação adaptada para a informação de contexto refinada considerando que o objeto de interesse é recebido, a solicitação originando de uma parte solicitante. A solicitação adaptada inclui uma regra customizada (312a, 414) que foi criada com base nos dados de contexto individuais coletado por pelo menos uma entidade individual (316, 404) da mencionada parte solicitante, a regra definindo condição na solicitação adaptada.

[0073] Em um próximo passo 1002, dados de contexto brutos recebido são refinados aplicando a regra customizada recebida.

[0074] Em um passo final 1004, a informação de contexto refinada é

Petição 870180071254, de 15/08/2018, pág. 37/44

29/30 fornecida para entregar a mencionada parte solicitante. De acordo com as modalidades descritas acima, a informação de contexto refinada é enviada para uma função de contexto agregado que então a transmite para a parte solicitante, e. g. para um ou mais indivíduos ou para um servidor de aplicação acessível.

[0075] Deve ser observado que o mecanismo descrito acima pode ser configurado em maneiras diferentes dentro do escopo da presente invenção, dependendo do campo de aplicação e outros fatores. Em um outro exemplo tangível, a parte solicitante pode ser um grupo de usuários de rádio móvel desejando ativar um serviço de comunicação conhecido como PoC (Push-totalk over Cellular) no qual vários usuários podem se comunicar coletivamente pressionando um botão para abrir um canal para falar. Neste caso, o objeto de interesse está contido nos recursos da rede para permitir a comunicação de PoC. Os recursos da rede são tipicamente possuídos e/ou controlados por um operador de rede que também controla o servidor de contexto associado incluindo sua política para controle de admissão. De modo a otimizar o uso de recurso, capacidades disponíveis dos usuários no grupo devem ser determinadas antes de invocar o serviço. O seguinte procedimento, A) - G) pode então ser executado, e. g. usando as configurações mostradas na Fig. 3 ou Fig. 4:

A) O grupo é criado ou importado em uma função de contexto de grupo, e. g. no gerenciador de grupo 408;

B) Um contexto de grupo é criado agregando contextos individuais, e. g. na unidade de agregação de contexto 412. Se o serviço requer recursos, uma solicitação para uma aplicação de grupo especificada associada com o serviço invoca os procedimentos para juntar contexto e criar uma regra customizada;

C) Uma regra customizada é criada para apurar os recursos de comunicação permitidos para ao serviço e as capacidades dos usuários para

Petição 870180071254, de 15/08/2018, pág. 38/44

30/30 usar o serviço, condições na regra assim refletem as situações de usuários;

D) A regra customizada é enviada ao servidor de contexto mantendo um contexto para os recursos de rede;

E) A regra customizada é processada no servidor de contexto, e. g. servidor 300 ou 406, uma vez que isto foi verificado através de políticas de controle de admissão, e. g. controle de admissão 304. A regra é aplicada para refinar dados de contexto brutos, neste caso informação da rede, e determinar os recursos que os usuários estão permitidos a reservar;

F) Uma resposta com o contexto refinado, proveniente do servidor de contexto é enviada, e. g. por meio do distribuidor 314, para a função de contexto agregado, e é também distribuída para aos membros do grupo. Isto pode se expresso com uma regra de reserva de recurso para um ponto de decisão de política de serviços (PDP) que é uma entidade de rede conhecida para distribuir recursos de rede;

G) Quando os usuários finalmente invocam o serviço, eles podem enviar a regra de reserva de recurso para um PDP para um dado serviço.

[0076] Para concluir, a presente invenção fornece uma solução de encontro as necessidade e requisitos específicos de uma parte solicitante quando geralmente obtendo informação de contexto proveniente de um servidor de contexto considerando um objeto de interesse. Mais ainda, um mecanismo é fornecido para tratar contextos de grupo efetivamente, e informação de contexto relevante pode ser obtida, que é relevante para as necessidades e requisitos coletivos de um grupo.

[0077] Enquanto a invenção foi descrita com referência a modalidades exemplares específicas, a descrição é geralmente somente pretendida para ilustrar o conceito inventivo e não deve ser considerada como limitante do escopo da invenção, que é definida pelas reivindicações anexadas.

Claims

1. Método para obter informação de contexto proveniente de um servidor de contexto (300, 406, 614) mantendo um contexto para um objeto de interesse (306a), em uma rede de telecomunicação, o dito servidor de contexto recebendo dados de contexto brutos provenientes de sensores (306) associados com o objeto de interesse e processando os dados de contexto brutos em um refinador de contexto de acordo com as regras predeterminadas de modo a derivar ou calcular informação de contexto dos dados de contexto brutos, o método caracterizado pelas etapas de:

- receber, de uma parte solicitante, uma solicitação para informação de contexto refinada com referência ao dito objeto de interesse, em que a parte solicitante compreende uma pluralidade de entidades individuais,

- coletar dados de contexto individuais para cada da pluralidade de entidades individuais (316, 414) a partir de pelo menos um gerenciador de contexto mantendo um contexto para as ditas entidades individuais e agregando os dados de contexto individuais recebidos em um contexto de grupo,

- criar uma regra customizada com base no contexto de grupo e na solicitação de informações de contexto recebidas, a dita regra customizada definindo condições em uma solicitação adaptada para informação de contexto refinada considerando o objeto de interesse,

- enviar a dita solicitação adaptada incluindo a regra customizada para o servidor de contexto do dito objeto de interesse, em que o servidor de contexto produz informação de contexto refinado a partir dos dados de contexto brutos de acordo com a regra customizada, e

- receber, do servidor de contexto, informação refinada de acordo com a mencionada regra customizada.

2. Método, de acordo com a reivindicação 1, caracterizado

Petição 870180071254, de 15/08/2018, pág. 40/44

2/4 pelo fato de que uma estrutura de gabarito de contexto é usada para coletar os dados de contexto individuais, o dito gabarito compreendendo campos de dados predefinidos para parâmetros de relevância para a parte solicitante que são preenchidos com dados de contexto correntes da parte solicitante.

3. Método, de acordo com reivindicação 2, caracterizado pelo fato de que o gabarito de contexto é apresentado como um documento XDM comunicado por meio de uma interface de IMS usando um protocolo SlP/Simple.

4. Método, de acordo com reivindicação 2 ou 3, caracterizado pelo fato de que o gabarito de contexto é criado estendendo um gabarito genérico, compreendendo os campos padrão para dados básicos definindo uma parte solicitante em geral, em um gabarito aplicado também compreendendo campos para os ditos parâmetros de contexto.

5. Método, de acordo com reivindicação 4, caracterizado pelo fato de que a parte solicitante é um grupo de várias entidades individuais e ainda em que o gabarito genérico inclui campos padrão para uma identidade de grupo, membros de grupo e opcionalmente um administrador de grupo, se usado.

6. Método, de acordo com reivindicação 4 ou 5, caracterizado pelo fato de que a parte solicitante é um grupo de várias entidades individuais, e em que o gabarito aplicado inclui campos de parâmetros para cada uma das entidades individuais.

7. Aparelho para obter informação de contexto proveniente de um servidor de contexto (300, 406, 614) mantendo um contexto para um objeto de interesse (306a), em uma rede de telecomunicação, o dito servidor de contexto recebendo dados de contexto brutos provenientes de sensores (306) associados com o objeto de interesse e processar os dados de contexto brutos em um refinador de contexto de acordo com as regras predefinidas de modo a derivar ou calcular informação de contexto refinado a partir dos dados

Petição 870180071254, de 15/08/2018, pág. 41/44

3/4 brutos, caracterizado por:

- meios para receber, de uma parte solicitante, uma solicitação para informação de contexto refinada com referência ao dito objeto de interesse, em que a parte solicitante compreende uma pluralidade de entidades individuais,

- uma unidade de junção de contexto (410, 604) adaptada para coletar dados de contexto individuais para cada uma da pluralidade de entidades individuais (316, 404) a partir de pelo menos um gerenciador de contexto mantendo um contexto para as ditas entidades individuais e adaptado para agregar os dados de contexto individuais recebidos em um contexto de grupo,

- uma unidade de agregação de contexto (412, 606) adaptada para criar uma regra customizada com base no contexto de grupo e na solicitação de informações de contexto recebidas, a dita regra customizada definindo condições em uma solicitação adaptada para informação de contexto refinada considerando o objeto de interesse,

- meios para enviar a dita solicitação adaptada incluindo a regra customizada para o servidor de contexto do dito objeto de interesse, em que o servidor de contexto produz informação de contexto refinada a partir dos dados de contexto brutos de acordo com a regra customizada, e

- meios para receber, do servidor de contexto, dados de contexto refinados de acordo com a dita regra customizada.

8. Aparelho, de acordo com a reivindicação 7, caracterizado pelo fato de que a unidade de junção de contexto é também adaptada para usar uma estrutura de gabarito de contexto para coletar dados de contexto individual, o dito gabarito compreendendo campos de dados predefinidos para parâmetros de relevância para a parte solicitante a serem preenchidos com dados de contexto correntes da parte solicitante.

Petição 870180071254, de 15/08/2018, pág. 42/44

4/4

9. Aparelho, de acordo com reivindicação 8, caracterizado pelo fato de que a unidade de junção de contexto é também adaptada para usar um documento XDM como o gabarito de contexto comunicado por meio de uma interface de IMS usando um protocolo SlP/Simple.

10. Aparelho, de acordo com reivindicação 8 ou 9, caracterizado pelo fato de que a unidade de junção de contexto é também adaptada para criar o gabarito de contexto estendendo um gabarito genérico, compreendendo os campos padrão para dados básicos definindo uma parte solicitante em geral, em um gabarito aplicado também compreendendo campos para os ditos parâmetros de contexto.

11. Aparelho, de acordo com reivindicação 10, caracterizado pelo fato de que a parte solicitante é um grupo de várias entidades individuais, e em que o gabarito genérico inclui campos padrão para uma identidade de grupo, membros de grupo e opcionalmente um administrador de grupo, se usado.

12. Aparelho, de acordo com reivindicação 10 ou 11, caracterizado pelo fato de que a parte solicitante é um grupo de várias entidades individuais, e em que o gabarito aplicado inclui campos de parâmetros para cada uma das entidades individuais.