BR112020011703A2 - fornecendo acesso à rede usando pagamentos em blockchain - Google Patents

Abstract

São revelados aparelhos, métodos e sistemas para acesso à rede usando pagamentos em blockchain. Um aparelho 400 inclui um processador 405 e um transceptor 425 que recebe 905 uma mensagem de solicitação de autenticação para uma unidade remota, a mensagem de solicitação de autenticação incluindo um identificador de unidade remota, o identificador de unidade remota indicando que a unidade remota está solicitando acesso à rede por meio de um pagamento em blockchain. O processador 405 gera 910 um endereço para uma rede de blockchain indicada pelo identificador de unidade remota para receber o pagamento em blockchain. O transceptor 425 recebe 915 uma mensagem de informação de pagamento em blockchain da unidade remota e o processador 405 fornece 920 acesso à rede à unidade remota em resposta à validação com sucesso da informação de pagamento em blockchain recebida.

Description

FORNECENDO ACESSO À REDE USANDO PAGAMENTOS EM BLOCKCHAIN CAMPO

[001] O assunto revelado neste documento refere-se de modo geral a comunicações sem fio e mais particularmente a acesso à rede usando pagamentos em blockchain (“protocolo de confiança”).

FUNDAMENTOS

[002] As seguintes abreviações e acrônimos são por este meio definidas, algumas das quais são mencionadas dentro da descrição a seguir.

[003] Projeto de Parceria de Terceira Geração (“3GPP”), Autenticação, Autorização e Contabilidade (“AAA”), Função de Gerenciamento de Acesso e Mobilidade (“AMF”), Agregação de Portadoras (“CA”), Avaliação Clara de Canal (“CAA”), Elemento de Canal de Controle (“CCE”), Informação de Estado de Canal (“CSI”), Espaço de Pesquisa Comum (“CSS”), Informação de Controle de Enlace Descendente (“DCI”), Enlace Descendente (“DL”), Avaliação Clara de Canal Aperfeiçoada (“eCCA”), Banda Larga Móvel Aperfeiçoada (“eMBB”), Nó B Evoluído (“eNB”), Instituto Europeu de Padrões de Telecomunicações (“ETSI”), Equipamento Baseado em Quadro (“FBE”), Duplex por Divisão de Frequência (“FDD”), Acesso Múltiplo por Divisão de Frequência (“FDMA”), Solicitação de Repetição Automática Híbrida (“HARQ”), Internet das Coisas (“IoT”), Indicadores de Desempenho Chave (“KPI”), Acesso Assistido Licenciado (“LAA”), Equipamento Baseado em Quadro (“LBE”), Escutar Antes de Falar (“LBT”), Evolução a Longo Prazo (“LTE”), LTE Avançado (“LTE-A”), Controle de Acesso de Meio (“MAC”), Acesso Múltiplo (“MA”), Esquema de Codificação de Modulação

(“MCS”), Comunicação Tipo Máquina (“MTC”), MTC Massivo (“mMTC”), Múltiplas Entradas Múltiplas Saídas (“MIMO”), TCP de Múltiplos Percursos (“MPTCP”), Acesso Compartilhado Multiusuário (“MUSA”), Banda Estreita (“NB”), Função de Rede (“NF”), Nó B de Próxima Geração (“gNB”), Controle e Carregamento de Política (“PCC”), Função de Controle de Política (“PCF”), Qualidade de Serviço (“QoS”), Manipulação por Comutação de Fase em Quadratura (“QPSK”), Controle de Recursos de Rádio (“RRC”), Recepção (“RX”), Função de Comutação/Divisão (“SSF”), Solicitação de Agendamento (“SR”), Função de Gerenciamento de Sessão (“SMF”), Bloco de Informação de Sistema (“SIB”), Bloco de Transporte (“TB”), Tamanho de Bloco de Transporte (“TBS”), Protocolo de Controle de Transmissão (“TCP”), Duplex por Divisão de Tempo (“TDD”), Multiplex por Divisão de Tempo (“TDM”), Ponto de Transmissão e Recepção (“TRP”), Transmissão (“TX”), Informação de Controle de Enlace Ascendente (“UCI”), Protocolo de Datagrama de Usuário (“UDP”), Entidade/Equipamento de Usuário (Terminal Móvel) (“UE”), Enlace Ascendente (“UL”), Sistema Universal de Telecomunicações Móveis (“UMTS”), Comunicações de Ultraconfiabilidade e Baixa Latência (“URLLC”) e Interoperacionalidade Mundial para Acesso de Micro-Ondas (“WiMAX”).

[004] É muito comum atualmente obter acesso à rede fazendo um pagamento online. O pagamento tipicamente garante acesso à rede durante algum período de tempo ou até que algum montante de dados tenha sido consumido. Contudo, o processo de pagamento pode ser muito demorado e necessitar da intervenção do usuário. Na maioria dos casos,

o usuário é direcionado para um portal de pagamento onde deve fornecer detalhes de cartão de crédito ou entrar em uma carteira online (por exemplo, PAYPALTM) e autorizar o pagamento. Com a introdução de tecnologias de blockchain, contudo, pagamentos para acesso à rede podem tornar-se muito rápidos e perfeitos, exigindo quase nenhuma intervenção do usuário.

SUMÁRIO RESUMIDO

[005] São revelados métodos para acesso à rede usando pagamentos em blockchain. Aparelhos e sistemas também executam as funções dos métodos. Em algumas modalidades, um método de uma função de rede para acesso à rede usando pagamentos em blockchain inclui receber uma mensagem de solicitação de autenticação para uma unidade remota, a mensagem de solicitação de autenticação incluindo um identificador de unidade remota, o identificador indicando que a unidade remota (por exemplo, um UE) está solicitando acesso à rede por meio de um pagamento em blockchain, e gerar um endereço para uma rede de blockchain indicada pelo identificador de unidade remota para receber o pagamento em blockchain. O método inclui receber uma mensagem de informação de pagamento em blockchain da unidade remota e fornecer acesso à rede para a unidade remota em resposta à validação com sucesso da informação de pagamento em blockchain recebida.

[006] Outro método de um equipamento de usuário acessar a rede usando pagamentos em blockchain inclui a transmissão, pelo equipamento de usuário, de uma mensagem de resposta de autenticação a uma rede de comunicação móvel, a mensagem de resposta de autenticação incluindo um identificador de unidade remota, o identificador indicando que o equipamento de usuário está solicitando acesso à rede por meio de um pagamento em blockchain. O método inclui receber um endereço para uma rede de blockchain indicada pelo identificador de unidade remota e transmitir uma mensagem de informação de pagamento em blockchain associada ao pagamento em blockchain ao endereço recebido. O método inclui receber acesso à rede em resposta à validação com sucesso da mensagem de informação de pagamento em blockchain.

DESCRIÇÃO RESUMIDA DOS DESENHOS

[007] Uma descrição mais específica das modalidades descritas resumidamente acima será apresentada por referência a modalidades específicas que são ilustradas nos desenhos apensos. Entendendo que estes desenhos representam apenas algumas modalidades e não devem, portanto, ser considerados como limitantes do âmbito, as modalidades serão descritas e explicadas com especificidade e detalhe adicionais por meio do uso dos desenhos anexos, nos quais: a Figura 1 é um diagrama de blocos esquemático que ilustra uma modalidade de um sistema de comunicação sem fio para acesso à rede usando pagamentos em blockchain; a Figura 2 é um diagrama de blocos que ilustra outra modalidade de um sistema de comunicação sem fio para acesso à rede usando pagamentos em blockchain; a Figura 3 é um diagrama de blocos esquemático que ilustra uma modalidade de um aparelho de equipamento de usuário para acesso à rede usando pagamentos em blockchain; a Figura 4 é um diagrama de blocos esquemático que ilustra uma modalidade de um aparelho de autenticação para acesso à rede usando pagamentos em blockchain; a Figura 5A é um diagrama de blocos que ilustra uma modalidade de um procedimento de rede para acesso à rede usando pagamentos em blockchain; a Figura 5B é uma continuação do procedimento de rede da Figura 5A; a Figura 6A é um diagrama de blocos que ilustra outra modalidade de um procedimento de rede para acesso à rede usando pagamentos em blockchain; a Figura 6B é uma continuação do procedimento de rede da Figura 6A; a Figura 7 é um diagrama de blocos esquemático que ilustra uma modalidade de uma arquitetura de protocolo para acesso à rede usando pagamentos em blockchain; a Figura 8 é um diagrama de fluxograma esquemático que ilustra uma modalidade de um método para acesso à rede usando pagamentos em blockchain; e a Figura 9 é um diagrama de fluxograma esquemático que ilustra outra modalidade de um método para acesso à rede usando pagamentos em blockchain.

DESCRIÇÃO DETALHADA

[008] Como será entendido por aqueles versados na técnica, aspectos das modalidades podem ser concretizados como um sistema, aparelho, método ou produto de programa. Consequentemente, as modalidades podem tomar a forma de uma modalidade inteiramente de hardware, uma modalidade inteiramente de software (incluindo firmware, software residente, microcódigo, etc.) ou uma modalidade que combine aspectos de software e hardware.

[009] Por exemplo, as modalidades reveladas podem ser implementadas como um circuito de hardware que compreende circuitos de integração de escala muito grande (“VLSI”) personalizados ou matrizes de portas, semicondutores prontos para uso tais como chips lógicos, transistores, ou outros componentes discretos. As modalidades reveladas podem ser implementadas em dispositivos de hardware programáveis tais como matrizes de portas programáveis de campo, lógica de matrizes programáveis, dispositivos lógicos programáveis ou similares. Como outro exemplo, as modalidades reveladas podem incluir um ou mais blocos físicos ou lógicos de código executável que podem, por exemplo, ser organizados como um objeto, procedimento ou função.

[0010] Além disso, modalidades podem tomar a forma de um produto de programa concretizado em um ou mais dispositivos de armazenamento legíveis por computador que armazenam código legível por máquina, código legível por computador e/ou código de programa, referidos doravante como código. Os dispositivos de armazenamento podem ser tangíveis, não-transitórios e/ou sem transmissão. Os dispositivos de armazenamento podem não corporificar sinais. Em uma determinada modalidade, os dispositivos de armazenamento podem utilizar sinais para acessar código.

[0011] Pode ser usada qualquer combinação de um ou mais meios legíveis por computador. O meio legível por computador pode ser um meio de armazenamento legível por computador. O meio de armazenamento legível por computador pode ser um dispositivo de armazenamento que armazena o código. O dispositivo de armazenamento pode ser, por exemplo, um sistema, aparelho ou dispositivo eletrônico,

magnético, ótico, eletromagnético, infravermelho, holográfico, micromecânico ou semicondutor, ou qualquer combinação adequada dos precedentes, mas não se limita a estes.

[0012] Exemplos mais específicos (uma lista não- exaustiva) do dispositivo de armazenamento incluiria os seguintes: uma conexão elétrica que tem um ou mais fios, um disquete portátil de computador, um disco rígido, uma memória de acesso aleatório (“RAM”), uma memória apenas de leitura (“ROM”), uma memória apenas de leitura programável apagável (“EPROM” ou memória Flash), uma memória apenas de leitura em disco compacto (“CD-ROM”), um dispositivo de armazenamento ótico, um dispositivo de armazenamento magnético, ou qualquer combinação adequada dos precedentes. No contexto deste documento, um meio de armazenamento legível por computador pode ser qualquer meio tangível que possa conter, ou armazenar um programa para uso por ou em conexão com um sistema, aparelho ou dispositivo de execução de instrução.

[0013] Referência por toda esta especificação a “uma modalidade”, ou linguagem similar significa que um recurso, estrutura ou característica específico descrito em conexão com a modalidade está incluído em pelo menos uma modalidade. Portanto, aparições da frase “em uma modalidade”, e linguagem similar por toda esta especificação podem referir-se, mas não necessariamente, todas à mesma modalidade, mas significam “uma ou mais, mas não todas as modalidades” a não ser que expressamente especificado de outro modo. Os termos “incluindo”, “compreendendo”, “tendo” e suas variações significam

“incluindo, mas não limitado a”, a não ser que expressamente especificado de outro modo. Uma lista enumerada de itens não implica que qualquer ou todos os itens sejam mutuamente exclusivos, a não ser que expressamente especificado de outro modo. Os termos “um”, “uma” e “o” também se referem a “um ou mais” a não ser que expressamente especificado de outro modo.

[0014] Além disso, os recursos, estruturas ou características descritos das modalidades podem ser combinados de qualquer modo adequado. Na descrição a seguir, são fornecidos diversos detalhes específicos, tais como exemplos de programação, módulos de software, seleções de usuários, transações de rede, consultas de bancos de dados, estruturas de bancos de dados, módulos de hardware, circuitos de hardware, chips de hardware, etc., para fornecer uma compreensão completa de modalidades. Uma pessoa versada na técnica relevante reconhecerá, contudo, que modalidades podem ser concretizadas sem um ou mais dos detalhes específicos, ou com outros métodos, componentes, materiais, etc. Em outros casos, estruturas, materiais ou operações bem conhecidos não são mostrados ou descritos em detalhe para evitar obscurecer aspectos de uma modalidade.

[0015] São descritos abaixo aspectos das modalidades com referência a diagramas de fluxogramas esquemáticos e/ou diagramas de blocos esquemáticos de métodos, aparelhos, sistemas e produtos de programa de acordo com modalidades. Será entendido que cada bloco dos diagramas de fluxogramas esquemáticos e/ou dos diagramas de blocos esquemáticos, e combinações de blocos nos diagramas de fluxogramas esquemáticos e/ou nos diagramas de blocos esquemáticos, podem ser implementados por código. Este código pode ser fornecido a um processador de um computador de uso geral, computador de uso especial, ou outro aparelho de processamento de dados programável para produzir uma máquina, de modo que as instruções, que são executadas por meio do processador ou do outro aparelho de processamento de dados programável, criem meios para implementar as funções/ações especificadas nos diagramas de fluxogramas esquemáticos e/ou nos diagramas de blocos esquemáticos.

[0016] O código pode também ser armazenado em um dispositivo de armazenamento que pode orientar um computador, outro aparelho de processamento de dados programável, ou outros dispositivos a funcionar em um modo específico, de modo que as instruções armazenadas no dispositivo de armazenamento produzam um artigo de manufatura que inclua instruções que implementam a função/ação especificada nos diagramas de fluxogramas esquemáticos e/ou nos diagramas de blocos esquemáticos.

[0017] O código pode também ser carregado para um computador, outro aparelho de processamento de dados programável, ou outros dispositivos para fazer com que uma série de etapas operacionais seja executada no computador, outro aparelho programável ou outros dispositivos para produzir um processo implementado em computador tal que o código que é executado no computador ou outro aparelho programável forneça processos para implementar as funções/ações especificadas nos diagramas de fluxogramas esquemáticos e/ou nos diagramas de blocos esquemáticos.

[0018] Os diagramas de fluxogramas esquemáticos e/ou os diagramas de blocos esquemáticos nas figuras ilustram a arquitetura, funcionalidade e operação de possíveis implementações de aparelhos, sistemas, métodos e produtos de programa de acordo com diversas modalidades. No que se refere a isto, cada bloco nos diagramas de fluxogramas esquemáticos e/ou nos diagramas de blocos esquemáticos pode representar um módulo, segmento, ou parte de código, que inclui uma ou mais instruções executáveis do código para implementar a(s) função(ões) lógica(s) específica(s).

[0019] Deverá ser observado que, em algumas implementações alternativas, as funções mencionadas no bloco podem ocorrer fora da ordem mencionada nas figuras. Por exemplo, dois blocos mostrados em modo de sucessão podem, na verdade, ser executados substancialmente de modo concorrente, ou os blocos podem algumas vezes ser executados na ordem inversa, dependendo da funcionalidade envolvida. Podem ser concebidas outras etapas e métodos que sejam equivalentes em função, lógica ou efeito a um ou mais blocos, ou partes daqueles, das figuras ilustradas.

[0020] A descrição de elementos em cada figura pode fazer referência a elementos de figuras precedentes. Números similares referem-se a elementos similares em todas as figuras, incluindo modalidades alternativas de elementos similares.

[0021] As modalidades reveladas consideram pagamentos online feitos por meio de uma rede de blockchain. Tais pagamentos podem ser quase em tempo real (rápidos) e podem acionar uma sequência de outros eventos, tais como a criação e a atribuição de pacotes de informação de conexão. Vantajosamente, isto torna possível para um usuário móvel acessar uma rede visitada (por exemplo, uma rede móvel ou uma rede WLAN) mesmo quando a rede visitada não tem um acordo de roaming com a rede doméstica do usuário.

[0022] É revelado neste documento um novo método para permitir acesso rápido e perfeito à rede fazendo pagamentos em uma blockchain. Uma vez que o Protocolo de Autenticação Extensível (EAP) é tipicamente usado para controle de acesso, nós introduzimos um novo método EAP, denominado EAP-CRY, que é usado para permitir pagamentos em blockchain durante o procedimento de acesso à rede. Em diversas modalidades, as arquiteturas de sistema e os procedimentos descritos neste documento facilitam o acesso à rede com o método EAP-CRY.

[0023] A Figura 1 representa um sistema de comunicação sem fio 100 para acesso à rede usando pagamentos em blockchain, de acordo com modalidades da revelação. Em uma modalidade, o sistema de comunicação sem fio 100 inclui pelo menos uma unidade remota 105, uma rede de acesso 120 que contém pelo menos uma unidade de base 110, ligações de comunicação sem fio 115, uma rede básica móvel 130 e uma rede de blockchain 160. Mesmo embora um número específico de unidades remotas 105, redes de acesso 120, unidades de base 110, ligações de comunicação sem fio 115, redes básicas móveis 130 e redes de blockchain 160 seja representado na Figura 1, aquele versado na técnica reconhecerá que qualquer número de unidades remotas 105, redes de acesso 120, unidades de base 110, ligações de comunicação sem fio 115, redes básicas móveis 130 e redes de blockchain 160 pode ser incluído no sistema de comunicação sem fio 100. Em outra modalidade, a rede de acesso 120 contém um ou mais pontos de acesso WLAN (por exemplo, WI-FITM).

[0024] Em uma implementação, o sistema de comunicação sem fio 100 é compatível com o sistema 5G especificado nas especificações 3GPP. Mais geralmente, contudo, o sistema de comunicação sem fio 100 pode implementar algumas outras redes de comunicação abertas ou proprietárias, por exemplo, LTE ou WiMAX, entre outras redes. A presente revelação não se destina a ser limitada às implementações de qualquer arquitetura ou protocolo de sistema de comunicação sem fio específico.

[0025] Em uma modalidade, a unidade remota 105 pode incluir dispositivos computacionais, tais como computadores de mesa, computadores portáteis, assistentes digitais pessoais (“PDAs”), computadores tablet, telefones inteligentes, televisões inteligentes (por exemplo, televisões conectadas à Internet), eletrodomésticos inteligentes (por exemplo, eletrodomésticos ligados à Internet), conversores, consoles de jogos, sistemas de segurança (incluindo câmeras de segurança), computadores a bordo de veículos, dispositivos de rede (por exemplo, roteadores, comutadores, modems), ou similares. Em algumas modalidades, as unidades remotas 105 incluem dispositivos vestíveis, tais como relógios inteligentes, pulseiras de condicionamento físico, visores óticos montados na cabeça, ou similares. Além disso, as unidades remotas 105 podem ser referidas como unidades de assinante, móveis, estações móveis, usuários, terminais, terminais móveis, terminais fixos, estações de assinante, UE, terminais de usuário, um dispositivo, ou por qualquer outra terminologia usada na técnica. As unidades remotas 105 podem comunicar-se diretamente com uma ou mais das unidades de base 110, por meio de sinais de comunicação de enlace ascendente (“UL”) e de enlace descendente (“DL”). Além disso, os sinais de comunicação UL e DL podem ser transportados pelas ligações de comunicação sem fio 115.

[0026] As unidades de base 110 podem estar distribuídas por uma região geográfica. Em determinadas modalidades, uma unidade de base 110 pode também ser referida como um terminal de acesso, um ponto de acesso, uma base, uma estação base, um Nó-B, um eNB, um gNB, um Nó- B Doméstico, um nó de retransmissão, um dispositivo, ou por qualquer outra terminologia usada na técnica. As unidades de base 110 podem atender diversas unidades remotas 105 dentro de uma área de serviço, por exemplo, uma célula ou um setor de célula por meio de uma ligação de comunicação sem fio 115.

[0027] Geralmente, as unidades de base 110 transmitem sinais de comunicação de enlace descendente (“DL”) para atender as unidades remotas 105 no domínio do tempo, frequência e/ou espacial. Além disso, os sinais de comunicação de DL podem ser transportados pelas ligações de comunicação sem fio 115. As ligações de comunicação sem fio 115 podem ser qualquer portadora adequada em espectro de rádio licenciado ou não-licenciado. As ligações de comunicação sem fio 115 facilitam comunicação entre uma ou mais das unidades remotas 105 e/ou uma ou mais das unidades de base 110.

[0028] As unidades de base 110 são geralmente parte de uma rede de acesso de rádio (“RAN”), tal como a rede de acesso 120, que pode incluir um ou mais controladores acoplados comunicativamente a uma ou mais correspondentes unidades de base 110. Estes e outros elementos da rede de acesso de rádio não são ilustrados, mas são bem conhecidos geralmente por aqueles versados na técnica. As unidades de base 110 conectam-se a uma rede básica móvel (por exemplo, na rede visitada 130) por meio da rede de acesso 120.

[0029] Em uma modalidade, a rede básica móvel é um núcleo 5G (“5GC”) ou um núcleo de pacote evoluído (“EPC”), que pode estar acoplada a uma rede de dados 150, como a Internet e redes privadas de dados, entre outras redes de dados. Cada rede básica móvel pertence a uma única rede móvel terrestre pública (“PLMN”). A presente revelação não se destina a ser limitada às implementações de qualquer arquitetura ou protocolo de sistema de comunicação sem fio específico.

[0030] A rede básica móvel 130 inclui diversas funções de rede (“NFs”), incluindo funções de plano de controle (tal como Função de Autenticação 132) e funções de plano de usuário (tal como a Função de Portal 134). Como entendido na técnica, uma rede básica móvel pode incluir tais funções de plano de controle como uma Função de Gerenciamento de Acesso e Mobilidade (“AMF”), uma Função de Gerenciamento de Sessão (“SMF”), uma Função de Controle de Política (“PCF”). A Função de Portal 134 fornece acesso a redes de dados externas 150. A Função de Portal 134 tem uma interface com a Função de Autenticação 132 e é configurada pela Função de Autenticação 132 com regras que podem aplicar determinadas limitações ao tráfego entre o UE e as redes de dados 150.

[0031] A Função de Autenticação 132 é um servidor que autoriza (ou proíbe) acesso à rede após executar um procedimento de autenticação com a unidade remota 105. Em uma modalidade, a Função de Autenticação 132 implementa um servidor de Protocolo de Autenticação Extensível (“EAP”) e o procedimento de autenticação é uma troca de EAP. Observar que a Função de Autenticação 132 tem uma interface com um ou mais nós de blockchain 164 na rede de blockchain 160. Por meio desta interface a Função de Autenticação 132 pode fazer novas transações (pagamentos) em blockchain ou confirmar a existência de pagamentos anteriores em blockchain.

[0032] A rede de blockchain 160 é uma rede ponto-a- ponto que mantém uma contabilidade compartilhada segura 166, isto é, uma lista de transações que ocorreram no passado. Esta lista de transações é organizada em blocos ligados entre si, portanto o nome “blockchain (cadeia de blocos)”. A rede de blockchain 160 é composta de múltiplos nós (tipicamente milhares) de blockchain 164, cada um mantendo uma cópia da contabilidade compartilhada 166, também conhecida como a “blockchain”. A rede de blockchain 160 fornece interfaces de programação de aplicativos (APIs) que podem ser usadas por aplicativos para interagir com a blockchain. Como um exemplo, um aplicativo pode usar uma chamada de API para acionar uma transação em blockchain, por exemplo, para transferir alguns fundos para uma conta, ou para ser notificado quando a sua conta receber novos fundos. Aplicativos que usam a blockchain por meio de APIs adequados podem ser externos a um nó de blockchain 164 ou internos a um nó de blockchain 164. Em algumas modalidades, a rede de blockchain 160 suporta uma API externa (por exemplo uma API JSON-RPC) para uso por aplicativos externos e uma API interna separada (por exemplo, uma API JavaScriptTM) para uso pelos aplicativos internos.

[0033] Para solicitar acesso à rede de dados 150 por meio da rede de acesso 120 (e da rede básica móvel) em troca por um pagamento em blockchain, a unidade remota 105 sinaliza implicitamente à rede básica móvel uma solicitação para adquirir um acesso à rede por meio de um pagamento em blockchain quando envia um identificador de unidade remota associado à rede de blockchain 160. A unidade remota 105 submete o seu pagamento à rede básica móvel 130 e, usando a sua interface com a rede de blockchain 160, a Função de Autenticação 132 valida o pagamento e difunde a transação à rede de blockchain 160. A Função de Portal 134 concede então acesso à rede à unidade remota 105.

[0034] Beneficamente, o sistema sem fio 100 elimina a necessidade de uma rede visitada ou acordos de roaming entre redes, uma vez que a unidade remota 105 é capaz de fazer um pagamento em blockchain em troca pelo acesso à rede.

[0035] A Figura 2 representa uma arquitetura de rede 200 usada para acesso à rede usando pagamentos em blockchain, de acordo com modalidades da revelação. A arquitetura de rede 200 pode ser uma modificação do sistema de comunicação sem fio 100. Como representado, a arquitetura de rede 200 inclui um UE 205, um gNB 210, uma rede de acesso de rádio (“RAN”) 215, uma rede de comunicação móvel 220 e uma rede de blockchain 160. Neste documento, o UE 205 pode ser uma modalidade da unidade remota 105, e o gNB 210 pode ser uma modalidade da unidade de base 110, como discutido acima. O gNB 210 é uma parte da RAN 215, que é ela mesma uma parte da rede de comunicação móvel 220. Neste documento, a rede de comunicação móvel 220 inclui a RAN 215 e uma rede básica de acesso 225, que pode ser uma modalidade da rede básica móvel 130, discutida acima.

[0036] A rede básica de acesso 225 inclui uma função de portal 134, uma função de servidor EAP 133 e um nó de blockchain 164. A função de servidor EAP 133 pode ser uma modalidade da função de autenticação 132 discutida acima. A função de servidor EAP 133 e o nó de blockchain 164 estão colocalizados, formando uma função de servidor EAP de blockchain (“BESF”) 136. Isto significa que a rede básica de acesso 225 é uma parte da rede de blockchain 160.

[0037] Como representado, o UE 205 envia uma solicitação de acesso 201 à rede de comunicação móvel 220. Neste documento, a solicitação de acesso 201 inclui um nome de usuário e domínio do UE 205 (representado neste documento como “usuário@domínio (user@realm)”). O domínio específico apontará para uma rede de blockchain 160 através da qual o UE 205 deseja fazer um pagamento.

[0038] A Figura 3 representa uma modalidade de um aparelho de equipamento de usuário 300 que pode ser usado para acesso à rede usando pagamentos em blockchain, de acordo com modalidades da revelação. O aparelho de equipamento de usuário 300 pode ser uma modalidade da unidade remota 105 e/ou do UE 205. Além disso, o aparelho de equipamento de usuário 300 pode incluir um processador

305, uma memória 310, um dispositivo de entrada 315, um visor 320 e um transceptor 325. Em algumas modalidades, o dispositivo de entrada 315 e o visor 320 são combinados em um único dispositivo, tal como uma tela sensível ao toque. Em determinadas modalidades, o aparelho de equipamento de usuário 300 pode não incluir qualquer dispositivo de entrada 315 e/ou visor 320.

[0039] Como representado, o transceptor 325 inclui pelo menos um transmissor 330 e pelo menos um receptor 335. Adicionalmente, o transceptor 325 pode suportar pelo menos uma interface de rede 340. Neste documento, a interface de rádio 340 facilita comunicação com a unidade de base 110 e a rede básica móvel 130.

[0040] O processador 305, em uma modalidade, pode incluir qualquer controlador conhecido capaz de executar instruções legíveis por computador e/ou capaz de executar operações lógicas. Por exemplo, o processador 305 pode ser um microcontrolador, um microprocessador, uma unidade de processamento central (“CPU”), uma unidade de processamento gráfico (“GPU”), uma unidade de processamento auxiliar, uma matriz de portas programáveis de campo (“FPGA”), ou controlador programável similar. Em algumas modalidades, o processador 305 executa instruções armazenadas na memória 310 para executar os métodos e rotinas descritos neste documento. O processador 305 está comunicativamente acoplado à memória 310, ao dispositivo de entrada 315, ao visor 320 e ao transceptor 325.

[0041] Em algumas modalidades, o transceptor 325 transmite uma mensagem de resposta de autenticação a um servidor de autenticação em uma rede de comunicação móvel,

tal como a BESF 136. Neste documento, a mensagem de resposta de autenticação inclui um identificador de unidade remota que pertence ao aparelho de equipamento de usuário 300, tal como um identificador de endereço de rede (“NAI”) ou identificador de equipamento de usuário (“UEID”), que indica que a unidade remota está solicitando acesso à rede por meio de um pagamento em blockchain. Em um exemplo, o identificador de unidade remota é um NAI com um domínio ou âmbito específico a uma rede de blockchain através da qual a unidade remota deseja fazer pagamento em blockchain. Neste documento, diferentes redes de blockchain podem ter seus próprios domínios/âmbitos, de modo que a rede de blockchain desejada é facilmente identificada pelo NAI. Além disso, o uso de um NAI com um domínio ou âmbito específico a uma rede de blockchain indica ao servidor de autenticação que o aparelho de equipamento de usuário 300 está solicitando acesso à rede por meio de um pagamento em blockchain. Portanto, o processador 305 implicitamente sinaliza a sua solicitação para usar um pagamento em blockchain para acessar a rede (ao contrário de usar uma assinatura ou conta com a rede) pelo envio de uma mensagem de resposta de autenticação que inclui o identificador de unidade remota associado à rede de blockchain.

[0042] Adicionalmente, o transceptor 325 recebe, da rede de comunicação móvel um endereço de uma rede de blockchain (por exemplo, um primeiro endereço de blockchain). Neste documento, o primeiro endereço de blockchain é um endereço de pagamento na rede de blockchain que foi indicado pelo identificador de unidade remota. Em diversas modalidades, o aparelho de equipamento de usuário

300 não confia em uma assinatura de rede para obter acesso à rede, mas ao invés faz um pagamento em blockchain à rede de comunicação móvel com a finalidade de obter acesso à rede.

[0043] Em algumas modalidades, o endereço de pagamento está incluído em uma mensagem de solicitação de pagamento recebida por meio do transceptor 325. Neste documento, a mensagem de solicitação de pagamento pode incluir o endereço gerado e um ou mais opções de valor. Como usado neste documento, uma opção de valor refere-se a uma quantidade de acesso à rede (por exemplo, medido por tempo e/ou consumo de dados) a ser recebida em troca de um montante de valor (por exemplo, montante de pagamento). Cada opção de valor na mensagem de solicitação de pagamento indica um montante de acesso à rede e correspondente valor de pagamento. Em modalidades, o processador 305 controla um visor 320 para apresentar a uma ou mais opções de valor ao usuário. Além disso, o processador 305 pode também controlar o visor 320 para apresentar uma opção para indicar uma transação anterior. O dispositivo de entrada 315 pode receber uma seleção de uma opção de valor específica.

[0044] Em resposta à recepção do endereço de pagamento na rede de blockchain indicada (e em resposta à recepção da seleção de usuário de uma opção de valor ou indicação de uma transação anterior), o processador 305 gera uma mensagem de informação de pagamento em blockchain associada à rede de blockchain indicada. Em uma modalidade, a informação de pagamento em blockchain recebida inclui uma nova transação em blockchain (por exemplo, em resposta ao usuário selecionar uma das opções de valor). Em outra modalidade, a informação de pagamento em blockchain recebida é uma referência para uma transação em blockchain anterior (por exemplo, em resposta ao usuário indicar uma transação anterior).

[0045] Quando a informação de pagamento em blockchain inclui uma nova transação em blockchain, a mensagem de informação de pagamento em blockchain transmitida indica o valor a ser pago correspondente à opção de valor selecionada. Além disso, a mensagem de informação de pagamento em blockchain pode conter uma transação em blockchain. Alternativamente, a mensagem de informação de pagamento em blockchain pode conter parâmetros suficientes para o servidor de autenticação gerar uma transação em blockchain em nome do aparelho de equipamento de usuário 300. Em diversas modalidades, a informação de pagamento em blockchain transmitida também inclui uma chave pública do aparelho de equipamento de usuário 300.

[0046] Quando a informação de pagamento em blockchain inclui uma referência a uma transação em blockchain anterior, a mensagem de informação de pagamento em blockchain transmitida pode conter uma ID e/ou assinatura de transação. Em determinadas modalidades, o processador 305 determina se a transação anterior referenciada tem algum valor remanescente. Por exemplo, quando o pagamento em blockchain adquire um bloco de tempo, o processador 305 pode determinar se resta algum tempo. Como outro exemplo, quando o pagamento em blockchain adquire uma quantidade de dados (por exemplo, 1 GB), o processador 305 pode determinar se restam alguns dados. Adicionalmente, o servidor de autenticação valida a mensagem de informação de pagamento em blockchain transmitida.

[0047] Em resposta ao servidor de autenticação validar a mensagem de informação de pagamento em blockchain, o aparelho de equipamento de usuário 300 recebe acesso à rede (por exemplo, à rede de comunicação móvel). Em determinadas modalidades, é concedido acesso limitado ao aparelho de equipamento de usuário 300 até que a transação em blockchain seja confirmada. Observar que o servidor de autenticação recebe uma pluralidade de mensagens de confirmação provenientes da rede de blockchain em resposta ao pagamento/transação em blockchain. Neste documento, cada mensagem de confirmação confirma “mineração” e inserção com sucesso da transação na contabilidade compartilhada 166 da rede de blockchain 160. Além disso, a rede de comunicação móvel fornece acesso à rede ao aparelho de equipamento de usuário 300 em uma variedade de níveis baseados no número de mensagens de confirmação recebidas.

[0048] Por exemplo, a rede de comunicação móvel pode fornecer um primeiro nível de acesso à rede em resposta à validação da transação em blockchain e antes da recepção de uma primeira mensagem de confirmação. Neste documento, o primeiro nível de acesso à rede é um nível reduzido de acesso que limita pelo menos um de uma taxa de tráfego da unidade remota, um número de destinos acessíveis à unidade remota pela rede, e um número de protocolos e portas de comunicação acessíveis à unidade remota. Como outro exemplo, a rede de comunicação móvel pode fornecer um segundo nível de acesso à rede em resposta à recepção de uma primeira mensagem de confirmação. Neste documento, o segundo nível de acesso à rede é um nível intermediário de acesso que relaxa alguns, mas não todos, os limites do primeiro nível de acesso à rede. Como um exemplo adicional, a rede de comunicação móvel pode fornecer um terceiro nível de acesso à rede em resposta à recepção de um número limite de mensagens de confirmação. Neste documento, o terceiro nível de acesso é um nível total de acesso que remove todas as limitações de tráfego do primeiro nível de acesso e do segundo nível de acesso.

[0049] Em diversas modalidades, o transceptor 325 recebe mensagem de confirmação que contém uma chave de sessão mestra criptografada para proteção de tráfego entre o aparelho de equipamento de usuário 300 e uma unidade de base. Neste documento, o processador 305 descriptografa a chave de sessão mestra usando a chave privada do aparelho de equipamento de usuário 300. O transceptor 325 recebe mensagem de confirmação em resposta ao servidor de autenticação validar a informação de pagamento em blockchain recebida (por exemplo, validação de uma nova transação ou validação de uma transação referenciada anterior). Quando a informação de pagamento em blockchain recebida referencia uma transação anterior, o processador 305 gera uma nova chave de sessão mestra.

[0050] Em diversas modalidades, o processador 305 inicia uma sessão EAP quando se comunica com o servidor de autenticação. Em uma modalidade, o processador 305 inicia uma sessão EAP-CRY com o servidor de autenticação, com a mensagem de solicitação de pagamento sendo a primeira mensagem da sessão EAP-CRY. Além disso, a mensagem de informação de pagamento em blockchain e a mensagem de confirmação (incluindo a mensagem que contém a chave de sessão mestra criptografada) são transmitidas dentro da sessão EAP-CRY.

[0051] A memória 310, em uma modalidade, é um meio de armazenamento legível por computador. Em algumas modalidades, a memória 310 inclui meios de armazenamento em computador voláteis. Por exemplo, a memória 310 pode incluir uma RAM, incluindo RAM dinâmica (“DRAM”), RAM dinâmica síncrona (“SDRAM”) e/ou RAM estática (“SRAM”). Em algumas modalidades, a memória 310 inclui meios de armazenamento em computador não-voláteis. Por exemplo, a memória 310 pode incluir uma unidade de disco rígido, uma memória flash, ou qualquer outro dispositivo de armazenamento em computador não-volátil adequado. Em algumas modalidades, a memória 310 inclui ambos os meios de armazenamento em computador voláteis e não-voláteis. Em algumas modalidades, a memória 310 armazena dados referentes a acesso à rede usando pagamentos em blockchain, por exemplo armazenando chaves de sessão, IDs de transação, endereços de blockchain, identificadores de unidades remotas, e similares. Em algumas modalidades, a memória 310 também armazena código de programa e dados correlatos, tais como um sistema operacional ou outros algoritmos de controlador que operam o aparelho de equipamento de usuário 300 e um ou mais aplicativos de software.

[0052] O dispositivo de entrada 315, em uma modalidade, pode incluir qualquer dispositivo conhecido de entrada de computador incluindo um painel de toque, um botão, um teclado, um estilete, um microfone, ou similar. Em algumas modalidades, o dispositivo de entrada 315 pode estar integrado ao visor 320, por exemplo, como uma tela sensível ao toque ou visor sensível ao toque similar. Em algumas modalidades, o dispositivo de entrada 315 inclui uma tela sensível ao toque de modo que texto possa ser inserido usando um teclado virtual exibido na tela sensível ao toque e/ou por escrita manual sobre a tela sensível ao toque. Em algumas modalidades, o dispositivo de entrada 315 inclui dois ou mais diferentes dispositivos, tais como um teclado e um painel de toque.

[0053] O visor 320, em uma modalidade, pode incluir qualquer conhecido visor controlado eletronicamente ou dispositivo de exibição. O visor 320 pode ser projetado para enviar sinais visuais, audíveis e/ou hápticos. Em algumas modalidades, o visor 320 inclui um visor eletrônico capaz de enviar dados visuais a um usuário. Por exemplo, o visor 320 pode incluir um visor de LCD, um visor de LED, um visor de OLED, um projetor, ou dispositivo de exibição similar capaz de enviar imagens, texto ou similar a um usuário, mas não limitado a estes. Como outro exemplo não- limitativo, o visor 320 pode incluir um visor vestível tal como relógio inteligente, óculos inteligentes, um visor no topo da cabeça, ou similar. Além disso, o visor 320 pode ser um componente de um smartphone, um assistente digital pessoal, uma televisão, um computador de mesa, um computador portátil (laptop), um computador pessoal, um painel de controle de veículo, ou similar.

[0054] Em determinadas modalidades, o visor 320 inclui um ou mais alto-falantes para produzir som. Por exemplo, o visor 320 pode produzir um alerta ou notificação audível (por exemplo, um bip ou repique). Em algumas modalidades, o visor 320 inclui um ou mais dispositivos hápticos para produzir vibrações, movimento, ou outra realimentação háptica. Em algumas modalidades, todo ou partes do visor 320 podem estar integradas com o dispositivo de entrada 315. Por exemplo, o dispositivo de entrada 315 e o visor 320 podem formar uma tela sensível ao toque ou visor sensível ao toque similar. Em outras modalidades, o visor 320 pode estar localizado próximo do dispositivo de entrada 315.

[0055] Em determinadas modalidades, o transceptor 325 é configurado para comunicar-se com a unidade de base 110 e com uma ou mais funções de rede de uma rede de comunicação móvel tal como o servidor de autenticação. O transceptor 325 opera sob o controle do processador 305 para transmitir mensagens, dados e outros sinais e também para receber mensagens, dados e outros sinais. Por exemplo, o processador 305 pode seletivamente ativar o transceptor (ou partes deste) em instantes específicos com a finalidade de enviar e receber mensagens. O transceptor 325 pode incluir um ou mais transmissores 330 e um ou mais receptores 335. Como discutido acima, o transceptor 325 pode suportar uma ou mais das interfaces de rede 340 para comunicação com a unidade de base 110 e/ou servidor de autenticação.

[0056] A Figura 4 representa uma modalidade de um aparelho de autenticação 400 que pode ser usado para acesso à rede usando pagamentos em blockchain, de acordo com modalidades da revelação. O aparelho de autenticação 400 pode ser uma modalidade da função de autenticação 132 e/ou da BESF 136. Além disso, o aparelho de autenticação 400 pode incluir um processador 405, uma memória 410, um dispositivo de entrada 415, um visor 420 e um transceptor

425. Em algumas modalidades, o dispositivo de entrada 415 e o visor 420 são combinados em um único dispositivo, tal como uma tela sensível ao toque. Em determinadas modalidades, o aparelho de autenticação 400 pode não incluir qualquer dispositivo de entrada 415 e/ou visor 420.

[0057] Como representado, o transceptor 425 inclui pelo menos um transmissor 430 e pelo menos um receptor 435. Adicionalmente, o transceptor 425 pode suportar pelo menos uma interface de rede 440. Neste documento, a interface de rede 440 facilita comunicação com uma ou mais funções de rede, tal como a função de portal 134, e um ou mais nós de blockchain 164 na rede de blockchain 160. Além disso, o transceptor 425 facilita comunicação com uma unidade remota 105, tal como o UE 205, por meio da unidade de base 110 (ou gNB 210).

[0058] O processador 405, em uma modalidade, pode incluir qualquer controlador conhecido capaz de executar instruções legíveis por computador e/ou capaz de executar operações lógicas. Por exemplo, o processador 405 pode ser um microcontrolador, um microprocessador, uma unidade de processamento central (“CPU”), uma unidade de processamento gráfico (“GPU”), uma unidade de processamento auxiliar, uma matriz de portas programáveis de campo (“FPGA”), ou controlador programável similar. Em algumas modalidades, o processador 405 executa instruções armazenadas na memória 410 para executar os métodos e rotinas descritos neste documento. O processador 405 está acoplado comunicativamente à memória 410, ao dispositivo de entrada 415, ao visor 420 e ao transceptor 425.

[0059] Em algumas modalidades, o transceptor 425 recebe uma mensagem de solicitação de autenticação para uma unidade remota, tal como o UE 205. Neste documento, a mensagem de solicitação de autenticação inclui um identificador de unidade remota, tal como um identificador de endereço de rede (“NAI”) ou identificador de equipamento de usuário (“UEID”), que indica que a unidade remota está solicitando acesso à rede por meio de um pagamento em blockchain. Em um exemplo, o identificador de unidade remota é um NAI com um domínio ou âmbito específico à rede de blockchain por meio do qual a unidade remota deseja fazer um pagamento em blockchain. Neste documento, diferentes redes de blockchain podem ter seus próprios domínios/âmbitos, de modo que a rede de blockchain desejada seja facilmente identificada pelo NAI. Além disso, o uso de um NAI com um domínio ou âmbito específico a uma rede de blockchain indica ao aparelho de autenticação 400 que a unidade remota está solicitando acesso à rede por meio de um pagamento em blockchain. Portanto, a unidade remota implicitamente sinaliza a sua solicitação para usar um pagamento em blockchain para acessar a rede (ao contrário de usar uma assinatura ou conta com a rede) pelo envio do identificador de unidade remota associado à rede de blockchain.

[0060] Após recepção da mensagem de autenticação, o processador 405 examina o identificador de unidade remota. Em uma modalidade, a unidade remota tem uma assinatura e o aparelho de autenticação 400 está localizado em uma rede doméstica (por exemplo, H-PLMN) para a unidade remota. Em outra modalidade, a unidade remota tem uma assinatura em outra rede e o aparelho de autenticação 400 está localizado em uma rede visitada (V-PLMN). Em diversas modalidades, a unidade remota não confia em uma assinatura de rede para obter acesso à rede, mas ao invés faz um pagamento em blockchain por meio do aparelho de autenticação 400 com a finalidade de obter acesso à rede.

[0061] Em resposta à unidade remota solicitar acesso à rede por meio de um pagamento em blockchain, o processador 405 gera um primeiro endereço para a rede de blockchain indicada pelo identificador de unidade remota (por exemplo, um primeiro “endereço de blockchain”). O primeiro endereço é um endereço “de pagamento” para receber o pagamento em blockchain. Em algumas modalidades, o processador 405 gera um novo endereço de pagamento na rede de blockchain indicado pelo identificador de unidade remota (por exemplo, âmbito de NAI). Como um exemplo, a rede de blockchain indicada pelo identificador de unidade remota pode ser a rede BitcoinTM, em que o processador 405 gera um novo endereço de BitcoinTM para aceitar o pagamento. Por toda a revelação, modalidades descrevem a realização de pagamentos em BitcoinTM, uma vez que BitcoinTM é um exemplo bem conhecido de tecnologia de blockchain. Contudo, outras tecnologias de blockchain podem ser usadas com as modalidades descritas e podem mesmo ter melhor desempenho que a rede BitcoinTM, por exemplo, devido à oferta de menores atrasos de confirmação de transações.

[0062] Em determinadas modalidades, o processador

405 pode reutilizar um endereço de blockchain previamente gerado como o endereço de pagamento para receber o pagamento em blockchain. Em outras modalidades, o processador 405 cria um novo endereço sempre que um novo pagamento tiver que ser feito, com a finalidade de aumentar o anonimato e a segurança. Adicionalmente, o processador 405 controla o transceptor 425 para enviar o endereço de rede de blockchain gerado à unidade remota.

[0063] Em algumas modalidades, o processador 405 controla o transceptor 425 para enviar uma mensagem de solicitação de pagamento à unidade remota. Neste documento, a mensagem de solicitação de pagamento pode incluir o endereço gerado e uma ou mais opções de valor. Como usado neste documento, uma opção de valor refere-se a uma quantidade de acesso à rede (por exemplo, medido por tempo e/ou consumo de dados) a ser recebida na troca por um montante de valor (por exemplo, montante de pagamento). Cada opção de valor na mensagem de solicitação de pagamento indica um montante de acesso à rede e correspondente valor de pagamento.

[0064] O transceptor 425 recebe informação de pagamento da unidade remota. Em resposta à recepção da informação de pagamento, o processador 405 valida a informação de pagamento recebida e fornece acesso à rede à unidade remota em resposta à validação com sucesso da informação de pagamento recebida. Em uma modalidade, a informação de pagamento em blockchain recebida inclui uma transação em blockchain. Em outra modalidade, a informação de pagamento em blockchain recebida é uma referência a uma transação em blockchain anterior.

[0065] Observar que o transceptor 425 recebe uma pluralidade de mensagens de confirmação da rede de blockchain em resposta ao pagamento/transação em blockchain. Neste documento, cada mensagem de confirmação confirma “mineração” e inserção com sucesso da transação na contabilidade compartilhada 166 da rede de blockchain 160. Além disso, o processador 405 fornece acesso à rede à unidade remota em uma variedade de níveis baseados no número de mensagens de confirmação recebidas.

[0066] Por exemplo, o processador 405 pode fornecer um primeiro nível de acesso à rede em resposta à validação da transação em blockchain e antes da recepção de uma primeira mensagem de confirmação. Neste documento, o primeiro nível de acesso à rede é um nível reduzido de acesso que limita pelo menos um de uma taxa de tráfego da unidade remota, um número de destinos acessíveis à unidade remota pela rede, e um número de protocolos e portas de comunicação acessíveis à unidade remota. Como outro exemplo, a rede de comunicação móvel pode fornecer um segundo nível de acesso à rede em resposta à recepção de uma primeira mensagem de confirmação. Neste documento, o segundo nível de acesso à rede é um nível intermediário de acesso que relaxa alguns, mas não todos, os limites do primeiro nível de acesso à rede. Como um exemplo adicional, o processador 405 pode fornecer um terceiro nível de acesso à rede em resposta à recepção de um número limite de mensagens de confirmação. Neste documento, o terceiro nível de acesso é um nível total de acesso que remove todas as limitações de tráfego do primeiro nível de acesso e do segundo nível de acesso.

[0067] Quando a informação de pagamento em blockchain recebida inclui uma nova transação em blockchain, a informação de pagamento em blockchain recebida indica um valor a ser pago correspondente a uma opção de valor selecionada. Por exemplo, a unidade remota pode apresentar as diversas opções de valor ao usuário, em que o usuário seleciona uma opção de valor que é em seguida incluído na mensagem de informação de pagamento em blockchain. Além disso, a mensagem de informação de pagamento em blockchain pode conter uma transação em blockchain. Alternativamente, a mensagem de informação de pagamento em blockchain pode conter parâmetros suficientes para o processador 405 gerar uma transação em blockchain em nome da unidade remota. Em diversas modalidades, a informação de pagamento em blockchain recebida inclui também uma chave pública da unidade remota.

[0068] Quando a informação de pagamento em blockchain recebida inclui uma referência a uma transação em blockchain anterior, a mensagem de informação de pagamento em blockchain recebida pode conter uma ID e/ou uma assinatura de transação. Neste documento, o processador 405 valida a informação de pagamento em blockchain procurando o ID de transação de referência e determinando (por exemplo, usando uma assinatura) se a transação anterior referenciada foi feita pela unidade remota (ou usuário associado à unidade remota). Além disso, o processador 405 determina se a transação anterior referenciada tem qualquer valor remanescente. Por exemplo, quando o pagamento em blockchain adquire um bloco de tempo, o processador 405 pode determinar se resta algum tempo.

Como outro exemplo, quando o pagamento em blockchain adquire uma quantidade de dados (por exemplo, 1 GB), o processador 405 pode determinar se restam alguns dados.

[0069] Quando a transação anterior referenciada tem valor remanescente, o processador 405 gera uma mensagem de confirmação e concede acesso à rede até que não exista valor remanescente associado à transação. Se a transação anterior referenciada não tem valor remanescente (ou não foi feita pelo mesmo usuário ou unidade remota), então o processador 405 gera uma mensagem de solicitação de pagamento e controla o transceptor 425 a enviar a mensagem de solicitação de pagamento à unidade remota.

[0070] Em diversas modalidades, o processador 405 gera uma chave de sessão mestra para proteger tráfego na unidade remota. Neste documento, o processador 405 gera a chave de sessão mestra em resposta à validação da informação de pagamento em blockchain recebida (por exemplo, validação de uma nova transação ou validação de uma transação anterior referenciada). Quando a informação de pagamento em blockchain recebida referencia uma transação anterior, o processador 405 gera uma nova chave de sessão mestra.

[0071] Além disso, o processador 405 criptografa a chave de sessão mestra gerada usando uma chave pública associada à unidade remota e controla o transceptor 425 para enviar as chaves de sessão mestra criptografadas à unidade remota. Por exemplo, o processador 405 pode incluir a chave de sessão mestra criptografada em uma mensagem de confirmação. Em seguida, a unidade remota usa a sua chave privada (por exemplo, correspondente à chave pública enviada na mensagem de informação de pagamento em blockchain) para descriptografar a chave de sessão mestra. A chave de sessão mestra serve como uma chave comum entre a unidade remota e a rede de acesso para proteger o tráfego na interface aérea. Consequentemente, o processador 405 controla o transceptor 425 para enviar uma cópia da chave de sessão mestra à unidade de base por meio da qual a unidade remota acessa a rede.

[0072] Em diversas modalidades, o processador 405 inicia uma sessão EAP quando se comunica com a unidade remota. Em uma modalidade, o processador 405 inicia uma sessão EAP-CRY em resposta à geração do novo endereço de pagamento, com a mensagem de solicitação de pagamento sendo a primeira mensagem da sessão EAP-CRY. Além disso, a mensagem de informação de pagamento em blockchain e a mensagem de confirmação (incluindo a mensagem que contém a chave de sessão mestra criptografada) são transmitidas dentro da sessão EAP-CRY. Neste documento, EAP-CRY é um método EAP que é executado em cima de EAP, como discutido abaixo com referência à Figura 7.

[0073] A memória 410, em uma modalidade, é um meio de armazenamento legível por computador. Em algumas modalidades, a memória 410 inclui meios de armazenamento em computador voláteis. Por exemplo, a memória 410 pode incluir uma RAM, incluindo RAM dinâmica (“DRAM”), RAM dinâmica síncrona (“SDRAM”) e/ou RAM estática (“SRAM”). Em algumas modalidades, a memória 410 inclui meios de armazenamento em computador não-voláteis. Por exemplo, a memória 410 pode incluir uma unidade de disco rígido, uma memória flash, ou qualquer outro dispositivo de armazenamento em computador não-volátil adequado. Em algumas modalidades, a memória 410 inclui ambos os meios de armazenamento em computador voláteis e não-voláteis. Em algumas modalidades, a memória 410 armazena dados referentes a acesso à rede usando pagamentos em blockchain, por exemplo armazenando chaves de sessão, IDs de transação, endereços de blockchain, identificadores de unidades remotas, e similares. Em algumas modalidades, a memória 410 também armazena código de programa e dados correlatos, tais como um sistema operacional ou outros algoritmos de controlador que operam o aparelho de equipamento de autenticação 400 e um ou mais aplicativos de software.

[0074] O dispositivo de entrada 415, em uma modalidade, pode incluir qualquer dispositivo conhecido de entrada de computador incluindo um painel de toque, um botão, um teclado, um estilete, um microfone, ou similar. Em algumas modalidades, o dispositivo de entrada 415 pode estar integrado ao visor 420, por exemplo, como uma tela sensível ao toque ou visor sensível ao toque similar. Em algumas modalidades, o dispositivo de entrada 415 inclui uma tela sensível ao toque de modo que texto possa ser inserido usando um teclado virtual exibido na tela sensível ao toque e/ou por escrita manual sobre a tela sensível ao toque. Em algumas modalidades, o dispositivo de entrada 415 inclui dois ou mais diferentes dispositivos, tais como um teclado e um painel de toque.

[0075] O visor 420, em uma modalidade, pode incluir qualquer conhecido visor ou dispositivo de exibição controlável eletronicamente. O visor 420 pode ser projetado para enviar sinais visuais, audíveis e/ou hápticos. Em algumas modalidades, o visor 420 inclui um visor eletrônico capaz de enviar dados visuais a um usuário. Por exemplo, o visor 420 pode incluir um visor de LCD, um visor de LED, um visor de OLED, um projetor, ou dispositivo de exibição similar capaz de enviar imagens, texto ou similar a um usuário, mas não limitado a estes. Como outro exemplo não- limitativo, o visor 420 pode incluir um visor vestível tal como relógio inteligente, óculos inteligentes, um visor no topo da cabeça, ou similar. Além disso, o visor 420 pode ser um componente de um smartphone, um assistente digital pessoal, uma televisão, um computador de mesa, um computador portátil (laptop), um computador pessoal, um painel de controle de veículo, ou similar.

[0076] Em determinadas modalidades, o visor 420 inclui um ou mais alto-falantes para produzir som. Por exemplo, o visor 420 pode produzir um alerta ou notificação audível (por exemplo, um bip ou repique). Em algumas modalidades, o visor 420 inclui um ou mais dispositivos hápticos para produzir vibrações, movimento, ou outra realimentação háptica. Em algumas modalidades, todo ou partes do visor 420 podem estar integradas ao dispositivo de entrada 415. Por exemplo, o dispositivo de entrada 415 e o visor 420 podem formar uma tela sensível ao toque ou visor sensível ao toque similar. Em outras modalidades, o visor 420 pode estar localizado próximo do dispositivo de entrada 415.

[0077] Em determinadas modalidades, o transceptor 425 é configurado para comunicar-se com a rede de blockchain 160, a unidade remota 105 (por meio da unidade de base 110) e com uma ou mais funções de rede de uma rede de comunicação móvel. O transceptor 425 opera de acordo com o controle do processador 405 para transmitir mensagens, dados e outros sinais e também receber mensagens, dados e outros sinais. Por exemplo, o processador 405 pode seletivamente ativar o transceptor (ou partes deste) em instantes específicos com a finalidade de enviar e receber mensagens. O transceptor 425 pode incluir um ou mais transmissores 430 e um ou mais receptores 435. Como discutido acima, o transceptor 425 pode suportar uma ou mais das interfaces de rede 440 para comunicação com a unidade de base 110 e/ou a unidade remota 105.

[0078] As Figuras 5A-5B representam procedimento de rede 500 para acesso à rede usando pagamentos em blockchain, de acordo com modalidades da revelação. O procedimento de rede 500 representa um exemplo de uma unidade remota (por exemplo, o UE 205) fazendo uma transação em blockchain para obter acesso à rede. O procedimento de rede 500 envolve o UE 205, uma unidade de base 110, a BESF 136 e a rede de blockchain 160.

[0079] Na Figura 5A, o procedimento de rede 500 começa com o UE selecionando uma rede de acesso (representada pela unidade de base 110) e executando associação de rede com a unidade de base 110 (vide sinalização 502). Em uma modalidade, a unidade de base 110 é um gNB ou eNB. Em outra modalidade, a unidade de base 110 é um ponto de acesso sem fio, tal como um ponto de acesso de WI-FITM ou outro AP de WLAN.

[0080] Após associação, a unidade de base 110 inicia um procedimento de autenticação baseado em EAP com o UE 205 (vide sinalização 504). Neste documento, o UE 205 é solicitado a fornecer o seu NAI ou outro ID de UE. Recordar que um NAI tem a forma ‘nome_de_usuário@domínio’ (username@realm).

[0081] O UE 205 fornece o seu NAI (ou outro ID de UE) à unidade de base 110 (vide sinalização 506). Neste documento, o NAI usa um nome de âmbito ou domínio especial com a finalidade de indicar à unidade de base 110 que o UE 205 quer acessar a rede fazendo um pagamento em blockchain ou pagamento em criptomoeda. Adicionalmente, o âmbito do NAI indica que rede de blockchain o UE 205 prefere para pagamento. Por exemplo, o domínio ‘bitcoin.crypto’ pode ser usado no NAI para indicar que o UE 205 prefere pagar com bitcoins usando a rede de blockchain bitcoin. Consequentemente, ao incluir um domínio especial, o UE 205 implicitamente sinaliza uma solicitação para acessar a rede usando uma transação em blockchain.

[0082] Com base no domínio fornecido, a unidade de base 110 envia uma mensagem de solicitação de AAA à BESF

136. Observar que a BESF 136 é uma função de processo interno que é responsável pela configuração de uma sessão de pagamento com o UE 205 e pela autorização ou rejeição do acesso de UE à rede mediante utilização de um método baseado em EAP. Observar que o valor de ‘nome_de_usuário’ (username) do NAI especial pode ter qualquer valor e não é mais usado no procedimento de rede 500.

[0083] A BESF 136 cria em seguida um novo endereço de pagamento (vide bloco 508). Neste exemplo, uma vez que o UE 205 indica que prefere pagar com bitcoins, a BESF 136 cria um novo endereço de bitcoins para aceitar o pagamento. Em determinadas modalidades, um novo endereço é criado sempre que um novo pagamento tiver que ser feito, com a finalidade de evitar usar o mesmo endereço e, portanto, aumentar o anonimato.

[0084] Neste momento, a BESF 136 inicia uma sessão EAP-CRY com o UE 205 e envia uma mensagem de Solicitação de EAP que transporta uma mensagem de Solicitação de Pagamento, a mensagem de Solicitação de EAP encapsulada em uma mensagem de AAA (vide sinalização 510). A mensagem de Solicitação de EAP/Solicitação de Pagamento é uma mensagem de EAP-CRY que inclui o endereço de pagamento criado e um ou mais opções de Valor. Em determinadas modalidades, a mensagem de Solicitação de EAP/Solicitação de Pagamento inclui um parâmetro Nonce que é usado quando o UE fez um pagamento anterior a esta rede. Isto é discutido mais adiante com referência à Figura 6. Observar que o EAP-CRY é um método EAP que é executado em cima de EAP, como discutido abaixo com referência à Figura 7. A Solicitação de EAP ou Resposta de EAP é uma mensagem de EAP que transporta uma mensagem de EAP-CRY, tal como ‘Solicitação de Pagamento’, ou ‘Resposta de Pagamento’, ou ‘Pagamento Terminado’.

[0085] Em uma modalidade, uma opção de Valor indica o valor a ser pago com a finalidade de permitir acesso à rede durante algum período de tempo. Por exemplo, uma opção de Valor (0,001, 1 hora) indica que um pagamento de 0,001 bitcoin deverá ser feito para permitir acesso à rede durante 1 hora. Em outra modalidade, uma opção de Valor indica o valor a ser pago com a finalidade de permitir acesso à rede durante algum montante de tráfego. Por exemplo, uma opção de Valor (0,001, 1 GB) indica que um pagamento de 0,001 bitcoin deverá ser feito para permitir acesso à rede até que 1 GB de tráfego tenha sido consumido.

[0086] Em uma modalidade, o UE 205 apresenta uma solicitação de pagamento ao usuário em resposta à recepção da mensagem de Solicitação de EAP/Solicitação de Pagamento. Em determinadas modalidades, o UE 205 determina se um pagamento anterior foi feito à rede e tem valor remanescente. A Figura 6 descreve o cenário onde foi feito um pagamento anterior. Contudo, no procedimento de rede 500 é assumido que não existe pagamento anterior, portanto o UE 205 pede ao usuário para autorizar um novo pagamento e para selecionar o valor a ser pago (vide bloco 514). No exemplo representado, o usuário seleciona pagar 0,002 bitcoin com a finalidade de acessar a rede durante 3 horas.

[0087] Em resposta ao usuário selecionar uma opção de Valor, o UE 205 envia uma mensagem de informação de pagamento em blockchain, tal como uma mensagem de Resposta de EAP/Resposta de Pagamento, à BESF 136 (vide sinalização 516) que inclui uma transação regular em bitcoins (recordar que o domínio indicou um pagamento em bitcoins e o que endereço de pagamento é o endereço de bitcoins). De acordo com as especificações de bitcoins, esta transação inclui: 1) uma Identidade de Transação (“TxID”), 2) uma ou mais Entradas, e 3) uma ou mais Saídas. Cada Entrada refere-se a uma transação anterior em bitcoins (TxID-i) e uma saída nesta referencia transação (Saída-n). Esta saída referenciada indica as bitcoins que foram previamente recebidos pelo usuário e serão agora gastos para fazer este pagamento (por exemplo, 0,002 bitcoin). Além disso, cada Entrada inclui uma Chave Pública e uma Assinatura que provam que o usuário possui as bitcoins na saída referenciada, por exemplo, o UE 205 detém a necessária chave privada. Uma Saída indica o valor de bitcoins a ser pago ao endereço de pagamento (por exemplo, 0,002 bitcoin). Uma Saída adicional pode ser incluída para devolver troco ao remetente (por exemplo, quando a saída referenciada na Entrada é maior que o valor pago de 0,002 bitcoin).

[0088] A BESF 136, que mantém uma cópia da blockchain de bitcoins, valida a transação enviada pelo UE 205 (vide bloco 518). Neste documento, a validação refere- se à confirmação de que as bitcoins na saída referenciada já não foram gastas e que pertencem ao usuário que fez o pagamento. Se a validação tiver sucesso, então uma nova transação é difundida na rede de blockchain que será processada como normalmente por todos os nós de blockchain (vide sinalização 520).

[0089] A BESF 136 cria então uma nova Chave de Sessão Mestra (“MSK”, vide bloco 522). Por exemplo, esta chave pode ser criada aleatoriamente ou mediante utilização de qualquer outro método adequado. Em seguida a BESF 136 criptografa a MSK mediante utilização da chave pública do UE 205 (por exemplo, enviada previamente pelo UE 205 na mensagem de informação de pagamento em blockchain). A finalidade da MSK é servir como uma chave comum entre o UE 205 e a rede de acesso (por exemplo, unidade de base 110) para proteção do tráfego pela interface aérea. No caso de redes de acesso WI-FITM, a MSK é usada para obter a Chave Mestra Emparelhada (PMK) e outras chaves filhas, como especificado na especificação IEEE 802.11. Se necessário, a BESF 136 pode também criar uma MSK Estendida. Observar que a MSK e a EMSK são chaves criadas a partir de uma execução do método EAP com sucesso (neste documento, o método EAP- CRY).

[0090] O procedimento 500 continua na Figura 5B com a BESF 136 enviando a MSK criptografada ao UE 205 dentro de uma mensagem de Solicitação de EAP/Pagamento Terminado (vide sinalização 524). O UE 205 usa em seguida a chave privada associada para descriptografar a MSK (vide bloco 526) e em seguida responde com uma mensagem de Resposta de EAP/Reconhecimento de Pagamento Terminado (vide sinalização 528).

[0091] A BESF 136 termina o procedimento EAP-CRY pelo envio de uma mensagem de Sucesso de EAP (vide sinalização 530). Por meio da mensagem de Sucesso de EAP, a BESF 136 encaminha a MSK à unidade de base 110 de modo que possa proteger o tráfego pela interface aérea. O UE 205 e a unidade de base 110 criam chaves para proteger o tráfego pela interface aérea mediante utilização da MSK comum (vide sinalização 532). No caso da unidade de base 110 ser uma rede de acesso WI-FITM, estas chaves podem ser criadas por meio do “handshake” de 4 vias especificado em IEEE 802.11i.

[0092] Neste momento, o UE 205 submeteu um pagamento (a nova transação em bitcoins na sinalização 516) que foi validado pela BESF 136 e foi difundida na rede de blockchain 160. Observar, contudo, que este pagamento não é ainda confirmado pela rede de blockchain 160. Até que o pagamento seja totalmente confirmado a rede de comunicação móvel deve aplicar limitações ao tráfego associado ao UE 205 (vide bloco 534). Por exemplo, o UE 205 pode ser inicialmente limitado a um primeiro nível.

[0093] Em um exemplo de limitações de tráfego, a rede de comunicação móvel pode aceitar o UE 205, mas limita a taxa de tráfego do UE 205 a algum valor predefinido. Em outro exemplo de limitações de tráfego, a rede de comunicação móvel pode aceitar o UE 205, mas permitir que o UE 205 acesse apenas alguns domínios predefinidos (por exemplo, google.com, facebook.com, etc.). Estas limitações poderão ser definidas pela BESF 136 e ser retransmitidas à Função de Portal 134, que é responsável por aplicá-las.

[0094] A transação de pagamento já está inserida em uma blockchain de bitcoins e passa pelo processo normal de mineração que pode durar um longo período de tempo. No caso de bitcoin, a mineração pode levar tipicamente de 10 minutos a um par de horas, mas para outras redes de blockchain 160 a mineração pode ser consideravelmente mais curta (por exemplo, 1-3 minutos). Após a transação de pagamento ser minerada, é inserida em um novo bloco na blockchain e o bloco é difundido por toda a rede de blockchain 160. Este modo é também recebido pela BESF 136 que é parte da rede de blockchain 160. Neste momento, a transação de pagamento tem uma confirmação e, como resultado, a BESF 136 pode instruir a Função de Portal 134 a reduzir as limitações de tráfego para o UE 205 (por exemplo, aumentar a taxa máxima de tráfego, etc., vide bloco 538). Agora foi concedido ao UE 205 um segundo nível de acesso.

[0095] À medida que mais e mais blocos de bitcoins são minerados, a transação de pagamento recebe mais e mais confirmações. Quando a BESF 136 determina que foram recebidas confirmações suficientes (por exemplo, um limite de N confirmações), então aquela instrui a Função de Portal 134 a remover as limitações de tráfego do primeiro e do segundo níveis para o UE 205 (vide bloco 540). Observar que podem ainda existir limitações colocadas sobre o UE 205 não relacionadas com a confirmação de pagamento. O procedimento 500 termina.

[0096] As Figuras 6A-6B representam um procedimento de rede 600 para acesso à rede usando pagamentos em blockchain, de acordo com modalidades da revelação. O procedimento de rede 600 representa um exemplo de uma unidade remota (por exemplo, o UE 205) que solicita acesso à rede baseada em um pagamento anterior à rede de blockchain. O procedimento de rede 600 envolve um UE 205, uma unidade de base 110 e a BESF 136. Aqui, o UE 205 já fez um pagamento em blockchain e não necessita fazer outro pagamento em blockchain devido ao valor remanescente na transação anterior. Uma vez que o UE 205 tenta acessar a rede novamente antes da transação anterior expirar, o UE 205 refere-se ao pagamento em blockchain anterior e prova que foi ele que fez o pagamento.

[0097] Na Figura 6A, o procedimento de rede 600 começa com o UE 205 selecionando uma rede de acesso (representada pela unidade de base 110) e executando associação de rede com a unidade de base 110 (vide sinalização 602). Após associação, a unidade de base 110 inicia um procedimento de autenticação baseado em EAP com o UE 205 (vide sinalização 604). Aqui, o UE 205 é solicitado a fornecer o seu NAI ou outro ID de UE. Recordar que um NAI tem a forma ‘nome_de_usuário@domínio’ (username@realm).

[0098] O UE 205 fornece o seu NAI (ou outro ID de

UE) à unidade de base 110 (vide sinalização 506). Aqui, o NAI usa um nome de âmbito ou domínio especial com a finalidade de indicar à unidade de base 110 que o UE 205 deseja acessar a rede fazendo um pagamento em blockchain ou pagamento em criptomoeda. Adicionalmente, o domínio do NAI indica em que rede de blockchain o UE prefere fazer o pagamento. Consequentemente, ao incluir o domínio especial, o UE 205 implicitamente sinaliza uma solicitação para acessar a rede usando uma transação em blockchain.

[0099] Baseada no domínio fornecido, a unidade de base 110 envia uma mensagem de solicitação de AAA à BESF

136. Observar que a BESF 136 é uma função de infraestrutura que é responsável pela configuração de uma sessão de pagamento com o UE 205 e pela autorização ou rejeição do acesso do UE à rede mediante utilização de um método baseado em EAP. Observar que o valor de ‘nome_de_usuário’ do NAI especial pode ter qualquer valor e não é mais usado no procedimento de rede 600.

[00100] A BESF 136 cria em seguida um novo endereço de pagamento (vide bloco 608). Neste exemplo, uma vez que o UE 205 indica que prefere pagar com bitcoins, a BESF 136 cria um novo endereço de bitcoins para aceitar o pagamento. Em determinadas modalidades, um novo endereço é criado sempre que um novo pagamento tiver que ser feito com a finalidade de evitar usar o mesmo endereço e, portanto, aumentar o anonimato.

[00101] Neste momento, a BESF 136 inicia uma sessão EAP-CRY com o UE 205 ao enviar uma mensagem de Solicitação de EAP/Solicitação de Pagamento, encapsulada em uma mensagem de AAA (vide sinalização 610). Esta mensagem de

EAP-CRY é uma mensagem de solicitação de pagamento que inclui o endereço de pagamento criado e uma ou mais opções de Valor, como discutido acima. Em uma modalidade, o UE 205 apresenta uma solicitação de pagamento ao usuário em resposta à recepção da mensagem de Solicitação de EAP/Solicitação de Pagamento.

[00102] Em determinadas modalidades, o UE 205 determina se um pagamento anterior foi feito à rede e se existe valor remanescente. Neste documento, é assumido que existiu pagamento anterior com valor remanescente. Portanto, o UE 205 determina (por exemplo, baseado nas transações anteriores armazenadas) que já foi feito um pagamento para acessar esta rede (vide bloco 612).

[00103] Portanto, o UE 205 envia uma Resposta de EAP/Resposta de Pagamento que não inclui uma nova transação de pagamento, mas inclui apenas uma referência a uma transação anterior (TxID) e uma Assinatura_Nonce (Nonce_ Signature) (vide sinalização 614). A Assinatura_Nonce é obtida mediante utilização do Nonce recebido na mensagem de solicitação de pagamento (vide sinalização 610) e da chave privada que foi usada para assinar a transação anterior. Essencialmente, a Assinatura_Nonce confirma que o UE 205 é aquele que fez a referida transação anterior.

[00104] Uma vez que a BESF 136 conhece a chave pública associada à transação anterior referenciada, aquela usa a chave pública junto com Assinatura_Nonce para confirmar que o UE 205 é realmente aquele que fez a transação anterior ‘TxID’ (vide bloco 616). Além disso, a BESF 136 também confirma que a transação anterior (por exemplo, pagamento) ainda tem valor remanescente, por exemplo, o seu período de validade não expirou, ou o seu volume máximo de dados não foi alcançado (vide bloco 616).

[00105] Continuando na Figura 6B, se a BESF 136 determina que a transação anterior referenciada (por exemplo, pagamento) não tem valor remanescente, ou que o UE 205 não é aquele que fez esta transação, então a BESF 136 envia outra Resposta de EAP/Resposta de Pagamento solicitando o UE 205 a fazer um novo pagamento (vide sinalização opcional 618). Neste caso não é fornecido um Nonce. Quando o UE 205 responde à segunda mensagem de solicitação de pagamento (por exemplo, fazendo um novo pagamento em blockchain), o procedimento mostrado na Figura 5 é executado começando da sinalização 516. Neste documento é assumido que a transação anterior referenciada tem valor remanescente.

[00106] Em resposta a confirmação/validação da transação anterior referenciada, a BESF 136 cria em seguida uma nova Chave de Sessão Mestra (“MSK”, vide bloco 620) e criptografa a MSK mediante utilização da chave pública do UE 205. A BESF 136 envia a MSK criptografada ao UE 205 dentro da mensagem de Solicitação de EAP/Pagamento Terminado (vide sinalização 622). O UE 205 usa em seguida a chave privada associada para descriptografar a MSK (vide bloco 624) e em seguida responde com uma mensagem de Resposta de EAP/Reconhecimento de Pagamento Terminado (vide sinalização 626).

[00107] A BESF 136 termina o procedimento EAP-CRY pelo envio de uma mensagem de Sucesso de EAP (vide sinalização 628). Por meio da mensagem de Sucesso de EAP, a BESF 136 encaminha a MSK à unidade de base 110 de modo que possa proteger o tráfego pela interface aérea. O UE 205 e a unidade de base 110 criam chaves para proteger o tráfego pela interface aérea mediante utilização da MSK comum (vide sinalização 630). No caso da unidade de base 110 ser uma rede de acesso WI-FITM, estas chaves podem ser criadas por meio do “handshake” de 4 vias especificado em IEEE 802.11i.

[00108] Se o pagamento anterior não está totalmente confirmado, a rede de comunicação móvel pode aplicar limitações ao tráfego associado ao UE 205 (vide bloco 632). Neste documento, a BESF 136 pode definir limitações de tráfego baseadas no número de mensagens de confirmação de transações recebidas e retransmiti-las à Função de Portal 134 para aplicação, como discutido acima. O procedimento 600 termina.

[00109] A Figura 7 representa uma arquitetura de protocolo 700 para acesso à rede usando pagamentos em blockchain, de acordo com modalidades da revelação. Neste documento, a arquitetura de protocolo 700 envolve a unidade remota 105, a unidade de base 110 e a BESF 136.

[00110] A pilha de protocolo da unidade remota 105 inclui uma camada de rádio 705 que compreende as camadas inferiores usadas para comunicação com a unidade de base 110 pela interface aérea. Neste documento, é assumido que a unidade de base 110 é um AP de WLAN, tal como um ponto de acesso de WI-FITM, pelo que a camada de rádio 705 pode incluir uma camada de WLAN e uma camada de IP (por exemplo, IPv4/v6). A unidade remota 105 também inclui uma camada de EAPoL 710 e uma camada de EAP 715. Observar que a unidade de base 110 também tem uma correspondente camada de Rádio 705, camada de EAPoL 710 e camada de EAP 715 que terminam com conexões com as camadas na unidade remota 105.

[00111] Adicionalmente, a unidade de base 110 inclui uma pilha de rede 730 e uma camada de AAA 735. Cada uma destas termina em uma correspondente camada na BESF 136. Além disso, a unidade de base 110 e a BESF 136 têm individualmente uma camada de EAP 715. Ambas a unidade remota 105 e a BESF 136 incluem uma camada de EAP-CRY 720. O EAP-CRY é um método EAP cujo protocolo é executado entre a unidade remota 105 e a BESF 136. Observar que o método EAP-CRY é executado em cima de EAP. Durante uma sessão EAP- CRY são usadas mensagens de Solicitação de EAP e/ou Resposta de EAP para transportar uma mensagem de EAP-CRY, tais como uma Solicitação de Pagamento, Resposta de Pagamento, Pagamento terminado, reconhecimento de Pagamento Terminado, ou similares.

[00112] Além disso, um aplicativo interno 740 liga a camada de EAP-CRY 720 ao cliente de blockchain 745. APIs adequadas são usadas pelo aplicativo interno 740 com a finalidade de comunicação com o protocolo de EAP-CRY (por exemplo, com EAP-CRY 720) e com o cliente de blockchain 745, que fornece acesso à rede de blockchain 160. Outra pilha de rede 730 é usada entre a BESF 136 e a rede de blockchain 160.

[00113] Observar que a camada de EAP-CRY 720 da unidade remota 105 tem acesso a uma lista de transações de pagamentos que foram realizadas pela unidade remota no passado. Usando a lista, a unidade remota pode determinar se existe um pagamento anterior com valor remanescente, como discutido acima com referência às Figuras 6A-6B. Além disso, observar que o cliente de blockchain 745 na BESF 136 tem acesso a toda a lista de transações registradas na rede de blockchain 160.

[00114] A Figura 8 representa um método 800 para acesso à rede usando pagamentos em blockchain, de acordo com modalidades da revelação. Em algumas modalidades, o método 800 é executado por uma unidade remota, tal como a unidade remota 105, o UE 205 e/ou o aparelho de equipamento de usuário 300. Em determinadas modalidades, o método 800 pode ser executado por um processador que executa código de programa, por exemplo, um microcontrolador, um microprocessador, uma CPU, uma GPU, uma unidade de processamento auxiliar, uma FPGA, ou similar.

[00115] O método 800 começa com a transmissão 805, por uma unidade remota, de uma mensagem de resposta de autenticação a uma rede de comunicação móvel. Aqui, a mensagem de resposta de autenticação inclui um identificador de unidade remota, o identificador indicando que a unidade remota está solicitando acesso à rede por meio de um pagamento em blockchain.

[00116] O método 800 inclui a recepção 810 de um endereço para uma rede de blockchain (por exemplo, um endereço de blockchain), a rede de blockchain específica sendo indicada pelo identificador de unidade remota. Em uma modalidade, receber 810 o endereço para a rede de blockchain inclui iniciar uma sessão EAP, em que o endereço é recebido por meio da sessão EAP. Além disso, podem ser trocadas diversas mensagens com a rede de comunicação móvel usando o método EAP (por exemplo, correspondente à sessão EAP).

[00117] O método 800 inclui a transmissão 815 de uma mensagem de informação de pagamento em blockchain associada a um pagamento em blockchain ao endereço recebido. Em determinadas modalidades, a mensagem de informação de pagamento em blockchain é transmitida em resposta à recepção de uma mensagem de solicitação de pagamento da rede de comunicação móvel, a mensagem de solicitação de pagamento incluindo o endereço gerado e uma ou mais opções de valor, cada opção de valor indicando um montante de acesso à rede e um correspondente valor de pagamento. Em uma modalidade, a mensagem de informação de pagamento em blockchain transmitida inclui uma nova transmissão de blockchain. Em tal modalidade, a mensagem de informação de pagamento em blockchain transmitida indica um valor a ser pago correspondente a uma opção selecionada da um ou mais opções de valor.

[00118] Em outra modalidade, a transmissão 815 da mensagem de informação de pagamento em blockchain compreende transmitir uma referência à transação anterior em uma resposta à mensagem de solicitação de pagamento. Neste documento, em resposta à recepção da mensagem de solicitação de pagamento, a unidade remota determina acessar a rede de comunicação móvel usando uma transação anterior (por exemplo, uma transação anterior que tem valor remanescente e sendo feita pelo mesmo usuário e/ou unidade remota).

[00119] O método 800 inclui a recepção 820 de acesso à rede em resposta à validação com sucesso da mensagem de informação de pagamento em blockchain. O método 800 termina. Em algumas modalidades, a recepção 820 de acesso à rede inclui receber uma chave de sessão mestra criptografada da rede de comunicação móvel e descriptografar a chave de sessão mestra com uma chave privada da unidade remota. Por exemplo, a mensagem de informação de pagamento em blockchain transmitida pode incluir uma chave pública da unidade remota, em que a chave de sessão mestra criptografada é descriptografada usando a correspondente chave privada. Quando a mensagem de informação de pagamento em blockchain faz referência a transação anterior, a chave de sessão mestra pode ser uma nova chave de sessão mestra. Além disso, a recepção 820 de acesso à rede inclui usar a chave de sessão mestra para proteger tráfego comunicado com a rede de comunicação móvel, por exemplo, pela interface aérea.

[00120] Em uma modalidade, a recepção 820 de acesso à rede inclui receber um primeiro nível de acesso em resposta à validação da mensagem de informação de pagamento em blockchain e antes da rede de comunicação móvel receber uma primeira mensagem de confirmação de transação. Em outra modalidade, a recepção 820 de acesso à rede inclui receber um segundo nível de acesso em resposta à rede de comunicação móvel receber a primeira mensagem de confirmação de transação. Em uma outra modalidade, a recepção 820 de acesso à rede inclui receber um terceiro nível de acesso em resposta à rede de comunicação móvel receber um número limite de mensagens de confirmação de transação. Nestas modalidades, o primeiro nível de acesso é um nível reduzido de acesso, o segundo nível de acesso é um nível intermediário de acesso, e o terceiro nível de acesso é um nível completo de acesso. Neste documento, o terceiro nível de acesso remove as limitações de tráfego do primeiro nível de acesso e do segundo nível de acesso. Em determinadas modalidades, o primeiro nível de acesso limita pelo menos um de uma taxa de tráfego da unidade remota, um número de destinos acessíveis à unidade remota por meio da rede e um número de protocolos e portas de comunicação acessíveis à unidade de rede.

[00121] A Figura 9 representa um método 900 para acesso à rede usando pagamentos em blockchain, de acordo com modalidades da revelação. Em algumas modalidades, o método 900 é executado por um aparelho, tal como a função de autenticação 132, a BESF 136 e/ou o aparelho de autenticação 400. Em determinadas modalidades, o método 900 pode ser executado por um processador que executa código de programa, por exemplo, um microcontrolador, um microprocessador, uma CPU, uma GPU, uma unidade de processamento auxiliar, uma FPGA, ou similar.

[00122] O método 900 começa com a recepção 905, em uma função de autenticação e a partir de uma unidade remota, de uma mensagem de solicitação de autenticação que inclui um identificador de unidade remota. Neste documento, o identificador de unidade indica que a unidade remota está solicitando acesso à rede por meio de um pagamento em blockchain. Em uma modalidade, a mensagem de solicitação de autenticação é corporificada em uma mensagem de resposta de EAP.

[00123] O método 900 inclui gerar 910 um endereço para uma rede de blockchain indicada pelo identificador de unidade remota. Neste documento, o endereço gerado é para recepção do pagamento em blockchain. Em uma modalidade, um novo endereço para cada solicitação para acesso à rede é por meio de um pagamento em blockchain. Em determinadas modalidades a geração 910 de endereço inclui enviar uma mensagem de solicitação de pagamento à unidade remota, a referida mensagem de solicitação de pagamento incluindo o endereço gerado. Além disso, a mensagem de solicitação de pagamento pode incluir uma ou mais opções de valor, cada opção de valor incluindo um montante de acesso à rede e um correspondente valor de pagamento. Além disso, o endereço gerado pode ser trocado usando um método EAP.

[00124] O método 900 inclui a recepção 915 de uma mensagem de informação de pagamento em blockchain da unidade remota. Em algumas modalidades, a recepção 915 da mensagem de informação de pagamento em blockchain inclui validar a informação de pagamento em blockchain. Em determinadas modalidades, a mensagem de informação de pagamento em blockchain é trocada usando o método EAP. Em uma modalidade, a mensagem de informação de pagamento em blockchain inclui uma nova transação em blockchain. Neste documento, a nova transação em blockchain pode indicar um valor a ser pago correspondente a uma opção de valor selecionada.

[00125] Em outra modalidade, a recepção observando a mensagem de informação de pagamento faz referência a uma transação anterior em blockchain. Aqui, o servidor de autenticação determina se a transação anterior de referência foi feita pela unidade remota e se existe valor remanescente associado à transação anterior referenciada. Em resposta à transação anterior referenciada não ter qualquer valor remanescente ou em resposta à determinação de que a transação anterior referenciada não foi feita pela unidade remota, o servidor de autenticação pode reenviar a mensagem de solicitação de pagamento. A mensagem de solicitação reenviada pode incluir um código de erro que indica que a transação anterior referenciada não é válida.

[00126] O método 900 inclui fornecer 920 acesso à rede à unidade remota em resposta à validação com sucesso da informação de pagamento em blockchain recebida. Em algumas modalidades, fornecer 920 acesso à rede à unidade remota inclui gerar chave de sessão mestra para proteger tráfego da unidade remota, criptografar a chave de sessão mestra com uma chave pública da unidade remota, e enviar a chave de sessão mestra criptografada à unidade remota. Aqui, a chave pública pode estar contida na mensagem de informação de pagamento em blockchain. Quando a informação de pagamento em blockchain faz referência a uma transação anterior, a chave de sessão mestra pode ser uma nova chave de sessão mestra.

[00127] Em determinadas modalidades, fornecer 920 acesso à rede à unidade remota inclui fornecer diversos níveis de acesso à rede. Por exemplo, fornecer 920 acesso à rede pode incluir receber um primeiro nível de acesso em resposta à validação da mensagem de informação de pagamento em blockchain e antes da rede de comunicação móvel receber uma primeira mensagem de confirmação de transação. Em outra modalidade, fornecer 920 acesso à rede pode incluir receber um segundo nível de acesso em resposta à rede de comunicação móvel receber a primeira mensagem de confirmação de transação. Em uma outra modalidade, fornecer 920 acesso à rede pode incluir receber um terceiro nível de acesso em resposta à rede de comunicação móvel receber um número limite de mensagens de confirmação de transação. Nestas modalidades, o primeiro nível de acesso é um nível reduzido de acesso, o segundo nível de acesso é um nível intermediário de acesso, e o terceiro nível de acesso é um nível total de acesso. Neste documento, o terceiro nível de acesso remove as limitações de tráfego do primeiro nível de acesso e do segundo nível de acesso. Em determinadas modalidades, o primeiro nível de acesso limita pelo menos um de uma taxa de tráfego da unidade remota, um número de destinos acessíveis à unidade remota por meio da rede e um número de protocolos e portas de comunicação acessíveis à unidade remota.

[00128] As modalidades podem ser concretizadas em outras formas específicas. As modalidades descritas devem ser consideradas em todos os sentidos apenas como ilustrativas e não restritivas. O âmbito da invenção é, portanto, indicado pelas reivindicações apensas ao invés de pela descrição precedente. Todas as alterações que venham dentro do significado e faixa de equivalência das reivindicações devem ser abarcadas dentro de seu âmbito.

Claims (27)

REIVINDICAÇÕES

1. Aparelho caracterizado pelo fato de compreender: um transceptor que recebe uma mensagem de solicitação de autenticação para uma unidade remota, a mensagem de solicitação de autenticação incluindo um identificador de unidade remota, o identificador de unidade remota indicando que a unidade remota está solicitando acesso à rede por meio de um pagamento em blockchain; e um processador que gera um endereço para uma rede de blockchain indicada pelo identificador de unidade remota para receber o pagamento em blockchain, em que o transceptor recebe uma mensagem de informação de pagamento em blockchain da unidade remota e o processador fornece acesso à rede à unidade remota em resposta à validação com sucesso da informação de pagamento em blockchain recebida.

2. Aparelho, de acordo com a reivindicação 1, caracterizado pelo fato de que a mensagem de informação de pagamento em blockchain recebida inclui uma transação em blockchain.

3. Aparelho, de acordo com a reivindicação 2, caracterizado pelo fato de que o transceptor recebe uma pluralidade de mensagens de confirmação da rede de blockchain, cada mensagem de confirmação confirmando a transação em blockchain, em que fornecer acesso à rede à unidade remota compreende o processador: fornecer um primeiro nível de acesso em resposta à validação da transação em blockchain e antes da recepção de uma primeira mensagem de confirmação, fornecer um segundo nível de acesso em resposta à recepção da primeira mensagem de confirmação de transação, e fornecer um terceiro nível de acesso em resposta à recepção pelo transceptor de um número limite de mensagens de confirmação, em que o primeiro nível de acesso é um nível reduzido de acesso, o segundo nível de acesso é um nível intermediário de acesso, e o terceiro nível de acesso é um nível completo de acesso.

4. Aparelho, de acordo com a reivindicação 3, caracterizado pelo fato de que o primeiro nível de acesso e o segundo nível de acesso limitam pelo menos um de uma taxa de tráfego da unidade remota, um número de destinos acessíveis à unidade remota por meio da rede e um número de protocolos e portas de comunicação acessíveis à unidade remota, em que o terceiro nível de acesso remove as limitações de tráfego do primeiro nível de acesso e do segundo nível de acesso.

5. Aparelho, de acordo com a reivindicação 1, caracterizado pelo fato de que a mensagem de informação de pagamento em blockchain é recebida em resposta ao envio pelo transceptor de uma mensagem de solicitação de pagamento à unidade remota, a mensagem de solicitação de pagamento incluindo um endereço gerado e uma ou mais opções de valor, cada opção de valor indicando um montante de acesso à rede e um correspondente valor de pagamento.

6. Aparelho, de acordo com a reivindicação 5, caracterizado pelo fato de que a mensagem de informação de pagamento em blockchain recebida indica um valor a ser pago correspondente a uma opção selecionada da uma ou mais opções de valor.

7. Aparelho, de acordo com a reivindicação 1, caracterizado pelo fato de que a mensagem de informação de pagamento em blockchain recebida inclui uma chave pública da unidade remota, em que fornecer acesso à rede à unidade remota compreende o processador: gerar uma chave de sessão mestra para proteger tráfego da unidade remota; e criptografar a chave de sessão mestra com a chave pública da unidade remota, em que o transceptor envia a chave de sessão mestra criptografada à unidade remota.

8. Aparelho, de acordo com a reivindicação 1, caracterizado pelo fato de que a mensagem de informação de pagamento em blockchain recebida inclui uma referência a uma transação anterior, em que o processador valida a informação de pagamento recebida ao: determinar se a transação anterior referenciada foi feita pela unidade remota, e determinar se a transação anterior referenciada tem algum valor remanescente.

9. Aparelho, de acordo com a reivindicação 8, caracterizado pelo fato de que a transação anterior referenciada inclui uma chave pública da unidade remota, em que fornecer acesso à rede à unidade remota compreende o processador: gerar uma nova chave de sessão mestra para proteger tráfego da unidade remota; e criptografar a nova chave de sessão mestra com a chave pública da unidade remota, em que o transceptor envia a nova chave de sessão mestra criptografada à unidade remota.

10. Aparelho, de acordo com a reivindicação 8, caracterizado pelo fato de que o transceptor envia ainda uma segunda mensagem de solicitação de pagamento à unidade remota em resposta ao processador determinar que a transação anterior referenciada não foi feita pela unidade remota ou determinar que a transação anterior referenciada não tem qualquer valor remanescente.

11. Aparelho, de acordo com a reivindicação 1, caracterizado pelo fato de que as mensagens com a unidade remota são trocadas mediante utilização de um método de Protocolo de Autenticação Extensível (“EAP”).

12. Método caracterizado pelo fato de compreender: receber uma mensagem de solicitação de autenticação para uma unidade remota, a mensagem de solicitação de autenticação incluindo um identificador de unidade remota, o identificador de unidade remota indicando que a unidade remota está solicitando acesso à rede por meio de um pagamento em blockchain; gerar um endereço para uma rede de blockchain indicada pelo identificador de unidade remota para receber o pagamento em blockchain; receber uma mensagem de informação de pagamento em blockchain da unidade remota; e fornecer acesso à rede à unidade remota em resposta à validação com sucesso da informação de pagamento em blockchain recebida.

13. Método, de acordo com a reivindicação 12, caracterizado pelo fato de que a mensagem de informação de pagamento em blockchain recebida inclui uma transação em blockchain.

14. Método, de acordo com a reivindicação 13, caracterizado pelo fato de que compreende ainda receber uma pluralidade de mensagens de confirmação da rede de blockchain, cada mensagem de confirmação confirmando a transação em blockchain, em que fornecer acesso à rede à unidade remota compreende: fornecer um primeiro nível de acesso em resposta à validação da transação em blockchain e antes da recepção de uma primeira mensagem de confirmação, fornecer um segundo nível de acesso em resposta à recepção da primeira mensagem de confirmação de transação, e fornecer um terceiro nível de acesso em resposta à recepção pelo transceptor de um número limite de mensagens de confirmação, em que o primeiro nível de acesso é um nível reduzido de acesso, o segundo nível de acesso é um nível intermediário de acesso, e o terceiro nível de acesso é um nível completo de acesso.

15. Método, de acordo com a reivindicação 12, caracterizado pelo fato de que a mensagem de informação de pagamento em blockchain recebida inclui uma referência a uma transação anterior em blockchain, o método compreendendo validar a informação de pagamento em blockchain recebida ao: determinar se a transação anterior referenciada foi feita pela unidade remota, e determinar se a transação anterior referenciada tem algum valor remanescente.

16. Aparelho caracterizado pelo fato de compreender:

um transceptor que: transmite uma mensagem de resposta de autenticação a uma rede de comunicação móvel, a mensagem de resposta de autenticação incluindo um identificador de unidade remota, o identificador de unidade remota indicando que o aparelho está solicitando acesso à rede por meio de um pagamento em blockchain; recebe um endereço de uma rede de blockchain indicada pelo identificador de unidade remota para receber o pagamento em blockchain; transmite uma mensagem de informação de pagamento em blockchain associada a um pagamento em blockchain ao endereço recebido; e recebe acesso à rede em resposta à validação com sucesso da mensagem informação de pagamento em blockchain.

17. Aparelho, de acordo com a reivindicação 16, caracterizado pelo fato de que a mensagem de informação de pagamento em blockchain transmitida inclui uma transação em blockchain.

18. Aparelho, de acordo com a reivindicação 16, caracterizado pelo fato de que a mensagem de informação de pagamento em blockchain é transmitida em resposta à recepção de uma mensagem de solicitação de pagamento da rede de comunicação móvel, a mensagem de solicitação de pagamento incluindo o endereço na rede de blockchain e uma ou mais opções de valor, cada opção de valor indicando um montante de acesso à rede e um correspondente valor de pagamento.

19. Aparelho, de acordo com a reivindicação 18, caracterizado pelo fato de que a mensagem de informação de pagamento em blockchain transmitida indica um valor a ser pago correspondente a uma opção selecionada da uma ou mais opções de valor.

20. Aparelho, de acordo com a reivindicação 16, caracterizado pelo fato de que a mensagem de informação de pagamento em blockchain transmitida inclui uma chave pública do aparelho, em que o transceptor recebe uma chave de sessão mestra criptografada da rede de comunicação móvel, o aparelho compreendendo um processador que: descriptografa a chave de sessão mestra com uma chave privada que corresponde à chave pública incluída na mensagem de informação de pagamento em blockchain; e protege tráfego comunicado com a rede de comunicações móvel usando a chave de sessão mestra.

21. Aparelho, de acordo com a reivindicação 16, caracterizado pelo fato de que compreende ainda um processador que determina acessar a rede de comunicação móvel usando uma transação anterior não-expirada, em que o transceptor recebe ainda uma mensagem de solicitação de pagamento da rede de comunicação móvel, em que a transmissão da mensagem de informação de pagamento em blockchain compreende o transceptor transmitir uma referência à transação anterior em uma resposta à mensagem de solicitação de pagamento.

22. Aparelho, de acordo com a reivindicação 21, caracterizado pelo fato de que a transação anterior referenciada inclui uma chave pública da unidade remota, em que o transceptor recebe uma nova chave de sessão mestra criptografada da rede de comunicação móvel, o aparelho compreendendo um processador que:

descriptografa a nova chave de sessão mestra com uma chave privada que corresponde à chave pública incluída na transação anterior; e protege tráfego comunicado com a rede de comunicações móvel usando a nova chave de sessão mestra.

23. Aparelho, de acordo com a reivindicação 16, caracterizado pelo fato de que as mensagens com a unidade remota são trocadas mediante utilização de um método de Protocolo de Autenticação Extensível (“EAP”).

24. Método caracterizado pelo fato de compreender: transmitir, por uma unidade remota, uma mensagem de resposta de autenticação a uma rede de comunicação móvel, a mensagem de resposta de autenticação incluindo um identificador de unidade remota, o identificador de unidade remota indicando que a unidade remota está solicitando acesso à rede por meio de um pagamento em blockchain; receber um endereço para uma rede de blockchain indicada pelo identificador de unidade remota; transmitir uma mensagem de informação de pagamento em blockchain associada a um pagamento em blockchain ao endereço recebido; e receber acesso à rede em resposta à validação com sucesso da mensagem informação de pagamento em blockchain.

25. Método, de acordo com a reivindicação 24, caracterizado pelo fato de que a mensagem de informação de pagamento em blockchain é transmitida em resposta à recepção de uma mensagem de solicitação de pagamento da rede de comunicação móvel, a mensagem de solicitação de pagamento incluindo o endereço para a rede de blockchain e uma ou mais opções de valor, cada opção de valor indicando um montante de acesso à rede e um correspondente valor de pagamento.

26. Método, de acordo com a reivindicação 24, caracterizado pelo fato de que compreende ainda: receber uma mensagem de solicitação de pagamento da rede de comunicação móvel; e determinar acessar a rede de comunicação móvel usando uma transação anterior, em que a transmissão da mensagem de informação de pagamento em blockchain compreende transmitir uma referência à transação anterior em uma resposta à mensagem de solicitação de pagamento.

27. Método, de acordo com a reivindicação 24, caracterizado pelo fato de que as mensagens com a rede de comunicação móvel são trocadas mediante utilização de um método de Protocolo de Autenticação Extensível (“EAP”).