BR112019015066A2 - Sistema de conexões universais de bchain todos/tudo/toda parte - Google Patents

Sistema de conexões universais de bchain todos/tudo/toda parte

Info

Publication number
BR112019015066A2
BR112019015066A2 BR112019015066-8A BR112019015066A BR112019015066A2 BR 112019015066 A2 BR112019015066 A2 BR 112019015066A2 BR 112019015066 A BR112019015066 A BR 112019015066A BR 112019015066 A2 BR112019015066 A2 BR 112019015066A2
Authority
BR
Brazil
Prior art keywords
node
appchain
lom
petition
ubec
Prior art date
Application number
BR112019015066-8A
Other languages
English (en)
Inventor
Kamran Hasan Syed
Original Assignee
Kamran Hasan Syed
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kamran Hasan Syed filed Critical Kamran Hasan Syed
Publication of BR112019015066A2 publication Critical patent/BR112019015066A2/pt

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0655Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/01Social networking
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/177Initialisation or configuration control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Accounting & Taxation (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Human Resources & Organizations (AREA)
  • Tourism & Hospitality (AREA)
  • Economics (AREA)
  • Software Systems (AREA)
  • Finance (AREA)
  • Biomedical Technology (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Instruments For Viewing The Inside Of Hollow Bodies (AREA)
  • Details Of Aerials (AREA)
  • Lighting Device Outwards From Vehicle And Optical Signal (AREA)
  • Developing Agents For Electrophotography (AREA)
  • Prostheses (AREA)
  • Liquid Crystal Substances (AREA)

Description

SISTEMA DE CONEXÕES UNIVERSAIS DE BCHAIN TODOS/TUDO/TODA PARTE
REFERÊNCIA CRUZADA A APLICAÇÕES RELACIONADAS
[01] Este pedido reivindica prioridade no Pedido Provisório n° 62449313 apresentado em 23 de janeiro de 2017, intitulado Conexões Universais de Tudo em BCHAIN (UBEC); Pedido Provisório n° 62464 56, apresentado em 27 de fevereiro de 2017, intitulado Conexões Universais de Tudo em BCHAIN (UBEC); Pedido Provisório n° 62468202, depositado em 7 de março de 2017, intitulado Conexões Universais de Tudo em BCHAIN (UBEC); Pedido Provisório n° 62489309, apresentado em 24 de abril de 2017, intitulado Conexões Universais totalmente BCHAIN (UBEC); Pedido Provisório No. 62504057, apresentado em 1 de maio de 2017, intitulado Conexões Universais de Tudo em BCHAIN de Conteúdo Metafísico Neuroeconómico (UBEC NMC); Pedido Provisório n° 62530197, depositado em 8 de julho de 2017, intitulado Conteúdo Metafísico Neuroeconómico (NMC); e Pedido Provisório n° 62549714, apresentado em 24 de agosto de 2017, intitulado Autoprogramação de Auto Inovação (SPSI); cujas divulgações são incorporadas por referência como se estabelecidas aqui.
[02] Os pedidos relacionados incluem o Pedido de Patente No. 15145800 depositado em 04 de maio de 2016, intitulado MÉTODO E DISPOSITIVO PARA GERENCIAR SEGURANÇA EM UMA REDE DE COMPUTADOR; Pedido de Patente No. 15264744 depositado em 14 de setembro de 2016, intitulado Sistema Perpétuo de Dados; e Pedido de Patente n° 15413666 depositado em 24 de janeiro de 2017, intitulado SEGURANÇA DO COMPUTADOR COM BASE NA INTELIGÊNCIA ARTIFICIAL, cujas divulgações são incorporadas por referência,
Petição 870200056145, de 06/05/2020, pág. 4/1737
2/754 como aqui estabelecido.
CAMPO DA INVENÇÃO
[03] A invenção é intitulada BCHAIN Conexões universais/ubiquas Tudo/Tudo o tempo/Em todo lugar (E3A) (UBEC). O UBEC consegue uma colaboração eficiente por meio de instâncias sincronizadas, mas separadas, de critérios algorítmicos.
ANTECEDENTES DA INVENÇÃO
[04] O domínio digital que usa dispositivos inteligentes (por exemplo, smartphones, PC, dispositivos loT) requer uma plataforma para se conectar. Essa plataforma deve permitir que dispositivos inteligentes realizem atividades digitais com segurança e eficiência. Blockchain é uma tecnologia adequada para construir essa plataforma. A inteligência artificial é um campo emergente para melhorar a plataforma e as atividades digitais realizadas através da plataforma.
RESUMO DA INVENÇÃO
[05] A presente invenção fornece um sistema de coconexões universais BCHAIN Tudo/Tudo o tempo/Em todo lugar (UBEC) que compreende: a) aplicações UBEC operando de acordo com o Protocolo BCHAIN; b) rede BCHAIN compreendendo uma pluralidade de nós BCHAIN, que operam software de acordo com o Protocolo BCHAIN; c) Appchains, que incluem programas de armazenamento, serviço e cálculo de dados que operam diretamente na rede BCHAIN; d) Inteligência de Governança Independente Legislada da UBEC (LUIGI), que compreende um mecanismo de controle artificialmente inteligente em uma Plataforma UBEC, onde no paradigma de interação do Nó existente na Rede BCHAIN, a Metachain é uma Customchain que contém metadados que todos os nós na conexão de
Petição 870200056145, de 06/05/2020, pág. 5/1737
3/754 rede BCHAIN para referências essenciais e primárias, onde a Metachain rastreia informações fundamentais contendo locais de nó/setor, tendências de demanda de conteúdo e roteamento de salto para simplificar a configuração da infraestrutura, em onde cada nó BCHAIN é obrigado a participar da leitura da Metachain, onde as Appchains são Customchains que agem como contratos inteligentes avançados para fornecer informações através da infraestrutura que foi organizada pela Metachain, onde as Appchains podem ser referenciadas entre si para entrada/saida em ecossistemas de Customchain aninhados e paralelos, em que os Microchains são Appchains que são automaticamente convertidas em uma Customchain que não depende ou se conecta à Metachain.
[06] No protocolo BCHAIN, o Enfileiramento de Informações (QIB) transmite Requerimentos de Solicitação de Conteúdo (CCR) ou Conformidade de Solicitação de Conteúdo (CCF) que devem ser transmitidas a outros nós, onde os pacotes de informações da CCR e os CCF são enviados à Plataforma de Comunicação (CG), que é a camada de interface exclusiva entre o Protocolo BCHAIN (BP) e a Interface de Hardware do Nó, onde o CG encaminha as informações sobre o Levantamento Estatístico de Nós Circundantes (NSS), no qual o NSS rastreia o comportamento do nó circundante, causando o cálculo da formação de quatro índices: índice de escape do nó, índice de saturação do nó, índice de consistência do nó, índice de consistência do nó, índice de sobreposição do nó; em que o índice de escape do nó rastreia a probabilidade de um vizinho escapar da vizinhança de um nó perceptive, em que o índice de saturação do nó rastreia o número de nós no intervalo de um nó Perceptive de detecção, em que o
Petição 870200056145, de 06/05/2020, pág. 6/1737
4/754 indice de consistência do nó rastreia a qualidade dos serviços do nó, conforme interpretado por um nó receptor, em que o índice de Sobreposição de nós rastreia a quantidade de sobreposição de nós entre si, interpretado por um nó de percepção, em que o nó de percepção é aquele que executa a instância do NSS.
[07] As quatro variáveis resultantes são enviadas ao Sistema de Corroboração da Estratégia (SCS), que aplica o consenso do Protocolo Entre os Nós, onde a Adaptação Dinâmica da Estratégia (DSA) recebe as variáveis do NSS para alterar dinamicamente a Implantação do Estratégia baseada na composição dos critérios da estratégia calculada, em que a composição dos critérios da estratégia contém uma ampla gama de variáveis que informam os elementos essenciais, importantes e complementares do protocolo BCHAIN como operar, onde as Appchains Registradas contêm senhas criptográficas de várias Appchains, onde quando uma atualização de uma Appchain é anunciada nas atualizações da Appchain da Metachain, o dispositivo baixa as atualizações mais recentes da Appchain, que manifestará como uma prova criptográfica de propriedade que se origina das chaves criptográficas armazenadas nos aplicativos registrados.
[08] LUIGI recebe um nivel codificado permanente e irrevogável de privilégio administrativo e executivo da
Plataforma UBEC; LUIGI é exclusivamente programado e mantido pelo SPSI; LUIGI é hospedado exclusivamente na rede BCHAIN distribuída; onde a Programação Automática Inovação Automática (SPSI) é uma Appchain que se programa automaticamente e outras Appchains na plataforma UBEC que recebem uma designação oficial.
[09] A Mineração Objetiva Lexical (LOM) tenta se
Petição 870200056145, de 06/05/2020, pág. 7/1737
5/754 aproximar o máximo possível da resposta objetiva a uma ampla gama de perguntas e/ou afirmações . A LOM se envolve com o usuário UBEC para permitir que concedam ou aprimorem seus argumentos contra a posição da LOM. 0 Mecanismo de Investigação Automatizado (ARM) tenta constantemente fornecer à CKR novas idéias para melhorar a estimativa geral da LOM e os recursos de tomada de decisão.
[10] A Appchain de contêineres da LOM abriga os módulos principais no formato de uma Appchain, onde a Appchain tem seus segmentos de execução extraídos por meio do ESC para gerar o fluxo de execução, que se manifesta como os módulos principais que operam o LOM, onde o Raciocínio da Consulta Inicial (IQR) recebe a pergunta/declaração inicial fornecida pelo usuário da UBEC e, posteriormente, aproveita a Retenção Central de Conhecimento (CKR) para decifrar os detalhes ausentes que são cruciais para entender e responder à pergunta/afirmação, na qual a Construção de Asserções (CA) recebe uma proposta na forma de afirmação ou pergunta e fornece a saída dos conceitos relacionados à referida proposição, onde o Mapeamento Hierárquico (HM) mapeia conceitos associados para encontrar corroboração ou conflito na consistência da pergunta/afirmação e calcule os benefícios e riscos de ter um certo posição sobre o assunto, em que o Apelo Racional (RA) critica as alegações, autocríticas ou críticas das respostas humanas por meio do uso da tecnologia CTMP, na qual a Validação de Conhecimento (KV) recebe conhecimento altamente confiável e pré-crítico que deve ser logicamente separado para a capacidade de consultar e assimilar na CKR, na qual com a Análise de Referência Cruzada (CRA), as informações recebidas são comparadas e construídas levando em
Petição 870200056145, de 06/05/2020, pág. 8/1737
6/754 consideração o conhecimento preexistente da CKR, no qual a sequência de execução se manifesta na realidade uma vez executado pelo ESE, no qual os segmentos de dados chegam da lógica do sistema UBEC à Appchain do contêiner LOM, no qual o ESE processa os segmentos de dados juntamente com a lógica central do LOM definido pela sequência de execução e listado como Manifestação Modular do Fluxo de Execução, onde os Segmentos de Dados de Entrada se manifestam como Entrada Pergunta/Afirmação LOM, onde a execução do ESE emite Segmentos de Dados que são retornados à Lógica de todo o Sistema UBEC como resposta formal da LOM à Pergunta/Afirmação de Entrada da LOM.
[11] 0 Perfil de Inteligência Pessoal (PIP) armazena as informações pessoais do usuário UBEC por meio de vários pontos de extremidade e front-ends em potencial.
[12] 0 mecanismo de implantação automatizada é adaptado para implantar a Plataforma UBEC como um Aplicativo para dispositivos de hardware, onde o SPSI envia atualizações de software, firmware e hardware para o Núcleo Lógico Híbrido da UBEC/BCHAIN, no qual a Plataforma UBEC possui sua própria Base Código Diferente, que colabora com a Base de Código do Protocolo BCHAIN, na qual ambas as bases de código são conectadas diretamente ao plug-in de interface modular, o que garante a execução compatível de bases de código em diferentes configurações de hardware e nós do sistema operacional BCHAIN, em que a lógica do núcleo híbrido é posteriormente implementada por meio de uma das diferentes rotinas de implementação, que é selecionada de acordo com o hardware de correlação e a composição do sistema operacional do nó BCHAIN selecionado.
Petição 870200056145, de 06/05/2020, pág. 9/1737
7/754
[13] 0 Gateway UBEC recebe o tráfego de informações que ocorre do UBEC como a Appchain, no qual, ao analisar as informações, as informações são retornadas ao UBEC como uma Appchain através do Retorno Abrangente do UBEC para continuar seu seguir adiante e chegar ao destino pretendido na Plataforma UBEC, na qual as informações recebidas do Gateway UBEC são encaminhadas à Delegação de Atividades LUIGI (LTD), que determina se LOM, LIZARD ou ambos devem processar os dados, em que chama a Ação Corretiva LUIGI (LCA) para gerenciar adequadamente os eventos e transações de acesso a informações que estão ocorrendo na plataforma UBEC.
[14] Ao apresentar um novo aplicativo ou uma atualização para um aplicativo existente, a LUIGI usa a tecnologia LIZARD para identificar padrões de jurisdição corretos, para que você entender se um aplicativo é necessário no UBEC ou não, onde o LUIGI bloqueia ou aprova o envio de a solicitação, que é uma execução manifestada na Ação Corretiva LUIGI (LCA).
[15] A Interação do Nó do Usuário (UNI) usa dados biométricos diretos para autenticação e não faz referência a nenhum nome de usuário ou contêiner de conta, onde nós, dados e serviços estão diretamente vinculados aos dados biométricos do usuário, em os dados biométricos são transferidos para a Categorização de Banda Biométrica (BBC), que cria uma versão arredondada dos dados que elimina variações na medição de dados biométricos devido a margens de erro no equipamento de medição de dados biométricos, em que, para cada entrada de dados biométricos na BBC, um Token de Autorização de Banda (BAT)
Petição 870200056145, de 06/05/2020, pág. 10/1737
8/754
Correspondente é produzido como saída, em que é feita uma comparação entre os BAT recém-gerados e os tokens de autenticação armazenados na Appchain da associação de banda, na qual a quantidade de dados biométricos fornecidos é medida e verificada como suficiente para o processo de autenticação.
[16] Dentro da BBC, é criada a separação granular da entrada biométrica genérica recebida, onde a separação do granulador representa a entrada biométrica genérica em um formato que quantifica as faixas de magnitude encontradas na entrada, onde são montadas diferentes composições de dados Biométricos no mesmo formato que destaca pontos de dados de alta e baixa magnitude, nos quais o escopo dos pontos de dados é expandido para criar um formato que afirma ser maior que o erro de margem esperado, no qual as categorias de banda produzido no formato são armazenados como um Token de Autorização de Banda (BAT).
[17] 0 ecossistema de Customchains é uma interação complexa de Appchains, Microchains, juntamente com uma Metachain única para produzir um sistema de retenção e serviço de dados dinamicamente adaptável, juntamente com a execução do programa/rotina que compõe a rede BCHAIN em que a loja de aplicativos UBEC existe no ecossistema Customchain para hospedar, listar e atender aplicativos UBEC, em que o dispositivo habilitado para UBEC seleciona e baixa o aplicativo A da UBEC na loja de aplicativos UBEC, em onde os segmentos de execução são coletados da Appchain AO que mapeia para o aplicativo UBEC A, onde os segmentos de execução coletados são enviados para a Coleta de Fluxo de Execução (ESC) que os reúne no Fluxo de Execução AO, em que a montagem realizada pela ESC considera a
Petição 870200056145, de 06/05/2020, pág. 11/1737
9/754 ordem correta na qual os segmentos de execução devem ser alinhados, onde a execução dos segmentos de execução do Fluxo de Execução AO ocorre no Módulo de Execução de Sequência (ESE), onde, paralelamente ao processamento e montagem do Fluxo de Execução AO, está o processo e a montagem dos Fluxos de Dados AO e Z3, que é realizado na Estagio, que coleta os segmentos de dados da Appchain AO e os envia para classificação no Organizador de Fluxo de Dados (DSS) , onde o Fluxo de Dados AO e ESE faz referência ao Z3 para executar corretamente os comandos listados no Fluxo de Execução AO.
[18] Vários Ecossistemas de Customchain compõem a rede BCHAIN, onde o aplicativo UBEC A e o aplicativo UBEC B compõem seu próprio ecossistema de Customchain, onde ou cada ecossistema de Customchain que se correlaciona com um aplicativo, existe uma Appchain de Contêiner, em que a Appchain de Contêiner se refere aos Fluxos de Execução e fluxos de dados que são armazenados nos aplicativos complementares.
[19] Os ecossistemas de Customchains contêm Appchains separadas que não pertencem ou representam um aplicativo UBEC especifico, onde fluxos de execução ou fluxos de dados separados podem ser extraídos de Appchains separadas.
[20] O usuário UBEC insere Criatividade e Decisão na Interface do Gerente de Logística (LMI) , em que a LMI gera a camada de logística, que é um formato de informação genérico que define a logística do aplicativo projetada pelo usuário da UBEC via LMI, em que a camada de logística é enviada como entrada para a Customchain Construtor de Ecossistemas (CEB), em que o CEB constrói automaticamente o Aplicativo Logístico, conforme
Petição 870200056145, de 06/05/2020, pág. 12/1737
10/754 percebido pelo Usuário UBEC, usando os blocos de construção fundamentais que consistem em um Ecossistema da Customchain, em que no fluxo lógico da Customchain do Construtor de Ecossistemas, inicialmente o estado atual da Appchain é interpretada para interpretar as posições relevantes em que existem segmentos de dados e segmentos de execução, em que os segmentos de execução são montados em um fluxo de execução, na ordem correta para garantir a execução correta do programa pelo ESE, em que os segmentos de dados são coletados e montados em um fluxo de dados via processamento DSS, em que o Processamento Lógico Interno do CEB Gera Execução + Suplementos de Dados, que são armazenados no bloco mais novo da Appchain, em que novos Suplementos de Execução e Dados para a Appchain começam a ser processados na Rede BCHAIN através do Anúncio de Novo Conteúdo (NCA), em que o conteúdo é enviado ao Armazenamento de Dados Mempool (MDS) dos mineradores, onde é eventualmente extraído no próximo bloco da Appchain 602 pelo Módulo de Interface de Customchain(CIM), em que o conteúdo do bloco recém-extraído é cortado em partes do cache e transferido para nós de armazenamento em cache via Fornecimento de Nós de Mineração Semeadura de Cache, em que as partes do cache migram gradual e automaticamente para atender a áreas otimizadas, o que garante o melhor tempo de atividade e velocidade de download possível para os nós que solicitam os dados, em que os nós reivindicam o conteúdo dos nós de cache por meio do Gerador de Reivindicação de Conteúdo, no qual os nós executados após baixarse são executados em o Fluxo de Execução via ESE, o que leva à manifestação do aplicativo pretendido.
[21] Uma Unidade de Watt é uma moeda criptográfica
Petição 870200056145, de 06/05/2020, pág. 13/1737
11/754 atrelada algoritmicamente ao valor da eletricidade, em que as Unidades de Watt são criadas e destruídas diretamente pela LUIGI, à medida que a liquidez entra e sai da Economia UBEC, em que a Pesquisa de Preço de Energia Distribuída (DEPS) pesquisa os Nós BCHAIN que podem autenticamente relatar o preço atual da eletricidade em moeda fiduciária, em que a Bolsa de Moeda de Terceiros (TPCE) atua como a camada logística para gerenciar a compra e venda de moeda fiduciária que permite que a liquidez flua para dentro e para fora da Economia de Watt da Metachain, em que na TPCE, Os usuários UBEC que procuram vender e comprar Unidades de Watt são essencialmente emparelhados em uma bolsa de valores, em que o valor da moeda fiduciária de uma Unidade de Watt está atrelado ao valor relatado pelo DEPS, em que um Usuário UBEC que compra uma quantidade de Unidades de Watt, Relatório de transação verificado que detalha o valor comprado é enviado à LUIGI, em que após a aprovação da transação pela LUIGI, um usuário que compra unidades de Watt leva a Criação de Unidade de Watt na Interface Econômica LUIGI (LEI), em que, quando um usuário UBEC vende uma quantidade de unidades de watt, um Relatório de transação verificado que detalha a quantidade comprada é enviado à LUIGI, em que após a aprovação da transação pela LUGI, um usuário compra unidades de watt leva à destruição de unidades de watts na interface econômica LUIGI, em que as funções do LEI exigem conhecimento e acesso à Alocação de Fundos Privados do Usuário (UPFA), em que a alocação de fundos na UPFA é inteligentemente distribuída entre os nós de acordo com o tipo, atenuando o risco de nó sendo danificado/roubado.
[22] 0 Usuário UBEC pode selecionar Personalidades
Petição 870200056145, de 06/05/2020, pág. 14/1737
12/754
Econômicas, em que Personalidade Econômica (Equalizador) é quando os recursos do nó são consumidos para corresponder apenas ao que o Usuário UBEC consome, em que Personalidade B (Lucro) é quando o nó consome tantos recursos locais quanto possível, desde que a margem de lucro é maior que X, em que a Personalidade C (Consumidor) é quando o Usuário UBEC paga pelas unidades de trabalho por meio de uma moeda negociada para que o conteúdo possa ser consumido enquanto gasta menos recursos do nó, em que Personalidade D (Altruísta) quando os recursos do nó são gastos como tanto quanto possível e sem nenhuma restrição de esperar algo em troca, em que a Imposição de Trabalho Economicamente Considerado (ECWI) faz referência à economia de watts da Metachain para determinar o excedente/déficit atual desse nó em relação ao crédito do trabalho realizado, em que o excedente de trabalho atual/déficit é encaminhado ao ECWI, que considera a Personalidade Econômica Selecionada e o Excedente/Déficit para avaliar se mais trabalho deve ser realizado no momento.
[23] Se os critérios definidos na Implantação da Estratégia, conhecidos como Critérios de Propagação de Salto Paralelo, foram atendidos, o Nó chama a Lógica de Salto Paralelo (PHL), leva os nós específicos a iniciarem mais Caminhos de Salto Paralelo do que receberam, o que leva a uma redundância em Caminhos de Salto Relacionados ao CCR ou CCF itinerante, em que Caminhos de Salto Paralelo redundantes atenuam o risco apresentado pelo caos, aumentando as chances de que pelo menos a quantidade mínima de caminhos necessários atinja o Alvo Final sem uma interrupção significativa do caos, em que o Alvo Final pode receber uma confirmação originada de um consenso
Petição 870200056145, de 06/05/2020, pág. 15/1737
13/754 descentralizado devido ao fato de os Caminhos de Salto Paralelo redundantes serem iniciados pelo PHL, em que para que um pacote CCR ou CCF seja aceito em seu Nó de destino, deve chegar de pelo menos um número predeterminado de Caminhos de Salto Paralelo separados, em que a Redução de Caminho de salto Excessivamente Paralelo (OPHPR) detecta Caminhos de Salto Paralelo que se tornaram uma carga ineficiente no sistema em e deve cessar de continuar sua jornada, em que a quantidade de Caminhos de Salto Paralelo redundantes gerados depende do tamanho da taxa da unidade de watts que foi pré-autorizada para o EAT (CCR ou CCF), em que a funcionalidade de alavancar o movimento físico dos Nós é processado pelos módulos da Camada de Migração de Dados Físicos (PDML) e Uso de Migração de Dados Físicos (PDMU) , em que a funcionalidade de Migração Física permite uma taxa de transferência geral aumentada no sistema, à medida que os movimentos físicos dos Nós são feitos para funcionar a favor da eficiência da rede e não contra ela.
[24] Os setores são agrupamentos de nós BCHAIN que facilitam logicamente a orientação e o roteamento de viagens na rede BCHAIN, em que a qualquer momento qualquer nó BCHAIN fica sob a jurisdição de exatamente dois setores, em que as definições dos setores são derivadas do hash de escopo duplo gerado pelo Consentimento do Escopo de Tráfego (TSC), em que a Descoberta Otimizada de Rotas do Setor (OSRD) interpreta o estado geográfico da Rede BCHAIN conforme ao definido na Metachain e produz Rotas Setoriais Otimizadas que são efetivamente estradas de informação, nas quais as informações são submetidas ao Roteamento Setorial Otimizado da Metachain, Informações estatísticas, incluindo a
Petição 870200056145, de 06/05/2020, pág. 16/1737
14/754 força do caminho (eficácia) e a saturação do caminho (demanda/uso) estão incluídas no Roteamento setorial otimizado da Metachain.
[25] Um nó BCHAIN usa o CCG para gerar o CCR que é finalmente enviado ao nó de destino final, em que o CCR é equipado com o Caminho de Salto Proposto da Linha de Base (PBHP) e o Conjunto de Variáveis de Trilha (TVS), em que o PBHP contém informações de roteamento relacionadas à sequência proposta de nós para, eventualmente, alcançar o Objetivo Final, em que o TVS contém informações dinâmicas relacionadas ao gerenciamento de logística da entrega da CCR, em que os elementos do gerenciamento de logística incluem o Token de Autorização Econômica (EAT) e uma instância de Implementação da Estratégia que é referenciada em todo viajam dentro de um Setor Específico, em que o CCR viaja pelos Nós existentes nos Nós Intermediários, em que após o CCR chegar com êxito ao Nó de Destino Final, o Nó executa a Entrega de Reivindicação de Conteúdo (CCD) para tentar atender à solicitação de conteúdo feita pelo Nó solicitante, em que um pacote de CCF é enviado em retorno, que viaja através do Nó Intermediário até o Nó solicitante, em que o CCF é processado pela Renderização de Reivindicação de Conteúdo (CCR), em que o CCR utiliza o Cache de Conteúdo de Inicialização em Camadas (SRCC) para reter partes do conteúdo até que toda a unidade de conteúdo possa ser totalmente renderizada.
[26] 0 mecanismo de conteúdo de transmissão ao vivo não utiliza (CCR) , em que as necessidades de conteúdo são preenchidas por meio de CCFs aos nós que solicitam esse conteúdo de acordo com as implicações de sua descrição e jurisdição, em
Petição 870200056145, de 06/05/2020, pág. 17/1737
15/754 que o módulo Envio Jurisdicionalmente Implícito de CCF (JICS) opera em um Nó da BCHAIN que percebe a necessidade jurisdicional de entrega de conteúdo de outro Nó, em que um CCF é enviado por meio de Nós Intermediários sem um CCR acompanhante, em que o CCF é recebido e validado no Nó Alvo Final pela Recepção CCF Jurisdicionalmente Aceita (JACR) e posteriormente prestado pela CCR.
[27] 0 Sistema de Corroboração da Estratégia (SCS) usa o módulo Consenso de Escopo de Tráfego (TSC) para derivar uma coleção de Hash de Escopo Duplo, em que a composição do Hash de Escopo Duplo é finalmente derivada das quatro variáveis produzidas pelo Nó de Levantamento Estatístico (NSS); Nó de índice de Fuga, Nó do índice de Saturação, Nó de índice de Consistência e Nós do índice de Sobreposição, em que as variáveis são derivadas pelo NSS do Comportamento Externo do Tráfego, em que os anúncios de Hash são trocados entre diferentes Áreas de Tráfego conhecidas como setores, em que cada nó percebe dois Hashes devido ao algoritmo que é executado no Consenso do Escopo de Tráfego (TSC), em que a Lógica de Reconhecimento de Hash Duplo exige que pelo menos um dos dois Hashes corresponda a dois nós para poderem se comunicar, devido ao arredondamento para baixo/para arriba da lógica empregada no TSC, um nó pode atravessar diferentes ambientes de rede, mantendo consenso com outros nós, porque apenas um Hash pode mudar por vez, portanto, o nó deve ter uma sobreposição com pelo menos um Hash com nós circundantes sob o protocolo BCHAIN.
[28] A Pesquisa Estatística de Nós (NSS) reúne informações sobre o comportamento dos Nós vizinhos para calcular
Petição 870200056145, de 06/05/2020, pág. 18/1737
16/754 quatro índices principais, que por sua vez informa os módulos que operam as funções principais do Protocolo BCHAIN sobre o estado da Rede BCHAIN em relação à atividade e comportamento dos Nós, em que o módulo Lógica de Interação (NIL) opera como um subconjunto do Gateway de Comunicação (CG) e interage com a interface de hardware via o Sistema Operacional e pontos de extremidade da API, em que todos os pings relacionados aos Nós nas imediações do nó que está executando a instância do NSS são encaminhados ao Processamento de Ping do Nó (NPP) , em que o Banco de Dados de Atividade do Nó (NAD) é um banco de dados local que retém dados brutos em relação à atividade do Nó Ping, em que o NAD é a principal fonte de informações para a NPP executar Consultas Operacionais que levam ao Cálculo do índice da coleção Variáveis de índice do Nó, em que os Registros do Nó Ping são recebidos inicialmente no Tráfego de Entrada, em que Cada Registro do Nó Ping contém a identidade referente ao Nó Relevante, bem como um Registro de Data e Hora de Expiração, em que o Registro de Data e Hora faz com que o NSS relate informações atualizadas que refletem o estado atual da vizinhança local da Rede BCHAIN, em que as consultas operacionais processam os registros de ping do nó em lotes enquanto consideram o registro de data e hora de expiração, em que os registros são finalmente calculados de acordo com o critérios das quatro variáveis de índice do nó no cálculo do índice.
[29] Em relação ao Sistema de Corroboração da Estratégia (SCS), o Consumo do Escopo de Tráfego (TSC) produz um conjunto de Hash de Escopo Duplo referenciando variáveis NSS e definições estáticas da Política de Código Codificado Estático
Petição 870200056145, de 06/05/2020, pág. 19/1737
17/754 (SHP), em que o SCS invoca a Derivação de Identidade de Setor (SID) para usar os Hashes de Escopo Duplo atuar como base para definir as identificações atuais do setor, em que cada nó em um determinado momento existe sob a jurisdição de exatamente dois setores, cada um definido pelo Hash 1 e Hash 2, em que com a Corroboração Hash dos Hashes anunciados pelos vizinhos, são verificados em relação aos Hashes Produzidos Localmente, nos quais, se nenhum dos hashes corresponder, o nó vizinho será adicionado à lista de bloqueios de nós, em que os nós de percepção de tráfego do nó especifico reconhecidos como legítimos devido ao anúncio de Hash correspondente podem informar outros nós sobre os nós que eles suspeitem serem não autorizados e operando além dos limites do protocolo BCHAIN definidos na Política de Código Fixo Estático (SHP).
[30] O TSC chama o NVP para receber variáveis de Pesquisa Estatística de Nó (NSS) e produzir uma Média Composta de Variáveis do NSS (NVCI), em que com os nós do NVP dos mesmos setores anunciam sua percepção das variáveis do NSS entre si para criar consenso sobre as características do setor, as variáveis locais e remotas do NSS são agrupadas para criar uma média composta conhecida como NVCI, em que a NVCI é usada para manter um consenso sobre o escopo e a definição desse setor e, portanto, onde estão os limites físicos, em que a versão agrupada do Nó de índice de Fuga é arredondado para baixo para o múltiplo X mais próximo, em que a versão agrupada do Nó de índice de Saturação é arredondada para baixo para o múltiplo X mais próximo, em que a versão agrupada do Nó de índice de Consistência é arredondada para baixo para o múltiplo X mais próximo, em que a versão
Petição 870200056145, de 06/05/2020, pág. 20/1737
18/754 agrupada do Nó de índice Sobreposição é arredondado para baixo para o múltiplo X mais próximo no estágio, em que todas as variáveis assim produzidas no estágio são mescladas o uma única variável.
[31] Os Fatores de Desempenho são produzidos pelo Conjunto de Variáveis do NSS (NVP) e também são arredondados para o múltiplo X mais próximo, em que os fatores de desempenho são medidores de desempenho relativos ao tráfego da rede no setor relevante, em que o valor X usado no estágio de arredondamento vem de o Múltiplo de Arredondamento de Consenso de Tráfego da Implantação da Estratégia, em que a Implantação da Estratégia é extraída de um Conjunto de Variáveis de Trilha (TVS) que é processado pelo Setor de Processamento de Eventos de Travessia (SCEP), em que se espera que o Múltiplo seja diferente dentro de cada Setor, o mesmo para todos os Nós no mesmo setor em que os resultados da fusão se tornam a base do Hash 1 do Hash de escopo duplo, em que, para a base do Hash 2, a mesma NVCI é referenciada no processo de arredondamento, exceto que o processo é arredondado para cima a partir do mesmo múltiplo X retirado do Arredondamento de Consenso Múltiplo, em que os mesmos fatores de desempenho do NVP são processados embora arredondado para cima.
[32] A Adaptação Dinâmica da Estratégia (DSA) atua como a estrutura para a criação de variáveis dinâmicas que controlam os fatores de processamento na Rede BCHAIN, em que as variáveis são empacotadas e transferidas por meio da Implantação da Estratégia, que é realizada dentro de um Conjunto de Variável sde Trilha (TVS), em que o DSA mantém e ajusta variáveis que controlam as operações de rede de acordo com o estado da rede
Petição 870200056145, de 06/05/2020, pág. 21/1737
19/754 física, conforme relatado pelas variáveis do NSS por meio da Interpretação de Caos de Campo (FCI), em que a FCI interpreta o nível geral de caos de disponibilidade de nós em toda a rede BCHAIN, em que a Implantação da Estratégia é um conjunto empacotado de critérios que definem valores operacionais nos módulos do Protocolo BCHAIN, em que o algoritmo de seleção de estratégia otimizada (OSSA) seleciona a estratégia mais adequada e mais ideal que opera melhor nas condições ambientais declaradas pelo NSS, em que a estratégia preferida atual (SCM) é usada como entrada para o Módulo de Criação de Estratégia (SCM) para ajustar a estratégia com a experimentação, em que o SCM usa o Módulo de Criatividade para hibridar a forma da Estratégia Atual Preferida com a interpretação atual do Caos de Campo da FCI.
[33] A Cessão Prioritária e Prova (PAP) modifica os Critérios de Implantação da Estratégia para executar com prioridade estendida de acordo com o valor extra pago pelo Usuário UBEC, em que a Implantação da Estratégia que é subsequentemente produzida contém um valor relativamente alto para os Critérios de Propagação de Salto Paralelo e um valor relativamente baixo valor para Critérios de Redução de Salto Paralelo em que mais Caminhos de Salto Paralelo são iniciados, o que leva a menor latência, menor perda de pacotes e maior confiabilidade, em que as Implementações da Estratégia são empacotadas em Conjunto de Variável sde Trilha (TVS) de um CCR ou CCF, em que o Acompanhamento do Desempenho da Estratégia (SPT) é uma Appchain de banco de dados que rastreia o desempenho percebido das estratégias implantadas na rede, que permite à OSSA selecionar a que é considerada a estratégia preferida atual,
Petição 870200056145, de 06/05/2020, pág. 22/1737
20/754 considerando as condições da rede local.
[34] O Rastreamento de Desempenho da Estratégia (SPT) opera como uma Appchain pesada do Segmento de Dados, o SPT armazena Unidades de Estratégias, em que cada Estratégia tem uma Composição de Critérios de Estratégia Básica, que atua como a Identidade Principal da Estratégia, na qual todas as outras variações dentro de uma Unidade de Estratégia atuam como medidas logísticas de desempenho e tempo para permitir que a OSSA escolha o que considera ser a Estratégia Atual Preferida, que é estendida sempre que uma atualização da Estratégia é fornecida pela Interpretação de Desempenho da Estratégia (SPI), em que associadas a cada Estratégia existem várias Unidades de Rastreamento de Desempenho, que são relatadas pelo SPT, em que uma Unidade de Rastreamento contém uma Composição do NSS e um índice de Desempenho, em que a composição do NSS captura as variáveis do NSS que existiam no momento em que esta Unidade de Rastreamento foi capturada, em que o índice de Desempenho registra as Medições de Desempenho, incluindo Saltos por Segundo e megabytes.
[35] O Rastreamento de Desempenho da Estratégia (SPT) se conecta indiretamente ao Algoritmo de Seleção de Múltiplas Variáveis (MVSA) , em que o MVSA seleciona a Estratégia mais apropriada dos dados no SPT, em que os Dados do SPT são usados para derivar um índice de Desempenho da Estratégia, que é uma média composta de todos os índices de desempenho individuais listados em uma única Estratégia, em que o Ranking de Confiança da Estratégia indica quanta precedência/evidência está disponível para justificar a percepção no índice de Desempenho
Petição 870200056145, de 06/05/2020, pág. 23/1737
21/754 da Estratégia, em que o MVSA faz referência à Política de Código Codificado Estático (SHP) para discernir os critérios pelos quais selecione a estratégia apropriada, em que todas as estratégias que não expiraram do SPT são recuperadas, em que todas as composições do NSS de Todas as Estratégias Ativas que estão dentro do Alcance da Maquiagem Local do NSS são recuperadas, produzindo o NSS Makeups dentro do intervalo, que contêm unidades de acompanhamento de desempenho selecionadas de várias Estratégias, em que as Unidades de Acompanhamento de Desempenho são organizadas de acordo com a Composição dos Critérios da Estratégia, em que os Contêineres da Estratégia contêm estratégias selecionadas que contêm as Unidades de Rastreamento de Desempenho que foram inicialmente selecionadas, em que os Contêineres da Estratégia são referidos para calcular o índice de Desempenho Médio por Estratégia que gera como índice de Desempenho da Estratégia pelo qual o Ranking de Confiança da estratégia é calculado por estratégia, em que a Estratégia Preferida é selecionada de acordo com o desempenho e a confiança da avaliação via MVSA.
[36] 0 Módulo de Criação de Estratégia (SCM) é invocado pela Adaptação Dinâmica da Estratégia (DSA), em que o SCM varia inteligentemente composições de Estratégias por meio do Módulo de Criatividade para criar Estratégias Experimentais de baixo risco que se baseiam nos pontos fortes das iterações anteriores, em que a Interpretação de Caos de Campo (FCI) envia sua saída da Interpretação do Caos à Criatividade como um formulário de entrada, em que os Critérios Estáticos da Criatividade são baseados nos Limites do Escopo da Estratégia acordados e no valor
Petição 870200056145, de 06/05/2020, pág. 24/1737
22/754 da Unidade Watt que foi pré-autorizado no Token de Autorização Econômica (EAT), em que a atual estratégia preferida é recebida pela OSSA e é descompactado para recuperar a composição dos critérios de estratégia.
[37] Os critérios que compõem a composição dos critérios de estratégia compreendem:
a) Expiração de Testemunha de Salto que indica quanto tempo deve ter passado para que uma entrada de Testemunha de Salto na História Recente do Salto (RHH) seja ignorada, removendo os caminhos de lúpulo paralelo potencialmente inúteis;
b) Critérios de Propagação de Salto Paralelo que indicam a Largura do Salto Paralelo e a que gatilho os valores das variáveis;
c) Critérios de redução de Salto Paralelo que indicam quando os Caminhos de Salto Paralelo devem ser removidos devido a redundância;
d) Saturação de Conteúdo necessária para armazenar em Cache, que é a Quantidade Mínima de Ocorrências nas quais uma Appchain foi recentemente testemunhada por esse nó no Histórico Recente de Saltos (RHH);
e) Curso mínimo de salto necessário para armazenar em cache, que é a quantidade mínima de progresso que precisa ser concluída para o nó armazenar em cache o conteúdo, pelo qual apenas os nós que participam da jornada após o ponto intermediário serão elegíveis para armazenar em cache o conteúdo;
f) Ponto de Salto da Declaração de demanda que é o ponto de salto ao longo da jornada CCR ou CCF em que o Nó Declara para a Metachain a demanda da Appchain e a demanda do Setor, em
Petição 870200056145, de 06/05/2020, pág. 25/1737
23/754 que o a Demanda da Appchain é rastreada para decidir o cache e os locais da Appchain, enquanto a Demanda do Setor é rastreada para calcular os diferentes preços de diferentes setores;
g) Confiabilidade Minima do Nó para a Implantação de
Caminhos, que é o nível mínimo de confiabilidade de um nó,
conforme determinado pelas variáveis do NSS, para que um seja
incluído em um Caminho de Salto;
h) Critérios de Mineração Autoimposta, que é a
quantidade minima de recursos de computação relativos necessários para minerar uma Appchain, em que o valor é proporcional à carga de recursos da mineração para a Appchain;
i) Critérios de Evitação do Ambiente Caótico que definem características dos nós que os indicam esporádicos e não confiáveis, conforme entendido pelas variáveis fornecidas pelo NSS;
j) CCFs a reter no Cache Clash que define a quantidade percentual do armazenamento do Nó local que deve ser alocado para reter os CCF que não existem no cache de conteúdo do nó primário (PNCC);
k) Troca de confiabilidade/distância da rota que define a zona de eficiência percebida em relação à troca de seleção entre a confiabilidade dos nós selecionados e a distância esperada percorrida;
l) Gatilho da Microchain da ITII que define o valor do índice de Isolamento de Transferência de Informação (ITII) necessário para merecer um voto de Nó na troca de uma Appchain para um formato de Microchain;
1) Múltiplo de Arredondamento de Consenso de
Petição 870200056145, de 06/05/2020, pág. 26/1737
24/754
Tráfego, que é o múltiplo do qual as variáveis NVCI e de desempenho são arredondadas para cima ou para baixo, em que se esse valor aumentar, o tamanho relativo dos setores influenciados por essa variável aumentará gradualmente de tamanho e se esse valor diminuir, os setores diminuirão de tamanho e a contagem de nós ;
m) Intervalo Variável do Grupo NSS que define com que frequência os Nós devem se anunciar nos Setores com os quais compartilham uma sobreposição, as variáveis do NSS que percebem;
n) Multiplicador de Pagamento de Trabalho que define a intensidade da discrepância no pagamento entre os setores com pagador mais baixo e mais alto;
o) Tempo Mínimo de Retenção de Cache que define a quantidade mínima de tempo que um nó de cache é necessário para reter um cache que ele optou por adotar;
p) Taxa de Pagamento de Mineração para Armazenamento em Cache que aloca uma divisão de pagamento entre o Trabalho Passivo realizado pelo Algoritmo de Seleção de Mineração (MSA) e o Trabalho Passivo realizado pelo Algoritmo de Seleção de Cache (CSA);
q) Limite de Exclusão de Peças de Cache que define quando é seguro para os mineradores em um setor que está recuperando dados via Processamento de Refúgio de Dados (DRP) excluir esses dados em perigo;
r) Magnitude Tributária do Setor que atua como multiplicador do tamanho do valor da Unidade de Consequências Tributárias a ser imposta ao Nó do Setor relevante.
[38] 0 processamento do SCM de sua entrada e saída
Petição 870200056145, de 06/05/2020, pág. 27/1737
25/754 modular começa com a Estratégia Preferida Atual como entrada inicial, em que a Estratégia é extraída em um formato intermediário para disponibilizá-la para manipulação e processamento pelo SCM do módulo pai, pelo qual a Composição dos Critérios de Estratégia é gerada a partir da Entrada Estratégia Preferida Atual, em que a lógica atualiza a Composição dos Critérios da Estratégia para uma nova versão de experimentação de baixo risco da estratégia, que acaba se tornando a saída da Implantação da Estratégia, em que, após a conclusão do processo de atualização, o módulo Montagem da Sintaxe da Estratégia (SSA) repete as informações no formato que é compreensível para os outros módulos que operam o protocolo BCHAIN.
[39] 0 Módulo de Criatividade é usado para atualizar a Composição dos Critérios de Estratégia, considerando as variáveis NSS que refletem o estado do ambiente local da Rede BCHAIN, em que a Criatividade recebe o Modo dos critérios atualmente selecionados da Criação de Estratégia, que é um Modelo Predefinido para gerenciar a dinâmica de criação e variação de estratégia, em que a criatividade processa duas entradas; Forma A e Forma B, em que todos os Critérios da Composição dos Critérios de Estratégia são selecionados para processos individuais como Forma A com Criatividade, em que a Forma B é a interpretação geral do Caos de Campo da Interpretação de Campo do Caos (FCI), em que após a conclusão do processamento da Criatividade, o Formulário de Saída AB é produzido como as novas variações propostas dos Critérios.
[40] O Usuário UBEC acessa a Plataforma UBEC por meio do reconhecimento biométrico realizado na Interação com o Nó do
Petição 870200056145, de 06/05/2020, pág. 28/1737
26/754
Usuário (UNI), através da qual é produzida uma Sessão de Usuário Autenticada a partir da qual a Lista de Nós Associados é extraída, em que a Sessão do Usuário Autenticado também é usada para acessar o Usuário Front-End. Interface que leva a uma Seleção de Personalidade Econômica, em que o Usuário UBEC seleciona uma Personalidade Econômica referenciada pela Computação e Disponibilidade de Recursos de Rede do Protocolo BCHAIN, em que a CNRA faz referência à Seleção de Personalidade Econômica da Plataforma UBEC como uma metodologia para medir qualquer excedente disponível recurso de um Nó que está associado ao Usuário UBEC por meio da Lista de Nós Associados, em que a CNRA concede referência ao módulo Seleção de Incentivo Econômico (EIS), em que o EIS recomenda que o Nó execute Outro Trabalho de Nó ou uma sessão de trabalho de Envio de Log de Diagnóstico (DLS), em que a execução local do EIS em um nó aciona esse nó para se tornar um colocou o Nó de Diagnóstico por meio da execução do DLS, em que o Nó se declara um Nó de Diagnóstico para Localização do Nó de Diagnóstico da Metachain, em que, devido ao status inicialmente declarado do Nó desde a execução do Estágio, o Nó é marcado como não confirmado até outros Nós podem confirmar que está executando a função declarada, em que as atualizações feitas no Local do Nó de Diagnóstico da Metachain são enviadas ao Módulo de interface da Metachain (CIM) para serem extraídas e comprometidas com a Metachain real.
[41] Devido à declaração do Nó na Metachain respeito de ser um Nó de Diagnóstico, outros Nodos do mesmo Setor enviam Registros de Diagnóstico por meio de Submissão CCF Jurisdicionalmente Implicada (JICS) e Recepção CCF
Petição 870200056145, de 06/05/2020, pág. 29/1737
27/754
Jurisdicionalmente Aceita (JACR), em que os Logs de Diagnóstico são validados para autenticidade pelo nó de diagnóstico autodeclarado, em que as Unidades de Log marcadas com um Token Oficial do sistema são enviadas ao Desenvolvimento Indireto SPSI (SID), em que o token oficial do sistema é a prova criptográfica de que a unidade de log se origina de uma Appchain oficial, em que as Appchains são marcadas como Oficial se elas contribuírem com a funcionalidade principal da Plataforma UBEC.
[42] Outros nós BCHAIN no mesmo setor processam o módulo Coleta de Log de Diagnóstico (DLC) para registrar os Logs Relevantes que devem ser enviados aos locais relevantes por meio do Envio de Log de Diagnóstico (DLS), em que os Logs do DLC são encaminhados para o JICS, que envia um CCF sem o CCR acompanhante para uma instância do JACR que invocou o DLS no Nó de Diagnóstico auto-declarado, em que, devido à declaração do Nó de ser um Nó de Diagnóstico no Local do nó de Diagnóstico da Metachain, ele deve aceitar os Pacotes CCF enviados pelo JICS devido à jurisdição eleita, em que o LIZARD monitora e justifica pacotes CCF sem um CCR associado, pelo qual a tecnologia de rastreamento de jurisdição do LIZARD é implementada nas camadas mais baixas do tráfego da Rede BCHAIN.
[43] Na Seleção de Incentivo Econômico (EIS) e no Processamento de Reivindicações de Pagamento de Trabalho (WPCP), o EIS atua como um mecanismo de arbitragem de oferta/demanda para a Rede BCHAIN, em que os Nós que procuram Trabalho com Nó Ativo invocam o EIS para selecionar o melhor tipo de trabalho disponível que é o mais provavelmente produzirá o Nó com o melhor retorno do investimento, em que variáveis locais e remotas
Petição 870200056145, de 06/05/2020, pág. 30/1737
28/754 relativas a Metachain são analisadas para entender as tendências atuais da demanda de suprimento, em que é invocado o módulo de Arbitragem de Demanda e Oferta (SDA), em que o SDA faz referência a Metachain para criar uma representação lógica de vetores de oferta/demanda na Rede BCHAIN, em que a SDA envia a Composição da Demanda para Representar as descobertas de seus cálculos, em que a disponibilidade de recursos é verificada chamando-se Computação e Disponibilidade de Recursos de Rede (CNRA), em que a designação de Personalidade Econômica é projetada dentro da UBEC UPI (Platform Interface), em que se os recursos não estiverem disponíveis, a operação do EIS será encerrada, em que, se houver recursos disponíveis, o EIS chama a Seleção de Trabalho de Nó (NJS), que faz referência à Composição da Demanda de Fornecimento e à disponibilidade de recursos do Nó na seleção de um trabalho de trabalho adequadamente lucrativo.
[44] Na transição entre Seleção de Incentivo Econômico (EIS) e Processamento de Reivindicação de Pagamento de Trabalho (WPCP), uma vez concluído o trabalho Ativo ou Passivo, é feita uma reivindicação de receita ao WPCP que verifica e processa o pagamento à Economia de Watt a Metachain, em que o Passivo Trabalho do Nó é um trabalho implicado pelo Protocolo BCHAIN devido às necessidades da Rede, em que o Trabalho do Nó Ativo é realizado por motivos egoístas do Nó em nome de seu proprietário, o Usuário UBEC, enquanto está de acordo com a Personalidade Econômica selecionada, em que o EIS chama apenas o Trabalho do Nó Ativo via Seleção de Trabalho do Nó, enquanto o Trabalho do Nó Passivo está implicado devido à conformidade do Protocolo, em que se o WPCP foi chamado pela conclusão do Trabalho Passivo ou
Petição 870200056145, de 06/05/2020, pág. 31/1737
29/754
Ativo por um Nó; o Pagamento de trabalho validado é enviado para Pagamentos de Trabalho Pendentes e ainda validados da Metachain, em que se o WPCP foi invocado por um novo anúncio de bloco resolvido, os pagamentos pendentes são enviados para a economia de watts, em que após a invocação modular do WPCP via Resolvido
[45] Anúncio de Novo Bloco de Trabalho, pagamentos de Trabalho Pendentes ainda validados é recuperado da Appchain associada ao bloco recém-resolvido pelo qual pagamentos pendentes são produzidos como saida.
[46] Em um processador UBMA, dois reguladores de tensão controlam a entrada de tensão que leva a duas subseções separadas do processador UBMA, em que duas tensões separadas podem ser ajustadas em paralelo, o que leva à priorização dinâmica de recursos de acordo com os sinais recebidos do Protocolo BCHAIN, em que Para que os nós BCHAIN possam se comunicar via rádio, existem várias frequências de encontro às quais cada nó transmite ocasionalmente sua identidade, anúncio de hash e frequência pessoal, onde, posteriormente, dois nós estabelecem um canal de comunicação ponto a ponto podem se encontrar nas frequências pessoais uns dos outros e trocar informações, nas quais o Wireless opera em diferentes frequências para evitar colisões e interferências, e é diversificado por comunicações de curto, médio e longo alcance, nas quais o Protocolo BCHAIN prioriza as informações que devem ser transferidas em situações de escassez, em que o gerenciamento de E/S reconhece os segmentos de execução e Instruções Gerais de Processamento e, portanto, as atribui ao Microchip correto e retorna os dados para o restante do Nó.
[47] Na estrutura da Subseção A, o Microchip de
Petição 870200056145, de 06/05/2020, pág. 32/1737
30/754 logística da Appchain é capaz de processar a retenção e a execução das Appchains e Microchains na Rede BCHAIN, em que o LIZARD como um microchip não depende de um banco de dados para operação e, em vez disso, julga e estima medidas de risco e conformidade em momento devido à sua complexa inteligência a priori (sem referência prévia), em que o UBMA Processor pode alterar dinamicamente seu próprio conjunto de microprocessadores por meio de estruturas condutoras dinâmicas, em que o Microchip de Lógica de Roteamento aumenta a eficiência energética e reduz a latência para a Lógica de Roteamento (RL) , em que o mais utilizado dos Submódulos da LOM, incluindo Construção de Asserção (AC) e Mapeamento Hierárquico (HM) , é otimizado no LOM Lógica Principal como um Microchip, pelo que todo o Fluxo de Manifestação Modular de Execução da LOM é eficiente para executar, em que o módulo de criatividade como um microchip otimiza a execução do módulo de criatividade dentro da plataforma UBEC, que aumenta a eficiência computacional na plataforma UBEC e na rede BCHAIN devido a muitas Appchains, dependendo da criatividade, incluindo I2GI, CTMP, MPG, SPSI .
[48] Na Subseção B do Processador UBMA, a Unidade de Processamento Criptográfico (CGPU) executa as funções que operam no Núcleo de Criptografia (CC) , que são chamadas por todo o Protocolo BCHAIN, em que a Unidade Geradora de Certificado de Hardware Seguro (SHCG) retém com segurança Chave Privada Exclusiva sensível que é usada para manipular os fundos do Nó dentro da Economia de Watts da Metachain, em que um endereço público gerado pelo nó pode ser gerado de forma eficiente e rápida pelo SHCG sem responsabilidade e risco de que a chave
Petição 870200056145, de 06/05/2020, pág. 33/1737
31/754 privada exclusiva sensível à segurança seja exposta, em que forçosamente acoplando unidades de watt na Economia de Watt ao hardware físico de um nó por meio do Processador UBMA, o gerenciamento e a manipulação de Unidades de Watt se tornam mais previsíveis e seguros na Plataforma UBEC e na Rede BCHAIN, em que o Microchip SHCGU contém uma Cadeia de Identificação exclusiva do nó codificado que foi gerado aleatoriamente no momento da fabricação do Processador UBMA.
[49] No SHCGU, a Associação de Identidade Permanente com Hardware (PIAH) produz a Identificação Exclusiva do Nó que foi definida no momento da fabricação, em que com a Chave Privada Bloqueada por Hardware (HLPK), a Chave Privada Única Sensível à Segurança é permanentemente observada atrás de uma Camada de Bloqueio de Hardware, em que a única exceção para uma cópia da chave privada que sai intencionalmente da camada de bloqueio de hardware é por meio do canal exclusivo de backdoor para envio à LUIGI, em que a Geração de Endereço Público (PAG) é a subseção que gera um endereço público derivado da chave privada sem transferir nenhuma instância da chave privada para fora da camada de bloqueio de hardware.
[50] No Mecanismo de Recuperação de Fundos (FRM), o Usuário da UBEC se autentica pela Interação com o Nó do Usuário (UNI), que produz uma Sessão de Usuário Autenticado, em que o início do processo para recuperar fundos perdidos é invocado pelo Usuário da UBEC através do Front-End da UBEC, em que a lista de nós associados é descompactada da sessão de usuário autenticado, em que uma Sessão de Verificação de Recuperação de Fundos é iniciada com o Usuário da UBEC por meio do front-end da UBEC, em
Petição 870200056145, de 06/05/2020, pág. 34/1737
32/754 que o Módulo de Verificação de Recuperação de Fundos (FRV) gerencia a Sessão de Verificação de Recuperação de Fundos.
[51] Em interação entre o Mecanismo de Recuperação de Fundos (FRM) e a LUIGI, em que FRM é um submódulo pertencente à jurisdição da LUIGI, em que a Chave de descriptografia de retenção é acessada no LUIGI Seguro da Enclave (LSE), em que a Chave de Descriptografia de Retenção é usada para descriptografar e acessar a Chave Privada Única Sensível à Segurança, usada para manipular fundos da Economia de Watt da Metachain por meio do Mecanismo de Manipulação de Fundos (FMM), pelo qual a LUIGI tem acesso a toda a Economia UBEC/BCHAIN armazenada na Economia de Watt devido à sua duplicata cópias das Chaves Privadas na Retenção Criptografada de Chaves Privadas.
[52] 0 LUIGI é programado uma vez e pela primeira vez diretamente por seres humanos e uma vez que a Plataforma UBEC e a Rede BCHAIN estão ativas e operacionais pela primeira vez, todo acesso criptográfico para modificar a base de código da LUIGI é retido exclusivamente pelo Auto-programação Auto-inovação (SPSI), em que o SPSI é uma Appchain que usa a tecnologia LIZARD para programar outras Appchain na Plataforma UBEC, em que a programação pelo SPSI inclui refino, correção de erros, manutenção agendada, análise da Unidade de Log de Diagnóstico, inovação de novos recursos, em que o SPSI é capaz de se programar, mas recebe elementos Diretrizes de Programação do Desenvolvimento Indireto do SPSI (SID).
[53] De acordo com o Protocolo BCHAIN permanente, é concedido ao SPSI acesso exclusivo para manipular a Base de Código de todas as Principais Funções da PLATAFORMA UBEC,
Petição 870200056145, de 06/05/2020, pág. 35/1737
33/754 incluindo Aplicativo UBEC, LUIGI, Criatividade, I2GE, SPSI, LOM, LIZARD, CTMP, MPG, MC e I2CM, em que o LOM recebe Unidades de Log de Diagnóstico do Mecanismo de Pesquisa Automatizados (ARM), em que o LOM caracteriza e entende defeitos de rotina com os Recursos Existentes Atualmente e Propõe Soluções para as Unidades de Log Recebidas, em que os Recursos Existentes são os Recursos da Appchain selecionada que foi direcionada para programação/refinamento/inovação, em que as Soluções Propostas são produzidas com Avarias de Recursos Existentes, em que o LOM inspeciona a Appchain selecionado e estima novos recursos propostos, o que espera melhorar a capacidade e a eficiência da Appchain no desempenho de sua função principal, em que os Recursos Propostos e as soluções são definidas em seu propósito e transferidas para o LIZARD para serem programadas em aos códigos funcionais através dos Módulos Objetivo e Sintaxe.
[54] 0 LIZARD gera Conjuntos de códigos executáveis que representam as idéias originalmente concebidas pela LOM, em que os Conjuntos de códigos executáveis são transferidos para o I2GE juntamente com os Cenários de execução bem-sucedida e com falha da LIZARD, o I2GE evolui e aprimora, pela Criatividade, o software através de várias vias evolutivas usando os Recursos de CPU e armazenamento disponibilizados pela Rede BCHAIN, em que, ao fazer referência aos Cenários de Execução Bem-sucedida e com Falha, o I2GE é capaz de distinguir Variações dos Conjuntos de Códigos que são finalmente estáveis e funcionais com os que não são, em que a LOM verifica se o software resultante é de acordo com sua percepção de estabilidade e meios de alcançar a funcionalidade.
Petição 870200056145, de 06/05/2020, pág. 36/1737
34/754
[55] 0 Avanço da Inteligência Recursive Simbiótica (SRIA), é um Algoritmo de Inteligência Artificial que se manifesta principalmente na Operação de autoprogramação de Autoinovação (SPSI). 0 SRIA está relacionado ao LIZARD, I2GE e SPSI, em que o LIZARD aprimora o Código-fonte de um Algoritmo ao entender o Objetivo do Código, em que o I2GE emula Gerações de Iterações de Programas Virtuais, selecionando a versão mais forte do programa, em que BCHAIN é uma vasta Rede de Nós caoticamente conectados que podem executar Appchain de maneira descentralizada, em que o SPSI mantém as mesmas Appchain que lhe conferem funcionalidade e recursos, em que o Layout do Sistema Baseado em Loop de Feedback garante que o progresso incrementai gradual nos recursos cognitivos e de solução de problemas de Inteligência Artificial aumente, em que a Emulação virtual ocorre quando o I2GE executa o código do Cambio de Aplicativo de destino em um Ambiente Virtual hospedado pela REDE BCHAIN, em que BCHAIN atua como um Provedor de Recursos de Hospedagem para I2GE, LIZARD, LOM, CTMP, NC e I2CM.
[56] 0 Status Quo representa genericamente a funcionalidade geral, a eficiência e o design de um Sistema de destino, em que o LOM é chamado pelo Prompt de Chamada de Princípio de Design (DPIP) para produzir Princípios de Design de Sistema, em que o aperfeiçoamento dos Princípios de Design é ativado por LIZARD, que converte os dados relevantes no formato de finalidade que atua como o estágio intermediário crucial para a execução precisa de modificações do sistema, em que o LIZARD usa suas habilidades de programação para realizar modificações experimentais no Status Quo Refinado, em que o novo Status Quo é
Petição 870200056145, de 06/05/2020, pág. 37/1737
35/754 virtualizado e evoluído pelo I2GE, pelo qual o ciclo de inteligência foi redefinido e o potencial do próximo ciclo se torna disponível aumenta à medida que os algoritmos relevantes da Appchain descobrem novas informações, funcionalidades e técnicas .
[57] No que diz respeito ao pool de inteligência, o CTMP atua como o local central de retenção de inteligência, pois gradualmente usa a inteligência de algoritmos, em que o CTMP interpreta todas as decisões baseadas artificialmente tomadas pelos algoritmos da Appchain, incluindo LIZARD, LOM e I2GE, e recebe seus logs de processamento bruto que agem como fatos objetivos relativos à decisão tomada, em que a inteligência agregada de vários algoritmos da Appchain é reciclada pelo CTMP e qualquer inteligência coletada/agrupada eventualmente beneficia todos os algoritmos da Appchain que interagem com o CTMP.
[58] No que diz respeito ao feedback e influência sobre Hardware, Estrutura e Funcionalidade, um design de sistema ideal é produzido no Gerador de Sistema de Destino Abstrato (ATSG), em que a funcionalidade necessária do usuário está relacionada e informa a definição de nova funcionalidade do usuário, na qual a sintaxe da funcionalidade é herdado pela Funcionalidade de Aplicativo, que por sua vez se torna uma camada de Ativação da Operação para Funcionalidade de Novo Usuário, em que o aprimoramento da Funcionalidade de Aplicativo se manifesta no submódulo do Novo SPSI Novo desenvolvimento de Appchain (NAD), em que a prática principal da tensão da camada logística é o aprimoramento da Eficiência do Código, Qualidade, Segurança e
Petição 870200056145, de 06/05/2020, pág. 38/1737
36/754
Estabilidade e o Processo é Realizado pela SPSI por meio de seus submódulos Proteção da Segurança da Appchain (ASH), Correção de Erros Inatos (IEC), Refinamento Automatizado da Appchain (A2R), Manutenção automatizada da Appchain (A2M), Manutenção automatizada da Appchain (A2M), Regulamentação da Appchain (ARC) e Análise de Unidade de Log de Diagnóstico (DLUA) , em que a qualidade aprimorada do código permite a operação do aplicativo, que por sua vez Ativa a Nova Funcionalidade do Usuário, em que os referidos aspectos do software são Ativados pela Adaptação de Framework, em que a Adaptação representa as alterações executadas no Framework subjacente que permitem que os Aplicativos de Espaço do Usuário Operem, em que a Adaptação de Framework é praticamente realizada por o Desenvolvimento Aprimorado do Framework (EFD) do SPSI, no qual as Alterações de Hardware são executadas de acordo com a sintaxe do Framework Herdada, que, por sua vez, permite que o Framework e seu Espaço de Usuário Operem.
[59] Em relação à inteligência que escorre da interação do Usuário da UBEC em ciclos multicamadas, o Ciclo de Longo Prazo representa os Princípios Orientadores da Direção do SPSI em larga escala, segundo os quais as capacidades, metodologias e tendências do SPSI são gradualmente informadas de maneira lenta e a longo prazo básica através da interação Humana da LOM e o Desenvolvimento Indireto da SPSI (SID), em que a LOM atua como um diretor racional da funcionalidade e da operação da SPSI devido ao seu raciocínio objetivo que é ativado pela invocação modular interna do CTMP, em que as alterações que ocorrem via LOM e SID a longo prazo do Ciclo, Afetam e Informam o Ciclo de Médio Prazo, que representa a operação prática sustentada do
Petição 870200056145, de 06/05/2020, pág. 39/1737
37/754
SPSI, em que os Submódulos do SPSI são gradualmente afetados pelos Princípios Orientadores da Direção do SPSI, em que a operação do SPSI no Ciclo de Médio Prazo leva ao aprimoramento geral dos Appchains que existem na Plataforma UBEC/Rede BCHAIN, bem como em Appchains/ Programas Herdados que operam com nos Sistemas Herdados pela Camada de Emulação da Appchain (AEL), em que os Ciclos de Inteligência de Adaptação de Curto Prazo são aprimorados pelo SPSI, que permite estratégias sofisticadas de adaptação implantadas no Curto Prazo.
[60] Na Autoprogramação de Auto-Inovação (SPSI), o Refinamento Automático da Appchain (A2R) inspeciona as Appchains ou Programas Legados, em que a Manutenção Automatizada da Appchain (A2M) mantém a Appchain ou Programa Legado selecionado, excluindo caches expirados, atualizando Funções Reprovadas para Funções Utilizáveis, atualizando Módulos Reprovados e Dependências com módulos utilizáveis, excluindo pontos de referência expirados e executando a calibração econômica de estabilidade, em que a Proteção da segurança da Appchain (ASH) inspeciona automaticamente pontos de invasão e exploração em uma Appchain ou Programa Legado, em que a Conformidade com os Regulamentos da Appchain (ARC) garante que o aplicativo selecionado da Appchain ou Programa Legado está em conformidade com várias regulamentações específicas, em que a Análise de Unidade de Log de Diagnóstico (DLUA) recebe Unidades de Log de Diagnóstico (DLU) de rotinas com mau funcionamento e estabelece as disposições apropriadas para tentar corrigir tais avarias percebidas, em que a Correção de Erro Inato (IEC) tenta corrigir fundamentos e falhas de procedimento que podem levar a uma rotina
Petição 870200056145, de 06/05/2020, pág. 40/1737
38/754 interrompida, em que o Novo Desenvolvimento de Appchains (NAD) encontra usos para Aplicativos em um Ecossistema de Aplicativos Especificado que possui um Recurso de Aplicativo em potencial ausente, o que seria perceptivelmente benéfico para esse ecossistema, em que o Desenvolvimento Aprimorado do Framework (EFD) inspeciona e potencialmente aprimora as estruturas de software existentes para a plataforma UBEC/Rede BCHAIN e Sistemas Legados, em que o Desenvolvimento Aprimorado de Hardware (EHD) modifica sistemas físicos que contêm as Placas Condutoras Líquidas Dinâmicas (DLCB) e, portanto, pode ter sua estrutura de hardware principal otimizada e atualizada, em que o Mecanismo de Segmentação da Appchain (ATM) processa um algoritmo de seleção inteligente que informa outros módulos para quais Appchains eles devem selecionar em seu processamento.
[61] 0 LIZARD opera para converter o Fluxo de Execução da Appchain de Destino, que foi selecionado pelo ATM, em um Mapa de Hierarquia de Propósito, em que o Fluxo de Execução da Appchain de Destino que é produzida pela Coleta de Fluxo de Execução (ESC) é enviado ao Módulo de Sintaxe, em que para a escrita do código, o SM recebe o Formato de Propósito Complexo do Módulo de Propósito (PM), em que, para a leitura do código, o SM fornece uma interpretação sintática do código do computador para o PM derivar um propósito para a funcionalidade desse código, em que a Appchain de Destino é recebida no formato Fluxo de Execução Cumprido pela Tradução de código, em que a Tradução de código converte Código Arbitrário (genérico) que é reconhecido e compreendido pela SM para o Idioma de Computação Escolhido, em que o Tradução de código executa a função inversa de traduzir
Petição 870200056145, de 06/05/2020, pág. 41/1737
39/754 idiomas de computação conhecidos em tipos de sintaxe arbitrários, em que a saída da execução concluída da Conversão de Código é transferida como entrada para Redução Lógica, em que a Redução de Rede Lógica reduz a lógica do código a formas mais simples para produzir um mapa de funções interconectadas de acordo com as definições de Regras e Sintaxe, em que após a execução completa da Redução Lógica, a Execução da Instância SM correspondente é concluída e a Saída Modular do SM é enviada para Interpretação Iterativa de PM, em que PM usa SM para derivar um propósito em Formato de Propósito Complexo a partir de código de computador, em que a Interpretação Iterativa circula todas as funções interconectadas para produzir uma definição de propósito interpretada consultando Associações de Propósito.
[62] A Redução Lógica do Módulo de Sintaxe SM envia sua saída para Interpretação Iterativa do PM, em que a Interpretação Iterativa percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada consultando Associações de Propósito, em que a saída de definição de finalidade existe no Formato de Propósito Complexo, que é submetido como saída modular para PM, em que a saída é rotulada como um Mapa de Hierarquia de Propósito, que é apresentada como a versão de Formato de Propósito Complexo da Appchain Alvo.
[63] Os Princípios de Design de Código são submetidos à SM, que pertence à jurisdição do Núcleo Externo (OC), em que a SM fornece uma estrutura para Leitura e Gravação de Código de Computador, em que, para a Redação do Código, a SM recebe o Formato de Propósito Complexo da PM, em que o Formato de Propósito
Petição 870200056145, de 06/05/2020, pág. 42/1737
40/754
Complexo é então escrito em pseudocódigo, em que, posteriormente, uma função auxiliar converte o pseudocódigo em Código Executável real, dependendo da sintaxe de computação de destino desejada, em que para leitura de código, o SM fornece uma interpretação sintática do Código do Computador para o PM derivar uma finalidade para a funcionalidade desse código, em que a Appchain Alvo é recebida no formato de sintaxe de principio pela Tradução de Código, em que a Tradução de Código converte código arbitrário que é reconhecido e entendido pela SM em qualquer linguagem de computação escolhida, em que a tradução de código executa a função inversa de traduzir linguagens de computação conhecidas em tipos de sintaxe arbitrários, em que a saída da execução concluída da tradução de código é transferida como entrada para a redução lógica, em que a redução lógica reduz a lógica do código para formas mais simples de produzir um mapa de funções interconectadas de acordo com as definições de Regras e Sintaxe.
[64] A Redução Lógica do SM envia sua saída para Interpretação Iterativa do PM, em que a Interpretação Iterativa faz um loop através de todas as funções interconectadas para produzir uma definição de finalidade interpretada consultando Associações de Propósito, em que a saída de definição de finalidade existe no Formato de Propósito Complexo, que é enviado como saída modular para PM, em que a saída é rotulada como um Mapa de Hierarquia de Propósito, que é apresentada como a versão de Formato de Propósito Complexo dos Princípios de Design de Código.
[65] A Coleção Finalidade da Instrução existe em Formato de Finalidade Complexa e é submetida à Expansão Iterativa
Petição 870200056145, de 06/05/2020, pág. 43/1737
41/754 do PM, dentro do Núcleo Externo (OC) da LIZARD, em que a Expansão Iterative adiciona detalhes e complexidade para evoluir uma meta simples para uma definição de finalidade complexa específica, sendo, portanto, o máximo potencial de associação de finalidade da entrada é realizado e retido como um formato de objetivo complexo, antes de ser submetido à Derivação lógica do SM, em que os dados de entrada são recebidos no formato de objetivo complexo do PM e são transferidos para derivação lógica do SM, em que A derivação lógica deriva funções logicamente necessárias de funções inicialmente mais simples, em que o resultado produzido é uma árvore de dependências de funções que são construídas de acordo com os dados definidos no formato de finalidade complexa, em que a derivação lógica opera de acordo com as regras e definições de Sintaxe Herdadas do Núcleo Elemento de Código do Núcleo Interno, em que a Derivação Lógica envia sua saída para a Tradução de Código, em que, portanto, o PM chama SM para produzir a versão resultante da sintaxe da Appchain do mapa de finalidade atualizado de entrada pela Tradução de Código.
[66] A Correção de Erro Inato (IEC) é um submódulo do SPSI, em que o Mecanismo de Segmentação da Appchain (ATM) seleciona uma Appchain Alvo especificada que é então enviada como entrada modular a uma instância chamada Coleta de Fluxo de Execução (ESC), em que o Fluxo de Execução que é produzido como saída modular da instância ESC é enviado como entrada modular para um estágio do IEC, que separa o fluxo de execução da Appchain para produzir o Blueprint da Estrutura de Código, em que cada Unidade de Código Selecionada existente no Blueprint da Estrutura de Código é percorrida por meio de um Loop de programação, em
Petição 870200056145, de 06/05/2020, pág. 44/1737
42/754 que LIZARD é chamado para produzir um Mapa de Hierarquia de Propósito de todo o Blueprint da Estrutura de Código, em que ambos Mapas de Hierarquia de Propósito são submetidos como entrada modular ao módulo Processamento de Simetria de Propósito a Propósito (P2SP), em que após a conclusão do processamento de P2SP, o resultado do processamento de simetria é produzido como a saída modular.
[67] A Unidade de Código Selecionada é enviada à SM, em que a Unidade de Código Selecionada é recebida no formato Fluxo de Execução Cumprido pela Conversão de Código, em que a saída da execução concluída da Conversão de Código é transferida como entrada para Redução Lógica, em que Redução Lógica reduz a lógica de código para formulários mais simples para produzir um mapa de funções interconectadas de acordo com as definições de Regras e Sintaxe, em que a Redução Lógica envia sua saída para Interpretação Iterativa, em que o Blueprint da Estrutura de Código é enviado para SM.
[68] Depois que a Coleta de Fluxo de Execução (ESC) envia o Fluxo de Execução como entrada modular do IEC, a Renderização de Fluxo de Execução é chamada para interpretar e construir todas as dependências relevantes das Appchains, produzindo o Fluxo de Execução Cumprido, em que o Segmento de Execução Cumprido selecionado é isolado e armazenado no pool de Buffer da Unidade de Código (CUBP) , em que o CUBP é enviado ao
SM.
[69] 0 CUBP é processado em um loop (de cada Potencial
Unidade de Código) , em que o Mapa da hierarquia de finalidades de todo o CUBP e o Mapa da hierarquia de finalidades da unidade
Petição 870200056145, de 06/05/2020, pág. 45/1737
43/754 de código selecionada é submetido ao Processamento de Simetria de Propósito a Propósito (P2SP) , produzindo o resultado do processamento de simetria, em que a saida modular da instância P2SP correspondente é Resultado de Processamento de Simetria, cujo resultado é enviado como Entrada Modular para a validação de Resultado de Processamento de Simetria (SPRV), em que cada Instância de Detecção de Integração de Alinhamento (AID) é separada, em que um loop para cada AID e o resultado da instância é invocado, em que o Loop é realizado através de cada Propósito de Unidade de Código Desalinhado e deriva uma finalidade adequada por meio da invocação de Substituição de Propósito Adequado (SPR) que está em conformidade com o Mapa de Hierarquia de Propósito do Blueprint de Estrutura de Código, em que LIZARD é chamado para converter as Substituições de Finalidade Produzidas pela instância SPR correspondente nos Segmentos de Execução, em que cada Unidade de Substituição de Sintaxe está associada a seu lugar relevante no Blueprint da Estrutura de Código, em que LIZARD é chamado para converter Substituições de Finalidade em Segmentos de Execução, produzindo e enviando resultados para a Retenção de Unidade de Substituição de Sintaxe (SRUR), em que cada Unidade de Substituição de Sintaxe está associada ao seu lugar correspondente no código da Estrutura do Blueprint, em que a Pesquisa do Blueprint da Unidade (UBL) é chamada, em que a UBL produz sua saida para o Estrutura de Código de Processamento Otimizado (CSSP), que organiza os dados de entrada em uma saida Atualizada da Appchain, em que um Patch de Implantação, que contém as Unidades de Substituição de Sintaxe e Instruções para qual parte da Appchain eles substituirão, é criado.
Petição 870200056145, de 06/05/2020, pág. 46/1737
44/754
[70] A retenção de Objetivo de Unidade de Código Desalinhado (MCUPR) é enviada como entrada modular para o SPR, em que é iniciado um loop através de cada objetivo de unidade de código desalinhado de MCUPR, em que o LOM é invocado para produzir uma substituição de objetivo para a unidade de código desalinhado selecionada, que é congruente e compatível com o Blueprint da Estrutura de Código, em que a Substituição de Propósito individual dentro do Loop é processada pela LIZARD.
[71] O Blueprint da Estrutura de Código, a Unidade de Código Desalinhado e os Princípios de Design de Conformidade são fornecidos como entrada inicial ao Prompt de Invocação de Substituição (RIP) , em que o RIP produz um Prompt que interage diretamente com o LOM para invocar a Produção do Substituto de Propósito, levando em consideração a entrada do Critério Modelo de Estrutura de Código, Unidade de Código Desalinhado e Princípios de Conformidade de Design, em que o Prompt é enviado ao módulo IQR (LM) , em que esta instância do LOM é automaticamente invocada pelo RIP, em que o Prompt fornecido é analisado via Invocação de Retenção de Conhecimento Central (CKR) para decifrar detalhes ausentes do prompt que são cruciais para concluir o entendimento virtual correto pelo LOM, em que os detalhes ausentes resultantes produzidos pelo IQR são enviados como entrada modular para o Esclarecimento de Pesquisas (SC), em que o SC se envolve com o origem do prompt para recuperar informações suplementares, em que a versão totalmente formada e refinada de o Prompt é produzida a partir do SC e enviada como entrada modular a Construção de Asserção (AC) , em que o AC tenta formar uma resposta coerente ao Prompt referenciando a CKR diretamente e
Petição 870200056145, de 06/05/2020, pág. 47/1737
45/754 também pelo Mapeamento Hierárquico (HM).
[72] 0 AC Fornece uma Apresentação de Resposta ao Apelo Racional (RA), em que a asserção produzida é enviada diretamente ao CTMP como uma entrada de Opinião subjetiva, e também a Construção de Contexto (CC), que fornece a entrada de Fato Objetivo ao CTMP, em que o CC faz referência a Metadados de AC e Evidência Potencial Fornecida via RIP para enviar Fatos Brutos ao CTMP, em que os Metadados de Entrada são representados pelo arquivo de Agregação de Registros LOM, que contém uma coleção de arquivos de Log relevantes produzidos a partir das principais funções operacionais da LOM. Após a conclusão do CTMP em operação, uma decisão pós-critica é produzida como saída modular, em que a decisão pré-crítica inicial e a decisão pós-critica são submetidas à Comparação de Decisões (DC), que determina o Escopo da Potencial Sobreposição entre as duas entradas, em que a Saída Unificada fornecida pelo DC pode indicar a Concessão do CTMP ou uma melhoria percebida em seu nome, em que as Respostas a Argumentos podem ser classificadas como Outros Resultados de Baixa Confiança ou Resultados de Alta Confiança, nos quais as saídas modulares produzidas IQR, SC, AC, Mapeamento Hierárquico (HM) e Validação de Conhecimento (KV) são submetidas a Coleta de Registros Modulares LOM (LMLC), em que a LMLC combina os dados do log de entrada em um único arquivo legível referido como Agregação de Registros LOM.
[73] A Decisão Pré-Crítica é apresentada como Saída Modular do CA, em que a Decisão é marcada como uma Opinião Subjetiva, em que a Opinião Subjetiva é submetida aos Metadados do Sistema de Entrada, que atua como a Entrada Modular Primária
Petição 870200056145, de 06/05/2020, pág. 48/1737
46/754 para o CTMP e uma representação interna do Algoritmo de Correspondência de Padrão Selecionado (SPMA), em que para esta configuração de instância; o SPMA é LOM, em que os Metadados do Sistema de Entrada são submetidos para processamento no Motivo do Processamento e na Produção de Percepção Bruta (RP2), em que o Motivo do Processamento entenderá logicamente as asserções feitas comparando atributos de propriedade, em que a RP2 analisa os metadados do sistema de entrada do LOM para produzir uma percepção no Formato Complexo de Percepção (PCF) que representa a percepção algorítmica do LOM, em que a Percepção produzida é submetida ao Emulador de Observador da Percepção (POE), em que o Motivo do Processamento invoca o Processamento de regras, em que os resultados produzidos pelos dois ramos pensantes são transferidos a Saída de Decisão Crítica (CDO), que avalia quaisquer elementos fundamentais de conflito ou corroboração entre os resultados.
[74] 0 LOM produz a Substituição de Propósito invocando AC, em que a Substituição de Propósito é enviada a RP2 que descompacta os dados para produzir instâncias de um Rastreio de Depuração e Rastreio de Algoritmo nos Metadados do Sistema de Entrada que se origina da instância AC correspondente, em que o Rastreio de Depuração é um código rastreio de nível que fornece variáveis, funções, métodos e classes que são usadas junto com o tipo e conteúdo de variável correspondente a entrada e saída, em que o Rastreamento de Algoritmo é um rastreamento em nível de software que fornece dados de segurança juntamente com a análise de algoritmos, em que a decisão de segurança resultante é fornecida juntamente com uma trilha logística de como chegou à
Petição 870200056145, de 06/05/2020, pág. 49/1737
47/754
Decisão, em que a RP2 transfere os dados referentes ao resultado da percepção produzida para o Emulador de Observador da Percepção (POE) para processamento.
[75] A Operação de Processamento Métrico e a Separação de Metadados do Sistema (SMS) leva à produção de percepções, que representam a resposta modular da LOM de produzir a substituição de finalidade por AC, em que a RP2 produz um ponto de dados de formato variável comparável que é alimentado na Pesquisa de Armazenamento (SS) como critérios de pesquisa, em que a SS executa uma pesquisa no Armazenamento de Percepção (PS) para encontrar correspondências com as percepções já existentes armazenadas no PS, em que são produzidos os resultados da execução da SS, o que leva a um cálculo de peso, que tenta encontrar a distribuição correta dos Percepções Correspondentes do PS para replicar e corresponder ao formato de variável comparável, que representa a execução do algoritmo LOM que produziu a substituição de finalidade.
[76] 0 Processo da Memória na Web opera em paralelo com a execução do POE, em que a Substituição de Propósito produzida pela LOM é submetida como entrada modular ao Motivo do Processamento que processa como a LOM alcançou a decisão de produzir a Substituição de Propósito em resposta ao Prompt Fornecido pelo RIP, em que a conclusão do processamento do Motivo do Processamento define as regras que são consistentes com o comportamento de execução da LOM, em que se alguma inconsistência for encontrada no comportamento da regra em relação ao comportamento de execução da LOM, as regras existentes no momento serão modificadas ou novas regras serão adicionadas, em que o
Petição 870200056145, de 06/05/2020, pág. 50/1737
48/754
Extensor de Escopo de regra Critica (CRSE) utiliza as percepções conhecidas para expandir o escopo de 'pensamento critico' dos conjuntos de regras, aprimorando os conjuntos de regras para produzir Regras Corretas enviadas como entrada modular para a Separação do Formato da Sintaxe da Regra (RSFS) de dentro da jurisdição operacional da Memória na Web, em que a RSFS separa e organiza as regras corretas por tipo, em que a Análise de Campo Caótico (CFP) combina e formata a Agregação de Registros LOM em uma única unidade digitalizável referida como Campo Caótico, em que o Campo Caótico é submetido como entrada modular ao Reconhecimento de Memória (MR), em que o MR também recebe as Regras Originais que são as resultado da execução da RSFS, em que o MR varre o Campo Caótico fornecido pela CFP para reconhecer conceitos conheciveis definidos nas Regras Originais.
[77] 0 PS Contém Quatro subconjuntos de Percepções: Ângulos de Percepção Desconhecidos Deduzidos, Todos os Ângulos de Percepção, Ângulos de Percepção Implícitos e Ângulos de Percepção Aplicados, em que os Ângulos de Percepção Aplicados são importados diretamente pelo estudo do comportamento algorítmico do Algoritmo de Correspondência de Padrões Selecionados (SPMA), em que os ângulos de percepção implícitos são derivados de ângulos de percepção aplicados por meio da execução modular de implicações.
[78] Derivação (ID) e APDM, em que Todos os Ângulos de Percepção representam todo o escopo de percepções conhecidas do CTMP que não foram incluídas por Ângulos de Percepção Aplicados e Ângulos de Percepção Implícitos, em que Ângulos de Percepção Desconhecidos Deduzidos representam o escopo de percepções que
Petição 870200056145, de 06/05/2020, pág. 51/1737
49/754 espera-se que exista ainda que o CTMP ainda não tenha descoberto de acordo com a Densidade de Conhecimento Autocritico (SCKD), em que o ID analisa as Métricas Individuais dos Ângulos de Percepção Aplicados para derivar deterministicamente Ângulos de Percepção Implícitos, enquanto o APDM varia criativamente composições dos Ângulos de Percepção por meio do Módulo de Criatividade para produzir uma Nova Iteração que combina os dois Pesos de entrada iniciais, em que todos os Ângulos de Percepção Envolvidos no processamento de APDM correspondem e representam a Substituição de Propósito Produzida pela AC.
[79] 0 Apelo Racional (RA) opera no LOM e chama a Construção de Contexto (CC) para processar o Agregado de Registro de LOM para o Análise de Campo Caótico (CEP) que produz um Campo Caótico a partir da saída modular do CC referenciada pelo Reconhecimento de Memória (MR), em que as Regras Atuais exibem conjuntos de regras que são indicativos do estado de funcionamento atual do Algoritmo de Correspondência de Padrão Selecionado (SPMA) , em que as Regras Atuais som enviadas como entrada modulares para a Derivação de Sintaxe de Regras (RSD), onde Regras Lógicas em Preto e Branco são convertidas em Métricas Percepções baseadas em que a saída do RSD é fornecida como entrada para a Correspondência de Percepção (PM) , em que no PM, uma unidade de formato variável comparável (CVF) é formada a partir da percepção recebida do RSD, em que o CVF recém-formado é usado para pesquisar informações relevantes nas Percepções no PS, em que as Correspondências Potenciais são enviadas como entrada modular para a geração de sintaxe de regras (RSG), em que o RSG recebe percepções confirmadas anteriormente, que são armazenadas
Petição 870200056145, de 06/05/2020, pág. 52/1737
50/754 no Formato de percepção e acessam a composição métrica interna da Percepção, em que as percepções são recebidas do PS que contém Percepções Previamente Confirmadas, em que essas medidas de métricas baseadas em gradiente são convertidas em Conjuntos de Regras Lógicas e Binárias que emulam o fluxo de informações de entrada/saida da percepção original, em que, portanto, o RSG produz regras perceptivas que são consideradas relevantes, populares e foram convertidas em regras lógicas, em que se uma percepção tiver muitas relações métricas complexas que definem muitas 'áreas cinzentas', as regras locais 'Preto e Branco' abrangem essas 'cinzas' áreas expandindo a complexidade do conjunto de regras, em que as regras perceptivas são armazenadas por uma coleção de definições de Regra de Sintaxe de Regras (RSI), em que as regras perceptivas são enviadas como entrada para o MR, onde são digitalizadas no campo caótico produzido pelo CFP, em que o MR produz regras extras que completam as regras corretas em sua validade.
[80] Os Ângulos de Percepção Aplicados do PS são enviados como entrada ao ID para produzir mais Percepções que pertencem aos Ângulos de Percepção Implícitos, em que os Ângulos de Percepção Aplicados são enviados especificamente para a Combinação Métrica do ID, em que a Combinação Métrica separa os Ângulos de Percepção recebidos em categorias de métricas: Escopo, Tipo, Consistência, Intensidade, em que os Ângulos de percepção de entrada estão relacionados à Substituição de Propósito produzida pela AC, em que o Conjunto de Complexidade Métrica A é enviado como entrada para Expansão Métrica (ME), em que com ME, as métricas de múltiplos e variados ângulos de percepção são
Petição 870200056145, de 06/05/2020, pág. 53/1737
51/754 armazenadas categoricamente, em que o ME aprimora o lote atual de métricas recebidas com detalhes/complexidade extraídos de métricas conhecidas/encontradas anteriormente, em que após a conclusão do aprimoramento e aprimoramento da complexidade, as métricas são retornadas como saída do ME como Complexidade da métrica Defina B e, posteriormente, convertido novamente em Ângulos de percepção para ser armazenado nos Ângulos de percepção Implícitos.
[81] 0 Resultado de Decisões Críticas (CDO) do CTMP recebe o output do POE e RE, em que cada agência envia sua respectiva decisão crítica, além de corresponder os metametadados, que fornecem variáveis contextuais que justificam por que a decisão crítica inicial foi alcançada, em que os dois conjuntos de decisões que representam as percepções de POE e as regras cumpridas de ER são enviadas ao Módulo de Categorização de Metadados (MCM), que separa os rastreamentos de depuração e algoritmo em categorias distintas usando a categorização de informações tradicional baseada em sintaxe, em que a Comparação de Decisão da Lógica de Processamento interno da Direção (DDC) verifica se há confirmação ou conflito entre a Decisão Intuitiva e a Decisão Pensante, em que o Controle De saída do Terminal (TOC) inicia com o Prompt, que verifica se o DDC foi capaz de fornecer uma Saída Final da Decisão, em que se a resposta ao Prompt for Sim, então a decisão final combinada fornecida pelo DDC no resultado final da decisão é enviada como resultado do TOC, em que se a resposta ao Prompt for Não, o PM é executado para buscar os resultados correspondentes, em que Regras Cumpridas são extraídas da Decisão Crítica + Meta-metadados do
Petição 870200056145, de 06/05/2020, pág. 54/1737
52/754
ER, em que as Regras são convertidas em Percepções por Derivação de Sintaxe de Regra (RSD) , em que o PM faz referência a metametadados para determinar se houve uma forte sobreposição interna e corroboração das percepções usadas.
[82] A Substituição de Propósito existe em Formato de Propósito Complexo e é submetida à Expansão Iterativa do PM, em que a Expansão Iterativa adiciona detalhes e complexidade para evoluir uma meta simples (definida indiretamente na Substituição de Propósito) em uma definição de finalidade complexa específica pela qual o potencial máximo da Associação de Propósito a entrada é realizada e mantida como um formato de finalidade complexa, antes de ser submetida à derivação lógica do SM, em que o elemento do código principal do IC contém elementos fundamentais
[83] Estruturas e Bibliotecas, Scripts de Gerenciamento de Encadeamento e Balanceamento de Carga, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória, permitindo a operação e funcionalidade gerais para SM e PM, em que os objetivos do sistema do IC definem a política de segurança e os objetivos da empresa.
[84] Em relação à operação e funcionalidade da Pesquisa de Projeto de Unidade (UBL) da IEC, é recebida a entrada da Retenção de Unidade de Substituição de Sintaxe (SRUR), portanto, iniciou um Loop que percorre todas as Unidades de Substituição de Sintaxe, em que o ID da Unidade de Código Associado é descompactado a Unidade de Substituição da Sintaxe, em que em um encadeamento paralelo separado na mesma instância do UBL o Blueprint da Estrutura de Código é enviado como entrada e o Blueprint da Estrutura de Código é instalado na Nova Retenção de
Petição 870200056145, de 06/05/2020, pág. 55/1737
53/754
Blueprint da Estrutura de Código (NCSBR), em que o status Cumprido da Execução os segmentos são revertidos por meio do Estrutura de Código Simplificar o Processamento (CSSP) produzindo na Appchain atualizada como saída, que representa a estrutura sintática original, mas com as Unidades de código desalinhadas substituídas por substituições de finalidade adequada, em que a Appchain atualizada é submetido ao Conjunto de Patches de Implantação (DPA) para produzir o patch de correção a Appchain, em que a Appchain de destino é processada pela execução do Fluxo de Coleção (ESC), portanto, envia o Fluxo de Coleção original ao DPA, permitindo que o DPA tenha acesso a Appchain de destino em sua forma original, em que o Patch de Correção da Appchain é implantado no Construtor de Ecossistemas de Customchain(CEB), que manipula a Appchain de destino para que ela se converta em conteúdo para a Appchain atualizada.
[85] Em relação à operação interna do LOM e do CTMP em relação ao Proteção da segurança da Appchain (ASH), a Teoria de Segurança, Informações de Segurança Não Confirmadas e Conhecimento de Segurança Confirmado são fornecidos como entrada inicial para o Prompt de Invocação de Dedução (DIP) que produz um Prompt que interage diretamente com a LOM para invocar a produção da Asserção de Segurança Confiável, levando em consideração os critérios de entrada Teoria de Segurança, Informações de Segurança Não Confirmadas e Conhecimento de Segurança Confirmado, em que o Prompt é enviado ao Raciocínio Inicial da Consulta (IQR), em que o Prompt fornecido é analisados por meio da invocação da Retenção Central de Conhecimento (CKR), em que os Detalhes Ausentes resultantes produzidos pelo IQR são
Petição 870200056145, de 06/05/2020, pág. 56/1737
54/754 enviados como entrada para o Esclarecimento da Pesquisa (SC), que se engaja com a origem do Prompt para Recuperar Informações Suplementares, a SC se envolve com o DIP para Recuperar Informações Suplementares referentes ao Prompt, em que a versão refinada do Prompt é produzida a partir de SC e enviado como entrada ao AC que tenta formar uma resposta coerente ao Prompt referenciando CKR diretamente e também via Mapeamento Hierárquico (HM), em que o RA usa o CTMP para criticar asserções na forma de autocríticas ou críticas externas à origem da pergunta/afirmação processada pelo IQR, em que se uma afirmação produzida a partir do CA falhar, uma medida significativa do teste de autocrítica e processado pelo RA; então, uma nova instância do AC é invocada para dar conta de quaisquer críticas válidas, em que se uma declaração de alta confiança for produzida pelo AC que passe consistentemente nos Testes de Autocrítica Processados pelo RA, a asserção é produzida como saída da LOM, referenciada como a Asserção de Segurança Confiável no contexto do prompt inicial fornecido pelo DIP.
[86] No que diz respeito ao procedimento operacional interno da AR em relação à ASH, a AC fornece uma Apresentação de resposta à RA referente à afirmação produzida pela AC em relação ao Prompt de Entrada Correspondente, a afirmação produzida é enviada diretamente ao CTMP como uma entrada de Opinião Subjetiva, e também para Construção de Contexto (CC), que fornece a entrada de Fato Objetivo para o CTMP, em que CC faz referência a metadados do CA e evidências potenciais fornecidas por RIP para enviar fatos brutos ao CTMP para um pensamento crítico, em que esses Metadados de Entrada são representados pelo arquivo
Petição 870200056145, de 06/05/2020, pág. 57/1737
55/754
Agregado de Registro LOM, em que as saídas produzidas pelo Raciocínio Inicial da Consulta (IQR) , SC, AC, HM e KV são enviadas para a Coleta de Registros Modulares LOM (LMLC) que combina os dados do Log de Entrada em um único arquivo legível referido como Agregado de Registro LOM, enviado ao CC do Apelo Racional (RA).
[87] No que diz respeito à invocação de RP2 no CTMP, o LOM produz uma Asserção de Segurança Confiável chamada AC, em que a Asserção de Segurança Confiável é então enviada ao RP2, que descompacta os dados para produzir instâncias de um Rastreio de Depuração e Rastreio de Algoritmo nos Metadados do Sistema de Entrada originados em a instância AC correspondente, em que o Processamento Métrico faz a engenharia reversa das variáveis do LOM para extrair percepções da inteligência artificial exibida pelo LOM, em que posteriormente os metadados do sistema de entrada são separados em relacionamentos significativos de causaefeito de segurança pela Separação de Metadados do Sistema (SMS).
[88] A Substituição de Propósito produzida pela LOM e o Agregado de Registro LOM correspondente é submetida à Análise de Dados, o que faz com que os Logs Avançados de Dados sejam derivados, aplicados no Aplicativo para obter uma Dicotomia de Interpretação de um Sentimento Positivo (Aprovar) ou Sentimento Negativo (Bloquear) com relação ao Substituição de Finalidade De entrada, em que a Conclusão bem-sucedida da Execução do Aplicativo leva a uma ação corretiva de substituição que é processada pela Saída de Decisão Crítica (CDO) em paralelo à saída modular da Execução de Regras (RE) , em que Densidade do Conhecimento Autocrítico (SCKD) estima o escopo e o tipo de conhecimento desconhecido potencial que está além do alcance do
Petição 870200056145, de 06/05/2020, pág. 58/1737
56/754
Agregado de log LOM Reportável.
[89] Em relação à interação do fluxo lógico entre o PS e o Mecanismo de Descoberta de Percepção Automatizada (APDM), o PS contém quatro subconjuntos de percepções: Ângulos de Percepção Desconhecidos Deduzidos, Todos os Ângulos de Percepção, Ângulos de Percepção Implícitos e Ângulos de Percepção Aplicados, em que Ângulos de Percepção Aplicados são importados diretamente pelo estudo do comportamento algorítmico do SPMA, os Ângulos de Percepção Implícitos são derivados de Ângulos de Percepção Aplicados por meio da execução de Derivação de Implicação (ID) e APDM, em que Todos os Ângulos de Percepção representam todo o escopo de percepções conhecidas do CTMP que não foram incluídos por Ângulos de Percepção Aplicados e Ângulos de Percepção Implícitos, em que os Ângulos de Percepção Desconhecidos Deduzidos representam o escopo das percepções que se espera que existam ainda que o CTMP ainda não tenha descoberto de acordo com a SCKD, em que o ID analisa as métricas individuais dos Ângulos de Percepção Aplicados para derivar deterministicamente os Ângulos de Percepção Implícitos, enquanto APDM cria as composições de dos Ângulos de Percepção através do Módulo de Criatividade para produzir uma nova iteração que combina os dois pesos iniciais de entrada pelos quais todos os Ângulos de Percepção Envolvidos no processamento do APDM correspondem e representam a asserção de segurança confiável produzida pelo AC da LOM.
[90] O Apelo Racional (RA) opera no LOM e chama a Construção de Contexto (CC) para processar o Agregado de Registro LOM para o Análise de Campo Caótico (CEP) que produz um Campo
Petição 870200056145, de 06/05/2020, pág. 59/1737
57/754
Caótico a partir da saída modular do CC referenciada pelo Reconhecimento de Memória (MR), em que as Regras Atuais exibem conjuntos de regras que são indicativos do estado de funcionamento atual do Algoritmo de Correspondência de Padrão Selecionado (SPMA) , em que as Regras Atuais som enviadas como entrada modulares para a Derivação de Sintaxe de Regras (RSD), onde Regras Lógicas em Preto e Branco são convertidas em Métricas Percepções baseadas em que a saída do RSD é fornecida como entrada para a Correspondência de Percepção (PM) , em que no PM, uma unidade de formato variável comparável (CVF) é formada a partir da percepção recebida do RSD, em que o CVF recém-formado é usado para pesquisar informações relevantes nas Percepções no PS, em que as Correspondências Potenciais são enviadas como entrada modular para a geração de sintaxe de regras (RSG), em que o RSG recebe percepções confirmadas anteriormente, que são armazenadas no Formato de percepção e acessam a composição métrica interna da Percepção, em que as percepções são recebidas do PS que contém Percepções Previamente Confirmadas, em que essas medidas de métricas baseadas em gradiente são convertidas em Conjuntos de Regras Lógicas e Binárias que emulam o fluxo de informações de entrada/saída da percepção original, em que, portanto, o RSG produz regras perceptivas que são percepções consideradas relevantes, populares e foram convertidas em regras lógicas, em que as regras perceptivas são armazenadas por uma coleção de Definições de Formato de Sintaxe de Regras (RSF) , em que as regras perceptivas são enviadas como entrada para o reconhecimento de memória (MR), onde são digitalizadas no campo caótico que foi produzido pela CFP, pelo qual a MR produzindo
Petição 870200056145, de 06/05/2020, pág. 60/1737
58/754
Regras Extra que completam as Regras Corretas em sua validade.
[91] Em relação ao ID do CTMP, os Ângulos de Percepção Aplicados do PS são enviados como entrada para o ID para produzir mais Percepções que pertencem aos Ângulos de Percepção Implícitos, em que os Ângulos de Percepção Aplicados são enviados especificamente para a Combinação Métrica do ID, em que a Combinação Métrica separa os Ângulos de Percepção recebidos em categorias de métricas: Escopo, Tipo, Consistência, Intensidade, em que os Ângulos de Percepção de entrada estão relacionados à Substituição de Propósito produzida pela AC.
[92] 0 CDO recebe saída modular dos dois principais ramos do CTMP: POE e RE, em que cada ramo envia sua respectiva decisão crítica, bem como os meta-metadados correspondentes, em que ambos os conjuntos de decisões são submetidos ao Módulo de Categorização de Metadados (MCM) que separa a depuração e Algoritmo Rastreia em categorias distintas usando a categorização de informações tradicional baseada em sintaxe.
[93] Em relação à operação do LIZARD para converter os Regulamentos e Diretrizes do Sistema em um Mapa de Hierarquia de Propósito, os Regulamentos e Diretrizes do Sistema são enviados da LUIGI para SM, em que os Regulamentos e Diretrizes do Sistema são recebidos no formato do Fluxo de Dados AO pela Tradução de Código que converte código arbitrário para a linguagem de computação escolhida e, portanto, executa a função inversa de traduzir as linguagens de computação conhecidas em tipos de sintaxe arbitrários.
[94] 0 Mapa de Finalidade Atualizado existe no Formato de Finalidade Complexa e é submetido à Expansão Iterativa que
Petição 870200056145, de 06/05/2020, pág. 61/1737
59/754 adiciona detalhes e complexidade para evoluir uma meta simples para uma definição de finalidade complexa específica, em que os dados de entrada são recebidos no Formato de Finalidade Complexa da PM e são transferidos para Derivação Lógica de SM, em que PM invoca SM para produzir a versão resultante da sintaxe Appchain do mapa de finalidade atualizado de entrada pela Tradução de Código, em que a Appchain atualizada resultante da produção terminal da Tradução de Código é a saída modular de SM, Núcleo Externo e LIZARD.
[95] Com relação à operação do LIZARD para converter o conteúdo completo da Retenção de Log Relacionada a Erros (ERLR) em um Mapa de Hierarquia de Propósito, o conteúdo do ERLR é enviado ao SM, em que a Redução Lógica do SM envia sua saída para Interpretação Iterativa do PM, em que Interpretação Iterativa percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada, consultando Associações de Propósitos, em que a saída é rotulada como um mapa de hierarquia de finalidades, que é apresentado como a versão do formato de finalidades complexas do ERLR.
[96] Com relação à operação do LIZARD para converter o Log de Erros Contextual! zados em um Mapa de Hierarquia de Propósito, o Log de Erros Contextual!zados é enviado ao SM, em que a Redução Lógica do SM envia sua saída para Interpretação Iterativa do PM, em que a Interpretação Iterativa faz um loop através de todas as funções interconectadas para produza uma definição de finalidade interpretada consultando Associações de Propósitos, em que a saída é rotulada como um Mapa de Hierarquia de Propósitos, que é apresentada como a versão de Formato de
Petição 870200056145, de 06/05/2020, pág. 62/1737
60/754
Propósitos Complexos do Log de Erros Contextualizados.
[97] Com relação à operação do LIZARD para converter o Segmento de Execução Refinado em um Mapa de Hierarquia de Propósito, o Segmento de Execução Refinado é enviado ao SM, em que a Redução Lógica do SM envia sua saida para Interpretação Iterativa do PM, em que a Interpretação Iterativa faz um loop através de todas as funções interconectadas para produzir uma definição de finalidade interpretada consultando Associações de Propósitos, em que a saida é rotulada como um Mapa de Hierarquia de Propósitos, que é apresentada como a versão do Formato de Propósitos Complexos do Segmento de Execução Refinado.
[98] Com relação à operação do LIZARD para converter todo o ecossistema Customchain da plataforma UBEC em um mapa de hierarquia de finalidades, a plataforma UBEC é submetida ao SM, em que a Redução Lógica do SM envia sua saida para Interpretação Iterativa do PM, em que a Interpretação Iterativa circula por todos os interconectados funciona para produzir uma definição de finalidade interpretada consultando Associações de Propósitos, em que a saida é rotulada como um Mapa de Hierarquia de Propósitos, que é apresentada como a versão do Formato de Propósitos Complexos da Plataforma UBEC.
[99] Em relação à operação do LIZARD para converter o Mapa de Hierarquia de Propósito em uma série de Faixas de Propósito, o Mapa de Hierarquia de Propósito existe em Formato de Propósito Complexo e é submetido à Expansão Iterativa do PM, em que a Expansão Iterativa adiciona detalhes e complexidade para transformar um objetivo simples em um definição de finalidade complexa especifica pela qual o potencial máximo de associação
Petição 870200056145, de 06/05/2020, pág. 63/1737
61/754 de finalidade da entrada é realizado e retido como um formato de finalidade complexa, antes de ser submetido à Derivação lógica do SM, em que os dados de entrada são recebidos no formato de finalidade complexa da MP e são transferidos para Derivação lógica de SM, em que Derivação lógica deriva funções logicamente necessárias de funções inicialmente mais simples, em que o resultado produzido é uma árvore de dependências de funções que são construídas de acordo com os dados definidos no formato de finalidade complexa.
[100] Com relação à operação do LIZARD para converter as Novas Alterações Propostas em um Mapa de Hierarquia de Propósito, a Plataforma UBEC é submetida ao SM, em que a Redução Lógica do SM envia sua saída para Interpretação Iterativa do PM, em que a Interpretação Iterativa circula por todas as funções interconectadas para produzir um definição de finalidade interpretada consultando Associações de Propósitos, em que a saída é rotulada como um Mapa de Hierarquia de Propósitos, que é apresentada como a versão do Formato de Propósitos Complexos das Novas Alterações Propostas.
[101] Em relação à operação do LIZARD para converter os Princípios de Projeto do Sistema em um Mapa de Hierarquia de Propósito, os Princípios de Projeto do Sistema são submetidos ao SM, em que a Redução Lógica do SM envia sua saída para Interpretação Iterativa do PM, em que a Interpretação Iterativa faz um loop através de todas as funções interconectadas para produzir um definição de finalidade interpretada consultando Associações de Propósitos, em que a saída é rotulada como um Mapa de Hierarquia de Propósitos, que é apresentada como a versão do
Petição 870200056145, de 06/05/2020, pág. 64/1737
62/754
Formato de Propósitos Complexos dos Princípios de Projeto do Sistema.
[102] Com relação à operação do LIZARD para converter Jurisdições Appchain em um Mapa de Hierarquia de Propósito, as Jurisdições Appchain são submetidas ao SM, em que a Redução Lógica do SM envia sua saída para Interpretação Iterative do PM, em que a Interpretação Iterative faz um loop através de todas as funções interconectadas para produzir um propósito interpretado definição, referindo-se a Associações de Propósitos, em que a saída é rotulada como um Mapa de Hierarquia de Propósitos, que é apresentada como a versão do Formato de Propósitos Complexos das Jurisdições da Appchain.
[103] Com relação à operação do LIZARD para converter o Mapa de Finalidade Atualizado em Novas Alterações Propostas, o Mapa de Finalidade Atualizado existe no Formato de Finalidade Complexa e é submetido à Expansão Iterative do PM, em que os dados de entrada são recebidos do PM e são transferidos para a Derivação Lógica da SM, em que a Derivação lógica deriva funções logicamente necessárias a partir de funções inicialmente mais simples e o resultado produzido é uma árvore de dependências de funções que são construídas de acordo com os dados definidos no formato de finalidade complexa, em que o PM chama SM para produzir a versão resultante da sintaxe da Appchain da entrada Atualizada para o Mapa Finalidade pela Tradução do Código.
[104] No que diz respeito à operação do LIZARD para converter Appchains para Criar em uma Camada Logística, em que as Appchains para Criar é enviada ao SM, em que a Redução Lógica do SM envia sua saída para Interpretação Iterative do PM, em que
Petição 870200056145, de 06/05/2020, pág. 65/1737
63/754
Interpretação Iterative circula todas as funções interconectadas para produzir uma Finalidade Interpretada, referindo-se a Associações de Propósito, em que a saida é rotulada como uma Camada de Logística, que é apresentada como a Versão de Finalidade Complexa das Appchains para Criar e ainda codificado em um formato de Camada de Logística, em que a camada de logística é um arranjo macro da sintaxe, enquanto o formato de Finalidade Complexa define o micro arranjo da sintaxe.
[105] Com relação à operação do LIZARD para converter o Mapa OC3 em um Mapa de Sintaxe da Appchain, o Mapa OC3 existe no Formato de Propósito Complexo e é submetido à Expansão Iterative do PM, em que a Expansão Iterative adiciona detalhes e complexidade para transformar um Objetivo Simples em um Objetivo Complexo Específico, em que os dados de entrada são recebidos no Formato de Propósito Complexo da PM e são transferidos para Derivação Lógica do SM, em que a Derivação lógica deriva funções logicamente necessárias de Funções Inicialmente Mais Simples e o resultado produzido é uma Árvore de Dependências de Funções que são criadas de acordo com o dados de Formato de Finalidade Complexa Definidos, em que a unidade resultante do mapa de sintaxe da Appchain que é produzida terminalmente pela Tradução de código é a saída modular de SM, OC e o LIZARD.
[106] Com relação à operação do LIZARD 120 para converter a Appchain cumprida no mapa de hierarquia de finalidades, a Appchain cumprida é submetida à SM, em que a Redução Lógica da SM envia sua saída para Interpretação Iterative do PM, em que a saída é rotulada como uma Camada de Logística, apresentada como a Versão de Formato de Finalidade Complexa da
Petição 870200056145, de 06/05/2020, pág. 66/1737
64/754
Appchain Concluídos.
[107] Em relação à operação LOM e CTMP em relação a Nova Appchain de Desenvolvimento (NAD), os Princípios de Design Criativo, o Segmento de Mapa Selecionado e o Mapa OC3 são fornecidos como entrada inicial para o Prompt de Invocação de Variação Criativa (CVIP), que produz um Prompt que interage diretamente com o LOM para invocar a produção da asserção de segurança confiável, levando em consideração os critérios de entrada Teoria de Segurança, Informações de Segurança Não Confirmadas e Conhecimento de Segurança Confirmado, em que o Prompt é enviado ao módulo LQ de Raciocínio Inicial da Consulta (IOM), em que o Prompt é analisado por meio da invocação da Retenção Central de Conhecimento (CKR), em que os Detalhes ausentes resultantes produzidos pelo IQR são enviados como entrada modular ao Esclarecimento da Pesquisa (SC) que se envolve com a origem do prompt para recuperar informações suplementares, em que o SC se envolve com o DIP para recuperar informações suplementares relacionadas ao Prompt, em que a versão do Prompt do SC é enviada ao AC, que tenta formar uma resposta coerente ao Prompt Referenciando CKR diretamente e também pelo Mapeamento Hierárquico (HM) , em que o AC fornece uma Apresentação de Resposta ao RA referente à afirmação produzida pela AC, em que a afirmação produzida é classificada como uma Decisão Pré-Crítica, em que o CTMP produz uma decisão pós-crítica, em que a decisão pré-crítica inicial e a decisão pós-crítica são submetidas à comparação de decisões (DC), que determina o escopo da potencial sobreposição entre as duas entradas.
[108] As saídas modulares produzidas a partir de IQR,
Petição 870200056145, de 06/05/2020, pág. 67/1737
65/754
SC, AC, HM e KV são enviadas ao Coleção de Log Modular LOM (LMLC) que combina os dados do log de entrada em um único arquivo legível referido como Agregado de registro LOM, enviado ao CC do Apelo Racional (RA), em que a decisão pré-criticada é apresentada como saída modular da CA e marcada como uma opinião subjetiva, em que os metadados do sistema de entrada são submetidos para processamento no Motivo do Processamento e no RP2, em que o Motivo do Processamento entenderá logicamente as afirmações feitas comparando os atributos de propriedade e o RP2 analisam os metadados do sistema de entrada do LOM para produzir uma percepção no Formato Complexo de Percepção (PCF), que é submetida ao POE, em que o Motivo do Processamento invoca o Processamento de regras que eventualmente produz conjuntos de regras que refletem o algoritmo SPMA.
[109] No que diz respeito à operação do POE, a Operação de Processamento Métrico e Separação de Metadados do Sistema (SMS) leva à produção de Percepções, em que as Percepções resultantes representam a resposta da LOM de produzir a Substituição de Propósito via AC, em que RP2 produz um ponto de dados de Formato Variável Comparável que é alimentado no SS como critério de pesquisa, em que os resultados da execução do SS são produzidos, o que leva a um cálculo de peso que tenta encontrar a distribuição correta das percepções correspondentes do PS para replicar e corresponder ao formato variável comparável que representa a execução do LOM que produziu a Unidade de Potencial Criativo, em que o Cálculo de Peso é concluído para levar à Aplicação das Percepções para tomar uma decisão ativa de Aprovar ou Bloquear, em que a Unidade de Potencial Criativo produzida
Petição 870200056145, de 06/05/2020, pág. 68/1737
66/754 pela LOM e o Agregado de Log LOM correspondente são submetidos à Análise de Dados, o que faz com que os Logs Avançados de Dados derivados que são aplicados no Aplicativo para obter um In dicotomia de interpretação de um sentimento positivo (aprovar) ou sentimento negativo (bloquear) com relação à unidade de potencial criativo de entrada, em que após a conclusão bemsucedida da execução do aplicativo, leva a uma ação corretiva de substituição que é processada pelo CDO em paralelo à saída de RE, em que o SCKD estima o escopo e o tipo de conhecimento desconhecido potencial que está além do alcance do agregado de log LOM reportável.
[110]No que diz respeito ao processo de memória da Web que opera paralelamente à execução do POE, a Unidade de potencial criativo produzida pela LOM é enviada como entrada modular ao Motivo do Processamento que processa como a LOM alcançou a decisão de produzir a Unidade de potencial criativo em resposta ao Prompt fornecido por CVIP, em que o CRSE utiliza percepções conhecidas para expandir o escopo de 'pensamento crítico' dos conjuntos de regras, em que as regras corretas são submetidas ao Separação do Formato da Sintaxe da Regra (RSFS) dentro da jurisdição operacional da Memória da Web, em que o RSFS separa e organiza as regras corretas por tipo, em que a Análise de campo caótico (CFP) combina e formata o Agregado de Registro da LOM em uma única unidade digitalizável referida como o campo caótico que é submetido ao MR, em que o MR recebe as Regras Originais que são o resultado da execução do RSFS e verifica o campo caótico fornecido pelo CFP para reconhecer conceitos conhecíveis definidos nas Regras Originais que produzem Segmentos de Regras
Petição 870200056145, de 06/05/2020, pág. 69/1737
67/754
Reconhecidos, nos quais a RFP recebe as partes individuais de as Regras Originais que foram marcadas de acordo com o seu reconhecimento ou falta delas no Campo Caótico pela MR e RFP deduzem logicamente que conjunto de regras inteiro (a combinação de todas as suas partes) foi suficientemente reconhecido no Campo Caótico para processamento por mérito pelo ER, em que a conclusão da execução do ER leva a uma Ação Corretiva de Substituição processada pelo CDO em paralelo à saída do POE.
[111] Em relação à operação do LIZARD para converter Soluções Criativas Sintáticas em um Mapa de Hierarquia de Propósito, em que as Soluções Criativas Sintáticas são enviadas para SM, em que a Redução Lógica do Módulo de Sintaxe (SM) envia sua saída para Interpretação Iterativa do PM, em que Interpretação Iterativa circula por todos funções interconectadas para produzir uma definição de finalidade interpretada consultando Associações de Propósito, em que a saída é rotulada como uma Camada Logística, que é apresentada como a versão de Formato de Propósito Complexo das Soluções Criativas Sintáticas.
[112] Em relação ao Desenvolvimento aprimorado do framework (EDD), os Princípios de Design de Eficiência, Princípios de Design de Estabilidade e Mapa de Finalidade de Hardware são fornecidos como entrada inicial para o Prompt de Invocação de Dedução (DIP) que produz um Prompt, enviado ao IQR, em que o Prompt fornecido é analisados pela CKR para decifrar os Detalhes Ausentes do Prompt, em que os Detalhes Ausentes Resultantes são enviados ao SC que se engaja com a origem do prompt para recuperar informações suplementares, em que a versão
Petição 870200056145, de 06/05/2020, pág. 70/1737
68/754 do prompt produzido do SC é enviada ao CA que tenta formar uma resposta coerente ao Prompt referenciando CKR diretamente e também via HM.
[113] No que diz respeito à invocação de RP2 no CTMP, o LOM produz a Estrutura Ideal da Estrutura chamando AC, em que a Estrutura Ideal da Estrutura é então enviada ao RP2, que descompacta os dados para produzir instâncias de um Rastreio de Depuração e Rastreio de Algoritmo, em que o RP2 transfere os dados referentes ao resultado de percepção produzido para POE.
[114] Em relação ao ID do CTMP, os Ângulos de Percepção Aplicados do PS recebem ID para produzir mais Percepções que pertencem a Ângulos de Percepção Implícitos, em que a Combinação Métrica separa os Ângulos de Percepção recebidos em categorias de métricas, em que os Ângulos de Percepção de Entrada estão relacionados a Estrutura Ideal, em que o Conjunto de Métricas de Complexidade A é enviado como saída de ME, em que, após a conclusão do aprimoramento e enriquecimento da complexidade, as métricas são retornadas como saída do ME como Conjunto de Métricas de Complexidade B e, posteriormente, convertidas novamente em Ângulos de Percepção para serem armazenados em Ângulos Implícitos de Percepção, em que o Conjunto de Complexidade Métrica B C737 é processado pela Conversão Métrica, que reverte as Métricas Individuais em Ângulos de Percepção completos.
[115] Com relação à operação do LIZARD para converter a Interpretação da Estrutura do Framework Refinada em um Mapa de Propósito da Estrutura Ideal, a Interpretação da Estrutura do Framework Refinada é submetida ao SM, a Redução Lógica do SM
Petição 870200056145, de 06/05/2020, pág. 71/1737
69/754 envia sua saída para Interpretação Iterative do PM, em que a Interpretação Iterative faz um loop através de todas as Funções Interconectadas para produzir uma Definição de Finalidade Interpretada, referindo-se a Associações de Propósitos, em que a saída é rotulada como um Mapa de Objetivos da Estrutura Refinada.
[116] Em relação a Necessidade de Correspondência no Mapa (NMM), a instância do NMM é gerada para atender à operação do Desenvolvimento Aprimorado do Framework (EFD), em que, após a chamada do NMM, a Análise Inicial baixa cada ramo de jurisdição do Armazenamento para reter temporariamente para referência na instância do NMM em andamento, em que com Calcular Necessidades de Ramificação: de acordo com as definições associadas a cada ramificação, as necessidades são associadas ao seu departamento correspondente, em que o resultado do processamento de simetria é fornecido como um objetivo de entrada como entrada para o Algoritmo de Pesquisa do NMM, em que o Algoritmo de Pesquisa faz referência e pesquisa através do índice de Necessidades compilado, através do qual determinar se o Objetivo de Entrada define uma necessidade válida de acordo com os ramos de jurisdição inicialmente definidos em Desenvolvimento e Armazenamento de Acesso a Necessidades, em que a execução concluída do Algoritmo de Pesquisa por meio do índice de Necessidades produz uma resposta Aprovar/Bloquear enviada como saída modular do NMM e referenciado como o resultado da necessidade.
[117] No que diz respeito à invocação da Produção de Percepção Bruta (RP2) no CTMP, o LOM produz a Estrutura de Framework Ideal chamada AC, em que a Estrutura de Framework Ideal
Petição 870200056145, de 06/05/2020, pág. 72/1737
70/754 é então enviada ao RP2, que descompacta os dados para produzir instâncias de um Rastreio de Depuração, em que o RP2 transfere os dados referente ao resultado da percepção produzida para o POE .
[118] No que diz respeito à operação do LIZARD para converter a Configuração Ideal de Hardware em um Mapa de Hierarquia de Propósito, a Configuração Ideal de Hardware é enviada ao SM, em que a Redução Lógica do SM envia sua saída para Interpretação Iterativa do PM, em que a Interpretação Iterativa circula todas as funções interconectadas para produzir uma interpretação definição de finalidade, consultando as Associações de Propósitos, em que a saída é rotulada como Mapa de Hierarquia de Propósitos, que é apresentada como a versão de Formato de Propósito Complexos da Configuração de Hardware Ideal.
[119] Em relação à operação da Necessidade de Correspondência no Mapa (NMM) , o NMM é gerado para atender à operação do Middleware de Instrução Externa (EIM), em que a Análise Inicial baixa cada ramo de Jurisdição do Armazenamento para reter temporariamente para referência na instância do NMM em andamento, em que com Calcular Necessidades de Filial_ de acordo com as definições associadas a cada filial, as necessidades são associadas ao seu departamento correspondente, em que o Objetivo de entrada é fornecido como entrada para o algoritmo de pesquisa do NMM, em que o algoritmo de pesquisa faz referência e pesquisa no índice de Necessidade Compilado, determinando se o objetivo de entrada define uma necessidade válida de acordo com os ramos de jurisdição definidos inicialmente em Necessidade de Acesso ao Desenvolvimento e
Petição 870200056145, de 06/05/2020, pág. 73/1737
71/754
Armazenamento, em que o algoritmo de pesquisa produz uma resposta Aprovar/Bloquear, em que o resultado da necessidade é retornado novamente no processamento do EIM como prontidão para isolamento de instruções.
[120] Em relação à operação e funcionalidade da Camada de Emulação da Appchain (AEL) e produção de uma Pilha Précompilada de Aplicativos (PAS) pelo Processamento estático de Appchain (SAP), a SAP interpreta o conteúdo correspondente da Appchain, produz a retenção estática da Appchain e a envia ao PAS, em que a AEL é compilados e incorporados ao PAS, dando, portanto, autonomia à instância do PAS nos sistemas herdados, em que a Interpretação e Detecção do Sistema de Destino (TSID) da AEL é executada em um conjunto de instruções preliminarmente básico e procura detectar o sistema operacional, drivers de dispositivo e hardware do Sistema de Destino, em que a AEL invocaria o mecanismo de conversão adequado para executar o código complexo no Sistema de Destino, permitindo que a retenção estática da Appchain seja totalmente executada, em que a retenção contém os segmentos de dados e segmentos de execução da Appchain para a Appchain alvo, juntamente com outras Appchains direcionadas depende da operação.
[121] A SAP produz uma instância de retenção estática de Appchain que contém a Appchain de destino, em que a retenção estática da Appchain é submetida à Execução e Extração de Segmento de Dados (EDSE) da AEL, em que o EDSE é um módulo de contêiner para a chamada de Coleta de Fluxo de Execução (ESC) e para a chamada de Classificação de Fluxo de Dados (DSS), em que o Sistema de Destino é interpretado pelo módulo Interpretação e
Petição 870200056145, de 06/05/2020, pág. 74/1737
72/754
Detecção do Sistema de Destino (TSID) pela consideração da Coleção Estática de Bibliotecas do Sistema de Destino que define os conjuntos de instruções apropriados aplicáveis a vários tipos de Sistemas, em que o TSID produz o conjunto de instruções do Sistema de Destino, que permite que a Operação Interna da AEL envie as instruções computacionais corretas ao Sistema de Destino, em que a Tradução do segmento de execução (EST) é chamada para interpretar o conjunto de instruções do sistema de destino que, portanto, converte a sintaxe da Appchain nas instruções herdadas apropriadas, em que a Tradução do Segmento de Dados (DST) é chamada para interpretar o conjunto de instruções do sistema de destino que traduz a sintaxe da Appchain em os segmentos legados de dados apropriados, em que as saídas modulares do EST e DST são enviadas para a Unificação de Instruções Herdadas (LIU), que invoca uma instância ao vivo de Renderização de Fluxo de Execução (ESR) para renderizar a retenção estática da Appchain de acordo com o conjunto de instruções do sistema de destino definido.
[122] Com relação à operação do Middleware de Instrução Externa (EIM), a operação da Retenção Estática da Appchain na instância ESR da Unificação de Instruções Herdadas (LIU) faz com que o LIU produza a Proposição de Instrução Externa e o índice de Prontidão de Isolamento da Instrução como saída modular, em que as Saídas são enviadas ao EIM, em que LIZARD é chamado para converter a Proposição de Instrução Externa em um Mapa de Hierarquia de Propósito, em que o Processamento de Realinhamento de Propósito (PRP) é chamado para entradas modulares Coleção de Propósito de Instrução e Mapa de Hierarquia de Propósito, em que
Petição 870200056145, de 06/05/2020, pág. 75/1737
73/754
Afinidade de Mestre/Escravo define a Coleção de Propósito de Instrução como Escravo, em que o PRP produz a nova iteração da Instrução Finalidade da Instrução, em que o LIU é invocado para produzir uma Instrução de Prontidão de Isolamento através da Necessidade de Correspondência de Mapa (NMM), em que a variável Prontidão define se a Finalidade da Instrução é suficientemente isolada dentro do Destino Sistema a ser executado sem interferência de sintaxes de execução alternativas, em que o Prompt é ativado para avaliar se a Variável Prontidão de Isolamento da Instrução indica que a Coleta de Propósitos de Instrução pode ser implantada no Sistema de Destino, em que se a resposta ao Prompt para Implantação Não está Pronto, então a Etapa será ativada que suspende a execução do EIM até que a próxima Proposição de Instrução externa seja produzida pelo ESR via LIU, em que se a Resposta ao Prompt estiver pronta para implantação, o LIZARD será chamado para converter a Coleção de Fins de Instrução na Sintaxe Correspondente Definida pelo TSID.
[123] Em relação à operação do SAP, uma coleção de Appchain proposta é produzida a partir da interface administrativa, em que as coleções de execução e segmento de dados são produzidas a partir das referências da coleção de Appchain proposta, em que a coleção de Appchain proposta é processada pelo ESR a partir do Ambiente de Captura Modificado (MCE), que é um Ambiente de Execução Personalizado que instala pontos de acionamento para vários eventos, para que as informações de dependência e depuração possam ser derivadas da sessão de execução, em que o Atendimento de Solicitações de Dependência (DRF) é invocado no SAP em conjunto com o MCE, em
Petição 870200056145, de 06/05/2020, pág. 76/1737
74/754 que uma Solicitação de Execução ou Dados é feita pelo ESR, em que as Coleções de Segmentos de Execução e Dados são avaliadas para determinar se a Solicitação de Execução ou Dados feita pelo ESR existe em tais Coleções, em que se a resposta ao Prompt for Existir, será solicitado o Prompt que avaliará se a execução ou segmento de dados correspondente for justificado de acordo com o NMM.
[124] A coleção proposta do Appchain é enviada separada em referências independentes da Appchain que são armazenadas posteriormente na Retenção de Cache de Referência da Appchain (ARCR) , em que um loop que percorre todas as instâncias da
Appchain no ARCR é gerado, em que a instância da Appchain selecionada é recuperada de um nó de cache relevante da rede BCHAIN e via protocolo BCHAIN, em que a instância da Appchain cumprida é produzida e processada por meio de invocações de ESC e DSS.
[125] É produzido um Pedido de Reivindicação de Conteúdo (CCR) com um Caminho de Linha de Base Proposto (PBHP), em que o CCR é enviado na Rede BCHAIN para que eventualmente atinja um Nó de Cache correspondente que contenha partes da Instância Appchain solicitada, em que o Nó de Cache atende o CCR, sendo assim compensado economicamente via Protocolo BCHAIN e aproveitando a Economia de Watt da Metachain, em que o Nó do Cache produz uma unidade correspondente de Realização de Reivindicação de Conteúdo (CCF) em resposta ao CCR correspondente, em que o CCF recémproduzido viaja ao longo do Rede BCHAIN para alcançar o módulo de Renderização de Reivindicação de Conteúdo (CCR) do Nó que está processando a instância do SAP, em que as Instruções de
Petição 870200056145, de 06/05/2020, pág. 77/1737
75/754
Decodificação de Conteúdo são referenciadas para renderizar a resposta do CCF, que gera a instância do Appchain cumprida.
[126] Em relação ao DRE no SAP, a resposta Não existe ao Prompt para a verificação se a Execução ou o Segmento de Dados correspondente é Justificado de acordo com o NMM, em que se a resposta Justificada ao Prompt ocorrer, o segmento de Execução ou Dados é marcado para inclusão no Cache do Segmento Marcado Retenção (MSCR), em que a Resposta Não Existe e a Resposta Não Justificada gera e envia uma Unidade de log de Diagnóstico (DLU) que contém um Token oficial do sistema, em que o Token é incluído para indicar que a função ou programa correspondente alcançou um estado não ideal se uma função oficial dentro da Plataforma da UBEC, em que a DLU é enviada ao DLS, que é invocada pelo ARM para fornecer DLU ao SPSI, pelo qual o SPSI é capaz de processar as informações de diagnóstico encontradas na DLU com o DLUA.
[127] 0 SAP é invocado por um Usuário UBEC ou Usuário Genérico por meio de uma interface administrativa, em que uma coleção de Appchain proposta é recebida, em que um loop percorre todas as instâncias de Appchain da Retenção de Cache de Referência da Appchain (ARCR), em que a instância de Appchain cumprida é Recuperada de Retenção de Cache de Segmento Marcado (MSCR), instâncias de Appchain Cumpridas contêm o conjunto completo de segmentos de execução e dados necessários para executar a Appchain escolhida, em que todas as instâncias da Appchain Cumpridas são instaladas de forma incrementai na retenção estática de Appchain, que cada execução ou segmento de dados de saída sendo verificado por ter o status Marcado pelo MSCR, em que a Retenção Estática das Appchains é produzida como
Petição 870200056145, de 06/05/2020, pág. 78/1737
76/754 a saida modular final do SAP e, posteriormente, é submetida como entrada modular ao EDSE da AEL.
[128] Em relação ao Intercâmbio Econômico Digital (CDEE) e seu módulo de dependência LUIGI, o módulo principal de Contentamento Metafísico Neuroeconómico (NMC) é a Avaliação Abrangente do Estado (CSE) que o monitoramento e a regulamentação, realizados por meio da Supervisão de Movimento de Fundos (FMO) de fundos que se deslocam para um aplicativo Alocação de Fundos Públicos (AP-FA), que pertence ao aplicativo UBEC designado que foi selecionado para investimento pela Estrutura de Doações (SE) relevante, em que o acesso criptográfico aos fundos mantidos no APFA é mantido por meio de nós da BCHAIN, em que BD e ID do SE têm acesso ao Mecanismo de Recuperação de Fundos (FRM) da LUIGI.
[129] Com relação à LUIGI operando como um Appchain na Plataforma UBEC, as invocações da LUIGI regulam a movimentação da Unidade Watt e garantem a segurança da alocação da Unidade Watt no CDEE, em que o Passagem da UBEC recebe informações de transferência de dados das Appchains, nas quais o tráfego e a atividade dentro do CDEE são inerentemente vinculado aos Gancho de Passagem da UBEC, em que a Delegação de Tarefas da LUIGI (LTD) determina se os dados recebidos da Passagem da UBEC devem ser processados por LIZARD, LOM ou ambos, em que a chamada da Appchain da LIZARD indica que o modo de processamento 'Leitor de Intenção e Intenção Jurisdicional' foi selecionado, em que a invocação da Appchain da LOM indica que o modo de processamento 'Consultas de conhecimento e arbitragem judicial' foi selecionado, em que o fluxo lógico continua para a Personalização Dinâmica da API
Petição 870200056145, de 06/05/2020, pág. 79/1737
77/754 (DAC), em que a função do DAC é interpretar o tipo de tarefa e, portanto, personalizar a interface da API Selecionada para o Tipo de Tarefa Selecionado, em que a Correspondência dos algoritmos da LOM e LIZARD são executados à medida que são invocados, produzindo resultados analíticos que são enviados à Unificação de Conclusão Inteligente (IUTI), em que a UTI reconcilia quaisquer conclusões interpretativas/subjetivas entre LOM e LIZARD.
[130] A composição ideal de decisão de investimento 13 da CSE, recebida pelo Passagem da UBEC, em que a LUIGI percebe que a maquiagem atua como um contêiner de numerosas alocações de Investimento de Subelemento, Retiradas de Investimento, Alocações de Lucro e Notificação do Diretor, nas quais a Delegação de Tarefa LUIGI (LTD) delega a composição de saída de dados correspondente a ser analisada pelos ramos de análise LUIGI apropriados: consultas de conhecimento e arbitragem judicial (LOM) e leitor de aplicação e intenção jurisdicional (LIZARD).
[131] No que diz respeito às Appchains que interagem com a LUIGI, a Plataforma UBEC se manifesta como uma Appchain com a Appchain UBEC, que se liga ao Passagem da UBEC para fornecer entrada de dados modular à LUIGI, em que após a conclusão do processamento da LUIGI, o retorno abrangente da UBEC envia os dados de volta para a Appchain UBEC, em que o LOM atua como a Appchain Principal para permitir o processamento dentro da ramificação Consultas de Conhecimento e Arbitragem Judicial, em que LOM e LIZARD alimentam Informações de Personalização da API para a Personalização Dinâmica da API (DAC), que tem acesso às informações apropriadas da API executar as personalizações
Petição 870200056145, de 06/05/2020, pág. 80/1737
78/754 relevantes do processo lógico, conforme necessário, dependendo de qual Appchain é chamada, em que o SPSI monitora, mantém e atualiza a composição e a operação do LUIGI.
[132] No que diz respeito ao DAC, a API de uso LIZARD é fornecida na operação do DAC, em que LTD determina o tipo de tarefa definido em Recepção de tarefas e o tipo de tarefa fornecido indica o escopo de personalização do DAC que fornece o conjunto de instruções modular fornecido à filial selecionada, em que o conjunto de instruções modular é programado de acordo com a API de uso LIZARD, em que o LIZARD é executado para atender às duas entradas, em que a Unificação de Conclusão Inteligente (UTI) reconcilia várias saídas de diferentes execuções de módulo para garantir uma saída unificada singular das filiais, através da qual permitindo a recepção de entrada simplificada da ação corretiva LUIGI (LCA).
[133] No que diz respeito ao DAC, a API de uso da LOM é fornecida na operação do DAC, em que LTD determina o tipo de tarefa definido em Recepção de tarefas, em que o tipo de tarefa é interpretado no DAC produzindo o conjunto de instruções modular fornecido ao ramo selecionado, em que o conjunto de instruções modular é programado de acordo com a API de uso da LOM, em que a LOM é executada para atender às duas entradas, em que a UTI reconcilia várias saídas de diferentes execuções de módulo para garantir uma saída unificada singular dos ramos, permitindo uma recepção simplificada de entrada de LCA.
[134] Em relação às funções de manipulação de liquidez cambial que pertencem exclusivamente à LUIGI na Manipulação de Liquidez Financeira, em que no LSE há uma Chave de
Petição 870200056145, de 06/05/2020, pág. 81/1737
79/754
Descriptografia de Retenção que permite à LUIGI Descriptografar a Retenção Criptografada de Chaves Privadas, permitindo que o Mecanismo de Manipulação de Fundos (FMM) manipule fundos na Economia de Watt de a Metachain em uma sessão de recuperação de fundos, em que Prova de Autoridade é uma chave criptográfica exclusiva que é Criptograficamente garantida para ser produzida apenas pela LUIGI devido à logística da LSE, em que a prova de autoridade é usada para chamar um chip UBMA para fornecer sua chave privada exclusiva sensível à segurança.
[135] 0 BD e o ID interagem com o DVM por meio da Interface de votação da proposta (PVI), em que uma proposta autorizada é enviada por um diretor, em que com o ID, as propostas são efetivamente tratadas como comandos no SE, por serem apenas um único diretor e nenhum dilema de consenso, em que a admissão de novo diretor implica a aceitação potencial da diretoria de um novo diretor, em que a proposta é aplicável apenas ao BD e não ao ID, em que a aplicabilidade da admissão de novo diretor depende da política definida na EPR, em que os votos realizados pelos diretores via DVM para modificar um Política Preexistente são votos efetivos em relação a um par de propostas, adição de regra de política e exclusão de regra de política que são tratados como uma única unidade, em que a adição de medida de substituição manual introduz uma nova regra personalizada para substituir a retenção de medida (OMR), que influencia a Decisão Ideal de Investimento: Composição Produzida pela CSE, em que se dois SE forem gerados ao mesmo tempo, ambos com um OMR idêntico, eles serão receba, oralmente, exatamente as mesmas maquiagens de decisão de investimento ideal da CSE.
Petição 870200056145, de 06/05/2020, pág. 82/1737
80/754
[136] Em relação à Iniciação Preliminar do Encadeamento (PTI), o Intervalo de Invocação do CSE é recuperado do Estabelecimento de Política Estabelecida (EPR), em que o Intervalo define com que frequência o SE relevante pretende que uma instância do CSE seja gerada, em que um Intervalo menor implica que o EPR indica que mais unidades de Watt devem ser gastas em taxas BCHAIN para hospedar mais iterações de instâncias do CSE, em que o tempo da última invocação do CSE é recuperado de um armazenamento de valor definido no EPR, em que o valor da Última Invocação do CSE é uma variável específica relacionada à o BD ou ID especificado, em que após o financiamento bem-sucedido dos Nós BCHAIN relevantes do Capital de Investimento correspondente (IC), se Manipulação de Medida de Substituição Automática (A0M2) foi sinalizada para invocação no EPR correspondente do SE relevante, em que a SE pode optar por ativar ο A0M2 se uma Mente-alvo especificada tiver como objetivo orientar as decisões de investimento realizadas pelo CSE.
[137] Ο A0M2 emula os critérios reacionários de uma Mente Alvo, que foi identificada por meio da Identidade da Mente Alvo A0M2, para decretar, modificar ou remover as Medidas de Substituição adotadas na Retenção de Medida de Substituição (OMR) de uma SE relevante, em que o efeito prático da operação da A0M2 é que o SE relevante contém um OMR que é propício às reações e tendências esperadas da Mente Alvo, em que a composição resultante do OMR influencia as Circunstâncias de Investimento Alvo produzidas pela Interpretação das Circunstâncias de Investimento Alvo (TICI) e, portanto, a Decisão de Investimento Ideal Maquiagem e produzida por CSE, em que o cache de resultados
Petição 870200056145, de 06/05/2020, pág. 83/1737
81/754
TICI é descomprimido e extraído para produzir as circunstâncias de investimento-alvo como processadas originalmente por TICI, em que a Posição Atual da estaca é recuperada a partir da Retenção de Estaca de Portfolio (PSR), em que todas as variáveis processadas anteriormente, Medidas de Substituição Ativa, Posição Atual da Estaca, Circunstâncias do Investimento-Alvo e Identidade da Mente-Alvo do A0M2 são Acumuladas, em que após a acumulação, as variáveis mencionadas são fornecidas ao Módulo de solicitação de emulação da mente (MERM) para invocar instâncias do Digital Mind Rastreamento (DMT).
[138] 0 MERM é chamado para produzir uma Solicitação de Emulação da Mente para o DMT que o DMT usa o CTMP para emular a Mente Alvo representada pela Identidade da Mente Alvo do A0M2, produzindo, portanto, o Resultado da Percepção da Mente, que é enviado de volta ao MERM, em que o MERM chama várias instâncias do DMT conforme necessário para produzir com precisão o resultado final Medidas de substituição preferidas, que representam as medidas de substituição que devem ser selecionadas e, portanto, preferidas pela mente especificada.
[139] As decisões baseadas em consenso para investir em Serviços Inteligentes de Previsão de Investimento são tomadas como um SE, em que o SE financia o serviço de previsão, Avaliação Global do Estado (CSE), via IC, em que o CSE é invocado de acordo com o Intervalo de Invocação do CSE, definido na Retenção de Política Estabelecida (EPR), em que o trabalho computacional é realizado nos Nós da BCHAIN que operam o Protocolo BCHAIN, formando assim a Rede BCHAIN, em que a manipulação de fundos que são estrategicamente alocados no IC relevante acumula a Economia
Petição 870200056145, de 06/05/2020, pág. 84/1737
82/754 de Watt da Metachain, em que os fundos nunca existem criptograficamente diretamente na Própria Instância do IC, mas, em vez disso, são prometidos via WUP2 pelos nós BCHAIN que Mantêm os Fundos pelos quais todas as Unidades de Watt são gerenciadas pela economia de Watt enquanto Residem Criptograficamente nos nós BCHAIN físicos.
[140] 0 CSR gerencia relatórios de informações executados por entidades corporativas registradas que enviam informações operacionais para a Appchain Correspondente de Rastreamento de Entidades Corporativas, o que permite que a Avaliação Abrangente do Estado (CSE) considere a atividade operacional de todas as entidades corporativas registradas no processamento de SE, em que uma entidade corporativa é 'registrada' no sentido de ter optada por anunciar os Elementoschave dos Dados Registrados relacionados às suas Atividades Operacionais à Appchain de Rastreamento de Entidades Corporativas, em que o Gerador de Reivindicação de Conteúdo (CCG) é uma função do Protocolo BCHAIN que permite recuperar o conteúdo de vários nós BCHAIN, em que o Módulo de Reconhecimento de Customchain (CRM) é uma função do protocolo BCHAIN, que mantém automaticamente as Appchains definidas nas Appchains registradas, em que o Relatório de Erros na forma de uma DLL é encaminhado pelo ARM para o SPSI processa o relatório de erros por meio da Análise de Unidade de Registro de Diagnóstico (DLUA), em que o Loop de Feedback do Relatório de Erros com SPSI leva à programação do CSR para eventualmente mudar, para acomodar a solução comprovada ao Relatório de Erros inicial demonstrado pela DLL, seguindo o conceito de SRIA, em que o MRP é iniciado pela
Petição 870200056145, de 06/05/2020, pág. 85/1737
83/754 operação do CSE via RIP que invoca uma Instância de LOM que pesquisa Atividades e Eventos de Mercado via ARM, em que inicialmente o ARM Recupera Informações não confirmadas de Fontes Públicas e Privadas e, posteriormente, LOM e CTMP verificam as Informações não Confirmadas e as expandem para produzir Conceitos Verdadeiros.
[141] 0 Procedimento de Pesquisa Regulatória/Tributária (RTRP) é iniciado pela operação do CSE via RIP que chama uma instância do LOM que pesquisa Códigos Tributários e Regulatórios via ARM, em que inicialmente o ARM recupera informações não confirmadas de Fontes Públicas e Privadas e, posteriormente, a LOM e verifica as não confirmadas informações e expandi-las para produzir conceitos verdadeiros.
[142] 0 TICI extrai a Composição da Estaca do Portfolio da Retenção da Estaca do Portfolio (PSR) relevante do SE correspondente, em que as Medidas de Substituição são extraídas da Retenção da Medida de Substituição (OMR) relevante do SE correspondente, em que as Medidas de Substituição induzem um efeito de personalização pretendido ao resultante Composição ideal da decisão de investimento via DVM, em que as informações contidas nas medidas de Composição e Substituição de Estaca do Portfolio são mescladas em um Contêiner de Abstração que se transforma em Circunstâncias de Investimento Alvo, as quais são enviadas ao CSE, em que após a Chamada Completa do LOM e do CTMP; a Composição Ideal da Decisão de Investimento é produzida pela CSE, em que a LOM produz Conhecimento de Atividades de Mercado da CKR, em que a LOM é invocada para produzir esse Conhecimento pelo Prompt de Invocação de Conhecimento da NMC (NKIP).
Petição 870200056145, de 06/05/2020, pág. 86/1737
84/754
[143] As circunstâncias de investimento alvo são fornecidas ao prompt de chamada de configuração idealista (ICIP), em que o prompt produzido pelo ICIP 12403 é enviado ao IQR da LOM, em que o Prompt Fornecido é Analisado pela CKR, em que o NMM é gerado para atender a CSE, em que o estado da Situação Holistica é enviado para armazenamento em Necessidade de Acesso e Desenvolvimento e Armazenamento, em que o estado de situação holistica é dividido em subcategorias e retido em Armazenamento como uma série de ramificações e camadas hierárquicas, em que a ameaça de segurança artificial (AST) fornece uma finalidade de entrada para o Pesquise Algo thm do NMM, que faz referência e pesquisa através do índice de Necessidades compilado, determinando, portanto, se o Objetivo de Entrada define uma necessidade válida de acordo com os ramos de jurisdição inicialmente definidos em Necessidade de Desenvolvimento e Armazenamento de Acesso.
[144] A Iniciação Preliminar de Encadeamentos (PTI) inicia uma instância da Interpretação das Circunstâncias de Investimento Alvo (TICI) que produz as Circunstâncias de Investimento Alvo para o mecanismo de Processamento Interno da CSE, em que a Composição da Decisão de Investimento Refinado é descompactada para seus elementos individuais, em que a Composição da Estaca é obtida Assimilado nas Circunstâncias Alvo de Investimento, a Atuação de Decisão de Investimento (IDA) executa os Elementos Individuais fornecidos para executar as consequências pretendidas para o SE relevante.
[145] Em relação à operação do Rastreamento Mental Digital (DMT), a Gravação do Comportamento Alvo (TBR) recebe
Petição 870200056145, de 06/05/2020, pág. 87/1737
85/754 informações do Conjunto de Dados de Comportamento (BDS) diretamente da Mente Alvo especificada e também as associações de Mapeamento Neurológico Feitas pelo Aprimoramento do Mapeamento Neurológico (NME), em que o BDS contém informações sobre ações, instruções e metadados referentes à mente-alvo, em que a instância BDS é fornecida pelo DMT e normalizada via LIZARD, que a converte do formato de sintaxe para o formato de finalidade, em que um mapa de finalidade de comportamento é construído a partir da instância de BDS pela LIZARD, em que o Mapa de Objetivos de Comportamento é armazenado e retido em uma instância do Perfil de Inteligência Pessoal (PIP) que é logisticamente associada à Mente-alvo, em que o LOM é chamado para produzir Tipos de Modelo de Personalidade, em que uma Maquiagem do Modelo de Personalidade é produzida a partir do Cumprimento do Modelo de Personalidade (PTF), em que uma maquiagem de modelo de personalidade captura Elementos de Personalidade existentes nos Tipos de Modelo de Personalidade de acordo com os Critérios de Modelo de Personalidade da Mente Alvo, em que o LOM é invocado para produzir a definição de Nuance da Personalidade que corresponde à Mente Alvo da instância PIP correspondente.
[14 6] 0 PTF inicia um loop para percorrer cada um dos Critérios de Modelo de Personalidade, em que os Critérios de Modelo de Personalidade selecionados da Iteração do loop recuperam os tipos de Modelo de Personalidade correspondentes de acordo com os Tipos de Modelo de Personalidade referenciados nos Critérios de Modelo de Personalidade selecionados que produzem o Tipo Modelo de Personalidade Selecionado Atribuído de acordo com a Magnitude de Presença Definida nos Critérios de Modelo de
Petição 870200056145, de 06/05/2020, pág. 88/1737
86/754
Personalidade Selecionada que produzem a Maquiagem do Modelo de Personalidade, em que o LIZARD converte a Definição de Nuance da Personalidade em um Mapa de Hierarquia de Propósitos, em que LIZARD converte a Maquiagem do Modelo de Personalidade em um Mapa de Hierarquia de Propósitos, em que ambos Mapas de Hierarquia de Finalidade são processados pelo processamento de simetria de Objetivo a Objetivo (P2SP) que determina a congruência/compatibilidade entre as duas entradas, produzindo o resultado do processamento de simetria.
[147] A Identidade da Mente Alvo da Mente Alvo é recuperada e a instância Retenção de Cache de Instantâneo de Personalidade (PSCR) associada à Identidade da Mente de Destino é recuperada, em que se houver uma iteração anterior do Sistema de Reação da Personalidade armazenada na instância do PSCR que corresponde à Era do Tempo Definido é verificada, em que a Era do Tempo Definido é referenciada na Identidade Mental do alvo, em que a Era do Tempo Definido pode fazer distinções entre versões mais antigas e mais recentes das pessoas, pois eram, se sim, a Iteração Anterior da Personalidade do Sistema de Reação é excluído da instância do PSCR, em que a próxima etapa Converte, Armazena e Retém o atual Sistema de Reação da Personalidade na Instância do PSCR associada à Mente-Alvo da Era do Tempo Definido, de acordo com a Identidade da Mente-Alvo.
[148] Um conjunto de comandos personalizado é enviado ao ESR que o instrui a extrair o Conteúdo da Appchain do CTMP sem nenhum dado preexistente que produza uma base de execução de CTMP vazia, que é uma Captura Instantânea da Instância de ESR, na qual a base de execução de CTMP vazia é Renderizada em uma
Petição 870200056145, de 06/05/2020, pág. 89/1737
87/754 nova instância do ESR, em que a Appchain CTMP Personalizado Renderizada Interage com o Sistema de Reação da Personalidade capturando a personalidade da Mente-Alvo na instância CTMP personalizada, em que um Conjunto de Comandos Personalizado é enviado como uma Instrução à Instância do ESR para confirmar todas as Alterações no Armazenamento Persistente e a Instância CTMP personalizada é efetivamente capturada em um Arquivo de Retenção de Appchain de Instantâneo CTMP, em que um conjunto de cenários de emulação relevantes é produzido por meio da Produção de Cenário de Emulação (ESP) , em que o ESP produz cenários de emulação que são relevantes para o escopo, jurisdição e capacidades do Sistema de Reação da Personalidade, em que um Loop é iniciado, que itera pelos Cenários de Emulação Relevantes, produzindo um cenário de Emulação Selecionado unitário por iteração do Loop, em que o Cenário de Emulação Selecionado é descompactado para produzir as duas variáveis principais que ele contém: a Proposição de Emulação e o Ambiente de Emulação, em que a proposição de emulação é enviada à instância CTMP personalizada como Metadados do Sistema de Entrada e o ambiente de emulação é enviado como Registros à instância CTMP personalizada com a Classificação de Fato Objetivo.
[149] Em relação ao Aprimoramento do Mapeamento Neuroeconómico (NME), que associa os Padrões Neurais da Mente Alvo aos Estados Físicos de Existência capturados no Estado Circunstancial Alvo, o Dispositivo de Varredura Neural Nãoobstrutiva (UNSD) recebe um Padrão Neural Bruto da Mente Alvo que está atuando nela capacidade como um Usuário da UBEC, em que a Mente Alvo sendo um Usuário da UBEC permite que as comunicações
Petição 870200056145, de 06/05/2020, pág. 90/1737
88/754 da API padronizadas internas sejam feitas pela Rede BCHAIN para o UNSD, em que o Padrão Neural Bruto do Usuário UBEC é recebido via UNSD, em que LO relata o Destino Estado Circunstancial e confiança do usuário UBEC por meio do PIP correspondente e da Automação de Gerenciamento de Vida (LAA), em que a LOM produz o estado circunstancial alvo com base nos dados fornecidos pelo PIP, que retém informações pessoais sobre o usuário da UBEC alvo e o LAA, que conecta o Estilo de Vida Digital do Usuário da UBEC, em que a LOM produz um Conhecimento da Associação do Estado Neural, que representa relações entre o estado neural potencial e o estado circunstancial potencial, em que a confiança do conhecimento da associação do estado neural se correlaciona com a confiança algorítmica que a LOM possui em relação à precisão e confiabilidade do conhecimento da associação do estado neural, em que o LIZARD converte o conhecimento da associação do estado neural em um mapa de hierarquia de finalidades.
[150] Em relação ao SPSI, além do AEL, programação e reconfiguração da Metodologia de Doação Perpétua (MPG) no NMC, o SPSI é executado no Sistema Legado via AEL, que permite ao SPSI acessar e manipular elementos que existem e operam dentro da API e Estrutura de Legado, em que o SPSI realiza Atualizações de Eficiência e Funcionalidade, Manutenção e Modificações gerais no MPG produtor de NMC, em que o SPSI é uma Appchain dentro da rede de BCHAIN, em que o SPSI converte o NMC como um Programa Herdado em NMC como uma Appchain através da invocação do Construtor de Ecossistemas Customchain (CEB)
[151] BREVE DESCRIÇÃO DOS DESENHOS
[152] A Fig. 1 mostra o ecossistema de informações com
Petição 870200056145, de 06/05/2020, pág. 91/1737
89/754 seus respectivos submódulos/dependências que compõem a plataforma UBEC;
[153] A Fig. 2 mostra detalhes de aplicativos e serviços de terceiros e algoritmos de terceiros;
[154] A Fig. 3 mostra o mecanismo de implantação automatizada para a plataforma de UBEC;
[155] A Fig. 4 mostra a rotina de implantação A, otimizada para dispositivos Apple iOS;
[156] A Fig. 5 mostra a rotina de implantação B, otimizada para a Google Play Store;
[157] A Fig. 6 mostra a rotina de implantação C, na qual a especificação direta de hardware é referenciada pelo SPSI para produzir drivers da interface;
[158] A Fig. 7 mostra um exemplo de caso de uso de usuário Layman interagindo com a plataforma UBEC pela primeira vez ;
[159] A Fig. 8 mostra o usuário que opera um smartphone que executa a plataforma UBEC nativamente como um sistema operacional;
[160] A Fig. 9 mostra o Fluxo Lógico Detalhado do processo automatizado de Chamada Telefônica, realizado pela LOM, através da plataforma UBEC e da rede BCHAIN;
[161] A Fig. 10 mostra a LOM como uma Appchain operando várias funções para gerenciar a saúde pessoal como um assistente pessoal artificialmente inteligente;
[162] As Figs. 11 e 12 mostram que o Passagem da UBEC recebe o tráfego de informações que está ocorrendo no UBEC como uma Appchain;
Petição 870200056145, de 06/05/2020, pág. 92/1737
90/754
[163] As Figs. 13 e 14 mostram como as especificações de uso da API de uso LIZARD e da API de uso LOM são definidas pelas próprias Appchains;
[164] A Fig. 15 mostra as funções de manipulação de liquidez da moeda que pertencem exclusivamente à LUIGI;
[165] A Fig. 16 mostra a funcionalidade do LUIGI para executar Verificação de envio + Manutenção de Appchains;
[166] A Fig. 17 mostra a funcionalidade da LUIGI para realizar a verificação das condições contratuais;
[167] A Fig. 18 mostra a funcionalidade do LUIGI como Sistema de Apelação de Resolução de Conflitos;
[168] A Fig. 19 mostra a capacidade do LUIGI em relação à interação do nó do usuário com o monitoramento do comportamento do obstáculo virtual;
[169] A Fig. 20 mostra a funcionalidade do LUIGI em relação à verificação da impressão em série da Appchain;
[170] A Fig. 21 mostra a funcionalidade do LUIGI em relação à recuperação de fundos perdidos e reversão de atividade fraudulenta;
[171] A Fig. 22 mostra a funcionalidade da interação do nó do usuário (UNI);
[172] A Fig. 23 mostra que a quantidade de dados biométricos fornecidos é medida e verificada se suficiente para o processo de autenticação;
[173] A Fig. 24 mostra que as Appchains de Associação de Banda e nó são atualizadas para a versão mais recente do ecossistema Customchain por meio do protocolo BCHAIN;
[174] A Fig. 25 mostra que a autenticação bem-sucedida
Petição 870200056145, de 06/05/2020, pág. 93/1737
91/754 ocorre apenas se uma quantidade suficiente de Tokens de
Autorização de Banda (BAT) corresponder a qualquer Token de
Autenticação;
[175]A Fig. 26 mostra a categorização de banda
biométrica (BBC);
[176] A Fig. 27 mostra a mecânica da camada base das
Appchains que formam o ecossistema Customchain;
[177] A Fig. 28 mostra os ecossistemas Customchain que são relevantes para o dispositivo habilitado para UBEC de uma forma básica;
[178] A Fig. 29 mostra o processo de desenvolvimento e implantação de aplicativos UBEC;
[179] A Fig. 30 mostra que o Processamento lógico de CEB interno gera suplementos de execução + dados;
[180] A Fig. 31 mostra as etapas que seguem após a conclusão do processo CEB;
[181] A Fig. 32 mostra a LOM operando como uma série de Appchains conhecidas por serem um ecossistema Customchain;
[182] A Fig. 33 mostra que a Lógica No Âmbito do Sistema da UBEC representa a Appchain Contêiner de LOM interagindo com outras Appchain dentro da Plataforma da UBEC;
[183] A Fig. 34 mostra como a Retenção Central de Conhecimento (CKR) existe como sua própria Appchain independente;
[184] A Fig. 35 mostra uma instância do Perfil de Inteligência Pessoal (PIP) como uma Appchain;
[185] A Fig. 36 mostra como o módulo Administração e Automação de Vida (LAA) da LOM existe como uma Appchain suplementares paralela;
Petição 870200056145, de 06/05/2020, pág. 94/1737
92/754
[186] A Fig. 37 mostra o algoritmo de moeda da Unidade de watt;
[187] A Fig. 38 mostra a mecânica da compra e venda de unidades Watt com integração da autenticação do usuário via Interação do Nó do Usuário (UNI);
[188] A Fig. 39 mostra que o FMO e as funções do LEI requerem conhecimento e acesso à Alocação de fundos privados do usuário (UPFA);
[189] A Fig. 40 mostra a Bolsa de Economia Digital Criptográfica (CDEE);
[190] A Fig. 41 mostra como os aplicativos UBEC listados no módulo Diretório de Aplicativos e Exploração (ADE) podem receber e enviar liquidez em termos de investimento;
[191] A Fig. 42 mostra que o aplicativo UBEC interage diretamente com o fundo privado de usuário do usuário UBEC
[192] A Fig. 43 mostra a interação entre a Interface de plataforma UBEC (UP1) e a Aceitação do Trabalho em Cache (CWA);
[193]A Fig . 44 mostra como o CWSI faz referência à
Economia . de Watts da Metachain;
[194]A Fig . 45 mostra uma Visão Geral do Protocolo
BCHAIN ( BP) ;
[195]A Fig . 46 mostra como o protocolo BCHAIN opera
com seu próprio hardware e o hardware de outros nós BCHAIN;
[196] A Fig. , 47 mostra o paradigma da interação do
existente na rede BCHAIN;
[197]A Fig. , 48 mostra como a confirmação da troca de
anúncios de hash impede que um Nó Rogue BCHAIN participe da Rede
BCHAIN;
Petição 870200056145, de 06/05/2020, pág. 95/1737
93/754
[198] A Fig. 49 mostra o padrão básico de deslocamento de um pacote CCR ou CCF dentro da rede BCHAIN;
[199] A Fig. 50 mostra duas funções da inteligência adaptativa da rede BCHAIN em vigor;
[200] A Fig. 51 mostra uma 'estrada' conhecida de viagens recomendadas entre vários setores dentro da rede BCHAIN;
[201] A Fig. 52 mostra o conteúdo de liberação escalonada;
[202] A Fig. 53 mostra o conteúdo da transmissão ao vivo ;
[203] A Fig. 54 mostra que o Sistema de Corroboração da Estratégia (SCS) usa o módulo Consumo de Escopo de Tráfego (TSC) para derivar uma coleção Hash de Escopo Duplo;
[204] A Fig. 55 mostra que os anúncios de hash são mostrados sendo trocados entre três áreas de tráfego diferentes conhecidas como setores;
[205] A Fig. 56 mostra a estrutura do armazenamento da Customchain;
[206] A Fig. 57 mostra que a Pesquisa Estatística dos
Nós (NSS) reúne informações sobre o comportamento dos Nós
circundantes para calcular os quatro principais índices;
[207]A Fig. 58 mostra os Detalhes do Processamento de
Ping do nó (NPP);
[208]A Fig. 59 mostra o Sistema de Corroboração de
Estratégia (SCS);
[209] A Fig. 60 mostra que o TSC Consensus do escopo do
tráfego chama o NVP para receber dados estatísticos do nó para
Levantar Variáveis (NSS) e produzir uma Média Composta de
Petição 870200056145, de 06/05/2020, pág. 96/1737
94/754
Variáveis NSS (NVCI);
[210] As Figs. 61-63 mostram que os Fatores de Desempenho são produzidos pelo Conjunto de Variáveis do NSS (NVP) e arredondados para o múltiplo X mais próximo;
[211] A Fig. 64 mostra Adaptação Estratégica Dinâmica (DSA);
[212] A Fig. 65 mostra a Interpretação do Desempenho da Estratégia (SPI);
[213] As Figs. 66 e 67 mostram a estrutura do banco de dados do Rastreamento de Desempenho da Estratégia (SPT), que opera como uma Appchain do segmento de dados;
[214] As Figs. 68 - 70 mostram o trabalho detalhado do Algoritmo de Seleção de Estratégia Otimizada (OSSA);
[215] A Fig. 71 mostra o Módulo de Criação de Estratégia (SCM), que é chamado pela adaptação estratégica dinâmica (DSA);
[216] A Fig. 72 mostra os vários critérios que compõem os critérios de estratégia de composição;
[217] A Fig. 73 mostra como o SCM processa sua entrada e saída modular;
[218] A Fig. 74 mostra como o Módulo de Criatividade é usado para atualizar a Composição dos Critérios de Estratégia;
[219] A Fig. 75 mostra que o usuário UBEC acessa a plataforma UBEC por meio de reconhecimento biométrico realizado
na interação do nó do usuário (UNI);
[220] A Fig. 76 mostra que a Computação e
Disponibilidade de Recursos de Rede (CBRA) é invocada, o que
concede referência à Seleção de Incentivo Econômico (EIS);
[221] As Figs. 77 -79 mostram Envio de Log de
Petição 870200056145, de 06/05/2020, pág. 97/1737
95/754
Diagnóstico (DLS);
[222] As Figs. 80 - 83 mostra Seleção de incentivo econômico (EIS) e Processamento de reclamação de pagamento de trabalho (WPCP);
[223] As Figs. 84 - 169 demonstram a funcionalidade Gerenciamento de Integridade de Dados (DIM) que opera com CSR, MNSCS e MFDR;
[224] As Figs. 170 - 358 fornecem detalhes sobre a lógica de roteamento, que é o principal núcleo da rede BCHAIN;
[225] As Figs. 359 - 365 mostram a Estrutura do
Processador Personalizada projetada a partir da arquitetura de microchip UB-EC/BCHAIN (UBMA);
[226] A Fig. 366 mostra detalhes do módulo de Conjunto de Patches de Implantação (DPA), detalhes de Logística, Camada e sua Interação com o Construtor de Ecossistemas Customchain (CEB);
[227] A Figs. 367 mostra o processo para Adição de Bloco de Correção (CPBA);
[228] As Figs. 368 e 371 mostram a sequência do
Mecanismo de Troca da Appchain (ASM);
[229] As Figs. 372 a 373 mostram a Sequência de
Interpretação da Camada de Logística (L2I);
[230] As Figs. 374 a 375 mostram o processo LIZARD para converter a camada de logística da Appchain alvo em Appchain;
[231] A Fig. 376 mostra o processo da Manipulação de Appchain em bruto (RAM) da entrada da camada de logística;
[232] As Figs. 377 e 378 mostram que o processo para o LIZARD converte os elementos lógicos executáveis da camada de logística em execução;
Petição 870200056145, de 06/05/2020, pág. 98/1737
96/754
[233] As Figs. 379 e 381 mostram que o processo para LIZARD converte os elementos de dados estáticos da camada de logística em dados;
[234] A Fig. 382 mostra a sequência para o fluxo de execução sendo processada por ESR no MCE;
[235] A Fig. 383 mostra que uma instância preliminar de ESR encontra o escopo ambiental potencial;
[236] As Figs. 383 a 385 mostram o LIZARD convertendo o estado de renderização inicial em finalidade de renderização inicial;
[237] As Figs. 386 a 387 mostram LIZARD convertendo o estado de renderização final em finalidade de renderização final;
[238] Fig. 388 a Fig. 402 mostram detalhes onde a instância preliminar de ESR encontra o Escopo Ambiental Potencial utilizando CTMP e LOM;
[239] A Fig. 403 e a figura 404 mostram o atendimento de solicitação de dependência de Manipulação da Appchain Bruta (RAM) (DRF);
[240] Fig. 405 a Fig. 407 mostram LIZARD convertendo a Solicitação de Execução em Finalidade;
[241] A Fig. 408 mostra RAW com DRF;
[242] A Fig. 409 mostra DPA com Fluxo de Execução atualizado e fluxo de execução original;
[243] A Fig. 410 mostra EDSM com ESC e fluxo de execução atualizado;
[244] As Figs. 411 a 412 mostram DSDL com fluxo de dados atualizado e fluxo de dados original;
[245] As Figs. 413 e 416 mostram ESDL recebendo fluxo
Petição 870200056145, de 06/05/2020, pág. 99/1737
97/754 de execução atualizado AO;
[246] As Figs. 417 a 418 mostram ESR;
[247] As Figs. 419 e 420 mostram tipos de comando com referência de comando condicional e sequência de execução;
[248] As Figs. 421 a 424 mostram a Execução MEL com base nos tipos de comando;
[249] As Figs . 425 - 429 mostram processamento AO do
fluxo de dados;
[250] A Fig. 430 mostra a NCA;
[251] A Fig. 431 mostra ESR e processamento de
resultados render izados (R2P ') ;
[252] As Figs . 432 a 436 mostram ESC;
[253] As Figs . 437 a 439 mostram DSS;
[254]A Fig . 440 a Fig. 442 mostram NSA;
[255] As Figs . 443 a 445 mostram P2SP;
[256] A Fig . 4 4 6 e a figura 447 mostram PRP;
[257] As Figs . 448 - 452 mostram avanço da inteligência
simbiótica recursive ( SRIA);
[258] As Figs . 600 à Fig. 603 mostram SPSI;
[259] A Fig. 604 mostra Appchains oficiais interagindo entre si dentro de um ecossistema de Customchain;
[260] A Fig. 605 mostra uma visão geral dos vários submódulos que operam no SPSI;
[2 61] As Figs . 606 - 609 mostram ATM;
[262] As Figs . 610 - 616 mostram A2R;
[263] A Fig. 617 e a Figura 618 mostram o LIZARD
convertendo o Mapa de Finalidade Atualizado em uma Appchain Atualizada;
Petição 870200056145, de 06/05/2020, pág. 100/1737
98/754
[264] As Figs. 619 - 652 mostram IEC;
[265] As Figs. 653 e 654 mostram ASH;
[266] As Figs. 655-659 mostram o procedimento de operação interna do LOM e do CTMP em relação à ASH;
[267] A Fig. 660 mostra RP2 de dentro do CTMP;
[268] As Figs. 661 - 662 som elaboradas em POE;
[269] A Fig. 663 mostra o processo da memória da Web que opera em paralelo à execução do POE;
[270] A Fig. 664 elabora a Interação do Fluxo lógico Entre PS e APDM;
[271] A Fig. 665 Mostra os Detalhes Operacionais Relativos ao CRSE;
[272] As Figs. 666 - 667 elaboram em ID;
[273] As Figs. 668 - 669 elaboram em CDO;
[274] A Fig. 670 mostra o processamento de ARM com base no escopo da ameaça de segurança;
[275] A Fig. 671 mostra ASH e CKR;
[276] A Fig. 672 mostra ASH com elaboração de ARM e CKR;
[277] As Figs. 673 e 674 mostram a LOM produzindo conhecimento sobre ameaças à segurança, submetida à AST;
[278] As Figs. 675 - 676 mostram ASH com detalhes sobre o processamento do LIZARD AST;
[279] A Fig. 677 mostra ASH com detalhes sobre ο processamento I2GE AST;
[280] A Fig. 678 mostra ASH com LIZARD recebendo o Fluxo de Execução do Appchain de destino do ESC;
[281] A Fig. 679 mostra ASH com LIZARD executando a Execução do Appchain de Destino recebido através do ESC;
Petição 870200056145, de 06/05/2020, pág. 101/1737
99/754
[282] A Fig. 680 mostra ASH com I2GE realizando Evolução Iterative;
[283] A Fig. 681 mostra ASH sob ataque de AST;
[284] A Fig. 682 mostra ASH com I2GE realizando Evolução Iterative;
[285] A Fig. 684 mostra a conformidade regulamentar da Appchain (ARC);
[286] As Figs. 685 - 686 mostram o LIZARD convertendo os Regulamentos e Diretrizes do Sistema em um Mapa de Hierarquia de Propósito;
[287] A Fig. 687 mostra a utilização do Mapa de Hierarquia de Propósito;
[288] A Fig. 688 mostra como determinar se a LUIGI confirmou independentemente que o Appchain em questão viola os regulamentos e diretrizes do sistema;
[289] A Fig. 689 mostra o ajuste do mapa da hierarquia de finalidades da Appchain alvo;
[290] As Figs. 690 - 692 mostram LIZARD convertendo o Mapa de Finalidade Atualizado em um Appchain Atualizado;
[291] As Figs. 693 - 697 mostram DLUA;
[292] As Figs. 698 - 699 mostram LIZARD convertendo ERLR em um mapa de hierarquia de finalidades;
[293] As Figs. 700 - 705 mostram DLUA;
[294] As Figs. 706 - 707 mostram LIZARD convertendo o log de erro contextual!zado em um mapa de hierarquia de finalidades;
[295] As Figs. 708 - 709 mostram LIZARD convertendo o segmento de execução refinada em um mapa de hierarquia de
Petição 870200056145, de 06/05/2020, pág. 102/1737
100/754 finalidades;
[296] A Fig. 710 mostra DLUA;
[297] A Fig. 711 mostra NAD;
[298] As Figs. 712 - 713 mostram o LIZARD convertendo todo o ecossistema Customchain da plataforma UBEC em um mapa de hierarquia de finalidades;
[299] A Fig. 714 mostra Cooperação de Sobreposição e Verificação de Conflitos (OC3);
[300] As Figs. 715 -716 mostram LIZARD convertendo o mapa de hierarquia de finalidades em uma série de faixas de finalidades;
[301] A Fig. 717 mostra OC3;
[302] As Figs. 718 - 719 mostram a operação do CTMP, LOM e I2GE para desenvolver o Mapa OC3;
[303] As Figs. 720 - 721 mostram LIZARD convertendo novas alterações propostas em um mapa de hierarquia de finalidades;
[304] As Figs. 722 - 724 mostram Cooperação de sobreposição e verificação de conflitos (OC3);
[305] As Figs. 725 - 726 mostram o LIZARD convertendo os Princípios de Projeto do Sistema em um Mapa de Hierarquia de Propósitos;
[306] As Fig. 727 - 728 mostram o LIZARD convertendo as Jurisdições da Appchain em um Mapa de Hierarquia de Propósito;
[307] As Figs. 729 - 730 mostram Cooperação de sobreposição e verificação de conflitos (OC3);
[308] As Figs. 731 - 732 mostram LIZARD convertendo o mapa de finalidades atualizadas em novas alterações propostas;
Petição 870200056145, de 06/05/2020, pág. 103/1737
101/754
[309] A Fig. 733 mostra Atuação de Modificação de Princípios (PMA);
[310] As Figs. 734 - 735 mostram LIZARD convertendo Appchains para criar em uma camada de logística;
[311] A Fig. 736 mostra a Atuação de Modificação de Princípios (PMA);
[312] A Fig. 737 - 740 mostram o Novo Desenvolvimento de Appchain (NAD);
[313] A Fig. 741 - 742 mostram LIZARD convertendo o mapa OC3 em um mapa de sintaxe da Appchain;
[314] A Fig. 743 mostra NAD;
[315] As Figs. 744 - 745 mostram o LIZARD convertendo o Appchain cumprido no mapa de hierarquia de finalidades;
[316] As Figs. 746 - 754 mostram NAD;
[317] As Figs. 755 - 756 mostram POE;
[318] A Fig. 757 mostra a rede de memória;
[319] A Fig. 758 elabora o fluxo lógico entre PS e APDM;
[320] A Fig. 759 mostra CRSE;
[321] As Figs . 760 - 761 mostram o ID do programa;
[322] As Figs . 762 - 763 mostram CDO;
[323] As Figs . 764 - 765 mostram NAD;
[324] As Figs . 766 - 767 mostram o LIZARD convertendo
soluções criativas sintáticas em um mapa de hierarquia de finalidades;
[325] As Figs. 770 - 771 mostram LIZARD convertendo o mapa de finalidades atualizadas em uma camada de logística;
[326] As Figs. 775 - 776 mostram o LIZARD convertendo a interpretação da estrutura de hardware em um mapa de finalidade
Petição 870200056145, de 06/05/2020, pág. 104/1737
102/754 de hardware;
[327] As Figs. 777 - 778 mostram o LIZARD convertendo a interpretação da estrutura da estrutura em um mapa de finalidades da estrutura;
[328] As Figs . 781 - 784 mostram a operação do LOM e do
CTMP em relação à EFD;
[329] As Figs . 785 - 786 mostram RP2;
[330] As Figs . 787 - 788 mostram POE;
[331]A Fig . 789 mostra o proce sso de memória da Web
que opera em paralelo à execução do POE;
[332] A figura 790 elabora o fluxo lógico entre PS e
APDM;
[333] A Fig. 791 mostra CRSE;
[334] As Figs . 792 - 793 mostram ID;
[335] As Figs . 794 - 795 mostram CDO;
[336] As Figs . 798 - 799 mostram o LIZARD convertendo a
interpretação da estrutura de estrutura refinada em um mapa de finalidade da estrutura ideal;
[337] A Fig. 801 mostra NMM;
[338] As Figs. 807 - 815 mostram LOM e CTMP em relação a EHD;
[339] A Fig. 816 descreve a interação entre PS e APDM;
[340]A Fig. 817 mostra CRSE;
[341] As Figs . 818 - 819 mostram ID;
[342] As Figs . 820 - 821 mostram CDO;
[343] As Figs . 822 - 823 mostram o LIZARD convertendo a
configuração ideal de hardware em um mapa de hierarquia de
finalidades;
Petição 870200056145, de 06/05/2020, pág. 105/1737
103/754
[344] As Fig. 826 - 827 mostram o LIZARD convertendo os Princípios de Engenharia Elétrica em um Mapa de Hierarquia de Propósitos;
[345] As Figs. 833 - 834 mostram o LIZARD convertendo drivers de interface em um mapa de hierarquia de finalidades; As Figs. 835 - 836 mostram o LIZARD convertendo as especificações da interface em um mapa de hierarquia de finalidades;
[346] As Figs. 841 - 842 mostram o LIZARD que converte a parte referenciada do plug-in de interface modular em um mapa de hierarquia de finalidades;
[347] As Figs. 843 - 844 mostram o LIZARD convertendo a Parte Referenciada dos Drivers de Interface em um Mapa de Hierarquia de Propósito;
[348] As Figs. 854 - 855 mostram o LIZARD convertendo dependências modulares de Appchain em um mapa de hierarquia de finalidades;
[349] As Figs. 856-857 mostram o LIZARD convertendo dependências modulares de Appchain em um mapa de hierarquia de finalidades;
[350] As Figs. 859 - 860 mostram o LIZARD convertendo o mapa de finalidades atualizadas em um binário pré-compilado;
[351] As Figs. 1000 - 1001 mostram ES;
[352] A Fig. 1002 mostra a funcionalidade de supervisão de segurança do CDEE;
[353] As Figs. 1003 - 1005 mostram LUIGI;
[354] As Figs. 1006 - 1007 elaborado sobre DAC;
[355] A Fig. 1008 mostra as funções de manipulação de liquidez da moeda em Manipulação de liquidez financeira;
Petição 870200056145, de 06/05/2020, pág. 106/1737
104/754
[356] As Figs . 1009 - 1011 mostram DVM;
[357] As Figs . 1012 - 1014 mostram PTI ;
[358] As Figs . 1015 - 1026 mostram A0M2 ;
[359] A Fig . 1027 mostra a injeção de liquidez;
[360] As Figs . 1028 - 1030 mostram PCP;
[3 61] As Figs . 1031 - 1034 mostram RSE;
[362] As Figs . 1035 - 1036 mostram MRP;
[363] As Figs . 1037 - 1038 mostram RTRP;
[364] As Figs . 1039 - 1087 mostram CSE;
[365] As Figs. 1088 - 11 15 mostram DMT;
[366] As Figs. 1116-1145 mostram MERM;
[367] As Figs. 1146-1183 mostram NME;
[368] A Fig. 1184 mostra a operação e aplicação da agregação de log no ES;
[369] As Figs. 1185 - 1189 ilustram exemplos de usabilidade de Autoprogramação de Auto-Inovação (SPSI) no que diz respeito à operação de Appchains e Programas Legados nos sistemas Legado e BCHAIN;
[370] A Fig. 1190 mostra uma visão geral dos vários submódulos que operam no SPSI;
[371] As Figs. 1191 - 1224 mostram a operação e a funcionalidade da correção de erros inatos (IEC); e
[372] As Figs. 1225 - 1242 mostram a operação e a funcionalidade da camada de emulação de Appchain (AEL).
[373] DESCRIÇÃO DETALHADA DA INVENÇÃO
[374] [00] Figs. 1-2 mostram o ecossistema de computação com seus respectivos submódulos/dependências que compõem a Plataforma UBEC 100 que obtém colaboração eficiente
Petição 870200056145, de 06/05/2020, pág. 107/1737
105/754 por meio de Instâncias de Critérios Algorítmicos Separados e Sincronizados. Universal/Onipresente; BCHAIN 110 (Harmonização da Conexão de Base Conectando nós Integrados); Todo, Todos, Todos os Lugares, Todo o Tempo (E3A) (Economia, Emprego, Entretenimento, Educação, Energia, Trocas, etc.); Conexões (um relacionamento no qual uma pessoa, coisa ou ideia está vinculada ou associada a outra (Comunicações, Garantias, Criatividade, Constituição, Capital, Comércio, Contentamento, Conforto, etc.) - Plataforma UBEC 100. A Plataforma UBEC 100 é uma plataforma nova e catalítica principalmente para o domínio digital (o mundo digital). Quando algo é feito no domínio digital, isso implica que as informações originais (imagens, sons, vídeo etc.) foram convertidas para um formato digital e som manipuladas na memória do computado) com base em software e hardware, que usa dispositivos inteligentes (por exemplo, smartphones, computadores, dispositivos da Internet das Coisas, etc.). No entanto, seus usos também podem ser feitos em outros domínios (por exemplo, analógico, acústico etc.). O software e o hardware da plataforma UBEC 100 permitem que dispositivos inteligentes se conectem através da conectividade Wi-Fi hotspot (sem o uso da rede móvel tradicional), servindo assim como uma plataforma de comunicação global alternativa para que o dispositivo e seu usuário participem da sociedade da informação digital (usando as tecnologias de informação e comunicação digitais (TIC) ) . Dessa forma, permite que os proprietários de dispositivos digitais que possuem a Plataforma UBEC 100 (software e hardware) realizem todas as atividades digitais (incluindo a geração de renda, simplesmente permitindo o uso de seu dispositivo inteligente pela
Petição 870200056145, de 06/05/2020, pág. 108/1737
106/754
Plataforma UBEC 100) de uma maneira seguro, eficiente, legal, privado e controlado pelo usuário. A estrutura principal de definição da plataforma UBEC 100 é a BCHAIN (110 de conexão básica de harmonização de conexão). O BCHAIN 110 é um banco de dados distribuído que mantém uma lista crescente de registros organizados chamados blocos. O BCHAIN 110 é uma estrutura para a produção de Blockchain sofisticado (o componente principal da moeda digital bitcoin, onde serve como razão pública para aplicativos ativados publicamente (para comunicações, colaboração, transporte de informações, comércio, capital, interação, etc.), para dispositivos inteligentes interconectados. Portanto, o BCHAIN é uma estrutura nova e inovadora (personalizada e aprimorada) de Tecnologia da Informação e Comunicação (TIC) para lidar com o crescimento exponencial de dados e dispositivos com segurança e eficiência. A Plataforma UBEC 100 oferece uma ampla gama de serviços, como serviços financeiros, por meio da Troca Econômica Digital Criptográfica (CDEE) 705, (semelhante a uma troca de ativos com usuários que possuem ações, fundos mútuos, índices, coberturas, trocas, etc.), bem como uma criptomoeda com o símbolo -U(Unidades de Watts). O valor de um único -U- (Unidade de Watts) é derivado com base no algoritmo de moeda proprietário de 666 Watts, que usa Inteligência Artificial (AI - a teoria e o desenvolvimento de sistemas de computador capazes de executar tarefas que normalmente exigem inteligência humana, como percepção visual, reconhecimento de voz, tomada de decisão e tradução de idiomas) e os seguintes fatores como entrada/valor: 1. Economia de serviços da plataforma UBEC 100; 2. Economia da
Petição 870200056145, de 06/05/2020, pág. 109/1737
107/754 infraestrutura BCHAIN; 3. Energia; 4. Tempo; e 5. Recursos (forças de mercado etc.). As principais diferenças de -U(Unidade de Watts) em comparação com outras moedas são: 1. Criptografia pós-quantum; 2. Meios exclusivos de pagamento pelos Serviços UBEC; 3. Robustez da plataforma BCHAIN 110; 4. UBEC CDEE 705; 5. Contratos inteligentes de Inteligência Artificial; 6. Auto-inovação e Autoprogramação 130 (sem a necessidade de programadores centrais); 7. Autogovernança baseada no LUIGI 116; 8. Avaliação baseada em Inteligência Artificial (algoritmo); 8. CDEE 705, trabalhando em conjunto com outras trocas financeiras através da Federação Mundial de Trocas (WFE); e 9. Crescimento financeiro automático (usando LOM 132, MPG, UBEC NMC 114/13300 para investir no portfolio de produtos/serviços financeiros, preparação/mitigação legitima de impostos e planejamento/gerenciamento/geração de relatórios CDEE 705) para todas as entidades; 10. Aprimoramento perpétuo e automático da auto-programação de auto-inovação 130; 11. DMT (Rastreamento Mental Digital) 12700; e melhorando o mapeamento neurológico/Neuroeconómico (NME) 13090. A plataforma UBEC 100 usa Inteligência Artificial (IA), Inteligência Aumentada, Computação Cognitiva, Avanço de Inteligência de Recursos Simbióticos (SRIA) com Rastreamento mental DIGITAL (DMT) 12700 em ascensão continua (programação, emulação, adaptação e inteligência investigativa), Melhorando o mapeamento Neuroeconómico (NME)/Melhorando o mapeamento neurológico (NME) 13090, BCHAIN 110 (com criptografia, inteligência de adaptação, nós BCHAIN, protocolo BCHAIN 794, Gerenciamento da Integridade de dados da BCHAIN 1204), LUIGI (Legislação Independente de
Petição 870200056145, de 06/05/2020, pág. 110/1737
108/754
Inteligência Governamental do Governo UBEC) 116, Mineração Objetiva Lexical (LOM) 132, Metodologia para Doação Perpétua (MPG) 113, Satisfação Metafísica Neuroeconômica da UBEC (NMC) 114, Auto -Inovação da auto-programação 130 e indução e dedução (I2GE 122 e LIZARD 120) para permitir a economia mundial da informação digital (com conexões antecipadas de trilhões de dispositivos e trilhões de Zettabytes 10007/Yottabytes 10008 de dados nas próximas décadas) para servir a Sociedade da Informação Digital, fornecendo interconectividade universal entre tudo (coisas digitais conectadas, etc.) e tornando a todos um Cidadãos digitais em todos os lugares. A plataforma UBEC 100 é como um quebra-cabeça gigante. Todas as peças são feitas para interagir e se conectar, desde que não haja partes duplicadas e cada uma atinja seu objetivo, portanto, as partes são mapeadas para as Appchains 836. A manipulação bruta das Appchains (RAM) 6146 é um subconjunto significativo do Criador de Ecossistemas Customchain (CEB) 584, que é o núcleo da plataforma UBEC 100 e a harmonia das peças do quebra-cabeça da Appchain. O ecossistema no CEB 584 refere-se ao quebra-cabeça gigante. Portanto, a Manipulação da Appchain em Bruto (RAM) 6146 é o módulo que faz as modificações mais diretas nas peças do quebra-cabeça, enquanto os módulos que invocam o CEB 584, em conjunto com o CEB 584, decidem a configuração do mosaico do ecossistema Appchain (quebra-cabeça). Um forte exemplo disso é o SPSI 130, que modifica a peça do quebra-cabeça em uma escala macro. Vários métodos são usados para controlar a composição do quebra-cabeça, incluindo o Ajuste de Segmento Nulo (NSA) 6900, que é um módulo que busca tornar eficientes a atualização de novas informações no quebra-cabeça.
Petição 870200056145, de 06/05/2020, pág. 111/1737
109/754
A Internet das Coisas (ΙοΤ) 102 representa o ecossistema de dispositivos que interagem entre si por meio da conectividade digital. Tais dispositivos podem variar de geladeiras, termostatos, carros, garagens, portas, drones etc. Portanto, um Dispositivo de Hardware 104 que está operando a Plataforma UBEC 100 funcionará como um dispositivo ΙοΤ 102 dentro do Ecossistema ΙοΤ 102. O Usuário UBEC 106 é uma pessoa que tem suas informações biométricas registradas na Plataforma UBEC 100 através de Interação com o nó do usuário 470. Isso permite que o usuário 106 faça transações digitais relacionadas a informações e comércio a partir da plataforma 100 da UBEC. Portanto, o dispositivo de hardware 104 se conecta ao aplicativo/sistema 118 da UBEC, que é uma série de rotinas codificadas que conectam todos os vários submódulos a uma interface central. O Sistema/Aplicativo UBEC 118 e suas dependências enumeradas operam na rede BCHAIN (Harmonização de Conexão de Base Conectando Nós Integrados) 110. A Rede BCHAIN 110 é uma série de dispositivos ΙοΤ 102 conhecidos como Nós BCHAIN 78 6 que operam software de acordo com o Protocolo BCHAIN 794. Portanto, a Plataforma UBEC 100 opera com as características de descentralização de 786 nós, segurança criptográfica e retenção/otimização de dados de eficiência de roteamento através da adaptação artificial da rede BCHAIN 110. A operação eficiente de a Rede BCHAIN 110 é idealmente processada pelo chip UBMA 4260. Os submódulos e dependências na plataforma UBEC 100 operam como Appchains 836. As Appchains 836 são os programas de armazenamento de dados, serviço e computador que operam diretamente na camada de infraestrutura de rede. BCHAIN 110. A Metodologia para Doação Perpétua (MPG) 113 e
Petição 870200056145, de 06/05/2020, pág. 112/1737
110/754
Satisfação Metafísica Neuroeconômica (NMC) 114 são as Appchains 836 que tomam decisões de investimento artificialmente inteligentes na Plataforma UBEC 100. Tais decisões são tomadas para aproveitar as estipulações dos regulamentos financeiros (ex. leis tributárias). A Legislação de Inteligência Independente do Governo da UBEC (LUIGI) 116 é um mecanismo de aplicação artificialmente inteligente para implementar igualdade, equidade e justiça dentro dos limites da Plataforma UBEC 100. Para conseguir isso, o LUIGI 116 recebe um nível permanente e irrevogável de privilégios administrativos e executivos codificados na Plataforma UBEC 100. Para consolidar a concentração densa centralmente de poder autoritário existente no LUIGI 116, é programada e mantida exclusivamente pelo SPSI 130 para impedir absolutamente programadores maliciosos de realizar explorações. Ele também é hospedado exclusivamente na Rede Distribuída BCHAIN 110 para eliminar absolutamente a alavancagem de qualquer entidade ou organização do gerenciamento de seu hardware dependente. Portanto, os terceiros não conseguem fechar ou comprometer. A Autoinovação de Autoprogramação (SPSI) 130 é uma Appchain 836 que se programa automaticamente e outras Appchains na Plataforma UBEC que recebem a designação 'oficial'. Essa designação 'oficial' indica que a Appchain 836 é uma parte fundamental da operação da Plataforma UBEC 100. O LIZARD 120 é um algoritmo de monitoramento central capaz de bloquear todas as ameaças potenciais à segurança cibernética em tempo real, sem a ajuda direta de um banco de dados de crescimento dinâmico. A Mineração Objetiva Lexical (LOM) 132 é um algoritmo sofisticado que tenta chegar o mais próximo possível da resposta objetiva a
Petição 870200056145, de 06/05/2020, pág. 113/1737
111/754 uma ampla gama de perguntas e/ou declarações. Se envolve com o Usuário da UBEC 106 para permitir que concedam ou aprimorem seus argumentos contra a posição LOM 132. Conceder ou melhorar um argumento é a filosofia principal do LOM 132, pois deve ser capaz de admitir quando é errado. O conhecimento do usuário da UBEC 106, é onde ele obtém a maior parte de seu conhecimento em primeiro lugar. O Mecanismo de Investigação Automatizado (ARM) 134 tenta constantemente fornecer ao CKR 648 novas idéias para melhorar os recursos gerais de estimativa e tomada de decisão da 132 LOM. O Perfil de Inteligência Pessoal (PIP) 136 é o local onde as informações pessoais do Usuário UBEC 106 são armazenadas por meio de vários pontos de extremidade e front-ends em potencial. Suas informações são altamente seguras e isoladas do CKR 648; no entanto, elas estão disponíveis para a LOM 132 para realizar tomadas de decisões personalizadas. O Gerenciamento e Automação de Vida (LAA) 138 conecta vários dispositivos e serviços habilitados para BCHAIN 786 em uma plataforma que automatiza tarefas para rotinas de vida e incidentes isolados. O módulo de Monitoramento de Comportamento (BM) 140 monitora as solicitações de dados de identificação pessoal dos Usuários da UBEC 106 para verificar se há material antiético e/ou ilegal. A Privacidade Ética Legal (EPL) 142 recebe uma lista negra personalizada do MSNP 126 e usa o Sistema de substituição de suposições (AOS) 148 para bloquear qualquer reivindicação que contenha material antiético, sensível à privacidade e/ou ilegal. A Digitalização STD 144 analisa o STD quanto a novos conteúdos (aos quais o sistema ainda não foi exposto) . Isso ajuda a CKR 648 a rastrear as expectativas de fonte de dados/asserção, o que
Petição 870200056145, de 06/05/2020, pág. 114/1737
112/754 também ajuda o LOM 132 a detectar asserções corroborativas. A Construção de Afirmação (CA) 148 recebe uma proposta na forma de uma afirmação ou pergunta e fornece resultados dos conceitos relacionados à referida proposição. 0 Mapeamento Hierárquico (HM) 150 atribui conceitos associados à descoberta de corroboração ou conflito na coerência da pergunta/afirmação. Em seguida, calcula os benefícios e os riscos de ter uma certa posição sobre o assunto. Aplicativos e Serviços de Terceiros 152, algoritmos de terceiros 154 e fontes de informação 156 se comunicam com o LOM 132 .
[375] A Fig. 2 expande os detalhes de aplicativos e serviços de terceiros 152 e algoritmos de terceiros 154. Os aplicativos e serviços de terceiros 152 contêm Comércio 156, Pesquisa 158, Medicina 160, Transporte 162, Educação 164 e Comunicações 166. Os Algoritmos de terceiros 154 são uma coleção de tecnologia proprietária que é desenvolvida e mantida pelos Usuários na UBEC 106 na plataforma UBEC 100, que oferecem serviços técnicos que melhoram a operação e a funcionalidade do LOM 132 e, portanto, do UBEC 118. O Algoritmo de Inteligência Emocional 168 pode detectar várias emoções humanas por meio de transmissões de câmera, expressões faciais como padrões de voz que foram reconhecidos pelo algoritmo de reconhecimento de voz 172. O algoritmo de Reconhecimento de Voz 172 pode transcrever palavras faladas em texto. O algoritmo de Digitalização de Retina 174 compreende as estruturas do olho humano que complementam os usos da autenticação de segurança, como Interação com o nó do usuário (UNI) 470. O Algoritmo de Tradução de Idiomas 176 converte automaticamente frases, citações e palavras entre uma
Petição 870200056145, de 06/05/2020, pág. 115/1737
113/754 variedade de idiomas, permitindo o comércio e a comunicação dentro da Plataforma UBEC 100. O Algoritmo de Reconhecimento Facial 178 compreende as estruturas relacionadas ao rosto humano que complementam os usos da autenticação de segurança, como com a Interação com o Nó do Usuário (UNI) 470. O Algoritmo de Amostragem de DNA 180 pode processar sequências genéticas extraídas de amostras humanas, como cabelo, pele ou saliva. Isso complementa os usos da autenticação de segurança, como a Interação com o nó do Usuário (UNI) 470 e a investigação teórica processada pelo LOM 132 para resolver mistérios, verificar conspirações etc. O algoritmo de reconhecimento de impressão digital 182 compreende as estruturas de impressão digital que complementam os usos da autenticação de segurança, como na UNI 470. O algoritmo da 'Predição' 184 analisa o enorme comportamento social para afirmar previsões sobre o resultado do evento social com diferentes graus de confiança. Esses graus de confiança geralmente variam de acordo com a riqueza e a densidade dos dados disponibilizados pelo Algoritmo 184. O Algoritmo de Stylometria 186 analisa o uso de palavras e os recursos físicos de escrita manual dos textos para decifrar uma assinatura sutil deixada pelo verdadeiro autor deste texto. Isso permite que o LOM 132 resolva misteriosamente, verifique conspirações etc.
[376] [00] Figs. 3-6 mostram o mecanismo de implantação automatizada para implantar a Plataforma UBEC 100 como um Aplicativo 216 em vários dispositivos de hardware. O SPSI 130 envia atualizações de software, firmware e hardware para a estrutura Código principal da UBEC 100 no cenário 188. As atualizações de hardware referenciam uma possível iteração futura
Petição 870200056145, de 06/05/2020, pág. 116/1737
114/754 da Arquitetura de microchip da UBEC na BCHAIN 42 60 (UBMA) que pode alterar dinamicamente seu próprio conjunto de microprocessadores por meio de estruturas dinâmicas de condutores. A Plataforma UBEC 100 possui sua própria Base de Código 192 diferente, que é diferente, mas depende diretamente e colabora com o Protocolo BCHAIN 794 e sua Base de Código 196. Ambas as Bases de Código 192 e 196 se conectam diretamente à Interface de Plug-in Modular 194, que atua como software de middleware para garantir uma execução compatível das bases de código 192 e 196 nos diferentes sistemas operacionais e de hardware dos nós BCHAIN 786. O Lógica de Núcleo Híbrido 190 é implementada a partir de várias rotinas de implementação 198, 200 e 202. A rotina de implantação 198-202 apropriada é selecionada de acordo com o hardware correlacionado e a composição do sistema operacional do nó BCHAIN selecionado.
[377] A Fig. 4 mostra o layout detalhado da Rotina de Implantação 198, otimizada para dispositivos Apple iOS. No estágio 206, o SPSI 130 prepara a lógica hibridizada básica para implementação na Apple iOS App Store. Esta etapa 206 inicia a Rotina de implantação A 198 e, posteriormente, invoca a Etapa 210, que invoca o SPSI 130 para atualizar os Controladores de interface A 212 para cumprir totalmente as especificações relevantes e atualizadas. No estágio 208, o SPSI 130 instala os drivers de interface 212 na Lógica de Núcleo Híbrido 190. Mais especificamente, os drivers de interface A são instalados como um Plugin da Interface Modular 194, permitindo que a plataforma 100 da UBEC codifique o código base 192 e a base de código 196 do Protocolo BCHAIN 794 para interagir com o Nó BCHAIN 786, o
Petição 870200056145, de 06/05/2020, pág. 117/1737
115/754 hardware e o sistema operacional compilado no aplicativo UBEC/BCHAIN 216. Esta Inscrição 216 está pronto para implantação no momento na Apple iOS 218 App Store. 0 SPSI 130 envia ο aplicativo UBEC/BCHAIN 216 para a Apple iOS 220 App Store no estágio 218.
[378] Na Figura 5, o SPSI 130 inicia no Estágio 222 o mesmo procedimento usado para compilar e enviar o aplicativo UBEC / BCHAIN 216 para a Apple iOS 220 App Store, mas para a Google Play Store 234. Portanto, um conjunto diferente de controladores de interface B 228 é usado de acordo com as especificações da API do Android 230, conforme programado pelo SPSI 130. Os controladores de Interface B são conectados à interface de plugin modular 194 para fazer a compilação do aplicativo UBEC/BCHAIN 216 que agora foi otimizada para sua execução e uso no ecossistema do Google Play Store 234. Portanto, a instância do aplicativo UBEC/BCHAIN 216 na rotina de Implantação A 198 mantém o mesmo Codifique as bases 192 e 196 como a instância da rotina de implantação B 200.
[379] Na Fig. 6, a Rotina de implantação C 202 segue um padrão semelhante às Rotinas A 198 e B 200, no entanto, difere em vez de serem usadas as Especificações 214 e 230 da App Store, Especificações diretas de hardware para smartphones 244 que são referenciados pelo SPSI 130 para produzir os Controladores de Interface C 242. Portanto, o sistema operacional UBEC/BCHAIN 217 resultante é um sistema operacional completo capaz de interagir diretamente com a Unidade Central de Processamento (CPU), Unidade de Processamento Gráfico (GPUs), Memória de Acesso Aleatório (RAM) etc. O SPSI envia a atualização para uma Appchain 836 na
Petição 870200056145, de 06/05/2020, pág. 118/1737
116/754 rede BCHAIN 110 que serve a versão mais recente do Sistema Operacional (OS) 217. Portanto, os Smartphones que já possuem o um OS UBEC 217 pré-instalado executam o mecanismo de atualização tradicional com um ponto de acesso do servidor para uma versão oficial e criptografada do OS 217. O aspecto não tradicional do mecanismo de atualização do SO 217 na Etapa 246 é que os arquivos do 217 OS são hospedados de forma descentralizada na rede BCHAIN 110 .
[380] [00] A Fig. 7 mostra um exemplo de caso de uso do usuário Layman interagindo com a plataforma UBEC 100 pela primeira vez. No estágio 250, o usuário Layman pretende ingressar na economia digital. Nesta fase 250, os bens do usuário Layman estão listados no suplemento 284 como um smartphone. No estágio 252, o Usuário Layman baixa o aplicativo UBEC da App Store relevante que o smartphone executa (por exemplo, Apple App Store, Android Play Store etc.). Portanto, o suplemento 286 indica que o usuário Layman agora possui um smartphone habilitado para UBEC, em vez de um smartphone normal do suplemento 284. Essa é uma alteração significativa, pois a execução da plataforma UBEC 100 no smartphone do Usuário Layman permite uma ampla gama de novos recursos e medidas de interação que permitem que o Usuário Layman se torne um 'Usuário Digital'. Na Etapa 254, o Aplicativo UBEC 118 faz perguntas rudimentares sobre as ambições e ativos do Usuário Layman. Com consentimento prévio, o Usuário Layman grava um feed de video ao vivo de sua propriedade, ativos e condição de estilo de vida processados pelo UBEC 118. No estágio 256; Ao concluir a análise realizada pelo LOM 132, o Aplicativo UBEC 118 recomenda que o Usuário Layman venda um ativo xyz para comprar
Petição 870200056145, de 06/05/2020, pág. 119/1737
117/754 três drones habilitados para 100 UBEC. No estágio 258, como o usuário Layman não possui nenhum meio de pagamento eletrônico, a UBEC solicita três drones através do serviço de back-end 132 da LOM e opta pelo pagamento em dinheiro ao pessoal de entrega. No estágio 260; mediante pagamento e recebimento dos drones, o Usuário Layman segue as instruções do aplicativo UBEC 118 para digitalizar os códigos QR gravados a laser dos drones com o aplicativo UBEC 118. Portanto, o suplemento 288 indica que o Usuário Layman agora possui um smartphone habilitado para UBEC, além dos três drones recém-registrados para UBEC. No estágio 262, os três drones imediatamente e automaticamente começam a digitalizar a propriedade do Usuário Layman através de suas câmeras 3D (Prontas para a Realidade Virtual).
[381] Isso permite que o LOM 132 seja constantemente atualizado sobre assuntos dentro da propriedade Usuário Layman, resultando em uma resposta mais calibrada do LOM 132 e assistência com experiência. No estágio 264, todos os três drones imediatamente e automaticamente começam a rotear pacotes do protocolo BCHAIN 794 da vizinhança, portanto, concedendo ao Usuário Layman acesso direto à rede BCHAIN 110. Na etapa 266; Como o Usuário Layman agora tem conectividade com a rede BCHAIN 110, o UBEC 118 recomenda que cancele o plano da companhia telefônica e remova o cartão SIM do telefone. Portanto, o suplemento 290 indica que o Usuário Layman economizou dinheiro cancelando pagamentos subsequentes da companhia telefônica. No estágio 268, o UBEC 118 sabe que o Usuário Layman usaria sua motocicleta antiga para ir à cidade uma vez por mês para pagar em dinheiro seu cartão SIM pré-pago. Portanto, a UBEC 118
Petição 870200056145, de 06/05/2020, pág. 120/1737
118/754 recomenda que venda sua motocicleta e compre uma bicicleta. Portanto, o suplemento 292 indica ainda que o Usuário Layman obteve lucro depois de vender sua motocicleta e comprar uma bicicleta. No estágio 270, o UBEC como Usuário Layman pode usar a rede BCHAIN 110 para fazer ligações internacionais extremamente acessíveis para seu irmão, que liga toda semana que ele mora em seu país. Portanto, o suplemento 294 indica que o Usuário Layman também obteve economia de dinheiro por não ter que gastar dinheiro em chamadas internacionais por meio de sistemas de telefone e VoIP herdados. No estágio 272, o UBEC 118 informa, por meio do LOM 132, a mineração de dados centralizada de que a localização da casa do Usuário Layman é relativamente próxima a uma rodovia de drones, onde as recargas e manutenção/reparo de drones são muito procuradas. No estágio 274, a UBEC recomenda ao Usuário Layman a compra de uma estação de ancoragem para drones com capacidade para dezesseis drones por vez e um kit de reparo. O UBEC 118 baseia essa recomendação no orçamento do Usuário Layman. Portanto, o UBEC 118 recomenda que o Usuário Layman adquira os itens mencionados usando o dinheiro ganho com a venda de sua motocicleta. No estágio 276, o Usuário Layman aprova e, portanto, o UBEC 118 a LOM 132 solicita a estação de ancoragem e o kit de reparo de serviços com as melhores classificações, o melhor preço para o Usuário Layman e o vendedor mais online confiável. No estágio 278, o Usuário Layman recebe os itens e paga em dinheiro. Digitaliza códigos QR gravados a laser em produtos com o aplicativo UBEC 118 no seu smartphone. Posteriormente, no Estágio 280, a Plataforma UBEC 100 e, portanto, a Rede BCHAIN 110 gerencia automaticamente a
Petição 870200056145, de 06/05/2020, pág. 121/1737
119/754 comunicação dos Drones do Usuário Layman e da estação de ancoragem com os drones da estrada de drones nas proximidades. No estágio 282, o Usuário Layman agora desfruta de um beneficio obtido revendendo sua eletricidade e serviço de reparo automatizado de drones para outros drones. Ele retém benefícios em -U- (Unidades de Watts) e os gasta diretamente na plataforma UBEC 100 para bens e serviços necessários, às vezes iniciados por uma recomendação da UBEC 118 através da LOM 132, levando em consideração seu contexto e situação.
[382] [00] Figs. 8-10 mostra, um Usuário não Layman interagindo com o UBEC 118 para gerenciar sua saúde pessoal.
[383] Na Fig. 8, a Etapa 296 descreve o usuário que opera o smartphone executando a Plataforma UBEC 100 nativamente como um Sistema operacional 217. Na Etapa 298, o Usuário usa um relógio inteligente habilitado para UBEC 100 que detecta constantemente a temperatura corporal, batimentos cardíacos, suor etc. O estágio 300 descreve como todos os dados pessoais de saúde do usuário do UBEC 100 smartwatch são armazenados em um PIP (Perfil de Inteligência Pessoal) 136 individual. No estágio 302, o LOM 132 faz referência ao conhecimento que aprendeu sobre medicina, que em parte veio da execução do Appchain 836 do Mecanismo de Investigação Automatizada (ARM) 134, com os dados pessoais de saúde armazenados no Appchain 836 PIP 136. No estágio 304, o LOM 132 realiza uma análise de dados de referência cruzada tão profunda da Etapa 302 aproveitando a eficiência resultante da Inteligência Adaptativa do Protocolo BCHAIN 794. Na Etapa 306, o LOM 132 observa um padrão nos dados de saúde pessoal do Usuário armazenados no PIP 136, indicando que há uma probabilidade de
Petição 870200056145, de 06/05/2020, pág. 122/1737
120/754
80% de o Usuário capturar o vírus da gripe sazonal. No Estágio 308, a LOM 132 analisa a programação esperada do Usuário para a próxima semana para entender qualquer conflito e consequência potencialmente significativa se o Usuário ficar doente. No estágio 310, a LOM 132 percebe que havería consequências muito negativas se o usuário adoecesse esta semana. No estágio 312, o LOM 132 cria uma percepção do local esperado em que o usuário deve estar nos próximos três dias. No Estágio 314, o LOM 132 localiza os consultórios médicos perto do local esperado do Usuário através de vários dos melhores e mais atualizados diretórios existentes na Plataforma UBEC 100 e na Internet. No estágio 316, o LOM 132 elimina todos os candidatos a consultórios médicos que não oferecem suporte à cobertura de seguro de saúde do usuário. No estágio 318, a LOM 132 verifica a disponibilidade de compromissos para os demais candidatos do consultório médico por meio de diretórios da plataforma UBEC 100 e da Internet. No estágio 320, o LOM 132, por meio da plataforma UBEC 100, juntamente com a rede BCHAIN 110, tenta fazer uma ligação telefônica com os candidatos para confirmar a disponibilidade do horário da consulta. Portanto, o processo automatizado de chamada telefônica 332 é iniciado. No estágio 322; Considerando que as Informações Aprendidas 333 das várias chamadas telefônicas feitas, o LOM 132 seleciona um candidato e o horário para marcar uma consulta. No estágio 324, o LOM 132 inicia uma chamada telefônica para marcar a consulta e envia com segurança as informações sobre seguro de saúde, pagamento e entrega de produtos farmacêuticos ao candidato selecionado. No estágio 326, devido à sensibilidade temporal do potencial dilema da doença do
Petição 870200056145, de 06/05/2020, pág. 123/1737
121/754 usuário, o LOM 132 agendou a consulta mais cedo possível. No Estágio 328, devido às permissões de controle preexistentes concedidas aos dispositivos 100 habilitados para o usuário da UBEC Platform 100 e UBEC 786, o LOM 132 instrui o veículo com o motorista a automatizar que ele está levando o usuário a fazer um desvio e dirigir até o escritório do médico selecionado para marcar a consulta. Portanto, a LOM 132 estimou que a maior prioridade é que o Usuário vá imediatamente ao médico em vez de trabalhar, devido às possíveis consequências da não aplicação de medidas médicas preventivas. No final da nomeação do estágio 330, o LOM 132 inicializa uma ligação telefônica 332 para a farmácia para organizar a entrega ou coleta de medicamentos.
[384] A Fig. 9 mostra o Fluxo Lógico detalhado do processo de chamada telefônica automatizada 332 realizado pelo LOM 132 através da Plataforma UBEC 100 e da Rede BCHAIN 110. O processo 332 é inicializado com uma lista de candidatos 334 que é subsequentemente iterada por meio de um Loop de programação 336. A etapa 338 verifica se o candidato selecionado do Loop 336 está presente no diretório da Plataforma UBEC 100. Se uma condição Yes 98 ocorrer em relação ao estágio 338, o fluxo lógico continuará no estágio 342, enquanto uma condição No 96 leva ao estágio 340. O estágio 340 faz uma verificação semelhante ao estágio 338, exceto pelas referências existentes na Internet, em vez da plataforma UBEC 100 e da rede BCHAIN 110. Sim o estágio 340 resulta em uma condição Yes 90, o fluxo lógico continua na Etapa 342. Se a Etapa 340 resultar em uma condição No 88, o fluxo lógico continuará na Etapa 337. A Etapa 337 remove o candidato selecionado no Loop de Candidato 336 e itera o Loop
Petição 870200056145, de 06/05/2020, pág. 124/1737
122/754
336 para o próximo candidato disponível (se houver). Se nenhum candidato estiver disponível na Lista de Candidatos 334, a execução modular do Processo 332 será encerrada. 0 estágio 342 verifica se o candidato selecionado do Loop 336 possui um número de telefone listado na Plataforma UBEC 100 e, portanto, através do Protocolo BCHAIN 794. Se o estágio 342 resultar em uma condição Yes 94, o fluxo lógico continuará para o estágio 346. Se o estágio 342 levar a uma condição No 92, o fluxo lógico continuará para o estágio 344. O estágio 344 executa uma verificação semelhante ao número do candidato selecionado, exceto pelo fato de verificar se há um número de telefone operando no sistema telefônico legado. Se a Etapa 344 resultar em uma condição Yes 86, o fluxo lógico continuará na Etapa 346, enquanto uma condição No 84 levará à Etapa 337, que itera o Loop 336. A Etapa 346 disca o número de telefone selecionado através do protocolo correspondente, da rede BCHAIN 110 ou da rede herdada. Após o início bem-sucedido da ligação, a Etapa 348 torna a ligação por meio de algoritmos e tecnologias disponibilizados por vários terceiros nas Unidades de Aplicação de Terceiros 350. Essas unidades 350 podem incluir algoritmos de reconhecimento de fala, algoritmos de síntese de fala, análise linguística conversacional etc. Após a conclusão da conversa realizada no Estágio 348, a Informação aprendida 333 sobre o conteúdo da chamada é apresentada como uma saída modular.
[385] A Fig. 10 mostra o LOM 132 como uma Appchain 836 operando várias funções que gerenciam a saúde pessoal como um Assistente Pessoal Artificialmente Inteligente. A LOM 132 faz referências processuais ao Perfil de Inteligência Pessoal (PIP)
Petição 870200056145, de 06/05/2020, pág. 125/1737
123/754
136, bem como à Administração e Automação da Vida (LAA) 138. 0 caso 352 é definido como pedindo receitas futuras e recomendando vitaminas. 0 PIP 136 armazenará com segurança qualquer informação pessoal sobre receitas futuras devido a condições conhecidas etc. 0 LOM 132 pode então se referir às referidas informações pessoais e seu conhecimento médico genérico armazenado na Retenção Central do Conhecimento (CKR) 648, e informações relacionadas a provedores externos para recomendar às vitimas disponíveis no Caso 352. 0 Quase 354 é definido como monitoramento diário dos principais parâmetros de saúde por meio da interação com aplicativos de terceiros. Aplicativos e Serviços de terceiros 154 que se conectam ao LOM 132 através do LAA 138 podem ser usados para monitorar parâmetros de saúde, como pressão arterial etc. 0 caso 356 é definido como programação de rotina de exercícios de saúde/condicionamento físico. Informações pessoais sobre horários, hábitos e rotinas são armazenadas no PIP 136 e, portanto, o LOM 132 pode estimar os horários e rotinas ideais que são adaptados ao Usuário do UBEC 106. O caso 358 é definido como Recomendações de dieta e recomendações de compra de alimentos. As informações sobre o metabolismo, peso, altura e condições de saúde do Usuário 106 são armazenadas em uma instância do PIP 136 como uma Appchain 836. Portanto, o LOM 132 pode se referir ao seu conhecimento médico armazenado no CKR 648 e o LAA 138 pode posteriormente, faça a compra de alimentos por meio de serviços de back-end que foram disponibilizados a eles. O caso 360 é definido como Agendamento de verificações futuras de acompanhamento, que se refere ao PIP 136 e LAA 138, cuja operação leva ao início do
Petição 870200056145, de 06/05/2020, pág. 126/1737
124/754 processo Automatizado de Chamada Telefônica 332. 0 caso 362 é definido como Atuando como técnico de saúde em todos os aspectos das atividades da UBEC, que faz uma grande referência às informações pessoais armazenadas no PIP 136, conhecimentos gerais armazenados no CKR 648 e a interconectividade de informações, dispositivos e serviços no LAA 138. 0 caso 364 é Recomendações para gerenciamento de estresse. Como o LOM 132 tem acesso a informações relacionadas à agenda de alguém, o LOM 136 pode ver situações estressantes que surgem interpretando várias variáveis que são esperadas para o futuro. Portanto, o LOM 132 pode fornecer recomendações ao usuário do UBEC 106 por meio do aplicativo UBEC 118 para gerenciar grandes cargas de trabalho e situações dificeis/complexas. O Caso 366 é definido como Recomendações de Hobby/Trabalho/Estilo de Vida, que se refere à capacidade do LOM 132 de interpretar agendas e recomendar sugestões inteligentes que aumentam a satisfação geral e de longo prazo do Usuário UBEC 106.
[386] [00] Figs. 11-21 articulam detalhes sobre a mecânica interna do LUIGI 116.
[387] Nas Figs. 11 e 12, o Passagem da UBEC 368 recebe informações sobre o tráfego que está acontecendo do UBEC como uma Appchain 118. Após a análise das referidas informações passadas, ele é retornado ao UBEC como uma Appchain 118 através do Retorno Integral UBEC 388 para continuar sua jornada em encaminhar e alcançar o destino pretendido na plataforma UBEC 100. As informações inseridas no Passagem da UBEC 368 são encaminhadas para a Força-Tarefa LUIGI (LTD) 370, que determina se os dados devem ser processados pelo LOM 132, LIZARD 120 ou
Petição 870200056145, de 06/05/2020, pág. 127/1737
125/754 ambos. A decisão de Delegação de Tarefas 370 é tomada levando em consideração o tipo de dados recebidos, bem como as capacidades do LOM 132 e do LIZARD 120. Portanto, o LTD 370 para delegação de processamento de dados é delegado nas Consultas de Conhecimento e Arbitragem O Judiciário 372, que representa a LOM 132, ou o Aplicativo Jurisdicional e Leitor de Intenções 376, que representa o LIZARD 120. A personalização dinâmica da API (DAC) 384 permite a operação dos módulos 372 e 376 Interpretação do tipo de tarefa 408 para uso O correto do LOM 132 e do LIZARD 120 pode ser implementado.
[388] As Figs. 13 e 14 contêm um diagrama detalhado do DAC 384, mostrando como o uso da API LIZARD 402 e o uso da API LOM 404 das especificações são definidos pelos próprias Appchains. Isso permite que um Conjunto de Instruções Modular 416 seja produzido por meio da consideração 384 do DAC do tipo de tarefa na Etapa 408. O Conjunto de Instruções Modular 416 produzido pelo Leitor Jurisdicional de Aplicativos e Intenção 376 relata o LIZARD 120 na Entrada LIZARD 414 sobre como processar o conjunto de dados da Tarefa 412 Corretamente. Portanto, a Execução Modular 418 da LIZARD ocorre levando a uma Saida 420 da LIZARD precisa e apropriada. Tais decisões e/ou estimativas alcançadas pelo LIZARD 120 durante a Execução Modular 418 são encaminhadas para a Unificação Inteligente de Conclusão (UTI) para consideração de decisões alternativas e/ou estimativas processadas pelo LOM 132 em paralelo. Posteriormente, a Ação Corretiva LUIGI (LCA) 378 pode ser invocada para gerenciar adequadamente os eventos e transações de acesso a informações
Petição 870200056145, de 06/05/2020, pág. 128/1737
126/754 que estão ocorrendo na Plataforma UBEC 100. O mesmo padrão de processamento de informações que ocorre para LIZARD 120 na Fig. 13 ocorre para o LOM 132 na Fig. 14. Um DAC 384 fornece um Conjunto de Instruções Modular semelhante 416, permitindo que a Entrada 422 do LOM receba e processe o Conjunto de Dados de Tarefa 412 de entrada da Recepção de Tarefas 410. Esse processamento de informações leva ao processamento de conclusões na UTI 374, o que pode levar à promulgação de medidas corretivas na LCA 378.
[389] A Fig. 15 mostra as funções de manipulação de liquidez monetária pertencentes exclusivamente ao LUIGI 116 na Manipulação de liquidez financeira 382. O Enclave Seguro LUIGI (LSE) 380 é uma zona segura de retenção de informações que somente o LUIGI 116 pode acessar. Portanto, não há possibilidade teórica para observadores humanos do conteúdo do LSE 380, pois as permissões para escrever o código LUIGI 116 pertencem exclusivamente ao SPSI 130 e as permissões para executar o código LUIGI 116 pertencem exclusivamente ao LUIGI 116. No LSE 380, existem uma Chave de Retenção de Descriptografia 394 que permite ao LUIGI 116 Descriptografar a Retenção Criptografada de Chaves Privadas 396. Isso permite que o Mecanismo de Manipulação de Fundos (FMM) 400 manipule fundos na Economia de 862 Watts da Metachain 834 em uma sessão de recuperação de fundos. O Governador de Liquidez Watt (WLG) 390 é um subconjunto do LUIGI 116 que monitora e potencialmente bloqueia picos excessivos nos movimentos de liquidez dentro e fora do UBEC 100. Isso garante uma economia gradual e previsível dentro do UBEC 100. O Monitoramento de Movimentação de Fundos (FMO) 392 é um módulo de
Petição 870200056145, de 06/05/2020, pág. 129/1737
127/754 subconjunto do LUIGI 116 que monitora e potencialmente bloqueia movimentos de liquidez correlacionados com fraudes. 0 Mecanismo de Recuperação de Fundos (FRM) 398 é um módulo de subconjunto do LUIGI 116 que permite aos proprietários legítimos dos fundos U- (Unidade de Watts) reivindicá-los da Economia de 862 Watts da Metachain 834 se eles foram perdidos, roubados ou mal manuseado. A Prova de Autoridade 402 é uma chave criptográfica exclusiva que é garantida Criptograficamente que só pode ser produzida pelo LUIGI 116 devido à logística LSE 380. Portanto, a Prova de Autoridade 402 é usada para invocar um Chip UBMA 42 60 para fornecer sua Chave Privada Segurança Sensível Exclusiva 4314, como ilustrado nas Figs. 362 e 363.
[390] A Fig. 16 mostra a funcionalidade do LUIGI 116 para executar a Verificação da apresentação + manutenção de Appchains 426. Na etapa 428, uma nova solicitação ou uma atualização de uma solicitação existente é enviada à UBEC App Store. A partir da Etapa 430, é executado quando o LUIGI 116 usa a tecnologia LIZARD 120 para identificar padrões de jurisdição corretos, para que possa entender se um aplicativo é necessário no UBEC 110 ou não. Portanto, isso se manifesta quando a Delegação de Tarefas LUIGI (LTD) 370 recebe essas informações em conexão com uma nova solicitação de Passagem da BEC 368. O Aplicativo Jurisdicional e o Leitor de Intenções 37 6, que é um contêiner lógico para a execução de LIZARD 120, pode estimar se a confirmação da solicitação deve ser Aprovada ou Bloqueada. Portanto, a Etapa 432 indica que o LUIGI 116 bloqueia ou aprova o envio da solicitação, que é uma execução manifestada na Ação corretiva da LUIGI (LCA) 378.
Petição 870200056145, de 06/05/2020, pág. 130/1737
128/754
[391] A Fig. 17 mostra a funcionalidade do LUIGI 116 para executar a Verificação das condições contratuais 434. Na etapa 436, o LUIGI 116 processa uma condição derivada do conhecimento em um contrato. Na etapa 438, o LUIGI 116 usa a tecnologia LOM 132 para interpretar se uma condição foi ou não atendida. Por exemplo, isso pode verificar se uma pessoa faleceu, executando as solicitações listadas em Última Vontade e Vontade Digital. 0 LOM 132 é capaz de perceber essas realizações de condições aproveitando seu conhecimento genérico em CKR 648, conhecimento pessoal em instâncias PIP 136 e informações externas (que eventualmente são integradas em CKR 648) através do ARM 134. Portanto, no Estágio 440 LUIGI 116 processa o contrato de acordo com a resposta dada por LOM 132. A Fig. 18 mostra a funcionalidade do LUIGI 116 como um sistema de apelação para resolução de conflitos 442. Na etapa 444, o LUIGI 116 coleta e valida informações sobre uma disputa transacional. Portanto, na Etapa 446, o LUIGI 116 usa a tecnologia LOM 132 para obter um possível veredicto sobre o assunto. O processo de execução relativa no Estágio 446 ocorre nas Consultas de Conhecimento e Arbitragem Judicial 372 na Figura 14. Portanto, no Estágio 448, o LUIGI 116 aplica as consequências relacionadas à disputa de acordo com uma decisão altamente confiável dada por LOM 132 . O processo de execução relacionado à Etapa 448 ocorre na Ação Corretiva (LCA) LUIGI 378.
[392] A figura 19 mostra a capacidade do LUIGI 116 em relação à Interação do nó do usuário com o monitoramento do comportamento da ofuscação virtual. Na Etapa 452, um usuário se autentica na Plataforma 100 do UBEC por meio da Interação com o
Petição 870200056145, de 06/05/2020, pág. 131/1737
129/754
Nó do Usuário (UNI) 470. O LUIGI 116 pode, posteriormente, aproveitar perfeitamente a tecnologia LIZARD 120 para ofuscar virtualmente o Usuário 106 de a plataforma UBEC 100 real, de acordo com os poderes de comportamento malicioso, conforme indicado na Etapa 454.
[393] A Fig. 20 mostra a funcionalidade do LUIGI 116 em relação à Verificação de rastreamento de combinação da Appchain 456. Na etapa 458, duas versões de uma Appchain são mescladas através do processo definido em Sincronização e Reconciliação da Customchain (CSR) 1208. No Estágio 460, o Rastreamento de Eventos de Combinação (MET) 1836 faixas das quais os Nós BCHAIN 786 participaram da combinação. Na Etapa 462, o comportamento subsequente desses nós envolvidos é rastreado para potencialmente reverter essa combinação se uma conspiração maliciosa for detectada.
[394] A Fig. 21 mostra a funcionalidade do LUIGI 116 em relação à Recuperação de fundos perdidos e reversão de atividades fraudulentas. Com as moedas típicas de blockchain, não há mecanismo de recuperação de fundos que foram perdidos devido ao mau gerenciamento da chave, corrupção de dados etc. As -U- (Unidades de Watt) são recuperáveis recorrendo a um sistema LUIGI de recuperação inteligente conhecido como Mecanismo de recuperação de fundos (FRM) 398. Inicialmente na etapa 466, um usuário faz uma reivindicação de propriedade referente aos fundos para o você não tem acesso. Posteriormente, na Etapa 468, o LUIGI 116 usa seu módulo FRM 398 interno para verificar a veracidade de tal reivindicação. O módulo FRM 398 conta com a tecnologia de autenticação da Interface do Nó do Usuário (UNI) 470 e a
Petição 870200056145, de 06/05/2020, pág. 132/1737
130/754 tecnologia de reconciliação de conhecimento do LOM 132.
[395] [00] Figs. 22-26 mostram a funcionalidade da Interação do Nó do Usuário (UNI) 470. UNI 470 é o mecanismo de Gerenciamento de Identidade e Acesso (IAM) do UBEC 118 que usa dados biométricos diretos para autenticação e não faz referência a nenhum Contêiner de Conta de Usuário. Nós, dados e serviços estão diretamente vinculados aos dados biométricos do usuário para melhorar a segurança e simplificar as rotinas. Inicialmente, o Usuário do UBEC 106 fornece fluxos de dados para o UNI 470 que contêm dados de reconhecimento biométrico medidos na Etapa 472. Esses dados biométricos podem incluir, e não estão limitados a: Impressões digitais 474, retina ocular 476, reconhecimento de voz 478 e amostras de DNA de Cabelos/Pele etc. 480. Com o reconhecimento de voz, o usuário UBEC 106 é obrigado a pronunciar uma sentença contestada gerada aleatoriamente para atenuar tentativas de um ator mal-intencionado usando gravações de voz para tentar entrar ilegalmente na plataforma UBEC 100. Os dados biométricos fornecidos são transferidos para o Categorização de bandas biométricas (BBC) 482, que cria uma versão arredondada dos dados que elimina variações na medição de dados biométricos devido a margens de erro no equipamento de medição de dados biométricos. Portanto, cada entrada de dados biométricos na BBC 482 produz como saida um correspondente Token de autorização BAT (BAT) 484. Em seguida, é feita uma comparação entre o BAT 484 recém-gerado e os tokens de autenticação armazenados na Appchain de Associação de Banda conforme indicado na Etapa 486. O UNI 470 emprega inerentemente a autenticação multifatorial, portanto, é necessário mais de um método de autenticação biométrica antes
Petição 870200056145, de 06/05/2020, pág. 133/1737
131/754 que a permissão de login possa ser concedida.
[396] Fig. 23 na etapa 490, a quantidade de dados biométricos fornecidos é medida e verificada se é suficiente para o processo de autenticação. O limite mínimo de dados biométricos necessários para autenticação é definido na Política de Código Estático (SHP) 488. Na condição 96 Não, a quantidade não é suficiente quando é atendida; a tentativa de autenticação é rejeitada e, portanto, a execução modular do UNI 470 termina como indicado na Etapa 496. Na condição 98 que Sim, a quantidade é suficiente for atendida, o fluxo lógico chamará a Categorização de Bandas biométricas (BBC) 482 para cada instância da entrada de dados biométricos 472. Após a execução bem-sucedida da BBC 482, a Associação de bandas e nós Appchain é atualizada do ecossistema Customchain na etapa 494. Após a conclusão bemsucedida do estágio 494 uma verificação é realizada na Etapa 486 para medir se um número suficiente de BAT 484 corresponde a um Token de autenticação 514. A quantidade considerada suficiente é definida na Política de codificação estática (SHP) 488.
[397] A Fig. 24 continua o fluxo lógico do estágio 494, em que a Associação de bandas e nós da Appchain é atualizada do Ecossistema Customchain 540 através do protocolo BCHAIN 794. Isso garante que as informações de autenticação mais precisas e atualizadas estejam disponíveis para o processo de autenticação. Portanto, a Appchain de Associação de Banda 500 e a Appchain de Associação de Nós 502 são atualizadas e armazenadas localmente no Nó (próprio) que está executando o procedimento UNI 47 0. Portanto, na Etapa 486, verifica se existe um somente token de autenticação que existe na Appchain de Associação de Banda 500.
Petição 870200056145, de 06/05/2020, pág. 134/1737
132/754
Após uma correspondência bem-sucedida e, portanto, a
autenticação, as identidades do nó associadas ao token de
autenticação 514 são recuperadas da Appchain de Associação de
Nós 502, conforme indicado no Etapa 506.
[398]Na Fig. 25, a autenticação bem-sucedida ocorre apenas se um número suficiente de Tokens de Autenticação de Banda (BAT) 484 corresponder a qualquer Token de autenticação exclusivo 514 da Appchain de Associação de Banda 500 de acordo com uma quantidade definida na Política de Codificação Estática (SHP) 488. A condição 96 indica que não há um número suficiente de BAT 484 correspondendo a um único token de autenticação 514. Portanto, a Etapa 512 que executa a qual rejeita a autenticação e finaliza a execução do módulo. A condição 98 indica que um número suficiente de BAT 484 correspondeu a um único token de autenticação 514. Portanto, a Etapa 510 é executada que recupera e descriptografa o token de autenticação 514 associado da Appchain de Associação de Banda 500. Portanto Assim, o estágio 510 leva ao estágio 506, que recupera a lista de nós associados 518 que correspondem a um token de autenticação 514 da Appchain de Associação de Nós 502. Portanto, o estágio 506 leva ao estágio 520, que combina o Token de Autenticação 514 a Lista de nós Associados 518 em Uma sessão de Usuário Autenticado 520. A Sessão de Usuário Autenticado 522 permite que o usuário UBEC 106 efetue login com êxito na plataforma 100 do UBEC e, portanto, no aplicativo 118 do UBEC e tenha associe um Perfil Pessoal Inteligente (PIP) 136 exclusivo da Appchain 836. Portanto, a Sessão de usuário autenticado 522 é apresentada como uma saída modular na Etapa 524, que concede a execução da UNI 470.
Petição 870200056145, de 06/05/2020, pág. 135/1737
133/754
[399] A Fig. 26 mostra um diagrama mais detalhado da categorização de bandas biométricas (BBC) 482. 0 objetivo da BBC 482 é tornar os dados biométricos de entrada referenciados, tornando a precisão de tais dados mais vaga do erro esperado do equipamento de reconhecimento biométrico (por exemplo, scanner de impressão digital etc.). Portanto, a BBC 482 recebe inicialmente uma Entrada Biométrica Genérica 526. Uma Separação Granular da Entrada 530 é criada na Etapa 528. A referida Separação Granular 530 representa a Entrada Biométrica Genérica (dados) 526 em um formato que quantifica os intervalos de magnitude encontrados nos Dados 526. Portanto, as várias composições de Dados Biométricos 526 que podem ser derivados de uma 474 Impressão Digital, 476 Digitalização da Retina Ocular, 478 Reconhecimento de Voz ou amostra de DNA de cabelo/pele, etc. podem ser montados no mesmo formato 530 que destaca os pontos de dados de alta e baixa magnitude. Posteriormente, o Estágio 532 expande o escopo desses pontos de dados encontrados no Formato 530 para criar o Formato 534. Conforme ilustrado na Referência 536 no Escopo da Banda no Formato 534, pretende ser maior que o erro de margem esperado que existe em dispositivos típicos de reconhecimento biométrico. Isso leva à capacidade do usuário do UBEC 106 de se autenticar na plataforma UBEC 100 a partir de qualquer dispositivo em qualquer lugar do mundo, sem a necessidade de uma senha ou conta de usuário memorizada. Portanto, os dados pessoais do Usuário da UBEC 106 estão indissociavelmente vinculados aos dados biométricos e, portanto, ao próprio Usuário 106. Se a Etapa 532 não ocorreu, a margem de não calibração entre vários dispositivos biométricos não
Petição 870200056145, de 06/05/2020, pág. 136/1737
134/754 permitiría ao usuário da UBEC 106 acessar constantemente suas informações e serviços de qualquer lugar e a qualquer momento. Portanto, a Etapa 532 leva à Etapa 538, que armazena as Categorias de Banda produzidas no formato 534 como um Token de Autorização de Banda (BAT) 484, que é posteriormente apresentado como uma saída modular.
[400] [00] Figs. 27-28 mostram a mecânica da camada base das Appchains 836 que compõem o ecossistema da Customchain 540.
[401] Na Fig. 27, o Ecossistema da Customchain 540 é uma interação complexa das Appchains, Microchains, junto com a única Metachain, para produzir um sistema eficiente e adaptável dinamicamente de retenção e serviço de dados, juntamente com a execução do programa/rotina que constitui a Rede BCHAIN 110. A Loja de Aplicativos da UBEC 542 existe dentro do ecossistema da Customchain 540 para hospedar, listar e servir aplicativos UBEC, como o aplicativo UBEC A 544, que já foram examinados e aprovados pelo LUIGI 116. Na etapa 546, o dispositivo ativado para o UBEC 548 selecione e baixe o aplicativo UBEC A 544 da loja de aplicativos UBEC 542. Posteriormente, no estágio 550, os segmentos de execução são coletados da Appchain A 554, que é mapeada para o aplicativo UBEC A 544. Portanto, os segmentos de execução 551 coletados na etapa 550 são enviados para a coleção
de fluxo de execução (ESC) 6700 que os reúne em um fluxo de
execução A0 556. Esta montagem feita pelo Coleta de Fluxo de
Execução (ESC) 6700 considera a ordem correta na qual os
segmentos de execução 551 devem ser alinhados. Isso ocorre porque a ordem na qual os segmentos de execução 551 existem dentro da linha do tempo da Appchain 836 (Appchain A0 554) não requer a
Petição 870200056145, de 06/05/2020, pág. 137/1737
135/754 ordem na qual os Segmentos de Execução 551 devem ser executados para promulgar o programa desejado. A referida Execução dos Segmentos de Execução 551 do Segmento de Execução AO 556 ocorre no módulo 6400 de Execução de Representação de Fluxo (ESR). Paralelamente ao processamento e montagem do Fluxo de Execução AO 556 é o processamento e montagem do Fluxos de dados AO e Z3 562. Isso é realizado na Etapa 550, que leva à Etapa 559, que coleta os Segmentos de Dados 553 da Appchain AO 554 e os envia para classificação na Classificação de Fluxo de Dados (DSS) 6800. Portanto, os segmentos de dados 553 são organizados de uma maneira que leva à recuperação e retenção de dados eficientes e, portanto, os fluxos de dados A0 e Z3 562 são montados pelo DSS 6800. Tais fluxos de dados A0 e Z3 562 são referenciados pelo ESR 6400 para executar corretamente os comandos listados no Fluxo de Execução A0 556. Portanto, a manipulação dos dados referenciados pode ser realizada usando as rotinas de código que atuam como o bloco de construção de todos as Appchains 836 e, portanto, dos módulos (por exemplo, LOM 132, LIZARD 120 etc.) na Plataforma UBEC 100.
[402]Na Fig. 28, os ecossistemas de Customchain 540 relevantes para os dispositivos habilitados para UBEC 548 são mostrados em uma forma básica. Vários ecossistemas de Customchain 540 compõem a Grande Rede BCHAIN 110. O aplicativo UBEC A 564 e o aplicativo UBEC B 566 compõem seu próprio ecossistema Customchain 540. Para cada ecossistema de Customchain 540 que se correlaciona com um aplicativo como o aplicativo UBEC A 564, existe um Container de Appchain como o Recipiente de Appchain A0 568. Esse Recipiente de Appchain atua como a principal fonte de
Petição 870200056145, de 06/05/2020, pág. 138/1737
136/754 informações e instruções para o envio do Aplicativo. Portanto, o Container de Appchain pode se referir a Fluxos de Execução e Fluxos de Dados que são armazenados em Appchains Suplementares, como nos Clusters de Appchain Suplementares 572 e 574. Portanto, o Aplicativo UBEC 564 pode se referir a depender de fluxos de execução e de dados existentes no aplicativo UBEC B 566 pelo Cluster de Appchain Suplementar 572, fazendo referências a informações (execução e/ou dados) armazenadas em um Cluster de Appchain suplementar 574. Os Ecossistemas de Customchain 540 também podem conter Appchains independentes que não pertencem a ou representam um Aplicativo UBEC especifico, como o Cluster de Appchain Independente 576. Portanto, os Fluxos de Execução ou os Fluxos de Dados separados podem ser extraídos das Appchains Independentes, como a Appchain Independente Z3 577. Os dados são extraídos da Appchain Autônoma Z3 577 pelo DSS 6800 de acordo com as instruções definidas em o fluxo de execução AO 556 que leva à montagem do fluxo de dados Z3 562, levando à representação correta e abrangente do aplicativo selecionado no ESR 6400.
[403] [00] Figs. 29 - 31 mostra o processo de desenvolvimento e implantação do aplicativo UBEC.
[404] Na Figura 29, o Usuário UBEC 106 interage com a Interface de Gerenciamento (LMI) 580 em uma sessão que envolve a Entrada de Criatividade do Usuário 106 578 e a tomada de decisão que constrói a Estrutura Geral do Aplicativo. O LMI 580 é uma interface front-end para usuários UBEC 106 para criar aplicativos e negócios por meio de um conjunto de ferramentas que permitem a logística. As setas bidirecionais são mostradas entre o Usuário UBEC106, Entrada do Usuário e Criatividade 578 e LMI 580 para
Petição 870200056145, de 06/05/2020, pág. 139/1737
137/754 indicar que o LMI 580 retorna comentários de design para o Usuário DA UBEC 106 em uma sessão interativa de construção. Portanto, o LMI 580 produz uma Camada Logística 582, que é um formato de informação genérico que define a Logística de aplicativos projetada pelo Usuário UBEC 106 através do LMI 580. A Camada Logística 582 é enviada como entrada para o Construtor de Ecossistemas Customchain (CEB) 584. O CEB 584 cria automaticamente o Aplicativo de Logística, conforme percebido pelo Usuário DA UBEC 106, usando os blocos de construção fundamentais que consistem em um Ecossistema Customchain 540. Portanto, o fluxo lógico do Construtor de Ecossistemas Customchain 586 representa visualmente a operação do CEB 584. No Fluxo Lógico 586, inicialmente o Status Atual do Aplicativo 596 é interpretado na Etapa 588. Isso significa que interpreta as posições relevantes existentes nos Segmentos de Execução 551 e Segmentos de Dados 553. Portanto, na Etapa 590, os Segmentos de Execução 551 são montados no Fluxo de Execução 598, na ordem correta para garantir a execução correta do programa pelo ESR 6400. A Etapa 590 é efetivamente processada pelo ESC 6700. As setas que mover dos blocos da Appchain 596 para os segmentos de execução do fluxo de execução 598 indica que, geralmente, mais tarde um segmento de execução 551 na Appchain 596 obtém uma posição mais baixa no fluxo de execução 598. Apesar de Dessa tendência de ordem cronológica de existência, ainda é possível que um bloco posterior da Appchain contenha um segmento de execução 551 marcado para execução antecipada. A razão prática disso é que os aplicativos criados nos Ecossistemas Customchain 540 podem ser atualizados de forma incrementai e corrigidos com
Petição 870200056145, de 06/05/2020, pág. 140/1737
138/754 correções de bugs, novos recursos etc. Portanto, na Etapa 592, os segmentos de dados 553 são coletados e montados em um fluxo de dados através do processamento DSS 6800. Posteriormente, o fluxo de execução 598 e o fluxo de dados 600 são enviados para o processamento lógico interno do CEB. 594, que abriga e opera a lógica principal rudimentar que consiste em CEB 584.
[405] Na Fig. 30, o Processamento lógico interno do CEB 594 mostra a saída do suplemento Execução + Dados 596. Esses suplementos devem ser armazenados no bloco mais recente da Appchain 602. Apesar do novo segmento de execução 551 incluído no novo bloco da Appchain 602, contém um sinalizador de prioridade 2,5. Isso instrui o ESC 6700 a montar o fluxo de execução de maneira a preservar os indicadores de prioridade. Isso permite que o CEB 584 confirme atualizações na Appchain 602 para modificar efetivamente qualquer parte ou seção do Fluxo de Execução 598 e Fluxo de Dados 600. O segmento de dados 553 também é adicionado ao Fluxo de Dados 600, considerando a prioridade de recuperação. O CEB 584 também pode adicionar Instruções a Appchain 602 que proíbem efetivamente que um segmento de execução 551 ou segmento de dados 553 seja incluído no fluxo de execução 598 e/ou fluxo de dados 600. Esse segmento proibido continuaria a existir na sequência de Blocos da Appchain, mas seria ignorado pelo ESC 6700 para os segmentos de execução 551 e DSS 6800 para os segmentos de dados 553.
[406] A Fig. 31 mostra as etapas a seguir ao concluir o processo CEB 584. A conclusão do CEB 584 leva à Etapa 604, onde novos suplementos de dados e execução (como no elemento 596) ao Appchain começam a ser processados dentro do Rede BCHAIN via
Petição 870200056145, de 06/05/2020, pág. 141/1737
139/754
Anúncio de Novo Conteúdo (NCA) 2544. Isso leva ao estágio 606, onde o conteúdo é enviado para os mineradores Armazenamento de Dados Mempool (MDS) 2472, onde finalmente o próximo bloco da Appchain é extraído 602 para o Módulo de interface Customchain (CIM) 2470. Posteriormente, na Etapa 608, o conteúdo do bloco recém-extraído é cortado em partes do cache e transferido para os nós de armazenamento em cache por meio dos Nós de mineração de fornecimento de sementes de Cachê (MNSCS) 1850. Posteriormente, no Estágio 610, as partes do cache são migradas gradual e automaticamente para áreas otimizadas para serviços, garantindo o melhor tempo e velocidade de execução para os nós que solicitam os dados. O estágio 610 ocorre efetivamente através da Execução do Algoritmo de Seleção de Cache (CSA) 2350. Posteriormente, no estágio final 612, os nós reivindicam o conteúdo dos nós de cache por meio do Gerador de Recuperação de Conteúdo (CCG) 3050. Após o download, esses nós podem executar a Sequência de Execução através do ESR 6400, levando à manifestação do aplicativo pretendido.
[407] [00] Figs. 32-36 mostram o LOM 132 operando como uma série de Appchains 836 conhecidas como um ecossistema Customchain 540. O elemento inicial e primário que define o LOM 132 é o LOM da Appchain Container 614, que abriga os principais módulos no formato de uma Appchain. 596. Essa Appchain 596 possui seus próprios segmentos de execução 551 extraídos por meio do ESC 6700 para gerar um fluxo de execução 596. Esse fluxo de execução 596 praticamente se manifesta como os principais módulos que operam o LOM 132. Esses módulos são o Raciocínio de Consulta Inicial (IQR) 618 que recebe a pergunta declaração inicial
Petição 870200056145, de 06/05/2020, pág. 142/1737
140/754 fornecida pelo Usuário da UBEC 106 e subsequentemente aproveita a Retenção Central de Conhecimento (CKR) 648 para decifrar os detalhes ausentes que são cruciais para entender e responder à pergunta/declaração. O Esclarecimento de Pesquisas (SC) 620 interage com o Usuário da UBEC 106 para obter informações adicionais para que a declaração/pergunta possa ser analisada objetivamente e com todo o contexto necessário. Construção de afirmações (CA) 622 recebe uma proposta na forma de uma declaração ou pergunta e fornece resultados dos conceitos relacionados a essa proposição. A Atribuição Hierárquica (HM) 624 atribui conceitos associados para encontrar corroboração ou conflito na coerência da pergunta / afirmação. O HM 624 calcula os riscos e benefícios de uma certa postura sobre o assunto. Combinação de dados pessoais e gerados (PGDM) 626; com qualquer informação de solicitação de dados, ela sempre é acessada a partir do CKR 648. Se houver critérios pessoais na solicitação de dados, o PIP 136 será referenciado e com base no conhecimento do CKR 648. O Apelo Racional (RA) 628 critica as alegações de que seja lida com a autocrítica ou crítica das respostas humanas através do uso do CTMP 124. Validação de conhecimento (KV) 630 recebe conhecimento altamente confiável e pré-criticado, que deve ser logicamente separado para consulta e capacidade de assimilação na CKR 648. Com Análise de Referência Cruzada (CRA) 632, as informações recebidas são comparadas e construídas levando em consideração o conhecimento preexistente da CKR 648. Isso permite que novas informações recebidas sejam avaliadas e validadas de acordo com o que a CKR 648 atualmente conhece e não sabe. Portanto, o Fluxo de Dados 596 realmente se manifesta após
Petição 870200056145, de 06/05/2020, pág. 143/1737
141/754 a execução do ESR 6400.
[408] Na Fig. 33, a Lógica do Sistema UBEC 634 representa a LOM Contêiner Appchain 614 interagindo com outras Appchains 836 na plataforma UBEC 100. Portanto, os segmentos de dados 640 chegam da Lógica do Sistema UBEC 634 ao LOM Contêiner Appchain 614. Os 640 segmentos de dados são processados pelo ESR 6400 em conjunto com a lógica principal do LOM 132 definido pelo Fluxo de Execução 598 e listado como Manifestação Modular do Fluxo de Execução 616. Esses segmentos de dados de entrada 640 são manifestos 636 como entrada de perguntas/afirmações LOM 638. Portanto, a execução do ESR 6400, que neste caso é a execução efetiva do LOM 132, resulta nos segmentos de dados 642 que são enviados de volta à lógica do sistema UBEC 634 como resposta formal da LOM 132 à entrada de perguntas/afirmações LOM 638.
[409] A Fig. 34 mostra como a Retenção Central de Conhecimento (CKR) 648 existe como uma Appchain 650 independente, como mostrado no Elemento 644. Portanto, o CKR 648 como uma Appchain 650 interage em paralelo com a LOM Contêiner Appchain 614 para os módulos de Asserção de Construção da LOM 132 (AC) 622, Atribuição Hierárquica (HM) 624, Validação de Conhecimento (KV) 630, Combinação de Dados Pessoais e Gerais (PGDM) 626 e
Análise de Referência Cruzada (CRA) 632. Como ilustrado em na Appchain 650, a grande maioria do conteúdo do bloco são 553 Segmentos de Dados e a grande minoria são 551 Segmentos de Execução, o que é esperado, pois o CKR 648 é um banco de dados complexo e sofisticado. Também mostra como o Apelo Racional (RA) 628 do LOM da Appchain 614 interage e depende do CTMP como uma Appchain 124.
Petição 870200056145, de 06/05/2020, pág. 144/1737
142/754
[410] A Fig. 35 mostra uma instância do PIP (Perfil de Inteligência Pessoal) 136 como uma Appchain 654. Os blocos menores são mostrados na Appchain 654 em contraste com os blocos mais concentrados na Appchain 648 CKR 650. Isso é esperado como todas as Appchain 648 CKR 650 terão um tamanho muito mais vasto do que uma instância do 136 Appchain PIP 654. Cada usuário da UBEC 106 possui seu próprio PIP 136 Appchain 654 independente. Uma instância do PIP 136 Appchain 654 é mostrada para interagir com os módulos de Análise de referência cruzada (CRA) 632 e Combinação de Dados Pessoais e Gerais (PGDM) 626 do LOM Contêiner Appchain 614.
[411] A Fig. 36 mostra como o módulo LOM 136 para Gerenciamento e automação da vida (LAA) 138 existe como uma Appchain 658 suplementar. Portanto, 132 Serviços Front-End 660 e Serviços de back-end 662 da LOM são terminais de interação com o LAA 138 como uma Appchain 658. Paralelamente, o LOM Contêiner Appchain 614 fornece a entrada de perguntas/instruções do LOM 638 que recebeu da lógica do sistema UBEC 634 para a Appchain suplementar que hospeda o LAA 656.
[412] [00] Figs. 37 - 39 mostra o Algoritmo de Moeda de Unidades de Watts (indicado como -U-) 666, que opera as principais funções de liquidez relacionadas ao meio de câmbio usado na Plataforma UBEC 100 e na Rede BCHAIN 110. Uma Unidade de Watt é uma moeda criptográfica que preserva o valor intrínseco, uma vez que é algoritmicamente fixo ao valor da eletricidade, portanto, energia. Como a energia é um bem precioso, isso evita grandes quantidades de especulação e volatilidade na economia de -100. Não há um número fixo de
Petição 870200056145, de 06/05/2020, pág. 145/1737
143/754 unidades de watt disponíveis em circulação (não um modelo deflacionário), pois isso limitaria artificialmente o crescimento da plataforma UBEC 100 para um nível de energia limitado. Em vez disso, as unidades de watts são criadas e destruídas diretamente por seu único governador, LUIGI 116, quando a liquidez entra e sai da economia da UBEC. A Pesquisa de Preço de Energia Distribuída (DEPS) 668 é um módulo que pesquisa os nós do BCHAIN 78 6 que podem relatar autenticamente o preço atual da eletricidade em moeda fiduciária. Esses nós 786 podem ser medidores elétricos instalados nas casas que participam da rede BCHAIN 110. A Bolsa de Moeda de Terceiros (TPCE) 672 é um módulo que atua como a camada logística para gerenciar a compra e venda de moeda fiduciária. Isso permite que a liquidez flua para dentro e para fora da economia de 862 watts da Metachain 834. No TPCE 672 UBEC 106, os usuários que procuram vender e comprar unidades de watts são essencialmente emparelhados em uma bolsa. Não há longos atrasos nas negociações e na descoberta dos preços de mercado, uma vez que o valor da moeda fiduciária de uma unidade de watts está vinculado ao valor relatado pelo DEPS 668. Após um usuário UBEC 106 comprar uma quantidade de unidades de vários, um relatório de transação verificado de 674, detalhando a quantidade comprada, é enviado à LUIGI 116. Após a aprovação da transação pela LUIGI 116, a Etapa 682 de um usuário que compra unidades de Watt leva à criação de unidades de Watt 688 na Interface econômica LUIGI 686. Da mesma forma, depois que um usuário UBEC 10 6 vende uma quantidade de unidades de watts, um Relatório de transação verificado 674 detalhando a quantidade comprada é enviado para a LUIGI 116. Após a aprovação
Petição 870200056145, de 06/05/2020, pág. 146/1737
144/754 da transação pelo LUGI 116, o passo 680 de um usuário que compra unidades de watt leva à unidade de destruição de 690 watts na interface econômica LUIGI 686. Portanto, toda a liquidez flui através da da plataforma UBEC 100 é governada pelo módulo LUIGI 392 Monitoramento do Movimento De fundos (EMO). Para LUIGI 116 Criar 688 ou Destruir 690 Unidades de Várias, o módulo LEI 686 deve receber informações de identidade da Etapa 692 em relação aos nós associados aos Usuários da UBEC 106 que mantêm os fundos. Para manter uma economia funcional de transferência de dados, retenção e processamento da CPU na rede BCHAIN 110, as taxas de vários tipos de trabalho existentes no protocolo BCHAIN 794 são rastreadas no módulo Trabalhar em Watts (WWR) 670. Os tipos de trabalhos que existem no protocolo BCHAIN com mineração Metachain/Appchains/Microchains, Cache de Peças de Conteúdo, Roteamento de Rede (CCR/CCF), Localizador de Abrigo Local, Localizador de Buscador de Dados, Emulação DC2, Retenção de Metachain, Verificação da Cache do nó, Retenção de Registros de Diagnóstico. No estágio 676, um nó BCHAIN X trabalha e relata a quantidade de watts consumidos para fazer X trabalhar no Relatório de trabalho do Metachain 834 860 Watt via WWR 670. A Calculadora de taxa mínima de unidade Watts (WUMFC) 684, referência ao Relatório de trabalho da Metachain 834 a 860 Watts para calcular a taxa mínima aceita necessária para o trabalho na rede BCHAIN 110. Na etapa 678, o Nó 786 do BCHAIN deseja a quantidade de trabalho realizado (transferir dados, armazenar dados etc.), portanto, o nó se refere ao módulo WUMFC 684. Qualquer quantia que exceda a taxa mínima exigida facilita maior redundância na transferência e retenção de dados, portanto, isso
Petição 870200056145, de 06/05/2020, pág. 147/1737
145/754 leva a uma maior qualidade e confiabilidade desses serviços.
[413] A figura 38 mostra a mesma mecânica de compra de unidades de watts da figura 37, no entanto, com a integração da autenticação do usuário por meio da Interação do Nó do Usuário (UNI) 470. Após uma autenticação bem-sucedida do usuário UBEC 106, O UNI 470 retorna a Sessão do usuário autenticado 522. A Sessão do usuário autenticado 522 contém a Lista de nós associados 518, que é usada na Etapa 692. A Sessão do usuário autenticado 522 enviada pelo UNI 470 também é necessária para a compra 696 e Venda 698 de Unidades de Watts.
[414] Na Figura 39, o FMO 392 e as funções do LEI 686 requerem conhecimento e acesso à Alocação de fundos privados para usuários (UPFA) 718. Somente o LUIGI 116 e o Usuário UBEC 106 podem manipular os fundos mantidos pelos nós definidos no UPFA 718. Por isso, os módulos FMO 392 e LEI 686 operam sob a jurisdição da LUIGI 116. A alocação de fundos no UPFA 718 é inteligentemente distribuída entre os nós de acordo com seu tipo (computador, telefone, drone etc.), histórico, confiabilidade etc. Essa alocação inteligente de fundos é feita para mitigar o risco de um nó ser danificado/roubado etc. O que inadvertidamente causaria a perda dos fundos associados ao nó. No entanto, o mecanismo de reserva é usar o Mecanismo de Recuperação de Fundos LUIGI 116 (FRM). No entanto, o FRM é um processo subjetivo que pode levar uma quantidade significativa de tempo e pode levar à negação injusta do aplicativo. Devido a esses riscos e deficiências, é altamente preferível que o sistema UPFA aloque de maneira inteligente os fundos ao Nó 786 mais apropriado para
Petição 870200056145, de 06/05/2020, pág. 148/1737
146/754 mitigar os riscos.
[415] [00] Figs. 40 - 42 mostra a Bolsa de Economia Criptográfica Digital (CDEE), que é um mercado para a compra de Aplicativos, além de investir neles como ações públicas. Após a autenticação bem-sucedida, o UNI 470 envia uma Sessão de Usuário Autenticado 522, que permite que os 706 automatizados e os 708 automatizados invistam em Aplicativos existentes na Plataforma UBEC 100. A etapa 706 descreve para o Usuário 106 do UBEC a autorização da Metodologia de Doação Perpétua (MPG) 114 para investir automaticamente em Appchains apropriados. Por outro lado, a Etapa 708 descreve o Usuário UBEC 106 para procurar manualmente o Diretório de Aplicativos e Procurar (ADE) 710 para selecionar potencialmente um investimento. No cenário 712, o usuário UBEC 106 investe em um aplicativo transferindo de seus fundos privados para os fundos públicos do App. No cenário 714, um usuário retira um investimento existente de um aplicativo transferindo o valor de suas ações dos fundos públicos do aplicativo para seus fundos privados. Os fundos privados são mantidos pelo UPFA 718. Ambos os cenários 712 e 714 levam ao estágio 716, onde são feitas modificações apropriadas no Registro de investimentos em Aplicativos (AIR) 722.
[416] [00] Figs. 41 - 42 mostra como os Aplicativos UBEC listados no módulo 710 de Diretório e Exploração de Aplicativos (ADE) podem receber e enviar liquidez em termos de investimento. Para realizar movimentos de liquidez entre um Usuário UBEC 106 e um Aplicativo UBEC, são invocadas instâncias de quatro módulos (como Appchains 836) : Alocação de Fundos de Aplicativo Público (APFA) 720, Registrador de Investimentos em Aplicativos (AIR)
Petição 870200056145, de 06/05/2020, pág. 149/1737
147/754
722, Monitoramento de Dados de Aplicação (AET) 724 e Distribuição de Benefícios de Aplicação (APD) 726. No cenário 712, um Usuário 106 investe em uma Aplicação transferindo de seus Fundos Privados (UPFA) 718 para os Fundos Públicos da Aplicação através da APFA 720. Portanto, a Etapa 716 ocorre quando as modificações apropriadas no AIR 722 são feitas. Tais modificações são feitas no Aplicativo apropriado onde um investimento foi feito. O mesmo padrão de eventos ocorre quando o Usuário UBEC faz uma retirada 106 no Cenário 714. No Cenário 714, o Usuário UBEC 106 retira um investimento existente de um Aplicativo transferindo o valor de sua participação dos Fundos de Aplicativos Públicos para seus fundos privados (UPFA) 718. Como cenário 712; o cenário 714 leva ao estágio 716 quando ocorrem modificações no AIR 722.
[417] A Figura 42 mostra o mesmo aplicativo UBEC A 564 e o aplicativo UBEC B 566, desta vez interagindo diretamente com a UPFA (Alocação de Fundos de Usuários Privados do Usuário) UBEC 718 (UPFA), todas as despesas relacionadas ao Aplicativo UBEC e aos Usuários UBEC 106 que gerenciam o Aplicativo. Portanto, o AET 72 4 atua como uma forma de transparência pública para investidores atuais e potenciais. O AET 724 também envia informações de despesas para a Distribuição de Benefícios do Aplicativo (APD) 726. Ao se referir ao valor atual de mercado e, portanto, aos fundos públicos do APFA 720, o APD 726 pode calcular os benefícios e distribuí-los para investidores relevantes (Usuários da UBEC 106).
[418] [00] Figs. 43 - 44 mostram a interação entre a Interface da Plataforma UBEC (UPI) 728 e a Aceitação de Tarefa de Cache (CWA) 742. A execução do UNI 470 leva a uma Sessão de
Petição 870200056145, de 06/05/2020, pág. 150/1737
148/754
Autenticação do Usuário 522 com o UPI 728. Portanto, o Usuário UBEC 106 Você pode usar a Interface do usuário front-end 1148 para selecionar uma Personalidade Econômica 740. As Personalidades Econômicas 740 são detalhadas da seguinte maneira: Personalidade A: O equalizador 732 é quando 786 os recursos do Nó são consumidos para corresponder ao que que o usuário UBEC 106 consome (se houver) . Personalidade O 732 é ideal para o consumidor frugal ocasional, com uma quantidade leve a moderada de transferência de informações. As transmissões ao vivo, como chamadas VoIP (por exemplo, Skype) e a prioridade da transferência de informações, são mínimas. Personalidade B: O lucro 734 é quando o Nó 786 consome o maior número possível de recursos locais, desde que a margem de lucro seja maior que X. Posteriormente, para obter benefícios potenciais, as Unidades Watt em excesso podem ser negociadas por Moedas Alternativas, como Criptomoedas, Moedas Fiduciárias, Metais Preciosos, etc. A personalidade B 734 é ideal para um nó 786 que foi criado especificamente para contribuir com a infraestrutura da rede BCHAIN 110 com fins lucrativos. Portanto, esse Nó 786 normalmente seria uma instalação de infraestrutura permanente executada na rede elétrica, e não em um dispositivo alimentado por batería, e possui poderosos componentes internos do computador (recursos sem fio, energia da CPU, tamanho do disco rígido etc.) A personalidade C: Consumidor 736 é quando o usuário UBEC 106 paga pelas unidades de Watts por meio de uma Moeda Alternativa (Criptomoeda, Moeda Fiduciária, Metais Preciosos etc.) para que o conteúdo possa ser consumido gastando menos recursos no Nó 786. A personalidade C 736 é ideal para um consumidor pesado de
Petição 870200056145, de 06/05/2020, pág. 151/1737
149/754 transferência de informações ou para alguém que deseja tirar proveito da rede BCHAIN 110, mas não deseja que os recursos do dispositivo 786 sejam esgotados (por exemplo, o smartphone descarrega a batería rapidamente e fica quente) no bolso). Personalidade D: Altruísta 738 é quando os recursos do Nó 786 são gastos o máximo possível e sem nenhuma restrição de esperar algo em troca, seja consumo de conteúdo ou compensação monetária. A personalidade D 738 é escolhida por alguém cujos interesses estão na força da Rede BCHAIN 110 (por exemplo, os principais desenvolvedores do Protocolo BCHAIN 794 podem comprar e instalar nós para fortalecer apenas a Rede 110 e não consumir conteúdo ou ganhar Unidades de Watts). Portanto, a Personalidade Econômica selecionada 740 é submetida à ECWI 744, que opera sob a jurisdição do Aceitação do Trabalho em Cachê (CWA) 742.
[419] A Fig. 44 mostra como o CWSI 744 faz referência à economia de 862 Watts do Metachain 834 para determinar o excedente/déficit atual 746 deste nó 786 em relação às Unidades de Watts obtidas. Portanto, o excedente/déficit de trabalho atual 746 é encaminhado para o ECWI 744, que considera a personalidade econômica selecionada 740 e o excedente/déficit 746 para avaliar se é necessário mais trabalho no momento. Portanto, a Etapa 748 avalia a produção resultante do ECWI 744. O resultado 750 é descrito como: Abster-se do trabalho, portanto, não continua o processamento BCHAIN em relação à CCR 2308 ou CCF 2318. O resultado 752 é descrito como: execute mais trabalho, portanto, transferindo o CCR 2308 ou o CCF 2318 para o Algoritmo de seleção de cache (CSA) 2350 para continuar o processamento BCHAIN. A Lógica de Interação do Nó (NIL) 2380 opera a partir da jurisdição
Petição 870200056145, de 06/05/2020, pág. 152/1737
150/754 de gateway de comunicações (CG) 2348 e fornece o CCR 2308 ou o CCF 2318 inicial que está sendo considerado em cache.
[420] [00] Figs. 45-46 mostram uma visão geral do Protocolo BCHAIN (BP) 794.
[421] Na Fig. 45, a lógica de roteamento (RL) 774 faz referência aos principais módulos que lidam com o roteamento de dados no BCHAIN 110. Disseminação de Informações da Fila (QIB) 2700 gerencia CCR 2308 ou CCF 2318 que devem ser disseminados para outros nós. Esses pacotes de informações CCR 2308 e CCF 2318 são encaminhados pelas Plataforma de Comunicações (CG) 2348, que é a camada exclusiva de comunicação entre o Protocolo BCHAIN (BP) 794 e a Interface de hardware 786 Node 762. A Plataforma de Comunicações (CG) 2348 também encaminha informações sobre os nós 786 próximos para o Pesquisa de Nó Estatístico (NSS) 778. O NSS 778 rastreia o comportamento dos nós 786 próximos, fazendo com que a formação de quatro índices seja calculada: índice de Escape do Nó 886, índice de Saturação do Nó 888, índice de Consistência do Nó 890, índice de Sobreposição de Nós 892. O índice de Escape do Nó 886 rastreia a possibilidade de um nó 786 vizinho escapar da vizinhança de um Nó Perceptivo 786. O índice de Saturação do Nó 888 rastreia o número de nós 786 no Intervalo de Detecção 786 de um Nó Perceptivo. O índice de Consistência do Nó 890 rastreia a qualidade dos serviços de um Nó 78 6 interpretado por um Nó Perceptivo 786. O índice de Sobreposição de Nó 692 rastreia a quantidade de sobreposição de 786 nós que se interpretam como interpretados por um Nó Perceptivo 786. O Nó Perceptivo 786 é aquele que executa a instância do NSS 778 que está imaginando nas descrições. As quatro variáveis 886, 888, 890, 892
Petição 870200056145, de 06/05/2020, pág. 153/1737
151/754 resultantes são enviadas para o Sistema de Corroboração da Estratégia (SCS) 770, que impõe o Protocolo de consenso 794 entre os Nós 770. Portanto, nós não confiáveis com intenção maliciosa ou simplesmente está executando uma alteração ilegítima do Protocolo BCHAIN 794 e é proibido participar do consenso e da conclusão do trabalho. A Adaptação Dinâmica da Estratégia (DSA) 772 recebe variáveis do NSS 778 para alterar dinamicamente a Implantação da Estratégia 916, que se baseia no cálculo da Composição de Critérios Estratégicos 992. A Composição dos Critérios Estratégicos 992 contém uma ampla variedade de elementos de relatório de variáveis principal, importante e complementar ao Protocolo BCHAIN 794. A Implantação da Estratégia 916 é produzida pelo DSA 772 e, em seguida, é referenciada pelo QIB 2700 e CG 2348, entre muitos outros módulos que operam no protocolo BCHAIN (BP) 794. As Appchains registradas 776 contêm chaves de acesso criptográfico de várias Appchains 836 (normalmente, o contêiner Appchain de um aplicativo UBEC). Portanto, quando uma atualização para uma Appchain 836 é anunciada nas Atualizações da Metachain 834 para a Appchain 846, o dispositivo 786 fará baixara as atualizações mais recentes da Appchain 836. Isso se manifestará como Prova de Lei Criptográfica 2314 originária de chaves criptográficas armazenadas em Appchains registradas 776. O Núcleo Crypto (CC) 768 contém todas as principais bibliotecas que operam todas as funções criptográficas que operam o Protocolo BCHAIN 794, como o Calculadora de Árvore de Merkle (MTC) 1338 etc.
[422]A Fig. 46 mostra como o protocolo BCHAIN 794 opera com seu próprio hardware e o hardware de outros nós BCHAIN 786.
Petição 870200056145, de 06/05/2020, pág. 154/1737
152/754 protocolo 794 é executado através dos pontos de conexão API 792 que se comunicam com as Plataformas de Comunicação (CG) 2348. Os controladores que se comunicam com a interface de hardware 762 existem e são executados no sistema operacional 790. Portanto, o CG 2348 é capaz de enviar e receber pacotes CCR 2308 e CCF 2318 para outros nós BCHAIN 786. Essa transmissão de informações isso pode ocorrer por meio da comunicação ponto a ponto diretamente entre os Nós 786 ou roteamento através de sistemas centralizados, como a Internet. A interface de hardware 762 do nó BCHAIN (BN) 786 atua como uma camada lógica que recebe instruções de hardware. Portanto, a manifestação física do hardware existe no Dispositivo de Hardware 780, que abriga a arquitetura opcional do Microchip Processador 4260 UBEC/BCHAIN (UBMA). Esse processador 4260 aumenta a velocidade e a eficiência da execução do Protocolo BCHAIN 794. Isso leva a um melhor desempenho da batería entre os 786 dispositivos móveis e à execução mais rápida das Appchains 836.
[423] [00] A Fig. 47 ilustra o paradigma de interação do Nó 786 que existe na rede BCHAIN 110. O Metachain 834 é uma Customchain (semelhante a uma Blockchain) que contém metadados de todos os nós da rede BCHAIN 110 conectados a referências essenciais e primárias. O Metachain 834 não fornece conteúdo real, mas rastreia informações críticas contendo locais dos Nodos 786/Setores 884, tendências de demanda de conteúdo e saldos de roteamento para otimizar a configuração da infraestrutura. Portanto, é necessário que cada Nó BCHAIN 786 participe da leitura da Metachain 834. As Appchains 836 são Customchains que funcionam como contratos inteligentes avançados para a entrega
Petição 870200056145, de 06/05/2020, pág. 155/1737
153/754 de informações através da infraestrutura organizada pela Metachain 834. As Appchains 836 podem se referir a entradas/saidas aninhadas e paralelas, também conhecidas como um ecossistema Customchain 540. As Microchains 838 são Appchains 836 que se tornam automaticamente uma Customchain que não depende ou se conecta a Metachain 834. Isso ocorre quando os nós 786 Participar de um determinado Appchain 836 é isolado em um só lugar. As Microchains 838 permitem que pequenos dispositivos loT 102 participem da rede BCHAIN 110 sem precisar acompanhar o Metachain 834, que consome muitos recursos. O diagrama 796 ilustra o antigo paradigma de serviço de conteúdo que é indicativo do legado da Internet. Os dispositivos clientes fazem solicitações para um único servidor ou cluster de servidores, que pode se tornar um único gargalo no dimensionamento para aumentar a demanda por conteúdo (por exemplo, tráfego da web). O servidor, ou cluster de servidores, representa um único ponto de falha e ponto de ataque. Assim, os ataques DDoS (Negação de Serviço Distribuída) se tornaram uma arma eficaz em toda a Internet, levando à coerção, chantagem e censura etc. A configuração estática do servidor centralizado também leva a uma distribuição geográfica ineficiente do conteúdo, pois a camada secundária do saldo do download geográfico precisa ser configurada, o que pode ser relativamente caro e ineficiente. O novo paradigma de conteúdo descentralizado 798 representa a mecânica básica da rede BCHAIN 110. Como o servidor e o cliente foram vinculados de maneira extravagante e irrevogável, isso leva a alta disponibilidade e distribuição de conteúdo quando necessário. Portanto, o balanceamento de carga geográfica do
Petição 870200056145, de 06/05/2020, pág. 156/1737
154/754 serviço de conteúdo está incorporado no protocolo BCHAIN 794. Como não há um ponto único de falha ou ataque, alta disponibilidade e redundância são subprodutos naturais da rede BCHAIN 110. Qualquer ataque DDoS por nós 806 não confiáveis que possuam uma minoria de hardware de rede não poderá tirar proveito de um ataque bem-sucedido a um conjunto de conteúdo direcionado (como um Appchain especifico). Além disso, o protocolo BCHAIN 794 proibe que os nós 786 selecionem ou proibam a hospedagem de Appchains 836 ou Microchains especificas. Portanto, o Protocolo BCHAIN 794 favorece a harmonia e a cooperação na recepção e distribuição, enquanto a Plataforma UBEC 100 gerencia os aspectos judiciais da censura e gerenciamento de conteúdo por meio do LUIGI 116.
[424] [00] A Fig. 48 mostra como a confirmação de troca de anúncios de hash impede que um Nó Rogue BCHAIN 806 participe da Rede BCHAIN 110. Com o Spam de tráfego do Nó Rogue 800, o Nó Rogue 806 é mostrado tentando fingir ser um Nó 786 BCHAIN legitimo, enquanto enviando spam para os nós legítimos 786. Para evitar que isso ocorra, o mecanismo ilustrado na Verificação de realidade hash do Nó 808 mostra como os Nós Legítimos 786 podem detectar o comportamento abusivo do Rogue Node 806 e, portanto, colocá-lo em uma lista negra. O Nó Rogue 806 transmite aos Nós Vizinhos 786 um Anúncio de Hash 802, necessário para a participação da Rede BCHAIN 110 e o reconhecimento pelos Nós Vizinhos 786. O Anúncio de Hash 802 é derivado de interpretações das variáveis da Pesquisa Estatística de Nós (NSS) 778. Portanto, os Nós 78 6 participam apenas entre si se tiverem a mesma interpretação do estado da rede local. Se um Nó Rogue 806 mentir
Petição 870200056145, de 06/05/2020, pág. 157/1737
155/754 sobre seus critérios para interpretar o estado atual da rede e agir de maneira abusiva (enviando spam para os Nós 786, etc.), será sabido pelos Nós Legítimos 786 que o comportamento do Tráfego do Nó Rogue 806 é Excedendo o Limite Declarado da Estratégia 804. Portanto, enquanto a maioria dos Nós 786 em uma área local ou no Setor 884 forem Nós Legítimos 786 que operam versões não modificadas do Protocolo BCHAIN 794, eles chegarão a um consenso sobre os limites de tráfego e operação e, portanto, colocará na lista negra quaisquer Nós 786 que excedam os limites ou não ingressam no consenso sobre esses limites. Os limites são representados de maneira criptográfica no Anúncio de Hash 802.
[425] [00] A Fig. 49 mostra o padrão básico de deslocamento de um pacote CCR 2308 ou CCF 2318 na Rede BCHAIN 110. A jornada começa na Meta Imediata 2302, o que significa o Nó 786 imediatamente seguinte ao qual o pacote CCR 2308 ou CCF 2318 deve ser transferido. O pacote continuará saltando entre os Nós 786 em direção à Meta Final 2306. Cada Nó 786 considerará a posição do pacote ao longo de sua jornada geral. Se os critérios definidos no Implantação da Estratégia 916, conhecido como Critérios de Propagação de Salto Paralelo 1002, forem atendidos, o Nó 786 chamará a Lógica de Salto Paralelo (PHL) 2922 fora da conformidade com o Protocolo BCHAIN 794. Isso leva os Nós específicos 801, 802 e 805 a iniciar mais caminhos de salto paralelo do que receberam. Isso leva a uma redundância nas trilhas de salto em relação ao CCR 2308 ou CCF 2318 itinerante. Isso é feito principalmente para diminuir o tempo que leva para o CCR 23 ou CCF atingir a Meta Final 2306. A confiabilidade e a confiança nas expectativas do pacote que chega dentro de um
Petição 870200056145, de 06/05/2020, pág. 158/1737
156/754 periodo previsível também aumenta à medida que aumenta a quantidade das trilhas de salto paralelo. Isso ocorre porque existe uma quantidade esperada de caos de presença do Nó 786 que ocorre naturalmente na Rede BCHAIN 110. Esse caos existe devido à natureza descentralizada dos Nós 786, que têm características variadas e executam o trabalho com base em esforços voluntários. As Trilhas de salto paralelo redundantes mitigam o risco apresentado por esse caos, aumentando as chances de que pelo menos a quantidade mínima de trilhas necessárias atinjam a Meta Final 2306 sem uma interrupção significativa do caos. Se houvesse muito poucas Trilhas de Salto Paralelo, seria de esperar que o caos atrasasse a maioria deles; portanto, o CCR 2308 do CCF 2318 chegaria atrasado. Além disso, a Meta Final 2306 pode receber uma confirmação originada de um consenso descentralizado devido ao fato das Trilhas de Salto Paralelo redundantes serem iniciados pelo PHL 2922. Portanto, ele pode ser codificado na Política Codificada Estática (SHP) que, para um pacote CCR 2308 ou CCF 2318 para ser aceito no nó de destino 786, ele deve chegar de pelo menos três trilhas de salto paralelo separadas. Isso remove a chance já fraca de um Nó de Rogue 806 sabotar o conteúdo do CCR 2308 ou CCF 2318 durante sua jornada. Qualquer número para o requisito mínimo de trilhas de salto paralelo que é o mais produtivo para a Rede BCHAIN 110 pode ser escolhido. Se um número muito baixo for escolhido, aumentará a chance de um ataque de sabotagem do Nó de Rogue 806. Se o número for muito alto, ele adicionará muito mais estresse de recursos à Rede BCHAIN 110. Um número muito alto também impediría que os Nós 786, muito próximos uns dos outros, confiassem entre si com informações, exceto se
Petição 870200056145, de 06/05/2020, pág. 159/1737
157/754 enviassem o pacote CCR 2308 ou CCF 2318 em torno de uma longa viagem de desvio, para que as trilhas de salto paralelo possam ser iniciadas para fins de comprovação. Portanto, a troca entre segurança/velocidade/confiabilidade e consumo de recursos existe dentro da Rede BCHAIN 110. Essa troca também experimenta o que é conhecido como a Lei dos Retornos Diminutos. Portanto, esperase que um aumento inicial nas trilhas de salto paralelo redundante produza um aumento maior na segurança/velocidade/confiabilidade do que um aumento realizado em um número já alto de vias de salto paralelo redundantes. Portanto, chega um estágio em que uma quantidade excessiva de Trilhas de Salto Paralelo Redundantes gera um aumento na segurança/velocidade/confiabilidade, mas sobrecarrega os recursos da Rede BCHAIN 110. Portanto, o módulo Redução da Trilha de Salto Paralelo Excessivo (OPHPR) 3000 é incorporado ao Protocolo BCHAIN 794 para detectar trilhas de salto paralelo que se tornaram um fardo ineficiente para o Sistema 110 e devem deixar de continuar sua jornada. A ilustração mostra o Nó 807 fazendo isso para uma trilha de salto paralelo iniciado pelo Nó 803. Um Nó 78 6 sabe quando parar uma trilha de salto paralelo referenciando a implantação da estratégia dos Critérios de Redução de Salto Paralelo 1004 916. Diferentes Aplicativos UBEC podem exigir uma prioridade mais alta para transmissão CCR 2308 / CCF 2318, portanto, uma quantidade maior de trilhas de salto paralelo. Esse Aplicativo ou uso pode ser transmissão ao vivo de áudio/video, o que exigiría a menor latência possível, portanto, as trilhas de salto mais redundantes possíveis. A quantidade de vias de salto paralelo redundantes geradas depende do tamanho da
Petição 870200056145, de 06/05/2020, pág. 160/1737
158/754 taxa da Unidade de Watts que foi pré-autorizada para o 2308 da CCR ou o 23 8 Token de Autorização Econômica (EAT) 994 da CCR.
[426] [00] A figura 50 mostra duas funções da Inteligência Adaptativa da Rede BCHAIN 110 em vigor. Tais funções permitem que o Protocolo BCHAIN 794 aproveite e tenha cuidado com os movimentos físicos dos Nós 815. A primeira função é para os Nós 786 que participam da jornada de pacotes CCR 2308/CCF 2318 iniciada pelo Nó 809 e paralelizada pelo Nó 811 perceber o movimento perturbador dos Nós 786 que existem na estrada de veículos 813. Enquanto encaminha os pacotes adiante, os Nós 786 favorecem os Nós Vizinhos 786 que se inclinam no lado esquerdo da estrada, para mitigar o movimento esperado que os Nós 815 terão em movendo os dados fisicamente para a direita. Essa função também significa que o Nó 811 aumenta substancialmente a quantidade de Trilhas de Salto Paralelo Redundante antes da Estrada do Veículo 813 para aumentar as chances de atravessar com sucesso a Estrada 813 até o Nó 817 que é a Meta Final 2306 em ação. Portanto, o pacote CCR 2308 / CCF 2318 que foi enviado pelo Nó 809 é capaz de alcançar com êxito a sua Meta Final 2306 do Nó 817 com obstrução mínima do movimento físico dos Nós 815 na estrada 813. A segunda função é que o Protocolo BCHAIN 7 94 aproveite os movimentos físicos dos Nós 815 entre a Estrada do Veículo 813, movendo-se para a direita. Esses Nós 815 podem ser smartphones rodando a Plataforma UBEC 100, estando no bolso dos Usuários UBEC 106 que estão dirigindo seus carros para trabalhar durante o trajeto diário da manhã. Essa funcionalidade de alavancar o movimento físico dos Nós 786 é processada pelos módulos de Camada de Migração de Dados Físicos (PDML) 3850 e Uso
Petição 870200056145, de 06/05/2020, pág. 161/1737
159/754 de Migração de Dados Físicos (PDMU) 3851. Essa funcionalidade de Migração Física permite um aumento geral da taxa de transferência no sistema, pois os movimentos físicos dos Nós 786 são feitos para trabalhar a favor da eficiência da Rede 110 e não contra ela. Isso pode ser um tremendo benefício para movimentos de dados em larga escala, geralmente entre grandes empresas. Por exemplo, se uma grande empresa quisesse enviar 10 Petabytes de dados corporativos de sua filial na Costa Oeste para sua filial na Costa Leste; o PDML 3850 pode reduzir bastante a transferência de dados de longo prazo de três meses para dois meses.
[427] [00] A Figura 51 mostra uma 'estrada' conhecida de viagens recomendadas entre vários Setores 884 dentro da Rede BCHAIN 110. Os Setores 884 são aglomerados de Nós BCHAIN 786 que facilitam logicamente a orientação e o roteamento de viagens dentro da Rede BCHAIN 110. A qualquer momento, qualquer Nó BCHAIN 768 está sob a jurisdição de exatamente dois setores 884. A única exceção conhecida é se um Nó BCHAIN 786 tiver muito poucos ou nenhum Vizinho do Nó 786. As definições dos setores 884 são derivadas do Hash de Escopo Duplo 4134 gerado pelo Consenso do Escopo de Tráfego (TSC) 4090. Portanto, o módulo de Descoberta Otimizada de Rotas do Setor (OSRD) 3430 interpreta o estado geográfico da Rede BCHAIN 110 conforme definido no Metachain 834 e produz as Rotas Setoriais Otimizadas 858 que são efetivamente vias de informação. Essas informações são submetidas ao Roteamento Setorial Otimizado 858 do Metachain 834. Um exemplo de Rota do roteamento otimizado do setor 858 é ilustrado na Fig. 51, mostrando as identidades dos dois Setores 884 que contêm a estrada entre eles e como uma Trilha de Salto de Linha de Base
Petição 870200056145, de 06/05/2020, pág. 162/1737
160/754
Proposta (PBHP) 2322 contém as instruções de roteamento para seguir essa estrada. Informações estatísticas como Força do Caminho (eficácia) e Saturação do Caminho (demanda/uso) estão incluídas no Roteamento Setorial Otimizado 858 do Metachain 834. As Rotas Setoriais Otimizadas 858 são usadas para permitir a busca eficiente de caminhos em toda a Rede BCHAIN 110. Portanto, um Nó 786 precisa apenas calcular manualmente, via Associação de Localização do Metachain 834, um caminho de e para a Rota Setorial Otimizada 858 (estrada). Portanto, a transmissão de longa distância dos pacotes CCR 2308 e CCF 2318 é altamente eficiente e repetível, com custos indiretos e repetitivos mínimos.
[428] [00] As Figuras. 52 - 53 mostram o Conteúdo de Liberação Escalonado 808 e o Conteúdo de Transmissão ao Vivo 814, que são dois métodos para transferir informações pela Rede BCHAIN 110 .
[429] Na Fig. 52 mostra o Conteúdo de Liberação Escalonado 808, que é o principal método empregado pelo Protocolo BCHAIN 794 para solicitar e atender a solicitações de conteúdo. Portanto, um Nó BCHAIN 78 6 usa o Gerador de Reivindicação de Conteúdo (CCG) 3050 para gerar uma Solicitação de Reivindicação de Conteúdo (CCR) 2308 que é finalmente enviada para o Nó 786 da Meta Final 2306 786. Portanto, o CCR 2308 é equipado com informações geradas e alteradas dinamicamente, como a Trilha de Salto de Linha de Base Proposta (PBHP) 2322 e Conjunto Variável de Trilha (TVS) 2320. O PBHP 2322 contém informações de roteamento referentes à sequência proposta de nós para alcançar e, finalmente, atingir a Meta Final 2306. O TVS 2320 contém informações dinâmicas sobre gerenciamento de logística da entrega
Petição 870200056145, de 06/05/2020, pág. 163/1737
161/754 do CCR 2308. Esses elementos do gerenciamento de logística incluem o Token de Autorização Econômica (EAT) 994 e uma instância do Implantação da Estratégia 916 que é referenciada durante as viagens em um setor específico. O CCR 2308 viaja através dos Nós 786 existentes nos Nós Intermediários 812. Depois do CCR 2308 chegar com êxito ao Nó 786 da Meta Final 2306 786, esse Nó 786 executa a Entrega de Reivindicação de Conteúdo (CCD) 3260 para tentar atender à solicitação de conteúdo feita pelo solicitante Nó 786. Portanto, um pacote de Cumprimento de Reivindicação de Conteúdo (CCF) 2318 é enviado em retorno, que viaja através do Nó Intermediário 812 para o Nó Solicitante 786. Posteriormente, o CCF 2318 é processado pelo Renderização de Reivindicação de Conteúdo (CCR) 3300 de acordo com o apropriado e método relevante de renderização dos dados preenchidos. A renderização de reivindicação de conteúdo (CCR) 3300 utiliza o Lançamento do Cache de Conteúdo Escalado (SRCC) 810 para reter partes do conteúdo até que toda a unidade de conteúdo possa ser totalmente renderizada.
[430] A Figura 53 mostra o Conteúdo de Transmissão ao Vivo 814, que difere no mecanismo em comparação com o Conteúdo de Liberação Escalonado. O mecanismo do Conteúdo de Transmissão ao Vivo 814 não utiliza Solicitações de Reivindicação de Conteúdo (CCRs) 2308 para reduzir a latência e aumentar a taxa de transferência em toda a Rede UBEC 110 para aplicativos específicos (ou seja, chamadas de áudio ao vivo). Portanto, as Necessidades de Conteúdo são preenchidas por meio dos CCFs 2318 aos Nós 786 que solicitam esse Conteúdo de acordo com as implicações de sua descrição e jurisdição. Portanto, o módulo
Petição 870200056145, de 06/05/2020, pág. 164/1737
162/754
Submissão Jurisdicionalmente Implícita de CCF (JICS) 4194 opera em um Nó BCHAIN 786 que percebe a necessidade jurisdicional de entrega de conteúdo de outro Nó 786. Portanto, um CCF 2318 é enviado pelos Nós Intermediários 812 sem um CCR 2308 que o acompanha recebidos e validados no Nó 786 da Meta Final 2306 pela Recepção CCF (JACR) 4208 aceita juridicamente, e posteriormente renderizados pela Renderização de Reivindicação de Conteúdo (CCR) 3300. A maioria dos aplicativos que fazem uso do JICS 4194 e JACR 4208 não exige a invocação do Lançamento do Cache de Conteúdo Escalado (SRCC) 810, pois o CCF 2318 provavelmente será renderizado imediatamente como em uma chamada de áudio/vídeo ao vivo, etc.
[431] [00] As Figuras 54 - 55 mostram como as trocas de Anúncio de Hash 802 entre Nós BCHAIN 786 levam ao consenso do Protocolo 794.
[432] Na Figura 54 de dentro do Aplicativo UBEC 778, o Sistema de Corroboração da Estratégia (SCS) 4080 usa o módulo Consenso do Escopo de Tráfego (TSC) 4090 para derivar uma coleção do Escopo Dual de Hash 4134. A composição do Escopo Dual de Hash 4134 é derivada das quatro variáveis produzidas pela Pesquisa estatística do nó (NSS) 778; índice de Escape do Nó 886, índice de Saturação do Nó 888, índice de Consistência do Nó 890 e índice de Sobreposição de Nó 892. Essas variáveis são derivadas pelo NSS 778 do Comportamento de Tráfego Externo 816. Devido à programação cooperativa dos Nós BCHAIN 786 que operam a versão autêntica e completa do Protocolo BCHAIN 794, a Rede BCHAIN 110 é totalmente resistente a ataques DDoS. Em um ataque DDoS legado na Internet, agentes mal-intencionados enviam pacotes de spam
Petição 870200056145, de 06/05/2020, pág. 165/1737
163/754 para os servidores selecionados, o que sobrecarrega sua capacidade de hardware/software. Por outro lado, a Rede BCHAIN 110 está constantemente se adaptando às variações de oferta e demanda. Como todo o tráfego na Rede BCHAIN 110 é rastreado, contabilizado e cobrado, uma tentativa de ataque DDoS para enviar spam a um nó ou cluster de nós simplesmente contribuiría para a economia da Rede BCHAIN 110 em vez de prejudicar sua infraestrutura. Além disso, todos os aplicativos executados na Rede BCHAIN 110 operam na Plataforma UBEC 100 e são avaliados para fins significativos pelo LUIG1 116 através da tecnologia LIZARD 120. Portanto, várias medidas preventivas foram empregadas para mitigar o spam e o abuso da rede.
[433]Na Figura 55, os Anúncios 824, 826, 828 e 830 são mostrados trocados entre três áreas de tráfego diferentes, conhecidas como Setores 884. Cada Nó 786 percebe dois hashes devido ao algoritmo que é executado no Consenso do Escopo de Tráfego (TSC) 4090. A Lógica de reconhecimento de hash duplo exige que pelo menos um dos dois hashes corresponda a dois nós para poderem se comunicar. Devido à lógica de arredondamento para baixo empregada no TSC 4090, um nó pode atravessar para diferentes ambientes de rede, mantendo consenso com outros nós. Isso se deve ao fato de que apenas um hash pode ser alterado de cada vez; portanto, o nó provavelmente terá uma sobreposição com pelo menos um hash com os Nós 786 ao redor, se eles estiverem operando utilizando o legítimo Protocolo BCHAIN 794 (em oposição a desonestos que tentam invadir o Protocolo 794) . Os hashes corretamente derivados para a Área de tráfego A 818 (Setor 884 A) são Al e A2. Os hashes corretamente derivados para a Área de
Petição 870200056145, de 06/05/2020, pág. 166/1737
164/754 tráfego AB 820 (a sobreposição dos setores 884 A e B) são Al, A2, Bl, B2. Os hashes corretamente derivados para a Área de tráfego B 822 (Setor 884 B) são Bl e B2. [00] A Figura 56 mostra a estrutura do Armazenamento do Customchain (CS) 832, que é o armazenamento local de Customchains. Os Customchains são blockchains avançados que adicionaram recursos como execução inteligente de contratos, referência e dependências de outros Appchains 786 paralelos e Fusão de Customchain Divididos. A fusão de Customchain divididoa ocorre quando o Customchain é dividido em dois por causa de uma separação geográfica de nós e, portanto, o [módulo] é capaz de fusioná-los novamente, reconciliando as diferenças nos dados recém-extraidos. O Metachain 834 é um Customchain que contém metadados aos quais todos os nós da Rede BCHAIN 110 se conectam para referência essencial e primária. O Metachain 834 não fornece conteúdo real, mas rastreia informações fundamentais que contêm locais do Nó 786/Setor 883, tendências de demanda de conteúdo e roteamento de saltos para otimizar a configuração da infraestrutura. Portanto, o Metachain 834 pode ser descrito como um banco de dados distribuído que gerencia a alocação de infraestrutura da Rede BCHAIN 110. O Metachain 834 oferece ganchos de atualizações de informações para acionar eventos relevantes sobre o Appchains 836. Portanto, os sistemas de notificação instantânea (ou seja, telefonemas, mensagens instantâneas) podem ser programados em um Appchain 836 referenciando o Metachain 834 como uma camada de sincronização principal. Existe apenas um Metachain 834 em que todos os Nós 786 devem participar da leitura e a maioria deve participar da mineração. Associação de Localização 840 do Metachain 834 Contém
Petição 870200056145, de 06/05/2020, pág. 167/1737
165/754 uma entrada de cada Nó 786 que está conectado ao Metachain 834. Cada entrada contém uma declaração desse Nó 786 sobre o que são seus vizinhos. Isso normalmente indica vizinhos físicos que estão próximos do alcance sem fio desse nó 786, mas isso também pode significar nós 786 interconectados por hosts legados BCHAIN que operam pela Internet (com ou sem fio). A Associação Setorial 842 contém uma entrada de cada Setor 884, que é uma coleção geográfica dos Nós 786 dentro dos limites estabelecidos. Cada setor 884 declara que é percebido como vizinhos do setor 884, o que permite algoritmos avançados de roteamento para traçar caminhos eficientes de e para os Nós Específicos 786. A localização do Nó de Diagnóstico 844 contém as identidades dos Nós 78 6 que se declararam nós de diagnóstico autoimpostos. Os nós de diagnóstico podem ser ou não confirmados com relação à execução da sua função reivindicada. A Atualização do Appchain 846 contém identificadores exclusivos do Appchain 836 para cada Appchain 836 registrado, juntamente com um carimbo de data e hora indicando a última vez que uma atualização foi feita. Dessa forma, os Nós 786 podem monitorar o Metachain 834 para Appchains 836 nos quais estão registrados, como um sistema de notificação em tempo real, e, posteriormente, buscar o conteúdo real diretamente dos Nós 78 6 que contêm o Conteúdo de Cache do Appchain. A Localização do Cache da Appchain 848 contém identificadores exclusivos do Nó 786 e do Setor 884 para nós que possuem conteúdo armazenado para um determinado Appchain 836. Portanto, se um Nó 786 estiver buscando informações que foram publicadas em um Appchain 836 para o qual se registrou, poderá verificar esta seção do Metachain 834 para saber o paradeiro
Petição 870200056145, de 06/05/2020, pág. 168/1737
166/754 desse conteúdo. A Localização de Mineração de Appchain 850 rastreia a localização relativa dos Nós 786 que se impuseram sobre a jurisdição de minerar um Appchain 836. Isso permite que os nós transmitam informações por meio do Anúncio de Novo Conteúdo (NCA) 2544 para atingir os Mineiros que validam as novas informações e as incluem no próximo bloco do Appchain 836. A Demanda de Appchain 852 contém informações relacionadas à popularidade de um Appchain 836 de acordo com o que os Setores 884 estão reivindicando seu conteúdo. Portanto, os locais de cache do Appchain 848 podem ser descobertos adequadamente. A Demanda Setorial 854 contém informações referentes ao peso do tráfego de informações dentro de um Setor 884. Isso permite que o Metachain 834 rastreie quais setores 884 estão enfrentando forte demanda de informações e quais não. Portanto, algoritmos subsequentes que operam o Protocolo BCHAIN 794 podem ajustar o fornecimento de infraestrutura para atender à demanda. O Rastreamento de Ambiente Caótico 856 rastreia quais nóssão considerados não confiáveis devido às variáveis do NSS 778 que exibem. Isso pode significar que eles têm um Alto índice de Escape de Nó 886, o que indica que eles não residem consistentemente no mesmo local. O roteamento otimizado do setor
858 contém as rotas propostas de salto de linha de base propostas (PBHP) 2322, que são as rotas perceptivelmente mais eficientes entre os setores 884. Portanto, usando essas informações, um único Nó 786 pode planejar uma rota eficiente para seu destino sem uma grande quantidade de recursos de consumo da CPU. O Rastreamento de Trabalho em Watts 860 rastreia várias proporções relativas a diferentes tipos de tipo de trabalho do Nó BCHAIN
Petição 870200056145, de 06/05/2020, pág. 169/1737
167/754
786 realizados e a quantidade de watts elétricos necessários para realizá-los. A Economia de Watts 862 rastreia o déficit ou excedente de unidades Watts (-U-) para cada Nó 786 conhecido. Portanto, o trabalho de transferência de informações realizado na Rede BCHAIN 110 é rastreado, assim, cada Nó 78 6 pode ser adequadamente compensado e cobrado pelo consumo e trabalho de conteúdo feito. Os Fundos de Emergência do Setor 864 representam fundos de Unidades Watt resgatáveis com a Economia Watt e só podem ser gastos por uma decisão de consenso entre os mineiros confirmados do Setor 884 ao qual os fundos pertencem. Os fundos são reservados para gastos em preservação de dados, o que se aproxima de um risco de perda permanente da integridade. Os Appchains 836 são Customchains que agem como contratos inteligentes avançados para fornecer informações por meio da infraestrutura organizada pelo Metachain 834. Os Appchains 836 podem se referir mutuamente para entrada/saida em estruturas paralelas e aninhadas conhecidas como Ecossistema Customchain 540. Portanto, as trocas de informações padrão, como e-mail, mensagens de texto, chamadas ao vivo e streaming de video, podem ser programadas no Appchains 836 com intervalos variados nos blocos de mineração devido à carga de recursos e compensações de sincronicidade. Um exemplo de aplicativo que pode ser convertido em um Appchain 836 é o aplicativo Uber Driving. O gerenciamento de um serviço autônomo de condução de carro pode ser completamente gerenciado de maneira descentralizada, com a atribuição e supervisão de motorista/passageiro executadas por meio de contratos inteligentes elaborados manifestados como um Appchain 836. O rastreamento de nó de origem 870 rastreia quando
Petição 870200056145, de 06/05/2020, pág. 170/1737
168/754 um CCR 2308 ou CCF 2318 se origina de um nó 786 referente a um Appchain 836 específico. Isso permite que o índice de isolamento de transferência de informação (ITII) 3218 seja calculado e, portanto, os nós 786 podem discernir se votam no Appchain 836 para ser convertido em um Microchain 838 ou não no Microchain Switch Index 872. O índice do Comutador Microchain 872 registra votos dos Nós 786 que têm acesso criptográfico a este Appchain 836 para determinar se este Appchain 836 atende aos critérios que requerem conversão para um Microchain 838. Quando uma maioria especificada de votos indica uma mudança, as informações carregadas e baixadas ocorrerão na versão Microchain 838 e, portanto, qualquer pessoa que não cumpra a vontade da maioria será excluída das atualizações de informações. Isso aconteceria porque nenhuma atualização de informações é enviada ao Metachain 834 para Microchains 838. As Microchains 838 são Appchains 836 que foram convertidos automaticamente em um Customchain que não depende nem se conecta ao Metachain 834. Isso ocorre quando os nós que participam de um determinado Appchain são isolados no local. Por exemplo, espera-se que esta conversão ocorra em um escritório corporativo em que um funcionário apenas o Appchain 836 esteja sendo executado. O Protocolo BCHAIN 794 detectará que a transferência de informações possui um alto grau de isolamento geográfico (sem fazer referência às coordenadas GPS) e, posteriormente, converterá o Appchain 836 em um Microchain 838 com o objetivo de obter eficiência no consumo de recursos. A funcionalidade anterior do Metachain 834 é substituída pelo Emulador Metachain 882, que reside no Microchain 838, portanto, o público em geral dos Nós 786 não precisa arcar com o ônus de
Petição 870200056145, de 06/05/2020, pág. 171/1737
169/754 processar informações transferidas em rotas isoladas e obscuras que eles não pretendem no acesso. Portanto, qualquer menção da funcionalidade ou presença do Appchain 836 dentro das especificações do Protocolo BCHAIN 794 é intercambiável e compatível com um Microchain 838. 0 Rastreamento de Nó de Origem 880 rastreia quando um CCR 2308 ou CCF 2318 se origina de um nó referente a um Microchain 838 específico. Isso permite que o índice de Isolamento de Transferência de Informação (ITII) 3218 seja calculado, o que permite que os Nós 78 6 votem se o Microchain 838 deve ser convertido novamente em um Appchain 836 ou não. O Emulador Metachain 882 é um espaço reservado para todo o Metachain 834 que é armazenado no Microchain 838. Dessa forma, a Rede BCHAIN 110 faz as mesmas solicitações e modificações de informações neste Emulador Metachain 882 que faria para o Metachain 834 normal ao lidar com um Appchain 83 6 que foi convertido em um Microchain 838.
[434] [00] Figuras 57 - 58 mostra Pesquisa Estatística de Nós (NSS) 778.
[435] Na Figura 57, o NSS 778 reúne informações sobre o comportamento dos Nós Vizinhos 786 para calcular quatro índices principais 886, 888, 890, 892. Por sua vez, informa os módulos que operam as funções principais do Protocolo BCHAIN 794 sobre o estado da rede BCHAIN 110 em relação à atividade e comportamento do N 786. Portanto, funções úteis são derivadas, como consenso sobre a composição do Setor 884 etc. O módulo Lógico de Interação do Nó (NIL) 2380 opera como um Subconjunto da Porta de Comunicações (CG) 2348 e interage com a Interface de hardware 762 via Sistema operacional 790 e os Pontos Finais da API 792.
Petição 870200056145, de 06/05/2020, pág. 172/1737
170/754
Um Ping é uma interação de rede com hardware externo. Portanto, todos os Pings relacionados aos Nós 786 nas imediações do Nó 786 que estão executando a instância do NSS 778 são encaminhados para o Processamento de Pings no Nó (NPP) 894. O Banco de Dados de Atividade do Nó (NAD) 8 96 é um banco de dados local que retém dados brutos em relação à atividade de Ping do nó 786. O NAD 896 se torna a principal fonte de informações para a NPP 894 executar as Consultas Operacionais 904 que levam ao Cálculo do índice 906 da coleção Variáveis do índice do Nó 912. O O índice de Escape de Nó 886 rastreia a probabilidade de que um Nó Vizinho 786 escape da faixa de detecção de um Nó 78 6 que percebe. Um alto índice de Escape 886 indica um ambiente mais caótico que exigirá estratégias refinadas para enfrentar. Exemplos: smartphones em carros que estão em uma estrada exibem um alto índice de Escape de Nó 886. Um refrigerador em um Starbucks exibirá um índice de escape de Nó 886 de detecção muito baixa. Um índice de saturação mais alto indica uma área lotada com muitos Nós 786. Isso pode ter impactos positivos e negativos no desempenho devido às compensações de oferta/demanda, mas espera-se que uma área com mais densidade do Nó 786 seja mais estável/previsível e, portanto, menos caótico. Exemplos: um Starbucks no coração da cidade de Nova York possui um alto índice de saturação de Nós 888. Uma barraca no meio de um deserto terá um índice de saturação de Nós 888 muito baixo. O índice de consistência de nós 890 rastreia a qualidade dos serviços do nó 786 como interpretados por um Nó que percebe 786. Um alto índice de consistência dos Nós 890 indica que os Nós Vizinhos 786 tendem a ter mais tempo de disponibilidade e consistência no desempenho. Os nós 786 que
Petição 870200056145, de 06/05/2020, pág. 173/1737
171/754 têm propósitos duplos em uso tendem a ter um índice de Consistência 890 mais baixo, enquanto os nós dedicados à Rede BCHAIN 110 exibem um valor mais alto. Exemplos: os Nós 786 que têm uma finalidade dupla, como um computador de funcionário corporativo, terão um baixo índice de Consistência 890, pois possui menos recursos disponíveis durante o horário de trabalho e mais recursos disponíveis durante os intervalos para almoço e ausência de funcionários. O índice de Sobreposição de Nós 892 rastreia a quantidade de nós de sobreposição que são interpretados por um Nó 786 percebido. Enquanto os índices de sobreposição 892 e de saturação 888 tendem a ser correlacionados, eles são distintos, pois o índice de Sobreposição 892 indica a quantidade de sobreposição comum entre vizinhos e o índice de Saturação 888 lida apenas com tendência física. Portanto, um alto índice de Saturação 888 com um longo alcance sem fio em cada dispositivo levará a um alto índice de sobreposição 892. Exemplos: Os dispositivos começam a entrar em determinados setores 884 da BCHAIN Network 110 com a arquitetura do novo processador UBEC/BCHAIN Microchip (UBMA) 4260 instalado, que possui uma antena direcional de alto ganho com tecnologia avançada de formação de feixe. Portanto, o índice de Sobreposição 892 aumenta nos setores 884 devido aos nós 786 terem uma estrutura de comunicações mais sobreposta. Com a Detecção de Nó Significativa (SND) 898, os Nós 786 com características anormais e/ou informativas são destacados para facilitar o cálculo dos índices pretendidos.
[436] Na Fig. 58 são mostrados os detalhes do Processamento de Ping de Nó (NPP) 894. Os Registros de Ping do
Petição 870200056145, de 06/05/2020, pág. 174/1737
172/754
Nó 908 são contêineres de informações enviadas pela Lógica de Interação do Nó (NIL) 2380 como um subconjunto da Porta de Comunicação (CG) 2348. Inicialmente são recebidos no Tráfego de Entrada 902. Cada Registro de Ping do Nó 908 contém a identidade relativa aos dados relevantes. O Nó 786, bem como um carimbo de data/hora de expiração 910. Esse registro de data e hora 910 faz com que o NSS 778 relate informações atualizadas que refletem o estado atual da vizinhança local da Rede BCHAIN 110. Se os registros individuais de Ping de Nó 908 não expirarem depois de um longo período de tempo, as Variáveis do índice de Nós 912 não refletem com precisão o estado atual da vizinhança local, se não uma média. Os registros de Ping do Nó 908 do Tráfego de Entrada 902 são eventualmente armazenados no Banco de Dados de Atividade do Nó (NAD) 896. A partir daí, as consultas operacionais 904 processam os registros de Ping do Nó 908 em lotes, considerando o registro de data e hora de expiração 910. Portanto, os registros 908 são finalmente calculados de acordo com os critérios das quatro variáveis de índice de Nó 912 no Cálculo de índice 906.
[437] [00] A Fig. 59 mostra o Sistema de Corroboração de Estratégia (SCS) 4080, que opera um Sistema de Construção de Consenso do Protocolo 794 entre os nós BCHAIN 786. 00 Consenso de Escopo de Tráfego (TSC) 4090 produz um Hash de Escopo Duplo 4134 definido pela referência às variáveis NSS 778 e definições estáticas de Política de Código Estático (SHP) 488. O SHP 488 contém critérios codificados no protocolo BCHAIN 794. Esses critérios são estáticos em oposição aos critérios habituais da estratégia dinâmica, porque esses critérios são usados para definir a própria estratégia. Portanto, se o mecanismo usado para
Petição 870200056145, de 06/05/2020, pág. 175/1737
173/754 produzir estratégias em si se basear em estratégias, espera-se que o sistema acabe entrando em um estado extremo que possui funcionalidade e eficácia limitadas e/ou anormais. 0 SCS 4080 chama a Derivação de Identidade do Setor (SID) 2092 para usar os Hash de Escopo Duplo 4134, Hash 14136 e Hash 24138 para atuar como base para definir as identificações atuais do Setor 2094. Portanto, cada Nó 786 em qualquer momento existe dentro da jurisdição de exatamente dois Setores 884, cada um definido por Hash 14136 e Hash 24138. Com a Corroboração de Hash 4086, os Hashes 4134 anunciados pelos vizinhos 786 são comparados com os Hashes 4134 produzidos localmente. Se nenhum dos hashes corresponder, o Nó Vizinho 786 será adicionado à lista de blocos de nós 4082. Com a percepção de tráfego de nó especifico 4084; Os nós 786 que são forem reconhecidos como legítimos devido a seu Anúncio de Hash 4088 correspondente podem informar outros Nós 786 sobre os Nós 786 que eles suspeitam ser Nos de Rogue 806 e operando além dos limites do Protocolo BCHAIN 794 definidos na Política de Código Estático (SHP) 488. A Lista de Nós Bloqueados 4082 contém as identidades dos Nós 786 suspeitos de serem Nós de Rogue 806 porque eles não conseguem produzir pelo menos um Hash 4134 correspondente. Portanto, eles estão impedidos de interagir e transferir informações com os nós legítimos 786 para impedir spam e abuso de rede.
[438] [00] As Figuras 60 - 63 detalham a operação do Consenso do Escopo do Tráfego (TSC) 4090.
[439] Na Fig. 60, o TSC 4090 chama o NVP 4140 para receber variáveis de Pesquisa Estatística de Nó (NSS) 778 e produzir uma Média Composta de Variáveis NSS (NVCI) 4108. Com os
Petição 870200056145, de 06/05/2020, pág. 176/1737
174/754
Nós 78 6 do NVP 4140 de dentro dos mesmos Setores 884 anunciam sua percepção das variáveis do NSS 778 entre si para criar consenso sobre as 884 características do setor. Portanto, as variáveis locais e remotas do NSS 778 são agrupadas para criar uma média composta conhecida como NVCI 4108. Esse composto é usado para manter um consenso sobre o escopo e a definição deste Setor 884 e, portanto, onde estão seus limites físicos. Após a conclusão da produção do NVCI 4108, cada um dos índices agrupados 886, 888, 890, 892 é transferido para o Estágio 4094. A versão em pool do índice de Escape do Nó 886 é arredondada para baixo para o múltiplo X mais próximo no Estágio 4100. A versão em pool do índice de Saturação do Nó 886 é arredondada para baixo para o múltiplo mais próximo X no estágio 4102. A versão no pool do índice de Consistência de Nó 890 é arredondada para baixo para o múltiplo X mais próximo no Estágio 4104. A versão em pool do índice se Sobreposição do Nó 892 é arredondada para baixo para o múltiplo X mais próximo no Estágio 4106. Quando o Estágio 4098 também é concluído (como se mostra na Fig. 61), todas as variáveis produzidas no Estágio 4094 são fusionadas em uma única variável no Estágio 4094.
[440] Na Fig. 61, os fatores de desempenho 4110 são produzidos pelo Pool de Variáveis do NSS (NVP) 4140 e submetidos ao Estágio 4098 para que também sejam arredondados para o múltiplo X mais próximo (juntamente com os outros cálculos encontrados no estágio 4094). Os fatores de desempenho 4110 são medições de desempenho referentes ao tráfego da Rede 110 no Setor 884 relevante, como saltos médios por segundo, megabytes médios por segundo etc. O valor X usado no Estágio 4094 vem do
Petição 870200056145, de 06/05/2020, pág. 177/1737
175/754
Arredondamento de Consenso de Tráfego Múltiplo 1024 da Implantação da Estratégia 916. A própria unidade da Implantação da Estratégia 916 é extraída de um Conjunto Variável de Trilhas (TVS) 2320 que é processado pelo Setor de Cruzamento de Eventos (SCEP) 3360. Portanto, espera-se que o Múltiplo 1024 seja diferente dentro de cada Setor 884, permanecendo o mesmo para todos os Nós 786 no mesmo setor 884. Portanto, os resultados da fusão realizada no Estágio 4092 tornam-se a base para o Hash 14136 do Hash de Escopo Duplo 4134. A base do Hash 24138 é produzida pelo Estágio 4118, conforme mostrado na Fig. 62.
[441] Na Fig. 62, o mesmo NVCI 4108 é referenciado a partir do processo de arredondamento realizado no Estágio 4094, exceto no Estágio 4120, o processo é arredondado para cima a partir do mesmo múltiplo X que é retirado do múltiplo de 1024 de consenso de tráfego. Além disso, os mesmos fatores de desempenho 4110 do NVP 4140 são processados, embora arredondados para cima. Portanto, a saída da Fusão Processada no Estágio 4118 será derivada das mesmas referências do NVCI 4108 e dos fatores de desempenho 4110 que o estágio 4094, mas um resultado diferente será gerado devido à diferença de afinidade de arredondamento.
[442] Na Figura 63, ambas as variáveis que foram produzidas pelos estágios 4092 e 4118 tornam-se a semente da geração de Hash Alfanumérico no Estágio 4132. Portanto, dois Hashes são produzidos; Hash 14136 e Hash 24138 do Esopo Dual de Hash 4134. Estes se tornam os principais fatores definidores dos Setores 884, que são o principal mecanismo de orientação para retenção e movimentação de dados na Rede BCHAIN 110.
[443] [00] As Figuras 64 - 65 mostrar Adaptação Dinâmica
Petição 870200056145, de 06/05/2020, pág. 178/1737
176/754 da Estratégia (DSA) 772.
[444] A Figura 64 mostra como o DSA 772 atua como estrutura para a criação de variáveis dinâmicas que controlam os fatores de processamento na Rede BCHAIN 110. Tais variáveis são empacotadas e transferidas através da Implantação da Estratégia 916, que é transportada dentro de uma Trilha de Suite Variável (TVS) 2320. O DSA 772 mantém e ajusta constantemente variáveis que controlam as operações da Rede 110 de acordo com o estado da rede física, conforme relatado pelas variáveis do NSS 778 segundo a Interpretação de Caos no Campo (FCI) 918. A FCI interpreta o nível geral de caos de disponibilidade do Nó 786 em toda a Rede BCHAIN 110. A Implantação da Estratégia 916 é um conjunto de critérios empacotados que define valores operacionais nos módulos do Protocolo BCHAIN 794. O Algoritmo de Seleção da Estratégia Otimizada (OSSA) 956 seleciona a estratégia 914 mais adequada e ideal que opera melhor sob as condições ambientais que foram declaradas pelo NSS 778. Portanto, a Estratégia Preferida Atual (SCM) 914 é usada como entrada para o Módulo de Criação de Estratégia (SCM) 984 para ajustar a estratégia com experimentação. O SCM 984 usa o Módulo de Criatividade 112, que opera como um AppChain pesado do Segmento de Execução 551, para hibridar a forma da Estratégia Preferida Atual 914 com a interpretação atual do Caos no Campo FCI 918. Portanto, a Rede BCHAIN 110 está em constante estado de tentativa e erro gradual, desenvolvendo experimentação de baixo risco com ajustes variáveis para aprender correlações de causa e efeito entre os Critérios de Estratégia 992 e o desempenho real da Rede de trabalho 110. A Atribuição de Prioridade e Prova (PAP) 922 modifica os Critérios
Petição 870200056145, de 06/05/2020, pág. 179/1737
177/754
992 da Implantação da Estratégia 916 para executar com prioridade estendida de acordo com o valor extra pago pelo Usuário UBEC 106. Essa priorização é um processo automatizado, por exemplo; o Usuário UBEC 116 disca a outro Usuário 106 com a Chamada Telefônica do AppChain. Então o AppChain 836 solicita ao PAP 922 para aumentar a prioridade da transmissão de pacotes, para que seja possível estabelecer uma conexão telefônica consistente e confiável. A quantidade extra de Unidades de Watt que custa a ligação telefônica, em oposição às transferências de dados de prioridade padrão, é deduzida da Alocação de Fundos Privados do Usuário 106 e do usuário UBEC (UPFA) 718. Portanto, a Implantação da Estratégia 916, que é produzida posteriormente, contém um valor relativamente alto para os Critérios de Propagação de Salto Paralelo 1002 e um valor relativamente baixo para os Critérios de Redução de Salto Paralelo 1004. Portanto, mais Caminhos de Salto Paralelo são iniciados, o que leva a menor latência, menor perda de pacotes, maior confiabilidade etc. As Implementações de Estratégia 916 são empacotadas em Trilhas de Suíte Variável (TVS) 2320 de um CCR 2308 ou CCF 2318. As Estratégias de Tráfego 914, 916 são dinâmicas, mas existem limites codificados que são reconhecidos por todos os Nós Legítimos 786 como os limites do tráfego legítimo normal. Esses limites codificados são referenciados como Limites Acordados no Escopo da Estratégia 996. Portanto, se algum Nó 786 gerar tráfego além desses limites, o seu tráfego será considerado spam pelos Nós Legítimos 786. Esses limites são escaláveis em relação ao tráfego da Rede 110, o que significa que a Rede BCHAIN 110 pode crescer indefinidamente, sem atingir limites codificados permanentemente, mantendo as
Petição 870200056145, de 06/05/2020, pág. 180/1737
178/754 proteções contra abusos. 0 Acompanhamento do Desempenho da Estratégia (SPT) 920 é um banco de dados (que funciona como um AppChain) que rastreia o desempenho percebido de várias Implementações de Estratégia 916 na Rede 110, o que permite ao OSSA 956 selecionar o que é considerado a Estratégia Preferida Atual 914 considerando as condições locais da Rede 110.
[445]Na Figura 65 A Interpretação do Desempenho da Estratégia (SPI) 3420 recebe estratégias implantadas com dados de campo que determinam o desempenho percebido de tais estratégias em condições ambientais variadas. A fila de transmissão de informações (QIB) 2700 retransmite as Implementações da Estratégia 916 que estiveram ativas no campo para relatar as condições ambientais ao SPI 3420. Isso leva a uma correlação de causa e efeito a ser calculada no módulo DSA 772 referente aos Critérios 992 da Implementação da Estratégia 916 .
[446] [00] As Figuras 66 - 67 mostram a estrutura do banco de dados do Acompanhamento de Desempenho da Estratégia (SPT) 920, que opera como um Appchain 836 pesado do Segmento de Dados 553. O SPT 920 armazena unidades das Estratégias 916, além da Estratégia D28 924 e a Estratégia Kl 1 940. Cada Estratégia 916 tem uma Estratégia básica Critérios Composição 928, 944, que atua como a identidade principal da Estratégia 916, pois todos os critérios definidores são armazenados lá. Portanto, todas as outras variações na unidade da Estratégia 916 atuam como medidas logísticas de desempenho e tempo para permitir que o OSSA 956 escolha o que considera ser a Estratégia Preferida Atual 914. Cada unidade da Estratégia 916 possui uma Marca Temporal de
Petição 870200056145, de 06/05/2020, pág. 181/1737
179/754
Expiração 926, 942. A Expiração 926, 942 é estendida toda vez que uma atualização da Estratégia 916 é fornecida pela Interpretação do Desempenho da Estratégia (SPI) 3420. Portanto, a Marca Temporal de Expiração 926, 942 protege o banco de dados do SPT 920 de manter dados de desempenho desatualizados e irrelevantes. Associadas a cada Estratégia 924, 940, existem várias Unidades de Rastreamento de Desempenho 930, relatadas pelo SPT 920. Uma Unidade de Rastreamento 930 contém um NSS Composição 932, 936, 948, 952 e um índice de Desempenho 934, 938, 950, 954. A Composição NSS captura as Variáveis 886, 888, 890, 892 do NSS 778 que existiam quando esta Unidade de Rastreamento 930 foi capturada. O índice de Desempenho registra medições de desempenho, como saltos por segundo, megabytes por segundo etc. Os dados retidos nos índices de Composição e Desempenho do NSS 778 permitem que o OSSA 956 reconheça que a Estratégia Preferida Atual 914 está segundo às variáveis atuais do NSS 778 que estão sendo relatado à OSSA 956.
[447] [00] As Figuras 68 - 70 mostram o trabalho detalhado do Algoritmo de Seleção de Estratégia Otimizada (OSSA) 956 .
[448] A Figura 68 mostra o Acompanhamento de Desempenho da Estratégia (SPT) 920 conectando-se indiretamente (via fluxo lógico) ao algoritmo de seleção de variáveis múltiplas (MVSA) 962. O MVSA 962 seleciona a Estratégia 916 mais apropriada dos dados no SPT 920. Os dados do SPT 920 são usados para derivar um índice de Desempenho da Estratégia 958, que é uma média composta de todos os índices de desempenho individuais listados em uma única Estratégia 916. O Ranking de Confiança da Estratégia 960
Petição 870200056145, de 06/05/2020, pág. 182/1737
180/754 indica quanta precedência/evidência está disponível para justificar a percepção do índice de Desempenho da Estratégia 958. O MVSA 962 faz referência à Política de Código Codificado Estático (SHP) 488 para discernir os critérios pelos quais selecionar a Estratégia 916 apropriada. Portanto, o MVSA 914 envia a Estratégia Preferida Atual 914 como saída modular, que é a saída modular final do OSSA 956. Portanto, o MVSA 962 conduziu a decisão principal ao selecionar a Estratégia 914 que esperava oferecer o melhor desempenho e eficiência, considerando as variáveis atuais do NSS 778.
[449] A Figura 69 mostra mais detalhes no OSSA 956, que leva do SPT 920 ao MVSA 962. O estágio 958 recupera todas as Estratégias 916 que não expiraram no SPT 920. Portanto, Todas as Estratégias Ativas 960 são montadas e contêm a Estratégia D28 924 e a Estratégia Kll 940, que foram ilustradas em detalhes nas figuras 66 e 67. O Estágio 962 recupera todas as composições do NSS 778 de Todas as Estratégias Ativas 960 que estão dentro do alcance da Composição Local NSS 970, conforme fornecido por uma instância atual da operação do NSS 778 do Estágio 968. A magnitude desse intervalo é definida em Política Codificada Estática (SHP) 488. Portanto, o estágio 962 produz a Composição NSS 778 dentro do intervalo 964, que contém as unidades selecionadas de Rastreamento de Desempenho 930 de várias Estratégias 916. Posteriormente, no Estágio 966, as Unidades de Rastreamento de Desempenho 930 são organizadas de acordo com a definição da Estratégia 916, que é a Composição dos Critérios de Estratégia 992 .
[450] A Figura 70 continua o fluxo lógico do OSSA 956
Petição 870200056145, de 06/05/2020, pág. 183/1737
181/754 do Estágio 966. A saida do Estágio 966 é os Containers de Estratégias 972, que contém Estratégias 916 selecionadas que contêm as Unidades de Rastreamento de Desempenho 930 que foram inicialmente selecionadas no Estágio 930. O Estágio 974 faz referência ao Container de Estratégias 972 para calcular o índice de Desempenho Médio 930 por Estratégia 916, que gera o índice de Desempenho da Estratégia 978. Portanto, o Ranking de Confiança da Estratégia 980 é calculado pela Estratégia 916. Esse Ranking 980 indica quanta precedência/evidência, dos dados extraídos do SPT 920, está disponível para justificar a percepção sobre o desempenho da Estratégia 916. Posteriormente, o Estágio 982 seleciona a estratégia preferida de acordo com o Performance 978 e a Avaliação de Confiança 980 via MVSA 962.
[451] [00] As Figuras 71 - 74 mostram o Módulo de Criação de Estratégia (SCM) 984, que é invocado pela Adaptação Dinâmica da Estratégia (DSA) 772. O SCM 984 varia inteligentemente composições das Estratégias 914 por meio do Módulo de Criatividade 112 para criar Estratégias experimentais de baixo risco 916 que se baseiam nos pontos fortes das iterações anteriores.
[452] Na Figura 71, a Interpretação do Caos de Campo (FCI) 918 envia sua saída da Interpretação do Caos ao Estágio 986, que a envia à Criatividade 112 como um Formulário de Entrada. Os Critérios Estáticos 998 de criatividade 112 são baseados nos
Limites do Escopo da Estratégia Acordados 996 e o valor da Unidade Watt que foi pré autorizado no EAT (Token de Autorização Econômica) 994 (daí o nível de prioridade) . O token EAT 994 é fornecido pela Cessão Prioritária e Prova 922 . A Estratégia
Petição 870200056145, de 06/05/2020, pág. 184/1737
182/754
Preferida Atual 914 é recebida pelo OSSA 956 e é descompactada no Estágio 990 para recuperar a Critérios de Composição de Estratégia 992.
[453] A Figura 72 mostra os vários Critérios 992 que compõem os Critérios de Estratégia Composição 994. Cada Implantação de Estratégia 916 tem um valor definido para cada um desses critérios.
[454] A Expiração do testemunho de Salto 1001 indica quanto tempo deve ter passado para que uma entrada do testemunha de salto na história do salto recente (RHH) 2354 seja ignorada. Essa variável é usada para remover as rotas de salto paralelo potencialmente inúteis de serem geradas. Isso ocorre porque, se um CCR 2308 ou CCF 2318 já passou por este Nó 786 há muito tempo, há uma chance cada vez menor de gerar um novo CCR 2308 ou CCF 2318 paralelo que ultrapassará o anterior.
[455] Os Critérios de Propagação de Salto Paralelo 1002 indicam a largura que os Saltos Paralelos devem ser espalhados e em que valores de ativação de variáveis. Mais saltos paralelos indicam maior confiabilidade e qualidade na transferência da informações. Portanto, os CCRs 2308 e os CCFs 2318 que contêm sinalizadores de prioridade nos seus Tokens de Autorização Econômica (EAT) 994 levarão a um maior Critério de Propagação de Salto 1002.
[456] O Critério de Redução de Salto Paralelo 1004 indica quando devem ser removidas as Trilhas de Salto Paralelo devido a redundância. Uma remoção anterior das Trilhas de Salto Paralelo levará a uma menor confiabilidade e qualidade do serviço. Portanto, os CCRs 2308 e os CCFs 2318 que contêm
Petição 870200056145, de 06/05/2020, pág. 185/1737
183/754 sinalizadores de prioridade nos sens Tokens de Autorização Econômica (EAT) 994 levarão a um menor Critério de Redução de Salto 1004.
[457] A saturação de Conteúdo Necessária para o Cache 1006 é a quantidade mínima de ocorrências nas quais um AppChain 836 foi testemunho recentemente por esse nó no Histórico de Saltos Recentes RHH (233) . Portanto, o conteúdo frequentemente testemunhado será armazenado em cache, o que otimiza gradual e automaticamente os locais do cache entre um conjunto de nós caoticamente distribuídos.
[458] O Deslocamento Mínimo de Salto Necessário para o Cache 1008 é a quantidade mínima de progresso que precisa ser concluída para o nó armazenar em cache o conteúdo, ou seja, pelo menos 50% do Deslocamento do Salto precisa ter concluído antes de deixar armazenar no cache. Portanto, apenas os Nós 786 que participam da jornada depois do ponto intermediário serão elegíveis para armazenar em cache o conteúdo.
[459] O Ponto de Salto da Declaração de Demanda 1010 é o ponto de salto ao longo da jornada CCR 2308 ou CCF 2318 na qual o Nó 786 declara ao Metachain 834 que a Demanda do Appchain 852 e a Demanda de Setor 854. A Demanda do AppChain 852 é rastreada para decidir o cache e os locais do Appchain 836, enquanto A Demanda do Setor 854 é rastreada para calcular os diferentes preços dos diferentes Setores 884. Portanto, é produzida uma economia eficiente de oferta/demanda.
[460] Confiabilidade Mínima do Nó para a Implantação da Trilha 1012 é o nível mínimo de confiabilidade de um Nó 78 6, conforme adjudicado pelas variáveis do NSS 778, para que um nó
Petição 870200056145, de 06/05/2020, pág. 186/1737
184/754 seja incluído em uma Trilha de Salto. Essa trilha pode ser a ideal ou trilhas paralelas menos capazes.
[461] 0 Critério de Mineração Autoimposta 1014 é a quantidade mínima de recursos de computação relativos necessários para minerar um Appchain 836. Essa quantidade é proporcional à carga de recursos de 4 minerações do Appchain 786, uma vez que alguns Appchains 836 são mais pesados que outros, bem como a urgência imediata desse AppChain 836 requer que novos mineradores preservem a integridade dos dados.
[462] Os Critérios para Prevenção de Ambiente Caótico 1016 definem características dos nós que os indicam esporádicos e não confiáveis, conforme entendidos pelas variáveis fornecidas pelo NSS 786. Portanto, ambientes que envolvem movimentos imprevisíveis e esporádicos e a disponibilidade dos Nós 786 podem ser tratados de acordo com critérios dinamicamente inteligentes.
[463] Os CCFs a reter no Clash Cache 1018 definem a porcentagem do armazenamento do Nó local 78 6 que deve ser alocado para reter os CCFs 2318 que não existem no Cache de Conteúdo do Nó Primário (PNCC) 1218. Portanto, se um CCR 2308 e o seu correspondente CCF 2318 armazenado cruzarem o caminho um do outro prematuramente, a solicitação de conteúdo pode ser devidamente atendida. Há uma quantidade otimizada de ponto ótimo de CCFs 2318 a serem retidos para fazer uso eficiente de conflitos de informações não intencionais e caóticos. Portanto, a variação dinâmica das Estratégias 916 pela DSA (Adaptação de Estratégia Dinâmica) 772 tenta descobrir e implantar a variável 'ponto ótimo'.
[464] Troca de Confiabilidade/Distância da Rota 1020
Petição 870200056145, de 06/05/2020, pág. 187/1737
185/754 define a zona de eficiência percebida em relação à troca de seleção entre a confiabilidade dos Nós 786 selecionados e a distância esperada percorrida. A variável idealmente ajustada para obter a máxima eficiência dependerá de acordo com as variáveis ambientais circundantes contabilizadas pela NSS 778.
[465] 0 ITII Gatilho Microchain 1022 define o valor do índice de Isolamento de Transferência de Informação (ITII) 3218 necessário para merecer um nó votando para alternar um AppChain 836 para um formato Microchain 838, que omite o gasto de recursos no Metachain 834 e, portanto, otimiza o uso de recursos para transferências isoladas geograficamente de informação.
[466] Arredondamento de Consenso de Tráfego Múltiplo 1024 é o múltiplo do qual NVCI 4108 e variáveis de desempenho são arredondadas para cima ou para baixo. Se esse valor aumentar, o tamanho relativo dos Setores 884 que são influenciados por essa variável aumentará gradualmente de tamanho. Se esse valor diminuir, os Setores 884 diminuirão de tamanho e o Nó 786 contará.
[467] O intervalo de agrupamento variável do NSS 1026 define com que frequência os Nós 786 devem anunciar um ao outro (nos Setores 884 com os quais compartilham uma sobreposição) as variáveis NSS 778 que percebem. Portanto, um Setor 884 criará consenso sobre suas próprias características do NSS 778. Se esse intervalo for menor; haverá maior integração e mais sincronicidade, ainda mais recursos da Rede 110 esgotados. Se esse intervalo for maior; haverá menos sincronicidade e menos recursos da Rede 110 esgotados.
[468] O Multiplicador de pagamento do trabalho 1028 define a intensidade da discrepância no pagamento entre o Setor
Petição 870200056145, de 06/05/2020, pág. 188/1737
186/754 mais baixo e o mais alto de pagamento 884. Portanto, a economia pode ser mais intensa ao recompensar unidades de trabalho em áreas altamente saturadas. Quando essa variável aumenta, aumenta o desejo de participar de áreas fortemente saturadas, o que leva a menos motivação para participar de áreas esparsas. Portanto, quando essa variável é alta, a infraestrutura tende a se adaptar mais rapidamente e melhor às flutuações da demanda de conteúdo. No entanto, como a consistência da demanda pode ser caótica, isso levaria a uma flutuação mais caótica da localização da infraestrutura.
[469] 0 Tempo Mínimo de Retenção de Cache 1030 define a quantidade mínima de tempo que um Nó de Cache 785 é necessário para reter um cache que ele optou por adotar. O uso dessa variável visa impedir que a Rede BCHAIN 110 tenha uma rotatividade excessivamente caótica no Local de Cache 848, o que levaria a um aumento da latência e à confiabilidade reduzida em relação à entrega de conteúdo. Se essa variável fosse definida muito alta, levaria a uma rede de distribuição de cache a se tornar excessivamente rígida e incapaz de se adaptar adequadamente às mudanças na demanda de conteúdo.
[470] A Taxa de Pagamento de Mineração para Armazenamento em Cache 1032 aloca uma divisão de pagamento entre o Trabalho Passivo realizado por meio do Algoritmo de Seleção de Mineração (MSA) 2484 e o Trabalho Passivo realizado por meio do Algoritmo de Seleção de Cache (CSA) 2350. Portanto, essa Razão 1032 decide entre compensação do dilema de recursos finitos que é inerente à rede BCHAIN 110. Essa troca é entre manter redundância suficiente da integridade dos dados e cache
Petição 870200056145, de 06/05/2020, pág. 189/1737
187/754 geograficamente distribuído adequado, servindo para um serviço ideal.
[471] 0 Limite de exclusão de peças de cache 1034 define quando é seguro para os mineradores de um setor 884 que estão recuperando dados por meio do Processamento de Refúgio de Dados (DRP) 1984 para excluir esses Dados em Perigo. O Provedor de Cache de Nó (NCP) 2080 fornece partes dos Dados em Perigo do Conjunto de Propagação de Cache 2112 para os Nós 786 que estão em conformidade com o ultimato definido pelos mineradores de acordo com a Unidade de Consequência Fiscal 1852. Mesmo que o Cumprimento de Cache possa já ter ocorrido, ele ainda pode não ser apropriado excluir a cópia dos Dados em Perigo do Mineiro. Isso ocorre porque alguns Nós 786 podem optar por adotar os Dados, independentemente de o cumprimento do cache ter ocorrido ou não. Ele também atua como uma salvaguarda no caso de um vetor de ataque do à Integridade dos Dados dos Nós Invasores 806, excluindo imediatamente os dados que eles pretendiam cumprir assim que o cumprimento do cache ocorresse. Portanto, o evento quando as cópias do Mineiro são excluídas do Conjunto de propagação Cache 2112 ocorre após o evento de Cumprimento do Cache. Portanto, um alto valor para o Limite de Exclusão de Peças de Cache 1034 leva a uma garantia adicional de que os Dados em Perigo foram resgatados e ainda ocupam os dispositivos de armazenamento dos Mineradores por mais tempo; removendo, portanto, a oportunidade de outras tarefas produtivas para a Rede BCHAIN 110 fazer uso do espaço. Segue-se que um valor menor para o Limite de Exclusão 1034 aumenta o risco de os Dados em Perigo não terem sido resgatados, às custas do aumento do alívio dos
Petição 870200056145, de 06/05/2020, pág. 190/1737
188/754 recursos de armazenamento.
[472] A Magnitude 1036 do Imposto Setorial atua como um multiplicador para o tamanho do valor da Unidade de Consequência Fiscal 1851 que deve ser imposta ao Nó 786 do Setor 884 relevante. Portanto, um valor mais alto para a Magnitude 1036 leva a uma maior potencial Tributação Tributária a ser imposta nos nós 786 do setor 884, e um valor menor leva a uma menor potencial de penalidade tributária.
[473] A figura 73 mostra como o SCM 984 processa sua entrada e saída modular. Começa com a Estratégia Preferida Atual 914 como a entrada inicial. A Estratégia 914 é descompactada no Estágio 990, o que significa que é extraída em um formato intermediário para disponibilizá-lo para manipulação e processamento pelo módulo pai SCM 984. Portanto, a Composição 992 dos Critérios de Estratégia é gerada no Estágio 990 a partir da Estratégia Preferida Atual 914. Paralelamente, a lógica mostrada na Figura 74 atualiza a Composição dos Critérios de Estratégia 992 para uma nova versão de experimentação de baixo risco da Estratégia 914, que acaba se tornando a saída Implantação da Estratégia 916. Depois da conclusão do processo de atualização ilustrado na Figura 74, o módulo Montagem de Sintaxe da Estratégia (SSA) 1132 repete as informações no formato que é compreensível para os outros módulos que operam o Protocolo BCHAIN 794. Portanto, o SSA 1132 executa o inverso prático do Estágio 990. Portanto, o Implantação da Estratégia 916 é enviado como saída modular de SCM 984 enquanto contém todos os elementos de Composição dos Critérios de Estratégia disponíveis (só três são mostrados para fins ilustrativos: Expiração 1000 da
Petição 870200056145, de 06/05/2020, pág. 191/1737
189/754
Testemunho do Salto 4, Critérios de Dispersão de Salto Paralelo 1002 e Critérios de Redução de Salto Paralelo 1004) . 4 mostra ainda como o Módulo de Criatividade 112 é usado para atualizar a Composição dos Critérios de Estratégia 992 em uma direção que se espera ser mais eficiente e com melhor desempenho, considerando as variáveis do NSS 778 que refletem o estado do ambiente local da Rede BCHAIN 110. No Estágio 1136, a Criatividade recebe o Modo 1138 dos critérios atualmente selecionados da Criação de Estratégia, que é um Modelo Predefinido para gerenciar a criação e variação dinâmicas da estratégia. Esse modelo predefinido é produzido no Gerenciamento de Modelos de Modo Predefinido (PMTM) 1134. A Criatividade 112 processa duas entradas; Os formulários A e B. O formulário A é definido no Estágio 1146 e selecionado no Estágio 1144. Portanto, todos os Critérios da Composição 992 dos Critérios de Estratégia são selecionados para processos individuais como Forma A com Criatividade 112. A Forma B é mostrada na Figura 71 como a interpretação geral do Caos de Campo no Estágio 986 da Interpretação de Campo de Caos (FCI) 918. Portanto após a conclusão do Formulário de Saida AB do processamento da Criatividade 112, é produzido como as novas variações propostas dos Critérios 992 no Estágio 1140. Posteriormente, no Estágio 1142, as novas alterações são confirmadas na Composição dos Critérios de Estratégia 992.
[474] [00] As Figuras da 75 a 79 mostram os principais elementos da Plataforma UBEC 100 e do Protocolo BCHAIN 794 que lidam com auto monitoramento do uso de recursos, eficácia da operação e diagnóstico. A depuração do programa é operada automaticamente pela coleta automática de logs relevantes de
Petição 870200056145, de 06/05/2020, pág. 192/1737
190/754 desempenho e/ou de falha/erro que são processados e enviados para Auto Programação e Auto Inovação (SPSI) 130 e o SPSI Desenvolvimento Indireto (SID) 1190. Portanto, erros de programação e falhas genéricas no A Plataforma 100 da UBEC e a rede 110/Protocolo 794 da BCHAIN são automaticamente encontradas, analisadas e corrigidas.
[475] Na Figura 75, o Usuário UBEC 106 acessa a Plataforma UBEC 100 por meio de reconhecimento biométrico realizado na Interação do Nó do Usuário (UNI) 470. Portanto, uma sessão de usuário autenticado 522 é produzida a partir da qual a Lista de Nós Associados 518 é extraída no Estágio* 1150. A Sessão do Usuário 522 também é usada para acessar a Interface do Usuário Front-End 1148, que leva a uma Seleção de Personalidade Econômica 740. No estágio 1152, o Usuário UBEC 106 seleciona uma Personalidade Econômica 740, referenciada pela Computação e Disponibilidade de Recursos de Rede 1156 do Protocolo BCHAIN 794. No uso prático da Plataforma UBEC 100; o Usuário UBEC 106 seleciona uma Personalidade Econômica 740 na configuração inicial e no login do Aplicativo UBEC 118. Portanto, não é esperado como uso prático para o Usuário UBEC 106 selecionar manualmente uma Personalidade Econômica 740 toda vez que o Usuário 106 iniciar uma nova sessão com a Interface de Usuário Front-End 1148. No estágio 1154; a CNRA faz referência à Seleção de Personalidade Econômica 740 da Plataforma UBEC 100 como uma metodologia para medir qualquer recurso disponível excedente de um Nó 786 que está associado ao Usuário UBEC 106 através da Lista de Nós Associados 518 .
[476] Na Figura 76, o Estágio 1 54 continua invocando o
Petição 870200056145, de 06/05/2020, pág. 193/1737
191/754
CNRA 1156, que concede referência ao módulo Seleção de Incentivo Econômico (EIS) 1232. 0 EIS 1232 pode recomendar que o Nó 786 execute Outro Trabalho de Nó 158 ou uma sessão de trabalho de Diagnóstico de Envio de Log (DLS) 1160. Portanto, o Nó 786 que está operando esta instância do Protocolo BCHAIN 794 procura de maneira egoísta trabalho com o melhor retorno possível sobre investimento via EIS 1232, o que leva a um equilíbrio dentro da Rede BCHAIN 110 de oferta e demanda de micro serviços técnicos automatizados. Portanto, no Estágio 1162, a execução local do EIS 1232 em um Nó 786 pode fazer com que o Nó 786 se torne um Nó de Diagnóstico autoimposto através da execução do DLS 1160. Posteriormente, no Estágio 1164, o Nó 786 se declara um Nó de Diagnóstico para o Diagnóstico do Localizador de Nó 844 do Metachain 834. Devido ao status inicialmente declarado do Nó 786 desde a execução do Estágio 1164, o Nó 786 é marcado como não confirmado até que outros Nós 786 possam corroborar que está executando a função declarada. Isso é feito de acordo com o princípio vigente do Protocolo BCHAIN 794, que é obter colaboração eficiente por meio de instâncias sincronizadas, mas separadas, de critérios algorítmicos. Portanto, existe uma colaboração harmoniosa sem confiança na Rede BCHAIN 110. As atualizações feitas no Local do Nó de Diagnóstico 844 do Metachain 834 são enviadas para o Módulo de Interface Customchain (CIM) 2470 para serem extraídas e comprometidas com o Metachain 834 real .
[477] Na Figura 77 os Estágios 1162 e 1164, que foram contextual!zados na Figura 76, continue o fluxo lógico para o Estágio 1166. No Estágio 1166; devido à declaração do Nó 786 no
Petição 870200056145, de 06/05/2020, pág. 194/1737
192/754
Metachain 834 sobre ser um Nó de Diagnóstico, outros Nódulos 786 do mesmo Setor 884 enviam Registros de Diagnóstico por meio do Envio do CCF Implicado (JICS) 4194 e Recepção do CCF Aceita (JACR) 4208. Posteriormente, no Estágio 1168, os Registros de Diagnóstico são validados para autenticidade pelo Nó de Diagnóstico autodeclarado. Isso atenua os ataques de spam e abuso. Posteriormente, no Estágio 1170, as Unidades de Registro 1182 marcadas com um Token Oficial do Sistema 1184 são enviadas ao Desenvolvimento Indireto SPSI (SID) 1190 por meio do Console de Gerenciamento (MC) 1186 e (I2CM) 1188, que funcionam como Appchains 836 na Plataforma UBEC 100 e são hospedados pela Rede BCHAIN 110. O envio das Unidades de Registro 1182 para o SID 1190 permite que os programadores do Usuário UBEC 106 guiem melhor a programação da Auto Programação e Inovação (SPSI) 130 por métodos indiretos. O Token Oficial do Sistema 1184 é uma prova criptográfica de que a Unidade de Registro 1182 se origina de um Appchain Oficial como LOM 132, LIZARD 120, MPG 114 etc. Os Appchains 836 são marcados como Oficiais se contribuírem com a funcionalidade principal para a Plataforma UBEC 110. A similitude são os principais programas de um sistema operacional que não podem ser removidos, como um Explorador de Arquivos, os Drivers de componentes básicos, como RAM, uma janela de Terminal para executar instruções etc. No Estágio 1172, as mesmas Unidades de Registro 1182 enviadas no Estágio 1170 são enviadas ao LOM 132 por meio do Mecanismo de Pesquisa Automatizado (ARM) 134 que se conecta à Appchain 836 de Auto Programação e Inovação (SPSI) 130. As Unidades de Registro 1182 permitem ao SPSI 130 se programar melhor e outros Appchains 836 dentro da Plataforma UBEC 100.
Petição 870200056145, de 06/05/2020, pág. 195/1737
193/754
Posteriormente, no Estágio 1174, o Processamento de Reivindicação de Pagamento Comercial é enviado ao WPCP 1258 para resgatar os recursos que o Nó 786 colocou em Unidades Watt.
[478]Na figura 78 são detalhados os detalhes referentes à lógica originalmente mostrada na figura 77. Outros Nós BCHAIN no Mesmo Setor 1176 processam o módulo Coleta de Registro de Diagnóstico (DLC) 1178 para registrar os Registros relevantes que devem ser enviados aos locais relevantes por meio do Envio de Registro de Diagnóstico (DLS) 1160. Estes Registros do DLC 1179 são encaminhados para o JICS 4194, que envia um CCF 2318 sem o CCR 2308 acompanhante para uma instância do JACR 4208 que invocou o DLS 1160 no Nó de Diagnóstico auto declarado. Devido à declaração do Nó 786 de ser um Nó de Diagnóstico no Local de Nó de Diagnóstico 844 do Metachain 834, tornou explicita sua jurisdição e, portanto, deve implicitamente aceitar tais pacotes CCF 2318 enviados pelo JICS 4194 devido à jurisdição eleita. Portanto, o LIZARD 120 operando como um Appchain 836 dentro da Plataforma UBEC 100 pode monitorar e justificar pacotes CCF 2318 sem um CCR 2308 que o acompanha. Caso contrário, isso possa parecer spam, pois não há permissão explicita do nó para receber os CCFs 2318, apenas implicados devido à sua função auto imposta explicita. Portanto, a tecnologia de rastreamento de jurisdição 120 da LIZARD é implementada nas camadas mais baixas do tráfego da Rede BCHAIN 110. O Estágio 1168 valida os registros para autenticidade através do módulo de Validação de Registro de Diagnóstico (DLV) 1180. Portanto, validar registros como autênticos ou inautênticos enquanto agregá-los para envio à origem correta é o trabalho principal de um Nó de Diagnóstico.
Petição 870200056145, de 06/05/2020, pág. 196/1737
194/754
Uma Unidade de Registro de Diagnóstico 1182 é produzida pelo DLV 1180 se for autêntico. Um Token Oficial do Sistema 1184 é incluído, se for aplicável.
[479] A Figura 79 ilustra ainda o fluxo lógico descrito na Figura 77. No Estágio 1170, a Unidade de Registro de Diagnóstico 1182 é processada pelo Console de Gerenciamento (MC) 1186 e (I2CM) 1188. Essas Unidades de Registro 1182 são então revisadas pelos Usuários UBEC 106 como Programadores para ser um ponto de referência na programação indireta e na habilitação do SPSI 130. A Unidade de Registro de Diagnóstico 1182, juntamente com um Token Oficial do Sistema 1184 potencialmente aplicável, são enviados ao SPSI 130 para manutenção e correção direta e automatizada dos Appchains Oficiais 836.
[480] [00] As Figuras 80 - 83 mostram a Seleção de Incentivo Econômico (EIS) 1232 e o Processamento de Reivindicação de Pagamento de Trabalho (WPCP) 1258.
[481] Na figura 80; o EIS 1232 atua como um mecanismo de arbitragem de suprimento/demanda para a Rede BCHAIN 110. Os nós 78 6 que procuram trabalho com nó ativo 1254 invocam o EIS 1232 através do estágio 1234 para selecionar o melhor tipo de trabalho disponível com maior probabilidade de obter o melhor retorno para o nó 786 em investimento. Posteriormente, o Estágio 1236 analisa variáveis locais e remotas relativas ao Metachain
834 para entender as tendências atuais da demanda de fornecimento. Portanto, é chamado o módulo de Arbitragem da Demanda de Suprimento (SDA) 1238. A SDA 1238 faz referência ao Metachain 834 para criar uma representação lógica dos vetores de oferta/demanda na Rede BCHAIN 110. Portanto, pode-se
Petição 870200056145, de 06/05/2020, pág. 197/1737
195/754 posteriormente estimar quais categorias de Trabalho de Nó são as mais rentáveis. Dai SDA 1238 submete Oferta de Demanda de Composição 1240 para representar as conclusões dos seus cálculos. O Estágio 1236 leva ao Estágio 1242, que verifica se há uma quantidade excedente de recursos de computação e rede disponíveis, em conformidade com a Personalidade Econômica 740 selecionada. O estágio 1242 verifica a disponibilidade de recursos, invocando a CNRA (11) . A designação de Personalidade Econômica 740 foi projetada na Interface da Plataforma UBEC (UPI) 728. Se a Condição 1246 Não, recursos não disponíveis ocorrer, o Estágio 1250 será chamado, finalizando a operação do EIS 1232 e enviando uma saída nula. Se a Condição 1248 Sim, recursos disponíveis ocorrer, o EIS 1232 chamará a Seleção de Trabalho do Nó (NJS) 1252. O NJS 1252 faz referência à Composição da Demanda de Fornecimento 1240 e à disponibilidade dos recursos do Nó 786 na seleção de uma tarefa adequadamente lucrativa.
[482] A Figura 81 mostra a transição entre a Seleção de Incentivo Econômico (EIS) 1232 e o Processamento de Reclamação de Pagamento de Trabalho (WPCP) 1258. Depois que o trabalho do Ativo 1254 ou Passivo 1256 concluir, se faz uma reivindicação de receita ao WPCP 1258 que verifica e processa o pagamento à Economia de Watt 862 do Metachain 834. O Trabalho no Nó Passivo 1256 é um trabalho implicado pelo Protocolo BCHAIN 794 devido às necessidades da Rede 220. Por exemplo, o roteamento CCR 2308 ou CCF 2318 é uma necessidade da Rede 220, onde fica a cargo de um Nó 786 no lugar e no momento certo para atender a solicitações legítimas feitas de acordo com o Protocolo 794. O Trabalho do Nó Ativo 1254 é realizado por motivos egoístas do Nó 786 em nome de
Petição 870200056145, de 06/05/2020, pág. 198/1737
196/754 seu proprietário, o Usuário UBEC 106, enquanto está de acordo com a Personalidade Econômica 740 selecionada. Portanto, o EIS 1232 chama apenas o Trabalho em Nó Ativo 1254 através da Seleção de Trabalho em Nó 1252, enquanto o Trabalho em Nó Passivo 1256 está implicado devido à conformidade do Protocolo 794. Após a Conclusão do Trabalho Ativo 1254 ou Passivo 1256, o Estágio 1260 de recebimento de uma Reivindicação de Trabalho Concluído é processado. Posteriormente, o Estágio 1262 identifica o tipo de Trabalho que está sendo reivindicado como concluído. O Estágio 1264 executa uma verificação para ver se o tipo de Trabalho identificado está definido na Política de Código Estático (SHP) 488. O estágio 1264 garante que o Tipo de Trabalho do Nó seja legítimo e oficialmente reconhecido pelo Protocolo BCHAIN 794. Também é mostrado nos recursos e referências que usa o WPCP 1258; Pagamentos de Trabalho Pendentes e Validados 871 do Appchain 836, Economia de Watt 8 62 do Metachain 834 e Anúncio de Novo Bloco 2480 de Trabalho Resolvido 2480 do Módulo de Interface Customchain (CIM) 2470. Os Pagamentos de Trabalhos Pendentes e Validados 871 é um meio de alcançar a confirmação de terceiros de trabalhos reais realizados nos Tipos de Trabalho Oficiais 1264 na Rede BCHAIN 110 na Política de Código Estático (SHP) 488. A Economia de Watt 862 rastreia a alocação de Unidades Watt para os Nós 786. O Anúncio do Novo Bloco de Trabalho Resolvido 2480 é o segundo meio de chamar uma rotina de processamento no WPCP 1258, enquanto o Estágio 1260 é o primeiro meio de chamar uma rotina de processamento.
[483] A Figura 82 mostra mais detalhes sobre a rotina lógica no WPCP 1258. Se o tipo de trabalho identificado
Petição 870200056145, de 06/05/2020, pág. 199/1737
197/754 processado no estágio 1264 não for definido no SHP 488, a reivindicação de trabalho será rejeitada e a execução do módulo do WPCP 1258 será encerrada. Se a condição Yes 98 ocorrer para o estágio 1264; a Reivindicação de Trabalho é validada por meio de processamento de Prova Corroborativa de Terceiros por meio da Verificação de Prova Corroborativa (CPV) 1266 no Estágio 1270. Portanto, a Categoria de Trabalho Confirmada 1280 verificada no Estágio 1264 é enviada à CPV 1266 para processamento. Depois da conclusão do processamento do CPV 1266, um resultado de 1274 Não Verificados leva ao Estágio 1268, que rejeita a Reivindicação de Trabalho e finaliza a execução do módulo. Um resultado do Verificado 1272 leva a um dos dois Estágios potenciais 1276 e 1278 sendo executados. Se o WPCP 1258 foi invocado pela conclusão de um Nó 786 do Trabalho Passivo 1256 ou Ativo 1254; então é invocado o Estágio 1276, que envia o pagamento de trabalho validado para pagamentos de trabalho pendentes e ainda validados 871 do Metachain 834. No entanto, se o WPCP 1258 foi invocado por um Anúncio de Novo Bloco Resolvido 2480, o Estágio 1278 é executado, que envia pagamentos pendentes 1284 à Economia de Watt 862 .
[484] A Figura 83 mostra mais detalhes sobre a rotina lógica no WPCP 1258. Após a invocação modular do WPCP 1258 via Anúncio de Bloco Novo de Trabalho Resolvido 2480, no estágio 1282 é executado. O estágio 1282 recupera os pagamentos de trabalho pendentes e ainda validados 871 do Appchain 836 associado ao bloco recém-resolvido. Portanto, os Pagamentos Pendentes 1284 são produzidos como saída. O Estágio 1282 leva ao Estágio 1286, que verifica independentemente a Prova Corroborativa de Terceiros
Petição 870200056145, de 06/05/2020, pág. 200/1737
198/754
1292 incluída, extraída dos Pagamentos Pendentes 1284, através do CPV 1266. Portanto, o CPV 1266 verifica se o Metachain 834 tem confirmação de Pagamentos Pendentes 1284 ou Prova Corroborativa de Terceiros 1292 com a Categoria de Trabalho Confirmada 1280.
[485] [00] As Figuras 84 - 169 demonstram a funcionalidade de Gerenciamento de Integridade de Dados (DIM) 1204 que opera com três ramos principais: Sincronização e Reconciliação de Customchain (CSR) 1208, Nós de Mineração que Fornecem a Propagação de Cache (MNSCS) 1850 e Reconstrução de Dados de Falha de Mineração (MFDR) 1212. O objetivo do DIM 1024 é manter e garantir a integridade dos dados do Appchains 836 de forma descentralizada e sincronização para nós que executaram operações enquanto estavam offline. A finalidade da legitimidade dos dados é considerada de uma maneira computacionalmente cara a Crítica Profunda de Decisão do cliente (DC2) 1506, que emula qual deveria ser o comportamento esperado do protocolo. Portanto, os nós poder ser confiáveis ou não. O módulo de Criação de Imposto Setorial (STC) 1872 cria uma Unidade de Consequência Fiscal (TCU) 1852 que enumera as consequências fiscais positivas ou negativas que devem ser decretadas no tempo variável em que ocorre o cumprimento do cache. Os fatores que definem a composição de um TCU 1852 incluem a quantidade de nós no setor, magnitude da Demanda do Setor, magnitude dos Fundos de Emergência do Setor etc. Execução Fiscal do Setor (STE) 924 Avalia o desempenho do Cumprimento de Cache dos nós no setor. Após a eventual conquista do status de Cumprimento de cache no setor, este módulo aplica o código tributário conforme estipulado na Unidade de Consequência
Petição 870200056145, de 06/05/2020, pág. 201/1737
199/754
Fiscal (TCU) 1852. 0 TCU 1852 contém um plano de imposto programado gue é promulgado no momento do cumprimento do cache. A Unidade de Consequência Tributária (TCU) 1852 enumera a possível isenção de imposto ou penalidade tributária a ser decretada considerando qualquer quantidade potencial de tempo necessário para que os nós do respectivo setor realizem coletivamente o Cumprimento em Cache do conteúdo específico entregue pelo recém-extraído quadra. Anúncio de Imposto Setorial (STA) 1864 Transmite a Unidade de Consequência Fiscal (TCU) 1852 para todos os nós aplicáveis na jurisdição setorial relevante. As referências de nós são feitas principalmente via Associação de Localização no Metachain. A Recepção de Impostos Setoriais (STR) 1904 possui uma lógica processada em um Nó BCHAIN 786 individual que decide o momento mais eficaz para cumprir a Unidade de Consequência Fiscal (TCU) 1852. Essa decisão é tomada sem colaboração com outros nós do mesmo setor que receberam o mesmo TCU 1852. Portanto, o nó estima os seus próprios fatores, como Personalidade Econômica, disponibilidade e margem de lucro de trabalho alternativo, recursos locais disponíveis etc. A lógica é executada com o entendimento de que, se todos os nós procrastinarem a adoção do cache anunciado, todos os nós desse setor terão que pagar igualmente o preço na forma de impostos que são submetidos ao setor de emergência Fundos do Metachain 834. Portanto, os nós de um setor precisam colaborar sem comunicação explícita sobre esse tópico, o que evoca um cenário semelhante ao dilema do prisioneiro. A Reconstrução de Dados de Falha de Mineração (MFDR) 1212 é utilizada no evento raro de mineradores de um Appchain/Microchain perderem a integridade
Petição 870200056145, de 06/05/2020, pág. 202/1737
200/754 parcial dos dados que retêm, os nós que armazenaram esses dados em cache podem enviá-los de volta aos Mineiros após a verificação desses dados.
[486] A Figura 84 fornece lógica do DIM 1204 que consiste e interage com o Algoritmo de Seleção de Mineração (MSA) 2484, Economia de Watts 862, Localização do Cache da Appchain 848, Novo Trabalho Resolvido 1206, Processamento de Declarações de Pagamento de Trabalho (WPCP) 1258, Varredura de Integridade de Dados (DIS) 1960, Processamento de Refúgio de Dados (DRP) 1984, Relatório de Conteúdo em Perigo 1982, Sincronização e Reconciliação Customchain (CSR)/ Processamento de Fusão do Appchain (AMP) 1740, Seleção de Incentivo Econômico (EIS), NDS de Mineração (MNSCS) 1850 e Reconstrução de Dados de Falha de Mineração (MFDR) 1212. O MNSCS 1850 fornece uma propagação inicial do cache de dados de um bloco recém-extraído. Isso garante uma distribuição adequada da integridade da retenção de dados e uma distribuição geográfica eficiente desses dados. O MNSCS 1850 consiste na Criação de Impostos Setoriais (STC) 1872 Aplicação de Impostos Setoriais (STE) 1924 Anúncio de Impostos Setoriais (STA) 1864 Unidade de Consequências fiscais (TCU) 1852.
[487] A Figura 85 fornece lógica adicional para componentes do DIM 1204 e suas interações, que incluem o Tempo de retenção do cache de mineração 1020, a Ração de pagamento de mineração até o cache 1032, o Algoritmo de seleção de cache (CSA) 2350, o Algoritmo de seleção de mineração (MSA) 2484, a Lógica de Pagamento Appchain 1214, Unidades de Trabalho BCHAIN 1216.
[488] A Figura 86 fornece lógica dos algoritmos DIM 1204 MSA 2484 e CSA 2350 que trabalham com a Lógica de Pagamento
Petição 870200056145, de 06/05/2020, pág. 203/1737
201/754
Appchain 1214 e seus componentes que incluem os Administradores da Appchain 12120/Pagamento Devido à Infraestrutura 1224, Usuários Appchain 1222/Pagamento Devido à Infraestrutura 1226, Administradores da Appchain definem políticas de pagamento para o Appchain 1228 que recebe entrada dos Administradores do Appchain 1220 e alimenta a Política de pagamento do Appchain 1230. A Política de Pagamento do Appchain fornece entrada para os Administradores do Appchain 1220 e Usuários Appchain 1222, os quais alimentam as Unidades de Trabalho BCHAIN 1216.
[489] Figura 87 A Distribuição de Informações do Nó 1294 demonstra que a Sobreposição de Blocos Fortalece o Consenso de Verificação entre os Nós BCHAIN 1296, 1298, 1300 e 1302. Quando um bloco de Metachain é baixado de outro nó, é verificado que ele é o bloco correto e preciso fazendo referência ao conhecido hash do bloco, que cada nó retém (para todos os blocos da Metachain). Como medida de precaução contra ataques de colisão de hash, os nós legítimos são capazes de chegar a um consenso sobre o conteúdo correto de um bloco de Metachain, por serem redundantes em cópias legítimas. Assim, é preservada a integridade do Metachain.
[490] A Figura 88 expande ainda mais a Distribuição de Informações do Nó 1294, demonstrando um Escopo Completo Disponível para Metachain 1304 e Disponibilidade de Distribuição para Metachain 1306, que destaca a preservação total da zona de retenção obrigatória devido ao protocolo BCHAIN 794 que exige a retenção dos 3 primeiros blocos, tem uma curva de distribuição constantemente completa em todos os setores da Rede BCHAIN e disponibilidade exponencialmente decrescente em relação ao tempo
Petição 870200056145, de 06/05/2020, pág. 204/1737
202/754 decorrido. O módulo Lógica de Retenção Metachain (MRL) 1658 é codificado para selecionar a retenção de blocos Metachain em uma curva de distribuição exponencialmente decrescente. Isso é porque, com o passar do tempo, a probabilidade de que um bloco Metachain seja necessário para uma função de protocolo diminui exponencialmente. Por exemplo, com a Fusão de Appchain 1308, a probabilidade de uma fusão ser processada entre duas versões de um Appchain que foram separadas há três anos é altamente improvável. Portanto, não é economicamente rentável reter muitos blocos antigos e, dai, o MRL 1658 os retém exponencialmente menos em comparação aos blocos mais novos.
[491] Figura 89 A fusão da Appchain 1308 demonstra a Versão A da Appchain consistindo nos blocos 1314, 1320, 1326 e a Versão B da Appchain consistindo nos blocos 1312, 1318 e 1324. O módulo de Sincronização da Versão da Hora do App (AVC) 1328 compara os carimbos de data e hora criptográficos de ambas as versões do Appchain para deduzir qual bloco da Versão A da Appchain está cronologicamente associado a qual bloco da Versão B da Appchain. O Alterkle Merkle Hash 1330 é definido na Figura 90 .
[492] A Figura 90 continua a Fusão Appchain 1308 da Figura 89, com o bloco 1324 e o bloco 132G sendo Fusionados no bloco 1322. O Hash 1330 da Árvore Hash de Merkle é calculado levando em consideração todos os blocos anteriores na Appchain. Portanto, qualquer identidade única de Hash de um bloco, ou a adição ou remoção de um bloco, levaria à Árvore Hash de Merash final a mudar completamente. Portanto, a Árvore Hash de Merash é usada entre os Nós para verificar se eles estão de acordo com o
Petição 870200056145, de 06/05/2020, pág. 205/1737
203/754 conteúdo da Appchain e podem depender das versões um do outro para distribuição logística. Apesar do processo do Processo de Fusão do Appchain levar à inserção potencial de blocos no meio da Appchain, os nós chegarão a um consenso sobre a nova Árvore Hash de Merash, porque eles têm os mesmos critérios para a Prova de Trabalho e Prova de Aceitação de Dilema. A Árvore Hash de Merash A 1336, Árvore Hash de Merash B 1334 e Árvore Hash de Merash AB 1332 são mostradas para os respectivos blocos, juntamente com a Calculadora de Árvore de Merkle (MTC) 1338 e o Núcleo de Criptografia (CC) 768.
[493] A Figura 91 demonstra a Fusão Appchain 1308 entre a Versão A da Appchain 1340 e a Versão B da Appchain 1344, resultando na Fusão da Appchain AB 1342 e na Sincronização de Tempo da Versão Appchain (AVTS) 1328.
[494] A Figura 92 destaca a reconciliação da Versão A do Ecossistema Customchain 1346 e a Versão B da Reconciliação do Ecossistema Customchain 1348 para o Nó BCHAIN A 1350, Nó BCHAIN B 1352, Nó BCHAIN C 1354 e Processamento de Fusão Appchain (AMP) 1740 na nova interpretação do Status Quo do Ecossistema Customchain 1356. Critérios de Protocolo/Algoritmo idênticos levam ao consenso sobre o novo paradigma pós-Fusão. Como cada Nó BCHAIN está executando a versão legítima do Protocolo de Cliente BCHAIN, eles podem chegar a um consenso sobre o processo de Fusão, tendo critérios idênticos. Isso também elimina os Nós BCHAIN que estão executando versões ilegítimas do Protocolo do Cliente, pois seus critérios alternativos levarão a resultados espúrios que serão posteriormente ignorados pela maioria dos nós legítimos.
Petição 870200056145, de 06/05/2020, pág. 206/1737
204/754
[495] A Figura 93 mostra a Versão A do Ecossistema Customchain 1346 e a Versão B do Ecossistema Customchain B 1348. O Ecossistema customchain separado e conflitante devido a reconciliação. Por causa de uma separação geográfica entre grupos de nós, a sincronização entre os dois grupos não foi possível. Portanto, eles realizaram suas transações sem consideração um do outro, para que seus Metachains e seus respectivos Appchains/Microchains já não sejam idênticos. Os Appchains correspondentes de diferentes Ecossistemas Customchain são mostrados através de linhas pontilhadas. Apesar da versão diferente dos ecossistemas, espera-se que existam Appchains que correspondam à identidade, cada versão alegando ser a versão correta. A interpretação do dilema de separação geográfica pelo CDI 1660 é capaz de resolver esse conflito.
[496] A Figura 94 fornece detalhes sobre os Nós BCHAIN A/B/C 1350, 1352, 1354 no que diz respeito à Versão A do Ecossistema Customchain 1346, Versão B do Ecossistema Customchain 1348, Interpretação do Dilema customchain (CDI) 1660, Interpretação Completa do Dilema 1360, Interpretação do Status Quo de Ecossistema Customchain 1358 e Processo de Fusão do Appchain (AMP) 1740. Consenso prévio e extinto de paradigma de pré-Fusão (entre os Nós BCHAIN 1350, 1352, 1354 e sua respectiva Interpretação do Status Quo dos Ecossistemas Customchain 1358) . Cada Nó BCHAIN tinha uma percepção específica do Ecossistema Customchain que foi exposto a ter. Como eles mostraram um dilema legítimo de separação geográfica, são sincronizados na sua reação para considerar a versão atual do ecossistema como extinta até que toda a interpretação do dilema seja processada, o que
Petição 870200056145, de 06/05/2020, pág. 207/1737
205/754 levará ao novo e correto estado do Ecossistema.
[497] A Figura 95 fornece detalhes sobre a Realidade do Manifesto Ecossistêmico Customchain 1362, Dilema Inteiro 1360, Partes 1 -5 1362, 1364, 1366, 1368, 1370, Nó BCHAIN A 1350, Nó BCHAIN B 1352, Nó BCHAIN C 1354 e Interpretação do Dilema Customchain (CDI) 1660. Realidade do Manifesto do Ecossistema Customchain 1362, Interpretação Inteira do Dilema 1360 é uma interpretação do estado complexo real do Ecossistema Customchain observável. Isto é, a interpretação abstrata dos nós BCHAIN via computação refere-se diretamente à manifestação real dos dados em seu escopo observável de percepção. A Interpretação Completa Do Dilema Está Disponível No Campo, Embora Dispersa Em Uma Distribuição Caótica De Peças. Essa interpretação do Dilema é uma representação abstrata do dilema de separação geográfica existente que causou a mineração de duas versões dele Appchain. Apesar do dilema existente estar inteiramente dentro da realidade do ecossistema Customchain, a exposição de um nó individual a ele pode ser gradual. Como um nó não pode receber uma conformação quando recebe toda a interpretação do dilema, ele assume que todo incremento recebido representa a totalidade do dilema. Isso pode levar a um desacordo inicial entre os nós sobre o novo Appchain unificado e, portanto, é a raiz da árvore Merkle, mas eventualmente eles chegarão a um consenso à medida que cada Nó BCHAIN (1350, 1352, 1354) recebe uma exposição consistente de todas as partes que definem todo o conjunto. Dilema. Interpretação Caoticamente Escalonada De Partes Do Dilema Por Nós Da Cadeia. Cada Nó BCHAIN individual (1350, 1352, 1354) é exposto a diferentes aspectos ou 'partes' da interpretação do
Petição 870200056145, de 06/05/2020, pág. 208/1737
206/754 dilema e em diferentes ordens. Portanto, há um periodo de transição do qual existe uma falta de consenso, até que cada nó tenha sido suficientemente exposto à Interpretação Inteira do Dilema.
[498] Figura 95-96 Nós BCHAIN A/B/C 1350/1352/1354, Interpretação do Dilema De Customchain (CDI) e Interpretação Escalonada Do Dilema Do Ecossistema Realidade Existente 1372, 1374, 1376, 1378, 1380. A Interpretação Escalonada leva a Consenso devido a Critérios Sincronizados. Com o passar gradual do tempo, cada nó será necessariamente exposto a mais e mais partes da Interpretação do Dilema. Em cada parte válida que recebe, deve-se assumir que é a última parte e que já está exposta a todo o dilema. No entanto, ele adotará prontamente uma nova peça após a verificação de sua autenticidade. Como cada nó é programado com a mesma versão legitima do Protocolo do Cliente BCHAIN, eles chegarão a um consenso sobre todo o estado da Interpretação do Dilema, conforme mostrado na Parte 1360.
[499] Figura 97 Árvore Hash de Merkle A 1336, Árvore Hash de Merkle B 1334, Diferente 1383, Combinado 1385, Bloco 1382 e Bloco 1384. Ponto de divisão do Appchain (linha pontilhada) é o momento no qual os nós envolvidos com o Appchain se separam fisicamente assim que eles não conseguiram sincronizar com outras adições ao Appchain. Portanto, antes do ponto de divisão, todos os blocos eram idênticos, mas depois do ponto de divisão todos os blocos são diferentes. Para que uma fusão do Appchain ocorra, é necessário que eles tenham sido sincronizados. Mesmo dois Appchains que têm identidades e/ou propósitos idênticos nunca podem se fundir se não tiverem blocos de identidade idênticos.
Petição 870200056145, de 06/05/2020, pág. 209/1737
207/754
[500] As Figuras da 98 para a 100 fornecem mais detalhes sobre todo o processo, desde o contato inicial entre duas versões diferentes do mesmo Appchain 1386 até o Processo de Fusão de Appchain (AMP) 1740, incluindo a Interpretação Inteira do Dilema 1360 .
[501] A Figura 101 fornece a lógica para o Processo de Verificação Conflitante do Appchain (CAV) 1438 no Estágio 1436, contato inicial entre duas versões diferentes do mesmo Appchain 836. No estágio 1440, a população de nós da Versão A (para LNT 2620) atendeu à Diversidade de Mineração e o Estágio 1442, a população de nós da Versão B (do LNT 2620) atendeu ao requisito de diversidade de mineração? No Estágio 1444, Recupera o Requisito de Diversidade de Mineração de ambos os Appchains (que estão em conflito de compatibilidade de dados).
[502] A Figura 102 continua a lógica da Figura 101 do CAV 1438 e destaca os principais componentes: Versão Master/Afinidade Escrava (VMSA) 1478, Apelação de Reconciliação da Appchain (ARA) 1452, Requisito de Diversidade de Mineração 1448 e Cache de Nó de Mineração 1456. O VMSA 1478 determina qual versão do Appchain é o original e qual se ramificou do original. O ARA 1452 é um procedimento para aprovar manualmente uma fusão do Appchain pelos administradores do Appchain devido à incapacidade do Protocolo BCHAIN de processar automaticamente uma fusão. 0 Requisito de Diversidade de Mineração 1448 define a variação na composição do nó de mineração necessária para que uma fusão da Appchain seja inicialmente aprovada.
[503] As Figuras 103 e 104 fornecem mais detalhes sobre o CAV 1438 com detalhes sobre o uso de LMNV 1492, VMSA 1478, ARA
Petição 870200056145, de 06/05/2020, pág. 210/1737
208/754
1452, Cache do Nó de Mineração 1456, etc.
[504] A Figura 105 continua com o CAV 1438, Requisito de Diversidade de Mineração 1446/1448 e aprova o feed Appchain 1476 para a Versão Master/Afinidade Escrava (VMSA) 1478. Carga do pagamento de verificação (VPB) 1494 nos Adjudicados de Verificação de Nó de Mineração Legitima (LMNV) 1492, de acordo com à Política Appchain definida, cujos nós devem arcar com o ônus de pagar pela Incorporação da Appchain. Devido à complexidade relativa e ao uso intenso de recursos necessários para executar uma fusão bem-sucedida da Appchain, a logística para atribuir encargos de pagamento se torna crucial para administrar as ligações e indivíduos uiyai.
[505] A Figura 106 fornece detalhes adicionais sobre o CAV 1438 e o LMNV 1492, onde o módulo Crítica Profunda de Decisão do Cliente (DC2) 1506 recebe blocos relevantes e cumpridos do Metachain para emular a resposta correta do Protocolo BCHAIN às situações ambientais anteriores de um nó alvo. Ao analisar os fatores do ambiente da Rede BCHAIN, este módulo pode perceber a resposta mais correta e plausível (em situações de ambiguidade) a esses fatores. Portanto, as ações anteriores de um nó podem ser verificadas para verificar se estão de acordo com a definição legítima do Protocolo BCHAIN ou se o firmware/software do nó está comprometido intencionalmente ou não. Portanto, elementos de confiança do nó podem ser estabelecidos, o que permite procedimentos subsequentes na Rede BCHAIN, como a Fusão Appchain. O módulo para Descarregar a Retenção de Metachain (MRD) 1560 interage com outros Nós na Rede BCHAIN para recuperar o conteúdo dos blocos Metachain direcionados. O Ônus do Pagamento de
Petição 870200056145, de 06/05/2020, pág. 211/1737
209/754
Verificação (VPB) 1494 decide, de acordo com a Política Appchain definida, quais nós devemos arcar com o ônus de pagar pela fusão Appchain. Devido à complexidade relativa e ao uso intenso de recursos necessários para executar uma fusão bem-sucedida da Appchain, a logística para atribuir carga de pagamento se torna crucial para administrar organizações e indivíduos.
[506] A Figura 107 fornece detalhes sobre o processamento adicional no LMNV 1492, Políticas de Appchain 1502, Appchain 1504, bloco 1382 e bloco 1384 e AVTS 1328.
[507] A Figura 108 continua da Figura 107 nos detalhes no LMNV 1492, onde o Metachain Sem Dados Principais 1498 mostra a Sequência de Solicitação de Bloco (retângulo pontilhado com o Bloco 12, Bloco 13 e Bloco 14), onde referências relevantes do bloco Metachain são selecionadas para serem baixadas via Retenção de Metachain Download (MRD) 1560. Os blocos são selecionados em lotes que retrocedem no tempo, com o ponto de partida sendo o ponto de divisão do Appchain. O módulo MRD 15 60 interage com outros nós na rede BCHAIN para recuperar o conteúdo dos blocos Metachain direcionados. A saída do Metachain Com Core Data 1500 é alimentada no DC2 1506.
[508] As Figuras 109 a 112 fornecem os detalhes sobre DC2 1506 da Política Appchain 1502 e o Nó de Mineração Selecionado 1464 para Hypervisor de Emulação com Interface Virtual 1554, Protocolo BCHAIN; (BP) 794 e Hypervisor Interface 1556. O Hypervisor de Emulação 1522 é uma interface que envia instruções especializadas à CPU para permitir que um ambiente virtualmente isolado execute módulos do Protocolo BCHAIN 794 sem comprometer ou afetar a iteração principal do Protocolo BCHAIN 794 que é
Petição 870200056145, de 06/05/2020, pág. 212/1737
210/754 operando no nó. A Replicação de Módulo Inteiro de Interface do Hipervisor 1556. O Hypervisor de Emulação 1522 carrega todo o módulo configurado para o Protocolo BCHAIN, para que uma virtualização holistica da resposta correta do Protocolo BCHAIN 794 possa ser medida. O módulo DC2 1506 recebe blocos relevantes e cumpridos do Metachain para emular a resposta correta do Protocolo BCHAIN às antigas situações ambientais de um nó alvo. Ao analisar os fatores do ambiente da rede BCHAIN, este módulo pode perceber a resposta mais correta e plausível (em situações de ambiguidade) a esses fatores. Portanto, as ações anteriores de um nó podem ser verificadas para verificar se estão de acordo com a definição legítima do Protocolo BCHAIN 794, ou se o firmware/software do nó está comprometido intencionalmente ou não. Portanto, elementos de confiança do nó podem ser estabelecidos, o que permite procedimentos subsequentes na rede BCHAIN, como a Fusão Appchain.
[509] As Figuras 113 - 115 fornecem detalhes sobre o Download de Retenção de Metachain (MRD) 1560. A Avaliação Econômica do Valor Justo (EFVA) 1578 Recebe informações de entrada relativas às variáveis de oferta/demanda de vários escopos de módulos. Portanto, um valor justo de mercado exato de uma tarefa específica pode ser medido, o que precede informar outros nós sobre seus processos decisórios de trabalho. A figura 115 também inicia a sequência de busca de informações com 1586, 1590 e 1594.
[510] As Figuras 116 - 118 continuam a sequência de busca de informações da Figura 115 com 1594 seguida por 1602, 1606, 1608, 1612, 1620, 1626, 1632, seguida por MRD 1560.
Petição 870200056145, de 06/05/2020, pág. 213/1737
211/754
[511] A Figura 119 fornece uma visão geral do mapa 1638 do nó da sequência de busca de informações com o Nó BCHAIN (BN) 1640 (o nó que originou a solicitação de recompensa do bloco), BN 1642 (um nó que negou a oferta de localização do nó), BN 1644 (Um nó que aceitou a recompensa, mas não possuía o bloco solicitado), BN1646 (Um nó que aceitou a recompensa e possuía o bloco solicitado) e Crescimento de transferência exponencial da recompensa do bloco 1566. Como uma recompensa em bloco, é transmitida pela Rede BCHAIN, sua exposição e interação com outros nós aumentam exponencialmente devido a um único nó ter vários vizinhos.
[512] A Figura 120 fornece ilustração do Token de Autorização Econômica de Baixo Preço (EAT) 1648, Ilustração Do Token De Autorização Econômica De Alto Preço (EAT) 1650. A pesquisa finita acaba eventualmente apesar do mecanismo de crescimento exponencial e de taxa 1642. Para evitar que uma recompensa em bloco sobrecarregue permanentemente um sistema devido ao crescimento perpétuo e exponencial, o apelo de uma Recompensa em Bloco diminui a cada salto devido à Recompensa em Bloco ser compartilhada com cada nó que o transmite. Portanto, a Recompensa em Bloco finalmente deixa de ser repassada por ser uma perspectiva econômica não atraente, com nós propostos para interagir com a Recompensa em Bloco. Portanto, a taxa proposta anexada à Recompensa em Bloco por meio de um Token de Autorização Econômica (EAT) 1648 faz toda a diferença quanto à magnitude do alcance que a Recompensa em Bloco tem na Rede BCHAIN e, portanto, as perspectivas do bloco Metachain desejado encontrado. Lógica de retenção do Metachain (MRL) 1658 este módulo executa o
Petição 870200056145, de 06/05/2020, pág. 214/1737
212/754 processo de tomada de decisão para o qual o Metachain bloqueia o nó que deve reter. Portanto, este módulo tenta manter a variedade mais apropriada de blocos do Metachain para aumentar a probabilidade de o nó poder atender com êxito uma solicitação de Download de Retenção de Metachain (MRD) 1560. O cumprimento eficiente de tais solicitações leva a uma melhor visão econômica do nó que atende à solicitação e a uma execução mais eficiente dos processos do Protocolo BCHAIN (Como uma Fusão da Appchain). Eventos de Fusão Appchain e magnitudes variáveis da densidade Metachian 1652. Magnitudes variáveis da densidade de Metachain devido a Várias Ocorrências de Fusão 1654. O módulo Lógica de Retenção Metachain (MRL) 1658 será executado em áreas que variam em graus de Ocorrência de Fusão da Appchain. Portanto, em áreas onde existe uma alta magnitude de fusões do Appchain, o MRL 1658 instruirá o nó a reter mais Metachain na Zona de Retenção Aleatória. Eventos de Fusão do Appchain 1656. Quando um Appchain é fusionado com êxito, as informações rudimentares relativas ao evento são transmitidas para a rede para fins de rastreamento estatístico. Essas estatísticas, por sua vez, informam módulos como o LMR 1658 sobre seu processo de tomada de decisão.
[513] As Figuras 121 - 124 mostram detalhes sobre a Interpretação do Dilema da Customchain (CDI) 1660. Na Figura 122, a Detecção de Atividade de Mineração/Cache (MCAD) 1688 determina quais mineradores e caches contribuíram para o Appchain de destino na versão escrava do Metachain depois do Ponto de Divisão do Metachain. Também na Figura 122 o módulo de Descoberta de Divisão Customchain (CSD) 1692 calcula o ponto no tempo em que duas versões de um Customchain começaram a diferir na composição.
Petição 870200056145, de 06/05/2020, pág. 215/1737
213/754
[514] As Figuras 125 a 127 fornecem detalhes sobre a sequência de comprovação da prova de dilema 1698.
[515] As Figuras 128 a 129 fornecem detalhes sobre o Processo de Fusão do Appchain (AMP) 1740.
[516] A Figura 130 detalha o Processo de Desembalar em Bloco (BUP) 1766.
[517] A Figura 131 detalha o Consenso do Escopo do Bloco Retrospectivo (RBSC) 1784.
[518] As Figuras 132 a 136 fornecem detalhes sobre o Processo de Fusão do Appchain (AMP) 1740.
[519] A Figura 133 fornece detalhes sobre o Fluxo de Fusão do Mempool 1770. O vetor de Quantidade de Dados 1816 ilustra a quantidade de conteúdo que um bloco específico contribui e plota no Fluxo de Fusão do Mempool 1770. O Vetor de Intervalo de Dados 1818 ilustra a magnitude do escopo que os dados que um determinado bloco atinge. A Medida Linear do Tempo 1820 mede o tempo de maneira consistente e linear, contra o qual é plotado o conteúdo de vários blocos.
[520] A Figura 134 fornece detalhes sobre o Fluxo do Mempool com Escopo e Fusão. A Lógica de Mineração Clássica para Blocos Retrospectivos é a mesma lógica de mineração usada pelo CIM 2470 para minerar novos blocos típicos é usada para minerar retrospectivamente blocos inseridos no meio da Appchain/Microchain. A principal diferença é que os novos blocos típicos exigem apenas Prova de Trabalho, enquanto a mineração retrospectiva exige Prova de Trabalho e Prova de Dilema. Consenso sobre Novas Alocações de Blocos Retrospectivos. Devido à execução de todos os nós participantes, a mesma especificação legítima do
Petição 870200056145, de 06/05/2020, pág. 216/1737
214/754
Protocolo BCHAIN, os seus critérios para onde traçar linhas de escopo referentes ao Fluxo de Mempool Incorporado levam a um consenso eventual na mineração retrospectiva de tais blocos, o que leva a um eventual consenso sobre a composição do Appchain/Microchain, apesar da operação de procedimentos complexos, como a Fusão do Appchain.
[521] A Figura 135 fornece o Appchain 1828 fusionado com a Versão A Master do Appchain 1812 e a Versão B Escrava do Appchain 1814.
[522] A Figura 136 demonstra o módulo Fusão de Rastreamento de Eventos (MET) 1836 que anexa a Fusão de Tags de Eventos 1830 (que incluem Tempo de Fusão 1832, Afinidade Master/Escrava 1480 e Registro de Nós Envoltos 1834) a uma Fusão de Registro de Eventos 1838 que acompanha cada bloco único que já passou por uma fusão da Appchain. Isso permite iterações futuras de operações avançadas de análise e segurança relacionadas a ataques de injeção de informações da Customchain.
[523] A Figura 137 detalha os Nós de mineração Fornecendo a Propagação de Cache (MNCS) 1850. O módulo de Criação de Impostos Setoriais (STC) 1872 cria uma Unidade de Consequências Fiscais (TCU) 1852 que enumera as consequências fiscais positivas ou negativas que devem ser decretadas no tempo variável quando o Cumprimento do cache ocorrer. Os fatores que definem a composição de um TCU 1852 incluem a quantidade de nós no setor, magnitude da Demanda do Setor, magnitude dos Fundos de Emergência do Setor etc. A Aplicação Fiscal do Setor (STE) 1924 avalia o desempenho do Cumprimento de Cache dos nós no setor. Com a eventual conquista do status de Cumprimento de Cache no
Petição 870200056145, de 06/05/2020, pág. 217/1737
215/754 setor, este módulo aplica o código tributário conforme estipulado no TCU 1852. 0 Anúncio de Imposto do Setor (STA) 1864 transmite a TCU 1852 a todos os nós aplicáveis dentro da jurisdição relevante do setor. As referências de nós são feitas principalmente através da Associação da Localização no Metachain.
[524] A Figura 138 descreve a aplicação 1866 da Unidade de Consequência fiscal (TCU) que mostra os Nós BCHAIN 786, os Nós de Mineração BCHAIN 1870, o TCU 1852 no setor J21 884 e o setor KL4 884. Consenso Inicial de Consequências Fiscais entre os mineradores de um setor especifico. A criação, consenso e aplicação de Consequências Tributárias ocorrem independentemente em qualquer setor. Os Nós de Mineração BCHAIN (BMNs) de um determinado setor chegam primeiro a um consenso sobre a definição da Unidade de Consequência Tributária (TCU) antes de transmitir o conteúdo para os nós do mesmo setor por meio do Anúncio de Imposto Setorial (STA).
[525] A Figura 139 descreve os detalhes da criação de impostos setoriais (STC) 1872. O Módulo de Emulação Variável (VEM) 1880 cria variáveis uniformes confiáveis com qualquer entrada dinâmica. O Protocolo de Consenso de Nó de Mineração (MNCP) 1884, juntamente com Variáveis Brutas Pré-TCU 1882, permite que os mineradores cheguem a um consenso sobre Variáveis Brutas Pré-TCU, que produz uma versão final exatamente unificada do TCU entre todos os mineradores do setor especifico.
[526] A Figura 140 conclui o STC 1872 e detalha a Unidade de Consequência Tributária (TCU) 1852. O TCU 1852 contém um Plano de Cronograma de Impostos que é promulgado no momento do preenchimento do cache. A Unidade de Consequência Tributária
Petição 870200056145, de 06/05/2020, pág. 218/1737
216/754 (TCU) 1852 enumera a possível isenção de imposto ou penalidade tributária a ser decretada considerando qualquer quantidade potencial de tempo necessário para que os nós do respectivo setor realizem coletivamente o Cumprimento em Cache do conteúdo entregue a partir do bloco recém-extraído.
[527] A Figura 141 detalha o Anúncio de Imposto Setorial (STA) 1900 com a Submissão Jurídica Implícita CCF (JICS) 4194.
[528] As Figuras 142 e 143 fornecem detalhes sobre a Recepção de Impostos Setoriais (STR) 1904. STR 1904 é uma lógica que é processada dentro de um Nó BCHAIN individual que decide o momento mais eficaz para cumprir a Unidade de Consequência Fiscal (TCU) 1852 é tomada uma decisão sem colaboração com outros nós do mesmo setor que receberam o mesmo TCU 1852. Portanto, o nó estima seus próprios fatores, como Personalidade Econômica 740, disponibilidade e margem de lucro de trabalho alternativo, recursos locais disponíveis etc. A lógica é executada com o entendimento de que, se todos os nós procrastinarem a adoção do cache anunciado, então todos os nós desse setor terão que pagar igualmente o preço na forma de impostos que são submetidos aos Fundos do Setor de Emergência do Metachain. Portanto, os nós de um setor precisam colaborar sem comunicação explícita sobre esse tópico, o que evoca um cenário semelhante ao dilema do prisioneiro (é um exemplo padrão de um jogo analisado na teoria dos jogos que mostra por que dois indivíduos completamente racionais podem não cooperar, mesmo que parece que é do seu interesse fazê-lo). A conformidade de cache de nó (NCC) 2110 é a execução lógica que envolve um nó que adota e retém os dados que foram especificados pelos mineradores do setor mediante uma
Petição 870200056145, de 06/05/2020, pág. 219/1737
217/754 chamada do Anúncio de Imposto Setorial (STA) 1900. Cumprimento do Cache é o momento instantâneo em que uma quantidade suficiente de adoção de cache foi realizada pelos nós em um setor. O Cumprimento do Cache ocorre apenas depois da adoção reivindicada e verificada desse cache. Conformidade de Cache é o ato de um nó que cumpre os comandos dos mineradores do setor em cache dos dados destacados. Para neutralizar um nó invasor que está em conformidade com o pedido, os nós são testados de forma deterministica e aleatória para verificar se estão realmente retendo os dados ou se estão fingindo ter os dados.
[529] As Figuras 144 e 145 descrevem a Execução Fiscal do Setor (STE) 1924. A Figura 145 1938 mostra o STA 1940, Conformidade do Nó A 1942, Conformidade do Nó B 1944, Conformidade do Nó C 1946, Prazo Limite Atingido 1954, Sem Tentativas de Conformidade em 1950, Cumprimento de Cache Atingido 1948 com a seta Diminuição nos Impostos (Redução de Impostos) subindo e seta para Aumentar Impostos (penalização de impostos) descendo. No ponto em que 1948 e 1946 se encontram, o atendimento ao cache termina com a demanda de conformidade dos nós. Depois que o Cumprimento do Cache ocorre, a dinâmica da conformidade com o cache muda, pois não há mais um fator de penalidade referente à quando ou se cumprir. No entanto, os nós ainda podem se voluntariar para adotar esses caches disponíveis devido à sua Personalidade Econômica 740 definida e/ou à percepção da lucratividade da adoção. Tempo 1956, Limite de tempo atingido em 1954, Adoção de cache (número de nós) 1958, Cumprimento de cache alcançado em 1948.
[530] A Figura 146 detalha a Verificação de Integridade
Petição 870200056145, de 06/05/2020, pág. 220/1737
218/754 de Dados (DIS) 1960. O conteúdo do Relatório de Perigos de 1982 é um relatório abrangente que enumera a identidade dos dados que afirma estarem em risco de perder permanentemente a integridade, com referências externas a evidências que indicam esse perigo, uma realidade preocupante para o sistema em geral. Tais referências externas são feitas através do Metachain para que partes alternativas possam verificar tais alegações de perigos à integridade dos dados.
[531] As Figuras 147-150 mostram detalhes do Processamento de Refúgios de Dados (DRP) 1984.
[532] A Figura 148 Descoberta de Refúgio no Setor (SRD) 2002 localiza um setor que tem a melhor probabilidade de adotar dados com um Conteúdo no Relatório de Perigo com precisão e urgência. Os setores com fundos de emergência mais altos do setor têm maior probabilidade de adotar dados em refúgio. Além disso, a proximidade com os nós deste localizador é considerada para evitar um caminho de migração desnecessariamente longo para obter segurança na integridade dos dados. O Localizador de Nós de Mineração do Setor (SMNL) 2004 procura um nó de mineração apropriado no setor de destino, selecionado no SRD 2002.
[533] Figura 149 Gerador de Aplicativos para Refúgio de Dados (DRAG) 2010 cria um contêiner de informações que enumera as informações listadas no Conteúdo do Relatório de Perigos original, bem como informações de identificação e pagamento do Nó Localizador.
[534]Figura 150 Aplicação de Refúgio Setorial (SRA)
2014 é um minerador verificado no setor de destino que considera situação enumerada no Aplicação de Refúgio de
Dados
2006.
Petição 870200056145, de 06/05/2020, pág. 221/1737
219/754
Portanto, ele invoca sua própria instância do Verificação da Integridade de Dados (DIS) 1960 para verificação independente da integridade dos dados cenário. As Figuras 151-155 detalham a lógica da Solicitação de Refúgio Setorial (SRA) 2014, iniciada na Figura 150.
[535] As Figuras 156-158 descrevem o processo do Auto Nó (Mineiro) com os detalhes do Provedor de Cache de Nó 2080, incluindo o Registro de Conformidade de Cache de Nó (NCCR) 2230, Registro de Eventos de Conformidade 2250, Cumprimento de Cache API 2108, Processamento de Cache API 2108, Exclusão do Conjunto de Cache de Propagação 2180, Conjunto de Cache de Propagação 2112, etc.
[536] A Figura 159 continua com o processo Conformidade de Cache de Nó (NCC) 2110, iniciado na Figura 158. Resposta de Cache de Nó (NCR) 2080 na Figura 160 está em conformidade com a Solicitação de Verificação de Cache de Nó (NCV) 2152 do Nó de Verificação 2150, respondendo ao Hash de Desafio solicitado.
[537] A Figura 160 descreve a Verificação de Cache do Nó (NCV) 2152 no Nó de verificação 2150 utilizando a Verificação
On-line via Metachain (OVCM) 2160, Desafio de verificação de
cache 2170, Desafio Hash 2172
[538] A Figura 161 continua e conclui o Processo de
Verificação de Cache de (NCV) 2152 com o Relatório como
Confirmado 2178 para o log de Eventos de Conformidade 2250 no NCP 2080 e o nó automático (minerador) 2078 ou termina a execução modular sem relatar o evento de conformidade como confirmado 2176.
[539] A Figura 162 descreve o processo de Exclusão do
Petição 870200056145, de 06/05/2020, pág. 222/1737
220/754
Conjunto de Cache de Propagação (SCPD) 2180, que inicia com Ocorreu o Processamento de Cache 2182 e termina com Excluir a entrada da parte de cache do Conjunto de Cache de Propagação 2192 se for bem-sucedido ou Finalize a execução do módulo com o modular nulo 2184 se for malsucedido.
[540] A Figura 163 descreve os detalhes e as interações do Provedor de Cache do Nó (NCP) 2080 e a Verificação de Cumprimento do Cache do Nó (NCFC) 2200.
[541] A Figura 164 fornece detalhes sobre a Resposta de Cache de Nó (NCR) 2210 no seu processo interno com Conteúdo de Cache de Nó Primário (PNCC) 1218, Hash de Desafio 2172, NCV 2152, Sequência de desafio 2224, etc.
[542] A Figura 165 e a Figura 166 fornecem detalhes sobre a Gravação de Conformidade de Cache de Nós (NCCR) 2230.
[543] A Figura 167 fornece os detalhes no Registro de Eventos de Conformidade 2250.
[544] A Figura 168 fornece detalhes sobre uma Gravação de Conformidade de Cache de Nó (NCCR) 2230. Uma Sequência de Desafio 2224 é uma Sequência de Desafio 2272 de oito bytes de comprimento, inicio da parte 2264, Valor Aleatório X 2266, Valor Aleatório X 2266, Final da Parte 2268.
[545] A Figura 169 mostra os Padrões de Migração de Dados 2280 com os estados desejados entre a integridade dos dados e a veiculação de conteúdo e a Rede BCHAIN, por meio do Protocolo BCHAIN, tenta maximizar constantemente o nível de integridade dos dados e configuração ideal para entrega rápida e consistente de conteúdo. Isso é feito considerando os recursos finitos disponíveis entre os nós da Rede BCHAIN. Área de Propagação
Petição 870200056145, de 06/05/2020, pág. 223/1737
221/754
Inicial de Conteúdo 2282, Área de Conteúdo de Integridade 2284 representa Locais Ótimos de Integridade: 0 Protocolo BCHAIN possui uma abordagem binária para a integridade da retenção de dados. Todos os dados são tratados como de grande importância e nenhum dado pode ser perdido, a menos que um evento de expiração intencional de dados tenha sido executado. Portanto, o protocolo garante a redundância dos dados, apesar da distribuição caótica e do tempo de atividade de nós individuais. Com a Área de Propagação Inicial de Conteúdo 2282, os nós de mineração confirmados (nós que minaram com êxito um bloco) impõem políticas tributárias que motivam os nós de um setor a armazenar em cache o conteúdo de um bloco minado recentemente. Área de alta demanda de conteúdo 2286 é um Local Ótimo para Serviço - espera-se que a demanda de conteúdo culmine em bolsos específicos da rede. Portanto, o Algoritmo de Seleção de Cache (CSA) permitirá a hospedagem de conteúdo em cache em áreas mais próximas da demanda por esse conteúdo. Isso leva a um alívio geral para a rede, pois os pacotes de roteamento (CCR/CCF) precisam viajar muito menos para realizar a mesma transferência de dados. Isso também leva a menor latência e maiores velocidades de transferência para os consumidores de informações.
[546] [00] As Figuras 170 - 358 fornecem detalhes sobre a Lógica de Roteamento 774, que é o núcleo principal da Rede 110 de BCHAIN (Harmonização de Conexão de Base Anexando Nós Integrados), incluindo os vários algoritmos que utiliza. A essência do BCHAIN é rotear pacotes de maneira eficiente sobre uma malha de maneira descentralizada. Os nós assumem diferentes funções em uma distribuição caótica de recursos, alguns acabam
Petição 870200056145, de 06/05/2020, pág. 224/1737
222/754 atendendo a Solicitações de Reivindicação de Conteúdo (CCRs) 2308, alguns recebem Cumprimentos de Reivindicação de Conteúdo (CCFs) 2318. A lógica de roteamento principal ocorre em torno da criação, referência e atualização do PBHP 2322. Um aspecto muito exclusivo da lógica de roteamento é encontrado na Descoberta de Rota da Seção Otimizada (OSRD) 3430. As Figuras 291-294, são um sistema de armazenamento em cache inteligente que detecta automaticamente rotas eficientes em toda a topologia do nó sem gastar recursos significativos. Dois aspectos principais do módulo são a Detecção de Nó de Borda (END) 3672, Figuras 317-323 são o Algoritmo Boomerang 3830 começando na Figura 329. A sequência bumerangue é um método eficiente para determinar o ângulo e a área da passagem de pacotes, aproveitando a distribuição caótica dos nós. Portanto, rotas de pacotes eficientes tornam-se autoconscientes, o que leva a estradas otimizadas de informações ao longo da topologia do nó.
[547] Figura 170 Lógica de Roteamento (RL) 774 recebe entrada do Armazenamento Customchain (CS) 832 (que consiste em Metachain 834, Appchain 836 e Microchain 838) por meio do Módulo de Reconhecimento Customchain (CRM) 3060 que se conecta a Customchains (que pode ser Appchains ou Microchains) registrados anteriormente pelo nó. Portanto, o nó tem acesso criptográfico para ler, gravar e/ou habilidades administrativas para essa função. Este módulo informa o restante do Protocolo BCHAIN quando uma atualização é detectada na seção de um Appchain no Metachain ou no emulador de Metachain do Microchain.
[548] A Figura 171 continua com a Figura 170 no processo de RL 774. Entrega de Reivindicação de Conteúdo (CCD) 3260 ao
Petição 870200056145, de 06/05/2020, pág. 225/1737
223/754 receber uma Solicitação de Reivindicação de Conteúdo (CCR) 2308 válida, este módulo produz e envia o Cumprimento de Solicitação de Reivindicação de Conteúdo (CCF) 2318 relevante para atender o pedido.
[549]A Figura 172 continua com a Figura 171 no processo da RL 774. Renderização de Reivindicação de Conteúdo (CCR) 3300 ao receber um CCF 2318 validado, este módulo processa o conteúdo da solicitação ao usuário por meio de um front-end como a Interface da Plataforma UBEC.
[550] A Figura 173 detalha o conteúdo do CCR 2308 que consiste na Reivindicação de Origem 2310, Localização de Conteúdo Perceptível Plausibilidade 2312, Prova Criptográfica de Titularidade 2314, Conjunto Variável de Trilha (TVS) 2320, Trilha de Salto Proposto da Linha de Base (PBHP) 2322, Identificação Exclusiva do Nó 4304 e Tipo de alvo 2300. O Tipo de Alvo 2300 consiste no Alvo Imediato 2302 é o nó que é imediatamente procurado na sequência de salto seguinte da trilha da jornada, Alvos Subsequentes 2304, que é uma lista dinâmica e crescente de nós que são percebidos como o melhor caminho de curto prazo para facilitar uma jornada eficiente em direção à Meta Final 2306 e Meta Final, que é o nó de destino pretendido que espera conteúdo de entrega ou entrega de conteúdo em si. A Origem da Reivindicação 2310 inclui um bloco de informações assinado de maneira criptográfica que indica os detalhes de identificação do nó de origem que forneceu a reivindicação de conteúdo. Conteúdo percebido de Localização Plausível 2312 é um conjunto de variáveis dinamicamente variáveis que indicam os principais aspectos do roteamento de salto de nó. A Prova de Titularidade
Petição 870200056145, de 06/05/2020, pág. 226/1737
224/754
Criptográfica 2314 contém um bloco de informações assinado de maneira criptográfica que indica que o nó de origem tem acesso a uma chave válida que pode acessar o Appchain/Microchain especificado. A essa chave pode ser atribuída permissão de leitura, permissões de gravação e/ou recursos administrativos. Essas chaves também podem ser de maneira criptográfica revogadas pelos administradores do Appchain/Microchain no nível por usuário ou grupo.
[551] A Figura 174 detalha o conteúdo do CCF 2318, que consiste em Originação de Conteúdo 2326, Plausibilidade de Entrega de Conteúdo Percebida 2313 (mostrada como 2312 na Figura 174), Parte criptografada do Conteúdo 2314, Conjunto de Trilhas Variáveis (TVS) 2320, Trilha de Salto de Linha de Base Proposto (PBHP) 2322, Identificação Exclusiva do Nó 4304 e Tipo de Destino 2300. A Origem do Conteúdo 2326 inclui um bloco de informações assinado de maneira criptográfica que indica os detalhes de identificação do nó de origem que forneceu o cumprimento do conteúdo. A percepção de plausibilidade de entrega de conteúdo 2313 (mostrada como 2312 na Figura 174) é um conjunto de variáveis dinamicamente variáveis que indicam os aspectos principais do roteamento de salto de nó. Parte Criptografada do Conteúdo 2314 tem as informações solicitadas, as quais são preenchidas por um nó de cache, retornando uma Parte relevante das informações ao requerente dessas informações. O tamanho da peça é otimizado ativamente pelo Implantação da Estratégia para encontrar o tamanho ideal da peça para o desempenho geral da Rede.
[552] A Figura 175 fornece detalhes sobre o Porta de Comunicações (CG) 2348, seus componentes de Lógica de Integração
Petição 870200056145, de 06/05/2020, pág. 227/1737
225/754 de Nó (NIL) 2380, Aceitação do Trabalho em Cache (CWA) 742 e seu funcionamento com Pontos Finais da API 792, Pontos Finais da API 792, Saturação da Largura de Banda de Comunicação 2346, Saida CCR CCF 2308, e PBHP 2322.
[553] As Figura 176 - 180 descrevem principalmente o Algoritmo de Seleção de Cache (CSA) 2350. O módulo Avaliação de Saturação Recente (CRSE) 2351 da Customchain verifica se o Appchain 2318 do CCF de entrada foi recentemente testemunhado no Histórico Recente de Saltos (RHH) 2354.
[554] As Figuras 181 - 184 definem o processo na Lógica de Interação com os Nós (NIL) 2380, que é a lógica principal para interagir e trocar informações com outros nós. Essa é a camada mais próxima da Interface de Hardware 762, dentro do Protocolo BCHAIN. A Interface de Hardware 762 consiste no Microchip de Antena Celular 2402, que possui conectividade 5G/4G/LTE/3G 2404 e GSM / CDMA 2406. Também possui Microchip de Antena sem Fio 2408 com WIFI (por exemplo, Espec. 802.11 ac) 2410 e Bluetooth (Versão 4.2) Recursos do 2412.
[555] As figuras 185 - 190 descrevem o processo para o Mecanismo de Ponte de Rede Herdado (LNBM) 2410 e a Lógica de Interação com os Nós (NIL) 2380. Conclui com a Pesquisa Estatística de Nós (NSS) 778.
[556] As Figuras 191 - 193 descrevem o processo no Módulo de Interface Customchain (CIM) 2470 que interage com o Gerenciamento de Integridade de Dados (DIM) 1204, Portas de Comunicações 2348, Processador de Transmissão (BP) 2704. O Envio de CCF Juridicamente Vinculado (JICF) 4134 tem CCFs 2318 são enviados para um nó sem um CCR 2308 associado devido à
Petição 870200056145, de 06/05/2020, pág. 228/1737
226/754 responsabilidade implícita do nó de receber esse CCF 2318. 0 Processador de Transmissão (BP) 2704 é um estágio intermediário entre a lógica de roteamento de saltos e a Porta de Comunicação (CG) 2348, este módulo de maneira criptográfica assina as transações efetuadas, bem como as solicita por ordem de chegada, até que os níveis de congestionamento de hardware permitam a transmissão de mais transações.
[557] As Figuras 194 -198 descrevem o Algoritmo de Seleção de Mineração (MSA) 2484. Interage com CG 2348, CS 832, Gerenciamento de Rastreamento de Tendências de Tráfego do Appchain (ATTTM) 2500 na Figura 194. O CIM 2470 contém funções rudimentares que facilitam a mineração de Customchains.
[558] As Figuras 199 - 203 fornecem detalhes sobre o Anúncio de Novo Conteúdo (NCA) 2544. Submissão CCF Implicada (JICF) 4134 é o local em que o 2318 do CCF é enviado a um nó sem uma CCR 2308 associada devido à responsabilidade implícita desse nó de receber uma CCF 2318.
[559] As Figuras 204 - 206 mostram detalhes sobre o Processamento de Armazenamento de Nó (NSP) 2590. O Levantamento Estatístico de Nó (NSS) 778 fornece entrada para o NSS Pool de Variáveis (NVP) 4140. O NVP 4140 é onde os nós dos mesmos setores anunciam sua percepção de Pesquisa Estatística de Nós (NSS) 778 Variáveis entre si para construir consenso sobre as características do setor. Portanto, as variáveis locais e remotas do NSS 778 são agrupadas para criar uma média composta conhecida como NVCI. Esse composto é usado para manter um consenso sobre o escopo e a definição desse setor e, portanto, onde estão seus limites. As informações do nó recebidas por meio da Recepção CCF
Petição 870200056145, de 06/05/2020, pág. 229/1737
227/754
Aceita (JACR) 4208 e NVP 4140 são enviadas ao NSP 2390, em que as variáveis NSS são descompactadas dos nós remotos e a instância local do NSS 2592. O Rastreamento de Nó Local (LNT) 2620 armazena informações sobre 2018/014874 atualmente alocados na vizinhança local, conforme definido pelo escopo da Pesquisa Estatística de Nós (NSS) 778. As Figuras 207 - 209 mostram detalhes sobre o Gerador de Salto de Linha de Base Proposto (PBHG) 2640. O Suplemento de Conscientização de Nó local (LNR) 2642 substitui os nós que estão dentro do escopo de salto do LNT por nós que comprovadamente fornecem uma via de salto inicial confiável. A Meta Final 2306 é o nó de destino pretendido que está esperando o conteúdo da entrega ou está entregando o próprio conteúdo. O Alvo Imediato 2302 é o nó que é procurado imediatamente na próxima sequência de saltos do caminho da jornada. A Meta Subsequente 2304 é uma lista dinâmica e crescente de nós que são percebidos como o melhor caminho de curto prazo para facilitar uma jornada eficiente em direção ao objetivo final 2306. As Metas Finais alternativas 2652 são nós propostos que oferecem funcionalidade semelhante à Meta Final 2306. Dessa forma, uma transportadora o nó pode alternar facilmente para uma Metal Final Alternativo, caso a Meta Final original 2306 esteja inacessível. A Troca de Estabilidade do Intercâmbio (NSE) 2301 (não identificado na Figura 208) substitui os nós considerados não confiáveis por nós que estão em ambientes estáveis e confiáveis.
[560] A Figura 210 a Figura 212 mostra processos relacionados à Detecção de Rota Mais Curta (SRD) 2660.
[561] As Figuras 213 - 215 mostram detalhes da
Transmissão de Informações na Fila (QIB) 2700. O Processamento
Petição 870200056145, de 06/05/2020, pág. 230/1737
228/754 de Eventos de Cruzamento de Setor (SCEP) 3360 desativa um Suite Variável de Trilha (TVS) 2320 completa em um CCR 2308 ou CCF 2318 transferindo-se para um novo setor e depois comissiona um novo TVS 2320 para a jornada seguinte do pacote. A Melhor Percepção de Salto (BHP) 2720 fornece a lógica principal para o avanço de um CCR 2308 ou CCF 2318 para seus alvos imediatos e subsequentes para sua jornada em direção ao sua Meta Final 2306. O Rastreamento de Nó Local (LNT) 2620 armazena informações sobre os nós atualmente alocados no vizinhança local, conforme definido pelo escopo da Pesquisa Estatística dos Nós (NSS) 778.
[562] As Figuras 216 - 218 mostram detalhes do Processador de Transmissão (BP) 2704, que é um estágio intermediário entre a lógica de roteamento de saltos e a Porta de Comunicação (CG) 2348, este módulo assina de maneira criptográfica transações de saída e as ordena em um primeiro contato a ser servido até que os níveis de congestionamento de hardware permitam a transmissão de mais transações. O Histórico de Salto Recente (RHH) 2354 é um cache temporário que armazena informações de cabeçalho CCR 2308 e CCF 2318 para que vários algoritmos possam incorporar as implicações dessas entradas em sua lógica. O Módulo de Gerenciamento de Histórico de Saltos Recentes (RHHMM) 2702 é onde os CCRs de saída 2308 e os CCFs 2318 são registrados no RHH 2354 para facilitar outros algoritmos que se referem a esse cache de informações. Depois que o sistema não considera mais um evento testemunha como 'recente', a entrada é excluída do RHH 2354.
[563] As Figuras - 221 mostram detalhes da Melhor Percepção de Salto (BHP) 2720. Verifique se o Próprio 2722 é o
Petição 870200056145, de 06/05/2020, pág. 231/1737
229/754 estágio crucial no qual um nó reconhecerá que foi feito o alvo pretendido dentro de uma trilha de salto. Recalcule os Destinos Subsequentes 2732, como os próximos dez saltos. A Meta Final 2306 é o nó de destino pretendido que está esperando o conteúdo da entrega ou está entregando o próprio conteúdo. A Meta Imediata 2302 é o nó que é procurado imediatamente na próxima sequência de saltos da trilha da jornada. As Metas Subsequentes 2304 são uma lista crescente e reduzida de nós que são percebidos como o melhor caminho de curto prazo para facilitar uma jornada eficiente em direção à Meta Final 2306.
[564] As Figuras 222 - 223 mostram detalhes do Avanço Subsequente da Meta (STA) 2740. Como o CCR 2308 ou o CCF 2318 é processado através da lógica de roteamento, este módulo interpreta o campo Destinos Subsequentes 2304 para produzir a próxima Meta Imediata 2302. Este módulo verifica se algumas das Metas Subsequentes 2304 estão atualmente disponíveis para uma transmissão imediata e direta de informações, mesmo que isso não fosse esperado pelo PBHP 2322. Isso significa que se movimentos caóticos de nós proporcionam uma potencial micro otimização na sequência (um atalho), então este módulo irá detectá-lo e capturá-lo alterando A Meta Imediata 2302 declarada. As Metas Subsequentes 2304 são uma lista crescente e reduzida de nós que são percebidos como o melhor caminho de curto prazo para facilitar uma jornada eficiente em direção à Meta Final 2306. O LNT 2620 armazena informações sobre os nós atualmente alocados na vizinhança local, conforme definido pelo escopo de Pesquisa Estatística do Nó (NSS) 778.
[565] As figuras 224 - 228 mostram detalhes do Cálculo
Petição 870200056145, de 06/05/2020, pág. 232/1737
230/754 da Estratégia de Salto (HSC) 2770.
[566] As Figuras 229 - 232 mostram detalhes da Extração de Caminho de Linha de Base Proposta (ΡΒΗΡΕ) 2820.
[567] Figuras 233 - 235 mostram detalhes da Trilha de Recálculo (RP) 2880. A Plausibilidade de Localização de Conteúdo Percebida 2312 fornece entrada para as Metas Finais Alternativas 2652, que propõe nós que oferecem funcionalidade semelhante à Meta Final 2306. Dessa forma, um nó transportador pode 14874 alternar facilmente para uma Meta Final Alternativa 2306, caso a Meta Final original 2306 esteja inacessível. A Descoberta Alternativa de Meta Final (AFTD) 2646 procura destinos que sejam similares em função e geografia à Meta Final de Destino.
[568] As Figuras 236 - 240 mostram detalhes da Lógica de Salto Paralelo (PHL) 2922. Começa com a Meta Final 2306 e termina com nenhuma Trilha de Salto Paralelo para Iniciar 2948 ou Interface de Hardware 762.
[569] As Figuras 241 - 244 mostram detalhes da Iniciação de Salto Paralelo (PHI) 2960. O Suplemento de Conscientização de Nó Local (LNR) 2642 substitui os nós que estão dentro do escopo de salto do Rastreamento de Nó Local (LNT) 2620 por nós que comprovadamente fornecem uma trilha de salto inicial confiável. O LNT 2620 armazena informações sobre os nós atualmente alocados na vizinhança local, conforme definido pelo escopo da Pesquisa Estatística de Nó (NSS) . A Troca de Estabilidade dos Nós (NSE) 2982 substitui os nós considerados não confiáveis por nós que estão em ambientes estáveis/confiáveis.
[570] As Figura 245 - 247 mostram detalhes da Redução da Trilha de Salto Paralelo Excessivo (OPHPR) 3000.
Petição 870200056145, de 06/05/2020, pág. 233/1737
231/754
[571] As Figuras 248 - 251 mostram detalhes do Gerador de Reivindicações de Conteúdo (CCG) 3050.
[572] A Figura 252 mostra detalhes do Módulo de Reconhecimento customchain (CRM) 3060. As Atualizações em Tempo Real 3062 contêm atualizações em tempo real do Metachain à medida que o armazenamento em cadeia local é atualizado pelo CIM, todas as atualizações do Appchain são enviadas ao CRM em tempo real para que os CCRs apropriados possam ser gerados. A Detecção de Recuperação da Appchain Devida (DARD) detecta diferenças pendentes entre as Atualizações do Metachain Appchain atualizadas em tempo real e as versões conhecidas localmente dos Appchains. Dessa forma, se um Appchain for atualizado, os carimbos de data/hora diferentes instruirão este módulo a destacar que um CCR 2308 deve ser enviado para buscar essas informações.
[573] Figuras 253 y 254 mostram detalhes do Gerador de Direitos Criptográficos (CEG) 3080.
[574] As Figuras 255 - 256 mostram detalhes da
Descoberta de Conexão de Nó excluído (ENCD) 3100.
[575] As Figuras 256-258 mostram detalhes da Melhor Seleção de Nó (BNS) 3120. Resultados Potenciais de Nós de Destino (PDNR) 3058 é uma lista temporária que é armazenada em cache pelo nó para considerar os melhores nós de destino possíveis.
[576] As Figuras 259 - 261 mostram detalhes da
Associação de Localização 840, Roteamento de Setor Otimizado 858 e Localização de Cache de Appchain 848, todos dentro do Metachain.
[577] As Figuras 262 - 264 mostram detalhes da Seleção Preliminar de Metas (PTS) 3170 que descobre eficientemente nós
Petição 870200056145, de 06/05/2020, pág. 234/1737
232/754 que atendem aos critérios do Gerador de reivindicação de conteúdo (CCG) 3050 usando dados de descoberta de nó otimizados que são fornecidos pelo Metachain. Começa com o Nó de Origem (próprio) 2582 e termina com o Nó de Destino Potencial 3196.
[578] As Figuras 265 - 267 mostram detalhes do Consenso do Desvio de Microchain (MBC) 3200. Ele pode ter três possíveis partidas, incluindo: Minerador Autoimposto da Appchain 3211 (não rotulado na Figura 265), Nós de Cache do Appchain 3210 ou Nós do Consumidor Appchain 3212.
[579] As figuras 268 e 269 mostram detalhes da Verificação de Derivação da Microchain (MBC) 3230. Começa com Pedido de Metachain e/ou a Informação Appchain 3228 e termina com a Devolução dos Pontos de Acesso às Informações do Metachain com a versão emulada por microchip 3228. A Política Codificada Estática (SHP) 488 fornece critérios codificados no protocolo BCHAIN. Esse critério é estático, em oposição aos critérios habituais da estratégia dinâmica, porque esse critério é usado para definir a própria estratégia. Portanto, se o mecanismo usado para produzir estratégias em si se basear em estratégias, esperase que o sistema acabe entrando em um estado extremo que possui funcionalidade e eficácia limitadas e/ou anormais. O Emulador Metachain 880 é um emulador de Metachain para transferência de informações ativadas por Microchain - A Microchain é uma combinação localizada e fusionada do Metachain e um Appchain. Portanto, o acesso de um algoritmo ao Metachain é substituído pelo acesso ao Emulador do Metachain, quando o Appchain solicitado é um Microchain. A implementação do Microchain é perfeita e transparente para o usuário final, é apenas uma rotina
Petição 870200056145, de 06/05/2020, pág. 235/1737
233/754 de protocolo que otimiza a eficiência no consumo de recursos.
[580] As Figuras 270 - 276 mostram detalhes da Solicitação de Reivindicação de Conteúdo (CCR) 2308, Entrega de Reivindicação de Conteúdo (CCD) 3260, Cumprimento de Reivindicação de Conteúdo (CCF) 2318 (rotulado como Solicitação de Reivindicação de Conteúdo na Figura 274), Plausibilidade Percebida de Entrega de Conteúdo 2312 (rotulado como Plausibilidade de Localização de Conteúdo Percebido na Figura 274), Conjunto de Trilhas Variáveis (TVS) 2320 e Processamento de Reversão de Autorização Econômica (EARP) 3290. Começa com o CCR 2308 e termina com a Informação de Transmissão (QIB) 2700.
[581] A Figura 277 mostra detalhes do Processamento de Reversão de Autorização Econômica (EARP) 3290 que contém Reversão da Trilha Deduzido Logicamente (LDPR) 3292. O LDPR 3292 recebe o PBHP 2322 original que foi pré-congelado pelo remetente do CCR 2308. A Trilha é então invertida para indicar qual escopo de uma trilha o remetente CCR 2308 pré-congelou para uma viagem de retorno. A Trilha Invertida pode não ser uma imagem invertida da Trilha Original devido à complexidade no layout do nó. É semelhante a estradas de sentido único que indicam que você não pode voltar pela trilha de onde veio.
[582] As figuras 278 - 282 mostram detalhes do Cumprimento de Reivindicação de Conteúdo 2318 (desabilitado na Figura 278 como Solicitação de Reivindicação de Conteúdo), Renderização de Reivindicação de Conteúdo (CCR) 3330. Começa com o CCF 2318 e termina com o Download de conteúdo 3318 na Interface da Plataforma UBEC (UPI) 728. O CCR 3330 representa o estágio final da jornada 2318 do CCF e conclui o cumprimento da
Petição 870200056145, de 06/05/2020, pág. 236/1737
234/754 solicitação de conteúdo original (feita de forma explicita ou implícita). Portanto, a última instância do Processo de Desmantelamento do TVS (TDP) 3402 desta jornada do CCF 2318 é chamada para retornar resultados estatísticos e recompensar o trabalho realizado pelos nós na trilha de salto. A Verificação do de conteúdo Hashsum (CHC) 3302 valida que a parte do conteúdo transferido ou armazenado não foi corrompida durante o trânsito, verificando sua saída de hashsum em comparação com o hashsum prégerado fornecido. O Cache de Conteúdo de Lançamento Escalado (SRCC) 810 possui partes de conteúdo que são armazenadas e mantidas até que uma quantidade satisfatória delas tenha sido coletada (conforme indicado nas Instruções de Decodificação de Conteúdo). Em seguida, são compilados e lançados como Conteúdo baixado para a Interface de Plataforma UBEC 728.
[583] As figuras 283 e 285 mostram detalhes do Processamento de Eventos de Cruzamento de Setor (SCEP) 3360, que inclui o Conjunto de Trilhas Variáveis (TVS) 2320, o Processo de Criação de TVS (TCP) 3380, o Processo de Desativação de TVS (TDP) 3402. 0 TCP 3380 cria e chama um nova matriz de variáveis para preencher um novo Conjunto de Trilhas Variáveis (TVS) 2320. Isso inclui uma nova interpretação da Implantação da Estratégia da Adaptação Dinâmica da Estratégia (DSA) 772 e um Registro em Branco 3282. A única variável reutilizada a partir do antigo TVS é o Token de Autorização Econômica (EAT) 994. O TDP 3402 é um Conjunto de Trilhas Variáveis (TVS) 2320 que deve ser substituído por um novo é processado para fins de coleta de inteligência derivada de dados. Este 8 014874 permite que um pagamento da Unidade de Trabalho BCHAIN (BWU) 1216 seja processado em todos
Petição 870200056145, de 06/05/2020, pág. 237/1737
235/754 os nós que participaram da transferência do CCR 2308 ou CCF 2318, conforme indicado no Registro de Salto 3282. As informações de desempenho são coletadas da Implantação de Estratégia 916 para ser armazenado no Rastreamento Desempenho de Estratégia (SPT) 920 .
[584] As Figuras 286 - 290 mostram detalhes do Processo de Criação de TVS (TCP) 3380 e Processo de Desativação de TVS (TDP) 3402. O TVS 2320 é um conjunto de variáveis que são dinamicamente alteradas e referenciadas como um CCR 2308 ou CCF 2318 à medida que atravessa um setor. O Mecanismo de Liquidação de Trabalho (WSM) 3980 fornece pagamento pelo trabalho realizado pelos nós, autorizados e enviados à seção Economia de infraestrutura do Metachain 834. O Registro de Salto 3282 é uma lista de maneira criptográfica segura de nós que participaram da transferência de uma CCR 2308 ou CCF 2318 em um setor específico. Como um nó deve existir exatamente em dois setores a qualquer momento, o Registro de Salto é redefinido durante o processo de desativação, após o TVS 2320 relevante ser recebido por um nó que não pertence a nenhum dos dois setores definidos na Identificação do Setor de Trilha 3280. O Mecanismo de Preços do Setor (SPM) determina o preço da Unidade de Trabalho BCHAIN (BWU) 1216 da transferência de informações por meio de um salto de nó para um setor específico, por informações referenciadas acumuladas na Demanda Setorial 854 do Metachain 834. A Interpretação do Desempenho da Estratégia (SPI) 3420 recebe estratégias implantadas com dados de campo que determinam o desempenho percebido de tais estratégias em diferentes condições ambientais.
Petição 870200056145, de 06/05/2020, pág. 238/1737
236/754
[585] As Figuras 291 - 294 mostram detalhes da Descoberta Otimizada de Rotas do Setor (OSRD) 3430. O Produtor de Ponte de Rota Intersetorial (Inter-SRBP) 3506 conecta uma série de setores através de caminhos intersetoriais eficientes (a sigla na Figura 291 está incorreta como Inter-SRSP). O Produtor de Segmento de Rota intrasetorial (Intra-SRSP) 3460 produz um segmento de rota proposto que visa fornecer um caminho eficiente de entrega de conteúdo de uma extremidade de um setor para outro. A Eleição Da Trilha de rota holistica (WRPE) 3480 propõe rotas intersetoriais eficientes, unindo vários segmentos de rota. O Setor de Segmento de Rota do Setor (SRSR) 3500 é um banco de dados que mantém as rotas executadas pelos Registros de Salto 3282 desativados. Eles são adicionados diretamente quando a instância de um nó desse banco de dados experimenta um evento de desativação do TDP 3402 ou quando nós de outros setores anunciam esse nó sobre a desativação de Registros de Salto 3282 que eles receberam. O Composto do Setor 3450 destaca o Segmento de Rota Intrasetorial (Intra-SRS) 3452 e o Segmento de Rota Intersetorial (Inter-SRS) 3454 e o Setor 884. O Intra-SRS 3452 é capaz de descobrir Trilhas de 4 Saltos Eficientes, que abrangem uma jornada de ponta a ponta em um único setor. Tais descobertas são realizadas pelo módulo Intra-SRSP 3460. O módulo Inter-SRS 3454 encontra pontos eficientes de sobreposição que permitem a conexão de vários segmentos de rota para formar eventualmente rotas de setor otimizadas que são armazenadas e referenciadas na cadeia eta-834.
[586] As Figuras 295 e 297 mostram detalhes do Produtor de Segmentos de Rota Intrasetoriais (ISRSP) 3460. A entrada é
Petição 870200056145, de 06/05/2020, pág. 239/1737
237/754 recebida do TVS 2320 no Registros de Salto 3282 e na identificação do setor de trilhas 3280.
[587] As Figuras 298 e 299 mostram detalhes da eleição da Trilha Rota Holística (WRPE) 3506 que recebe entrada da sincronização de acionador de evento aleatório que parece aleatório (PRETS) 3440 no PRETS invoca a iniciação do módulo 3484 .
[588] As Figuras 300 e 301 mostram detalhes do Produtor de Ponte de Rota Intersetorial (Inter-SRBP) 3506 que une uma série de setores através de vias intersetoriais eficientes. O Retenção de Segmento de Rota do Setor (SRSR) 3500 armazena segmentos de rota que contêm informações sobre a própria Trilha de Caminho Salto, Classificação de Confiabilidade e Orientação da Direção 3520. O módulo Designação da Orientação da Direção da
Rota (RDOD) 3582 calcula a Orientação da Direção 3520 de um
caminho intrasetoi ciai de acordo com é a proximidade relativa à
posição calculada dos nós de borda relevantes.
[589] A Figura 302 mostra a visão geral do
entrelaçamento do setor 3530. Os estágios de entrada/saida do segmento de rota 3534 são níveis preliminares de complexidade da interação do nó indicam que todos os segmentos de rota percorríveis são reversíveis. Esse nível primário de gerenciamento de nós é suficiente devido à presunção de eficiência de salto bidirecional igual. Uma segunda camada de gerenciamento de nós é implementável para otimizar as percepções do algoritmo para considerar as nuances na interação dos nós que levam a que um caminho não seja per feitamente reversível em relação à eficiência. Portanto, a camada principal dos estágios
Petição 870200056145, de 06/05/2020, pág. 240/1737
238/754 de entrada e saida do gerenciamento de nós é sinônimo um do outro. Tendo determinado a direção geral de um segmento de rota por meio da interseção de largura de setor 3532, módulos como o Inter-SRSP podem selecionar os segmentos de rota mais adequados, considerando a trilha de salto no nível do setor. A intersecção da largura do setor 3532 é onde o módulo RDOD 3582 mede a largura na qual dois setores se cruzam. Portanto, os estágios de entrada/saída de um segmento de rota podem ser atribuídos em incrementos a setores específicos.
[590] Portanto, é calculada uma avaliação precisa da direção da trilha, em relação a outros setores. O segmento de rota intrasetorial (Intra-SRS) 3452 e o setor 884 também são mostrados.
[591] A Figura 303 mostra a visualização especificada do entrelaçamento de setor 3531 (não rotulada na Figura 303), onde os nós de borda 3536 são estrategicamente selecionados para atuar como pontos de referência para o cálculo da orientação da direção 3520. A ponte de rota do setor na base de melhor esforço 3454 é onde o interse torial os segmentos são calculados para alcançar a trilha de viagem mais eficiente possível entre dois segmentos de rota intrasetoriais acordados.
[592] A Figura 304 mostra a Lógica de Priorização de Segmento de Rota (RSPL) 3540. A Troca de Confiabilidade/Distância da Rota 1020 é uma variável para definir a zona de eficiência percebida em relação à troca de seleção entre a confiabilidade dos nós selecionados e a distância esperada percorrida. A variável idealmente ajustada para eficiência máxima dependerá de acordo com as variáveis ambientais circundantes contabilizadas
Petição 870200056145, de 06/05/2020, pág. 241/1737
239/754 pelo NSS 778. Condições de pesquisa do banco de dados 3550 (Afinidade do estágio de entrada do setor M2V - ordem descendente, limite de quantidade de X e afinidade do estágio de saída do setor KL4 - ordem descendente, quantidade limite de X) .
[593] As Figuras 305 e 306 mostram a Lógica de Ponte de Segmento de Rota (RSBL) 3560. Processamento de execução com dois setores de conexão ao mesmo tempo 3564 (por exemplo, um segmento de rota do setor M2V e um segmento de rota do setor J21 são processados juntos). O sinalizador de execução 3492 indica que não faz referência a rotas de setor otimizadas.
[594] As Figuras 307 - 309 mostram a Designação da Orientação da Direção da Rota (RDOD) 3582, que recebe entrada do Registro de Salto 3282. A Detecção de Nó de Borda (END) 3672 elege os nós para se tornarem nós de borda para atuar como um ponto de referência no roteamento de setor do Protocolo BCHAIN 794
[595] A Figura 310 mostra a Barreira do Nó de Borda 3576 (número da etiqueta não mostrado na Figura 310) com a Saída Declarada do Nó de Borda 3536, Segmento de Rota Intrasetorial (Intra-SRS) 3452. As Cruzes X (não rotuladas na Figura 310) é onde a interseção da barreira do nó de borda define a orientação.
[596] As Figuras 311 - 316 mostram o Monitoramento de Interseção de Barreira (BIM) 3610. A Pesquisa de Composição de Bordas do Setor (SEMS) 3660 mede a exposição que um Nó de Borda tem a vários setores vizinhos.
[597] A Figura 317 mostra a Detecção de Nó de Borda (END) 3672, iniciando na área de intersecção do setor 3592 até a saída Declarada do Nó de Borda 3596.
Petição 870200056145, de 06/05/2020, pág. 242/1737
240/754
[598] A Figura 318 mostra o Estágio 1 de detecção de nó de borda: Preencher Bolhas do Detector 3680, em que o módulo DBF (373) do Formato Detetor de Bolhas seleciona nós aleatórios na área de interseção do setor para espalhar as bolhas uniformemente nos nós vizinhos.
[599] A Figura 319 mostra o Estágio 2 de Detecção do Nó de Borda: a saturação da bolha do detector 3690 é onde eventualmente as Bolhas não terão mais espaço para se expandir ou, tecnicamente, não haverá mais nós disponíveis para reivindicar a jurisdição de uma bolha enquanto a bolha mantém uma expansão uniforma na área de superfície entre sua circunferência.
[600] A Figura 320 mostra o Estágio 3 de Detecção do Nó de Borda: Eliminação da Maioria dos Vizinhos 3700 é que as bolhas X principais são excluídas de acordo com a área de superfície através do módulo 3770 da Eliminação dos Vizinhos da Bolha (BNE). X é definido de acordo com a Política Estática de Código Codificado (SHP) 488. Esse estágio leva apenas às menores bolhas restantes, que se tornarão um fator principal na localização exata dos nós de borda.
[601] A Figura 321 mostra o Estágio 4 de Detecção de Nó de Borda: a Calibração da Direção 3710 é a orientação da direção ideal da rota intrasetorial é calculada por referência à Sequência Algorítmica do Boomerang, conforme referenciado no módulo 3800 da Calibração da Direção de Viagem (TDC) . Isso permite que pequenas bolhas dispersas sejam removidas, o que distrai o algoritmo de encontrar a localização exata dos Nós de Borda.
Petição 870200056145, de 06/05/2020, pág. 243/1737
241/754
[602] A Figura 322 mostra o Estágio 5 de Detecção de Nó de Borda: Dissecção da Largura da Seção 3720 é o local em que as coordenadas da largura do setor são calculadas pelo módulo 3790 da dissecção da largura do setor (SWD). A Largura do setor é definida como a maior distância possível entre qualquer uma das bolhas restantes.
[603] A Figura 323 mostra o Estágio de Detecção de Nó de Borda 6: Descoberta do Nó de Borda 3730 é onde a Dissecção da largura do setor (SWD) 3790 foi realizada depois da Calibração da Direção de Viagem (TDC) 3800 remover todas as pequenas bolhas de tamanho que poderíam ter atuado como nós de borda falsos positivos. Portanto, a Detecção de Nó de Borda (END) 3672 pode confiar na expectativa de que os dois nós que conectam a largura do setor sejam nós de borda corretos e precisos.
[604] A Figura 324 mostra a lógica da Detector de Formação de Bolhas (DBF) 3740, lógica em que o Estágio 3748 aplica a estratégia de expansão a cada bolha identificável exclusivamente aos nós vizinhos, que utiliza a seguinte estratégia de expansão em que: 1. As bolhas podem se expandir dependendo dos nós em potencial serem capazes de se correlacionar para inclusão. Isso leva a uma bolha crescer em um padrão circular como permitido pela composição do nó. Portanto, uma bolha não age como um líquido que preenche lacunas independentemente da forma, mas requer expansão uniforme; 2. A maturação da expansão da bolha atinge um pico quando seu limite atinge o limite das outras bolhas concorrentes. Uma parte da borda de uma bolha que atinge um obstáculo faz com que toda a bolha pare de se expandir; e 3. Uma bolha só pode se expandir incluindo nós em sua jurisdição
Petição 870200056145, de 06/05/2020, pág. 244/1737
242/754 que ainda não foram atribuídos por outras bolhas e pertencem à Área de Interseção Setorial 3592.
[605] A Figura 325 mostra o Estágio 1 de Formação de Bolhas Detetoras: Plantar Sementes Aleatórias de Bolhas 3758 e o Estágio 2 de Formação de Bolhas Detetoras: Maturação de Bolhas 3766. Estágio 1 de Formação de Bolhas Detetoras: Plantar Sementes de Bolhas Aleatórias 3758 os nós são selecionados aleatoriamente para se tornarem Sementes de Bolhas. Adoção da Formação de Bolhas do Detector (DBF) 3740
[606] A Fig. 326 mostra a sequência 3770 de Eliminação de Bolhas Vizinhas (BNE), onde ele recebe um mapa de bolhas 3756 e fornece a saída como um mapa de bolhas reduzido 3780 para o mapa de bolhas reduzido 3782.
[607] A Fig. 327 mostra a dissecção da largura do setor (SWD) 3790 recebendo o mapa de bolhas reduzidas 3782 e fornecendo a saída declarada do nó do perímetro 3596.
[608] A Fig. 328 mostra os Receptores da Sequência 3282 do Livro de Saltos da Calibração da Direção de Viagem (TDC) 3800 para fornecer o mapa de Saída contendo todos os nós marcados pela Sequência Bumerangue 3810 ao Mapa de Sequência Bumerangue 3812.
[609] A Fig. 329 mostra a lógica do Mapa de Sequência do Bumerangue (BSA) 3820 do nó A selecionado (como entrada) para imitar a sequência do Bumerangue 3822 até a sequência do final do Bumerangue 3820, em que todos os nós foram selecionados e não fazem parte de nenhum dos os dois Livro de Saltos 3282 estão marcados como pertencentes a essa sequência de Bumerangue.
[610] A Fig. 330 mostra a Sequência Bumerangue 3832, onde o nó receptor emulará nós que não pertencem a um segmento
Petição 870200056145, de 06/05/2020, pág. 245/1737
243/754 intrasetorial, sucumbindo à jurisdição de uma rota gerada aleatoriamente chamada Sequência Bumerangue. As referidas sequências sempre se originam de qualquer nó que pertença a uma Rota Intrasetorial dos setores de perímetro. Essas sequências terminam quando colidem com um nó que pertence a qualquer segmento de rota intrasetorial ou quando expiram porque são muito longas 3836. Os setores de perímetro 3834 são as arestas dos setores que atuam como limites para calcular o ponto de origem de uma sequência de bumerangue na área de interseção do setor 3592. Nós BCHAIN 786 mostrados nos setores de perímetro 3834.
[611] As Figs. 331 e 332 mostram a sequência da Camada de Migração de Dados Físicos (PDML) 3850. O Gerador de link de fricção (FLG) 3862 refere-se à categorização de nós em diferentes suportes de velocidade para gerar links entre os nós que representam um diferencial na velocidade de escape do nó. A Estimativa de Zona de Atrito (FZE) 3868 refere-se a links de atrito pré-fabricados para definir um limite geográfico que é virtualmente conhecido pelo nó como uma ferramenta logística para alcançar a migração de dados físicos. O uso da migração de dados físicos (PDMU) 3851 fornece aos dados em movimento a capacidade de fazer uso funcional dos caminhos de migração físicos que foram criados pela 3880 Construção do Caminho de Migração (MPC). Migração (MPD) 3875 (identificada incorretamente como 3874 na Fig. 332). A Construção do Caminho de Migração (MPC) 3880 referese aos dados de rota incrementais da rota da Metachain 834 para criar novas rotas de migração física que estão sendo procuradas.
[612] A Fig. 333 mostra a rota de migração para definir as zonas de atrito 3893 nas quais as zonas de atrito são áreas
Petição 870200056145, de 06/05/2020, pág. 246/1737
244/754 estratégicas praticamente definidas no algoritmo da camada de migração de dados físicos (PDML) 385. Elas são construídas medindo o espaço de interação entre dois grupos de nós que operam com diferentes suportes de velocidade de escape do nó. Essas zonas de atrito tornam-se essenciais para orquestrar uma sequência de migração bem-sucedida para uma unidade de dados. Eles são usados para facilitar o carregamento em nós em movimento físico, a logística para permanecer nos nós corretos que estão em um caminho físico esperado e a sequência de aterrissagem para
desconectar com êxito de um de migração para um
estacionário. Os Links de Fricção 389 6 definem as Zonas de
Fricção 3893, em que os Links ; de Fricção são um cálculo abstrato
dentro do algoritmo que constrói um limite geográfico equivalente a uma Zona de Fricção. Os Links de atrito são links entre dois nós, cada um dos quais pertencendo a diferentes grupos de velocidade. Inclui o cluster de velocidade 3897, as zonas de fricção 3893, o nó BCHAIN (BN) 786 e a rota de migração 3894.
[613] As Fig. 334 e Fig. 335 mostram a sequência de otimização de choque de rota de salto (HPCO) 3900. CCF 2318 para retenção de cache de choque 1018 é a quantidade percentual de armazenamento de nó local que deve ser alocado para a retenção de CCF 2318 que não existe no PNCC 1218. Portanto, se um CCR e o CCF 2318 armazenado correspondente cruzarem o caminho do outro prematuramente, a solicitação de conteúdo poderá ser devidamente atendida. Há uma quantidade otimizada de ponto justo das CCF 2318 a serem mantidas para fazer uso eficiente de choques de informação caóticos não intencionais.
[614] A Fig. 336 mostra a Viagem de pacote abandonada
Petição 870200056145, de 06/05/2020, pág. 247/1737
245/754
2318, que são todos os nós que originalmente deveríam participar da viagem de realização de conteúdo, agora aliviados de sua carga e capazes de investir seus recursos e tempo em trabalhos alternativos. Portanto, a economia de oferta/demanda da Rede BCHAIN em geral foi afetada pelo Evento de Choque. 0 local original da Appchain do Cachê (que é o BN 786 mostrado no canto superior direito) é o nó de cache original que precisava para satisfazer a solicitação da CCR 2308 agora que não precisa atender à solicitação original devido ao evento de falha. Portanto, a mecânica da oferta/demanda do entorno é alterada à medida que mais recursos são liberados para facilitar outras solicitações. O Evento de Falha na Rota de Salto 2308 é um CCR 2308 que estava originalmente se movendo em direção a um Nó de Cache (no Setor L22 - setor superior direito) agora, aliás, encontrou um nó com uma cópia do conteúdo com o qual está procurando recuperar. Portanto, esse evento de falha acidental pode ser usado para otimizar a eficiência de roteamento na rede BCHAIN.
[615] A Fig. 337 mostra a sequência de retificação de erro de rota 3940 (PER) . O aumento da intensidade da rede e congruência (NSCE) rastreia o comportamento de interação dos nós para detectar áreas de isolamento da rede e fraqueza de redundância. Portanto, o roteamento de nó e a priorização de ponte podem ser executados com mais eficiência.
[616] A Fig. 338 mostra o Gargalo de Tráfego do Nó nos dois BN 786 dentro do Ambiente Caótico (retângulo interno). O ambiente caótico é definido por um gargalo na largura de banda do desempenho devido à baixa densidade de nós na área. Portanto,
Petição 870200056145, de 06/05/2020, pág. 248/1737
246/754 a transferência de dados primária está ocorrendo entre dois nós principais que estão montando os ambientes não caóticos juntos. Os mesmos dois BN 78 6s no ambiente caótico têm uma seta bidirecional que indica a Priorização de Sincronização de Metachain - dada a largura de banda limitada entre os dois nós de gargalo, as informações são priorizadas de acordo com o tipo de Customchain em um protocolo semelhante ao Voice over IP (VoIP). Os pacotes da Metachain recebem a maior prioridade para manter a integridade e a eficiência da Rede BCHAIN em geral. Em segundo lugar, os pacotes da Appchain/Microchain são priorizados de acordo com a taxa de pagamento do EAT (Token de Autorização Econômica) 994 dessa transferência de dados. 0 pacote CCR ou CCF não entregue (retângulo pontilhado no ambiente caótico) é uma tentativa malsucedida de fornecer um CCR 2308 ou CCF 2318 levando à invocação do módulo Retificação de Erro de Rota (PER) 394. Isso permite que os ambientes caóticos sejam rastreados e marcados na Metachain 834 por meio da Melhoria da Intensidade e Congruência da Rede (NSCE) 2442 em primeiro lugar. O Ambiente Caótico indica fraqueza nas comunicações entre nós - O monitoramento do ambiente caótico na Metachain 834 destaca uma área geográfica, em relação à localização do nó, que possui uma baixa densidade de disponibilidade do nó ativo. Portanto, o protocolo BCHAIN 794 é capaz de impedir preventivamente a ineficiência dos dados de roteamento que passam por um ambiente caótico.
[617] A Fig. 339 mostra a conclusão da sequência de
Retificação de Erros de Caminho (PER) 3940 enviando nós marcados ao NCSE para consenso impulsionado pelo rastreamento da
Petição 870200056145, de 06/05/2020, pág. 249/1737
247/754 modificação do ambiente caótico na Metachain 3948.
[618] A Fig. 340 a Fig. 343 mostra o Mecanismo de Preços do Setor (SPM) 3962 e o Mecanismo de Liquidação de Empregos (WSM) 3980. O Nó de Salário por Emprego (NWP) 4000 interage com a Metachain 834 para apresentar o pagamento do trabalho ao nós que contribuíram para a transferência da CCR 2308 ou CCF 2318. A Verificação da Produção Econômica Assinada (SEOV) 4016 verifica se o nó que está pagando pela transferência de informações autorizou o escopo do trabalho (prevenção de abuso). Opcionalmente, o Conjunto de Rastreamento Variável (TVS) 2320 também pode fornecer informações ao Envio do Histórico de Diagnóstico (DHS) (não mostrado na Fig. 340) para aqueles que têm interesse em refinar e depurar o código e executar BCHAIN (por exemplo, desenvolvedores principais) sendo capaz de instalar nós habilitados para depuração em setores significativos que adicionam informações de diagnóstico para acompanhar o desenvolvimento do Protocolo BCHAIN. Os nós procuram nós de diagnóstico autodeclarados e testados em um setor. Portanto, qualquer CCR 2308 ou CCF 2318 que passa por esse setor terá seu Conjunto de Variáveis de Rastreamento (TVS) 2320 para coletar e enviar informações de diagnóstico para nós de diagnóstico conhecidos.
[619] A Fig. 344 mostra Nó Pagamento por Trabalho (NWP) 4000. O Nó Pagamento por Trabalho (NWP) 4000 interage com a Metachain 834 para apresentar Pagamento de Trabalho para nós que contribuíram para a transferência do CCR 2308 ou CCF 2318. A sequência começa com o percentil de setores atuais do desempenho total da rede 4004, fornecendo informações para calcular o
Petição 870200056145, de 06/05/2020, pág. 250/1737
248/754 pagamento por salto/nó (cada nó fez um salto) com a fórmula 4006 (consulte a Fig. 344) que envia as informações para o pagamento por 4008 (por exemplo, 5 unidades de trabalho BCHAIN 1216) e termina na interface de economia direta 4012.
[620] As Figs. 345 a 346 mostram Verificação da Produção Econômica Assinada (SEOV) 4016. A Verificação da Produção Econômica Assinada (SEOV) 4016 verifica se o nó que está pagando pela transferência de informações autorizou o escopo do trabalho (prevenção de abuso). O Cálculo de Divergência de Caminho de Salto (HPDC) 4032 calcula a diferença percentual entre o PBHP original conforme percebido pelo remetente e o PBHP 2322 real sendo realizado pelo CCR 2308 ou CCF 2318.
[621] As Figs. 347 a 349 mostram a Assinatura do Livro do Salto (HLS) 4040. O HLS 4040 começa com o Livro do Salto 3282 contendo os nós 4042 e o nó 4046 e termina no Livro do Salto 3282. Este módulo está concluído e o Livro do Salto é deixado, portanto, bloqueia o CCR 2308 ou CCF 2318 de saída do procedimento 4 97 4 é uma prevenção de abuso de pagamento duplo, em que uma representação de nó duplicado indica tentativa de abuso de pagamento, pois o Protocolo BCHAIN 794 não permite o mesmo nó participe do caminho de salto de um CCR 2308 ou CCF 2318 mais de uma vez. Essa proibição também impede que um CCR 2308 ou CCF 2318 fique preso em um caminho de loop infinito em certos ambientes caóticos .
[622] As Figs. 350 a 353 mostram o NSS de agrupamento variável (NVP) 414. No NVP 4140, os nós dos mesmos setores anunciam sua percepção das variáveis da Pesquisa de Nó Estatístico (NSS) 778 para construir consenso sobre as
Petição 870200056145, de 06/05/2020, pág. 251/1737
249/754 características do setor. Portanto, as variáveis locais e remotas do NSS 778 são agrupadas para criar uma média composta conhecida como NVCI 4108. Esse composto é usado para manter um consenso sobre o escopo e a definição desse setor e, portanto, onde os limites.
[623] A Fig. 351 continua a sequência da Fig. 350, em que a Implantação da Estratégia 916 determina o intervalo de agrupamento variável do NSS 1026 sobre a frequência com a qual os nós devem anunciar (nos setores com os quais compartilham uma sobreposição) as variáveis NSS 778 que percebem. Assim, um setor criará consenso sobre suas próprias características do NSS 778. Se esse intervalo for menor, haverá maior integração e mais sincronicidade, e mais recursos serão esgotados (vice-versa se aplica) . As Variáveis Remotas NSS 4158 são o local onde as variáveis de outros nós são armazenadas temporariamente.
[624] A Fig. 352 contínua da Fig. 351. Determina as características de desempenho dos setores atuais (por exemplo, saltos por segundo, megabytes por segundo, etc.) 4160 para o Fator de Desempenho A 4112 e o Fator de Desempenho B 4114 4110 analisado em 4162. A Política de Código Estático (SHP) 488 fornece critérios rigidamente codificados no Protocolo BCHAIN 794. Esses critérios são estáticos em vez de critérios baseados em estratégias dinâmicas comuns, porque esses critérios são usados para definir seus própria estratégia de critérios. Portanto, se o mecanismo usado para produzir estratégias em si fosse baseado em estratégias, espera-se que o sistema acabe em um estado extremo que tenha funcionalidade e eficiência limitadas e/ou anormais.
Petição 870200056145, de 06/05/2020, pág. 252/1737
250/754
[625] A Fig. 353 continua da Fig. 352 e mostra a execução do NVP 4140 da rotina em um intervalo ao recuperar as Variáveis NSS 4142. A Composição Média das Variáveis NSS (NVCI) 4108 mostra variáveis do índice de Escape do Nó 886, índice de Saturação de Nó 888, índice de Consistência de Nó 890, índice de Sobreposição de nó 892.
[626] As Fig. 354 a Fig. 356 mostram a lógica para a sequência Apresentação Jurisdicional de CCF Implicado (JICS) 4194 e sequência Jurisdicionalmente Aceita de CCF (JACR) 4208.
[627] A Fig. 354 mostra o Disparo Genérico de Eventos do Sistema (GSET) 4188, que é uma rotina automatizada que invoca obrigações de outros nós de acordo com sua categoria de jurisdição (Starts No.l) na Categoria de Invocação 4190 que fornece a entrada para Criar um prova de origem criptográfica usando a Identificação de Nó Único 4196 dentro do Envio da CCF Implícita Jurisdicional (SJICS) 4134 na qual os CCF 2318 são enviados para um nó sem uma CCR 2308 devido à responsabilidade jurisdicionalmente implícita desse nó em receber a CCF 2318. A chamada de categoria 4190 também obtém a entrada para os tipos de categoria codificados 4170 que incluem a categoria A: Envio de novo conteúdo para os mineradores 4172, Categoria B: NSS de agrupamento variável e uso compartilhado dos segmentos de rota do setor 4176, Categoria C: Sessão de Transmissão ao Vivo Autenticada pela Appchain 4180, Categoria D: Nós próximos ao nó de diagnóstico 4184. Dentro de cada uma das categorias está sua informação específica: Critérios de Característica: Categoria A 4174, Critérios de Característica: Categoria B 4178, Critérios de Característica: Categoria C 4182 e Critérios de
Petição 870200056145, de 06/05/2020, pág. 253/1737
251/754
Característica: Categoria D 4186. 0 Reconhecimento de Categorias 4192 verifica se o conteúdo corresponde aos critérios característicos desta categoria 4207 (falta de etiqueta na Fig. 354 na Recepção CCF Jurisdicionalmente Aceita (JACR) 4208.
[628] A Fig. 355 continua a lógica da Fig. 354 com os processos internos do JICS 413. O Upload de Conteúdo 4202 ocorre através da Interface de Upload de Conteúdo Genérico (GCUI) 4206, que é um ponto de conexão de entrada para o conteúdo a ser entregue. Carregar via apresentação implícita do CCF (por exemplo, pacotes de áudio para uma ligação telefônica ao vivo). Anúncio de novo conteúdo (NCA) 2544 (é o número final 1 para o início número 1).
[629] A Fig. 356 mostra a lógica do JACR 4208 ao longo de onde a Representação de reivindicações de conteúdo (CCR) 3300 (é o número de início 2 e o final de número 2) e a interface da plataforma UBEC 728 (é o fim No. 3).
[630] As Figs. 357 e 358 mostram que os participantes das chamadas ao vivo UBEC A e B fazem uma chamada com detalhes sobre a Parte 1 de iniciação de chamada 422 6 e a Parte 2 de iniciação de chamada 4240.
[631] Fig. 357 Iniciação de chamada Parte 1 4226 é semelhante ao tom de discagem nos sistemas de Rede Telefônica Pública Comutada Herdada (PSTN). O participante A nas chamadas ao vivo 4224 (conectado ao BN 786 com transmissão de voz 4222 e recepção de voz 4220) inicia uma proposta de chamada telefônica (que inclui um EAT 994) emitindo um CCR 2308 ao participante B 4228. EAT 994 fornece opções flexíveis de pagamento (quando uma
Petição 870200056145, de 06/05/2020, pág. 254/1737
252/754 ligação telefônica ao vivo está envolvida, o participante A pode optar por pagar totalmente pela sessão de transferência de informações em tempo real, dividir o pagamento com o participante B ou escolher o participante B para pagar por ela. 0 participante B tem a oportunidade de rejeitar ou aceitar a chamada com base na opção de pagamento proposta). 0 participante de chamada ao vivo B 4234 (conectado ao BN 786 com transmissão de voz 4238 e recebimento de voz 4236) aceita a chamada com (a aceitação de chamadas telefônicas em nome do participante B é representada por um CCF 2318) 4320. Participante A verifica se a aceitação do participante B da ligação 4232.
[632] A Fig. 358 continua da Fig. 357, onde a Appchain aninhado em execução exclusivamente para os Participantes A e B 424 6 dentro da Appchain de Chamada ao Vivo UBEC 4244 usando o módulo 4242 do Procedimento de Interação da Transmissão ao Vivo da Appchain (ALIP) que serve como um ponto final para conectar o agendamento de contrato inteligente da Appchain 836 à sessão de Transmissão ao Vivo. Portanto, uma Appchain 836 pode iniciar, pausar ou destruir uma Sessão de Transmissão ao Vivo com base em procedimentos automatizados e/ou entrada manual do usuário. A Appchain de Chamada ao Vivo da UBEC 4244 como exemplo é uma Appchain aninhado 836. Sua estrutura pode fornecer os recursos de transferência de informações para gerenciar e executar uma chamada telefônica ao vivo. Isso inclui autenticação do usuário, logística de pagamento, políticas de iniciação como tempo limite, opções de correio de voz etc. A Parte 2 da Iniciação de Chamada 4240 mostra o Participante A da Chamada ao vivo 4224 e envia os detalhes da proposta de chamada criptográfica a Appchain aninhado
Petição 870200056145, de 06/05/2020, pág. 255/1737
253/754
4248 que verifique a Proposta de Chamada Telefônica que foi extraída por um minerador da Appchain 4250. Ao receber uma confirmação afirmativa, YES 98, passa a executar o ALIP nos Participantes A e B 4254. No caso de 4254, receber um NO 96, espera um curto período de tempo 4252.
[633] [00] Figs. 359 - 365 mostram a estrutura do processador personalizado projetado para a Arquitetura de Microchip da UBEC/BCHAIN (UBMA) 4260 (também conhecido como Microchip Otimizado para BCHAIN ou BOM) . Demonstra um design exclusivo de segurança de hardware para proteger chaves de semente privadas. As chaves de semente privadas para criptografia são protegidas por hardware, para que o potencial de uma chave de semente vazada ou hackeada (que pode potencialmente manipular fundos) seja completamente eliminado. São estabelecidos canais especiais para a UBEC Legislativa de Inteligência Governamental Independente (LUIGI) 116 na Plataforma UBEC 100. O processador UBMA 4260 é otimizado para executar instruções sobre os módulos (coma Appchains 836) que compõem o protocolo BCHAIN 794.
[634]Na Fig. 359, os reguladores de tensão A 4272 e B 4274 controlam a entrada de tensão que leva a duas subseções separadas do processador UBMA 4260: subseção 4273 e subseção 4275. Portanto, duas tensões separadas podem ser ajustadas em paralelo. Porque a tensão tem uma relação linear com a frequência do relógio, o Processador da UBMA 4260 pode fazer Overclock dinâmico de uma parte do chip enquanto faze Underclocking da outra (e vice-versa). Isso leva à priorização dinâmica de recursos de acordo com os sinais recebidos do protocolo BCHAIN
Petição 870200056145, de 06/05/2020, pág. 256/1737
254/754
794. Incorporados ao processador estão três chips sem fio; o chip Wifi sem fio 4266, o chip Bluetooth sem fio 4268 e o chip de rádio de longo alcance e alto ganho 4270. O chip Wifi sem fio 4266 pode ser usado para comunicação de médio alcance entre os nós BCHAIN 786 com a maior capacidade de produção. O chip Wifi 4266 também pode ser usado para conectar-se a pontos de acesso Wifi herdados que podem conceder acesso à rede BCHAIN 110 através do Mecanismo de ponte de rede herdado (LNBM) 2410. O chip Bluetooth sem fio 42 68 pode ser usado para comunicação curto alcance entre os nós BCHAIN 78 6 com uma quantidade média de capacidade de produção. O chip Bluetooth 4268 pode ser usado para se comunicar com dispositivos Micro 102 loT que operam como nós BCHAIN 786, mas podem apenas operar e alimentar a tecnologia sem fio de baixa energia, como Bluetooth. O chip de rádio de longo alcance e alto ganho 4270 permite a comunicação de longa distância entre os nós BCHAIN 786 com a menor quantidade de capacidade de produção. O Rádio 4270 opera sob mecânica semelhante ao rádio AM. Para que os nós do BCHAIN 786 possam se comunicar através do Radio 4270, existem várias frequências de reunião às quais cada nó 786 transmite ocasionalmente sua identidade, anúncio de hash e frequência pessoal. Posteriormente, para dois Nós 786 estabelecerem um canal de comunicação ponto a ponto, eles poderão se encontrar nas Frequências Pessoais um do outro e trocar informações. Cada uma das tecnologias sem fio 4266, 4268, 4270 é equipada com a tecnologia Direção de Ganho Avançada 4262. Isso significa que cada uma das tecnologias 4266, 4268, 4270 é capaz de concentrar energia através de suas antenas em uma direção especifica para maximizar o desempenho com um Nó
Petição 870200056145, de 06/05/2020, pág. 257/1737
255/754 de Destino especifico 786, minimizando o uso de energia em áreas que não possuem Nó de Destino 786 Esperados. Isso aumenta a eficiência e o desempenho gerais entre os Nós da BCHAIN 786 que operam com o Processador UBMA 4260. Portanto, a eficiência e o desempenho gerais da rede BCHAIN 110 aumentam com a adoção do processador UBMA 4260. Os chips sem fio 4266, 4268, 4270 operam em frequências diferentes para evitar colisão e interferência e são eles diversificam por meio de comunicação de curto, médio e longo alcance. O protocolo BCHAIN 794 prioriza as informações que devem ser transferidas em situações de escassez. Por exemplo, se apenas uma conexão ponto a ponto fraca via rádio 4270 estiver disponível, o Protocolo 794 priorizará o tempo da Metachain 834, pois é a informação mais lógica e anterior que os Nós 786 podem reter. O cache L2 A 4276 e B 4278 são unidades de armazenamento não persistentes extremamente rápidas, cada uma delas acessível exclusivamente por sua respectiva subseção 4273, 4275. O cache L3 4280 é semelhante ao cache L2 4276, 4278, exceto que é maior em tamanho, mais lento em velocidade e disponível para acesso a todo o processador UBMA 42 60. O Gerenciamento de E/S 42 62 reconhece os segmentos de execução 551 e as instruções gerais de processamento e, portanto, os atribui ao microchip correto e retorna os dados para o restante do hardware do nó 786 (por exemplo, dispositivo de armazenamento persistente de um nó 786).
[635] A Fig. 360 mostra a estrutura da Subseção A 4273 que é controlada pelo Regulador de Tensão A 4273. Esta Subseção 4273 é composta por Microchips que são projetados especificamente para processar eficientemente as instruções exigidas pelos principais componentes do Protocolo BCHAIN 794. Portanto, o
Petição 870200056145, de 06/05/2020, pág. 258/1737
256/754
Protocolo BCHAIN 794 opera mais rapidamente e com menos consumo de energia em um processador UBMA 4260 em comparação com uma CPU (Unidade Central de Processamento) padrão. O Gerenciamento de Integridade de Dados como um Microchip 4282 é capaz de executar com eficiência todas as rotinas existentes no Gerenciamento de Integridade de Dados (DIM) 1204. Portanto, há um melhor gerenciamento/manipulação e resgate de Dados em risco na rede BCHAIN 110. A logística da Appchain, como o Microchip 4284, é capaz de processar a retenção e execução das Appchains 836 e Microchains 838 na rede BCHAIN 110. O LIZARD 120 é um dos mais cruciais, centrais e dependentes de Appchains 836 na plataforma UBEC 100. O LIZARD 120 não se baseia em um banco de dados para a operação e, em vez disso, julga e estima medidas de risco e conformidade no momento devido à sua complexa inteligência a priori (sem referência prévia) Isso permite que os elementos e submódulos LIZARD 120 mais estáticos sejam instalados como Rotinas de Hardware no LIZARD como um Microchip 4286. Uma possível revisão futura do Processor UBMA 4260 é a capacidade de alterar dinamicamente seu próprio conjunto de Microprocessadores através de Estruturas Condutoras Dinâmicas. Isso permitiría que todas as Appchains 836 LIZARD 120 funcionassem como um Microchip 4286, incluindo o LIZARD 120 Shell dinâmico (DS) . A Lógica de Roteamento como Microchip 4288 aumenta a eficiência de energia e reduz a Latência da Lógica de Roteamento (RL) 774 e seus submódulos para operar. Assim, aumentando a força e a eficácia geral da rede BCHAIN 110. O LOM 132 é um dos mais cruciais, centrais e dependentes das Appchains 836 da Plataforma UBEC 100. Portanto, o mais utilizado de seus submódulos, como Construção
Petição 870200056145, de 06/05/2020, pág. 259/1737
257/754 de As afirmações (AC) 622 e o Mapeamento Hierárquico (HM) 624 onde é otimizada na Lógica principal de LOM como um microchip 4290. Portanto, é mais rápido e requer menos energia para executar os submódulos LOM 132 (coma Appchains 836) como AC 622 e HM 624 no Microchip 4290 em comparação com a Unidade Central de Processamento (CPU) 4294. Portanto, toda a Manifestação Modular de Fluxo de Execução LOM 132 616 é feita com eficiência na execução. O Módulo de Criatividade, como o Microchip 4292, otimiza a execução do Módulo de Criatividade 112 na Plataforma UBEC 100. Isso leva a um grande aumento na eficiência computacional na Plataforma UBEC 100 e na Rede BCHAIN 110, devido a muitas Appchains 836, dependendo da Criatividade 112, como I2GE 122, CTMP 124, MPG 114, SPSI 130 etc. Somente os microchips 4282, 4284, 4286, 4288, 4290, 4292 na subseção 4273 têm acesso ao cache A L2 4276 e têm sua voltagem e, portanto, a frequência do relógio governada pelo Regulador de voltagem A 4273.
[636] A Fig. 361 mostra a subseção 4275 do processador UBMA 4260 que abriga microchips genéricos 4292, 4294, 4296, 4300 que facilitam tarefas mais genéricas que precisam ser concluídas no Protocolo BCHAIN 794 em comparação com a contrapartida da subseção A 4273. A Unidade Central de Processamento (CPU) 4294 é a seção de cálculo padrão para um Nó BCHAIN 786 com o instalador do Processador UBMA 4260; a menos que instruções especializadas que possam se beneficiar de outro microchip sejam encontradas pela Gestão de E/S 4262. A Unidade de Processamento Gráfico (GPU) 4296 é usada principalmente para renderizar o conteúdo da Appchain 836 na interface do usuário front-end da UBEC 1148. A Unidade de Processamento Criptográfico (CGPU) 4292 executa as
Petição 870200056145, de 06/05/2020, pág. 260/1737
258/754 funções que operam no Núcleo Criptográfico (CC) 768, que são invocadas em todo o protocolo BCHAIN 794. A Unidade de Geração de Certificado de Hardware Seguro (SHCG) 4300 mantém com segurança a Chave Privada Única Sensível à Segurança 4314, usada para manipular os Fundos do Nó 786 na Economia de 862 Watts da Metachain 834. Portanto, um Endereço Público Gerado pelo Nó 4302 pode ser eficiente e rapidamente gerado pelo SHCG 4300 sem responsabilidade e risco da Exposição da Chave Privada Exclusiva Sensível 4314. Ao acoplar forçosamente as unidades de Watt na economia de Watts 862 com o hardware físico de um nó 786 através do processador UBMA 4260, o gerenciamento e a manipulação das Unidades de Watt se tornam mais previsíveis e seguros na plataforma UBEC 100 e a rede BCHAIN 110. O microchip SHCGU 4300 também contém uma cadeia de identificação exclusiva de nó codificado 4304 que foi gerada aleatoriamente no momento da fabricação do Processador UBMA 4260. Essa identificação exclusiva 4304 é permanentemente combinada com o Processador UBMA 4260, levando a confiar no Rastreamento de Identificação de Nós, principalmente através do Metachain 834, na rede BCHAIN 110. Somente os microchips 4292, 4294, 4296, 4300 da subseção 4275 têm acesso ao Cachê L2 B4278 e têm sua voltagem e, portanto, a frequência do relógio governada pelo regulador de tensão B 4275.
[637] A Fig. 362 mostra detalhes adicionais sobre a Unidade de Geração de Certificados de Hardware Seguros (SHCGU) 4300. Neste diagrama, o SHCGU 4300 está em um processador UBMA 4260 hospedado em um nó pertencente à lista de nós associados à sessão da FRM 4306. A Associação de Identidade Permanente com Hardware (PIAH) 4308 é uma subseção do SHCGU 4300 que produz a
Petição 870200056145, de 06/05/2020, pág. 261/1737
259/754
Identificação Exclusiva do Nó 4304 que foi definida no momento da fabricação. Com a chave privada bloqueada por hardware (HLPK) 4310, a chave privada sensível à segurança exclusiva 4314 é permanentemente observada atrás de uma camada de bloqueio de hardware 4312. A única exceção para uma cópia da chave privada 4314 é deixar intencionalmente a camada de bloqueio do hardware 4312 feita através do canal exclusivo de Backdoor 4316 para envio ao LUIGI 116. A Geração de Endereços Públicos (PAG) 4318 é a subseção que gera um endereço público derivado 4302 da chave privada 4314 sem transferir nenhuma instância a Chave Privada 4314 fora da Camada de Bloqueio de Hardware 4312. De acordo com a Etapa 4322, a Lógica de Lançamento de Chave Privada (PKRL) 4324 gerencia o lançamento da Chave Privada 4314 através do Canal Exclusivo do Back Gate 4316 após a verificação da Prova de Autoridade 402 e do Canal de Criptografia 4326 usado. A Etapa 4322 é, portanto, invocada quando LUIGI 116 fornece Prova de autoridade 402 para a subseção HLPK 4310 do SHCGU 4300 na Etapa 4320 .
[638] A Fig. 363 mostra a interação entre o SHCGU 4300, o Canal de Criptografia Hospedado da BCHAIN 4326 e o LUIGI 116. Faz parte da responsabilidade oficial do LUIGI 116 na plataforma UBEC 100 e na rede BCHAIN 110 de manter versões de backup da Chave Privada Exclusiva Sensível à Segurança 4314, que controla as Unidades de Watts na Economia de Watts 862 da Metachain 834. Dessa forma, se o Nó 786 for roubado, perdido ou comprometido; as Unidades de Watt podem ser restauradas para o Usuário da UBEC correto 106, operando os recursos avançados artificialmente inteligentes do LUIGI 116. O LUIGI 116 apresenta a prova de
Petição 870200056145, de 06/05/2020, pág. 262/1737
260/754 autoridade 402 no nó 786 para forçá-lo a revelar com segurança a chave privada sensível à segurança exclusiva 4314. O LUIGI 116 mantém a Cópia Privada da Prova de Autoridade 402 dentro do Enclave Seguro da LUIGI (LSE) 380 e envia uma versão pública gerada da Prova de Autoridade 402 para o Nó 786. Como está programado no Protocolo BCHAIN 794 para que um Nó 786 atenda à solicitação de divulgação segura de Chave Privada 4314 da LUIGI 116, cada Nó Legitimo 786 obedecerá. Se o nó 786 não atender a uma solicitação autorizada pela LUIGI 116 com a Prova de autoridade 402; isso indica que o Nó não é confiável e, portanto, pode ser facilmente proibir a participação na rede BCHAIN 116 por LUIGI 116. Após a verificação da autenticidade da Prova de Autoridade 402 e do Canal de Criptografia Hospedada da BCHAIN 4326, o Nó Legítimo 786 cumpre e envia com segurança a Chave Privada Exclusiva Sensível à Segurança 4314 através do Canal de Criptografia 4326 para o LUIGI 116. O LUIGI 116 posteriormente armazena a Chave Privada 4314 em um Slot Vazio 4330 na Camada de
Criptografia 4312 que somente é descriptografável através da Chave de Descriptografia de Retenção 394, armazenada no Enclave Seguro da LUIGI (LSE) 380. Portanto, a Chave Privada 4314, a sequência de Backup está concluída. Após a invocação e o término de uma Sessão de Recuperação bem-sucedida com o Mecanismo de Recuperação de Fundos (FRM) 398, o Mecanismo de Manipulação de Fundos (FMM) 400 usa a Chave de Descriptografia de Retenção 394 para Descriptografar a Chave Privada Única Sensível ao Segurança relevante 4314, permitindo que o LUIGI 116 mova as unidades de watts em questão para um nó 786 que pertence e é controlado pelo Usuário da UBEC 106 (que é o proprietário legítimo das Unidades
Petição 870200056145, de 06/05/2020, pág. 263/1737
261/754 de Watts ) .
[639] A Fig. 364 mostra mais detalhes sobre o Mecanismo de Recuperação de Fundos (FRM) 398. 0 usuário da UBEC 106 é autenticado por meio da interação do nó do usuário (UNI) 470, que produz uma sessão de usuário autenticada 522. A Etapa 4352 representa o inicio do processo de recuperação de fundos perdidos, é invocado pelo Usuário da UBEC 106 através do FrontEnd UBEC 1148. A Etapa 4352 leva à Etapa 4354, que descompacta a Lista de Nós Associados 518 da Sessão do Usuário Autenticado 522. A etapa 4354 leva à etapa 4353, que inicia uma Sessão de verificação de recuperação de fundo 4342 com o Usuário da UBEC 106 por meio do Font-End da UBEC 1148. Portanto, o módulo Verificação de recuperação de fundo (FRV). O 4340 gerencia a Sessão de Verificação de Recuperação de Fundos 4342. A referida sessão 4342 é realizada com o Usuário da UBEC 106 através do Front-End da UBEC 1148, e envolve questionamentos e camadas adicionais de verificação para considerar a aprovação 4346 ou a rejeição 4344 da reivindicação aos fundos. Se a Sessão 4342 de Verificação de Recuperação de Fundos foi rejeitada 4344, o módulo FRM 398 encerrará a execução na Etapa 4348. Se a Sessão 4342 foi Aprovada 4346, será chamado o Estágio 4350 que Descriptografa a Chave Privada 4314 e a usado para manipular fundos relevantes de uma maneira que resolva a reivindicação de recuperação. Normalmente, isso envolve a transferência de fundos do Nó Inacessível 786 para um Nó 786 pertencente ao Usuário 106 UBEC Aprovado 4346.
[640] A Fig. 365 mostra mais elementos de interação entre o Mecanismo de recuperação de fundos (FRM) 398 e o LUIGI
Petição 870200056145, de 06/05/2020, pág. 264/1737
262/754
116. 0 FRM 398 é um submódulo que pertence à jurisdição do LUIGI 116. Após a Etapa 4350, a Chave de Descriptografia de retenção 394 é acessada pelo Enclave Seguro da LUIGI (LSE) 380. A Chave de Descriptografia de Retenção 394 é usada para descriptografar e acessar a Chave Privada Exclusiva Sensível à Segurança 4314, usada para manipular fundos da Economia de 862 Watt da Metachain 834 através de do Mecanismo de Manipulação de Fundos (FMM) 400. Portanto, o LUIGI 116 tem acesso a toda a Economia UBEC/BCHAIN armazenada na Economia de Watts 862 devido às cópias duplicadas das chaves privadas 4314 na retenção de chave privada criptografada 4328. Com um sistema programado por humanos, isso levaria a um problema de responsabilidade extremamente grande. Isso se deve à consideração de que os programadores teriam, teoricamente, acesso a grandes somas de riqueza e poderíam roubar os fundos instruindo o LUIGI 116 a entregar a Chave de Descriptografia Retida na Fonte 394, ou o FMM 400 manipular os Fundos de uma maneira que não Confiável de acordo com as instruções do programador. O LUIGI 116 é programado uma vez e pela primeira vez diretamente pelo homem. Quando a plataforma UBEC 100 e a rede BCHAIN 110 estiverem ativas e em operação pela primeira vez, todo o acesso criptográfico para modificar o código base LUIGI 116 será retido exclusivamente pela Autoinovação de Autoprogramação (SPSI) 130. SPSI 130 é um Appchain 836 que usa a tecnologia LIZARD 120 para programar outras Appchains 836 na plataforma UBEC 100. Essa programação do SPSI 130 inclui refino, correção de erros, manutenção programada, análise da unidade de registro de diagnóstico 1182, novos recursos de inovação, etc. O SPSI 130 é capaz de se programar, no entanto, recebe elementos
Petição 870200056145, de 06/05/2020, pág. 265/1737
263/754 da SIDI 1190 de Orientação para Programação de Desenvolvimento Indireto (SID) 1190. Os usuários da UBEC 106 aprovados que possuem habilidades comprovadas de programação/engenharia/arquitetura são permitidos pela LUIGI 116 no desenvolvimento de diretrizes de programação e da teoria do código, como o SID 1190. Isso leva a melhorias induzidas por humanos nas capacidades do SPSI 130 sem nunca ter acesso humano direto. Isso é feito principalmente porque o acesso direto à programação do SPSI 130 implica acesso direto à programação do LUIGI 116, o que implicaria acesso direto à programação de toda a riqueza armazenada na economia de 862 watts da Metachain 834.
[641] A Fig. 366 mostra os detalhes do módulo 6260 do Patch de Montagem de Implementação, os detalhes da Camada Logística 582 e sua interação com o Construtor de Ecossistemas da Customchain (CEB) 584. O DPA 6260 consiste na Ação de Modificação de Princípio (PMA) 8620, Análise de Unidade de Registro de Diagnóstico (DLUA) 8048, Refinamento Automatizado da Appchain (A2R) 8040, Correção de Erros Inatos (IEC) 8050, Proteção da Segurança da Appchain (ASH) 8044 e Conformidade Regulamentar da Appchain (ARC) 806 e Produz o Patch de Correção da Appchain 6270. O CEB 584 recebe o patch de correção da Appchain 6270 e executa o ASC (Mecanismo de Troca da Appchain) para produzir a Appchain de destino 6060.
[642] A Fig. 367 mostra o Processo de Adição de Bloco de Correção (CPBA) 6062, em que o patch de correção da Appchain 6270 é recebido do módulo de montagem de patch de implementação (DPA) 6260 na etapa 6064 o patch de correção de Appchain é aplique como um novo bloco aa Appchain 596 com os segmentos de execução
Petição 870200056145, de 06/05/2020, pág. 266/1737
264/754
551 e 553 para a Appchain 596.
[643] As Fig. 368 a Fig. 371 mostram a sequência do Mecanismo de Appchain Exchange (ASM) 6066. Na etapa 6068 ASM 6066 Receba todos os blocos que compõem a Appchain do Target 6060 e execute os vários estágios dos processos ASM até o Anúncio do Novo Conteúdo (NCA) 2544.
[644] As Fig. 372 a Fig. 373 mostram a sequência 6144 da Interpretação da Camada Logística (L2I) que recebe entrada da interface Gestão de logística (LMI) 580 e da interface do Novo Desenvolvimento de Appchain (NAD) 8052 e fornece saída para o Patches de Implementação (DPA) e manipulação de aplicativos brutos (RAM) 6146.
[645] As Fig. 374 a Fig. 375 mostram o processo LIZARD para converter a Camada Logística da Appchain de destino em Appchain na Etapa 6136.
[646] A Fig. 376 mostra o processo de Manipulação de Appchain em Bruto (RAM) 6146 a partir da entrada da Camada Logística 582.
[647] A Fig. 377 a Fig. 378 mostra o processo para o LIZARD converter os Elementos Lógicos Executáveis da Camada Logística em Execução na Etapa 6162.
[648] As Figs. 379 a 380 mostram o processo para o LIZARD converter os elementos de dados estáticos da camada de logística em dados na etapa 6158.
[649] A Fig. 381 continua o processo de Manipulação de Appchain em Bruto (RAM) 614 6 da Etapa 6158 em que o LIZARD converte elementos de dados estáticos da camada de logística em dados.
Petição 870200056145, de 06/05/2020, pág. 267/1737
265/754
[650] A Fig. 382 mostra a sequência da Etapa 6172 que ο fluxo de execução é processado pelo ESR 6400 no MCE 6174.
[651]A Fig. 383 mostra a Etapa 6190 quando uma
instância preliminar de ESR encontra o escopo ambiental
potencial.
[652]A Fig. 383 a Fig. 385 mostra a Etapa 6210. 0
LIZARD converte o Estado de renderização inicial na Etapa 6212 Finalidade de renderização inicial.
[653] As Figs. 386 a 387 mostram a Etapa 6214. LIZARD converte o Status de renderização final na Etapa 6216 Finalidade da renderização final.
[654] A Fig. 388 a Fig. 402 mostra Detalhes da Etapa 6190, em que uma instância preliminar de ESR encontra o Escopo Ambiental Potencial usando CTMP 124 e LOM 132.
[655] As Fig. 403 e Fig. 404 mostram a lógica do DRF (Pedido de Dependência de Conformidade) 6146 (DRF) 6146 dos Segmentos de Dados 6160 aos Segmentos de Dados Marcados 6224. O I2GE 122 fornece entrada direta ao DRF 6176 e o LIZARD 120 fornece informações via Necessidade de Mapa Correspondente (NMM) C114 a DRF 6176.
[656] As Fig. 405 a Fig. 407 mostram a lógica do LIZARD 120 na Etapa 6242, onde o LIZARD transforma a Solicitação de Execução ou Solicitação de Dados em Finalidade.
[657] A Fig. 408 mostra a lógica para Manipulação de Appchain em bruto (RAW) com Conformidade com Solicitação de Dependência (DRF) 6176.
[658] A Fig. 409 mostra 6260 Conjunto de Patches de
Petição 870200056145, de 06/05/2020, pág. 268/1737
266/754
Implantação (DPA) com fluxo de execução atualizado AO 6264 e fluxo de execução original AO 6266.
[659] A Fig. 410 mostra Gerenciamento de Fluxo de Execução e Dados (EDSM) 6272 com fluxo de execução de fluxo de execução de coleção (ESC) 6700 atualizado AO 6264.
[660] A Fig. 411 a Fig. 412 mostra a Lógica de Fluxo de Dados Diferencial (DSDL) 6274 com o Fluxo de Dados Atualizado AO 6276 e o Fluxo de Dados Original AO 6278.
[661] A Fig. 413 a Fig. 416 mostra a lógica diferencial de fluxo de execução (ESDL) 6300 recebida pelo fluxo de execução atualizado A0 6260 na etapa 6302 para iniciar o loop do contador do segmento de execução do Genesis e do fluxo de execução original A0 6266 na Etapa 6304 para Iniciar o loop do contador do Segmento de Execução Genesis para iniciar o processo EDSL 6300 que termina na Etapa 6348, onde envia a saida modular do contêiner de patch como o Patch de correção da Appchain via API 6288 para a Correção da Appchain 6270.
[662] As Fig. 417 a Fig. 418 mostram a Representação de Fluxo de Execução (ESR) 6400. O ESR 6400 recebe informações do ESC 6700 e DSS 6800 nos fluxos de execução geral 6402 e fornece R2P 6404 enquanto fornece e recebe referência e reconhecimento de tipo de comando 6406. Os tipos de comandos 6408 estão listados.
[663] A Fig. 418 mostra a interação do fluxo de execução A0 556 com a lógica de execução principal (MEL) 6428.
[664] As Fig. 419 e Fig. 420 mostram os Tipos de Comando 6408 com Referência de Comando Condicional 6410 e Sequência de Execução 6466.
[665] As Figs. 421 a 424 mostram a execução 556 da
Petição 870200056145, de 06/05/2020, pág. 269/1737
267/754 lógica de execução principal (MEL) 6428 com base nos tipos de comando 6408.
[666] A Fig. 421 mostra a Execução 556 da Lógica de
Execução Principal (MEL) 6428 com base nos Tipos de Comando 6408 com Resultados de Renderização Herdados da Appchain 6412
Especificado na Etapa 6516 Comando Definido Herdado.
[667] A Fig. 422 continua da Fig. 421 com a execução 556 da lógica de execução principal (MEL) 6428, com base nos tipos de comando 6408 com resultados de renderização herdados da Appchain 6412 especificado. O fluxo de dados Al 6524 recebe informações de classificação do Fluxo de Dados (DSS) e fornece resultados para MEL 6428.
[668] A Fig. 423 mostra a Execução 556 da Lógica de Execução Principal (MEL) 6428 com base nos Tipos de Comando 6408 com Execução de Rosca Paralela Contínua para a Appchain 6408 alternativo.
[669] A Fig. 424 mostra a execução 556 da lógica de execução principal (MEL) 6428 com base nos tipos de comando 6408 com execução de threads de transferência para a Appchain alternativo 6414.
[670]A Fig. 425 mostra o processamento do fluxo de
dados A0 6550 com os tipos de comando 6408 e os segmentos de
dados de leitura 6416.
[671] A Fig. 426 mostra o processamento do Fluxo de
dados A0 6550 com tipos de comando 6408 e segmento de dados de
exclusão de sessão 6424.
[672]A Fig. 427 mostra o processamento do fluxo de
Petição 870200056145, de 06/05/2020, pág. 270/1737
268/754 dados AO 6550 com tipos de comando 6408 e segmento de dados de gravação de sessão 6420.
[673] A Fig. 428 mostra o processamento do fluxo de dados AO 6550 com os tipos de comando 6408 e o segmento de dados de exclusão persistente 6426.
[674] A Fig. 429 mostra o processamento do fluxo de dados A0 6550 com os tipos de comando 6408 e o segmento de dados de gravação persistente 6422 .
[675] A Fig. 430 mostra o processamento do Anúncio de Novo Conteúdo (NCA) 2544 com base nos tipos de comando 6408 e no segmento de dados de eliminação persistente 6426 na etapa 6586 Enviando um segmento nulo para a NCA que substitui o segmento de dados selecionado da Appchain de destino.
[67 6] A Fig. 431 mostra o processamento da Representação do Fluxo de Execução (ESR) 6400 e o Processamento de Resultados Renderizados (R2P) 6404. Inclui a execução geral dos fluxos 6600.
[677] A Fig. 432 a Fig. 436 mostra a sequência da Coleta de Fluxo de Execução (ESC) 6700 com o Objetivo 6060 através de suas várias etapas até a Apresentação do registro de diagnóstico (DLS) 1160 (falta de etiqueta na Fig. 436) e Execução 556.
[678] As Fig. 437 a Fig. 439 mostram o processo Classificação do Fluxo de Execução (DSS) 6800 com base na Appchain Objetivo 6060, onde processa cada bloco na Appchain Objetivo 6060 até que todos os blocos sejam processados na Etapa 6816 aloque as Chamadas de Referência de Referência. Dados para seus segmentos de dados correspondentes.
[679] As Figs. 440 a 442 mostram o Ajuste de Segmento Nulo (NSA) 6900, que é um módulo que busca tornar a atualização
Petição 870200056145, de 06/05/2020, pág. 271/1737
269/754 de novas informações eficiente. 0 NSA 6900 na Etapa 6906 recebe uma coleção de segmentos de execução (do ESC 6700) ou segmentos de dados (do DSS) e os armazena no ISCR (Retenção de coleção de segmentos de entrada) 6908.
[680] As Figs. 443 a 445 mostram a lógica do Processamento de Simetria de Objetivo a Objetivo (P2SP) 7000. O processo P2SP 7000 produz o resultado de processamento de simetria 7034 correspondente às duas entradas que ele recebeu. Entrada A 7002, Mapa da Hierarquia de Finalidade 7006 e Entrada B 7004, Mapa da Hierarquia de Finalidade 7008.
[681] A Fig. 446 e a Fig. 447 mostram que o Processamento de Alinhamento de Finalidade (PRP) 7050 é usado para produzir uma Unificação do Mapa de Hierarquia de Finalidade (PHMU) 7066 com base nas duas entradas recebidas. Entrada A 7002,
Mapa da Hierarquia de Finalidade 7006 e Entrada B 7004, Mapa da Hierarquia de Finalidade 7008.
[682] [00] A Fig. 448 mostra a interpretação geral da Inteligência Recursive Simbiótica Avançada (SRIA), que é uma teoria relacionada à Inteligência Artificial que se manifesta principalmente na operação da Autoprogramação Auto-inovação (SPSI) 130. O pico de Inteligência Artificial é uma relação de tríade entre três algoritmos diferentes que nos permitem crescer em Inteligência. O LIZARD 120 pode aprimorar o código-fonte de um algoritmo, entendendo a finalidade do código, inclusive ele mesmo na Etapa 5002. O I2GE 122 pode emular gerações de iterações de programas virtuais, selecionando assim a versão mais forte do programa. Portanto, essa tecnologia de emulação beneficia todos os outros módulos que participam do processo SRIA. O BCHAIN é
Petição 870200056145, de 06/05/2020, pág. 272/1737
270/754 uma vasta rede 110 de nós caoticamente conectados 786 que pode executar programas complexos de dados pesados (Appchains 836) de maneira descentralizada. O SPSI 130 mantém as mesmas Appchains 836 que lhe conferem funcionalidade e recursos. O design do sistema baseado em loop de feedback garante que o progresso gradual na resolução de problemas de Inteligência Artificial e nas habilidades cognitivas aumente. Portanto, o SPSI 130 se torna o elemento chave do sistema de crescimento da inteligência recursive conhecido como SRIA. O I2GE 122 fornece a Emulação Virtual 5000 para o LIZARD 120 e a Rede/Protocolo BCHAIN 110 794. A Emulação Virtual 5000 é quando o I2GE 122 executa o código da Appchain Objetivo 836 em um ambiente virtual hospedado na Rede BCHAIN 110. Portanto, BCHAIN 110 atua como um provedor de recursos de hospedagem 5010 para I2GE 122, LIZARD 120, LOM 132, CTMP 124, NC 1186 e I2CM 1188. A rede BCHAIN 110 que hospeda esses vários sistemas com sua inteligência adaptativa permite que eles sejam mais liberais e intensos em portanto, a execução de seus algoritmos de inteligência, causando um melhor entendimento da eficiência, produtividade e funcionalidade do sistema que finalmente beneficia a operação da rede BCHAIN 110/Protocolo 794. A agregação de registro 5012 ocorre para permitir que observadores humanos monitorem o progresso do crescimento da SRIA.
[683] A Fig. 449 mostra a teoria SRIA referente à descoberta de um novo Sistema de Status Quo 5026. O Status Quo 5026 representa genericamente a funcionalidade geral, eficiência e design de um sistema de destino. O LOM 132 é invocado pelo Aviso de Invocação de Princípios de Design (DPIP) para Produzir
Petição 870200056145, de 06/05/2020, pág. 273/1737
271/754
Princípios de Design do Sistema 5016 na Etapa 5014. Esses princípios 5016 foram produzidos através do progresso gradual da pesquisa feito pelo LOM 132 e ainda mais ativado por CKR e CTMP 124. Portanto, quaisquer alterações, adições ou exclusões dos Princípios 5016 são refletidas no refinamento do Status Quo na Etapa 5018. Esse refinamento 5018 é ativado pelo LIZARD 120, que converte os dados relevantes em um formato de finalidade que atua como o estágio intermediário crucial para executar com precisão as modificações do sistema. Posteriormente, o LIZARD 120 usa suas habilidades de programação para fazer modificações experimentais no Status Quo Refinado na Etapa 5020. Essas modificações são feitas com uma expectativa razoável de um resultado positivo que aumenta a funcionalidade, eficiência, segurança e estabilidade. No entanto, devido ao seu status desconhecido e experimental, o novo Status Quo é virtualizado e evoluído pelo I2GE 122 na Etapa 5022. Esse processo de estabilização também confirma a estabilidade das modificações de refinamento feitas pelo LIZARD 120 na Etapa 5018. Por Portanto, o Novo Status Quo é formado na etapa 5024, que fez com que o sistema de destino fosse atualizado de todas as maneiras possíveis. Portanto, o ciclo de inteligência foi redefinido e o potencial para o próximo ciclo estar disponível aumenta à medida que os algoritmos relevantes da Appchain descobrem novas informações, funcionalidades e técnicas.
[684] A Fig. 450 mostra a teoria SRIA referente ao agrupamento de inteligência. O CTMP 124 atua como o local central para retenção de inteligência, pois a inteligência dos algoritmos é gradualmente usurpada nos estágios 5032. O CTMP 1224 interpreta
Petição 870200056145, de 06/05/2020, pág. 274/1737
272/754 todas as decisões baseadas artificialmente tomadas por algoritmos da Appchain como LIZARD 120, LOM 132 e 122 e também recebe seus registros de processamento bruto que atuam como fatos objetivos sobre a decisão que está sendo tomada. Portanto, o CTMP 124 critica a decisão de um algoritmo Appchain de acordo com a inteligência de que 5032 foi usurpado anteriormente de vários algoritmos Appchain. Portanto, a inteligência agregada de vários algoritmos da Appchain é reciclada na Etapa 5028 . Qualquer inteligência coletada/agrupada eventualmente beneficia todos os algoritmos da Appchain que interagem com o CTMP 124 nos estágios 5030 .
[685] A Fig. 451 mostra a teoria SRIA referente ao feedback e influência do hardware, estrutura e funcionalidade. Um design de sistema ideal ocorre no Gerador de Sistemas de Destino Abstrato (ATSG) 5040 que, portanto, lista as esperadas funcionalidades do usuário 5042 necessárias para o sistema conceituai ideal. Portanto, a funcionalidade de usuário necessária 5042 está relacionada e informa a definição de nova funcionalidade de usuário 5044. A sintaxe da funcionalidade 5044 é herdada pela funcionalidade de aplicativo 5046, que por sua vez se torna uma camada de ativação Operação 5054 para a nova funcionalidade do usuário 5044.
[686] As Aplicações de Aprimoramento 504 6 são praticamente manifestadas no NAD 8052 do submódulo SPSI 130. O SPSI 130 é a manifestação prática geral do conceito SRIA de diferentes camadas de logística herdadas e ativadas umas às outras. Portanto, a principal prática de enfatizar a camada logística é melhorar o Código de Eficiência, Qualidade, Segurança
Petição 870200056145, de 06/05/2020, pág. 275/1737
273/754 e Estabilidade 5048. Um processo desse tipo 5048 é praticamente realizado pelo SPSI 130 por meio de sua Proteção da Segurança dos Submódulos da Appchain (ASH) 8044, Correção de Erros Inatos (IEC) 8050, Refinamento Automático da Appchain (A2R) 8040, Manutenção Automatizada da Appchain (A2M) 8042, Conformidade Regulatória da Appchain (ARC) 8046 e Análise de Unidade de Registro de Diagnóstico (DLUA) 8048. A qualidade de código aprimorada 5048 permite a operação 5054 da funcionalidade de aplicativo 5046, que por sua vez permite a 5054 nova funcionalidade do usuário 5044. Todos os aspectos mencionados acima do software são habilitados 5054 pela adaptação da estrutura 5050. Essa adaptação 5050 representa as alterações feitas na estrutura subjacente (por exemplo, sistema operacional, núcleo do sistema etc.) permitidas por aplicativos do Espaço do Usuário 5046, 5044 para Operar 5054. Esse tipo de adaptação da estrutura 5050 é praticamente realizado pelo Desenvolvimento de Quadros Aprimorado do SPSI (EFD) 130, portanto, as alterações de hardware são feitas de acordo com a sintaxe 5056 legada 5050, que, por sua vez, permite que a Estrutura 5050 e seu Espaço de Usuário 5046, 5044 Operem 5054. As Alterações de hardware 5052 podem ocorrer devido a ciclos típicos nas tendências de fabricação do setor ou por meio do Desenvolvimento Avançado de Hardware (EHD) 8056 do SPSI 130. Portanto, toda essa pilha de camadas representa um sistema funcional geral que tenta se tornar o sistema ideal que os servidores de funcionalidade de usuário necessária 5042, de acordo com ATSG 5040.
[687] A Fig. 452 mostra a teoria do SRIA em relação à
Petição 870200056145, de 06/05/2020, pág. 276/1737
274/754 inteligência 5060 'vazada' da interação do Usuário da UBEC 106 (ou Usuário Genérico 5068 para Operações Legadas) através de ciclos de vários níveis. O Ciclo de Longo Prazo 5062 representa os Princípios Orientadores em grande escala da Diretoria do SPSI 5070. Portanto, os recursos, metodologias e tendências do SPSI 130 são gradualmente relatados para uma base 5062 lenta e de longo prazo através do Humano 106, 5068 Interação LOM 132 e Desenvolvimento Indireto do SPSI (SID) 1190. O LOM 132 atua como gerente racional da funcionalidade do SPSI 130 e na elaboração da operação devido ao seu raciocínio objetivo, que é permitido pela chamada modular integrada do CTMP 124. Portanto, as alterações que ocorrem através do LOM 132 e do SID 1190 no ciclo de longo prazo 5062 acabam afetando e relatando 5060 ao ciclo de médio prazo 5064, que representa a operação prática e sustentada do SPSI 130. Portanto, todos os submódulos 8040, 8042, 8044, 8046, 8048, 8050, 8052, 8054, 8056 do SPSI 130 são gradualmente afetados pelos Princípios Orientadores da Diretoria do SPSI 5070. Por sua vez, a operação do SPSI 130 no Ciclo de Médio Prazo 5064 leva ao aprimoramento geral das Appchains que existem na Plataforma UBEC 100/Rede BCHAIN 110, bem como as Appchains/Programas Herdados que operam nos Sistemas Herdados por meio da Camada de Emulação da Appchain (AEL) 8058. Portanto, no Curto Prazo 5066, os ciclos de adaptação de inteligência são aprimorados pelo SPSI 130, que permite estratégias sofisticadas de adaptação implantadas no Curto Prazo 5066. Portanto, a Unidade de Implantação da Estratégia 916 executa uma Tarefas cruciais no Protocolo BCHAIN 794 são influenciadas pela operação do SPSI 130 e, portanto, pela operação do LOM 132 e SID 1190. O SPSI 130
Petição 870200056145, de 06/05/2020, pág. 277/1737
275/754 aprimora especificamente os módulos do Protocolo BCHAIN 794, como Adaptação à Estratégia Dinâmica (DSA) 772 e o Módulo de Criação de Estratégia (SCM) 984, que por sua vez produzem instâncias das Unidades de Implantação da Estratégia 916 nos gatilhos invocados pelo Setor de Transição de Eventos (SCEP) 3360. Essas 916 Unidades realizam inteligência adaptativa no Ciclo a Curto prazo 5066 na operação da rede BCHAIN 110.
[688] Autoprogramação de auto-inovação (SPSI)
[689] Auto Programação de Inovação Automática (SPSI)
[690] [00] Figs. 600 à Fig. 603 mostram uma visão geral da função principal do Módulo de autoprogramação de auto-inovação (SPSI) 130. O SPSI 130 é uma Appchain 836 que usa a tecnologia LIZARD 120 para programar outras 836 Appchains na plataforma 100 UBEC. Essa programação do SPSI 130 inclui refino, correção de bugs, manutenção programada, Análise da Unidade de Registros de Diagnóstico 1182, inovação de novos recursos etc. O SPSI 130 pode se programar e ainda receber elementos das Guias de Programação para Desenvolvimento Indireto do SPSI (SID) 1190. Os Usuários da UBEC 106 aprovados que testaram habilidades de programação/engenharia/arquitetura têm permissão para participar do LUIGI 116, desenvolver guias de programação e teoria de códigos como o SID 1190 (como opção). Isso leva a aprimoramentos induzidos por humanos para os recursos do SPSI 130 sem nunca receber acesso humano direto. O SPSI 130 é concedido, de acordo com o Protocolo BCHAIN permanente 794, que age como uma lei de base rudimentar, com acesso exclusivo para manipular o código base de todas as principais funções da Plataforma UBEC 100. Exemplos significativos são o próprio Aplicativo UBEC 118, LUIGI
Petição 870200056145, de 06/05/2020, pág. 278/1737
276/754
116, Criatividade 112, I2GE 122, SPSI 130 como tal (programação automática), LOM 132 (que é uma tecnologia central que alimenta o SPSI 130), LIZARD 120 (que é uma tecnologia central que alimenta o SPSI 130), CTMP 124, NMC 114, MC 1186 e I2CM 1188. Os modulas Appchain mencionados anteriormente que compõem o SPSI 130 também são mantidos pelo SPSI 130. O SPSI 130 mantém as Appchains 836 que concedem funcionalidade e recursos. O design do sistema de feedback de loop garante que as capacidades de progresso incrementai na resolução de problemas cognitivos e de IA sejam aumentadas. O SPSI 130 torna-se o elemento chave para o sistema de crescimento da inteligência recursive Inteligência Simbiótica Recursive Avançada (SRIA) mostrada nas Figs. 448 - 452 é o ápice da Inteligência Artificial (IA), que é uma relação triádica entre três algoritmos diferentes que permitem um ao outro crescer em Inteligência (LIZARD 120, I2GE 122 e BCHAIN 110) . O LIZARD 120 (Aumentando continuamente a inteligência de programação) pode melhorar o código fonte de um algoritmo, entendendo o objetivo do código, inclusive ele próprio. I2GE 122 (Continuamente aumentando a inteligência de emulação), pode emular gerações de iterações de programação virtual, selecionando, portanto, a versão mais forte do programa. O BCHAIN 110 (Continuamente aumentando a inteligência adaptativa) é uma vasta rede de nós conectados caoticamente que podem executar programas complexos pesados em dados de maneira descentralizada. O principal ímpeto por trás do SPSI 130 é ter um mecanismo para criar conhecimento ou inteligência benéficos automáticos com a sabedoria de aproveitar o bem e perdoar o mal (EGFE). O SPSI 130 lida muito com o conceito de Propósito, mostrado como Mapas de Hierarquia
Petição 870200056145, de 06/05/2020, pág. 279/1737
277/754 de Propósitos. 0 conceito de estrutura de finalidade se origina do LIZARD 120, baseia-se na função LIZARD 120 e aprimora-a para alcançar o SPSI. O Objetivo da Estrutura é essencialmente a justificativa por trás de qualquer tipo de sintaxe. Imagine uma definição sintática, como Tipo X, no Estado Y, com Métricas Z. As definições de objetivo se concentram no aspecto da justificação, como: Estado deve existir como Y, porque o Tipo X é necessário com Métricas Z em Estágio L. O objetivo pode ser bem entendido consultando o módulo C42 de Necessidade de Correspondência de Mapas (NMM), que novamente origina e opera sob o LIZARD 120, que é o principal manipulador de Objetivos do Módulo de Objetivos. C36 O LIZARD 120 é, portanto, a linha de base da autoprogramação, para a qual o SPSI 130 usa para executar tarefas mais elaboradas como uma segunda camada. Portanto, o SPSI faz referências pesadas ao LIZARD 120 e sua associação ao formato de finalidade. Módulos dedicados que operam no SPSI 130, como Processamento de simetria de objetivo a propósito (P2SP) 7000 e Processamento de realinhamento de propósito (PRP) 7050, são chamados para interpretar e manipular formatos de objetivo. O P2SP 7000 e PRP 7050 mostrado nas Figs. 443 - 447 fazem parte do Protocolo BCHAIN 794.
[691] Fig. 601 mostra mais detalhes sobre a operação interna do SPSI 130. O LOM 132 recebe a Unidade de Registro de Diagnóstico 1182 de seu submódulo (como uma Appchain 836) do Mecanismo de Investigação Automatizado (ARM) 134. O ARM 134 recebe unidades de registro 1182 da Submissão de registros de diagnóstico (DLS) 1160. O recebimento das unidades de registro 1182 leva ao estágio 8000; onde o LOM 132 caracteriza e entende
Petição 870200056145, de 06/05/2020, pág. 280/1737
278/754 as falhas de rotina com os Recursos Existentes Atualmente e propõe 8002 Soluções para eles. Tais Recursos Atualmente Existentes são recursos da Appchain 836 selecionado que foi alvo de programação/refinamento/inovação. Portanto, o estágio 8000 gera soluções propostas para o mau funcionamento das funções existentes 8006. No estágio 8000, o LOM 132 inspeciona minuciosamente a Appchain 836 selecionado e estima os novos recursos propostos com os quais espera melhorar a capacidade e a eficiência da Appchain 836 para executar sua função principal. Portanto, a Etapa 8000 tem como saída os Novos Recursos Propostos 8004. Na Etapa 8008, os Recursos Propostos 8004 e as Soluções Propostas 8006 são propositadamente definidos e transferidos para o LIZARD 120 para serem programados em códigos funcionais através do Objetivo e sintaxe.
[692] A Fig. 602 mostra mais detalhes sobre a operação interna do SPSI 130 na continuação da Fig. 601. Se possível, o LIZARD 120 gera os conjuntos de códigos executáveis 8010 na etapa 8012, que representam as idéias originalmente concebidas pela LOM 132 nas etapas 8000 e 8002. Posteriormente, no estágio 4376, os conjuntos de códigos executáveis 8018 são transferidos para o I2GE 122, juntamente com os cenários de execução bem-sucedidos 8014 e com falha na execução 8016 do LIZARD 120. Esses cenários 8014 e 8016 atuam como estruturas para Referência no caso de a execução do código relevante ter êxito 8014 ou 8016 com falha. A partir daí, o estágio 8020 I2GE evolui e ajusta (Sintonizado Através da Criatividade 112) o software em várias sequências evolutivas com o uso de recursos da CPU e Armazenamento disponível na rede BCHAIN 110. Consultando os cenários de
Petição 870200056145, de 06/05/2020, pág. 281/1737
279/754 execução bem-sucedidos 8014 e 8016 com falha, o I2GE 122 é capaz de distinguir variações de Codifique 8010 dos jogos que são, em última análise, estáveis e funcionais daqueles que não são. Posteriormente, no Estágio 8022, o LOM 132 verifica se o software resultante está de acordo com a estabilidade percebida e os meios para alcançar a funcionalidade. Portanto, o LOM 132 está verificando se o software resultante é consistente com as propostas originais 8004 e 8006.
[693] A Fig. 603 mostra um cenário alternativo para a Fig. 601, onde LOM 132 e LIZARD 120 recebem a Unidade de Registro de Diagnóstico 1182 de seu submódulo (como um Appchain 836) . Diagnóstico (DLS) 1160. O LOM 132 caracteriza e entende as falhas de rotina com as Funções Existentes Atualmente e propõe 8024 Soluções para elas. O LIZARD caracteriza e entende bugs/bugs técnicos e os corrige usando o módulo de iteração 8026.
[694] A Fig. 604 mostra as Appchains oficiais 836 interagindo entre si dentro de um ecossistema Appchain personalizado 6032. O SPSI 130 conta com o LOM 132, LIZARD 120 e I2GE 122 para operação. A criatividade 112 complementa o CTMP 124 e o LOM 132, embora o CTMP 124 complemente o LOM 132. Portanto, as Appchains 836 podem depender um do outro, mesmo que mantenham sua própria identidade e jurisdição na Plataforma UBEC 100 .
[695] A Fig. 605 mostra uma visão geral de vários submódulos que operam no Autoprogramação (SPSI) 130. O Refinamento Automático de Appchain (A2R) 8040 inspeciona as Appchains 836 e os Programas Legados para melhorar a eficiência de suas rotinas e melhorar sua usabilidade e confiabilidade. A
Petição 870200056145, de 06/05/2020, pág. 282/1737
280/754
Manutenção automatizada de Appchain (A2M) 8042 mantém a Appchain 836 selecionado ou o programa herdado, removendo os caches expirados 8725, atualizando os recursos depreciados 8726 para os recursos utilizáveis, atualizando os módulos obsoletos e as dependências 8727 com os módulos utilizáveis, removendo os pontos de referência expirados 8728 (conteúdo ausente etc.) e executando uma calibração de estabilidade econômica 8729. A Proteção da Segurança da Appchain (ASH) 8044 inspeciona automaticamente pontos de intrusão e os explora em um Appchain 836 ou Programa Legado. A Conformidade com os Regulamentos da Appchain (ARC) 8046 garante que a Appchain 836 ou Programa Legado selecionado esteja em conformidade com os vários regulamentos específicos (por exemplo, conformidade com a API REST etc.). A Análise de Unidade de Registro de Diagnóstico (DLUA) 8048 recebe as Unidades de Registro de Diagnóstico (DLU) de rotinas com problemas de funcionamento e promulga as disposições apropriadas para tentar corrigir esses problemas de funcionamento. A Correção de Erros Inatos (IEC) 8050 tenta corrigir falhas procedimentais fundamentais que podem levar ao desligamento de rotina. 0 Novo Desenvolvimento da Appchain (NAD) 8052 encontra usos para Aplicativos em um ecossistema de Aplicativos especificado (como a Plataforma UBEC 100) que não possui uma função de Aplicativo em potencial, o que beneficiaria significativamente esse ecossistema. O Desenvolvimento Aprimorado do Framework (EFD) 8054 inspeciona e potencialmente aprimora as estruturas de software existentes (como linguagens de programação) para os sistemas de rede e legados da Plataforma UBEC 100/BCHAIN 110. O 8056 Desenvolvimento Aprimorado de Hardware (EHD) modifica os sistemas
Petição 870200056145, de 06/05/2020, pág. 283/1737
281/754 físicos que contêm 8856 Placas Condutoras Líquidas Dinâmicas (DLCB) e, portanto, pode ter sua estrutura de hardware principal otimizada e atualizada. 0 8038 Mecanismo de Segmentação da Appchain (ATM) processa uma seleção de algoritmo inteligente que informa outros módulos que a Appchain 836 deve selecionar em seu processamento. O ATM 8038 reporta aos módulos A2R 8040, A2M 8042, ASH 8044, ARC 8046, DLUA 8048 e IEC 8050. Outros módulos possuem seu próprio mecanismo de seleção inato que difere logicamente do ATM 8038.
[696] As Figs. 606 - 609 mostram a operação do 8038 Mecanismo de Segmentação da Appchain (ATM), que é um submódulo do SPSI 130 que seleciona de forma inteligente as Appchains 836 relevantes para o processamento de submódulos específicos do SPSI 130 (módulos A2R 8040, A2M 8042, ASH 8044, ARC 8046, DLUA 8048 e IEC 8050).
[697] A Fig. 606 mostra o 8038 Mecanismo de Segmentação da Appchain (ATM) na Etapa 8064, determina se este ponto do ATM 8038 está sendo executado dentro da Camada de Emulação da Appchain (AEL) 8058 ou em um Nó de Mineração da Appchain de destino 8062. Se AEL 8066, na Etapa 8070, siga a Rotina de execução A 8074 com preferências de comportamento recebidas da Administração herdada 8076 e envie a Appchain Modular 8078 para segmentar a Appchain 6060. E se o Nó de mineração 8068 no estágio 8072, siga a rotina de execução B 8080 com o anúncio do novo bloco de trabalho resolvido 8082 e envia a Appchain como 8084 para a Appchain de destino 6060.
[698] A Fig. 607 mostra a operação do Mecanismo de Segmentação da Appchain (ATM) 8038 na Rotina de Execução A 8074.
Petição 870200056145, de 06/05/2020, pág. 284/1737
282/754
Na Etapa 8090, recebe Preferências de Comportamento 8088 da Administração herdada 8086. Os tipos de preferência de comportamento 8092 incluem: Modo de Desligamento 8094, Modo Manual 8096 e Modo Automático 8098. Para o Modo Desligamento 8094, nenhuma outra ação é tomada; portanto, o SPSI 130 fica inativo até que sejam feitas alterações na Preferência de comportamento do 8088 Herdado 8086 na Etapa 8100. No Modo Manual 8096, recupera a lista manual de Programas de Administração de Legado da Appchain 8086 Appchain para o Modo Automático 8098, na Etapa 8104, o Programa da Appchain/Legado é delegado à Seleção Automatizada de Programa (APS) 8102.
[699] A Fig. 608 continua a lógica da Fig. 607 para o Mecanismo de Segmentação da Appchain (ATM) 8038 na Rotina de Execução A 8074 na Etapa 8106, recupera a lista de manuais 8108 dos Programas de Administração de Legado da Appchain 8086. Na etapa 8110, um loop é confirmado na lista de programas ativos. Na Etapa 8112, o Programa da Appchain/Legado é delegado à Seleção de Programa Automatizada (APS) 8114 em uma Lista de Programas Automatizada 8116. Na Etapa 8118, o Programa Selecionado 8122 é enviado como uma saída modular para Direcionar a Appchain 6060 para o processamento do SPSI 130. Após a conclusão do processamento do SPSI 130, o próximo Programa disponível no Loop estará comprometido com a Etapa 8120.
[700] A Fig. 609 mostra a operação do 8038 Mecanismo de Segmentação da Appchain (ATM) para o Caminho de Execução B 8080 dentro do Nó de Mineração Appchain de Destino 8062. Na Etapa 8124, a Invocação Modular do ATM 8038 ocorre em uma Mineração de um a Appchain especificado, portanto, as funções do SPSI 130 são
Petição 870200056145, de 06/05/2020, pág. 285/1737
283/754 executadas para manipular as Appchains nos Nós de Mineração que os minam na Etapa 8126. 0 Anúncio de Novo Bloco de Trabalho Resolvido Extraia a identidade da Appchain na Etapa 8128. A Etapa 8130 Verifica a identidade da Appchain das atualizações da Metachain da Appchain. Se verificado 8132, recebe a Appchain completa da Metachain 8134 local e envia a Appchain como 8136 modular para a Appchain de destino 6060. Se verificado 8138, envie DLU com o token oficial do sistema 5600 para o DLS 1160.
[701] [00] Figs . 610 - 616 Refinamento Automático da
Appchain (A2R) 8040 .
[702] A Fig . 610 mostra o Refinamento Automatizado DA
Appchain (A2R) 8040 onde o LIZARD 120 interpreta a sintaxe do
Target 6060 Appchain através do Módulo Sintaxe na etapa 8138. Na etapa 8140, o LIZARD 120 produz um Mapa de hierarquia de finalidades 8142 de a Appchain Target 6060 através do Módulo de Propósito. No Estágio 8144, são extraídos os Princípios de Design de Código 8140 estabelecidos, que garantem maior eficiência da Retenção Central de Conhecimento (CKR) 648. O LIZARD 120 produz um Mapa de Finalidade da Hierarquia 8150 dos Princípios de Design de Código 8140 no Estágio 8148
[703] A Fig. 611 mostra os detalhes sobre a operação do LIZARD 120 para converter o Fluxo de Execução 556 da Appchain Target 6060, que foi selecionado pelo Mecanismo de Foco da Appchain (ATM) 8038, em um Mapa de Hierarquia de Finalidades 8142. O Fluxo de Execução 556 do App60 Target 6060 que é produzido pela Coleta de Fluxo de Execução (ESC) 6700 é enviado ao Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Externo
Petição 870200056145, de 06/05/2020, pág. 286/1737
284/754 (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código, recebe um Formato de Propósito Complexo C325 do Módulo de finalidade (PM) C36. 0 formato de finalidade complexa C325 é então escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. 0 Pseudocódigo contém implementações básicas de operações de computação que são mais comuns entre todas as linguagens de programação, como instruções Yes/No, while etc. Portanto, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação de destino desejada (linguagem de computação) . Para ler o código, 0 SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar uma finalidade para a funcionalidade desse código. A Appchain Objetivo 6060 é recebida em um formato de fluxo executado alcançado 8189 pela Tradução de Código C321. O Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pela SM C35 para Qualquer idioma de computação escolhido e conhecido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saída da execução concluída da Tradução de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz o código lógico a maneiras mais simples de produzir um mapa de funções interconectadas com as definições de Regras e Sintaxe da C322 . Portanto, ao concluir a execução da Redução Lógica C323, a execução do estágio SM C35 correspondente é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para
Petição 870200056145, de 06/05/2020, pág. 287/1737
285/754 derivar uma finalidade no C325 Formato de Finalidade complexa do Código do computador. Essa definição de finalidade descreve adequadamente a função desejada da seção de código relevante, conforme interpretada por SM C35. 0 PM C36 também pode detectar trechos de código secretamente incorporados aos dados (binários/ASCII etc.). A Interpretação Iterative C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325) ao se referir à Associação de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção automatizada/programação automática e é direta e exclusivamente programada por especialistas na área relevante. O elemento Gerenciamento de código principal do IC C333 do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade geral do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do sistema C336 IC C333 define os objetivos de segurança e de política da empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[704] A Fig. 612 continua o fluxo lógico da Fig. 611 para ilustrar a operação do LIZARD 120 para converter a Appchain Objetivo 6060 em um Mapa de hierarquia de finalidades 8142. A Redução Lógica C323 do Módulo de sintaxe (SM) C35 envia sua saída para o Interpretação Iterative C328 do Módulo de Propósito (PM)
Petição 870200056145, de 06/05/2020, pág. 288/1737
286/754
C36. A Interpretação Iterative C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada, consultando a Associação de Propósito C326. A saída da definição de finalidade existe no Formato de Propósito Complexo C325, que é enviado como uma saída modular para PM C36 e, portanto, o Núcleo Externo (OC) C329 e no LIZARD 120. A saída é rotulada como um Mapa de Hierarquia de Propósito 8142, que é apresentado como a versão Formato de Finalidade Complexa do C325 para a Appchain Objetivo 6060. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às funções e módulos mencionados acima.
[705] A Fig. 613 mostra detalhes sobre a operação do LIZARD 120 para converter os Princípios de Design de Código 8146 que foram convertidos de Retenção Central de Conhecimento (CKR) 648 em um Mapa de Hierarquia de Propósitos 8150. Os Princípios de Design de Código 8146 são enviados ao módulo de sintaxe (SM) C35, que pertence à jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código, recebe um Formulário de finalidade complexa C325 do Módulo de finalidade (PM) C36. O Formato de Finalidade Complexa C325 é então escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de computação que são mais comuns entre todas as linguagens de programação, como instruções Yes/No, While etc. Posteriormente, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação de destino desejada (linguagem de computação) . Para leitura de código, o SM C35
Petição 870200056145, de 06/05/2020, pág. 289/1737
287/754 fornece uma interpretação sintática do Código de Computação do PM C36 para derivar uma finalidade para a funcionalidade desse código. A Appchain Objetivo 6060 é recebida no formato do Principio da sintaxe 8147 pelo Tradução de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pela SM C35 para qualquer idioma de computação escolhido e conhecido. A Conversão de Código C321 também executa a função inversa de converter códigos de computação conhecidos em tipos de sintaxe arbitrários. A saída da execução completa da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe da C322. Portanto, após a conclusão da execução da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para derivar uma finalidade no Formato de Finalidade Complexa C325 do Código do Computador. Essa definição de finalidade descreve adequadamente a funcionalidade desejada da seção de código relevante, conforme interpretada por SM C35. O PM C36 também pode detectar trechos de código secretamente incorporados aos dados (binários/ASCII etc.) . A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325) ao se referir à Associação de Propósito C326. O Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por
Petição 870200056145, de 06/05/2020, pág. 290/1737
288/754 manutenção/autoprogramação automatizada e é direta e exclusivamente programada por especialistas na área relevante. 0 elemento C335 do Código Principal do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade geral do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. Os elementos dos Objetivos do Sistema IC C333 C336 definem os Objetivos de Política de Segurança e Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[706] A Fig. 614 continua o fluxo lógico da Fig. 613 para ilustrar a operação do LIZARD 120 para converter os Princípios de Design de Código 8146 em um Mapa de Hierarquia de Propósito 8150. A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua Saída C328 da Interpretação Iterativa do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade ao se referir à Associação de Propósitos C326. A saída de definição de finalidade existe no Formato de Finalidade Complexa C325, que é enviado como uma saída modular para PM C36 e, portanto o Núcleo externo (OC) C329 e, LIZARD 120. A saída é marcada como um Mapa de Hierarquia de Propósito 8150, apresentado como a versão do Formato de Finalidade Complexa C325 dos Princípios de Design de Código 8146. A mesma definição e aplicação do Núcleo Interno (IC) C333 aplicava-se às funções e
Petição 870200056145, de 06/05/2020, pág. 291/1737
289/754 módulos já mencionados.
[707] Fig. 615 O Refinamento Automático de Appchain (A2R) 8040 inspeciona as Appchains 836 e os Programas Legados para melhorar a eficiência de suas rotinas e melhorar sua usabilidade e confiabilidade. Os Princípios de Design de Código 8146 e o ESC (67) de Execução de Coleta de Fluxo (ESC) 6700 no Mapa de Hierarquia de Propósito 8150 e no Mapa de Hierarquia de Objetivo 8142, respectivamente, são enviados ao P2SP 7000. O resultado do processamento de simetria 8152 determina no Etapa 8154 se o Código de finalidade da Appchain de destino concordar com os Princípios de design de código em sua totalidade e corresponde ao refinamento 8156 não necessário e execute o módulo finalizado. No entanto, se 8158 não corresponder, o Mapa de Hierarquia de Objetos 6060 da Appchain será ajustado para corresponder ao Mapa 8146 dos Princípios de Design com os resultados enviados para a Afinidade Mestre/Escravo 1480 e PRP 7050, que produz o Mapa Acionado por finalidade 8162.
[708] A Fig. 616 continua o fluxo lógico da Fig. 615 para ilustrar a operação do LIZARD 129 para converter o Mapa de finalidade aprimorada em sintaxe da Appchain 8164. A Appchain 6262 atualizada é enviada ao Conjunto de Patches de Implantação (DPA) 6260 para produzir o Patch de correção 6270 da Appchain implementado no Construtor de Ecossistemas da Customchain (CEB) 584, que manipula a Appchain Objetivo Target 6060 para converter seu conteúdo na Appchain atualizado 6262.
[709] A Fig. 617 mostra detalhes sobre a operação do LIZARD 120 para converter o Mapa de Finalidade Avançada 8162 em um Appchain Atualizado 6262 (mostrado sendo concluído na Fig.
Petição 870200056145, de 06/05/2020, pág. 292/1737
290/754
618) . A coleção de finalidade instrucional 9462 existe no formato de finalidade complexa C325 e é enviada para a expansão iterativa C327 do módulo de finalidade C36 no Núcleo Externo (OC) C329 do LIZARD 120. A expansão iterativa C327 adiciona detalhes e complexidade para evoluir um objetivo simples (definido indiretamente no Objetivo de Substituição 8258) em uma definição especifica de propósito complexo. Portanto, a associação de finalidade C326 potencial máxima da entrada é feita e mantida como um formato de finalidade complexa C325, antes de ser enviada para a derivação lógica C320 do módulo de sintaxe (SM) C35. O elemento de código principal C335 do IC Interno (C) C333 contém sistemas de estrutura e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e gerenciamento de sistemas de memória. Portanto, o código principal C335 permite operação e funcionalidade gerais para o SM C35 e PM C36, fornecendo bibliotecas e scripts padrão que permitem a funcionalidade básica. Os elementos dos Objetivos do Sistema 0336 do IC 0333 definem Metas de Segurança e Políticas de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[710] A Fig. 618 continua o fluxo lógico da Fig. 617 para ilustrar a operação do LIZARD 120 para converter o Mapa de finalidade aprimorada 8162 (mostrado na Fig. 617) para uma Appchain 6262 atualizada. Os dados de entrada são recebidos no formato de Objetivo complexo 0325 do Módulo de propósito geral (PM) 036 e transfira para Derivação lógica 0320 do Módulo de sintaxe (SM) 035. A derivação lógica 0320 deriva logicamente as
Petição 870200056145, de 06/05/2020, pág. 293/1737
291/754 funções necessárias de funções inicialmente mais simples. Isso significa que se uma função pode ser formada como uma função derivada devido à implicação de uma função pai mais simples; então é formado pela derivação lógica C320. A saída produzida é uma árvore de dependências de funções que são construídas de acordo com os dados definidos no Formato de Finalidade Complexa C325. A Derivação Lógica C320 opera de acordo com as definições das Regras e Sintaxe C322 que são adquiridas do elemento do Código Principal C335 do Núcleo Interno (IC) C333. A derivação lógica C320 envia sua saída para a Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pela SM C35 para qualquer idioma de computação escolhido e conhecido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computação conhecidas em tipos de sintaxe arbitrários. Portanto, o PM C36 aplica o SM C35 para produzir a versão da Appchain de Sintaxe resultante da entrada do Mapa de Finalidade Aprimorada 8162 pela Conversão de Código C321. A Appchain Atualizada 6262 resultante, que é finalmente produzido pela Conversão de Código C321, é a saída modular do SM C35, Núcleo Externo (OC) C329 e LIZARD 120.
[711] [00] Figs. 619 - 652 mostram a operação e a funcionalidade da Correção de Erros Inatos (IEC) 8050, que é um submódulo de Auto-Inovação em Autoprogramação (SPSI) 130 que tenta corrigir falhas do procedimento fundamental que pode levar a uma parada de rotina.
[712] A Fig. 619 mostra a operação e a funcionalidade da Correção de erros inatos (IEC) 8050, que é um submódulo do
Petição 870200056145, de 06/05/2020, pág. 294/1737
292/754
SPSI 130. O Mecanismo de segmentação da Appchain (ATM) 8038 seleciona uma Appchain de destino 6060 especifico que é enviado como um Entrada Modular para um gabinete 6700 de Coleta de Fluxo de Execução (ESC). O Fluxo de Execução que é produzido como uma saida modular do gabinete ESC 67 00 é enviado como uma entrada modular para o estágio 8170 da IEC 8050. O estágio 8170 separa o fluxo de execução da Appchain 836 para produzir o modelo de estrutura código 8172. Na Etapa 8174, cada Unidade de Código Selecionada 8188 que existe no Modelo de Estrutura de Código 8174 circula por um Loop de programação. Portanto, na Etapa 8178, o LIZARD 120 é aplicado para produzir um Mapa de Hierarquia de Propósito 8180 da Unidade de Código Selecionada. Na Etapa 8176, o LIZARD 120 é aplicado para produzir um Mapa de Hierarquia de Propósito 8182 da Estrutura de Modelo do Código 8176 completa. Portanto, o Mapa de Hierarquia de Propósito 8180 e 8182 são enviados como uma entrada modular para o módulo 7000 de Processamento de Simetria de Objetivo a Objetivo (P2SP). Na conclusão do processamento do P2SP 7000, o Resultado do Processamento é Produzido pela Simetria 8184 como a saida modular. Portanto, é executada a Etapa 8186, que executa consistência interna interpretando o Resultado de processamento de simetria 8184 para avaliar se cada um dos mapas de hierarquia de finalidades 8180 das unidades de código selecionadas se encaixam na finalidade maior (Mapa de Hierarquia de Propósito 8182) da Estrutura Modelo completa do Código 8172.
[713] A Fig. 620 mostra os detalhes sobre a operação do LIZARD 120 para converter a Unidade de Código Selecionada 8188
Petição 870200056145, de 06/05/2020, pág. 295/1737
293/754 em um Mapa de Hierarquia de Finalidade 8180 (mostrado na Fig. 621). A Unidade de Código Selecionada 8188 é enviada ao Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Externo (OC) C329. 0 SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever o código; recebe um Formulário de finalidade complexa C325 do Módulo de finalidade (PM) C36. O Formato de Finalidade Complexa C325 é então escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O Pseudocódigo contém implementações básicas de operações de computação que são mais comuns entre todas as linguagens de programação, como instruções Yes/No, While, etc. Portanto, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação de destino desejada (linguagem de computação). Para ler o código; o SM C35 fornece uma interpretação sintática do código de computação do PM C36 para derivar uma finalidade para a funcionalidade desse código. A Unidade de Código Selecionada 8188 é recebida no formato do Fluxo de Execução Concluído 8189 pelo Conversão de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pela SM C35 em qualquer linguagem de computação escolhida e conhecida. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saída da execução completa da Tradução de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica do C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições das Regras e Sintaxe do C322. Portanto,
Petição 870200056145, de 06/05/2020, pág. 296/1737
294/754 na execução concluída da Redução Lógica C323, a execução do caso SM C35 correspondente é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterative C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma finalidade no formato de finalidade complexa C325 do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade desejada da seção de código relevante, conforme interpretada por SM C35. 0 PM C36 também pode detectar trechos de código secretamente incorporados aos dados (binários/ASCII etc.) . A Interpretação Iterative C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada no Formato de Propósito Complexo (C325) ao se referir à Associação de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção/autoprogramação automatizada e é direta e exclusivamente programada por especialistas na área relevante. O elemento de código principal C335 do IC C333 contém sistemas de estrutura e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e gerenciamento de memória. Portanto, o Código do Núcleo C335 permite operação e funcionalidade gerais para o C35 e o PM C36, fornecendo bibliotecas e scripts padrão que permitem a funcionalidade básica. Os elementos objetivos do sistema C336 do IC C333 definem metas de segurança e políticas comerciais. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[714] A Fig. 621 continua o fluxo lógico da Fig. 620
Petição 870200056145, de 06/05/2020, pág. 297/1737
295/754 para ilustrar a operação do LIZARD 120 para converter a Unidade de Código Selecionada 8188 no Mapa de Hierarquia de Propósito 8180. A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saida à Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada, consultando a Associação de Propósito C326. A saida de definição de finalidade existe em um formato de finalidade complexa C325, que é enviada como uma saida modular para o PM C36 e o núcleo externo (OC) C329 e, portanto, o LIZARD 120. A saida é rotulada como um Mapa de Hierarquia de Finalidade 13242, apresentado como a versão do Formato de finalidade complexa C325 do Padrão Neural Assumido 13238. A mesma definição e aplicação do Núcleo Interno C333 (IC) se aplica às funções e módulos mencionados acima.
[715] A Fig. 622 mostra detalhes sobre a operação do LIZARD 120 para converter o Modelo de Estrutura Código 8172 em um Mapa de Hierarquia de Propósitos 8182. O Modelo de Estrutura Código 8172 é enviado ao Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código; recebe um Formato de Propósito Complexo C325 do Módulo de finalidade (PM) C36. O Formato de Finalidade Complexa C325 é então escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de computação que são mais comuns entre linguagens de programação, como instruções Yes/No, loops, etc. Portanto, uma função auxiliar converte o pseudocódigo
Petição 870200056145, de 06/05/2020, pág. 298/1737
296/754 em código executável real, dependendo da sintaxe de computação de destino desejada (linguagem de computação) . Para ler o código; o SM C35 fornece uma interpretação sintática do código de computação do PM C36 para derivar uma finalidade para a funcionalidade desse código. A estrutura do modelo do código 8172 é recebida no formato de Vários Fluxos de Execução 5626 pela Conversão do Código C321. A Conversão do Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pelo SM C35 em qualquer linguagem de computação escolhida e conhecida. A Conversão do Código C321 também executa a função inversa de traduzir linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saída da execução completa da Conversão do Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, na execução concluída da Redução Lógica C323, a execução do caso SM C35 correspondente é concluída e a saída do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma finalidade no formato de finalidade complexa C325 do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade desejada da seção de código relevante, conforme interpretada por SM C35. 0 PM C36 também pode detectar trechos de código secretamente incorporados aos dados (binários/ASCII etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada no Formato de Propósito Complexo (C325) ao se referir à Associação de Propósito
Petição 870200056145, de 06/05/2020, pág. 299/1737
297/754
C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção autoprogramação automatizada e é direta e exclusivamente programada por especialistas na área relevante. O elemento C335 do Código principal do IC C333 contém sistemas de estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade geral do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. Os elementos dos Objetivos do Sistema C336 do IC C333 definem Metas de Segurança e Políticas de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[716] A Fig. 623 continua o fluxo lógico da Fig. 622 para ilustrar a operação do LIZARD 120 para converter o Modelo de Estrutura de Código 8172 no Mapa de Hierarquia de Propósitos 8182. A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua Saia para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada, consultando a Associação de Propósito C326. A saída de definição de finalidade existe em um formato de finalidade complexa C325, que é enviada como uma saída modular para o PM C36 e, portanto, o núcleo externo (OC) C329 e, portanto, o LIZARD 120. A saída é rotulada como um Mapa de Hierarquia de Propósito 8182 que é apresentado como a versão do Formato de Finalidade Complexa C325 do Modelo de Estrutura de Código 8172.
Petição 870200056145, de 06/05/2020, pág. 300/1737
298/754
A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às funções e módulos mencionados acima.
[717] A Fig. 624 expande os detalhes operacionais do Estágio 8170 a partir da Correção de Erros Inatos (IEC) 8050. O Estágio 8170 separa o fluxo de execução 556 da Appchain de destino 6060. Portanto, uma vez que a Coleção de Fluxo de Execução (ESC) enviou o Fluxo de Execução 556 como uma entrada modular para o Estágio IEC 8050 8170, o Fluxo 556 é enviado como uma entrada modular para o Estágio 8190. O Estágio 8190 aplica a Renderização de Fluxo de Execução 6400 para interpretar e construir, portanto, dependências relevantes das Appchains Suplementares 836 produzindo o Fluxo de Execução Cumprido 8192. O Fluxo 8192 é enviado como uma entrada modular para a Etapa 8194, onde circula através de cada Segmento de Execução Cumprida 551 do Fluxo de Execução cumprida 8192/556.
[718] A Fig. 625 continua o Fluxo Lógico da Etapa 8170 da Correção de Erro Inato (IEC) 8050. O Fluxo de Execução Realizado 8192 é enviado como uma entrada modular para a Etapa 8194, que inicia o loop da Fig. 624. Na Etapa 8196, o segmento de execução compatível selecionado 551 é isolado e armazenado no Grupo de Buffer da Unidade de Código (CUBP) 8198, mantendo (com metadados) seu contexto relacionai a partir do Fluxo de Execução Compatível 556. A entrada 8202 interpreta se qualquer segmento de execução compatível com 551 não processado permanecer no loop iniciado na Etapa 8194. Se a resposta à Entrada 8202 for Sim 8204, será acionada a Etapa 8206, que avançará o Loop da Etapa 8194 para a próxima Segmento de execução concluído 551 disponível. Se a resposta à Entrada 8202 for No 8208, a Etapa
Petição 870200056145, de 06/05/2020, pág. 301/1737
299/754
8200 será ativada, aplicando o LIZARD 120 para cobrir todo o conteúdo do CUBP 8198 em um Mapa de Hierarquia de Finalidade 8210 .
[719] A Fig. 626 mostra detalhes sobre a operação do LIZARD 120 para converter o Grupo de Tampão de Unidade de Código (CUBP) 8198 no Mapa de Hierarquia de Finalidade 8210. O CUBP 8198 é enviado ao Módulo de Sintaxe (SM) C35 em que pertence à jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código; recebe um Formato de Propósito Complexo C325 do Módulo de finalidade (PM) C36. O C325 Formato de Finalidade Complexa é então escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O Pseudocódigo contém implementações básicas de operações de computação que são mais comuns entre todas as linguagens de programação, como instruções Yes/No, while, etc. Portanto, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação de destino desejada (linguagem de computação). Para ler o código; o SM C35 fornece uma interpretação sintática do código de computação do PM C36 para derivar uma finalidade para a funcionalidade desse código. O CUBP 8198 é recebido no formato de segmentos de execução 5628 pela Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pelo SM C35 em qualquer linguagem de computação escolhida e conhecida. A Conversão de Código C321 também executa a função inversa de traduzir linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saída da execução completa da Conversão de Código C321 é transferida
Petição 870200056145, de 06/05/2020, pág. 302/1737
300/754 como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa e funções interconectadas, de acordo com as definições das Regras e Sintaxe do C322. Portanto, após a conclusão da Redução Lógica C323, a execução do caso SM C35 correspondente é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para derivar uma finalidade no Formato de Finalidade Complexa C325 de um código de computador. Essa definição de finalidade descreve adequadamente a funcionalidade desejada da seção de código relevante, conforme interpretada por SM C35. O PM C36 também pode detectar trechos de código secretamente incorporados aos dados (binários/ASCII etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada no Formato de Propósito Complexo (C325) ao se referir à Associação de Propósito C326. O Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção/autoprogramação automatizada e é direta e exclusivamente programada por especialistas na área relevante. O Elemento de Código Principal C335 do IC C333 contém sistemas de estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade geral do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. Os elementos dos Objetivos do Sistema C336 do IC C333 definem os Objetivos de Política de
Petição 870200056145, de 06/05/2020, pág. 303/1737
301/754
Segurança e Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[720] A Fig. 627 continua o fluxo lógico da Fig. 626 para ilustrar a operação do LIZARD 120 para converter o Grupo de buffer da unidade de código (CUBP) 8198 em um Mapa de Hierarquia de Finalidades 8210. A redução lógica C323 do módulo de sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do
Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada, consultando a Associação de Propósito C326. A saída de definição de finalidade existe em um formato de finalidade complexa C325, que é enviado como uma saída modular para PM C36 e, portanto, para o Núcleo Externo (OC) C329 e, portanto, para o LIZARD 120. A saída é identificada como um mapa de hierarquia de Finalidades 8210, apresentado como a versão C3P do formato de finalidades complexa C3P do CUBP 8198. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às funções e módulos mencionados acima.
[721] A Fig. 628 continua o Fluxo lógico da Correção de Erro Inato (IEC) 8050. O Grupo de Tampão da Unidade de Código (CUBP) 8198 é Processado em um Loop (de cada Unidade de Código em potencial) na Etapa 8212. O Mapa de Hierarquia de Propósito do Grupo de Tampões da Unidade de Código 8210 (CUBP) 8198 e o Mapa de Hierarquia de Propósito da Unidade de Código 8148 8188 são enviados para o Processamento de Simetria de Propósito para Propósito (P2SP) 7000, produzindo portanto, o resultado do processamento de simetria 8216. A etapa 8218 realiza uma
Petição 870200056145, de 06/05/2020, pág. 304/1737
302/754 verificação de consistência interna para avaliar se o Mapa de Hierarquia de Propósito 8214 da Unidade de Código Selecionado 8188 está alinhado com o objetivo maior do Mapa de Hierarquia de Propósito (8210) do código de estrutura contido no CUBP 8189. Portanto, na etapa 8220, qualquer unidade de código desalinhado 8188 que não tenha uma finalidade alinhada com a estrutura de código (CUBP 8198) inteiro está marcado. Portanto, o estágio 8220 envia sua saída modular para a retenção de finalidade de unidade de código.
[722] Na Etapa 8224, cada Finalidade de Unidade de Código Desalinhado é iterada em um novo Loop para derivar uma finalidade adequada para cada Unidade que esteja em conformidade com o Mapa de Hierarquia de Finalidade 8182 do Modelo de Estrutura de Código 8172. O processo de derivação de uma finalidade adequada na Etapa 8224 é processado pela Substituição de Propósito Adequado (SPR) 8252.
[723] A Fig. 629 desenvolve detalhes das operações referentes às Etapas 8218 e 8220 da IEC 8050. A saída modular da caixa modular do caso de processamento de simetria de objetivo a objetivo (P2SP) 7000 é o resultado do processamento de simetria 8216. O resultado é enviado como uma entrada modular para a Etapa 8288 do resultado do módulo 8226 da Validação de Processamento de Simetria (SPRV) . A Etapa 8228 separa cada instância do resultado 7040 da Detecção de Integração de Alinhamento (AID) (gerada a partir da lógica interna do P2SP 7000) armazenada no resultado de processamento de simetria 8216. Posteriormente, a etapa 8230 aplica um loop para cada resultado do caso do AID 7040. A entrada interna do loop 8232 interpreta se o resultado
Petição 870200056145, de 06/05/2020, pág. 305/1737
303/754 do AID 7040 selecionado é considerado desalinhado de acordo com o resultado de processamento de simetria 8232. Se a resposta à entrada 8232 for de que não está desalinhada, a etapa 8234 será ativada e avança o loop para o próximo resultado do AID 7040. Se a resposta à Entrada 8232 for Sim, desalinhado 8236, será ativada a Etapa 8238, que gera o resultado do AID 7040 selecionado como Unidade de Código como uma saída modular para o SPRV 8226. Essa saída ele é enviado para a Etapa 8222, que marca a Unidade de Código Desalinhada quando armazenada na Unidade de Código Desalinhada (MCUPR) 8224. Portanto, a execução do módulo PSRV 8226 marca todas as Unidades de Código desalinhadas após a validação. Resultado do Processamento de Simetria 8216.
[724] A Fig. 630 continua o fluxo lógico da IEC 8050 a partir da Etapa 8224. A Etapa 8224 percorre cada Objetivo de Unidade de Código Desalinhado e deriva uma finalidade adequada através da Substituição de Propósito Adequado (SPR) 8252 que está em conformidade com o Mapa 8182 da Hierarquia de Finalidade do Modelo de Estrutura de Código 8172. Na Etapa 8240, o LIZARD 120 é aplicado para converter a Substituição de Finalidade produzida pelo caso SPR 8252 correspondente nos Segmentos de Execução 551. Isso leva à ativação do Palco 8242, que associa cada unidade de substituição de sintaxe ao seu site relevante no modelo de estrutura de código 8172. A partir daí, a etapa 8244 cria um patch de implantação 6270 por meio da invocação do módulo Patch Assembly. Deployment (DPA) 6260. Esse patch 6270 contém as unidades de substituição de sintaxe e as instruções pelas quais parte da Appchain 836 original eles devem substituir.
[725] A Fig. 631 continua o fluxo lógico da IEC 8050 da
Petição 870200056145, de 06/05/2020, pág. 306/1737
304/754
Etapa 8240, que aplica o LIZARD 120 para converter a substituição de finalidades em segmentos de execução 551, produzindo e enviando os resultados para a retenção de unidade de substituição de sintaxe (SRUR) 8246. A etapa 8242 associa cada unidade de substituição de sintaxe ao seu lugar correspondente no modelo de estrutura de código 8172. A etapa 8242 consegue isso aplicando o módulo 8248 da Pesquisa de Modelo de Unidade (UBL). O módulo 8248 da UBL produz sua saída no módulo de Estrutura de código Processamento de Linha CSS50 8250, que fixa os dados de entrada em uma saída da Appchain Atualizada 6262. Portanto, o CSSP 8250 aplica a Etapa 8244, que cria um Patch de Implantação que contém as unidades de substituição de sintaxe e as instruções para qual parte da Appchain 836 serão substituídas.
[726] A Fig. 632 mostra a operação e a funcionalidade do módulo DE Substituição de Propósito Específico (SPR) 8252 com referência à etapa 8224 de chamada como parte do módulo lógico interno de correção de erros inatos (IEC) 8050. O módulo de retenção de Propósito A da Unidade de Código Desalinhada (MCUPR) 8224 é enviado como uma entrada modular para a Etapa 8254 do SPR 8252. A Etapa 8254 inicia um Loop através de cada Unidade de Código Desalinhada DE Finalidade MCUPR 8224. Na Etapa 8256, aplica-se o LOM 132 para produzir uma Substituição de Objetivo 8258, para a Unidade de Código Desalinhado Selecionada, que é consistente e compatível com o Modelo de Estrutura do Código 8260. Portanto, o Modelo de Estrutura do Código 8172 é modificado para conter o Código de Substituição da Finalidade 8258, formando assim o Modelo 8260 mais preciso. A Substituição da Finalidade Individual no Loop 8258 aplicada pela Etapa 8254 é enviada para
Petição 870200056145, de 06/05/2020, pág. 307/1737
305/754 a Etapa 8240 para ser processada pelo LIZARD 120. Na etapa 8240, o LIZARD 120 é chamado para converter a Substituição de Propósito em Segmentos de Execução 556.
[727] A Fig. 633 mostra o procedimento operacional interno do LOM 132 e do CTMP 124 com referência à Etapa 8256 da Substituição de propósito especifico (SPR) 8252. O modelo de estrutura de código 8260, a unidade de código desalinhado 8264 e os Princípios de Design de Conformidade 8262 são fornecidos como uma entrada inicial para a Entrada de chamada de substituição (RIP) 8266. O RIP 8266 produz uma entrada 8268 que interage diretamente com o LOM 132 para aplicar a saída da Substituição de finalidade 8258, levando em consideração os critérios de entrada do Modelo de estrutura do Código 8260, Unidade de Código Desalinhada 8264 e Princípios de Projeto de Conformidade 8262. A entrada 8268 produzida pelo RIP 8266 é enviada para o módulo de Raciocínio de Consulta Inicial (IQR) C802A do LOM 132. Quando o LOM 132 é aplicado diretamente na plataforma UBEC 100 por um Usuário da UBEC 106, o IQR C802A recebe a pergunta/declaração fornecida pelo Usuário da UBEC 106. No entanto, este caso LOM 132 é automaticamente invocada pelo RIP 8266. A entrada 8268 fornecida é analisada através da invocação da Retenção Central de Conhecimento (CKR) 648 para decifrar os Detalhes ausentes da entrada 8268 que são cruciais para concluir o 'entendimento virtual' por LOM 132 para que o LOM 132 atenda/responda totalmente à entrada 8268. Os Detalhes ausentes resultantes produzidos pelo IQR C802A são enviados como entrada modular para o Clarificação de Pesquisa (SC) C803A. O SC C803A se envolve com
Petição 870200056145, de 06/05/2020, pág. 308/1737
306/754 a origem da entrada 8268 para obter informações suplementares, para que a entrada 8268 possa ser analisada objetivamente e em todo o contexto necessário. Quando o LOM 132 é aplicado diretamente na Plataforma UBEC 100 por um Usuário da UBEC 106, o SC C803A se compromete com esse Usuário 106 como a origem da pergunta/resposta. No entanto, esse caso do LOM 132 é automaticamente aplicado em vez do RIP 8266, portanto, o SC C803A se compromete com o RIP 8266 para obter informações adicionais sobre a Entrada 8268. É produzida a versão totalmente formada e refinada da Entrada 8268 do SC C803A e é enviado como uma entrada modular para a Construção da afirmação (AC) C808A. O AC C808A tenta formar uma resposta consistente à Entrada 8268 consultando a CKR 648 diretamente e também através do Mapeamento de Hierarquia (HM) C807A. O Apelo Racional (RA) C811A é um módulo de contêiner que hospeda uma interface de fluxo lógico com o CTMP 124. O RA C811A usa o CTMP 124 para criticar as Reivindicações. Tais criticas podem ter a forma de autocrítica ao criticar a saída do AC C808A ou críticas externas à origem da pergunta/declaração processada pelo IQR C802A (Usuário da UBEC 106 ou RIP 8266) . Se uma afirmação produzida pelo AC C808A falhar, uma quantidade significativa de avaliação de autocrítica processada pelo RA C811A; um novo caso do AC C808A é aplicado para dar conta de qualquer crítica válida. Se uma declaração altamente confiável for produzida pelo AC C808A que passa consistentemente nos testes de autocrítica processados pelo RA C811A; a asserção ocorre como uma saída modular do LOM 132, referenciada como Make-up de Decisão de Investimento 12404 no contexto da Entrada Inicial 8268 fornecida pelo RIP 8266.
Petição 870200056145, de 06/05/2020, pág. 309/1737
307/754
[728] A Fig. 634 mostra mais detalhes do procedimento de operação interna do LOM 132 de Apelo Racional (RA) C811A em relação ao CSE 12400 do Estágio 12402. A Declaração de Construção C808A (AC) fornece uma Resposta do Apelo Racional C843 (RA) C811A referente à afirmação produzida pela AC C808A em relação à entrada da entrada correspondente 8268. Nesse estágio do fluxo lógico, a asserção produzida é classificada como uma Decisão PréCrítica C847. Isso indica que ainda não foi processado através de criticas pelo CTMP 124. Portanto, a afirmação produzida é enviada diretamente ao caso do CTMP 124 como uma entrada do C848 Opinião subjetiva' e também à construção de contexto (CC) C817A, que fornece entrada C850 de Fato Objetivo para o caso CTMP 124. CC C817A refere-se aos metadados AC C808A e a evidência potencial fornecida pelo RIP 8266 para enviar fatos brutos ao CTMP 124 para o pensamento critico. Esses metadados de entrada são representados pelo arquivo Agregado de Registro de LOM 5502. O Agregado de Registro de LOM 5502 contém uma coleção de arquivos de Registro relevantes que são produzidos a partir das principais funções operacionais do LOM 132. Após a conclusão do caso do CTMP 124 em sua operação, uma Decisão Pós-Critica C851 é produzida como uma saída modular. A Decisão Pré-Criticada C847 inicial e a Decisão Pós-Criticada C851 são enviadas ao módulo de Comparação de Decisão (DC) C818A, que determina a extensão da sobreposição potencial entre as duas entradas C847 e C851. A saída unificada fornecida pelo DC 818A pode indicar uma concessão C852 124 do CTMP (imprecisão) por parte da instrução AC produzida C808A ou uma melhoria percebida C853 por parte da afirmação produzida AC C808A. As respostas aos argumentos C852 e C853 podem ser
Petição 870200056145, de 06/05/2020, pág. 310/1737
308/754 classificadas como Resultados de Baixa Confiança C845 ou Resultados de Alta Confiança C846. Um Resultado de Baixa Confiança C845 indica que a reivindicação original produzida pelo AC C808A é falha e deve ser reconstruída; portanto, o fluxo lógico continua para um novo caso do AC C808A. Um Resultado de Alta Confiança C846 indica que a declaração original produzida pela AC C808A tem mérito; portanto, as conclusões obtidas (juntamente com qualquer evidência correspondente, premissas etc.) são enviadas para a validação de conhecimento (KV) C805A. Portanto, o fluxo lógico continua para um novo caso do KV C805A, para que o CKR 846 e, portanto, o LOM 132 possa se beneficiar da reivindicação recém-processada.
[729] A Fig. 635 continua o fluxo lógico da Etapa 12402 do CSE 12400 para ilustrar a produção do arquivo Agregado do Registro de LOM 5502. As saídas modulares produzidas a partir do IQR (CQ), C802A, Clarificação de Pesquisa (SC) C803A, Construção de Afirmação (AC) C808A, Mapeamento de Hierarquia (HM) C807A e a Validação de Conhecimento (KV) C805A são enviadas para o módulo LOM (LMLC) 5500 do Coleção de Registro Modular. Portanto, o LMLC 5500 combina os dados de registro de Entrada em um único arquivo legível conhecido como Agregado de Registro de LOM 5502. O arquivo 5502 cobre o status operacional geral da instância LOM correspondentel32, fornecendo informações sobre como a instância LOM 132 chegou a várias conclusões. O Agregado do Registro de LOM 5502 é enviado ao CC do C817A Apelo Racional (RA) C811A.
[730] A Fig. 636 expande os detalhes operacionais referentes à Fig. 634 para ilustrar a operação interna do CTMP 124 em relação aos canais de entrada e saída definidos no Apelo
Petição 870200056145, de 06/05/2020, pág. 311/1737
309/754
Racional (RA) C811A. A Decisão Pré-Critica C847 é Apresentada C843 como uma saida modular da Construção de Afirmação (AC) C808A. A decisão C847 é então marcada como uma Opinião Subjetiva C848, cumprindo assim uma das duas entradas principais do CTMP 124. A Opinião Subjetiva C848 é enviada aos Metadados do Sistema de Entrada C484, que atuam como a principal entrada modular para CTMP 124 como uma representação interna do algoritmo de correspondência de padrões selecionados (SPMA) . Para este caso de configuração; o SPMA é LOM 132. Os metadados do sistema de entrada C484 são enviados para processamento no Motivo do Processamento C456 e Produção de Percepção Bruta (RP2) C465. O Processamento de Razões C456 entenderá logicamente as reivindicações feitas ao comparar atributos de propriedade. O RP2 C465 analisa os metadados do sistema de entrada LOM 132 C484 para produzir uma percepção no Formato de Percepção Complexa (PCF) que representa a percepção algorítmica do LOM 132. Essa percepção produzida é enviada para o Emulador de Observação de Percepção (POE) C475 que emula a percepção algorítmica do LOM 132. O Processamento de Razões C456 aplica o Processamento de Regras, que eventualmente produz conjuntos de regras que refletem o algoritmo SPMA, que neste caso é o LOM 132. Portanto, dois modos de 'pensamento' e percepção 'analógica' são executados no jogo de regras 'digital'. Esses dois ramos C461 e C475 representam semelhanças com intuição e lógica. Os resultados produzidos pelas Filiais C461 e C475 pensantes são transferidos para o CDO C462, que avalia qualquer elemento fundamental ou conflito ou corroboração entre os resultados. Encontrando uma grande magnitude de corroboração interna e uma baixa magnitude
Petição 870200056145, de 06/05/2020, pág. 312/1737
310/754 de conflito interno, o CTMP 124 fornece uma decisão binária de Aprovar ou Bloquear, referindo-se à Opinião Subjetiva de Entrada Inicial C848, que é referenciada como um Resultado de Alta Confiança C846. Se houver uma baixa magnitude de corroboração interna e uma alta magnitude de conflito interno, o CTMP 124 envia um 'voto de não confiança' que é referido como um Resultado de Baixa Confiança C845. Portanto, a saida resultante do CTMP 124 é considerada Decisão Pós-Criticada C851.
[731]A Fig. 637 mostra mais detalhes sobre a invocação da Produção de Percepção Bruta (RP2) C465 no CTMP 124. O LOM 132 produz a Substituição de Propósito 8258 aplicando a Construção de Afirmação (AC) C808A. A Substituição de Objetivo 8258 é então enviada para a Etapa 5506 do RP2 C465, que desembrulha os dados para produzir instâncias de um Rastreio de Depuração C485 e Rastreio do Algoritmo C486 nos Metadados do Sistema de Entrada C484, originários do caso de AC C808A correspondente. O rastreamento de depuração C485 é um rastreamento de nivel de codificação que oferece variáveis, funções, métodos e classes que são usadas juntamente com seus tipos de variáveis e o conteúdo de entrada e saida correspondente. A sequência de chamadas de função completa (rastreamento de função: funções chamando outras funções) é fornecida. O Rastreamento de Algoritmo C486 é um rastreamento em nivel de software que oferece dados de segurança emparelhados com a análise de algoritmos. A decisão de segurança resultante (aprovar/bloquear) é fornecida junto com um caminho logístico de como a Decisão C847 foi alcançada. O peso apropriado referente a cada fator que contribuiu para a Decisão C847 está incluído. A partir daí, o RP2 C465 transfere os dados referentes
Petição 870200056145, de 06/05/2020, pág. 313/1737
311/754 à percepção produzida pelo resultado do Emulador de Observação de Percepção (POE) 0475 para o processamento.
[732] A Fig. 638 executa a operação de produção bruta de percepção 0465 (RP2) no CTMP 124. Inicialmente, a Etapa 5506 ocorre, como na Fig. 1209, para desembrulhar os dados para produzir os casos de Acompanhamento e Acompanhamento de Depuração 0485. Algoritmo 0486 nos metadados do sistema de entrada 0484 que se originam do caso C808A correspondente. Na Etapa 5508, o Processamento Métrico 0489 faz engenharia reversa das variáveis do LOM 132 para extrair informações da inteligência artificial exibida pelo LOM 132. Portanto, os metadados do sistema de entrada 0484 são processados pela Etapa 5510, que separa 0484 Metadados em relacionamentos significativos de segurança de causa-efeito por meio da Separação de Metadados do Sistema 0487 (SMS) . Como também indicado na Fig. 1209, o RP2 C465 transfere os dados referentes à percepção produzida pelo resultado do Emulador de Observação de Percepção (POE) C475 para processamento.
[733] A Fig. 639 desenvolve a operação C475 do Emulador de Observação de Percepção (POE), inclui a relação da produção de percepção bruta (RP2) C465 com o armazenamento de percepção (PS) C478. A operação C489 do Processamento Métrico e C487 Separação de Metadados Do sistema (SMS) levam à produção das percepções 5512/5514/5516, que são armazenadas no PS C478. As percepções 5512/5514/5516 resultantes representam a resposta modular do LOM 132 à produção da Substituição de Propósito 8258 através da Construção de Afirmação (AC) C808A. 0 RP2 C465 produz um item de dados de formato variável que é alimentado na Pesquisa
Petição 870200056145, de 06/05/2020, pág. 314/1737
312/754 de Armazenamento C480 (SS) como critério de pesquisa. Portanto, o SS C480 realiza uma pesquisa no PS C478 para encontrar pares com percepções já existentes armazenadas no PS C478. Os resultados C716 da execução do SS C480 são produzidos levando a um C718 Cálculo de Peso. Esse cálculo C718 tenta encontrar a distribuição correta das percepções correspondentes do PS C478 para replicar e corresponder ao formato de variável comparável que representa a execução do algoritmo LOM 132 que produziu a substituição de finalidade 8258.
[734] A Fig. 640 continua a lógica do Emulador de Observação de Percepção (POE) C475 da Fig. 639. Após a produção a C716 Pesquisa de Armazenamento (SS) Resultado C480, o Cálculo do Peso C718 é concluído para levar o Aplicativo C729 de Considera 5512/5514/5516 para tomar uma decisão ativa de Aprovação C731 ou Bloqueio C730. A Substituição de Propósito 8258 produzida pela LOM 132 e o Agregado do Registro de LOM 5502 correspondente passa pela Análise de Dados C724, que faz com que os Regístradores de Dados Aprimorados C723 sejam derivados, aplicados no Aplicativo C729, para obter uma Dicotomia de Interpretação 5518 de um senso positivo (aprovar) C731 ou senso negativo (bloquear) C730 com referência à entrada da substituição de objetivo 8258. Com a conclusão bem-sucedida da execução do aplicativo C729, leva a uma ação corretiva da anulação C476 que é processada por a Saída de Decisão Crítica (CDO) C462 em paralelo com a execução modular da execução de regras (RE) C461. O módulo Densidade do conhecimento autocrítico (SCKD) C474 estima o escopo e o tipo de conhecimento desconhecido em potencial que está além do escopo do Agregado de Registro Reportável de LOM 5502. Dessa maneira,
Petição 870200056145, de 06/05/2020, pág. 315/1737
313/754 as funções de pensamento critico subsequentes do caso de processamento CTMP 124 podem tirar proveito do escopo potencial de todo o conhecimento envolvido, conhecido e desconhecido diretamente no caso.
[735] A Fig. 641 mostra o processo de Memória da Web C460 operando em paralelo com a execução do Emulador Observador (POE) C475 na Fig. 639. A substituição de finalidade 8258 produzida pelo LOM 132 é enviada como uma entrada modular para o Motivo do Processamento 0456. 0 Motivo do Processamento 0456 processa como o LOM 132 alcançou a decisão de produzir a Substituição de Propósito 8258 em resposta à Entrada 8268 fornecida pelo RIP 8266. A conclusão do Motivo do Processamento 0456 é a execução do Motivo do Processamento 0457, que define regras terciárias consistentes com o comportamento de execução do LOM 132. Se alguma inconsistência for encontrada no comportamento da regra referente ao comportamento de execução do LOM 132, as regras existentes no momento serão modificadas ou novas regras serão adicionadas. Essas regras são usadas no caso do CTMP 124 para criticar os comportamentos de tomada de decisão encontrados no caso LOM 132 correspondente. 0 Extensor de Escopo de Regra Crítica (CRSE) C458 aproveita as percepções conhecidas para expandir o escopo de 'pensamento crítico' dos conjuntos de regras, aprimorando os conjuntos de regras para produzir as Regras Corretas C459. As regras corretas C459 são então enviadas como uma entrada modular para a Separação do Formato da Sintaxe da Regra (RSFS) C499 dentro da jurisdição operacional da memória da web C460. 0 RSFS C499 separa e organiza as regras corretas C459 por tipo. Portanto, todas as ações, propriedades, condições
Petição 870200056145, de 06/05/2020, pág. 316/1737
314/754 e objetos são listados separadamente após o processamento do RSFS C499. Isso permite ao caso de o CTMP 124 discernir quais partes foram encontradas no campo caótico e quais não. A Análise de Campo Caótico (CFP) C535 combina e formata o Agregado de registro de LOM 5502 em uma única unidade digitalizável, como o Campo caótico. O campo caótico é enviado como uma entrada modular para o reconhecimento de memória (MR) C501. O MR C501 também recebe as Regras originais C555, que são o resultado da execução do RSFS C499. O MR C501 varre o Campo Caótico fornecido pelo CFP C535 para reconhecer conceitos conheciveis nas Regras Originais C555. Essa execução de caso MR C501 produz os segmentos de regra reconhecidos C556. Portanto, o Analisador de Conformidade com Regras (RFP) C498 recebe as partes individuais das Regras Originais C555 que foram rotuladas de acordo com seu reconhecimento ou, portanto, ausentes no Campo Caótico pelo MR C501. O RFP C498 pode deduzir logicamente que o conjunto completo de regras (a combinação de todas as suas partes) foi suficientemente reconhecido no Campo Caótico para dar mérito ao processamento pela Execução de Regras (RE) C461. A conclusão bemsucedida do RE C461 leva a uma Ação Corretiva de Substituição do C476, que é processada pelo CD46 (Saída de Decisão Crítica) C462 em paralelo ao Emulador de Observador de Percepção de Saída Modular (POE) C475.
[736] A Fig. 642 desenvolve a interação do fluxo lógico entre o Armazenamento de Percepção (PS) C478 e o Mecanismo de descoberta de percepção automatizada (APDM) C467. O PS C478 contém quatro subconjuntos de percepções: Os Ângulos de Percepção Desconhecidos Deduzidos C473, Todos os Ângulos de Percepção C472,
Petição 870200056145, de 06/05/2020, pág. 317/1737
315/754
Os Ângulos de Percepção Envolvidos C471 e os Ângulos de Percepção Aplicados C470. Os ângulos de percepção 0470 aplicados são percepções que foram importadas diretamente pelo estudo do comportamento algorítmico do algoritmo de correspondência de padrões selecionados (SPMA) , que neste caso é o LOM 132. Os ângulos de percepção 0471 envolvidos são percepções que foram derivados dos ângulos de percepção 0470 Aplicados através da execução do Derivação de Implicação (ID) 0477 e APDM 0467. Todos os ângulos de percepção 0472 representam o escopo completo das percepções conhecidas para o caso CTMP 124 que não foram incluídas pelos ângulos de percepção aplicados C470 e pelos ângulos de percepção envolvidos C471. Os ângulos de percepção desconhecidos deduzidos C473 representam a faixa de percepções que se espera existir, no entanto, o caso do CTMP 124 ainda não foi descoberto de acordo com o módulo C474 de Densidade do conhecimento autocrítico (SCKD). 0 ID C477 analisa as métricas individuais dos ângulos de percepção aplicados do C470 para derivar deterministicamente os ângulos de percepção aplicados do C470, enquanto o APDM C467 varia criativamente as composições dos Ângulos de Percepção do C650 através do Módulo de Criatividade 112 para produzir uma nova iteração C653 combinando os dois pesos iniciais de entrada C652. Portanto, todos os Ângulos de Percepção C650 envolvidos no processamento do C467 APDM correspondem e representam a substituição de finalidade 8258 produzida pelo módulo C0M8A Construção de Afirmação (AC) da LOM 132 .
[737] A Fig. 643 desenvolve os detalhes operacionais referentes ao Extensor de Escopo de Regra Crítica (CRSE) C458 do
Petição 870200056145, de 06/05/2020, pág. 318/1737
316/754
CTMP 124. Um caso do Apelo Racional (RA) C811A opera no LOM 132 e aplica a Construção de Contexto (CC) C817A para processar o Agregado do Registro de LOM 5502 na Análise de Campo Caótico (CFP) C535. O CFP produz um Campo Caótico a partir da saida modular do CC C817A, que é referenciada pelo Reconhecimento de Memória (MR) C501. A regra atual define as regras de exibição do C534 que são indicativas do status operacional atual do algoritmo de correspondência de padrão selecionado (SPMA), que neste caso é LOM 132. As regras atuais C534 são enviadas como uma entrada modular para o Módulo C504 de Derivação de Sintaxe de Regra (RSD), que é onde as regras lógicas 'Preto e Branco' são convertidas em percepções baseadas em métricas. Portanto, o arranjo complexo de várias regras se torna uma única percepção uniforme que é expressa por meio de várias métricas de gradiente variável. A saida modular do RSD C504 é fornecida como uma entrada modular para o Emparelhamento de Percepção (PM) C503. Na PM C503, uma unidade de formato variável comparável (CVF) é formada a partir da percepção recebida do RSD C504. O CVF recém-formado é usado para procurar percepções relevantes no C478 Armazenamento de Percepção (PS) com indices semelhantes. Os emparelhamentos em potencial são enviados como uma entrada modular para a Geração de Sintaxe de Regras (GSR) C505. O RSG C505 recebe percepções previamente confirmadas que são armazenadas no Formato de Percepção e acessam a constituição interna da Percepção. As percepções são recebidas do PS C478, que contém as percepções confirmadas anteriormente C468. Tais medições baseadas em gradientes métricos tornam-se conjuntos de regras binárias e lógicas que emulam o fluxo de informações de entrada/saída da
Petição 870200056145, de 06/05/2020, pág. 319/1737
317/754 percepção original. Portanto, o RSG C505 produz as Regras de Percepção C537, que são percepções consideradas relevantes, populares e que se tornaram regras lógicas. Se uma Percepção (em seu Formato de Percepção original) tiver muitas relações métricas complexas que definem muitas áreas cinza, as regras locais preto e branco abrangem essas áreas cinza, expandindo a complexidade do conjunto de regras. Portanto, as regras perceptivas do C537 são armazenadas por uma coleção de definições de formato de sintaxe da regra (RSF). As regras de percepção C537 são enviadas como uma entrada modular para o Reconhecimento de Memória (MR) C501, onde são digitalizadas no campo caótico produzido pelo CFP C535. Portanto, o MR C501 produz as Regras adicionais C536 que completam as Regras corretas C533 em sua validade.
[738] A Fig. 644 desenvolve os detalhes operacionais referentes ao CTMP 124. Desvio de implicação (ID) C477 Os ângulos de percepção aplicados C470 do Armazenamento de Percepção (PS) C478 são enviados como uma entrada modular para o ID C477 para produzir mais percepções que pertencem aos ângulos de percepção envolvidos C471. Os ângulos de percepção aplicados do 0470 são enviados especificamente para a combinação métrica ID 0477 0493. A combinação métrica 0493 separa os Ângulos de Percepção 0650 recebidos em categorias de métricas: Faixa 0739, Tipo 0740, Consistência C741, Intensidade C742. A disponibilidade de métricas e referências no sistema não está necessariamente limitada a esses quatro tipos. Os ângulos de percepção C650 de entrada estão relacionados à Substituição de Objetivo 8258, produzida pelo módulo LOM 132 C808A da Construção de Afirmação (AC). 0 Conjunto de Complexidade Métrica C736 é enviado como uma
Petição 870200056145, de 06/05/2020, pág. 320/1737
318/754 entrada modular para a Expansão Métrica (ME) C495. Com o ME C495, as métricas de ângulo de percepção múltiplos e variantes do C650 são armazenadas categoricamente em bancos de dados individuais C739/C740/C741/C742 . 0 ME C495 aprimora o grupo atual de métricas recebidas com detalhes/complexidade extraídos de métricas conhecidas/encontradas anteriormente. Após a conclusão da atualização e da complexidade, as métricas retornam como uma saída ME C495 modular como um Conjunto de Complexidade Métrica B C737 e, portanto, são convertidas novamente nos Ângulos de Percepção C650 para serem armazenados nos Ângulos Percebidos C471, conforme ilustrado em Fig. 1217.
[739] A Fig. 645 continua o fluxo lógico do Derivação de Implicação (ID) C477 da Fig. 644, ilustrando o Conjunto de Complexidade Métrica B C737 sendo processado pela Conversão Métrica C494, que reverte as métricas individuais retornadas aos Ângulos de Percepção C650 completos. Apesar dos processos de conversão executados pelo ID C477, os Ângulos de Percepção C650 resultantes ainda fornecem uma representação precisa da Substituição de Propósito 8258 produzido pelo módulo C808A do LOM 132 de Construção de Afirmação (AC). 0 medidor de conversão C494 envia os novos ângulos de percepção C650 derivados/implicados para os ângulos de percepção C471 envolvidos no armazenamento de percepção (PS) C478.
[740] A Fig. 646 desenvolve os detalhes operacionais referentes à Saída de Decisão Crítica (CDO) C462 do CTMP 124. O CDO C462 recebe uma saída modular das duas ramificações principais do CTMP 124: O Emulador de Observador de Percepção (POE) C475 (como a ramificação intuição) e Execução de Regras
Petição 870200056145, de 06/05/2020, pág. 321/1737
319/754 (RE) C461 (como o ramo lógico). Cada Filial C475/461 envia sua respectiva Decisão Critica C521 (a principal saída modular), além de corresponder os 'Meta-metadados' C521, que fornecem variáveis contextuais que justificam por que a decisão crítica inicial foi alcançada. Os conjuntos de decisões C521, que representam as percepções C516 do POE C475 e as regras de conformidade C517 do RE C461, são enviados ao Módulo de Categorização de Metadados (MCM) C488. 0 MCM C488 separa os algoritmos de depuração e rastreamento em diferentes categorias usando a categorização de informações com base na sintaxe tradicional. Essas categorias podem ser usadas para organizar e produzir respostas de segurança diferentes, com uma correlação com os riscos e problemas de segurança. A Decisão Intuitiva C514, que representa as Percepções C526 do POE C475, e a Decisão de Pensamento C515, que representa as Regras Cumpridas C517 de RE C461, são enviadas pelo MCM C488 à Lógica de Processamento Interno 5520 da Diretiva de Comparação da Decisão (DDC) C512. A DDC C512 Lógica de Processamento Interno 5520 analisa a corroboração ou o conflito entre a Decisão Intuitiva C514 e a Decisão de Pensamento C515. O DDC C512 refere se a uma variável 'principal' da Política Estática Codificada (SHP) 488. Se a variável 'principal' não for alcançada devido à semelhança entre a Decisão Intuitiva C514 e a Decisão de Pensamento C515 (por exemplo, 90% +), então, a comparação direta de cancelamento direto 5524 ocorre, o que pode levar o Controle de Saída do Terminal (TOC) C513 a enviar um voto de não confiança 5544, como mostrado na Fig. 647. O estágio de cancelamento de comparação direta 5524 envolve que o CTMP 124 não foi capaz de agir de forma consistente internamente, de acordo com a entrada
Petição 870200056145, de 06/05/2020, pág. 322/1737
320/754
8268 do RIP 8266. Se a variável 'limite' foi suficientemente satisfeita de acordo com a Lógica de processamento interno 5520, o estágio de saída de decisão 5522 é aplicado que combina as decisões C514/C515 em uma única saída modular que é recebida e processada pelo C513 TOC.
[741] A Fig. 647 continua o fluxo lógico da Saída de Decisão Crítica (CDO) C462 da Fig. 646 e desenvolve os detalhes operacionais do Controle de Saída do Terminal (TOC) C513. O TOC C513 começa com a Entrada 5526, que verifica se a Comparação Direta de Decisão (DDC) C512 foi capaz de oferecer a Saída Final de Decisão 5522 (em vez da diretiva 5524 de Cancelamento de Comparação Direta) . Se a resposta a essa Entrada 5526 for Sim 5528, a decisão final combinada fornecida pelo DDC C512 na Saída de Decisão Final 552 será enviada como uma saída modular do C513 TOC e, portanto, como uma saída modular de todo o caso CTMP 124 como a saída da Decisão Crítica Final 5542. Se a resposta à Entrada 5526 for No, 5530, a etapa 5532 aplica-se e ela mesma executa a execução 5532 de Correspondência de Percepção (PM) e procura os resultados correspondentes. As Regras Cumpridas C517 são extraídas da Decisão Crítica + Meta-metadados C521 de Regras de Execução (RE) C461. As regras C517 tornam-se percepções por derivação de sintaxe de regras (RSD) C504. A MP 5532 refere-se, então, aos meta-metadados para determinar, na entrada 5534, se houve forte sobreposição interna e corroboração das percepções utilizadas. Se a resposta à Entrada 5534 for Sim 5538, isso indica um Voto de Confiança 5544 do CTMP 124 como uma saída modular. Se a resposta à Entrada 5534 for No, 5536, a Etapa 5540 será ativada, que seleciona a decisão de menor risco percebida
Petição 870200056145, de 06/05/2020, pág. 323/1737
321/754 entre a Decisão Intuitiva C514 e a Decisão de Pensamento C515. Portanto, a Decisão Final Crítica 5542 é subsequentemente enviada como uma saída modular para o CDO C462, TOC C513 e CTMP 124. A lógica na Etapa 5534 ocorre para determinar se a falta de unidade entre a Decisão Intuitiva C514 e a Decisão de Pensamento C515 ocorre devido a uma falta geral de confiança algorítmica ou devido a visualizações altamente opostas entre os dois. Portanto, se este último ocorrer, uma Decisão Crítica Final 5542 ainda é discernível como uma saída modular. Um Voto de Não Confiança 5544 sempre leva à rota C845 de Resultado de Baixa Confiança dentro do Apelo Racional (RA) C811A. A decisão final crítica 5542 pode levar a um caminho lógico do resultado de alta confiança C846 ou do resultado de baixa confiança C845 dentro do RA C811A, dependendo da confiança algorítmica por trás da decisão crítica final 5542.
[742] A Fig. 648 mostra detalhes sobre a operação do LIZARD 120 para converter a Substituição de Propósito 8258 em Segmentos de Execução 8270. A Substituição de Propósito 8258 existe no Formato de Propósito Complexo C325 e é enviada para a Expansão Iterativa C327 do Módulo de Propósito C36 no núcleo externo LIZARD 120 C329 (OC) A expansão iterativa C327 adiciona detalhes e complexidade para desenvolver um objetivo simples (definido indiretamente no Substituição de Propósito 8258) para uma definição específica de objetivo complexo. Portanto, o potencial máximo de associação de finalidade C326 da entrada é realizado e retido como um formato de finalidade complexa C325, antes de ser enviado para a derivação lógica C320 do módulo de sintaxe (SM) C35. O elemento C335 do Código principal do IC
Petição 870200056145, de 06/05/2020, pág. 324/1737
322/754 interno (C) C333 contém Estruturas e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e gerenciamento de memória. Portanto, o Código Central C335 permite operação e funcionalidade gerais ao SM C35 e PM C36, oferecendo bibliotecas e scripts padronizados que permitem funcionalidade básica. Os elementos dos Objetivos do Sistema C336 do IC C333 definem Metas de Segurança e Políticas de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[743] A Fig. 649 continua o fluxo lógico da Fig. 648 para ilustrar a operação do LIZARD 120 para converter uma substituição de finalidade 8258 em segmentos de execução 8270. As informações de entrada são recebidas no formato de finalidade complexa C325 (PM) C36 e é transferido para a Derivação Lógica C320 do Módulo Sintaxe (SM) C35. A derivação lógica C320 deriva funções logicamente necessárias de funções inicialmente mais simples. Isso significa que se uma função pode ser formada como uma função derivada devido à implicação de uma função pai mais simples; então é formado pela derivação lógica C320. A saída produzida é uma árvore de dependências de funções que são construídas de acordo com os dados do C325 Formato de Propósito Complexo definido. A Derivação Lógica C320 opera de acordo com as definições das Regras e Sintaxe C322, que são herdadas do elemento do Código Principal C335 do Núcleo Interno (IC) C333. A Derivação Lógica C320 envia sua saída para a Conversão de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pela SM C35 em qualquer
Petição 870200056145, de 06/05/2020, pág. 325/1737
323/754 linguagem de computação escolhida e conhecida. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computação conhecidas em tipos de sintaxe arbitrários. Portanto, o PM C36 aplica o SM C35 para produzir a versão dos Segmentos de Execução 8270 resultantes da entrada da Substituição de Objetivo 8258 através da Conversão de Código C321. Os segmentos de execução 8270 resultantes que são produzidos terminalmente pela Conversão de Código C321 são a saída modular do SM C35, núcleo externo (OC) C329 e LIZARD 120. Os segmentos de execução 8270 são armazenados em retenção de unidade Substituição de sintaxe (SRUR) 8246.
[744] A Fig. 650 desenvolve a operação e a funcionalidade do módulo de busca de modelo de unidade (UBL) 8248, referente ao estágio 8242 da Correção de erros inatos (IEC) 8050. O estágio 8286 recebe uma entrada modular da retenção da Unidade de Substituição de Sintaxe (SRUR) 8246, portanto, inicia um loop que percorre todas as unidades de substituição de sintaxe 8288 do SRUR 8246. A etapa 8284 recupera a unidade de substituição de sintaxe 8288 selecionada do SRUR. A Unidade de Código Associada 8292 é desembrulhada da Unidade de Substituição de Sintaxe 8288 na Etapa 8290. Em um encadeamento paralelo separado no mesmo caso de UBL 8248, o Modelo de Estrutura de Código 8260 é enviado como uma entrada modular para o Estágio 8280. O estágio 8280 instala o modelo de estrutura de código 8260 na retenção do novo modelo de estrutura de código (NCSBR) 8282.
[745] A Fig. 651 continua o fluxo lógico da Fig. 1222, referindo-se à chamada da Pesquisa de Modelo de Unidade (UBL) 8248 de dentro da lógica interna da Etapa 8242. O Fluxo Lógico
Petição 870200056145, de 06/05/2020, pág. 326/1737
324/754 continua da Fig. 1222 na Etapa 8294, que instala a unidade de substituição de sintaxe 8288 na retenção do novo modelo de estrutura de código (NCSBR) 8282. A etapa 8296 é aplicada assim que o loop de processamento iterative aplicado na etapa 8286 for concluído. A etapa 8296 reverte o status de conformidade dos segmentos de execução 551 por meio do processamento de linha de estrutura de código (CSSP) 8250. Portanto, o CSSP 8250 produz a Appchain 6262 atualizado como uma saída modular.
[746] A Fig. 652 continua o fluxo lógico da Correção de Erros Inatos (IEC) 8050 a partir da chamada do CSSP 8250 na Fig. 651. O CSSP 8250 produz a Appchain 6262 atualizado, que representa a estrutura sintática original, mas substituindo as Unidades de Código Desalinhadas com a Substituição Correta da Finalidade. A Appchain 6262 atualizada é enviado ao Montagem de Patch de Implantação (DPA) 6260 para produzir o Patch de correção 6270 da Appchain. A Appchain de destino 6060 é processado pela Coleção de Fluxo de Execução (ESC) 6700, enviando assim o Fluxo de Execução 556 para o caso do DPA 6260. Isso permite que o DPA 6260 acesse o Aplicativo Objetivo 6060 em sua forma original. Como o DPA 6260 tem acesso ao diferencial entre o Original 6060 e a Appchain 6262 atualizada, ele produzir o Patch 6270 de Correção da Appchain, que contém as instruções para converter a App Original 6060 na Appchain 6262 atualizado. Na Etapa 8298, O Patch 6270 de correção da Appchain é implementado no Construtor de Ecossistemas Customchain (CEB) 584, que manipula a Appchain Objetivo 6060 para converter a Appchain Atualizada 6262 em conteúdo.
[747] A Fig. 653 mostra o procedimento de operação
Petição 870200056145, de 06/05/2020, pág. 327/1737
325/754 interna do Endurecimento de Segurança da Appchain (ASH) 8044. 0 ASH 8044 é um submódulo do SPSI 130 que executa Código de Eficiência, Qualidade, Segurança e Estabilidade 5048. O LOM 132 procura ameaças de segurança, casos conhecidos e possíveis casos através do ARM 134 na Etapa 8300. As informações novas e não confirmadas resultantes são armazenadas e processadas na CKR 648 na Etapa 8302. Na Etapa 8304, o LOM 132 extrai declarações e conclusões afirmativas sobre o segurança, portanto, produzindo a Conscientização Sobre Ameaças à Segurança 8306. Na Etapa 8308, a Conscientização Sobre Ameaças à Segurança é enviada para o AST (Ameaça de Segurança Artificial) 123 para referência.
[748] A Fig. 654 continua o fluxo lógico do Endurecimento de Segurança da Appchain (ASH) 8044 da Fig. 653. Na etapa 8310, o ARM 134 recupera informações não confirmadas de arquivos de dados públicos e privados e armazena as informações não confirmadas no CKR 648 em Etapa 8312. Na Etapa 8314 LOM 132 e CTMP 124, verifique as informações não confirmadas e as expanda para produzir conceitos confiáveis, o conhecimento confirmado é armazenado no CKR 648, para recuperação futura por uma entrada de chamada.
[749] A Fig. 655 mostra o Procedimento Operacional Interno do LOM 132 e CTMP 124 em referência à Etapa 8304 do Endurecimento de Segurança da Appchain (ASH) 8044. A Teoria da segurança 8312, Informações de segurança não confirmadas 8314 e Conhecimento da Confirmação de Segurança 8310 é fornecido como uma entrada inicial para a Entrada de Invocação de Dedução (DIP) 8316. O DIP 8316 produz uma entrada 8318 que interage diretamente com o LOM 132 para invocar a produção das Declarações de Segurança
Petição 870200056145, de 06/05/2020, pág. 328/1737
326/754
Confiáveis 8320, considerando critérios de entrada para a Teoria da segurança 8312, Informações de segurança não Confirmadas 8314 e Conhecimento de Segurança Confirmado 8310. A entrada 8318 produzida pelo DIP 8316 é enviada ao módulo de Raciocínio de consulta inicial (IQR) C802A do LOM 132. Quando o LOM 132 é aplicado diretamente na Plataforma UBEC 100 por um Usuário da UBEC 106, o IQR C802A recebe a pergunta/declaração inicial fornecida pelo Usuário da UBEC 106. No entanto, esse caso do LOM 132 é aplicado automaticamente pelo DIP 8316. A Entrada 8318 fornecida é analisada através da chamada 648 da Retenção Central de Conhecimento (CKR) para Descriptografar os Detalhes da Entrada ausente 8268, que são cruciais para concluir o 'entendimento virtual' correto do LOM 132 para que o LOM 132 atenda/responda totalmente à entrada 8268. Os Detalhes ausentes produzidos pelo IQR C802A são enviados como uma entrada modular para o Esclarecimento de Pesquisas (SC) C803A. O SC C803A se compromete com a origem da Entrada 8318 para recuperar informações suplementares, para que a Entrada 8318 possa ser analisada objetivamente e em todo o contexto necessário. Quando o LOM 132 é aplicado diretamente na Plataforma UBEC 100 por um Usuário da UBEC 106, o SC C803A confirma esse Usuário 106 como a origem da pergunta/resposta. No entanto, esse caso do LOM 132 é aplicado automaticamente pelo DIP 8316, portanto, o SC C803A se compromete com o DIP 8316 para recuperar informações adicionais sobre o Item 8318. É produzida a versão totalmente formada e refinada do Item 8318 do SC C803A e é enviado como uma entrada modular para a Construção de Afirmação (AC) C808A. O AC C808A tenta formar uma resposta consistente à Entrada 8318 consultando CKR 648
Petição 870200056145, de 06/05/2020, pág. 329/1737
327/754 diretamente e através do Mapeamento de Hierarquia (HM) C807A. 0 Apelo Racional (RA) C811A é um módulo de contêiner que hospeda uma interface de fluxo lógico com o CTMP 124. 0 RA C811A usa o CTMP 124 para criticar as reivindicações. Tais criticas podem ter a forma de autocrítica (criticar a saída do AC C808A) ou crítica externa da origem da pergunta/declaração processada pelo IQR C802A (Usuário da UBEC 106 ou DIP 8316) . Se uma afirmação produzida a partir do AC C808A falhar, uma medida significativa do teste de autocrítica processada pelo RA C811A; então, um novo caso do AC C808A é aplicado para responder a qualquer crítica válida. Se uma declaração de alta confiança for produzida pelo AC C808A, ela passará nos testes de autocrítica processados consistentemente pelo RA C811A; a asserção ocorre como uma saída modular do LOM 132, referenciada como a Afirmação de Segurança Confiável 8320 no contexto da entrada inicial 8318 fornecida pelo DIP 8316.
[750] A Fig. 656 mostra mais detalhes do procedimento de operação interna do LOM 132 Apelo Racional (RA) C811A, relacionado à Etapa 8304 da ASH 8044. A Construção afirmativa C808A (AC) fornece um envio de resposta C843 a Construção de Afirmação (RA) C811A, referente à declaração produzida pela AC C808A em relação aos rendimentos correspondentes à Entrada 8268. Nesse estágio do fluxo lógico, a asserção produzida é classificada como uma Decisão Pré-Crítica C847. Isso indica que ainda não foi processado através das críticas ao CTMP 124. Portanto, a afirmação produzida é enviada diretamente ao caso do CTMP 124 como uma entrada do 'Parecer subjetivo' C848 e também para a Construção de Contexto (CC) C817A, que fornece entrada de
Petição 870200056145, de 06/05/2020, pág. 330/1737
328/754 'Fato Objetivo' 0850 para o caso CTMP 124. 0 CC C817A refere-se aos metadados do CA C808A e às evidências fornecidas pelo RIP 8266 para enviar dados brutos ao CTMP 124 para o pensamento critico. Esses metadados de entrada são representados pelo arquivo Agregado de Registro de LOM 5502. O Agregado de Registro de LOM 5502 contém uma coleção de arquivos de Registro relevantes que são produzidos pelas funções de operação principal do LOM 132. Após a conclusão do caso CTMP em sua operação, uma Decisão Pós-Critica C851 é produzida como uma saída modular. A Decisão Pré-Criticada C847 inicial e a Decisão Pós-Criticada C851 são enviadas ao módulo de Comparação de Decisão (DC) C818A, que determina a extensão da sobreposição potencial entre as duas entradas C847 e C851. A saída unificada fornecida pelo DC 818A pode indicar a concessão C852 (de imprecisão) do CTMP 124 por parte da afirmação AC C808A produzida ou uma melhoria percebida C853 por parte da afirmação produzida AC C808A. As respostas de argumento C852 e C853 podem ser classificadas como Resultados de baixa confiança C845 ou Resultados de alta confiança C846. Um resultado de baixa confiança C845 indica que a reivindicação original produzida pelo AC C808A é falha e deve ser reconstruída; portanto, o fluxo lógico continua para um novo caso do AC C808A. Um resultado de alta confiança C846 indica que a declaração original produzida pela AC C808A tem mérito; portanto, as conclusões obtidas (combinadas com as evidências, premissas, etc.) correspondentes são enviadas para a Validação de conhecimento (KV) C805A. Portanto, o fluxo lógico continua para um novo caso do KV C805A, para que o CKR 846 e, portanto, o LOM 132 possa se beneficiar da reivindicação recém-processada.
Petição 870200056145, de 06/05/2020, pág. 331/1737
329/754
[751] A Fig. 657 continua o fluxo lógico da etapa 8304 do ASH 8044 para ilustrar a produção do Arquivo Agregado de Registro de LOM 5502. As saídas modulares produzidas a partir do Raciocínio de Consulta Inicial (IQR) C802A, Esclarecimento da Pesquisa (SC) C803A, C808A Construção de Afirmação (AC), C807A Mapeamento de Hierarquia (HM) e C805A Validação de Conhecimento (KV) são enviados para o Módulo de Coleta de Registros Modulares de LOM (LMLC) 5500. Portanto, o LMLC 5500 combina os dados de entrada de registro em um arquivo legível referido como Agregado do Registro de LOM 5502. O arquivo 5502 aborda o status operacional geral do caso LOM 132 correspondente, fornecendo informações sobre como o caso LOM 132 chegou a várias conclusões. O Agregado de Registro de LOM 5502 é enviado para o CC C817A do Apelo Racional (RA) C811A.
[752] A Fig. 658 expande os detalhes operacionais referentes à Fig. 657 para ilustrar a operação interna do CTMP 124 em referência aos canais de entrada e saída definidos no Apelo Racional (RA) C811A. A Decisão Pré-Crítica C847 é Apresentada C843 como a saída modular da Construção de Afirmação (AC) C808A. A decisão C847 é então marcada como uma Opinião Subjetiva C848, atendendo assim a uma das duas principais entradas do CTMP 124. A Opinião Subjetiva C848 é enviada aos Metadados do Sistema de Entrada C484, que atua como a entrada modular primária para CTMP 124 e uma representação interna do algoritmo de correspondência de padrões selecionados (SPMA) . Para este caso, configure; o SPMA é LOM 132. Os metadados do sistema de entrada C484 são enviados para processamento do processamento
Petição 870200056145, de 06/05/2020, pág. 332/1737
330/754 de razão C456 e produção de percepção bruta (RP2) C465. Ο Processamento de Motivos C456 entenderá logicamente as reivindicações feitas ao comparar atributos de propriedade. O RP2 C465 analisa os metadados do sistema de entrada LOM 132 0484 para produzir uma percepção no Formato Complexo de Percepção PCF que representa a percepção algorítmica do LOM 132. Essa percepção produzida é enviada para o Observador de Percepção (POE) C475 em que emula a percepção algorítmica do LOM 132. 0 Processamento da Razão C456 aplica o Processamento de Regras, que eventualmente produz conjuntos de regras que refletem o algoritmo SPMA que, neste caso, é o LOM 132. Portanto, duas maneiras de 'pensar' A percepção 'analógica' e o processamento do jogo de regras 'digital' executados. Esses dois ramos C461 e C475 representam semelhanças com intuição e lógica. Os resultados produzidos pelas ramificações pensantes C461 e C475 são transferidos para a Saída de Decisão Crítica (CDO) C462, que avalia qualquer elemento fundamental de conflito ou corroboração entre os resultados. Encontrando uma grande magnitude de corroboração interna e uma baixa magnitude de conflito interno, o CTMP 124 oferece uma decisão binária de Aprovar ou Bloquear, em termos da Opinião Subjetiva C848 da entrada inicial, refere-se a isso como um Resultado de Alta Confiança C846. Se houver uma baixa magnitude de corroboração interna e uma alta magnitude de conflito interno do CTMP 124, um 'voto de não confiança' é enviado, que é referido como um Resultado de Baixa Confiança C845. Portanto, a saída resultante do CTMP 124 é considerada Decisão Pós-Criticada C851.
[753] A Fig. 659 mostra mais detalhes sobre a chamada da Produção de Percepção Bruta (RP2) C465 no CTMP 124. 0 LOM 132
Petição 870200056145, de 06/05/2020, pág. 333/1737
331/754 produz a Declaração de Segurança Confidencial 8320 aplicando a Declaração de Construção (AC) C808A. A Declaração de Segurança Confiança 8320 é então enviada ao Estágio 5506 do RP2 C465, que desembrulha os dados para produzir instâncias de um Rastreio de Depuração C485 e Rastreio do Algoritmo C486 nos Metadados do Sistema de Entrada C484, originários do gabinete AC C808A correspondente. O rastreamento de depuração C485 é um rastreamento de nível de codificação que oferece variáveis, funções, métodos e classes que são usadas juntamente com seu tipo e o conteúdo de entrada e saída correspondente. A chamada Chain Completa é fornecida (função de rastreamento: Funções Chamando Outras Funções). O Rastreamento de algoritmo C486 é um rastreamento de nível de software que oferece dados de segurança juntamente com a análise de algoritmo. A decisão de segurança resultante (aprovada/bloqueada) é fornecida juntamente com uma trilha logística de como chegou à Decisão C847. O peso apropriado para cada fator que contribuiu para a produção da Decisão C847 está incluído. Portanto, o RP2 C465 transfere os dados referentes ao resultado da percepção produzido para o Emulador de Observador de percepção (POE) C475 para processamento.
[754] A Fig. 660 executa a operação de produção bruta de percepção C465 (RP2) no CTMP 124. Inicialmente, a Etapa 5506 ocorre, como na Fig. 659, para desembrulhar os dados para produzir os casos do Traço de Depuração C485 e os Rastreamento de algoritmo C486 nos metadados do sistema de entrada C484 que se originam do caso AC C808A correspondente. Na Etapa 5508, o C489 Processamento Métrico realiza engenharia reversa das variáveis do LOM 132 para extrair as percepções da inteligência
Petição 870200056145, de 06/05/2020, pág. 334/1737
332/754 artificial exibida pelo LOM 132. Portanto, os metadados do sistema de entrada 0484 são processados pela Etapa 5510, que separa 0484 Metadados nas relações de causa-efeito de segurança por meio da 0487 Separação de Metadados do Sistema (SMS). Como também indicado na Fig. 659, o RP2 C465 transfere os dados referentes ao resultado da percepção produzido para o Emulador de Observador de Percepção (POE) C475 para processamento.
[755] A Fig. 661 desenvolve a operação do Emulador de Observador de Percepção (POE) C475, e inclui a Relação de Armazenamento de Percepção (PS) C478 da Produção de Percepção Bruta (RP2) C465. A operação do C489 Processamento Métrico e da C487 Separação de Metadados do Sistema (SMS) leva à produção das percepções 5512/5514/5516, que são armazenadas no PS C478. As percepções 5512/5514/5516 resultantes representam a resposta modular do LOM 132 à produção da Substituição de Propósito 8258 através da Construção de Afirmação (AC) C808A. 0 RP2 C465 produz um valor de dados em Formato de variável comparável, que é alimentado na Pesquisa de Armazenamento (SS) C480 como critério de pesquisa. Portanto, o SS C480 realiza uma pesquisa no PS C478 para encontrar pares com percepções já existentes armazenadas no PS C478. Os resultados C716 da execução do SS C480 foram produzidos, levando a um cálculo de peso C718. Esse cálculo C718 tenta encontrar a distribuição correta das percepções correspondentes do PS C478 para replicar e corresponder ao formato de variável comparável que representa a execução do algoritmo LOM 132 que produziu a Declaração de Confiança de Confiança 8320.
[756] A Fig. 662 continua a lógica do Emulador de
Petição 870200056145, de 06/05/2020, pág. 335/1737
333/754
Observador de Percepção (POE) 0475 da Fig. 661. Após a produção dos Resultados 0716 da Pesquisa de Armazenamento (SS) 0480, o 0718 Cálculo de Peso é concluído para levar ao Aplicativo C729 de as Percepções 5512/5514/5516 para tomar uma decisão do Passe C731 ou do Bloco C730 são ativadas. A Substituição de Propósito 8258 produzida pela LOM 132 e o Agregado de Registro de LOM 5502 correspondente passam pela Análise Sintática dos Dados C724, que faz com que os Registradores de Dados Aprimorados C723 sejam derivados, aplicados no Aplicativo C729 para obter uma Dicotomia Interpretação 5518 de um sentimento positivo (aprovar) C731 ou sentimento negativo (bloquear) C730 com referência à receita de substituição da finalidade 8258. Após a conclusão bem-sucedida da Execução C729, o Aplicativo leva à Ação Corretiva de Substituição C476, que é processada pela Saída de Decisão Crítica (CDO) C462 em paralelo à Saída Modular de Execução de Regra (RE) C461. 0 módulo Densidade do Conhecimento Autocrítico (SCKD) C474 estima o escopo e o tipo de conhecimento desconhecido em potencial que está além do escopo do Agregado de Registro Reportável do LOM 5502. Dessa maneira, as funções de pensamento crítico subsequentes do caso de processamento do CTMP 124 podem tirar proveito do escopo potencial de todo o conhecimento envolvido, conhecido e desconhecido diretamente no caso.
[757] A Fig. 663 mostra o processo de Memória da Web C460 operando em paralelo com a execução do Emulador de Observador de Percepção (POE) C475 na Fig. 661. A Declaração de Segurança de Confiança 8320 produzida pela LOM 132 é enviada como uma entrada modular para Processamento da razão C456. 0 Processamento de Motivos C456 processa quanto o LOM 132 alcançou
Petição 870200056145, de 06/05/2020, pág. 336/1737
334/754 a decisão de produzir a Declaração de Segurança Confiança 8320 em resposta à Entrada 8318 fornecida pelo DIP 8316. A conclusão do processamento do Processamento de Motivos C456 é a execução do Processamento de Motivos C457, que define regras que são terciárias consistentes com o comportamento de execução do LOM 132. Se alguma inconsistência for encontrada no comportamento da regra em referência ao comportamento de execução do LOM 132, as regras existentes no momento serão modificadas ou adicionadas novas regras. Essas regras são então usadas no caso do CTMP 124 para criticar os comportamentos de tomada de decisão encontrados no caso LOM 132 correspondente. O Extensor de Escopo de Regra Crítica (CRSE) C458 aproveita as percepções conhecidas para expandir o escopo do 'pensamento crítico' nos conjuntos de regras, melhorando efetivamente os conjuntos de regras para produzir as Regras Corretas C459. As Regras Corretas C459 são então enviadas como uma entrada modular para a regra de sintaxe de regras (RSFS) C499 dentro da jurisdição operacional da memória da web C460. O RSFS C499 separa e organiza as regras corretas C459 por tipo. Portanto, todas as ações, propriedades, condições e objetos são listados separadamente após o processamento do RSFS C499. Isso permite ao caso de o CTMP 124 discernir quais partes foram encontradas no campo caótico e quais não. A Análise de campo caótico (CFP) C535 combina e formata o Agregado de Registro de LOM 5502 em uma Única Unidade Digitalizável referida como o campo caótico. O Campo Caótico é enviado como uma entrada modular para o reconhecimento de memória (MR) C501. O MR C501 também recebe as Regras originais C555, que são o resultado da execução do RSFS C499. O MR C501 varre o Campo Caótico fornecido pelo CFP
Petição 870200056145, de 06/05/2020, pág. 337/1737
335/754
C535 para reconhecer os conceitos conheciveis definidos nas Regras Originais C555. Essa execução de caso MR C501 produz os segmentos de regra reconhecidos C556. Portanto, o Analisador de conformidade de regras (REP) C498 recebe partes individuais das Regras originais C555 que foram rotuladas de acordo com o reconhecimento de falhas, portanto, dentro do campo caótico do MR C501. 0 RFP C498 pode deduzir logicamente que o conjunto completo de regras (a combinação de todas as suas partes) foi suficientemente reconhecido no Campo Caótico para ter o mérito de ser processado pela Execução de Regras (RE) C461. Após a conclusão bem-sucedida da execução do RE, o C461 leva a uma Ação Corretiva de Substituição do C476 que é processada pelo Saída de Decisão Crítica (CDO) C462 em paralelo à saída modular do Emulador de Observador de Percepção (POE) C475.
[758] A Fig. 664 desenvolve a interação do fluxo lógico entre o Armazenamento de Percepção (PS) C478 e o Mecanismo de descoberta de percepção automatizada (APDM) C467. 0 PS C478 contém quatro subconjuntos de percepções: os ângulos de percepção desconhecidos deduzidos C473, todos os ângulos de percepção C472, os ângulos de percepção envolvidos C471 e os ângulos de percepção aplicados C470. Os ângulos de percepção aplicados C470 são percepções que foram importadas diretamente pelo estudo do comportamento algorítmico do algoritmo de correspondência de padrões selecionados (SPMA) , que neste caso é o LOM 132. Os ângulos de percepção 0471 são percepções derivadas dos Ângulos de Percepção Aplicados 0470 através da execução modular da Derivação de Implicação (ID) 0477 e APDM 0467. Todos os ângulos
Petição 870200056145, de 06/05/2020, pág. 338/1737
336/754 de percepção C472 representam o escopo completo das percepções conhecidas pelo caso CTMP 124 que não foram incluídas pelos ângulos de percepção aplicados C470 e pelos ângulos de percepção envolvidos C471. Os ângulos de percepção desconhecidos deduzidos C473 representam o escopo de percepções que se espera existir, no entanto, o caso do CTMP 124 ainda não foi descoberto de acordo com o módulo C474 de Densidade do conhecimento autocrítico (SCKD). 0 ID C477 analisa as métricas individuais dos ângulos de percepção aplicados do C470 para derivar os ângulos de percepção implícitos do C470 deterministicamente, enquanto o C467 APDM varia criativamente as composições dos ângulos de percepção C650 através do módulo Criatividade 112 para produzir uma nova iteração C653 combinando os dois pesos iniciais de entrada C652. Portanto, todos os ângulos de percepção C650 envolvidos no processamento do C467 APDM correspondem e representam a Asserção de Confiança 8320, produzida pelo módulo de Construção afirmativa COM8A (AC) da LOM 132.
[759] A Fig. 665 desenvolve os detalhes operacionais referentes ao Extensor de Escopo de REGRA crítica CRSE (C458) do CTMP 124. Um caso do Apelo Racional (RA) C811A opera no LOM 132 e invoca a Construção de Contexto (CC) C817A para processar o Agregado do Registro de LOM 5502 na Análise de Campo Caótico (CEP) C535. O CEP produz um Campo Caótico a partir da saída modular DC C817A, que é referenciada pela Confirmação de Memória (MR) C501. A regra atual define as regras de exibição do C534 que são indicativas do status operacional atual do algoritmo de correspondência de padrão selecionado (SPMA) , que neste caso é LOM 132. As regras atuais C534 são enviadas como uma entrada
Petição 870200056145, de 06/05/2020, pág. 339/1737
337/754 modular para o módulo Derivação de sintaxe de regra (RSD) C504, que é onde as regras lógicas 'preto e branco' são convertidas em percepções baseadas em métricas. Portanto, o arranjo complexo de várias regras se torna uma única percepção uniforme que é expressa por meio de métricas de gradiente de múltiplas variantes. A saída modular C504 RSD é fornecida como uma entrada modular para o Emparelhamento de Percepção (PM) C503. Na PM C503; uma unidade de formato variável comparável (CVF) é formada a partir da percepção recebida do RSD C504. 0 CVF recém-formado é usado para procurar percepções relevantes no C478 Armazenamento de Percepção (PS) com índices semelhantes. Os emparelhamentos em potencial são enviados como uma entrada modular para a Geração de Sintaxe de Regras (GSR) C505. 0 RSG C505 recebe as percepções confirmadas anteriormente que são armazenadas no formato de Percepção e acessa a composição métrica interna de Percepção. As percepções são recebidas do PS C478, que contém as percepções confirmadas anteriormente C468. Tais medições baseadas em gradientes métricos tornam-se conjuntos de regras binárias e lógicas que emulam o fluxo de informações de entrada/saída da percepção original. Portanto, o RSG C505 produz as Regras de percepção C537, que são percepções consideradas relevantes, populares e que foram convertidas em regras lógicas. Se uma Percepção (em seu Formato de Percepção original) tiver muitas relações métricas complexas que definem muitas áreas cinza ' , as regras locais' preto e branco 'tratam dessas áreas' cinza 'expandindo a complexidade do conjunto de regras. Portanto, as regras perceptivas do C537 são armazenadas por uma coleção de definições de formato de sintaxe da regra (RSF). As regras de
Petição 870200056145, de 06/05/2020, pág. 340/1737
338/754 percepção C537 são enviadas como uma entrada modular para o Reconhecimento de Memória (MR) C501, onde são digitalizadas no campo caótico produzido pelo CFP C535. Portanto, o MR C501 produz as Regras adicionais C536 que completam as Regras corretas C533 em sua validade.
[760] A Fig. 666 desenvolve os detalhes operacionais referentes ao CTMP 124. A Percepção de derivação de implicação (ID) C477 C470 dos ângulos de percepção aplicados (PS) C478 são enviados como uma entrada modular para o ID C477 para produzir mais percepções que pertencem aos ângulos de percepção envolvidos C471. Os ângulos de percepção aplicados do C470 são enviados especificamente para a combinação métrica C493 da ID C477. A combinação de métricas separa os ângulos de percepção do C650 recebidos em categorias de métricas: Intervalo C739, Tipo C740, Consistência C741, Intensidade C742. A disponibilidade da métrica e referência dentro do sistema não é necessariamente limitada a esses quatro tipos. Os ângulos de percepção do C650 de entrada estão relacionados à Substituição Objetivo 8258 que foi produzida pelo módulo LOM 132 C808A da Construção de Afirmação (AC) . O conjunto de complexidade métrica A C736 é enviado como uma entrada modular para a expansão métrica (ME) C495. Com o ME C495, as métricas de múltiplos e variantes de Ângulos de percepção C650 são categorizadas em bancos de dados individuais C739/C740/C741/C742 . O ME C495 aprimora o grupo atual de métricas recebidas com detalhes/complexidade extraídos de métricas conhecidas/encontradas anteriormente. Após a conclusão do aprimoramento e enriquecimento da complexidade, as métricas são retornadas como uma saída modular ME C495 como um Conjunto de
Petição 870200056145, de 06/05/2020, pág. 341/1737
339/754
Complexidade Métrica B C737 e, portanto, convertidas de volta para os Ângulos de percepção C650 para serem armazenadas nos Ângulos de percepção envolvidos C471 como ilustrado na Fig. 667.
[761] A Fig. 667 continua o fluxo lógico da Derivação de Implicação (ID) C477 da Fig. 666, ilustrando o Conjunto de Complexidade Métrica C737 sendo processado pela Conversão Métrica C494, que reverte as métricas individuais de volta aos Ângulos de Percepção C650 completos. Apesar do processo de enriquecimento e conversão realizado pela ID C477, os Ângulos de Percepção C650 resultantes ainda fornecem uma representação razoavelmente precisa da Substituição de Propósito 8258 produzida pelo módulo C808A da Construção de Afirmação de LOM 132 (AC) do processo de conversão métrica C494 envia os ângulos de percepção C650 recémderivados/implicados para os ângulos de percepção envolvidos C471 no armazenamento de percepção C478 (PS).
[762] A Fig. 668 desenvolve os detalhes operacionais referentes a Saida de Decisão Critica (CDO) C462 do CTMP 124. 0 CDO C462 recebe saldas modulares dos dois principais ramos do CTMP 124: 0 Observador de Percepção (POE) C475 (como o ramo da intuição) e Execução de Regra (RE) C461 (como o ramo lógico) . Cada Filial C475/461 envia sua respectiva Decisão Crítica C521 (a principal saída modular), bem como os correspondentes M5metadados C521, que fornecem variáveis contextuais que justificam por que a decisão crítica inicial foi alcançada. Os conjuntos de decisões C521, que representam as percepções C516 do POE C475 e as regras de conformidade C517 do RE C461, são enviados ao Módulo de categorização de metadados (MCM) C488. 0 MCM C488 separa os algoritmos de depuração e rastreamento em diferentes categorias
Petição 870200056145, de 06/05/2020, pág. 342/1737
340/754 usando a tradicional categorização de informações baseada em sintaxe. Essas categorias podem ser usadas para organizar e produzir respostas de segurança diferentes, com uma correlação com riscos e problemas de segurança. A Decisão Intuitiva C514, que representa as Percepções C526 do POE C475, e a Decisão de Pensamento C515, que representa as Regras Cumpridas C517 de RE C461 e são enviadas pelo MCM C488 para a Lógica de Processamento Interno 5520 da Comparação da Decisão da Endereço (DDC) C512. A DDC C512 Lógica de Processamento Interno 5520 analisa a corroboração ou o conflito entre a Decisão Intuitiva C514 e a Decisão de Pensamento C515. O DDC C512 refere-se a uma variável 'top' da Política Estática Codificada (SHP) 488. Se a variável 'top' não for alcançada devido à semelhança entre a Decisão Intuitiva C514 e a Decisão de Pensamento C515 (por exemplo, 90% +), então a diretiva de Cancelamento de Comparação Direta 5524 ocorre, o que pode levar o TOC (Controle de Saída do Terminal) C513 a enviar um voto sem confiança 5544, como visto na Fig. 669. O Estágio de cancelamento de comparação direta 5524 envolve que o CTMP 124 não foi capaz de agir internamente consistente em relação ao RIP 8266, entrada 8268. Se a variável 'limite' foi suficientemente satisfeita em relação à Lógica de processamento interno 5520, o estágio final de saída da decisão 5522 se aplica como que combina as decisões C514/C515 em uma única saída modular que é recebida e processada pelo TOC C513.
[763] A Fig. 669 continua o fluxo lógico da Saída de
Decisão Crítica (CDO) C462 da Fig. 668 e desenvolve os detalhes operacionais do Controle de Saída do Terminal (TOC) C513. O TOC
Petição 870200056145, de 06/05/2020, pág. 343/1737
341/754
C513 inicia com a Entrada 5526, que verifica se a Comparação Direta de Decisão (DDC) C512 foi capaz de fornecer a Saida Final de Decisão 5522 (em vez da diretiva de Comparação de Cancelamento Direta 5524) . Se a resposta à Entrada 5526 for Sim 5528, a decisão final combinada fornecida pelo DDC C512 na Saída de Decisão Final 552 será enviada como uma saída modular do TOC C513 e, portanto, como uma saída modular do gabinete CTMP 124 seja concluída como a saída da Decisão Crítica Final 5542. Se a resposta à Entrada 5526 for No 5530, a Etapa 5532 se aplicará, a qual aplicará a execução da Correspondência de Percepção (PM) 5532 e buscará os resultados correspondentes. As Regras Cumpridas C517 são extraídas da Decisão Crítica + Meta-metadados C521 de Execução de Regra (RE) C461. As regras C517 são convertidas em percepções por derivação de sintaxe de regras (RSD) C504. O PM 5532, em seguida, faz referência aos meta-metadados para determinar, na entrada 5534, se houve forte sobreposição interna e corroboração das percepções usadas. Se a resposta à Entrada 5534 for Sim 5538, isso indica um Voto de Confiança 5544 do CTMP 124 como uma saída modular. Se a resposta à Entrada 5534 for No 5536, a Etapa 5540 será ativada, que seleciona as decisões menos arriscadas percebidas entre a Decisão Intuitiva C514 e a Decisão de Pensamento C515. Portanto, a Decisão Crítica Final 5542 é subsequentemente enviada como uma saída modular para o CDO C462, TOC C513 e CTMP 124. A lógica na Etapa 5534 ocorre para determinar se a falta de unidade entre a Decisão Intuitiva C514 e a Decisão de Pensamento C515 ocorre devido a uma falta geral de confiança algorítmica ou devido a visualizações altamente opostas entre os dois. Portanto, se a segunda ocorrer, uma decisão crítica final
Petição 870200056145, de 06/05/2020, pág. 344/1737
342/754 potencial 5542 ainda é discernivel como uma saída modular. Um Voto de Não Confiança 5544 sempre leva à rota lógica do Resultado de Baixa Confiança C845 dentro do Apelo Racional (RA) C811A. A Decisão Crítica Final 5542 pode levar ao caminho lógico do Resultado de Alta Confiança C846 ou do Resultado de Baixa Confiança C845 na RA C811A, dependendo da confiança algorítmica por trás da Decisão Final Crítica 5542.
[764] A Fig. 670 mostra o processamento do Mecanismo de Investigação (ARM) 134 com base no Escopo de Ameaça à Segurança 8322. O ARM 134, que constantemente tenta fornecer ao CKR 648 novos insights para melhorar a capacidade geral de estimativa e tomada de decisão de LOM 132. Espera-se que o Escopo de Ameaças de Segurança 8322 acabe cedendo a conceitos sobre os quais o CKR 806 tenha pouca ou nenhuma informação, conforme indicado na Lista de conceitos solicitados, mas ainda não disponíveis, C857B com a Classificação e Priorização de Conceitos (CSP) C821B, as Definições de Conceitos são recebidas de três fontes independentes e são agregadas para priorizar os recursos (largura de banda etc.) do Pedido de Informações (IR) C812B. Esse módulo de infravermelho C812B acessa fontes relevantes para obter informações definidas especificamente neste caso no Escopo de Ameaças à Segurança 8322. Essas informações são definidas de acordo com o tipo de conceito. Essa fonte é indicada como Fonte de Notícias Públicas do C857C (artigos de notícias públicas, por exemplo, Reuters, New York Times, Washington Post etc.), Arquivos de Dados Públicos do C857D (coleções de agregados de informações, como Wikipedia, Quora etc.) e C857E Mídias sociais (por exemplo, Facebook, Twitter etc.). Os dados fornecidos por essas fontes de
Petição 870200056145, de 06/05/2020, pág. 345/1737
343/754 informação são recebidos e analisados sintaticamente no Agregador de informações (IA) C821B, de acordo com a definição do conceito solicitado. Os metadados relevantes, como tempo de recuperação e fonte de recuperação, são mantidos. Portanto, as informações são enviadas para a Análise de Referência Cruzada (CRA) C814B, onde as informações recebidas são comparadas e construídas considerando o conhecimento preexistente da CKR 648. Isso permite que novas informações recebidas sejam avaliadas de acordo com a CKR 648 atualmente conhece e não sabe. A Digitalização Estilométrica (SS) C808B é um módulo suplementar que permite ao CRA C814B considerar que as Assinaturas Estilométricas assimilarão as novas informações com o conhecimento preexistente do CKR 648. Os conceitos de dependência ausentes C857F são conceitos que são logicamente necessários para serem entendidos como trabalho preliminar. Para entender um conceito objetivo inicial, por exemplo, para entender como um caminhão funciona, é preciso primeiro investigar e entender como os motores a diesel funcionam. Tais conceitos ausentes são transferidos para o CSP C821B para processamento. A Lista de conceitos ativos do C857G é um tema popular classificado como o mais ativo no CKR 648. Esses conceitos do C857G são transferidos para o Gerador de Conceito Criativo (CCG) C820B e depois emparelhados criativamente (via Módulo de criatividade 112) para produzir novos conceitos em potencial. Esse mecanismo depende da possibilidade de uma dessas misturas dar lugar a novas faixas de informações das fontes C857C, C857D, C857E conectadas ao IR C812B. Exemplo de uso de estilometria: Os Novos Dados Externos do C858A são marcados como provenientes de um repórter da CNN conhecido. No entanto, um
Petição 870200056145, de 06/05/2020, pág. 346/1737
344/754 emparelhamento estilométrico bastante forte com a assinatura de um think tank militar. Portanto, o conteúdo é atribuído principalmente dentro da CKR 648 ao Centro de Estudos Militares e é anotado como tendo 'declarado' ser da CNN. Isso permite mais correspondência de padrões e detecção de conspiração para execuções subsequentes da lógica LOM (por exemplo, desconfiando de futuras declarações de conteúdo da CNN) . Portanto, estima-se a confirmação de afirmações, conflitos e avaliações de preferências como se o conteúdo fosse do centro de estudos e não da CNN.
[765] A Fig. 671 continua o ASH 8044 da Fig. 670 na Etapa 8302. As informações resultantes e novas não confirmadas são armazenadas e prosseguem no CKR 648. A Retenção Central de Conhecimento (CKR) 648, é onde a inteligência baseada em dados LOM é armazena e une. As unidades de informação são armazenadas no Formato de Conhecimento da Unidade (UKF) C854F. O UKF C854F é constituído por uma cadeia de variantes do UKF ligadas entre si para definir informações separadas por jurisdição (tempo e fonte são definidos dinamicamente). Os Grupos de Conhecimento C854F da UKF são processados pelo KCA C816D para formar o Conceito 8323 de Ameaça à Segurança. A Análise de Corroboração do Conhecimento (KCA) 816D é onde as informações agrupadas do UKF são comparadas para corroborar evidências a respeito de uma postura tendenciosa. Esse algoritmo leva em consideração a confiabilidade da fonte atribuída, quando essa afirmação foi feita, negando as evidências. Portanto, depois que o processamento do KCA C816D estiver concluído, o CKR 648 poderá gerar uma postura de tendência concluída em um tópico 8322.
Petição 870200056145, de 06/05/2020, pág. 347/1737
345/754
[766] A Fig. 672 continua a ASH 8044 da Fig. 671 com a elaboração do ARM 134 e CKR 648. A Lista de Conceitos Ativos C857G são tópicos populares que são classificados como os mais ativos na CKR 648. Esses conceitos C857G são transferidos para o Gerador de Conceitos criativos (CCG) C820B e depois emparelhados criativamente (via Módulo de criatividade 112) para produzir novos conceitos em potencial.
[767] A Fig. 673 mostra o estágio 8034, em que o LOM tira declarações e conclusões significativas sobre segurança, produzindo assim a conscientização sobre ameaças à segurança que é enviada ao AST 123 para referência ao estágio 8308. O AST 123 recebe o Desvio de Vulnerabilidade de Segurança (SED) 8324 (conjunto de regras de segurança) que é avaliada com uma exploração artificial, onde, após a exploração, o módulo de feedback de resultados oferece o resultado se a exploração funcionou e se deve ser incorporada no Exploit da DB A192, onde o módulo de liberação de informações fornece detalhes ao módulo Criatividade 112 sobre a aparência da próxima exploração, onde as informações são unidas entre o módulo de liberação de informações e o Exploit da DB A192, onde a vulnerabilidade é executada como um grupo de vulnerabilidades de segurança coletada A193 e simultaneamente com a mesma vulnerabilidade, em que o Módulo o da Criatividade produz uma vulnerabilidade híbrida que utiliza os pontos fortes das vulnerabilidades anteriores e evita fraquezas conhecidas nas vulnerabilidades com base no resultado do módulo de liberação de informações.
[768] A Fig. 674 continua o ASH 8044 da Fig. 673, em que a Conscientização sobre Ameaças à Segurança 8306 recebeu do
Petição 870200056145, de 06/05/2020, pág. 348/1737
346/754
LOM para o AST 123. Na etapa 8326, a versão mais recente do AST 123, aprimorada pelo LOM 132, é referenciada pelo I2GE. 122 e LIZARD 120.
[769] A Fig. 675 continua a ASH 8044 da Fig. 674 com detalhes do processamento do LIZARD 120 AST 123. O Núcleo Estático C315 é onde a codificação embutida dos módulos de programas fixos foi realizada predominantemente por programadores humanos. O módulo de Iteração C314 modifica, cria e destrói de forma inteligente os módulos no compartimento dinâmico C198. Usa a ameaça de segurança artificial (AST) 123 para uma referência de desempenho de segurança e usa o Núcleo de Iteração C347 para processar a metodologia de gravação automática de código. O Núcleo de Iteração C314 é a principal lógica para iterar o Gabinete Dinâmico C198 para aprimoramentos de segurança. Com o Núcleo Estático de Clonagem C346, o Núcleo Estático C315, incluindo o Núcleo Externo C329 semi-dinâmico, é usado como critério para orientação da iteração. As informações comportamentais de malware são transferidas por meio do Relé de Retorno de Dados (DRR) C317 para o AST 123 para se beneficiar de iterações futuras.
[770] A Fig. 676 continua a ASH 8044 da Fig. 675 com detalhes do processamento do LIZARD AST 123. No Núcleo Estático C315, o Conjunto de Regras de Segurança 5562 fornece o Feedback de Resultado 5564 e a Liberação de Informações 5566, de volta ao AST 123. Ameaça de Segurança Artificial (AST) 123 fornece um cenário hipotético de segurança para testar a eficiência de conjuntos de regras de segurança. As ameaças à segurança são consistentes em gravidade e tipo, para fornecer uma comparação
Petição 870200056145, de 06/05/2020, pág. 349/1737
347/754 significativa dos cenários de segurança.
[771] A Fig. 677 continua o ASH 8044 da Fig. 676, com detalhes sobre o processamento I2GE do AST 123. O AST 123 é recebido no C867A, que envia um relatório 5572 ao Módulo de Revisão de Segurança 5568 e pelo Enviar Mais 5570 de volta ao AST 123. I2GE 122 possui Caminhos evolutivos paralelos que são amadurecidos e selecionados. As gerações iterativas se adaptam à mesma ameaça de segurança artificial (AST) 123, e a rota com os melhores traços de personalidade acaba sendo mais resistente a ameaças à segurança. A rota evolutiva C867A é uma série virtualmente contida e isolada de geração de jogos de regras. As Características e Critérios evolutivos são definidos por essa Rota X Personalidade C867D.
[772] A Fig. 678 continua o processamento do ASH 8044 com o LIZARD 120 que recebe o fluxo de execução (código) do ESC 6700 da Appchain Objetivo 6060 na etapa 8328. Na etapa 8330, o LIZARD faz um loop através das invocações do módulo de iteração, que se refere ao AST 123. Etapa 8332, uma vez considerada estável enquanto sob ataque pelo AST 123, o LIZARD 120 envia o Fluxo de Execução (código) I2GE 122 para Emulação Mista.
[773] A Fig. 679 continua o ASH 8044 com o LIZARD 120 executando a Execução 556 da Appchain Objetivo 6060 recebida via ESC 6700. O Módulo de Iteração (IM) C314 modifica, cria e destrói de forma inteligente os módulos no Gabinete Dinâmico C198. Usa a Ameaça de Segurança Artificial (AST) 123 para obter uma referência de desempenho de segurança e usa o Núcleo de Iteração C347 para processar a metodologia de gravação automática de código. O C347 Núcleo de Iteração é a principal lógica para
Petição 870200056145, de 06/05/2020, pág. 350/1737
348/754 iterar o C198 Gabinete Dinâmico para aprimoramentos de segurança. 0 Módulo de Iteração (IM) C314 usa o Núcleo Estático (SC) C315 para modificar sintaticamente o código base de acordo com a finalidade definida nos dados.
[774] A Fig. 680 continua o ASH 8044 com o I2GE 122 executando a Evolução Iterativa (um subconjunto do I2GE 122), que é o método pelo qual os Caminhos de Evolução C867AA e C867AB paralelos são amadurecidos e selecionados. As rotas evolutivas 34C867AA e C867AB são uma série virtualmente contida e isolada de gerações de jogos de regras. As características e critérios são definidos por essas Personalidades de rota C867DB e C867DA. As gerações iterativas se adaptam ao mesmo AST 123, e a rota com os melhores traços de personalidade acaba resistindo ainda mais ao conceito de traços. Ao usar o Isolamento Virtual 390, os dois caminhos evolutivos são praticamente isolados para garantir que suas iterações sejam baseadas apenas no julgamento de suas próprias personalidades. O sistema de monitoramento/iteração C868D é a plataforma que injeta os acionadores de dados conceituais do AST 123.
[775] A Fig. 681 mostra o ASH 8044 na etapa 8332. Uma vez considerado estável enquanto sob ataque pelo AST 123, o LIZARD 120 envia o fluxo de execução (código) para o I2GE 122 para emulação variada. O I2GE 122 recebe o fluxo de execução (código) endurecido da App Objetivo 60 6060 na etapa 8334 e o I2GE 122 executa a emulação variável do código com o AST 123 por caminhos evolutivos na etapa 8336. Na etapa 8338, verifica para ver se o Fluxo de execução (código) passa a emulação mista I2GE. Passa 8348 e No Passa 8342.
Petição 870200056145, de 06/05/2020, pág. 351/1737
349/754
[776] A Fig. 682 continua o ASH 8044 da Fig. 181 com o I2GE 122 executando uma Evolução Iterativa (como um subconjunto do I2GE 122), que é o método no qual os Caminhos de Evolução C867AA e C867AB paralelos são amadurecidos e selecionados. Os Caminhos evolutivos 34C867AA e C867AB são séries virtuais isoladas de gerações de jogos de regras. As características e critérios evolutivos são definidos por Rota de Personalidade Total C867DB e C867DA. As gerações iterativas se adaptam ao mesmo AST 123, e a rota com as melhores características de personalidade acaba resistindo ainda mais ao conceito de características. Ao usar o Isolamento Virtual 390, os dois caminhos evolutivos são praticamente isolados para garantir que suas iterações sejam baseadas apenas no julgamento de suas próprias personalidades. O Sistema de Monitoração/Interação C868D é a plataforma que injeta os gatilhos de dados conceituais do AST 123. O Processador de Conclusão da Iteração 5554 fornece os resultados de saída: Passe 8348 e Não Passe 8342 (Fig. 682 estão faltando as tags 8348 e 8342).
[777] A Fig. 683 conclui o processo de proteção de Segurança da Appchain (ASH) 8044. Na etapa 8338, o fluxo de execução (código) passa a emulação mista I2GE 120. Se Não for aprovado no 8342, o Fluxo de Execução (código) é encaminhado para o LIZARD para ser reprogramado de acordo com os critérios do LOM 132, conforme entendido pelo AST 123 na Etapa 8346. Se passa no 8340 na Etapa 8344, cria um Patch de Implantação que contém configurações de segurança reforçadas pelo Montagem de Patch de Implantação (DPA) 6260 e na Etapa 8348 da Implantação do Patch 6270 de correção da Appchain no Construtor de Ecossistemas
Petição 870200056145, de 06/05/2020, pág. 352/1737
350/754
Customchain (CEB) 584 para a Appchain de destino 6060
[778] A Fig. 684 mostra a Conformidade Normativa da Appchain (ARC) 8046, que garante que a Appchain 836 ou Programa Legado selecionado esteja em conformidade com vários regulamentos específicos (por exemplo, conformidade com a API REST etc.). Na Etapa 8350, o LIZARD 120 interpreta a sintaxe da Appchain Objetivo 6060 através do módulo de sintaxe C35 e produz um Mapa de Hierarquia de Finalidades (PHM) 8354 da Appchain Objetivo 6060 através do módulo Etapa 8352. Etapa 8358 O LIZARD 120 interpreta os Regulamentos do Sistema e Sintaxe de Orientação e produz um Mapa de Hierarquia de Propósito (PHM) 8362 de Regulamentos e Guias do Sistema através do Módulo de Propósito C36.
[779] A Fig. 685 mostra detalhes sobre a operação do LIZARD 120 para converter os Regulamentos e Guias do Sistema 8356 em um Mapa de Hierarquia de Propósitos 8362. Os Regulamentos e Guias do Sistema 8356 são enviados da LUIGI 116 para o Módulo de sintaxe C35 (SM) que pertence à jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código; recebe um Formulário de finalidade complexa C325 do Módulo de finalidade (PM) C36. O C325 Formato de Propósito Complexo é então escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O Pseudocódigo contém implementações básicas de operações de computação que são mais comuns entre todas as linguagens de programação, como instruções yes/no, while etc. Portanto, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação de destino desejada
Petição 870200056145, de 06/05/2020, pág. 353/1737
351/754 (linguagem de computação) . Para ler o código; o SM C35 fornece uma interpretação sintática do código de computação do PM C36 para derivar uma finalidade para a funcionalidade desse código. Os Regulamentos e Guias do Sistema 8356 são recebidos no formato de Fluxo de dados 6550 pela Tradução de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pela SM C35 em qualquer linguagem de computação escolhida e conhecida. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saída da execução completa da Tradução de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições das Regras e Sintaxe da C322. Portanto, a execução concluída da Redução Lógica C323, a execução do caso SM C35 correspondente é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para derivar uma finalidade no formato de finalidade complexa C325 do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade desejada da seção de código relevante, conforme interpretada por SM C35. O PM C36 também é capaz de detectar trechos de código secretamente incorporados aos dados (binários/ASCII etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada no Formato de Propósito Complexo C325 ao se referir à Associação de Propósito C326. O Núcleo Interno (IC) C333 é a área do LIZARD 120 que não
Petição 870200056145, de 06/05/2020, pág. 354/1737
352/754 passa por manutenção/autoprogramação automatizada e é direta e exclusivamente programada por especialistas na área relevante. 0 elemento de código principal C335 do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e gerenciamento de memória. Portanto, o Código Principal C335 permite a operação e a funcionalidade geral do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. Os elementos dos Objetivos do Sistema C336 do IC C333 definem os Objetivos de Política de Segurança e Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[780] A Fig. 686 continua o fluxo lógico da Fig. 685 para ilustrar a operação do LIZARD 120 para converter Regulamentos do Sistema e Guias 8356 em um Mapa de Hierarquia de Propósitos 8362. A Redução Lógica C323 do Módulo Sintaxe (SM) C35 envia sua Saia para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada, consultando a Associação de Propósito C326. A saída da definição de finalidade existe em um formato de finalidade complexa C325, que é enviado como uma saída modular para PM C36 e, portanto, o Núcleo Externo (OC) C329 e, no LIZARD 120. A saída é rotulada como um Mapa de Hierarquia de Propósito 8362, apresentado como a versão de Formato de Propósito Complexo C325 das Regulamentações e Guias do Sistema 8356. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às
Petição 870200056145, de 06/05/2020, pág. 355/1737
353/754 funções e módulos acima mencionados.
[781] A Fig. 687 continua o fluxo lógico da Fig. 686 e na Etapa 8364 usa o Mapa de hierarquia de finalidades 8362 (recebido dos regulamentos e guias do sistema 8356) e o Mapa de hierarquia de finalidades 8354 (recebido do objetivo 6060) para determinar se algum dos Propósitos no Mapa derivado da Appchain Objetivo 6060 tem conflitos com algum dos Objetivos dos Regulamentos e Guias do Sistema no Processamento de Simetria de Propósito a Propósito (P2SP) 7000. Se nenhum conflito foi encontrado 8366, a Appchain Objetivo 6060 está em conformidade com os Regulamentos e Guias do Sistema 8356 no Estágio 8370. Se os conflitos forem encontrados 8368, no Estágio 8372, LUIGI 116 será informado da violação da Appchain dos Regulamentos e Guias do Sistema 8356.
[782] A Fig. 688 continua o fluxo lógico da Fig. 687 na Etapa 8374 para determinar se o LUIGI 116 confirmou independentemente que a Appchain em questão viola os Regulamentos e Guias 8356 do sistema. Se confirmado 8375, ajusta o mapa de hierarquia de finalidades 8354 da Appchain Objetivo 6060 para corresponder ao Mapa de Hierarquia de Propósito 8362 dos Regulamentos e Guias do Sistema 8356. Se não for confirmado 8378, uma sessão de revisão será iniciada para descobrir por que o ARC 8046 (portanto, o SPSI 130) e LUIGI 116 não concordam com a conformidade da Appchain.
[783] A Fig. 689 continua o fluxo lógico da Fig. 688 na Etapa 8380 Ajustando o mapa de hierarquia de finalidades 8354 da Appchain Objetivo 6060 para corresponder ao mapa de hierarquia de finalidades 8362 dos regulamentos e guias do sistema 8356,
Petição 870200056145, de 06/05/2020, pág. 356/1737
354/754
Confirmado no PRP 7050. O PRP 7050 envia o Mapa de finalidade avançada 8382 para o LIZARD 120. O LIZARD 120 converte o Mapa de finalidade avançada na sintaxe da Appchain para implantação na Appchain atualizado 6262.
[784] A Fig. 690 mostra detalhes sobre a operação do LIZARD 120 para converter o Mapa de finalidade aprimorada 8382 em um Appchain aprimorado 6262. O Mapa de finalidade aprimorada 8382 existe no Formato de finalidade complexa C325 e é enviado para a expansão iterativa C327 do módulo da Finalidade C36 dentro do Núcleo Externo (OC) C329 do LIZARD 120. A Expansão Iterativa C327 fornece detalhes e complexidade para evoluir uma meta simples para uma definição de finalidade complexa específica. Portanto, o potencial máximo de associação de finalidade C326 da entrada é obtido e retido como um formato de finalidade complexa C325, antes de ser enviado para a derivação lógica C320 do módulo de sintaxe (SM) C35. O elemento do Código Central C335 do Núcleo Interno (IC) C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de encadeamentos e balanceador de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade geral do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. Os elementos Objetivos do Sistema C336 do IC C333 definem os Objetivos de Segurança e Política da Empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[785] A Fig. 695 continua o fluxo lógico da Fig. 694 para ilustrar o filtro da etapa 8402 nos registros relacionados
Petição 870200056145, de 06/05/2020, pág. 357/1737
355/754 a colapsos/falhas/erros/problemas, etc. Na Etapa 8404, solicita informações baseadas em DLU relacionadas a colapsos/falhas/erros/problemas, etc. por meio de Filtros de Cluster UKF 5578. A Retenção de Cluster UKF C854F fornece informações aos Filtros de Cluster UKF 5578. A Retenção Central de Conhecimento (CKR) 648, que é onde a inteligência baseada nas informações LOM 132 armazenadas. As unidades de informações são armazenadas no Formato das Unidades de Conhecimento (UKF) dos quais existem três tipos: UKF1 5580, UKF2 5582, UKF3 5584. UKF2 5582B é o formato principal no qual as informações de destino são armazenadas no formato de sintaxe das regras (RSF) C538, destacado como Valor 5592. O índice 5586 é um ponto de referência compatível para armazenamento e processamento digital que permite referências eficientes de recursos de grandes coleções de dados. Esse bloco principal de informações refere-se a um carimbo de data/hora 5590, que é uma referência a uma unidade de conhecimento separada por meio do índice 5586, conhecido como UKF1 8550. Esta unidade não possui uma seção equivalente a carimbo de data/hora 5590, como possuía UKF2 5582, mas armazena diversas informações sobre registros de data e hora no Setor Valor 5592 no formato RSF C538. O Formato de Sintaxe de Regras (RSF) C538 é um conjunto de padrões sintáticos para manter um registro das regras de referência. Várias unidades de regra no RSF C538 podem ser aproveitadas para descrever um único objeto ou ação. UKF1 5580 contém um setor de Atribuição de origem 5588, que é uma referência ao índice 5586 de uma instância 5584. Essa unidade UKF3 5584 é a inversa de UKF1 5580, pois possui uma seção de carimbo de data/hora, mas não uma seção de atribuição de
Petição 870200056145, de 06/05/2020, pág. 358/1737
356/754 fonte. Isso ocorre porque UKF3 5584 armazenado na atribuição de origem 5588 e conteúdo 5588 em seu setor de valor 5592 no RSF C583. A atribuição de fonte é uma coleção complexa de informações que controla as fontes de informações reivindicadas. Essas fontes recebem estados de confiabilidade e autenticidade devido aos fatores que confirmam e negam como são processados na Análise de Corroboração do Conhecimento (KCA) C816D. Portanto, um UKF 5581 Cluster (não marcado na Fig. 695) é composto de uma cadeia de variantes do UKF ligadas para definir informações separadas por jurisdição (tempo e fonte são definidos dinamicamente). Em resumo: UKF2 5582 contém as principais informações de destino. 0 UKF1 5580 contém as informações de carimbo de data e hora e, portanto, omite o próprio campo de período para evitar infinito backspace. 0 UKF3 5584 contém informações sobre a atribuição da fonte e, portanto, omite o campo da própria fonte para evitar o retorno infinito. Cada UKF2 5582 deve ser acompanhado por pelo menos um UKF1 5580 e um UKF3 5584; caso contrário, o cluster (sequência) é considerado incompleto e as informações contidas ainda não podem ser processadas pela Lógica Geral do Sistema (LOM). Entre o UKF2 5582 central (com as informações centrais de destino) e suas unidades UKF1 5580 e UKF3 5584 correspondentes, pode haver unidades UKF2 5582 atuando como uma ponte interligada. A Análise de Corroboração da Informação (KCA) C816D é onde as informações do Cluster UKF são comparadas para corroborar as evidências relativas a uma postura dogmática. Esse algoritmo leva em consideração a confiabilidade da fonte atribuída quando tal alegação foi feita, negando evidências etc. O CKR 648 nunca remove informações, pois mesmo as informações consideradas falsas
Petição 870200056145, de 06/05/2020, pág. 359/1737
357/754 podem ser úteis para distinções futuras entre verdade e falsidade.
[786] A Fig. 696 continua a lógica da Fig. 695 na etapa 8396 para derivar contexto para todos os registros relacionados a erros por referência a outros registros encontrados na CKR 648. Circula entre todos os registros relacionados a erros na etapa 8406 e recupera as informações com base nos logs CKR relacionados ao Registro de erros selecionado na Etapa 8408. Na Etapa 8410, o comportamento contextual!zado é adicionado ao Retenção de Registros Relacionados a Erros (ERLR) 8412.
[787] A Fig. 697 mostra a Análise de Unidade de Registro de Diagnóstico (DLUA) 8048 na Etapa 8414, em que o LIZARD 120 deriva de um Mapa de Hierarquia de Propósito 8416 para o atual comportamento contextualizado que contém erros e na Etapa 8418 a parte Fluxo de Execução (código) que está produzindo o erro é recuperado da Appchain do destino 6060. A parte selecionada do segmento de execução (código) é processada por meio de uma Chamada Personalizada do IEC 8050 em 8420. O segmento Execução de Execução 8422 é executado em um ambiente I2GE 122 virtualizado em todo o fluxo de execução, para testar a Execução Unanimemente correta da Etapa 8424.
[788] A Fig. 698 mostra detalhes relacionados à operação do LIZARD 120 para converter o conteúdo completo da Retenção de registro relacionado a erros (ERLR) 8430 em um mapa de hierarquia de finalidades 8428. O conteúdo da Retenção de registro relacionada a erro (ERLR) 8430 é enviado ao módulo de sintaxe (SM) C35, que pertence à jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código
Petição 870200056145, de 06/05/2020, pág. 360/1737
358/754 digital. Escrever códigos; recebe o Formulário de finalidade complexa C325 do Módulo de finalidade (PM) C36. 0 formato de finalidade complexa C325 é então escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. 0 pseudocódigo contém implementações básicas de operações tecnológicas que são mais comuns entre todas as linguagens de programação, como instruções yes/no, while, etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real que depende da sintaxe do computador (idioma do computador) desejada. Para leitura de códigos; o SM C35 fornece uma interpretação sintática do código do computador, de forma que o PM C36 tenha um propósito para a funcionalidade desse código. A retenção de registros relacionados a erros (ERLR) 8430 é recebida no formato do fluxo de informações AO 6550 pela conversão de código C321. A Tradução de Código C321 é convertida em código arbitrário (genérico), que é reconhecido e entendido pela SM C35 para qualquer idioma de computador conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em diferentes tipos de sintaxe arbitrária. O resultado da execução da conversão de código C321 concluída é transferido como uma entrada na redução lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322 . Portanto, após a execução concluída da Redução Lógica C323, a execução da instância correspondente do SM C35 e a saída modular do SM C35 são enviadas para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para derivar uma finalidade no formato
Petição 870200056145, de 06/05/2020, pág. 361/1737
359/754 de finalidade complexa C325 do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção relevante do código, conforme interpretada por SM C35. 0 PM C36 também pode detectar trechos de código que se infiltram em informações (binárias/ASCII, etc.). A Interpretação Iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção/autoprogramação automática e é direta e exclusivamente programada por especialistas na área relevante. O elemento de código principal C335 do IC C333 contém quadros e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade gerais do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C333 C336 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[789] A Fig. 699 continua o fluxo lógico da Fig. 698 para ilustrar a operação do LIZARD 120 para converter todo o conteúdo do ERLR (retenção de registros relacionados a erros 8430) em um mapa de hierarquia de finalidades 8428. A redução lógica C323 do Módulo de Sintaxe (SM) C35 envia suas saídas para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36.
Petição 870200056145, de 06/05/2020, pág. 362/1737
360/754
Interpretação iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada, consultando as Associações de finalidade C326. A saida de definição de finalidade existe no formato de finalidade complexa C325, que é enviada como uma saida modular para PM C36 e, portanto, o Núcleo Externo (OC) C329 e, portanto, LIZARD 120. A saida é identificada como um Mapa de Hierarquia de Propósito 8428, apresentado como a versão do Formato de Propósito Complexo C325 da Retenção de Erros Relacionados a Registros (ERLR) 8430. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica a funções e módulos mencionados.
[790] A Fig. 700 mostra o estágio 8418 da análise de unidade de registro de diagnóstico (DLUA) 8084. A parte do segmento de execução (código) que está produzindo o erro é recuperada da Appchain Objetivo 6060. No estágio 8432, circula por todos os Registros de Erros de retenção contextuais (ERLR) 8430 na ordem Appchain e revisão 8434. A Appchain associada foi recuperada no registro de erros relacionados selecionado? Se Sim 8438, executar 8444. As informações de localização relacionadas ao registro de erros relacionados foram encontradas entre as varreduras? Se Não 9436, recupera o local da Appchain através do local de cache da Metachain da Appchain 8440 e gera solicitações para o conteúdo da Appchain por meio da Reivindicação de Gerador de Conteúdo (CCG) 3050.
[791] A Fig. 701 continua a lógica da Fig. 700 na etapa 8456. Examina o segmento de execução do fluxo de execução para obter detalhes relacionados às informações armazenadas nos registros ERLR 8430 e aos metadados varridos em relação ao fluxo
Petição 870200056145, de 06/05/2020, pág. 363/1737
361/754 de execução 8458. A etapa 8450 verifica se as informações de localização relacionadas ao registro de erros relacionados selecionado são encontradas na verificação. Se Sim, 8452, continua na Etapa 8420. A parte selecionada do Segmento de Execução (código) é processada por meio de uma chamada personalizada da Correção de Erro Inato (IC) 8050. Se Não, 8454, continua na Etapa 8446 Avance a circulação para o próximo erro contextual!zado disponível e circule por todos os logs de erros relacionados ao contexto ERLR 8430 na ordem Appchain na Etapa 8448 .
[792] A Fig. 702 continua a lógica da Fig. 701 com a Etapa 8460, o segmento de fluxo de execução refinado 8462 é executado em um ambiente I2GE virtualizado 122 dentro do fluxo de execução para testar uma execução naturalmente correta. No estágio 8466, é feita uma revisão. O segmento de execução refinada operou corretamente? Se Sim, 8468, LIZARD deriva um Mapa de Hierarquia de Propósito para o Segmento de Execução Refinado 8462 no Estágio 8464. Se Não, 8470, uma revisão é feita no Estágio 8476, essa instância DLUA foi chamada por uma fonte DLU de DLUA? Se sim, 8474 na etapa 8477 (rotulada incorretamente como 8476 na Fig. 702) A execução do módulo é finalizada com a saída modular nula. Se não, 8472, envie o Meta DLU para o DLU 1182.
[793] A Fig. 703 continua a lógica da Fig. 702 com a etapa 8420. A parte selecionada do segmento de execução (código) é processada por meio de uma chamada personalizada de Correção de Erro Inato (IEC) 8050. O segmento de fluxo de execução refinado 8462 ele é instalado em seu local apropriado no Fluxo de Execução556. O Fluxo de Execução Refinado é enviado ao I2GE 122
Petição 870200056145, de 06/05/2020, pág. 364/1737
362/754 para processamento de emulação em 8480.
[794] A Fig. 704 continua a lógica da Fig. 703 com a Etapa 8460. O segmento de fluxo de execução refinado 8462 é executado em um Ambiente I2GE Virtualizado 122 dentro de todo o fluxo de execução para revisar a execução correta. O Fluxo de Execução Refinado AO 8480 é recebido pelo caminho evolutivo A C867AA e pelo caminho evolutivo B C867AB para iniciar o processo. O I2GE 122 executa Evolução Iterativa (um subconjunto do I2GE 122), que é o método pelo qual os C867AA e C867AB paralelamente os Caminhos Evolutivos amadurecem e são selecionados. Os Caminhos Evolutivos 34C867AA e C867AB são uma série de gerações de réguas praticamente contida e isolada. As características e os critérios evolutivos são definidos pelas referidas personalidades das estradas C867DB e C867DA. As gerações iterativas se adaptam ao mesmo AST 123 e o caminho com as melhores características de personalidade acaba resistindo mais às ameaças conceituais do que as outras. Ao usar o Isolamento Virtual 390, os dois caminhos evolutivos são praticamente isolados para garantir que suas iterações sejam baseadas apenas nos critérios de suas próprias personalidades. O Sistema de Monitoração/Interação C868D é a plataforma que injeta os gatilhos de risco para informações conceituais AST 123. O Processador de Conclusão Iterative 5554 fornece os principais resultados: Sim 8384 e Não 8342.
[795] A Fig. 705 continua a lógica da Fig. 704 com o LIZARD 120 dirigindo um Mapa de Hierarquia de Finalidade 8488 para o atual comportamento contextualizado que contém erros na Etapa 8486. Ajustando o Mapa de Hierarquia de Finalidade 8488 da Appchain de Destino para incluir o Mapa 8494 do Segmento de
Petição 870200056145, de 06/05/2020, pág. 365/1737
363/754
Execução Refinado no Estágio 8490 no Processamento de Realinhamento de Propósito (PRP) 7050 para produzir o Mapa de Propósito Aprimorado 8496. A LIZARD também deriva um Mapa de Hierarquia de Propósito 8494 para o Segmento de Execução Refinado 8462 no Estágio 8492.
[796] A Fig. 706 mostra detalhes sobre a operação do LIZARD 120 para converter o Registro de Erros Contextualizado 8500 em um Mapa de Hierarquia de Propósito 8502. O Registro de Erros Contextualizados 8500 é enviado ao Módulo de Sintaxe (SM) C35 pertencente ao Jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de códigos de computador. Para escrever códigos; recebe o Formato de Propósito Complexo C325 do Módulo de finalidade (PM) C36. O Formato de Propósito Complexo C325 é então escrito em código sintático arbitrário, também conhecido como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de computação que são mais comuns entre todas as linguagens de programação, como instruções yes/no, while, etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real que depende da sintaxe do computador (idioma do computador) desejada. Para leitura de códigos; o SM C35 fornece uma interpretação sintática do código do computador, de forma que o PM C36 tenha um propósito para a funcionalidade desse código. O Registro de Erro Contextual 8500 é recebido em um formato de dados/fluxo de execução 8501 misto da conversão de código C321. A Tradução de Código C321 é convertida em código arbitrário (genérico), que é reconhecido e entendido pela SM C35 para qualquer idioma de computador conhecido e escolhido. A Tradução De código C321 também executa
Petição 870200056145, de 06/05/2020, pág. 366/1737
364/754 a função inversa de traduzir linguagens de computador conhecidas em diferentes tipos de sintaxe arbitrária. 0 resultado da Execução da Conversão de Código C321 concluída é transferido como uma entrada na Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, após a execução concluída da Redução Lógica C323, a execução da instância correspondente do SM C35 e a saída modular do SM C35 são enviadas para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma finalidade no formato de finalidade complexa C325 do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção relevante do código, conforme interpretada por SM C35. 0 PM C36 também pode detectar trechos de código que se infiltram em informações (binárias/ASCII, etc.). A Interpretação Iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção/autoprogramação automática e é direta e exclusivamente programada por especialistas na área relevante. O elemento de código principal C335 do IC C333 contém quadros e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade gerais do SM C35 e PM C36, fornecendo bibliotecas e scripts
Petição 870200056145, de 06/05/2020, pág. 367/1737
365/754 padronizados que permitem a funcionalidade básica. 0 elemento dos Objetivos do Sistema C333 C336 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[797] A Fig. 707 continua o fluxo lógico da Fig. 706 para ilustrar a operação do LIZARD 120 para converter todo o conteúdo do Registro de Erros Contextual!zado 8500 em um Mapa de Hierarquia de Propósitos 8502. A Redução lógica C323 do Módulo de sintaxe (SM) C35 envia suas saídas para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada, consultando as Associações de finalidade C326. A Saída de Definição de Finalidade existe no formato de finalidade complexa C325, que é enviada como uma saída modular para PM C36 e, portanto, o Núcleo Externo (OC) C329 e, portanto, LIZARD 120. A saída é identificada como um Mapa de Hierarquia de Propósito 8502, apresentado como o Registro de Erro Contextual!zado 8500 do Formato de Propósito Complexo C325. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às funções e módulos mencionados.
[798] A Fig. 708 mostra detalhes sobre a operação do LIZARD 120 para converter o segmento de execução refinado 8462 no mapa de hierarquia de finalidades 8494. O Segmento de Execução Refinado 8462 é enviado ao módulo de sintaxe (SM) C35, que pertence a jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de códigos de computador. Para escrever códigos; recebe o Formulário de
Petição 870200056145, de 06/05/2020, pág. 368/1737
366/754 finalidade complexa C325 do Módulo de finalidade (PM) C36. 0 Formato de Propósito Complexo C325 é então escrito em código sintático arbitrário, também conhecido como 'pseudocódigo'. 0 pseudocódigo contém implementações básicas de operações de computação que são mais comuns entre todas as linguagens de programação, como instruções yes/no, while, etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real que depende da sintaxe do computador (idioma do computador) desejada. Para leitura de códigos; o SM C35 fornece uma interpretação sintática do código do computador, de forma que o PM C36 tenha um propósito para a funcionalidade desse código. 0 segmento de execução refinado 8462 é recebido no formato de fluxo de informações de conversão de código C321. A Tradução De código C321 é convertida em código arbitrário (genérico), que é reconhecido e entendido pela SM C35 para qualquer idioma de computador conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em diferentes tipos de sintaxe arbitrária. 0 resultado da Execução da Conversão de Código C321 concluída é transferido como uma entrada na redução lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322 . Portanto, após a execução concluída da Redução Lógica C323, a Execução da Instância Correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma finalidade no formato de finalidade complexa C325 do Código do
Petição 870200056145, de 06/05/2020, pág. 369/1737
367/754
Computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção relevante do código, conforme interpretada por SM C35. 0 PM C36 também pode detectar trechos de código que se infiltram em informações (binárias/ASCII, etc.) . A Interpretação Iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção/autoprogramação automática e é direta e exclusivamente programada por especialistas na área relevante. O elemento de código principal C335 do IC C333 contém quadros e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade gerais do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C333 C336 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[799] A Fig. 709 continua o fluxo lógico da Fig. 708 para ilustrar a operação do LIZARD 120 para converter o segmento de execução refinado 8462 no mapa de hierarquia de finalidades 8494. A redução lógica 0323 do módulo de sintaxe (SM) 035 envia suas saídas à Interpretação Iterativa 0328 do Módulo de Propósito (PM) 036. A Interpretação Iterativa 0328 circula por todas as
Petição 870200056145, de 06/05/2020, pág. 370/1737
368/754 funções interconectadas para produzir uma definição de finalidade interpretada, consultando as Associações de finalidade C326. A Saída de Definição de Finalidade existe no formato de finalidade complexa C325, que é enviada como uma saída modular para PM C36 e, portanto, o Núcleo Externo (OC) C329 e, portanto, LIZARD 120. A saída é identificada como um Mapa de Hierarquia de Propósito 8494, apresentado como a versão do Formato de Propósito Complexo C325 do Registro de Erros Contextualizado 8500. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às funções e módulos mencionados.
[800] A Fig. 710 mostra a Análise de Unidade de registro de Diagnóstico (DLUA) 8048 na etapa 8490. Ajuste ao mapa de hierarquia de objetivos da Appchain de destino para incluir o mapa de segmentos de Execução Refinados no Processamento de Realinhamento de Objetivos (PRP) 7050. O LIZARD converte o Mapa de Propósito Aprimorado 8496 em uma Sintaxe da Appchain no Estágio 8500. A Appchain 6262 aprimorada é enviado para Implantar
o Conjunto de Patches (DPA) 62 60 e, no Estágio 8502, implementa
o Patch de correção da Appchain no Criador de Ecossistema
Customchain (CEB) 584.
[801]A Fig. 711 mostra o Novo Desenvolvimento de
Appchain (NAD) 8052, onde o LIZARD 120 conduz um Mapa de
Hierarquia de Propósitos para todo o ecossistema Customchain da Plataforma UBEC 8506. Interpreta áreas no Mapa de Hierarquia de Propósitos de sobreposição, cooperação e conflito 8508 potenciais. A Revisão de cooperação e conflito de lapela (OC3) 8520 é enviada ao Mapa OC3 8522. O LOM recebe o Mapa OC3 8510. Novas alterações propostas 8512 recebidas do OC3 8520 da
Petição 870200056145, de 06/05/2020, pág. 371/1737
369/754
Mecanismo de Doação de Appchain (ASM) 6066 são enviadas ao Ato de Modificação com Princípios (PMA) 8620.
[802] A Fig. 712 mostra detalhes sobre a operação do LIZARD 120 para converter todo o ecossistema Customchain da plataforma UBEC 100 em um Mapa de Hierarquia de Finalidades 8506. A plataforma UBEC 100 é enviada ao módulo de sintaxe C35 (SM), que pertence à jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de códigos de computador. Para escrever códigos; recebe o Formulário de finalidade complexa C325 do Módulo de finalidade (PM) C36. 0 C325 Formato de Propósito Complexo é então escrito em código sintático arbitrário, também conhecido como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de computação que são mais comuns entre todas as linguagens de programação, como instruções yes/no, while, etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real que depende da sintaxe do computador (idioma do computador) desejada. Para leitura de códigos; o SM C35 fornece uma interpretação sintática do código do computador, de forma que o PM C36 tenha um propósito para a funcionalidade desse código. A plataforma UBEC 100 é recebida em um formato misto de execução/fluxo de dados 8501 por conversão de código C321. A Tradução de Código C321 é convertida em código arbitrário (genérico), que é reconhecido e entendido pela SM C35 para qualquer idioma de computador conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em diferentes tipos de sintaxe arbitrária. O resultado da Execução da Conversão de Código C321 concluída é transferido como uma
Petição 870200056145, de 06/05/2020, pág. 372/1737
370/754 entrada na redução lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, após a execução concluída da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para derivar uma finalidade no formato de finalidade complexa C325 do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção relevante do código, conforme interpretada por SM C35. O PM C36 também pode detectar trechos de código que se infiltram em informações (binárias/ASCII, etc.). A Interpretação Iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. O Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção/autoprogramação automática e é direta e exclusivamente programada por especialistas na área relevante. O elemento de código principal C335 do IC C333 contém quadros e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade gerais do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C333 C336 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como
Petição 870200056145, de 06/05/2020, pág. 373/1737
371/754 variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[803] A Fig. 713 continua com o Fluxo Lógico da Fig.
712 para ilustrar a operação do LIZARD 120 para converter todo o Ecossistema CUSTOMCHAIN da Plataforma UBEC 100 em um mapa De Hierarquia de Finalidades 8506. A redução lógica C323 do Módulo de Sintaxe (SM) C35 envia suas saídas para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada, consultando as Associações de finalidade C326. A saída de definição de finalidade existe no C325 Formato de Propósito Complexo, que é enviado como uma saída modular para PM C36 e, portanto, o Núcleo Externo (OC) C329 e, portanto, LIZARD 120. A saída é identificada como um Mapa de Hierarquia de Finalidades 8506, apresentado como a versão do Formato de Propósito Complexo C325 da plataforma UBEC 100. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às funções e módulos mencionados.
[804] A Fig. 714 mostra a Revisão de cooperação e conflito de lapela (OC3) 8520, onde a LIZARD processa todo o mapa de hierarquia de finalidades para categorizar os elementos de finalidade individuais em faixas de finalidades 8522. As faixas de finalidades 8524 consistem na faixa A 8526, Banda B 8528, Banda C 8530 e Banda D 8532. A Organização de Zonas de Propósito de Banda (PBZO) 8536 recebe as Faixas de Propósito 8524 e Organiza as Bandas de Propósito nas zonas comuns 8534.
[805] A Fig. 715 mostra detalhes sobre a operação do LIZARD 120 para converter o Mapa de hierarquia de finalidades
Petição 870200056145, de 06/05/2020, pág. 374/1737
372/754
8506 em uma série de faixas de finalidades 8524. O Mapa de hierarquia de finalidades 8506 existe no Formato de Finalidades Complexa C325 e é enviado para a expansão iterativa C327 do módulo de finalidade C36 no núcleo externo LIZARD 120 C329. A expansão iterativa C327 adiciona detalhes e complexidade para evoluir para uma meta simples em uma definição especifica de finalidade complexa. Portanto, o potencial máximo da Associação de Propósito C326 da entrada é realizado e retido como um Formato de Propósito Complexo C325, antes de ser enviado para a Derivação Lógica C320 do Módulo de Sintaxe (SM) C35. O elemento do Código Central C335 do Núcleo Interno (IC) C333 contém frameworks e bibliotecas fundamentais, scripts de gerenciamento de cabos e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade gerais do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C333 C336 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[806] A Fig. 716 continua o fluxo lógico da Fig. 715 para ilustrar a operação do LIZARD 120 para converter o Mapa de Hierarquia de Finalidades 8506 em uma série de faixas de finalidades 8524. As informações de entrada são recebidas no formato de finalidades complexas 0325 do módulo da Finalidade (PM) 036 e é transferido para a Derivação Lógica 0320 do Módulo de Sintaxe (SM) 035. A derivação lógica 0320 deriva as funções
Petição 870200056145, de 06/05/2020, pág. 375/1737
373/754 logicamente necessárias de funções inicialmente mais simples. Isso significa que, se uma função puder ser formada como uma função derivada devido à implicação de uma função pai mais simples, ela será formada por uma Derivação lógica C320. A saida produzida é uma árvore de dependências de funções que são construídas de acordo com as informações definidas no Formato de Finalidade Complexa C325. A Derivação Lógica C320 opera de acordo com as definições das Regras e Sintaxe C322 que são herdadas do elemento do Código Central do Núcleo Interno (IC) C333 e da Coleção de Bibliotecas do Sistema de Destino 9442 por meio da Interpretação e Detecção do Sistema de Destino (TSID). A derivação lógica C320 envia seus resultados para a tradução de código C321. A tradução de código C321 é convertida em código arbitrário (genérico), que é reconhecido e entendido pela SM C35 para qualquer idioma de computador conhecido e escolhido. A tradução de código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em diferentes tipos de sintaxe arbitrária. Portanto, o PM C36 chama o SM C35 para produzir a versão Banda resultante da entrada do Mapa de Hierarquia de Propósito 8506 por meio da Conversão de Código C321. A unidade de faixas de finalidade 8524 resultantes que é produzida terminalmente pela tradução de código C321 é a saída modular do SM C35, do núcleo externo (OC) C329 e do LIZARD 120.
[807] A Fig. 717 mostra a Revisão de Cooperação e Conflito de Lapela (OC3) 8520. A Organização de Zonas de Propósito de Banda (PBZO) 8536 organiza as Faixas de Propósito nas Zonas Comuns 8534, usando a Zona A 8538, Zona B 8540, Zona C 8542 e Zona D 8544 ao circular através de cada zona 8546.
Petição 870200056145, de 06/05/2020, pág. 376/1737
374/754
[808] A Fig. 718 continua o fluxo lógico da Fig. 717 para ilustrar a operação de CTMP 124, LOM 132 e I2GE 122 para desenvolver o Mapa 8522 OC3. A série de etapas começa com 8546 Circulando através de cada zona, 8548 Circulando através de cada banda da zona selecionada, 8550 Encontrando os elementos de finalidade que melhor correspondem e 8552 Encontrando jurisdições da Appchain dos elementos de finalidade. A LOM avalia as jurisdições Appchain selecionadas como uma unidade coletiva em relação à conformidade com os Princípios de design 8554 e as Novas alterações propostas 8558 são produzidas de acordo com a avaliação realizada 8556 com base nas informações de LOM 132 e I2GE 122. CTMP 124 e LOM 132 Eles interagem diretamente conforme necessário para todas as interações.
[809] A Fig. 719 continua o fluxo lógico da Fig. 718 para ilustrar a operação do LIZARD 120 para desenvolver o Mapa 8522 OC3. LIZARD deriva um Mapa de Hierarquia de Propósito 8564 para Novas Alterações Propostas 8560 (com base em uma avaliação realizada 8558) . Em 8566, produza o mapa OC3 através da afinidade mestre/escravo 1480, dentro do processamento de realinhamento de finalidade (PRP) 7050, que recebe o mapa de hierarquia de propósito 8564 e o mapa de hierarquia de objetivo 8564 da plataforma UBEC 100 para criar o mapa 8522 OC3 . As Novas Alterações Propostas 8560 também são submetidas à Ação de Modificação de Princípios (PMA) 8620.
[810] A Fig. 720 mostra detalhes sobre a operação do LIZARD 120 para converter as Novas Alterações Propostas 8560 em um Mapa de Hierarquia de Propósitos 8564. A unidade Novas
Petição 870200056145, de 06/05/2020, pág. 377/1737
375/754
Alterações Propostas 8560 é enviada ao Módulo de Sintaxe (SM) C35 pertencente ao Jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de códigos de computador. Para escrever códigos; recebe o Formato de Propósito Complexo C325 do Módulo de finalidade (PM) C36. O C325 Formato de Propósito Complexo é então escrito em código sintático arbitrário, também conhecido como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de computação que são mais comuns entre todas as linguagens de programação, como instruções yes/no, while, etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real que depende da sintaxe do computador (idioma do computador) desejada. Para leitura de códigos; o SM C35 fornece uma interpretação sintática do código do computador, de forma que o PM C36 tenha um propósito para a funcionalidade desse código. A unidade de Novas alterações proposta 8560 s é recebida em um formato misto de Execução 8501/Fluxo de dados por C321 de conversão de código. A Tradução de Código C321 é convertida em código arbitrário (genérico), que é reconhecido e entendido pela SM C35 para qualquer idioma de computador conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em diferentes tipos de sintaxe arbitrária. A saída da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322 . Portanto, após a execução concluída da Redução Lógica C323, a execução da instância
Petição 870200056145, de 06/05/2020, pág. 378/1737
376/754 correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma finalidade no formato de finalidade complexa C325 do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção relevante do código, conforme interpretada por SM C35. 0 PM C36 também pode detectar trechos de código que se infiltram em informações (binárias/ASCII, etc.). A Interpretação Iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por Manutenção/Autoprogramação automática e é direta e exclusivamente programada por especialistas na área relevante. O elemento de código principal C335 do IC C333 contém quadros e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade gerais do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C333 C336 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[811] A Fig. 721 continua o Fluxo Lógico da Fig. 720 para ilustrar a operação do LIZARD 120 para converter as novas
Petição 870200056145, de 06/05/2020, pág. 379/1737
377/754 alterações propostas 8560 em um mapa de hierarquia de finalidades 8564. A Redução Lógica do Módulo de Sintaxe (SM) C323 C35 envia suas saídas para Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada, consultando as Associações de finalidade C326. A saída de definição de finalidade existe no formato de finalidade complexa C325, que é enviada como uma saída modular para PM C36 e, portanto, o Núcleo Externo (OC) C329 e, portanto, LIZARD 120. A saída é identificada como um mapa de hierarquia de finalidades 8564, apresentado como a versão do Formato de Propósito Complexo C325 das novas alterações propostas 8560. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às funções e módulos mencionados.
[812] A Fig. 722 mostra a Revisão de cooperação e conflito de lapela (OC3) 8520, para encontrar os elementos de finalidade que combinam com o custo 8550. O processo começa iniciando (Zona A 8538) a Zona para processar 8570. Seguido pelos tipos de Selecionar um Elemento de Finalidade 8572 e Isolara-o da zona 8574, como mostrado em 8576.
[813] A Fig. 723 continua o fluxo lógico da Fig. 722 para Cooperação de lapela e revisão de conflitos (OC3) 8520 para encontrar as jurisdições na Appchain dos elementos de finalidade 8552. Como o elemento de finalidade, digitar 8572 e isolar do resto da zona 8574, como mostrado em 8576, já ocorreu, removendo as referências de categoria 8578 (como mostrado em 8580) . Em seguida, 8582 Organizar pela jurisdição da Appchain (como mostrado em 8584).
Petição 870200056145, de 06/05/2020, pág. 380/1737
378/754
[814] A Fig. 724 continua o fluxo lógico da Fig. 723 para a Cooperação de lapela e a Revisão de conflitos (0C3) 8520, em que o LOM 132 avalia as jurisdições da Appchainl 8588 selecionadas como uma unidade coletiva em relação à conformidade com os Princípios de design 8554. No estágio 8586, as Jurisdições Recebidas da Appchain 8588 são mostradas em 8584. No Estágio 8590, o LIZARD deriva um Mapa de Hierarquia de Propósitos 8592 para os Princípios de Design do Sistema 648. No Estágio 8594, o LIZARD 120 deriva o Mapa de Hierarquia de Propósitos 8596 para Jurisdições de Appchain 8588.
[815] A Fig. 725 mostra detalhes sobre a operação do LIZARD 120 para converter os Princípios de Projeto do Sistema 5016 em um Mapa de Hierarquia de Propósitos 8592. A unidade Princípios de Projeto do Sistema 5016 é enviada ao Módulo Sintaxe (SM) C35 que pertence à jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de códigos de computador. Para escrever códigos; recebe o Formato de Propósito Complexo C325 do Módulo de Finalidade (PM) C36. O Formato de Propósito Complexo C325 é então escrito em código sintático arbitrário, também conhecido como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de computação que são mais comuns entre todas as linguagens de programação, como instruções yes/no, while, etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real que depende da sintaxe do computador (idioma do computador) desejada. Para leitura de códigos; o SM C35 fornece uma interpretação sintática do código do computador, de forma que o PM C36 tenha um propósito para a funcionalidade desse código. A
Petição 870200056145, de 06/05/2020, pág. 381/1737
379/754 unidade de Princípios de Projeto de Sistema 5016 é recebida em um formato misto de Execução 8501/Fluxo de dados, por conversão de código C321. A Tradução de Código C321 é convertida em código arbitrário (genérico), que é reconhecido e entendido pela SM C35 para qualquer idioma de computador conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em diferentes tipos de sintaxe arbitrária. A saída da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, após a execução concluída da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para derivar uma finalidade no formato de finalidade complexa C325 do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção relevante do código, conforme interpretada por SM C35. O PM C36 também pode detectar trechos de código que se infiltram em informações (binárias/ASCII, etc.). A Interpretação Iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. O Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção/autoprogramação automática e é direta e exclusivamente programada por especialistas na área relevante. O
Petição 870200056145, de 06/05/2020, pág. 382/1737
380/754 elemento de código principal C335 do IC C333 contém frameworks e bibliotecas fundamentais, scripts de gerenciamento de cabos e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade gerais do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C333 C336 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[816] A Fig. 726 continua o Fluxo Lógico da Fig. 725 para ilustrar a operação do LIZARD 120 para converter os Princípios de Projeto do Sistema 5016 em um Mapa de Hierarquia de Propósitos 8592. A Redução Lógica C323 do Módulo Sintaxe (SM) C35 envia suas Saídas para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada, consultando as Associações de Finalidade C326. A saída de definição de finalidade existe no formato de finalidade complexa C325, que é enviada como uma saída modular para PM C36 e, portanto, o Núcleo Externo (OC) C329 e, portanto, LIZARD 120. A saída é identificada como a versão de Formato de Propósito Complexo C325 dos Princípios de design do sistema 5016. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às funções e módulos mencionados.
[817] A Fig. 727 mostra detalhes sobre a operação do LIZARD 120 para converter Jurisdições da Appchain 8588 em um Mapa
Petição 870200056145, de 06/05/2020, pág. 383/1737
381/754 de Hierarquia de Propósito 8596. A unidade de Jurisdições da Appchain 8588 é enviada ao Módulo de sintaxe (SM) C35, que pertence a jurisdição do Núcleo Externo (OC) C329. 0 SM C35 fornece uma estrutura para leitura e gravação de códigos de computador. Para escrever códigos; recebe o Formato de Propósito Complexo C325 do Módulo de Finalidade (PM) C36. 0 C325 Formato de Propósito Complexo é então escrito em código sintático arbitrário, também conhecido como 'pseudocódigo'. 0 pseudocódigo contém implementações básicas de operações de computação que são mais comuns entre todas as linguagens de programação, como instruções yes/no, while, etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real que depende da sintaxe do computador (idioma do computador) desejada. Para leitura de códigos; o SM C35 fornece uma interpretação sintática do código do computador, de forma que o PM C36 tenha um propósito para a funcionalidade desse código. A Unidade Jurisdições da Appchain 8588 é recebida em um formato misto de Execução/Fluxo de Dados 8501, por Conversão de Código C321. A Tradução de Código C321 é convertida em código arbitrário (genérico), que é reconhecido e entendido pela SM C35 para qualquer idioma de computador conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em diferentes tipos de sintaxe arbitrária. A saída da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 Reduz a Lógica do Código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322 . Portanto, após a execução
Petição 870200056145, de 06/05/2020, pág. 384/1737
382/754 concluída da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma finalidade no formato de finalidade complexa C325 do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção relevante do código, conforme interpretada por SM C35. 0 PM C36 também pode detectar trechos de código que se infiltram em informações (binárias/ASCII, etc.). A Interpretação Iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção/autoprogramação automática e é direta e exclusivamente programada por especialistas na área relevante. O elemento de código principal C335 do IC C333 contém quadros e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade gerais do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C333 C336 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[818] A Fig. 728 continua o fluxo lógico da Fig. 727
Petição 870200056145, de 06/05/2020, pág. 385/1737
383/754 para ilustrar a operação do LIZARD 120 para converter as Jurisdições da Appchain 8588 em um Mapa de Hierarquia de Propósito 8596. A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia suas saídas para Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada, consultando as Associações de finalidade C326. A saída de definição de finalidade existe no formato de finalidade complexa C325, que é enviada como uma saída modular para PM C36 e, portanto, o Núcleo Externo (OC) C329 e, portanto, LIZARD 120. A saída é identificada como um Mapa de Hierarquia de Propósito 8596, apresentado como a versão de Formato de Propósito Complexo C325 das Jurisdições Appchain 8588. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às funções e módulos mencionados.
[819] A Fig. 729 mostra a Revisão de cooperação e lapela de conflitos (OC3) 8520, em que a LOM avalia as jurisdições Appchain selecionadas 8588 como uma unidade coletiva em relação à conformidade com os Princípios de design 8554. O processamento de simetria de objetivo (P2SP) 7000 recebe Princípios de design de sistema 5016 através do Mapa de Hierarquia de Finalidades 8592 da LOM 132 a CKR 648. O P2SP 7000 também recebe o mapa de hierarquia de finalidades 8596 das Jurisdições da Appchain 8588. O P2SP envia para a simetria do processamento de resultados 8598 que determina: O Mapa de finalidades de jurisdições da Appchain combina inteiramente com os Princípios de design do sistema 8600? Sim, combinar 8602 ou Não, não combinar 8604.
[820] A Fig. 730 continua o fluxo lógico da Fig. 729
Petição 870200056145, de 06/05/2020, pág. 386/1737
384/754
Revisão de Cooperação e Conflito de Lapela (0C3) 8520, onde as novas alterações propostas são produzidas de acordo com a pesquisa realizada 8558. Na revisão 8600, o Mapa de finalidades das jurisdições da Appchain estão em total conformidade com os princípios de design do sistema 8600? Sim, combinar 8602, Não são necessárias alterações, finalizar a execução do módulo com resultados nulos 8606. Se Não, não combinar 8604, ajustar o Mapa de Hierarquia de Propósito das Jurisdições da Appchain para combinar com o Mapa 8608 dos Princípios de Design do Sistema no Processamento de realinhamento de finalidade (PRP) 7050. O LIZARD 120 converte o Mapa de finalidade aprimorada 8610 para a sintaxe da Appchain, que é referenciada como Novas alterações propostas 8050 no mecanismo de distribuição de prêmios da Appchain 6066. A sintaxe da Appchain é dividida em três Diferentes categorias de Appchains através do ASM 6066.
[821] A Fig. 731 mostra detalhes sobre a operação do LIZARD 120 para converter o Mapa de Finalidade Aprimorada 8610 em novas alterações propostas 8560. O Mapa de Finalidade Aprimorada 8610 existe no Formato de Finalidade Complexa C325 e é enviado para a expansão iterativa C327 do módulo das finalidades C36 no Núcleo Externo (OC) C329 do LIZARD 120. A expansão iterativa C327 adiciona detalhes e complexidade para transformar um objetivo simples em uma definição complexa e específica de propósitos. Portanto, o potencial máximo de associação de finalidade C326 da entrada é realizado e retido como um formato de finalidade complexa C325, antes de ser enviado para a derivação lógica C320 do módulo de sintaxe (SM) C35. O Elemento de Código Principal C335 do IC C333 contém quadros e
Petição 870200056145, de 06/05/2020, pág. 387/1737
385/754 bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade gerais do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. 0 elemento Objetivos do Sistema C333 C336 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[822] A Fig. 732 continua o fluxo lógico da Fig. 731 para ilustrar a operação do LIZARD 120 para converter o Mapa de finalidade aprimorada 8610 em Novas Alterações Propostas 8560. As informações de entrada são recebidas no Formato de finalidade complexa C325 do Módulo de finalidade (PM) C36 e é transferido para a Derivação Lógica C320 do Módulo Sintaxe (SM) C35. A derivação lógica C320 deriva as funções logicamente necessárias de funções inicialmente mais simples. Isso significa que, se uma função puder ser formada como uma função derivada devido à implicação de uma função pai mais simples, ela será formada por uma Derivação lógica C320. A saída produzida é uma árvore de dependências de funções que são construídas de acordo com as informações definidas no Formato de Finalidade Complexa C325. A Derivação Lógica C320 opera de acordo com as definições das Regras e Sintaxe C322 que são herdadas do elemento do Código Central do Núcleo Interno (IC) C333 e da Coleção de Bibliotecas do Sistema de Destino 9442 por meio da Interpretação e Detecção do Sistema de Destino (TSID). A derivação lógica C320 envia seus
Petição 870200056145, de 06/05/2020, pág. 388/1737
386/754 resultados para a tradução de código C321. A tradução de código C321 é convertida em Código Arbitrário (genérico), que é reconhecido e entendido pela SM C35 para qualquer idioma de computador conhecido e escolhido. A tradução de código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em diferentes tipos de sintaxe arbitrária. Portanto, o PM C36 chama o SM C35 para produzir a versão resultante do Mapa de Propósito Aprimorado 8 610 por meio da Conversão de Código C321. A unidade resultante das Novas alterações propostas 8560, que são produzidas terminalmente pela tradução de código C321, é a saída modular do SM C35, do núcleo externo (OC) C329 e do LIZARD 120.
[823] A Fig. 733 mostra a Ação de modificação de princípio (PMA) 8620 a 8614, em que a sintaxe da Appchain é desenhada em três categorias diferentes de Appchains através do Mecanismo de Doação de Appchain (ASM) 6066. O ASM 6066 fornece categorias: Appchains para Criar 8622, Appchains para Modificar 8624 (que vão diretamente para CEB 584), Appchains para Excluir 8626 que passam pelo Mecanismo de Eliminação de Appchains (ADM) 8630 para o Módulo de interface de Customchain (CIM) 2470. O LIZARD usa o módulo de sintaxe para converta o nova Appchain em um formato da Camada Logística 582. Todas as dependências e relacionamentos complementares existentes no Mapa de Finalidade Melhorada foram preservados 8628. A Camada Logística 582 envia o Criador de Ecossistemas Customchain (CEB) 584.
[824] A Fig. 734 mostra detalhes sobre a operação do LIZARD 120 para converter Appchains para Criar 8622 em uma Camada
Petição 870200056145, de 06/05/2020, pág. 389/1737
387/754 de Logística 582. Appchains para Criar 8622 é enviado ao Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Externo (OC) C329. 0 SM C35 fornece uma estrutura para leitura e gravação de códigos de computador. Para escrever códigos; recebe o Formulário de finalidade complexa C325 do Módulo de finalidade (PM) C36. 0 C325 Formato de Propósito Complexo é então escrito em código sintático arbitrário, também conhecido como 'pseudocódigo'. 0 pseudocódigo contém implementações básicas de operações de computação que são mais comuns entre todas as linguagens de programação, como instruções yes/no, while, etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real que depende da sintaxe do computador (idioma do computador) desejada. Para leitura de códigos; o SM C35 fornece uma interpretação sintática do código do computador, de forma que o PM C36 tenha um propósito para a funcionalidade desse código. As Appchains para a criação de 8622 são recebidas em um formato misto de Execução/Fluxo de Dados 8501 por a Tradução de Código C321. A Tradução de Código C321 é convertida em código arbitrário (genérico), que é reconhecido e entendido pela SM C35 para qualquer idioma de computador conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em diferentes tipos de sintaxe arbitrária. A saída da execução de Conversão de Código C321 concluída é transferida como uma entrada para Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322 . Portanto, após a execução concluída da Redução Lógica C323, a execução da
Petição 870200056145, de 06/05/2020, pág. 390/1737
388/754 instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma finalidade no formato de finalidade complexa C325 do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção relevante do código, conforme interpretada por SM C35. 0 PM C36 também pode detectar trechos de código que se infiltram em informações (binárias/ASCII, etc.). A Interpretação Iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção/autoprogramação automática e é direta e exclusivamente programada por especialistas na área relevante. O elemento de código principal C335 do IC C333 contém frameworks e bibliotecas fundamentais, scripts de gerenciamento de cabos e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade gerais do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C333 C336 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[825] A Fig. 735 continua o fluxo lógico da Fig. 734 para ilustrar a operação do LIZARD 120 para converter Appchains
Petição 870200056145, de 06/05/2020, pág. 391/1737
389/754 para Criar 8622 em uma camada logística 582. A Redução Lógica C323 do Módulo Sintaxe (SM) C35 envia suas saídas para a Interpretação Iterative C328 do Módulo de Propósito (PM) C36. A Interpretação iterative C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada, consultando as Associações de finalidade C326. A saída de definição de finalidade existe no formato de finalidade complexa C325, que é enviada como uma saída modular para PM C36 e, portanto, o Núcleo Externo (OC) C329 e, portanto, LIZARD 120. A saída é identificada como uma Camada de Logística 582, apresentada como Versão de Propósito Complexo C325 das Appchains para Criar 8 622 e codificada ainda em um formato de camada de logística 582. A camada de logística 582 é uma organização macro da sintaxe enquanto o C325 Formato de Propósito Complexo define a micro organização da sintaxe. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às funções e módulos mencionados.
[826] A Fig. 736 mostra a Ação de modificação com princípios (PMA) 8620 em 8614. A sintaxe da Appchain é classificada em três categorias diferentes de Appchains através do ASM 6066. O ASM 6066 fornece Appchains para modificar 8624 para o PMA 8620 que circula através de cada Appchain 8632 e 8634 Envia a Appchain selecionado para avançar o loop para o próxima Appchain 8636 e implantar o DPA (6260 Patch Set) disponível. O DPA 62 60 fornece um patch de correção da Appchain 6270 para o Construtor de ecossistemas Customchain (CEB) 584 para a Appchain Objetivo 6060.
[827] A Fig. 737 mostra a operação 8052 do Novo
Petição 870200056145, de 06/05/2020, pág. 392/1737
390/754
Desenvolvimento da Appchain (NAD) em que o LOM 132 recebe o MAP 8522 OC3 em 8638 e o LOM 132 faz referência aos Princípios de Design Criativo 8642 do CKR 648 em 8640. No estágio 8644, o LOM 132 produz um Mapa Potencial Criativo 8646.
[828] A Fig. 738 segue o fluxo lógico da Fig. 737 para ilustrar a operação 8052 do Novo Desenvolvimento da Appchain (NAD), na qual o LOM 132 faz referência ao Design Criativo 8640 e o LOM 132 produz um Mapa de Potencial Criativo 8644. O LOM 132 é invocado pelo Princípio de Invocação de Design (DPIP) 8648 para produzir designs de princípios criativos 8642. O LOM 132 usa o CKR 648 para produzir o Design de Princípios Criativos 8642.
[829] A Fig. 739 continua o fluxo lógico da Fig. 738 para ilustrar a operação 8052 do Novo Desenvolvimento da Appchain (NAD), na qual o LOM 132 faz referência ao Design Criativo 8640 e o LOM 132 produz um Mapa de potencial criativo 8644. O LOM 132 é chamado pela mensagem da Chamada de Invocação de Variação (CVIP) 8650 para produzir os Projetos Criativos de Princípios 8642. O mapa 8522 OC3 é dividido pelo LIZARD 120 em Seções Processáveis e armazenado no MSCR 8652.
[830] A Fig. 740 continua o fluxo lógico da Fig. 739 para ilustrar a operação 8052 do Novo Desenvolvimento da Appchain (NAD), na qual o mapa 8522 OC3 é dividido pelo LIZARD 120 em seções processáveis e armazenado no MSCR 8654. O LIZARD converte o MAP 8522 OC3 inteiro de uma Estrutura de Hierarquia de Finalidade em uma Sintaxe da Appchain 8658 a 8656. As Appchains são destacadas de acordo com seu Escopo de execução por Descoberta do escopo de execução (ESD) 8662 no estágio 8660. Os escopos da Appchain são armazenados em espera do Escopo do Cache
Petição 870200056145, de 06/05/2020, pág. 393/1737
391/754 de Execução (ESCR) 8666 no Estágio 8664. No Estágio 8668 Circula para cada Escopo de Execução armazenado no ESCR 8666.
[831] A Fig. 741 mostra detalhes sobre a operação do LIZARD 120 para converter o Mapa 8522 OC3 no Mapa de Sintaxe da Appchain 8658. O Mapa 8522 OC3 existe no Formato de Propósito Complexo C325 e é enviado para a Expansão Iterativa C327 do Módulo de Propósito C36 no núcleo externo LIZARD 120 C329 A expansão iterativa C327 adiciona detalhes e complexidade para transformar uma meta simples em uma definição complexa e específica de finalidade. Portanto, o potencial máximo de associação de finalidade C326 da entrada é realizado e retido como um formato de finalidade complexa C325, antes de ser enviado para a derivação lógica C320 do módulo de sintaxe (SM) C35. O elemento de código principal C335 do IC C333 contém quadros e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade gerais do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C333 C336 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[832] A Fig. 742 continua o fluxo lógico da Fig. 471 para ilustrar a operação do LIZARD 120 para converter o Mapa 8522 OC3 em um Mapa de sintaxe da Appchain 8 658. As informações de entrada são recebidas no Formato de finalidade complexa 0325 do
Petição 870200056145, de 06/05/2020, pág. 394/1737
392/754
Módulo de Finalidade (PM) C36 e transferido para a Derivação Lógica C320 do Módulo Sintaxe (SM) C35. A derivação lógica C320 deriva as funções logicamente necessárias de funções inicialmente mais simples. Isso significa que, se uma função puder ser formada como uma função derivada devido à implicação de uma função pai mais simples, será formada por uma Derivação lógica C320. A saida produzida é uma árvore de dependências de funções que são construídas de acordo com as informações definidas no Formato de Finalidade Complexa C325. A Derivação Lógica C320 opera de acordo com as definições das Regras e Sintaxe C322 que são herdadas do elemento do Código Central C335 do Núcleo Interno (IC) C333. A derivação lógica C320 envia seus resultados para a Tradução de Código C321. A Tradução de Código C321 é convertida em código arbitrário (genérico), que é reconhecido e entendido pela SM C35 para qualquer idioma de computador conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em diferentes tipos de sintaxe arbitrária. Portanto, o PM C36 chama o SM C35 para produzir a versão resultante do Mapa 8522 0C3 inserida pela Conversão de Código C321. 0 Mapa de Sintaxe de Appchain resultante, produzido terminalmente pela Conversão de código C321, é a saída modular do SM C35, Núcleo Externo (OC) C329 e LIZARD 120.
[833] A Fig. 743 mostra o Novo Desenvolvimento de Appchain (NAD) 8052, onde o Mapa 8652 OC3 é dividido pelo LIZARD 120 em seções processáveis e armazenado no MSCR 8652. A retenção do cache do escopo de execução (ESCR) 8672 circula para cada escopo de execução armazenados no ESCR 8668. Extraia a Appchain
Petição 870200056145, de 06/05/2020, pág. 395/1737
393/754
68 6 concluído do mapa de sintaxe da Appchain de acordo com ο escopo selecionado da execução 8670. No estágio 8672, o LIZARD converte a Appchain 8686 concluído no formato de mapa de hierarquia de finalidades 8674. No 8676 armazena o Mapa da Hierarquia de Propósito 8674 no MSCR 8652 e verifica se há um Escopo de Execução disponível no Loop. No estágio 8678. Se não 8680, conclua a execução da pesquisa 8684 e, se sim, 8682, prossiga para o estágio 8668.
[834] A Fig. 744 mostra detalhes sobre a operação do LIZARD 120 para converter a Appchain 8686 concluído em Mapa de hierarquia de finalidades 8688. A Appchain 8686 concluída é enviada ao Módulo de sintaxe (SM) C35, que pertence à jurisdição principal C329 externo (OC). O SM C35 fornece uma estrutura para leitura e gravação de códigos de computador. Para escrever códigos; recebe o Formulário de finalidade complexa C325 do Módulo de finalidade (PM) C36. O C325 Formato de Propósito Complexo é então escrito em código sintático arbitrário, também conhecido como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de computação que são mais comuns entre todas as linguagens de programação, como instruções yes/no, while, etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real que depende da sintaxe do computador (idioma do computador) desejada. Para leitura de códigos; o SM C35 fornece uma interpretação sintática do código do computador, de forma que o PM C36 tenha um propósito para a funcionalidade desse código. As Appchains concluídos 8686 são recebidas em um formato misto de Execução 8501/Fluxo de dados, por conversão de código C321. A tradução de Código C321 é
Petição 870200056145, de 06/05/2020, pág. 396/1737
394/754 convertida em código arbitrário (genérico), que é reconhecido e entendido pela SM C35 para qualquer idioma de computador conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em diferentes tipos de sintaxe arbitrária. A saída da execução de Conversão de Código C321 concluída é transferida como uma entrada para Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, após a execução concluída da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma finalidade no formato de finalidade complexa C325 do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção relevante do código, conforme interpretada por SM C35. 0 PM C36 também pode detectar trechos de código que se infiltram em informações (binárias/ASCII, etc.). A Interpretação Iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção/autoprogramação automática e é direta e exclusivamente programada por especialistas na área relevante. O elemento de código principal C335 do IC C333 contém quadros e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação
Petição 870200056145, de 06/05/2020, pág. 397/1737
395/754 e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade gerais do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. 0 elemento Objetivos do Sistema C333 C336 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[835] A Fig. 745 continua o fluxo lógico da Fig. 744 para ilustrar a operação 120 para converter a Appchain 8686 concluído no Mapa de hierarquia de finalidades 8688. A Redução Lógica 0323 do Módulo de sintaxe (SM) c35 envia suas saídas para Interpretação Iterativa 0328 do Módulo de Propósito (PM) 036. A Interpretação iterativa 0328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada, consultando as Associações de finalidade 0326. A saída de definição de finalidade existe no formato de finalidade complexa 0325, que é enviada como uma saída modular para PM 036 e, portanto, o Núcleo Externo (00) 0329 e, portanto, LIZARD 120. A saída é identificada como uma camada de logística 582 que é apresentada como a versão do Formato de Propósito Complexo 0325 da Appchain 8686 concluído. A mesma definição e aplicação do Núcleo Interno (IC) 0333 se aplica às funções e módulos mencionados. A Revisão de Cooperação e Conflito de Lapela (0C3) 8520 entra no Mapa 8522 0C3 no Retenção de Segmentos de Cache de Mapas (MSCR) 8652, que circula para cada Segmento de Mapa no Segmento de Mapa Selecionado 8691 no Estágio 8690 e Envia o segmento de mapa selecionado para a mensagem de chamada de
Petição 870200056145, de 06/05/2020, pág. 398/1737
396/754 variação criativa do 8650 (CVIP) no estágio 8692. No estágio 8693, o LOM 132 e o CTMP 124 produzem uma unidade de potencial criativo 8694 como modular.
[836] A Fig. 747 continua o fluxo lógico da Fig. 746 para ilustrar a operação do LOM 132 para produzir um Mapa de Potencial Criativo 8 644. O LOM 132 e o CTMP 124 produzem uma Unidade de Potencial Criativo 8694 como modular na Etapa 8693 e na revisão 8695. Iniciou um mapa de potencial criativo? Se Sim
8696, localize a seção do mapa de potencial criativo que corresponde à unidade de potencial criativo 8694 no estágio 8699. Em 8700, substitua a seção correspondente no mapa de potencial criativo 8646 pela unidade de potencial criativo 8694. Se não
8697, clone o Mapa 8522 OC3 em um Mapa de potencial criativo 8646 no Estágio 8698.
[837] A Fig. 748 continua o fluxo lógico da Fig. 747 para ilustrar o processo LOM 132 para produzir um mapa de potencial criativo 8644. Na etapa 8700, substitua a seção correspondente no mapa de potencial criativo 8644 pela unidade de potencial criativo 8694. Existem segmentos de mapa disponíveis no loop? 8701. Se Não, 8703, envie o Mapa do Potencial Criativo 8646 como saída modular 8705. Se Sim 8702, avance o loop para o próximo segmento de mapa disponível em 8704. Em 8706, circule para cada segmento de mapa no mapa no MSCR 8652.
[838] A Fig. 749 mostra o procedimento operacional interno do LOM 132 e CTMP 124 em relação ao estágio 8696 do Novo Desenvolvimento de Appchain (NAD) 8052. Os Projetos de Princípios Criativos 8642, os Segmentos de Mapas 8691 selecionados e o Mapa 8522 OC3 são fornecidos como informações de Mensagem de Invocação
Petição 870200056145, de 06/05/2020, pág. 399/1737
397/754 de Variação Criativa Inicial à Variação Criativa (CVIP) 8650. O
CVIP 8650 produz uma Solicitação 8318 que interage diretamente com o LOM 132 para invocar a produção da Declaração de Segurança Confiável 8320, levando em consideração os critérios de entrada da Teoria da Segurança 8312, Informações de segurança não confirmadas 8314 e Consciência de segurança confirmada 8310. A solicitação 8651 produzida pelo CVIP 8650 é enviada ao módulo L80 132 do LOM 132 para Raciocínio de Consulta Inicial (IQR) . Quando o LOM 132 é chamado diretamente na Plataforma UBEC 100 por um Usuário da UBEC 106, o IQR C802A recebe a pergunta/declaração inicial fornecida pelo Usuário da UBEC 106. No entanto, essa instância da LOM 132 é invocada pelo DIP 8316. A Solicitação 8318 fornecida é analisada através da invocação da Retenção Central de Conhecimento (CKR) 648 para decifrar os Detalhes ausentes da Solicitação 8268, que são cruciais para concluir o ' O entendimento correto virtual do LOM 132 para que o LOM 132 atenda/responda corretamente à Solicitação 8268. Detalhes ausentes produzidos pelo IQR C802A são enviados como informações modulares para o Esclarecimento de Pesquisas (SC) C803A. O SC C803A interage com a origem da Solicitação 8318 para recuperar informações suplementares, para que a Solicitação 8318 possa ser analisada objetivamente e com todo o contexto necessário. Quando o LOM 132 é invocado diretamente na Plataforma 100 do UBEC por um Usuário 106 do UBEC, o SC C803A interage com esse Usuário 106 como a fonte da pergunta/resposta. No entanto, essa instância do LOM 132 é automaticamente chamada pelo DIP 8316; portanto, o SC C803A interage com o DIP 8316 para recuperar informações suplementares sobre a Solicitação 8651. A versão
Petição 870200056145, de 06/05/2020, pág. 400/1737
398/754 totalmente formada e refinada da Solicitação 8651 é produzida do SC C803A e enviado como informações modulares na Construção de Afirmação (AC) C808A. 0 AC C808A tenta formar uma resposta consistente ao Pedido 8318 referenciando o CKR 648 diretamente e também por meio do Mapeamento Hierárquico (HM) C807A. 0 Apelo Racional (RA) C811A é um módulo de contêiner que hospeda uma interface de fluxo lógico com o CTMP 124. 0 RA C811A usa o CTMP 124 para criticar reivindicações. Tais criticas podem ser encontradas na forma de autocrítica (criticando os resultados do AC C808A) ou críticas externas da origem da pergunta/declaração processada pelo IQR C802A (Usuário da UBEC 106 ou DIP 8316). Se uma afirmação produzida pelo AC C808A falhar, uma medida significativa do teste de autocrítica processada pelo RA C811A; então, uma nova instância do AC C808A é invocada para justificar qualquer crítica válida. Se uma reclamação altamente confiável for produzida pelo AC C808A, ela passará consistentemente nos testes de autocrítica processados pelo RA C811A; a reivindicação é então produzida como o resultado modular do LOM 132, referido como a Unidade de potencial criativo 8698 no contexto da solicitação inicial 8651 fornecida pelo CVIP 8650.
[839] A Fig. 750 mostra mais detalhes do procedimento operacional interno do APELO Racional da LOM 132 (RA) C811A em relação ao Estágio 8696 da NAD 8052. A Construção de afirmação de (AC) C808A fornece uma apresentação na resposta C843 ao Apelo Racional (RA) C811A, referente à afirmação produzida pela AC C808A, referente ao Pedido de entrada 8268 correspondente. Nesse estágio do fluxo lógico, a asserção produzida é classificada como
Petição 870200056145, de 06/05/2020, pág. 401/1737
399/754 uma decisão pré-critica C847. Isso indica que ainda não foi processado através das criticas ao CTMP 124. Portanto, a declaração produzida é enviada diretamente à instância do CTMP 124 como uma entrada do 'Parecer subjetivo' C848 e também para a Construção do Contexto (CC) C817A que fornece a entrada 'Fatoalvo' do C850 para o CTMP 124. A Referência do CC C817A dos Metadados do AC C808A e evidência potencial fornecida por meio do CVIP 8650 para enviar dados puros ao CTMP 124 para o pensamento critico. Esses metadados de entrada são representados pelo arquivo Agregado de Registro de LOM 5502. O Agregado de Registro de LOM 5502 contém uma coleção de arquivos de Registro relevantes que são produzidos a partir das funções operacionais principais do LOM 132. Após o término da instância do CTMP 124 Em sua operação, uma Decisão Pós-Critica C851 é produzida como uma saida modular. A Decisão Inicial Pré-Criticada C847 e a Decisão PósCriticada C851 são enviadas ao módulo de Comparação de Decisão (DC) C818A, que determina o escopo da sobreposição potencial entre as duas entradas C847 e C851. O resultado unificado fornecido pelo DC 818A pode indicar uma Concessão CTMP 124 C852 (ou seu erro) em nome da reivindicação produzida pela AC C808A ou uma atualização C853 percebida de parte da reivindicação produzida pela AC C808A. As respostas de argumento C852 e C853 podem ser classificadas como Resultados de baixa confiança C845 ou Resultados de alta confiança C846. Um resultado de baixa confiança C845 indica que a declaração original produzida pelo AC C808A é imperfeita e deve ser reconstruída; portanto, o fluxo lógico continua para uma nova instância do AC C808A. Um resultado de alta confiança C846 indica que a declaração original produzida
Petição 870200056145, de 06/05/2020, pág. 402/1737
400/754 pela AC C808A tem mérito; portanto, as conclusões descritas (agrupadas com qualquer evidência, premissa, etc.) são enviadas para a validação de conhecimento C805A (KV) . Portanto, o fluxo lógico continua para uma nova instância do KV C805A, para que o CKR 846 e, portanto, o LOM 132 possa tirar proveito da reivindicação recém-processada.
[840] A Fig. 751 continua o fluxo lógico da etapa 8696 da NAD 8052 para ilustrar a produção do arquivo Agregado de Registro LOM 5502. As saídas modulares produzidas pelo raciocínio de consulta inicial (IQR) C802A, Esclarecimento do Inquérito (SC) C803A, Construção de Asserção (AC) C808A, o Mapa de Hierarquia (HM) C807A e a Validação de Conhecimento (KV) C805A são enviadas ao módulo Coleção de Registros Modulares de LOM (LMLC) 5500. Portanto, o LMLC 5500 combina os dados de receita do efetua o Registro em um arquivo legível e exclusivo referido como Agregado de Registro de LOM 5502. O arquivo 5502 abrange o status operacional geral da instância do LOM 132, fornecendo informações sobre como a instância do LOM 132 chegou a várias conclusões. O Agregado de Registro de LOM 5502 é enviado ao CC C817A do Apelo Racional (RA) C811A.
[841] A Fig. 752 explica os detalhes operacionais em relação à Fig. 751 para ilustrar a operação interna do CTMP 124 em relação aos canais de entrada e saída definidos no Apelo Racional (RA) C811A. A Decisão Pré-Crítica C847 é Apresentada C843 como uma saída modular da Construção de Afirmação (AC) C808A. A decisão C847 é então marcada como uma Opinião Subjetiva C848, cumprindo assim uma das duas principais saídas do CTMP 124. A Opinião Subjetiva C848 é enviada para os Metadados da Entrada
Petição 870200056145, de 06/05/2020, pág. 403/1737
401/754 do Sistema C484, que atua como a principal entrada modular para CTMP 124 e uma representação interna do algoritmo de correspondência de padrões selecionados (SPMA). Para esta configuração de instância; o SMPA é LOM 132 e os metadados de entrada do sistema C484 são enviados para processamento na Razão de Processamento de C456 e na Produção de Percepção Pura (RP2) C465. O Motivo de Processamento entenderá logicamente as reivindicações feitas ao comparar atributos de propriedade. O RP2 C465 analisa os metadados de entrada do sistema L48 132 C484 para produzir uma percepção no Formato de Percepção Complexa (PCF) que representa a percepção algorítmica do LOM 132. Essa percepção produzida é enviada para o Emulador de Observador de Percepção (POE) C475 que emula a percepção algorítmica do LOM 132. O Processamento de Razões C456 invoca o Processamento de Regras que eventualmente produz regras que refletem o algoritmo SPMA que, neste caso, é o LOM 132. Portanto, são executadas duas maneiras de 'pensar', percepção de processamento analógico e digital de regras. Esses dois ramos C461 e C475 representam semelhanças com intuição e lógica. Os resultados produzidos pelas Filiais C461 e C475 pensantes são transferidos para a Saída de Decisão Crítica (CDO) 6462, que avalia qualquer elemento fundamental de conflito ou colaboração entre os resultados. Encontrando uma alta magnitude de corroboração interna e uma baixa magnitude de conflito interno, o CTMP 124 fornece uma decisão binária de Aprovar ou Bloquear, relativa à entrada inicial da Opinião Subjetiva C848, que é referenciada como um Resultado de Alta Confiança C846. Se houver uma baixa magnitude de corroboração interna e uma alta magnitude de conflito interno,
Petição 870200056145, de 06/05/2020, pág. 404/1737
402/754 o CTMP 124 envia um 'voto de não confiança' que é referido como um Resultado de Baixa Confiança C845. Portanto, a saida resultante do CTMP 124 é considerada Decisão Pós-Criticada C851.
[842] A Fig. 753 mostra mais detalhes sobre a invocação da Produção de Percepção Pura (RP2) C465 no CTMP 124. O LOM 132 produz a Unidade de Potencial Criativo 8698 invocando a Construção de Afirmação (AC) C808A. A Unidade de potencial criativo 8698 é enviada ao estágio 5506 do RP2 C465, que descompacta as informações para produzir instâncias de um rastreamento de depuração C485 e rastreamento de algoritmo C486 nos metadados de entrada do sistema originários da instância AC correspondente C808A. O rastreamento de depuração C485 é um rastreamento de nivel de codificação que fornece variáveis, funções, métodos e classes usadas em conjunto com seu tipo e conteúdo de variável de entrada e saida. A sequência de Chamadas de Função Completa (rastreamento de funções: funções chamando outras funções) é fornecida. O Algoritmo de Rastreamento C486 é um rastreamento em nivel de software que fornece informações de segurança em conjunto com a análise de algoritmos. A decisão de segurança resultante (aprovar/bloquear) é fornecida junto com um rastreamento logístico de como chegou à Decisão C857. 0 peso apropriado em relação a cada fator que contribuiu para a produção da Decisão C847 está incluído lá. Em seguida, o RP2 C465 transfere as informações relativas ao resultado da percepção produzida para o Emulador de Observador de Percepção (POE) C475 para seu processamento.
[843] A Fig. 754 aprofunda a operação da Produção de Percepção C465 (RP2) a partir do CTMP 124. Inicialmente, a Etapa
Petição 870200056145, de 06/05/2020, pág. 405/1737
403/754
5506 ocorre, como na Fig. 753, para descompactar as informações para produzir instâncias de um Rastreio de Depuração C485 e Algoritmo C486 nos metadados de entrada do sistema C484 que se originam da instância AC correspondente C808A. Na Etapa 5508, o Processamento Métrico C489 faz engenharia reversa com variáveis LOM 132. Em seguida, os metadados de entrada do sistema C484 são processados pela Etapa 5510, que separa os metadados C484 em relacionamentos significativos de segurança de causa-efeito través da separação de metadados do sistema (SMS) C487. Como também indicado na Fig. 753, o RP2 C465 transfere as informações relativas ao resultado da percepção produzido para o Emulador de Observador de Percepção (POE) C475 para processamento.
[844] A Fig. 755 aprofunda a operação do Emulador de Observador de Percepção (POE) C475, inclui seu relacionamento e o da Produção de Percepção Pura (RP2) C465 com o Armazenamento de Percepção (PS) C478. A operação do Processamento Métrico C489 e da Separação de Metadados do Sistema (SMS) C487 resulta na produção das percepções 5512/5514/5516 que são armazenadas no PS C478. As percepções 5512/5514/5516 resultantes representam a resposta modular do LOM 132 para produzir a substituição de finalidade 8258 através da construção de asserção (AC) C808A. O RP2 C465 produz um ponto de informação de formato variável comparável, que é alimentado na Pesquisa de Armazenamento (SS) C480 como critério de pesquisa. Em seguida, o SS C480 realiza uma pesquisa no PS C478 para encontrar pares com as percepções já existentes armazenadas no PS C478. Os resultados C716 da execução do SS C480 são produzidos, o que resulta em um C718 Cálculo de Peso. Esse cálculo C718 tenta encontrar a distribuição
Petição 870200056145, de 06/05/2020, pág. 406/1737
404/754 correta das percepções correspondentes do PS C478 para replicar e combinar o formato de variáveis comparáveis que representa a execução do algoritmo LOM 132 que produziu a unidade de potencial criativo 8698.
[845] A Fig. 756 continua a lógica do Emulador de Observador de Percepção (POE) 0475 da Fig. 755. Após a produção dos Resultados da Pesquisa de Armazenamento 0716 (SS) 0480, o Cálculo de peso C718 completa o caminho para o Aplicativo C729 das percepções 5512/5514/5516 para tomar uma decisão ativa da aprovação C731 ou do bloco C730. A Unidade de Potencial Criativa 8698 produzida pela LOM 132 e o Agregado de Registro de LOM 5502 correspondente passam pela Análise de Informações C724 que faz com que os Regístradores de Informações Avançadas C723 sejam derivados, que são aplicados no Aplicativo C729 para obter uma Dicotomia Interpretativa 5518 de um Sentimento Positivo (Aprovar) C731 ou Sentimento Negativo (Bloquear) C730 em relação à entrada da Unidade de Potencial Criativo 8698. Após a conclusão bemsucedida da execução do Aplicativo C729, dá origem a uma Ação Corretiva para invalidar C476 o que é processado pela Saída de Decisão Crítica (CDO) C462 em paralelo com a Saída Modular da Execução de Regras (RE) C461. 0 Densidade do Módulo do Conhecimento Autocrítico (SCKD) C474 estima o escopo e o tipo de conhecimento desconhecido em potencial, que está além do escopo do Agregado de Registro de LOM 5502. Assim, as características do pensamento crítico subsequente da instância do CTMP 124 eles podem equilibrar o escopo potencial de todo o conhecimento envolvido, conhecido e desconhecido diretamente pela instância.
[846] A Fig. 757 mostra o processo de memória da Web
Petição 870200056145, de 06/05/2020, pág. 407/1737
405/754 operando em paralelo com a execução do Emulador de Observador de Percepção (POE) C475 na Fig. 756. A Unidade de potencial criativa 8698 produzida pela LOM 132 é enviada como uma entrada modular para o Processamento de Razão 0456 0 Processamento de Razão 0456 processa como o LOM 132 alcançou a decisão de produzir a Unidade de potencial criativo 8698 em resposta à Solicitação 8651 fornecida pelo CVIP 8650. A conclusão do processamento do Processamento de Razão 0456 é a execução do 0457, que define as regras que são consistentes com o comportamento executivo do LOM 132 . Se forem encontradas inconsistências nas regras de comportamento relacionadas à execução do comportamento do LOM 132, as regras existentes serão modificadas ou novas regras serão adicionadas. Essas regras são usadas na instância do CTMP 124 para criticar os comportamentos de tomada de decisão encontrados na instância correspondente do LOM 132. 0 Extensor de Âmbito de Regra Critica (CRSE) C458 utiliza percepções conhecidas para expandir o escopo de 'pensamento critico' dos conjuntos de regras; na verdade, aprimora os conjuntos de regras para produzir regras corretas. As regras corretas são enviadas como entrada modular para a Separação do formato sintaxe de regra (RSFS) C499 da jurisdição operacional da memória da web C460. 0 RSFS C499 separa e organiza as regras corretas C459 por tipo. Portanto, todas as ações, propriedades, condições e objetos são listados separadamente após o processamento do RSFS C499. Isso permite que a instância do CTMP 124 discernir quais partes foram encontradas no campo caótico e quais não. A Análise de campo caótico (CFP) C535 combina e formata o Agregado de Registro de LOM 5502 em uma única unidade digitalizável chamada Campo
Petição 870200056145, de 06/05/2020, pág. 408/1737
406/754
Caótico. O campo caótico é enviado como uma entrada modular para o reconhecimento de memória (MR) C501. O MR C501 também recebe as Regras originais C555, que são o resultado da execução do RSFS C499. O MR C501 varre o Campo Caótico fornecido pelo CFP C535 para reconhecer conceitos conhecidos definidos nas Regras Originais C555. Essa instância MR C501 produz as Regras de segmento reconhecidas C556. Em seguida, o Analisador de conformidade de regras (REP) C498 recebe partes individuais das Regras originais C555 que foram rotuladas de acordo com seu reconhecimento ou falta delas no campo caótico do MR C501. O RFP C498 pode deduzir logicamente que regras inteiras (a combinação de todas as suas partes) foram suficientemente reconhecidas no Campo Caótico para garantir o processamento da Execução de Regras (RE) C461. Após a conclusão bem-sucedida da execução do RE C461, leva a uma Ação Corretiva para Substituir C476, que é processada pela Saída de Decisão Crítica (CDO) C462 em paralelo com a saída modular do Emulador de observador de percepção (POE) C475.
[847] A Fig. 758 aprofunda a interação do fluxo lógico entre o Armazenamento de Percepção (PS) C478 e o Mecanismo de Descoberta de Percepção Automatizada (APDM) C467. O PS C478 contém quatro subconjuntos de percepções: Ângulos de Percepção Desconhecidos Deduzidos C473, Todos os Ângulos de Percepção C472, Ângulos de Percepção Implícitos C471 e Ângulos de Percepção Aplicados C470 Ângulos de Percepção Aplicados C470. Os ângulos de Percepção Aplicados C470 são percepções importadas diretamente pelo estudo do comportamento algorítmico. O Algoritmo de Correspondência de padrão Selecionado (SPMA), em que, neste caso, é o LOM 132. Os ângulos de Percepção Implícitos 0471 são
Petição 870200056145, de 06/05/2020, pág. 409/1737
407/754 percepções derivadas dos Ângulos de Percepção Aplicados C470 através da execução modular da derivação de implicação (ID) C477 e APDM C467. Todos os Ângulos de Percepção C472 representam o escopo completo das percepções conhecidas pela instância CTMP 124 que não foram incluídas nos ângulos de percepção aplicados C470 e nos ângulos de percepção implícitos C471. Os Ângulos de Percepção Desconhecidos deduzidos C473 representam o escopo de percepções que se espera existir, mas a instância CTMP 124 ainda não foi descoberta, de acordo com o módulo C474 Densidade autônoma de conhecimento C474 (SCKD) . O ID C477 analisa as métricas individuais dos Ângulos de Percepção Aplicados do C470 para derivar deterministicamente os ângulos de percepção implícitos do C470, em que o APDM C467 modifica criativamente as composições do Ângulo de Percepção do C650 através do módulo Criatividade 112 para produzir uma nova iteração C653 que combina os dois pesos iniciais de entrada C652. Portanto, Todos os Ângulos de Percepção C650 envolvidos no processamento do C467 APDM correspondem e representam a Unidade de potencial criativo 8698 que é produzida pelo módulo C808A da Construção de Afirmação (AC) da LOM 132.
[848] A Fig. 759 investiga os detalhes operacionais do CTMP 124. Expansor do Escopo da Regra Crítica (CRS) C458. Uma instância do Apelo Racional (RA) C811A opera no LOM 132 e chama o Construtor de Contexto (CC) C817A para processar o Agregado do Registro de LOM 5502 à análise de Campo Caótico (CEP) C535. O CEP produz um Campo Caótico a partir da saída modular DC C817A, que é referenciada pela Declaração de Memória (MR) C501. As regras atuais C534 exibem regras indicativas do status funcional
Petição 870200056145, de 06/05/2020, pág. 410/1737
408/754 atual do algoritmo de correspondência de padrão selecionado (SPMA), que nesta instância é LOM 132. As regras atuais C534 são enviadas como uma entrada modular para o módulo Derivação de sintaxe de regra C504, é ai que as regras lógicas do preto e branco se tornam percepções baseadas em métricas. Portanto, o arranjo complexo de várias regras se torna uma percepção única e uniforme que é expressa através de várias métricas de gradiente variável. A saída modular RSD C504 é fornecida como uma entrada modular para a Correspondência de percepção C503 (PM) . Na PM C503, uma unidade de formato variável comparável (CVF) é formada a partir da percepção recebida do RSD C504. O CVF recém-formado é usado para procurar percepções relevantes no C478 Armazenamento de Percepções (PS) com índices semelhantes. As combinações potenciais são enviadas como entradas modulares para a Geração de sintaxe de regra C505 (GSR). O RSG C505 recebe as percepções confirmadas anteriormente, que são armazenadas no formato de Percepção e acessam a composição das métricas internas de Percepção. As percepções são recebidas do PS C478, que contém as percepções confirmadas anteriormente C468. Tais medidas métricas baseadas em gradiente tornam-se regras binárias e lógicas que emulam o fluxo de informações de entrada/saída da percepção original. Portanto, o RSG C505 produz as Regras de percepção C537, que são percepções consideradas relevantes, populares e que foram convertidas em regras lógicas. Se uma Percepção (em seu Formato de Percepção original) tivesse muitos relacionamentos métricos complexos que definissem muitas 'áreas cinzas', as regras locais de 'preto e branco' abrangeríam essas áreas cinzentas, expandindo a complexidade das regras. Portanto, as
Petição 870200056145, de 06/05/2020, pág. 411/1737
409/754 regras perceptivas do C537 são armazenadas por uma coleção de definições de formato de sintaxe da regra (RSF). As regras de percepção C537 são enviadas como saídas modulares para o Reconhecimento de Memória (MR) C501, onde são escaneadas em contraste com o campo caótico produzido pelo CFP C535. Portanto, o MR C501 produz as Regras adicionais C536 que complementam as Regras corretas C533 em sua validade.
[849] A Fig. 760 investiga os detalhes operacionais relativos ao CTMP 124. Na Percepção de Derivação de Implicação (ID) C477 C470, os ângulos de percepção aplicados (PS) C478 são enviados como entradas modulares para o ID C477 para produzir mais percepções do que pertencem aos ângulos de percepção implícita C471. Os Ângulos de Percepção Aplicados do C470 são enviados especificamente para a Combinação Métrica ID C477 C493. A Combinação Métrica C493 separa os ângulos de percepção do C650 em categorias de métricas: Faixa C739, Tipo C740, Consistência C741, Intensidade C742. A disponibilidade de métricas e referências no sistema não é necessariamente limitada a esses quatro tipos. Os ângulos de percepção C650 de entrada estão relacionados à Substituição de Objetivo 8258 que foi produzida pelo Módulo L80 132 de Construção de Afirmação de LOM 132 (AC). O Conjunto de Complexidade Métrica C736 é enviado como uma entrada modular para a Expansão Métrica (ME) C495. Com o ME C495, as métricas de ângulo de percepção C650 múltiplas e variantes são armazenadas categoricamente em bancos de dados C739/C740/C741/C742 individuais. O ME C495 aprimora a rodada atual de métricas recebidas com detalhes/complexidade extraídos de métricas conhecidas/encontradas anteriormente. Após a
Petição 870200056145, de 06/05/2020, pág. 412/1737
410/754 conclusão do aprimoramento e enriquecimento da complexidade, as métricas são retornadas como saídas modulares ME C495 como Conjunto de Complexidade Métrica B C737 e, em seguida, convertidas de volta para os Ângulos de Percepção C650 para serem armazenadas nos Ângulos de Percepção Implícitos C471, conforme ilustrado na Fig. 761.
[850] A Fig. 761 continua o fluxo lógico da Derivação de Implicação (ID) C477 da Fig. 760, ilustrando o Conjunto B C737 de Complexidade Métrica, sendo processado pela Conversão Métrica C494, que reverte as métricas individuais de volta aos Ângulos de Percepção C650. Apesar do processo de enriquecimento e conversão realizado pelo ID C477, os Ângulos de Percepção C650 resultantes ainda fornecem uma visão razoavelmente precisa da Unidade de Potencial Criativo 8698 produzida pelo módulo C808A do Construção de Afirmação (AC) da LOM 132. Portanto, o processo de conversão métrica C494 envia os ângulos de percepção C650 derivados/implícitos para os ângulos de percepção implícitos C471 no armazenamento de percepção C478 (PS).
[851] A Fig. 7 62 investiga os Detalhes Operacionais do CTMP 124 C462 e a Saída de Decisão Crítica (CDO) . O CDO C462 recebe saídas modulares dos dois ramos principais do CTMP 124: Emulador Observador de Emcepção (POE) C475 (como ramo de intuição) e a Execução de Regras (RE) C461 (como ramo lógico) . Cada Filial C475/461 envia sua respectiva Decisão Crítica C521 (a principal saída modular), bem como os C521 'Meta-metadados' correspondentes, que fornecem variáveis contextuais que justificam por que a decisão crítica inicial foi tomada. Os
Petição 870200056145, de 06/05/2020, pág. 413/1737
411/754 conjuntos de decisões C521 que representam as regras concluídas C517 das percepções C516 e RE C461 do POE C475 são enviados ao Módulo de Categorização de Metadados (MCM) C488. 0 MCM C488 separa os rastreamentos de depuração e algoritmo em diferentes categorias usando a categorização tradicional baseada em sintaxe. Essas categorias podem ser usadas para organizar e produzir respostas de segurança distintas com uma correlação com os riscos e assuntos de segurança. A Decisão Intuitiva C514, apresentando as Percepções C526 da POE C475, e a Decisão Pensante C515, representando as Regras Completadas C517 de RE C451, são enviadas pelo MCM C488 à Lógica de Processamento Interno 5520 da Comparação das Decisões de Diretiva (DDC) C512. A DDC C512 Lógica de Processamento Interno 5520 analisa as corroborações ou conflitos entre a Decisão Intuitiva C514 e a Decisão Pensante C515. O DDC C512 faz referência a uma variável 'blocking' da Política Estática Codificada (SHP) 488. Se a similaridade da variável 'blocking' não for alcançada entre a Decisão Intuitiva C514 e a Decisão Pensante C515 (por exemplo, 90% +) , ocorre a Comparação Direta 5524, que pode levar o Controlo de Saída do Terminal TOC C513 a enviar um voto sem confiança 5544, como mostrado na Fig. 763. O estágio 5524 de comparação direta implica que o CTMP 124 não conseguiu agir internamente de maneira consistente com relação ao Pedido de entrada 8651 do CVIP 8650. Se a variável 'blocking' foi suficientemente alcançada de acordo com a Lógica de processamento interno 5520, então o estágio de saída do Decisão final 5522, que combina as decisões C514/C515 em uma única saída modular que é recebida e processada pelo TOC C513 .
Petição 870200056145, de 06/05/2020, pág. 414/1737
412/754
[852] A Fig. 763 continua o fluxo lógico da Saida de Decisão Critica (CDO) C462 da Fig. 762 e investiga os detalhes operacionais do Controlo de Saída de Terminal (TOC) C513. 0 TOC C513 inicia com a Solicitação 5526, que verifica se a Comparação Direta de Decisão (DDC) C512 foi capaz de fornecer a Saída Final de Decisão 5522 (em vez da diretiva de Comparação de Cancelamento Direta 5524). Se a resposta à Solicitação 5526 for Sim 5528, a decisão final combinada fornecida pelo DDC C512 na Saída de Decisão Final 552 será enviada como uma saída modular do TOC C513 e, portanto, como uma saída modular de toda a instância do CTMP 124 como a saída da Decisão Crítica Final 5542. Se a resposta à Solicitação 5526 for No 5530, a Etapa 5532 será chamada, o que invocará a execução de Perceções Correspondentes (PM) 5532 e procurará os resultados correspondentes. As Regras Completas C517 são extraídas da Decisão Crítica + Meta-metadados C521 da Execução das Regras (RE) C461. As regras C517 tornam-se percepções por derivação de sintaxe de regras (RSD) C504. O PM 5532, em seguida, faz referência aos meta-metadados para determinar, na solicitação 5534, se houve forte sobreposição interna e corroboração das percepções usadas. Se a resposta ao Pedido 5534 for Sim 5538, isso indica um Voto de Confiança 5544 do CTMO 124 como uma saída modular. Se a resposta à Solicitação 5534 for No, 5536, a Etapa 5540 será ativada, que seleciona a decisão percebida como a menos arriscada entre a Decisão Intuitiva C514 e a Decisão Pensante C515. Portanto, a Decisão Crítica Final 5542 é subsequentemente enviada como saída modular para CDO C462, TOC C513 e CTMP 124. A lógica na Etapa 5534 ocorre para determinar se a falta de unidade entre a Decisão Intuitiva
Petição 870200056145, de 06/05/2020, pág. 415/1737
413/754
C514 e a Decisão Pensante C515 ocorre devido a uma falta geral de confiança algorítmica ou devido a pontos de vista altamente opostos entre os dois. Portanto, se este último ocorrer, uma Decisão Crítica Final 5542 ainda é discernível como uma saída modular. Um Voto de Não Confiança 5544 sempre leva ao caminho lógico do Resultado de Baixa Confiança C845 dentro do Apelo Racional (RA) C811A. A Decisão Crítica Final 5542 pode levar a um caminho lógico de Resultado de Alta Confiança C846 ou Resultado de Baixa Confiança C845 dentro do RA C811A, dependendo da confiança algorítmica por trás da Decisão Crítica Final 5542.
[853] A Fig. 764 mostra o Desenvolvimento de Appchain Nova (NAD) 8052 a partir do Estágio 8644, onde a LOM produz um Mapa de Potencial Criativo 8646. No Estágio 8707, o CDM 8708 processa o Mapa de Potencial Criativo 8646 e forma soluções diferentes através da Criatividade 112 e testa-os com o I2GE 122. A 8708 Manifestação de Design Criativo (CDM) produz soluções sintaticamente criativas 8709.
[854] A Fig. 765 continua a lógica de Desenvolvimento de Novas Appchain (NAD) 8052 da Fig. 764, em que o CDM 8708 produz Soluções Sintaticamente Criativas 8709. Na etapa 8710, o LIZARD 120 deriva um Mapa de hierarquia de finalidades 8711 para Soluções Criativas Sintáticas 879 e ajusta o Mapa 8711 da Hierarquia de Propósitos da Plataforma UBEC 100 para incluir o Mapa 8709 de Soluções Sintaticamente Criativas. A LIZARD derivou um Mapa de Hierarquia de Propósitos 8713 para todo o ecossistema Customchain da Plataforma UBEC 100.
[855] A Fig. 766 mostra detalhes sobre a operação do LIZARD 120 para converter as soluções sintaticamente criativas
Petição 870200056145, de 06/05/2020, pág. 416/1737
414/754
8709 em um mapa de hierarquia de finalidade 8711. As soluções sintaticamente criativas 8709 são enviadas para o módulo de sintaxe (SM) C35, que pertence à jurisdição principal C329 externo (OC) . O SM C35 fornece uma estrutura para leitura e gravação de códigos de computador. Para escrever códigos; recebe o Formulário de finalidade complexa C325 do Módulo de finalidade (PM) C36. O Formato de Propósito Complexo C325 é então escrito em código sintático arbitrário, também conhecido como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de computação que são mais comuns entre todas as linguagens de programação, como instruções yes/no, while, etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real que depende da sintaxe do computador (idioma do computador) desejada. Para leitura de códigos; o SM C35 fornece uma interpretação sintática do código do computador, de forma que o PM C36 tenha um propósito para a funcionalidade desse código. As Appchains para a criação de 8622 são recebidos em um formato misto de Execução/Fluxo de Dados 8501 por Tradução de Código C321. A Tradução de Código C321 é convertida em código arbitrário (genérico), que é reconhecido e entendido pela SM C35 para qualquer idioma de computador conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em diferentes tipos de sintaxe arbitrária. A saída da execução de Conversão de Código C321 concluída é transferida como uma entrada para Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, após
Petição 870200056145, de 06/05/2020, pág. 417/1737
415/754 a execução concluída da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma finalidade no formato de finalidade complexa C325 do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção relevante do código, conforme interpretada por SM C35. 0 PM C36 também pode detectar trechos de código que se infiltram em informações (binárias/ASCII, etc.). A Interpretação Iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção/autoprogramação automática e é direta e exclusivamente programada por especialistas na área relevante. O elemento de código principal C335 do IC C333 contém quadros e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a operação e a funcionalidade gerais do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento IC C333 Objetivos do Sistema C336 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[856] A Fig. 767 continua o fluxo lógico da Fig. 766
Petição 870200056145, de 06/05/2020, pág. 418/1737
416/754 para ilustrar a operação do LIZARD 120 para converter as soluções sintaticamente criativas 8709 em um mapa de hierarquia de finalidades 8711. A redução lógica C323 do módulo de sintaxe (SM) C35 envia suas saídas para o Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. Interpretação iterativa C328 circula por todas as funções interconectadas para produzir uma definição de finalidade interpretada, consultando as Associações de finalidade C326. A saída de definição de finalidade existe no formato de finalidade complexa C325, que é enviada como uma saída modular para PM C36 e, portanto, Núcleo Externo (OC) C329 e, portanto, LIZARD 120. A saída é identificada como uma camada de logística 582, apresentada como a versão C325 Formato de Propósito Complexo das Soluções sintaticamente criativas 8709. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às funções e módulos mencionados acima.
[857] A Fig. 768 mostra o processo de Desenvolvimento da Nova Appchain (NAD) 8052 no Estágio 8714, em que o Mapa da Hierarquia de Finalidades 8713 da Plataforma UBEC 100 é ajustado para incluir o Mapa da Hierarquia de Finalidades 8711 da Sintáticas de Soluções Criativas 8709. O PRP (Processamento de realinhamento de finalidade) 7050 recebeu informações da Afinidade mestre/escravo 1480 para criar o Mapa de finalidade atualizado 8715. Na etapa 8716, o LIZARD 120 seleciona a estrutura de finalidade do Mapa de hierarquia de finalidade 8711 de 8709 da Sintáticas de Soluções Criativas do Mapa de finalidades atualizado 8715. O NAD 8052 geralmente encontra usos para aplicativos em um ecossistema de aplicativos específico que não possui uma característica de aplicativo em potencial, o que
Petição 870200056145, de 06/05/2020, pág. 419/1737
417/754 beneficiaria significativamente esse ecossistema.
[858] A Fig. 769 continua o fluxo lógico da Fig. 768 para ilustrar o processo na Etapa 8717, em que o LIZARD 120 usa o Módulo de sintaxe C35 para converter o novo Aplicativo no formato da camada de logística 582. Todas as dependências e relacionamentos de suplemento que existe no Mapa de Finalidade Atualizado 8715. O Construtor de Ecossistemas de Customchain (CEB) 584 recebe a camada logística 582 e constrói uma Appchain/Microchain 8719 que é consistente com a plataforma UBEC 100 na etapa 8718.
[859] A Fig. 770 mostra detalhes sobre como o LIZARD
120 funciona para converter o Mapa de Finalidade Atualizado 8715 em uma Camada Logística 582. O Mapa de Finalidade Atualizado 8715 existe no Formato de Finalidade Complexo C325 e é enviado para a Expansão Iterativa C327 do Módulo de Finalidade C36 dentro do núcleo externo LIZARD 120 C329 Expansão iterativa C327 e adiciona detalhes e complexidade para converter um único destino em uma definição específica de finalidade complexa. Portanto, o potencial máximo da entrada de associação de finalidade C326 é realizado e mantido como um formato de finalidade complexo C325, antes de ser enviado para a derivação lógica C320 do módulo de sintaxe (SM) C35. O Elemento de Código Principal C335 do Núcleo Interior (IC) C333 contém estruturas e bibliotecas principais, scripts de balanceamento de carga e gerenciamento de encadeamento, protocolos de criptografia e comunicação e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem
Petição 870200056145, de 06/05/2020, pág. 420/1737
418/754 a funcionalidade básica. 0 elemento Objetivos do Sistema 0336 do IC 0333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[860] A Fig. 771 continua o fluxo lógico da Fig. 770 para ilustrar a operação do LIZARD 120 para converter o Mapa de finalidade atualizada 8715 em uma camada logística 582. Os dados de entrada são recebidos no formato de finalidade complexa 0325 a partir do módulo de finalidade (PM) 036 e transferido para a derivação lógica 0320 do módulo de sintaxe (SM) 035. A derivação lógica 0320 deriva funções logicamente necessárias de funções inicialmente mais simples. Isso significa que, se uma função puder ser formada como uma função derivada devido à implicação de uma função pai mais simples, ela será formada pela Derivação Lógica 0320. A saída produzida é uma árvore de dependências de funções que são construídas de acordo com os dados definidos no formato de propósito complexo 0325. A Derivação Lógica 0320 opera de acordo com as definições das Regras e Sintaxe 0322 que são herdadas do elemento do Código Central C335 do Núcleo Interno (IC) C333. A Derivação Lógica C320 envia sua saída para a Conversão de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de converter linguagens de cálculo conhecidas em tipos de sintaxe arbitrários. Portanto, o PM C36 chama o SM C35 para produzir a versão resultante da sintaxe da Appchain da entrada Atualizada no Mapa de Finalidade 8715 pela Conversão de Código C321. A unidade
Petição 870200056145, de 06/05/2020, pág. 421/1737
419/754 resultante da camada de logística 582 que é produzida terminalmente pela conversão de código C321 é a saída modular do SM C35, do núcleo externo (OC) C329 e do LIZARD 120.
[861] A Fig. 772 mostra o processo de Manutenção Automatizada da Appchain (A2M) 8042, começando na Etapa 8721, em que a Appchain 6060 é selecionada para inspeção de suas necessidades de manutenção pelo Inspeção do Estado de Aplicação (ASI) 8722. As Necessidades manutenção 8723 inata, sao as siguientes: caches 8725 expirados, recursos depreciados 8726, módulos e dependências obsoletos 8727, benchmarks expirados 8728 e calibração de estabilidade econômica 8729.
[862] A Fig. 773 continua o processo de manutenção automatizada da cadeia para a Appchain (A2M) 8042, começando na Etapa 8730, onde o Banco de Dados de Rastreamento de Manutenção da Appchain (AMT) 8731 é atualizado para incluir o status mais recente de a manutenção inata precisa 8723 da Appchain Alvo 6060. Para cada X novos blocos de uma Appchain, é processado pela Desenvolvimento da Manutenção da Appchain (AMD) 8734 para executar as medidas de manutenção apropriadas na Etapa 8732. A Appchain 8733 arbitrária é enviada ao Implantação da Manutenção da Appchain (AMD) 8734 e ao Módulo de Interface da Customchain (CIM) 2470, que envia o anúncio do novo bloco de trabalho resolvido 2480 para a etapa 8732.
[863] A Fig. 774 mostra o Desenvolvimento de Quadro Reforçado (EFD) 8054 para produzir a estrutura ideal da estrutura, com base no Mapa de finalidades de hardware 8742 usando LOM 132 e CTMP 124. O Desenvolvimento de Quadro Reforçado (EFD) 8054 inspeciona e potencialmente aprimora as estruturas do
Petição 870200056145, de 06/05/2020, pág. 422/1737
420/754 software existente (como linguagens de programação) para a plataforma UBEC 100/BCHAIN Network 110 e para Sistemas Legados. O 8056 Desenvolvimento de Hardware Reforçado (EHD) modifica sistemas físicos que contêm 8856 Placas Dinâmicas de Condutores Líquidos (DLCB) e, portanto, pode ter sua estrutura de hardware principal otimizada e atualizada. O Mecanismo de Interpretação da Estrutura (FIM) 8795 fornece a Interpretação da Estrutura da Estrutura 8736 para o LIZARD 120. Na etapa 8740, o LIZARD 120 converte a Interpretação da Estrutura 8736 em um formato de finalidade conhecido como Mapa de objetivo da estrutura 8743. O inquérito de estrutura de hardware (HS2) 8793 (que contém o HIM) 8794 fornece a interpretação de estrutura de hardware 8735 para o LIZARD 120. Na etapa 8738, o LIZARD 120 converte Interpretação da Estrutura de Hardware 8735 em um formato de finalidade
conhecido como Mapa de Finalidade de Hardware 8742 . Na Etapa
8744, LOM 132 e CTMP 124 produzem a Estrutura de Estrutura Ideal
de acordo com o Mapa de Finalidade do Hardware 8742.
[8 64]A Fig 775 mostra detalhes sobre como o LIZARD
120 funciona para converter a Interpretação da Estrutura de Hardware 8732 em um Mapa de Finalidade do Hardware 8736. A Interpretação da Estrutura de Hardware 8732 é enviada ao Módulo Sintaxe (SM) C35 que pertence à jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código, recebe o formato de finalidade complexo C325 do módulo de finalidade (PM) C36. O formato de finalidade complexa do C325 é escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de
Petição 870200056145, de 06/05/2020, pág. 423/1737
421/754 cálculo que são mais comuns entre todas as linguagens de programação, como instruções yes/no, loops etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real, com base na sintaxe de computação de destino desejada (linguagem de computador) . Para a leitura do código, o SM C35 fornece uma interpretação sintática do código do computador, para que o PM C36 obtenha um objetivo para a funcionalidade do código. A Interpretação da Estrutura de Hardware 8732 é recebida no formato Especificações de Hardware 8973 via Conversão de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A Tradução De código C321 também executa a função inversa de converter linguagens de cálculo conhecidas em tipos de sintaxe arbitrários. A saida da execução completa da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, uma vez concluída a execução da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para obter uma finalidade no formato de finalidade complexa C325 a partir do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada no SM C35. 0 PM C3 6 também é capaz de detectar fragmentos de código imersos em dados (binários/ASCII, etc.). A Interpretação
Petição 870200056145, de 06/05/2020, pág. 424/1737
422/754
Iterativa C328 itera através de todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325) referente às Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área LIZARD 120 que não é submetida a manutenção/autoprogramação automatizada e é programada direta e exclusivamente por especialistas da área relevante. 0 elemento de código principal C335 do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[865] A Fig. 776 continua o fluxo lógico da Fig. 775 para ilustrar a operação do LIZARD 120 para converter a Interpretação de hardware 8732 no mapa de finalidade de hardware 8736. A redução lógica C323 do módulo de sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 itera através de todas as funções interconectadas para produzir uma definição de propósito interpretada consultando Associações de Propósito C326. A saída de definição de finalidade existe no formato de finalidade complexo C325, que é apresentado como uma saída modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329
Petição 870200056145, de 06/05/2020, pág. 425/1737
423/754 e, portanto, para o LIZARD 120. A saída é rotulada como um Mapa de Finalidade de Hardware 8736 que é apresentado como a Interpretação da Estrutura de Hardware do Formato de Finalidade Complexa C325 versão 8732. A mesma definição e aplicação do núcleo interno (IC) C333 se aplica às funções e módulos mencionados acima.
[866] A Fig. 777 mostra detalhes de como o LIZARD 120 funciona para converter a Interpretação da estrutura da estrutura 8738 em um mapa de objetivos da estrutura 8742. A interpretação da estrutura 8738 está sujeita ao Módulo de Sintaxe (SM) C35 pertencente a jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código, recebe o formato de finalidade complexo C325 do Módulo de Finalidade (PM) C36. O Formato de Finalidade Complexa do C325 é escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de cálculo que são mais comuns entre todas as linguagens de programação, como instruções yes/no, loops etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real, com base na sintaxe de computação de destino desejada (linguagem de computador) . Para a leitura do código, o SM C35 fornece uma interpretação sintática do código do computador, para que o PM C36 obtenha um objetivo para a funcionalidade do código. A interpretação da estrutura 8738 é recebida no formato 8975 das especificações da estrutura, através da tradução de código C321. A Tradução de Código C321 converte código arbitrário (genérico)
Petição 870200056145, de 06/05/2020, pág. 426/1737
424/754 reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de converter linguagens de cálculo conhecidas em tipos de sintaxe arbitrários. A saída da execução completa da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, uma vez concluída a execução da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para obter uma finalidade no formato de finalidade complexa C325 a partir do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada no SM C35. 0 PM C3 6 também é capaz de detectar fragmentos de código imersos em dados (binários/ASCII, etc.). A Interpretação Iterativa C328 itera através de todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325) referente às Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área LIZARD 120 que não é submetida a manutenção/autoprogramação automatizada e é programada direta e exclusivamente por especialistas da área relevante. 0 elemento de código principal C335 do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o
Petição 870200056145, de 06/05/2020, pág. 427/1737
425/754 código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. 0 elemento Objetivos do Sistema C336 do IC C333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[867] A Fig. 778 continua o fluxo lógico da Fig. 777 para ilustrar a operação do LIZARD 120 para converter a Interpretação da Estrutura da Estrutura 8738 no Mapa de Objetivos da Estrutura 8742. A Redução Lógica 0323 do Módulo Sintaxe (SM) 035 envia sua saída para a Interpretação Iterativa 0328 do Módulo de Propósito (PM) 036. A Interpretação Iterativa 0328 itera através de todas as funções interconectadas para produzir uma definição de propósito interpretada consultando Associações de Propósito 0326. A saída de definição de finalidade existe no formato de finalidade complexo 0325, que é apresentado como uma saída modular para PM 036 e, portanto, para o Núcleo Exterior (OC) 0329 e, portanto, para o LIZARD 120. A saída é como um Mapa de Finalidade da Estrutura 8742, que é apresentado como a versão 0325 do Formato de Finalidade Complexa da Interpretação da Estrutura da Estrutura 8738. A mesma definição e aplicação do núcleo interno (IC) C333 se aplica a funções e módulos mencionados acima.
[868] A Fig. 779 mostra o desenvolvimento de uma estrutura aprimorada (EFD) em que o LOM 132 e o CTMP 124 produzem o Enquadramento Ideal 8750 de acordo com o Mapa de finalidades de hardware 8736. Na etapa 8746, o LOM 132 recebe o mapa de
Petição 870200056145, de 06/05/2020, pág. 428/1737
426/754
Finalidade do Hardware 8736 que contém a Interpretação da Estrutura de Hardware 8732. No Estágio 8748, o LOM 132 produz os Princípios de Eficiência 8814 da Retenção Central de Conhecimento (CKR) 648. No Estágio 8744, LOM 132 e CTMP 124 produza a estrutura de estrutura ideal 8750 de acordo com o mapa de finalidade de hardware 8736.
[869] A Fig. 780 continua o fluxo lógico da Fig. 779 para ilustrar a operação do LOM 132 para produzir Princípios de Design de Eficiência da CKR 648 com base no Princípio de Invocação de Projeto (DPIP) 8648. O LOM constrói conceitos sobre Horas extras no CKR 648 a partir de dados recuperados pelo ARM 134 que facilitam o processo de determinação dos Princípios de Design de Eficiência 8814. O CKR 648 constrói uma base sólida de definições por meio de raciocínio avançado inato e é capaz para justificar qualquer conclusão que o LOM 8814 produz. Com o Construtor de Cluste C854F r, o CKR 648 chega a conclusões conceituais através do empilhamento de blocos de informações conhecidos como Clusters de Formato de Conhecimento Unitário (UKF) C854F. Esses grupos abrangem uma ampla gama de metadados relacionados às informações de destino, como fontes atribuíveis, tempos de criação de informações suspeitas, eficiência, design etc. Cada grupo UK8 C854F contém o formato de sintaxe da regra (RSF) C538.
[870] A Fig. 781 mostra o procedimento operacional interno do LOM 132 e do CTMP 124 em relação ao Estágio 8744 8054 do Desenvolvimento de Estrutura Aprimorada (EFD). Princípios de Projeto de Eficiência 8814, Princípios de Projeto de Estabilidade 8818 e Mapa de A finalidade do hardware 8736 é fornecida como entrada inicial para o DIP 8316. O DIP 8316 produz um aviso 8317
Petição 870200056145, de 06/05/2020, pág. 429/1737
427/754 que interage diretamente com o LOM 132 para invocar a produção do quadro de estrutura 8750 ideal, levando em consideração os critérios de entrada para os Princípios de design de eficiência 8814, Princípios de projeto de estabilidade 8818 e Mapa de finalidade de hardware 8736. O aviso 8317 produzido pelo DIP 8316 é enviado ao módulo IQR (LQ 132) do Raciocínio de Consulta Inicial C802A (IQR). Quando um usuário do UBEC 106 chama diretamente o LOM 132 na plataforma UBEC 100, o IQR C802A recebe da pergunta ou declaração fornecida pelo usuário inicial do UBEC 106. No entanto, esta instância do LOM 132 é automaticamente invocada pelo DIP 8316. O Aviso 8317 fornecido é analisado invocando a Retenção Central de Conhecimento (CKR) 648 para decifrar detalhes ausentes do Aviso 8317 que são cruciais para concluir o 'entendimento virtual' correto pela LOM 132 para que o LOM 132 atenda/responda totalmente ao Aviso 8317. Os detalhes ausentes resultantes produzidos pelo IQR C802A são apresentados como entrada modular para o Esclarecimento do Inquérito (SC) C803A. O SC C803A compromete-se com a origem do Aviso 8317 para recuperar informações suplementares para que o Aviso 8318 possa ser analisado objetivamente e com todo o contexto necessário. Quando um usuário do UBEC 106 invoca diretamente o LOM 132 na plataforma UBEC 100, o SC C803A se compromete com esse usuário 106 como a fonte da pergunta/resposta. No entanto, essa instância do LOM 132 é automaticamente chamada pelo DIP 8316, portanto, o SC C803A se conecta ao DIP 8316 para recuperar informações adicionais sobre o Aviso 8317. A versão totalmente formada e refinada do Aviso 8317 é produzida em do SC C803A e enviado como entrada modular para o Construção de Afirmação (AC) C808A. O AC C808A
Petição 870200056145, de 06/05/2020, pág. 430/1737
428/754 tenta formar uma resposta consistente ao Aviso 8317 referindose ao CKR 648 diretamente e também através do HM (HM) C807A. 0 Apelo Racional (RA) C811A é um módulo de contêiner que hospeda uma interface de fluxo lógico com o CTMP 124. 0 LR C811A usa o CTMP 124 para criticar reivindicações. Tais criticas podem ter a forma de autocrítica (criticar a saída do AC C808A) ou crítica externa da origem da pergunta/declaração processada pelo IQR C802A (usuário UBEC 106 ou DIP 8316) . Se uma afirmação produzida a partir do AC C808A falhar, uma medida significativa do teste de autocrítica processada pelo RA C811A; então, uma nova instância do AC C808A é invocada para explicar qualquer crítica válida. Se o AC C808A produz uma reivindicação de alta confiança que passa consistentemente nos testes de autocrítica processados pelo RA C811A, a reivindicação ocorre como a saída modular da LOM, referida como a Estrutura Ideal 8750 no contexto do Aviso Inicial 8317 fornecido pelo DIP 8316.
[871] A Fig. 782 mostra com mais detalhes o procedimento de trabalho interno do Apelo Racional (AR) C811A da LOM 132 em relação ao Estágio 8304 da EFD 8054. A Construção da Declaração (AC) C808A fornece um Envio de Resposta C843 ao Apelo Racional (RA) C811A referente à asserção produzida pela AC C808A em relação à entrada correspondente ao Aviso 8317. Nesta fase do fluxo lógico, a asserção produzida é classificada como uma Decisão Pré-Criticada C847. Isso indica que ainda não foi processado através de críticas do CTMP 124. Portanto, a declaração produzida é apresentada diretamente na instância CTMP 124 como uma entrada C848 de Opinião subjetiva' e também no Contexto de construção (CC) C817A que fornece a entrada C850 de
Petição 870200056145, de 06/05/2020, pág. 431/1737
429/754 'Fato-alvo' na instância CTMP 124. CC C817A refere-se aos metadados AC C808A e a evidência potencial fornecida pelo DIP 8316 para apresentar fatos cruciais ao CTMP 124 para um pensamento critico. Esses metadados de entrada são representados pelo arquivo Agregado de Registros de LOM 5502. O arquivo de Agregado de Registros de LOM 5502 contém uma coleção de arquivos de Registro relevantes que são produzidos a partir das principais funções operacionais do LOM 132. Depois que a instância do CTMP 124 concluir sua operação, uma Decisão Pós-Critica C851 é produzida como uma saída modular. A decisão pré-crítica inicial C847 e a decisão pós-crítica C851 são enviadas ao módulo de comparação de decisões (DC) C818A, que determina a extensão da sobreposição potencial entre as duas entradas C847 e C851. A saída unificada fornecida pelo DC 818A pode indicar o CTMP Grant 124 C852 (de incorreto) em nome da afirmação produzida pela AC C808A ou uma melhoria percebida C853 em nome da afirmação produzida pela AC C808A. As respostas argumentativas C852 e C853 podem ser classificadas como Resultados de baixa confiança C845 ou Resultados de alta confiança C846. Um resultado de baixa confiança C845 indica que a reivindicação original produzida pelo AC C808A é falha e precisa ser reconstruída; portanto, o fluxo lógico continua para uma nova instância do AC C808A. Um resultado de alta confiança C846 indica que a reivindicação original apresentada pelo AC C808A tem mérito; portanto, as conclusões tiradas (juntamente com qualquer evidência, premissa etc.) estão sujeitas à validação de conhecimento C805A (KV) . Portanto, o fluxo lógico continua para uma nova instância do KV C805A, para que o CKR 846 e, portanto, o LOM 132 possa tirar proveito da
Petição 870200056145, de 06/05/2020, pág. 432/1737
430/754 reivindicação recém-processada.
[872] A Fig. 783 continua o fluxo lógico 8054 do estágio EFD 8744 para ilustrar a produção do arquivo do Agregado de Registros de LOM 5502. As saídas modulares produzidas a partir do raciocínio de consulta inicial (IQR) C802A, do esclarecimento de pesquisa (SC) C803A, construção de asserções (AC) C808A, mapeamento hierárquico (HM) C807A e validação de conhecimento (KV) C805A são enviadas para o módulo Coleção de Registo Modular de LOM (LMLC) 5500. Portanto, o LMLC 5500 combina dados de registro de entrada em um único arquivo legível por humanos chamado Agregado de Registros de LOM 5502. O arquivo 5502 cobre o status operacional global da instância correspondente do LOM 132, fornecendo informações sobre como a instância do LOM 132 chegou a várias conclusões. O Agregado de Registros de LOM 5502 é enviado ao CC C817A Apelo Racional (RA) C811A.
[873] A Fig. 784 expande os detalhes operacionais da Fig. 783 para ilustrar o funcionamento interno do CTMP 124 em relação aos canais de entrada e saída definidos no Apelo Racional (RA) C811A. A Decisão Pré-Crítica C847 apresenta o C843 como uma saída modular do Construção de Afirmação (AC) C808A. A decisão C847 é então marcada como opinião subjetiva C848, portanto, atende a um dos dois principais requisitos do CTMP 124. A opinião subjetiva C848 é enviada aos metadados do sistema de entrada C484, que atua como a entrada modular primária para o CTMP 124 e como uma representação interna do algoritmo de correspondência de padrões selecionado (Algoritmo de correspondência de padrões selecionados, SPMA). Para esta configuração de exemplo, o SPMA é LOM 132. Os metadados do sistema de entrada C484 são enviados
Petição 870200056145, de 06/05/2020, pág. 433/1737
431/754 para processamento no Processamento de Motivos C456 e Produção de Percepção Bruta (RP2) C465. 0 Processamento de Motivos C456 entenderá logicamente as reivindicações feitas ao comparar atributos de propriedade. 0 RP2 C465 analisa os metadados do sistema de entrada L48 132 C484 para produzir uma percepção no formato de percepção complexa (PCF) que representa a percepção algorítmica do LOM 132. Essa percepção produzida é submetida ao Emulador de Observador de Percepção (POE) 0475 que emula percepção algorítmica da LOM 132. 0 Processamento de Razões 0456 chama o Processamento de Regras, que eventualmente produz conjuntos de regras que refletem o algoritmo SPMA, que neste caso é LOM 132. Portanto, dois modos de pensamento são executados, a percepção analógica e processamento de conjunto de regras digital. Esses dois ramos 0461 e 0475 representam semelhanças com intuição e lógica. Os resultados produzidos pelos dois ramos do pensamento 0461 e 0475 são transferidos para A Saída de Decisão Crítica (CDO) 0462, que avalia qualquer elemento fundamental de conflito ou corroboração entre os resultados. Encontrando uma alta magnitude de corroboração interna e uma baixa magnitude de conflito interno, o CTMP 124 fornece uma decisão binária de aprovação ou bloqueio, com relação à entrada inicial do parecer subjetivo C848, que é referenciado como um resultado de alta confiança. C846 Se houver uma baixa magnitude de corroboração interna e uma alta magnitude de conflito interno, o CTMP 124 apresenta um voto de não confiança conhecido como Resultado de Baixa Confiança C845. Portanto, o resultado resultante do CTMP 124 é considerado Decisão Pós-Crítica C851.
[874] A Fig. 785 mostra mais detalhes sobre como invocar
Petição 870200056145, de 06/05/2020, pág. 434/1737
432/754 a Produção Bruta de Percepção C465 (RP2) no CTMP 124. 0 LOM 132 produz a Estrutura Ideal 8750 invocando a Construção de Afirmação (AC) C808A. A Estrutura de Estrutura Ideal 8750 é então enviada para o Estágio 5506 do RP2 C465, que descompacta os dados para produzir instâncias de um Rastreio de Depuração C485 e Rastreio do Algoritmo C486 nos Metadados do Sistema de Entrada C484 originários da instância correspondente do AC C808A. O Rastreio de depuração C485 é um rastreio no nivel de codificação que fornece variáveis, funções, métodos e classes usadas em conjunto com o tipo e conteúdo correspondentes das variáveis de entrada e saida. A cadeia de chamada de função completa é fornecida (rastreio de função: funções chamando outras funções) . O Algoritmo de Rastreamento C486 é um rastreamento no nivel do software que fornece dados de segurança junto com a análise de algoritmos. A decisão de segurança resultante (aprovação/bloqueio) é fornecida junto com um rastreamento logístico de como a Decisão C847 foi alcançada. A ponderação apropriada de cada fator que contribuiu para a elaboração da Decisão C847 está incluída. Em seguida, o RP2 C465 transfere os dados referentes ao resultado da percepção produzido para o Emulador de Observadores de Percepção (POE) C475 para processamento.
[875] A Fig. 786 explica a operação da produção bruta de percepção C465 (RP2) do CTMP 124. Inicialmente, a etapa 5506 ocorre, como ocorre na Fig. 785, para descompactar os dados e produzir instâncias de um rastreamento de depuração C485 e um Rastreie o algoritmo C486 nos metadados do sistema de entrada C484 que se originam da instância correspondente do AC C808A. Na
Petição 870200056145, de 06/05/2020, pág. 435/1737
433/754
Etapa 5508, o C489 Processamento Métrico realiza engenharia reversa das variáveis do LOM 132 para extrair informações da inteligência artificial exibida pelo LOM 132. Em seguida, os metadados do sistema de entrada 0484 são processados na Etapa 5510, que separa os metadados 0484 em relacionamentos significativos de segurança de causa-efeito por meio da Separação de Metadados do Sistema (SMS) 0487. Como também indicado na Fig. 785, o RP2 C465 transfere os dados referentes ao resultado da percepção produzida para o Emulador de Observadores de Percepção (POE) C475 para processamento.
[876] A Fig. 787 explica a operação do Emulador de Observadores de Percepção (POE) C475, incluindo seu relacionamento com C465 e C478 da Produção de Percepção Bruta (RP2). A operação C487 Processamento Métrico C489 e a Separação de Metadados do Sistema (SMS) leva à produção das percepções 5512/5514/5516 que são armazenadas posteriormente no PS C478. As percepções 5512/5514/5516 resultantes representam a resposta modular da LOM à produção do quadro de estrutura ideal 8750 através da construção de asserção (AC) C808A. 0 RP2 C465 produz um ponto de dados de formato variável comparável que é inserido na C480 Pesquisa de Armazenamento (SS) como critério de pesquisa. 0 SS C480 realiza uma pesquisa pelo PS C478 para encontrar correspondências com as percepções já existentes armazenadas no PS C478. Os resultados C716 da execução SS C480 são produzidos, o que leva a um cálculo de peso C718. Esse cálculo C718 tenta encontrar a distribuição correta das percepções correspondentes do PS C478 para replicar e corresponder ao formato de variável comparável que representa a execução do algoritmo LOM 132 que
Petição 870200056145, de 06/05/2020, pág. 436/1737
434/754 produziu a estrutura ideal da estrutura 8750.
[877] A Fig. 788 continua a lógica do Emulador de Observadores de Percepção (POE) 0475 da Fig. 787. Após a produção dos resultados da Pesquisa de armazenamento (SS) 0716 0780, o 0718 de cálculo de peso é concluído para executar o 0729, aplicação das percepções 5512/5514/5516 para tomar uma decisão ativa para aprovar 0731 ou bloco 0730. A Estrutura Ideal Framework 8750 produzida pela LOM 132 e o Agregado de Registros de LOM 5502 correspondente passam pela Análise de Dados C724, que leva aos Registros de Dados 0723 Aprimorados que são aplicados no Aplicativo 0729 para obter uma Dicotomia de Interpretação 5518 de um Sentimento Positivo (Aprovado) 0731 ou Sentimento Negativo (Rejeitado) 0730 em relação à entrada da Estrutura-Quadro Ideal 8750. Após a conclusão bem-sucedida da execução do Aplicativo 0729, ocorre uma ação corretiva de substituição 0476 que é processada usando a Saída de Decisão Crítica (CDO) C462 em paralelo a Saída Modular da Execução de Regras (RE) C461. 0 módulo Densidade do conhecimento autocrítico (SCKD) C474 estima o escopo e o tipo de conhecimento potencial desconhecido que está fora do escopo do relatório de Agregado de Registros de LOM 5502. Dessa forma, os recursos de pensamento crítico subsequentes da instância de processamento CTMP 124 podem tirar proveito do escopo potencial de todo o conhecimento envolvido, conhecido e desconhecido diretamente pela instância.
[878] A Fig. 789 mostra o processo da Web de memória C460, operando em paralelo com o Emulador de Observação (POE) C475 executado na Fig. 788. A estrutura Ideal Framework 8750 produzida pelo LOM 132 é apresentada como uma entrada modular
Petição 870200056145, de 06/05/2020, pág. 437/1737
435/754 para o Processamento de Motivos C456. 0 Processamento de Motivos C456 processa como o LOM 132 tomou a decisão de produzir a Estrutura Ideal 8750 em resposta ao Aviso 8317 fornecido pelo DIP 8316. A conclusão do processamento do Processamento de Motivos C456 é a execução do Processamento de Motivos C457, que define regras terceiro consistentes com o comportamento de execução da LOM. Se forem encontradas inconsistências no comportamento das regras em relação ao comportamento de execução da LOM, as regras existentes serão modificadas ou novas regras serão adicionadas. Essas regras são subsequentemente usadas na instância 124 do CTMP para criticar os comportamentos de tomada de decisão encontrados na instância LOM 132 correspondente. O Extensor de Âmbito de Regras Criticas RSFS utiliza percepções conhecidas para expandir o escopo do pensamento critico dos conjuntos de regras, aprimorando os conjuntos de regras para produzir as Regras Corretas C459. As regras corretas C459 são enviadas como entrada modular para a regra de sintaxe de regras (RSFS) C499 da jurisdição operacional da Web de memória C460. O RSFS C499 separa e organiza as regras corretas C459 por tipo. Portanto, todas as ações, propriedades, condições e objetos são listados separadamente após o processamento do RSFS C499. Isso permite que a instância do CTMP 124 discernir quais partes foram encontradas no campo caótico e quais não foram. A Análise de Campo Caótico (CFP) C535 combina e formata o Agregado de Registros de LOM 5502 em uma única unidade digitalizável chamada Campo Caótico. O campo caótico é apresentado como uma entrada modular para o reconhecimento de memória (MR) C501. O MR C501 também recebe as Regras originais C555, que são o resultado da
Petição 870200056145, de 06/05/2020, pág. 438/1737
436/754 execução do RSFS C499. 0 MR C501 varre o Campo Caótico fornecido pelo CFP C535 para reconhecer conceitos conheciveis definidos nas Regras Originais C555. Essa execução da instância MR C501 produz os segmentos de regra reconhecidos C556. Posteriormente, o Analisador de Conformidade com Regras (REP) C498 recebe partes individuais das regras originais C555 que foram rotuladas de acordo com seu reconhecimento ou falta dentro do campo caótico pelo MR C501. 0 REP C498 pode deduzir logicamente que conjunto de regras (a combinação de todas as suas partes) foi suficientemente reconhecido no Campo Caótico para merecer ser processado pela Execução de regras (RE) C461. Após a conclusão bem-sucedida do RE C461, ocorre a ação corretiva de substituição C476 que é processada pela Saída de Decisão Crítica (CDO) C462 em paralelo com a saída modular do Emulador de Observadores de Percepção (POE) C475.
[879] A Fig. 790 explica a interação do fluxo lógico entre o Armazenamento de Perceção (PS) C478 e o Mecanismo Automatizado de Descoberta de Perceção (APDM) C467. O PS C478 contém quatro subconjuntos de percepções: Ângulos de Percepção Desconhecidos Deduzidos C473, Todos os Ângulos de Percepção C472, Ângulos de Percepção Implícitos C471 e Ângulos de Percepção Aplicados C470. Os Ângulos de Percepção Aplicados C470 são percepções que foram importadas diretamente pelo estudo do comportamento algorítmico do algoritmo de correspondência de padrões selecionados do Algoritmo de Correspondência de Padrões Selecionados (SPMA), que neste caso é LOM 132. Os ângulos de percepção implícitos 0471 são Percepções que foram derivadas dos Ângulos de Percepção Aplicados 0470 através da execução modular
Petição 870200056145, de 06/05/2020, pág. 439/1737
437/754 das Derivações de Implicações (ID) C477 e APDM C467. Todos os Ângulos de Percepção C472 representam o escopo completo das percepções conhecidas no CTMP 124 que não foram incluídas pelos ângulos de percepção aplicados C470 e pelos ângulos de percepção implícitos C471. Os Ângulos de Percepção Deduzidos Desconhecidos C473 representam o escopo de percepções que existe, no entanto, a instância do CTMP 124 ainda não foi descoberta de acordo com o módulo C474 de Densidade do conhecimento autocrítico (SCKD) . 0 ID C477 analisa as métricas individuais dos Ângulos de Percepção Aplicados C470 para derivar deterministicamente os Ângulos Implícitos de percepção C470, enquanto o APDM C467 varia criativamente as composições dos Ângulos de Percepção C650 através do Módulo de Criatividade 112 para produzir um novo Iteração C653 combinando os dois pesos iniciais de entrada C652. Portanto, todos os ângulos de percepção do C650 envolvidos no processamento do C467 APDM correspondem e representam a estrutura 8750 ideal produzida pelo módulo LOM C328A Construção de Afirmação (AC) 132.
[880] A Fig. 791 mostra os detalhes operacionais do CTMP 124. O Extensor de Escopo de Regras Críticas (CRSE) C458 é uma instância C811A do Apelo Racional (RA) que opera no LOM 132 e invoca a Construção de Contexto (CC) C817A para processo Agregado de Registros de LOM 5502 por meio da Análise de campo caótico (CFP) C535. O CFP produz um campo caótico a partir da saída modular do CC C817A que é referenciada pelo reconhecimento de memória (MR) C501. As Regras Atuais C534 exibem regras indicativas do status operacional atual do Algoritmo de Correspondência de Padrão Selecionado (SPMA), que neste caso é o
Petição 870200056145, de 06/05/2020, pág. 440/1737
438/754
LOM 132. As regras atuais 0534 são enviadas como entrada modular para o módulo de Derivação da Sintaxe de Regra 0504. (RSD), que é onde as regras lógicas em preto e branco se transformam em insights baseados em métricas. Portanto, o arranjo complexo de várias regras se torna uma percepção única e uniforme que é expressa através de várias métricas de diferentes gradientes. A saída modular do RSD 0504 é fornecida como uma entrada modular para o Jogo de Perceção (PM) 0503. Na PM 0503 é uma unidade de formato variável comparável (CVF), formada a partir da percepção recebida do RSD 0504. 0 CVF recém-formado é usado para procurar percepções relevantes no Armazenamento de Perceção (PS) C478 com índices semelhantes. As correspondências potenciais são enviadas como entrada modular para a Geração de regra de sintaxe (GSR) C505. 0 RSG C505 recebe percepções confirmadas anteriormente que são armazenadas no Formato de Perceção e acessam a estrutura métrica interna da Perceção. As percepções são recebidas do PS C478 contendo as percepções C468 confirmadas anteriormente. Tais medidas métricas baseadas em graus tornam-se regras binárias e lógicas que emulam o fluxo de informações de entrada/saída da percepção original. Portanto, o RSG C505 produz as Regras de percepção C537, que são percepções consideradas relevantes, populares e que se tornaram regras lógicas. Se uma Percepção (em seu Formato de Percepção original) tivesse muitos relacionamentos métricos complexos que definissem muitas 'áreas cinzas', as regras locais 'preto e branco' abrangeríam essas 'áreas cinzentas' expandindo a complexidade do conjunto de regras. Portanto, as regras perceptivas do C537 são armazenadas usando uma coleção de definições de formato de sintaxe da regra (RSF).
Petição 870200056145, de 06/05/2020, pág. 441/1737
439/754
As regras de percepção C537 são apresentadas como uma entrada modular no Reconhecimento de Memória (MR) C501, onde são contrastadas com o campo caótico produzido pelo PPC C535. Portanto, o MR C501 produz as Regras Extra C536 que completam as Regras Corretas C533 em sua validade.
[881] A Fig. 792 detalha os detalhes operacionais referentes à Derivação de implicações (ID) C477 do CTMP 124. Os ângulos de percepção aplicados C470 do Armazenamento de Perceção (PS) C478 são enviados como entrada modular para o ID C477 para produzir mais Perceção que pertencem aos ângulos implícitos de percepção C471. Os Ângulos de Percepção Aplicados do C470 são enviados especificamente para a combinação métrica ID C477 C493. A combinação de métricas C493 separa os ângulos de percepção recebidos C650 em categorias de métricas: Faixa C739, Tipo C740, Consistência C741, Intensidade C742. A disponibilidade e referência de métricas no sistema não são necessariamente limitadas a esses quatro tipos. Os ângulos de percepção do C650 estão relacionados ao quadro de estrutura ideal 8750, produzido pelo módulo de Construção de Afirmação de LOM 132 (AC) . O Conjunto de Complexidade Métrica C736 é apresentado como uma entrada modular para a Expansão Métrica (ME) C495. Com o ME C495, as métricas de múltiplos e variados ângulos de percepção C650 são categorizadas em bancos de dados individuais C739/C740/C741/C742. O ME C495 aprimora o lote atual de métricas recebidas com detalhes/complexidade extraídos de métricas conhecidas/encontradas anteriormente. Após concluir o aprimoramento e enriquecimento da complexidade, as métricas são retornadas como uma saída modular ME C4 95 como o Conjunto de
Petição 870200056145, de 06/05/2020, pág. 442/1737
440/754
Complexidade Métrica B C737 e, em seguida, convertidas novamente em Ângulos de percepção C650 para serem armazenados em Ângulos de percepção implícitos C471, como ilustrado na Fig. 793.
[882] A Fig. 793 continua o fluxo lógico do Derivação de implicação (ID) C477 da Fig. 792, ilustrando o Conjunto de complexidade métrica C C737 que está sendo processado pela conversão métrica C494, que inverte as métricas individuais de volta aos ângulos de percepção C650 completo. Apesar do processo de enriquecimento e conversão realizado pelo ID C477, os Ângulos de Perceção C650 resultantes ainda fornecem uma representação razoavelmente precisa da Estrutura de Quadro Ideal 8750 produzida pelo módulo de Construção de Afirmação de LOM 132 (AC) C808A. Portanto, o processo de conversão métrica C494 sujeita os novos ângulos de percepção derivados ou implícitos C650 aos ângulos implícitos de percepção C471 no armazenamento de percepção (PS) C478.
[883] A Fig. 794 detalha os detalhes operacionais relacionados à CTM62 Saída de decisão crítica (CDO) C462 124. O CDO C462 recebe saída modular das duas ramificações principais do CTMP 124: Observador de Perceção (POE) C475 (como ramificação intuição) e Execução das Regras (RE) C461 (como um ramo lógico). Cada ramificação C475/461 apresenta sua respectiva Decisão C521 (a principal saída modular), bem como os correspondentes Metametadados C521, que fornecem variáveis contextuais que justificam por que a decisão crítica inicial foi tomada. Os conjuntos de decisões C521 que representam as percepções C516 do POE C475 e as regras C517 do RE C461 são enviados ao módulo de categorização de metadados (MCM) C488. O MCM C488 separa os
Petição 870200056145, de 06/05/2020, pág. 443/1737
441/754 rastreamentos de depuração e algoritmo em diferentes categorias usando a categorização baseada em sintaxe das informações. Essas categorias podem ser usadas para organizar e produzir respostas de segurança diferentes com uma correlação com riscos e problemas de segurança. A Decisão Intuitiva C514, representando as Percepções C526 do POE C475, e a Decisão Pensante C515, representando as Regras C517 de RE C461, são enviadas pelo MCM C488 à Lógica de Processamento Interno 5520 da Comparação de Decisões de Gerenciamento (DDC) C512. A Lógica de Processamento Interno DDC C512 5520 verifica se há corroboração ou conflito entre a Decisão Intuitiva C514 e a Decisão Pensada C515. O DDC C512 refere-se a uma variável cut-off da política estática de código rígido (SHP) 488. Se a variável cut-off não for alcançada pela similaridade entre a Decisão Intuitiva C514 e a Decisão de Pensamento C515 (ou seja, 90% +), ocorre a diretiva Cancelar Comparação 5524 direta, o que pode levar o Controlo de Saída de Terminal (TOC) C513 a eventualmente registrar um 5544 Voto de Não Confiança, como mostra a Fig. 795. O estágio Cancelar Comparação Direta 5524 implica que o CTMP 124 não pôde atuar internamente de maneira consistente com relação à entrada Ask 8268 no RIP 8266. Se a variável cut -off foi suficientemente atendida de acordo com a lógica de processamento interno 5520, fase 5522 da decisão final, que combina as decisões C514/C515 em uma única saída modular que é recebida e processada pelo TOC C513 .
[884] A Fig. 795 continua o fluxo lógico da Saída de Decisão Crítica (CDO) C462 da Fig. 794 e elabora os detalhes operacionais do Controlo de Saída do Terminal (TOC) C513. O TOC
Petição 870200056145, de 06/05/2020, pág. 444/1737
442/754
C513 começa com o Aviso 5526, que verifica se a Comparação Direta de Decisão (DDC) C512 foi capaz de fornecer uma saida final de decisão 5522 (em vez da diretiva de Comparação de Cancelamento Direta 5524) . Se a resposta à pergunta 5526 for Sim 5528, a decisão final combinada fornecida pelo DDC C512 na saída final de decisão 552 será apresentada como saída modular TOC C513 e, portanto, como saída modular de toda a instância do CTMP 124 como a saída da Decisão Crítica Final 5542. Se a resposta à Pergunta 5526 for a No 5530, a Etapa 5532 será chamada, que por sua vez invoca a execução da Correspondência de Perceção (PM) 5532 e obtém os resultados correspondentes. As Regras Cumpridas C517 são extraídas da Decisão Crítica + Meta-metadados C521 da Regra de Execução (RE) C461. As regras C517 são convertidas em percepções por derivação de sintaxe de regras (RSD) C504. A MP 5532 refere-se então aos meta-metadados para determinar, no Aviso 5534, se houve forte sobreposição interna e corroboração das percepções utilizadas. Se a resposta à pergunta 5534 for Sim 5538, isso indica um voto de não confiança 5544 em nome do CTMP
124 como uma saída modular. Se a resposta à pergunta 5534 for No 5536, a Etapa 5540 será ativada, que seleciona a decisão de menor risco percebida entre a Decisão Intuitiva C514 e a Decisão Pensante C515. Portanto, a Decisão Crítica Final 5542 é subsequentemente apresentada como uma saída modular para CDO C462, TOC C513 e CTMP 124. A lógica na Etapa 5534 ocorre para determinar se a falta de unidade entre a Decisão Intuitiva C514 e a Decisão de Pensamento C515. Isso ocorre devido a uma falta geral de confiança algorítmica ou devido a visões altamente opostas entre os dois. Portanto, se este último ocorrer, uma
Petição 870200056145, de 06/05/2020, pág. 445/1737
443/754 possível Decisão Crítica Final 5542 ainda é discernível como uma saída modular. Um Voto de Não Confiança 5544 sempre leva ao Resultado de Baixa Confiança C845 por lógica dentro do Apelo Racional (RA) C811A. A decisão crítica final 5542 pode levar a um resultado de alta confiança C846 ou a um caminho lógico de resultado de baixa confiança C845 no AR C811A, dependendo da confiança algorítmica por trás da decisão crítica final 5542.
[885] A Fig. 796 mostra o Desenvolvimento de estrutura aprimorado (EFD) 8054, onde CTMP 124 e LOM 132 produzem a Estrutura de estrutura ideal 8750 de acordo com o Mapa de finalidade de hardware 8742 na Etapa 8744. Na Etapa 8752 I2GE 122, o teste de Esforço da Estrutura Ideal da Estrutura 8750 com variações da Interpretação de Hardware e Estrutura da Estrutura. Na etapa 8754, o esqueleto da estrutura demonstrou ser estável e na etapa 8756, esqueleto da estrutura não demonstrou ser estável. O Mecanismo de Interpretação de Hardware (HIM) 8798 interage com o Estudo de Estrutura de Hardware (HS2) 8796 para fornecer a Interpretação de Estrutura de Hardware 8732 para I2GE 122. A Política de Código Rígido Estático (SHP) 488 fornece informações sobre o Estágio 8752 para os testes de estresse I2GE 122.
[886] A Fig. 797 continua o fluxo lógico do Desenvolvimento de Quadros Melhorados (EFD) 8054 da Fig. 796 na Etapa 8758, onde a Estrutura de estrutura ideal refinada 8760 é apresentada como uma saída modular de I2GE 122 para o LIZARD 120. O LIZARD 120 converte a estrutura de o Quadro Ideal 8760 refinado para o formato de objetivo como Mapa 8764 do Objetivo do Quadro Ideal. O Mecanismo de Interpretação do Quadro (FIM) 8766 converte a Interpretação da Estrutura do Quadro 8768 no Mapa de Objetivo
Petição 870200056145, de 06/05/2020, pág. 446/1737
444/754 do Quadro 8 7 7 0.
[887] A Fig. 798 mostra detalhes de como o LIZARD 120 trabalha para converter a Interpretação do Esqueleto de Estrutura Refinada 8760 em um Mapa de Finalidade da Estrutura Ideal 8764. A Interpretação do Esqueleto de Estrutura Refinada 8760 é submetida ao Módulo de Sintaxe (SM) C35 que pertence à jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código, recebe-se o formato de finalidade complexo C325 do módulo de finalidade (PM) C36. O formato de finalidade complexo do C325 é escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de cálculo que são mais comuns entre todas as linguagens de programação, como instruções yes/no, loops etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real, com base na sintaxe de computação de destino desejada (linguagem de computador). Para a leitura do código, o SM C35 fornece uma interpretação sintática do código do computador, para que o PM C36 obtenha um objetivo para a funcionalidade do código. A Interpretação Refinada da Estrutura 8760 é recebida no formato Especificações da Estrutura 8975, via Conversão de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A Tradução De código C321 também executa a função inversa de converter linguagens de cálculo conhecidas em tipos de sintaxe arbitrários. A saida da execução completa da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução
Petição 870200056145, de 06/05/2020, pág. 447/1737
445/754
Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, uma vez concluída a execução da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para obter uma finalidade no formato de finalidade complexa C325 a partir do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada no SM C35. 0 PM C36 também é capaz de detectar fragmentos de código imersos em dados (binários/ASCII, etc.). A Interpretação Iterativa C328 itera através de todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325) referente às Associações de Objetivo C326. 0 Núcleo Interno (IC) C333 é a área LIZARD 120 que não é submetida a manutenção/autoprogramação automatizada e é programada direta e exclusivamente por especialistas da área relevante. O elemento de código principal C335 do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis
Petição 870200056145, de 06/05/2020, pág. 448/1737
446/754 de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[888] A Fig. 799 continua o fluxo lógico da Fig. 798 para ilustrar a operação do LIZARD 120 para converter a Interpretação da Estrutura da Estrutura Refinada 8760 em um Mapa de Finalidade da Estrutura Ideal 8764. A Redução Lógica C323 do Módulo Sintaxe SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 itera através de todas as funções interconectadas para produzir uma definição de propósito interpretada consultando Associações de Propósito C326. A saída de definição de finalidade existe no formato de finalidade complexo C325, que é apresentado como uma saída modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e, portanto, para o LIZARD 120. A saída é rotulada como um mapa de finalidade de estrutura refinada 8764, apresentado como a versão C325 Formato de Propósito Complexo da interpretação de estrutura de estrutura refinada 8760. A mesma definição e aplicação do núcleo interno (IC) C333 se aplica às funções e módulos mencionados acima.
[889] A Fig. 800 mostra o Desenvolvimento de estrutura aprimorado (EFD) 8054, onde na Etapa 8762, o LIZARD 120 converte o Esqueleto de Estrutura ideal refinada 8760 para o formato de finalidade como Mapa de finalidade de estrutura ideal 8794 dentro do Processo de simetria de finalidade com finalidade (P2SP) 7000. O P2SP 7000 também processa a Interpretação da Estrutura 8768 no Mapa de Objetivos da Estrutura 8770 e apresenta o Resultado do Processamento de Simetria 8772 na Etapa 8774 para verificar se há conflitos entre o Mapa de Objetivo da estrutura ideal 8764 e
Petição 870200056145, de 06/05/2020, pág. 449/1737
447/754 mapa de objetivos da estrutura 8770 em relação à composição da estrutura da estrutura. Se o Conflito 8776 for encontrado, continua-se na Etapa 8780 para verificar se existem Unidades de Propósito adicionais que causam o conflito justificado de acordo com o Mapa Necessita de Correspondência (NMM) C114, Justificado 8782 resultante ou 8784 não justificado. O resultado alternativo na Etapa 8774 não foi encontrado nenhum conflito de 8778.
[890] A Fig. 801 mostra a operação e a funcionalidade da Necessidade de Correspondência no Mapa C114 (NMM) operando como um submódulo do LIZARD 120 de Shell dinâmico C198. A instância do NMM C114 é gerada para atender à operação da Etapa 8780, iniciando com o Desenvolvimento de quadro Reforçado EFD 8054. Após a chamada modular do NMM C114, a varredura inicial C148 baixa cada ramo de jurisdição do Armazenamento 5550 para retenção temporária para referência na instância atual do NMM C114. Com Calcular requisitos da filial C149, de acordo com as definições associadas a cada filial, as necessidades são associadas ao seu departamento correspondente. Dessa maneira, as verificações de permissão podem ser formadas na instância do NMM C114. Por exemplo: O NMM C114 aprovou a solicitação de que o departamento de RH baixe todos os funcionários retomados conforme solicitado na área anual de análise de desempenho para funcionários com base em suas habilidades. Portanto, foi demonstrado que era uma necessidade válida da jurisdição do departamento. Portanto, o índice de Necessidades C145 é o principal armazenamento para as Agências de Jurisdição e suas respectivas necessidades. Como essa referência interna é um
Petição 870200056145, de 06/05/2020, pág. 450/1737
448/754 gargalo de recursos para a operação do NMM C114 e, portanto, de todos os módulos que atende, ela foi otimizada anteriormente para consultas rápidas ao banco de dados, a fim de aumentar a eficiência geral do sistema. A saída de processamento de simetria 8772 é fornecida como uma entrada de propósito C139 como uma entrada modular para o algoritmo de pesquisa NMM C114 C144. 0 algoritmo de pesquisa C144 faz referência e pesquisa o índice de Necessidades C145 compilado, determinando se o Objetivo de Entrada C139 define uma necessidade válida de acordo com os ramos de jurisdição inicialmente definidos em Desenvolvimento e Armazenamento de Acesso a Necessidades 5550. Por Portanto, a execução completa do algoritmo de busca C144 através do índice de necessidade C145 produz uma resposta de Aprovação/Bloqueio C14 6 que é apresentada como uma saída modular do NMM C114 e referenciada como resultado da necessidade de C141. Portanto, o resultado do requisito C141 é retornado no processamento EFD 8054 para a etapa 8780.
[891] A Fig. 802 mostra o processo de Desenvolvimento de Quadro Reforçado 8054 (EFD) que começa na Etapa 8752, em que o I2GE 122 testa a Estrutura Ideal da Estrutura com variações da Interpretação de Hardware e do Esqueleto da Estrutura. O que leva ao Esqueleto da Estrutura a mostrar-se estável 8754 ou a Estrutura de Estrutura não demonstrou ser estável 8756; nesse caso, envia uma DLU 1182 com o token oficial do sistema 1184 na etapa 5600 para o Envio de Registro de Diagnóstico (DLS) do Mecanismo de Investigação Automatizado (ARM) 1160 para envio ao SPSI 130. Na Etapa 8774, verifica se há conflitos entre o Mapa de Finalidade da Estrutura Ideal e o Mapa de Finalidade da
Petição 870200056145, de 06/05/2020, pág. 451/1737
449/754
Estrutura em relação à composição da finalidade. Se forem encontrados conflitos 8776, segue-se para a Etapa 8780 para verificar se existem Unidades de Propósito adicionais causando o conflito justificado de acordo com o NMM. Se 8782 não for garantido, envia um DLU 1182 com o token do sistema oficial 1184 na etapa 5600 para o Envio de Registro de Diagnóstico do Mecanismo de Investigação Automatizado (ARM) 1160 (DLS) para enviar ao SPSI 130. Como alternativa, se o resultado da etapa 8780 8784 é garantida, continua com o SRM (Mecanismo de Implementação de Especificação) 8786. Da etapa 8774, se nenhum conflito 8778 for encontrado, também continuará com o Mecanismo de Implementação de Especificação (SRM) 8786.
[892] A Fig. 803 mostra o processo de Desenvolvimento de Hardware Melhorado (EFD) 8056 para o 8800 Sistema de Destino Abstratou sando o 5040 Gerador de Sistema de Destino Abstrato (ATSG) começando na Etapa 8802, onde o LIZARD 120 interpreta a usabilidade do 8800 Sistema de Destino Abstratou Na Etapa 8804, o LIZARD 120 usa a Necessidade de Correspondência no Mapa (NMM) C114 para produzir uma definição do Mapa da Hierarquia de Propósitos 8806 referente à Funcionalidade Requerida do Usuário 8810. O LIZARD 120 converte o Mapa da Hierarquia de Fins em Sintaxe de Funcionalidade no estágio 8808. No estágio 8828, o LOM 132 e o CTMP 124 produzem a configuração ideal de hardware de acordo com a funcionalidade necessária do usuário. O Aviso de invocação de configuração idealista (ICIP) 8830 determina qual é a configuração de hardware mais eficiente e estável, levando em consideração a funcionalidade exigida pelo usuário 8832.
[893] A Fig. 804 mostra o processo de Desenvolvimento
Petição 870200056145, de 06/05/2020, pág. 452/1737
450/754 de Hardware Melhorado 8056 (EHD) em que o LIZARD 120 converte a Configuração de hardware ideal 8824 em um mapa de hierarquia de finalidades 8826 na etapa 8834. A partir da etapa 8808, o LIZARD 120 converte o mapa de hierarquia da Finalidade 8826 na Sintaxe da Funcionalidade 8810, levando o LOM 132 a Produzir os Princípios de Design de Eficiência CKR 648 8814 no Estágio 8812. No estágio 8816, o LOM 132 produz os Princípios de Design de Estabilidade 8818 do CKR 648 a estádio 8828, onde o LOM 132 e o CTMP 124 produzem a configuração ideal de hardware de acordo com a funcionalidade necessária do usuário. 0 LIZARD 120 converte a Configuração Ideal de Hardware 8824 em um Mapa de Hierarquia de Finalidade 8826 na Etapa 8834.
[894] A Fig. 805 mostra o processo de Desenvolvimento de Hardware Avançado (EFD) 8056, em que o LOM 132 produz os Princípios de Design de Eficiência 8814 da CKR 648 no Estágio 8812, com base no Princípio de Invocação de Projeto (DPIP) 8648. O LOM constrói conceitos em horas Extras dentro do CKR 648 a partir de dados recuperados pelo ARM 134 que facilitam o processo de determinação dos Princípios de Design de Eficiência 8814. O CKR 648 constrói uma base sólida de definições por meio de raciocínio avançado inato e é capaz de justificar qualquer conclusão que o LOM 8814 produz. Com a Construção de Clusters C854F, o CKR 648 chega a conclusões conceituais através do empilhamento de blocos de informações conhecidos como Clusters de Formato de Conhecimento Unitário (UKF) C854F. Esses grupos abrangem uma ampla gama de metadados relacionados às informações de destino, como fontes atribuíveis, tempos de criação de informações suspeitas, eficiência, design etc. Cada grupo UK8
Petição 870200056145, de 06/05/2020, pág. 453/1737
451/754
C854F contém o formato de sintaxe da regra (RSF) C538.
[895] A Fig. 806 mostra o processo de Desenvolvimento de Hardware Melhorado 8056 (EFD) em que o LOM 132 produz os Princípios de Projeto de Estabilidade 8818 da CKR 648 no Estágio 8816, com base no Princípio de Invocação do Projeto (DPIP) 8648. O LOM constrói conceitos sobre horas extras no CKR 648 a partir de dados recuperados pelo ARM 134 que facilitam o processo de determinação dos Princípios de Projeto de Estabilidade 8818. O CKR 648 constrói uma base sólida de definições por meio de raciocínio avançado inato e é capaz para justificar qualquer conclusão que o LOM 8818 produz. Com a Constrição de Cluster C854F, o CKR 648 chega a conclusões conceituais através do empilhamento de blocos de informações conhecido como Clusters de Formato de Conhecimento de Unidade C854F (UKF). Esses grupos abrangem uma ampla gama de metadados relacionados às informações de destino, como fontes atribuíveis, tempos de criação de informações suspeitas, estabilidade, eficiência, design etc. Cada grupo UK8 C854F contém o formato de sintaxe da regra (RSF) C538 .
[896] A Fig. 807 mostra o procedimento operacional interno do LOM 132 e CTMP 124 em relação ao estágio 8828 do EHD 8056. Os Princípios de Design de Eficiência 8814, Princípios de Design de Estabilidade 8818 e os Requisitos de Funcionalidade de usuário 8810 são fornecidos como entrada inicial para o Aviso de Chamada de Configuração Idealística (ICIP) 8822. O ICIP 8822 produz um Aviso 8823 que interage diretamente com o LOM 132 para invocar a produção da Configuração de hardware ideal 8824, levando em consideração os critérios de entrada de Princípios de
Petição 870200056145, de 06/05/2020, pág. 454/1737
452/754
Eficiência do Projeto 8814, Princípios de Estabilidade do Projeto 8818 e Funcionalidade Obrigatória do Usuário 8810. O aviso 8823 produzido pelo ICIP 8822 é enviado ao módulo de Raciocínio de Consulta Inicial (IQR) C802A da LOM 132. Como o usuário do UBEC 106 invoca diretamente o LOM 132 na plataforma UBEC 100, o IQR C802A recebe a pergunta ou afirmação iniciada fornecida pelo usuário UBEC 106. No entanto, esta instância do LOM 132 é automaticamente chamada pelo ICIP 8822. O Aviso 8823 fornecido é analisado invocando a Retenção Central de Conhecimento (CKR) 648 para decifrar os detalhes ausentes do Aviso 8823 que são cruciais para concluir o 'entendimento virtual' correto pelo LOM 132 para que o LOM 132 atenda/responda totalmente ao Aviso 8317. Os detalhes ausentes resultantes produzidos pelo IQR C802A são apresentados como entrada modular para o Clarificação de pesquisa (SC) C803A. O SC C803A compromete-se com a origem do Aviso 8317 para recuperar informações suplementares para que o Aviso 8318 possa ser analisado objetivamente e com todo o contexto necessário. Quando um usuário do UBEC 106 invoca diretamente o LOM 132 na plataforma UBEC 100, o SC C803A se compromete com esse usuário 106 como a fonte da pergunta/resposta. No entanto, esta instância do LOM 132 é automaticamente invocada pelo DIP 8316, portanto, o SC C803A se compromete com o ICIP 8822 para recuperar informações suplementares no Aviso 8823. A versão totalmente formada e refinada do Aviso 8823 é produzida em do SC C803A e enviado como entrada modular para o Construção de Afirmação (AC) C808A. O AC C808A tenta formar uma resposta consistente ao Aviso 8317 referindo-se ao CKR 648 diretamente e também através do HM (HM) C807A. Um (RA) C811A é um módulo de contêiner que abriga
Petição 870200056145, de 06/05/2020, pág. 455/1737
453/754 uma interface de fluxo lógico com o CTMP 124. 0 LR C811A usa o CTMP 124 para criticar reivindicações. Tais criticas podem ter a forma de autocrítica (criticar a saída do AC C808A) ou crítica externa da origem da pergunta/declaração processada pelo IQR C802A (Usuário UBEC 106 ou ICIP 8822). Se uma afirmação produzida a partir do AC C808A falhar, uma medida significativa do teste de autocrítica processada pelo RA C811A; então, uma nova instância do AC C808A é invocada para explicar qualquer crítica válida. Se o AC C808A produzir uma afirmação de alta confiança que passa consistentemente nos testes de autocrítica processados pelo RA C811A, a afirmação ocorre como a saída modular da LOM, referida como Configuração de hardware ideal 8824 no contexto do Aviso inicial 8823 fornecido pelo ICIP 8822.
[897] A Fig. 808 mostra com mais detalhes o procedimento de trabalho interno do Apelo Racional (RA) C811A da LOM 132 em relação ao Estágio 8828 do EHD 8056. A Construção da Declaração (AC) C808A fornece um Envio de Resposta C843 ao Apelo Racional (RA) C811A referente à asserção produzida pela AC C808A com relação à entrada correspondente Aviso 8823. Nesse estágio do fluxo lógico, a asserção produzida é classificada como uma Decisão Pré-Critica C847. Isso indica que ainda não foi processado através de críticas pelo CTMP 124. Portanto, a declaração produzida é apresentada diretamente na instância CTMP 124 como uma entrada C848 de Opinião subjetiva' e também no Contexto de construção (CC) C817A que fornece a entrada Fatoalvo do C850 para a instância CTMP 124. CC C817A refere-se aos metadados do AC C808A e a evidência potencial fornecida pelo ICIP 8822 para apresentar fatos brutos ao CTMP 124 para um pensamento
Petição 870200056145, de 06/05/2020, pág. 456/1737
454/754 critico. Esses metadados de entrada são representados pelo arquivo Agregado de Registro de LOM 5502. O arquivo Agregado de Registro de 5502 contém uma coleção de arquivos de Registro de LOM relevantes que são produzidos a partir das principais funções operacionais do LOM 132. Depois que a instância do CTMP 124 concluir sua operação, uma Decisão Pós-Critica C851 é produzida como uma saída modular. A decisão pré-crítica inicial C847 e a decisão pós-crítica C851 são enviadas ao módulo de comparação de decisões (DC) C818A, que determina a extensão da sobreposição potencial entre as duas entradas C847 e C851. A saída unificada fornecida pelo DC 818A pode indicar o CTMP Grant 124 C852 (incorreto) em nome da afirmação produzida pela AC C808A ou uma melhoria percebida C853 em nome da afirmação produzida pela AC C808A. As respostas argumentativas C852 e C853 podem ser classificadas como Resultados de baixa confiança C845 ou Resultados de alta confiança C846. Um resultado C845 de baixa confiança indica que a reivindicação original produzida pelo AC C808A é falha e precisa ser reconstruída; portanto, o fluxo lógico continua para uma nova instância do AC C808A. Um resultado C846 de alta confiança indica que a reivindicação original apresentada pelo AC C808A tem mérito; portanto, as conclusões tiradas (juntamente com qualquer evidência, premissa etc.) estão sujeitas à Validação de conhecimento C805A (KV) . Portanto, o fluxo lógico continua para uma nova instância do KV C805A, para que o CKR 846 e, portanto, o LOM 132 possa tirar proveito da reivindicação recém-processada.
[898] A Fig. 809 continua o fluxo lógico do estágio 8828 do EHD 8056 para ilustrar a produção do arquivo Agregado de
Petição 870200056145, de 06/05/2020, pág. 457/1737
455/754
Registro de LOM 5502. Saidas modulares produzidas a partir do raciocínio de consulta inicial (IQR) C802A, Clarificação de pesquisa (SC) C803A, construção de asserções (AC) C808A, mapeamento hierárquico (HM) C807A e validação de conhecimento (KV) C805A são enviadas para o módulo Coleção de Registo Modular de LOM (LMLC) 5500 da LOM. Portanto, o LMLC 5500 combina dados de registro de entrada em um único arquivo legível por humanos chamado Agregado de Registro de LOM 5502. O arquivo 5502 cobre o status operacional global da instância correspondente do LOM 132, fornecendo informações sobre como a instância do LOM 132 chegou a várias conclusões. O Agregado de Registro de LOM 5502 é enviado ao CC C817A Apelo Racional (RA) C811A.
[899] A Fig. 810 expande os detalhes operacionais da Fig. 809 para ilustrar o funcionamento interno do CTMP 124 em relação aos canais de entrada e saída definidos no Apelo Racional (RA) C811A. A Decisão Pré-Crítica C847 apresenta o C843 como uma saída modular do Construção de Afirmação (AC) C808A. A decisão C847 é então marcada como opinião subjetiva C848, portanto, atende a um dos dois principais requisitos do CTMP 124. A opinião subjetiva C848 é enviada aos metadados do sistema de entrada C484, que atua como a entrada modular primária para o CTMP 124 e como uma representação interna do algoritmo de correspondência de padrões selecionado (SPMA). Para esta configuração de exemplo, o SPMA é LOM 132. Os metadados do sistema de entrada C484 são enviados para processamento no Processamento de Motivos C456 e Produção de Percepção Bruta (RP2) C465. O Processamento de Motivos C456 entenderá logicamente as reivindicações feitas ao comparar atributos de propriedade. O RP2 C465 analisa os
Petição 870200056145, de 06/05/2020, pág. 458/1737
456/754 metadados do sistema de entrada L48 132 C484 para produzir uma percepção no formato de percepção complexa (PCF) que representa a percepção algorítmica do LOM 132. Essa percepção produzida é submetida ao Emulador de Observador de Percepção (POE) 0475 que emula percepção algorítmica da LOM 132. 0 Processamento de Razões 0456 chama o Processamento de Regras, que eventualmente produz conjuntos de regras que refletem o algoritmo SPMA, que neste caso é LOM 132. Portanto, dois modos de pensamento são executados, a percepção analógica e processamento de conjunto de regras digital. Esses dois ramos 0461 e 0475 representam semelhanças com intuição e lógica. Os resultados produzidos pelos dois ramos do pensamento 0461 e 0475 são transferidos para a Saída de Decisão Crítica (CDO) C462, que avalia qualquer elemento fundamental de conflito ou corroboração entre os resultados. Encontrando uma alta magnitude de corroboração interna e uma baixa magnitude de conflito interno, o CTMP 124 fornece uma decisão binária de aprovação ou bloqueio, com relação à entrada inicial do parecer subjetivo C848, que é referenciado como um resultado de alta confiança. C846 Se houver uma baixa magnitude de corroboração interna e uma alta magnitude de conflito interno, o CTMP 124 apresenta um voto de não confiança conhecido como Resultado de Baixa Confiança C845. Portanto, o resultado resultante do CTMP 124 é considerado Decisão Pós-Criticada C851.
[900] A Fig. 811 mostra mais detalhes sobre a invocação da Produção Bruta de Percepção C465 (RP2) no CTMP 124. 0 LOM 132 produz o Esqueleto de Estrutura Ideal 8750 invocando a Construção de Afirmação (AC) C808A. 0 Esqueleto de Estrutura Ideal 8750 é então enviada para o Estágio 5506 do RP2 C465, que descompacta
Petição 870200056145, de 06/05/2020, pág. 459/1737
457/754 os dados para produzir instâncias de um Rastreio de Depuração C485 e Rastreio do Algoritmo C48 6 nos Metadados do Sistema de Entrada C484 originários da instância correspondente do AC C808A. 0 Rastreio de Depuração C485 é um rastreio no nível de codificação que fornece variáveis, funções, métodos e classes usadas em conjunto com o tipo e conteúdo correspondentes das variáveis de entrada e saida. A cadeia de chamada de função completa é fornecida (rastreio de função: funções chamando outras funções). 0 Algoritmo de Rastreamento C486 é um rastreamento no nível do software que fornece dados de segurança junto com a análise de algoritmos. A decisão de segurança resultante (aprovação/bloqueio) é fornecida junto com um rastreamento logístico de como a Decisão C847 foi alcançada. A ponderação apropriada de cada fator que contribuiu para a elaboração da Decisão C847 está incluída. Em seguida, o RP2 C465 transfere os dados referentes ao resultado da percepção produzido para o Emulador de Observadores de Percepção (POE) 0475 para processamento.
[901] A Fig. 812 explica a operação da produção bruta de percepção 0465 (RP2) do CTMP 124. Inicialmente, a etapa 5506 ocorre, como ocorre na Fig. 811, para descompactar os dados e produzir instâncias de um rastreamento de depuração 0485 e um Rastreie o algoritmo 0486 nos metadados do sistema de entrada 0484 que se originam da instância correspondente do AC C808A. Na Etapa 5508, o Processamento Métrico C489 realiza engenharia reversa das variáveis do LOM 132 para extrair informações da inteligência artificial exibida pelo LOM 132. Em seguida, os metadados do sistema de entrada C484 são processados na Etapa
Petição 870200056145, de 06/05/2020, pág. 460/1737
458/754
5510, que separa os metadados C484 em relacionamentos significativos de segurança de causa-efeito por meio da Separação de Metadados do Sistema (SMS) C487. Como também indicado na Fig. 811, o RP2 C465 transfere os dados referentes ao resultado da percepção produzido para o Emulador de Observadores de Percepção (POE) C475 para processamento.
[902] A Fig. 813 explica a operação do Emulador de Observadores de Percepção (POE) C475, incluindo seu relacionamento com C465 e C478 da Produção de Percepção Bruta (RP2). A operação Processamento Métrico C489 e Separação de
Metadados do Sistema C487 (SMS) leva à produção das percepções 5512/5514/5516 que são armazenadas posteriormente no PS C478. As percepções 5512/5514/5516 resultantes representam a resposta modular da LOM à produção da configuração de hardware ideal 8824 através da construção de afirmação (AC) C808A. O RP2 C465 produz um ponto de dados de formato variável comparável que é inserido na C480 Pesquisa de Armazenamento (SS) como critério de pesquisa. O SS C480 realiza uma pesquisa pelo PS C478 para encontrar correspondências com as percepções já existentes armazenadas no PS C478. Os resultados C716 da execução SS C480 são produzidos, o que leva a um cálculo de peso C718. Esse cálculo C718 tenta encontrar a distribuição correta das percepções correspondentes do PS C478 para replicar e corresponder ao formato de variável comparável que representa a execução do algoritmo LOM 132 que produziu a estrutura ideal da estrutura 8750.
[903] A Fig. 814 continua a lógica do Emulador de Observadores de Percepção (POE) C475 da Fig. 813. Após a produção dos resultados da Pesquisa de armazenamento (SS) C716 C480, o
Petição 870200056145, de 06/05/2020, pág. 461/1737
459/754
C718 de cálculo de peso é concluído para executar o C729, aplicação das percepções 5512/5514/5516 para tomar uma decisão ativa para aprovar C731 ou bloco C730. A Estrutura do Framework Ideal 8750 produzida pela LOM 132 e o Agregado de Registro de LOM 5502 correspondente passam pela Análise de Dados 0724, que leva aos Registros de Dados 0723 Aprimorados que são aplicados no Aplicativo 0729 para obter uma Dicotomia de Interpretação 5518 de uma sensação positiva (aprovação) 0731 ou sensação negativa (bloqueio) 0730 em relação à entrada de configuração ideal de hardware 8824. Após a conclusão bem-sucedida da execução do aplicativo C729, ocorre uma ação corretiva de substituição 0476 que é processada usando a Saída de Decisão Crítica (CDO) C462 em paralelo a Saída Modular da Execução de Regras (RE) C461. 0 módulo de Densidade do Conhecimento Autocrítico (SCKD) C474 estima o escopo e o tipo de conhecimento potencial desconhecido que está fora do escopo do relatório de Agregado de Registros de LOM 5502. Dessa forma, os recursos de pensamento crítico subsequentes da instância de processamento CTMP 124 podem tirar proveito do escopo potencial de todo o conhecimento envolvido, conhecido e desconhecido diretamente pela instância.
[904] A Fig. 815 mostra o processo C460 de memória da Web operando em paralelo com a execução do Emulador de Observadores de Percepção (POE) C475 na Fig. 814. A configuração ideal de hardware 8824 produzida pelo LOM 132 é apresentada como uma entrada modular para o Motivo do Processamento C456. 0 Processamento de Motivos C456 processa como o LOM 132 tomou a decisão de produzir a Configuração Ideal de Hardware 8824 em resposta ao Aviso 8823 fornecido pelo ICIP 8822. A conclusão do
Petição 870200056145, de 06/05/2020, pág. 462/1737
460/754 processamento do Processamento de Motivos C456 é a execução do Processamento de Motivos C457, que define regras terceiro consistentes com o comportamento de execução da LOM. Se forem encontradas inconsistências no comportamento das regras em relação ao comportamento de execução da LOM, as regras existentes serão modificadas ou novas regras serão adicionadas. Essas regras são subsequentemente usadas na instância 124 do CTMP para criticar os comportamentos de tomada de decisão encontrados na instância LOM 132 correspondente. O Extensor de Âmbito de Regras Críticas CR45 utiliza percepções conhecidas para expandir o escopo do pensamento crítico dos conjuntos de regras, aprimorando os conjuntos de regras para produzir as Regras Corretas C459. As regras corretas C459 são enviadas como entrada modular para a regra de sintaxe de regras (RSFS) C499 da jurisdição operacional da Memória Web C460. O RSFS C499 separa e organiza as regras corretas C459 por tipo. Portanto, todas as ações, propriedades, condições e objetos são listados separadamente após o processamento do RSFS C499. Isso permite que a instância do CTMP 124 discernir quais partes foram encontradas no campo caótico e quais não foram. A Análise de Campo Caótico (CFP) C535 combina e formata o Agregado de Registro de LOM 5502 em uma única unidade digitalizável chamada Campo Caótico. O campo caótico é apresentado como uma entrada modular para o reconhecimento de memória (MR) C501. O MR C501 também recebe as Regras originais C555, que são o resultado da execução do RSFS C499. O MR C501 varre o Campo Caótico fornecido pelo CFP C535 para reconhecer conceitos conhecíveis definidos nas Regras Originais C555. Essa execução da instância MR C501 produz os
Petição 870200056145, de 06/05/2020, pág. 463/1737
461/754 segmentos de regra reconhecidos C556. Posteriormente, o analisador de conformidade de regras (RFP) C498 recebe partes individuais das regras originais C555 que foram rotuladas de acordo com seu reconhecimento ou falta dentro do campo caótico pelo MR C501. 0 RFP C498 pode deduzir logicamente que conjunto de regras (a combinação de todas as suas partes) foi suficientemente reconhecido no Campo Caótico para merecer ser processado pela Execução de Regras (RE) C461. Após a conclusão bem-sucedida do RE C461, ocorre a ação corretiva de substituição C476 que é processada pela Saida de Decisão Critica (CDO) C462 em paralelo com a saida modular C475 Emulador de Observadores de Percepção (POE).
[905] A Fig. 816 explica a interação do fluxo lógico entre o Armazenamento de Perceção (PS) C478 e o Mecanismo de descoberta de percepção automatizada (APDM) C467. O PS C478 contém quatro subconjuntos de percepções: Ângulos de percepção desconhecidos deduzidos C473, Todos os ângulos de percepção C472, Ângulos de percepção implícitos C471 e Ângulos de percepção aplicados C470. C470 Ângulos de percepção aplicados são percepções que foram importadas diretamente pelo estudo do comportamento algorítmico do Algoritmo de Correspondência de Padrões Selecionados (SPMA), que neste caso é LOM 132. Os ângulos de percepção implícitos C471 são Percepções que foram derivadas dos Ângulos de Percepção Aplicados C470 por meio da execução modular das Derivações de Implicações (ID) C477 e APDM C467. Todos os ângulos de percepção C472 representam o escopo completo das percepções conhecidas no CTMP 124 que não foram incluídas pelos ângulos de percepção aplicados C470 e pelos ângulos
Petição 870200056145, de 06/05/2020, pág. 464/1737
462/754 implícitos de percepção C471. Os ângulos de percepção desconhecidos deduzidos 0473 representam o escopo das percepções que existem, no entanto, a instância do CTMP 124 ainda não foi descoberta de acordo com o módulo C474 da Densidade do conhecimento autocrítico (SCKD). 0 ID C477 analisa as métricas individuais dos Ângulos de percepção aplicados C470 para derivar deterministicamente os Ângulos implícitos de percepção C470, enquanto o APDM C467 varia criativamente as composições dos Ângulos de percepção C650 através do Módulo de criatividade 112 para produzir um novo Iteração C653 combinando os dois pesos iniciais de entrada C652. Portanto, todos os ângulos de percepção do C650 envolvidos no processamento do C467 APDM correspondem e são representados pela Declaração de Segurança Confiável 8320, produzida pelo módulo LOM 132 Afirmação de Construção (AC) C808A.
[906] A Fig. 817 detalha os detalhes operacionais do Extensor de Âmbito de Regras Críticas (CRSE) C458 do CTMP 124. Uma instância do Apelo Racional (RA) C811A opera no LOM 132 e chama ao Edifício de Contexto (CC) C817A para processar o Agregado de Registros de LOM 5502 através da Análise de Campo Caótico (CFP) C535. O CFP produz um campo caótico a partir da saída modular do CC C817A que é referenciada pelo reconhecimento de memória (MR) C501. As regras atuais C534 exibem regras indicativas do status operacional atual do algoritmo de correspondência de padrão selecionado (SPMA), que nesse caso é o LOM 132. As regras atuais C534 são enviadas como entrada modular para o módulo de Derivação da Sintaxe da Regra C504. (RSD), que é onde as regras lógicas em preto e branco se transformam em insights baseados em métricas. Portanto, o arranjo complexo de
Petição 870200056145, de 06/05/2020, pág. 465/1737
463/754 várias regras se torna uma percepção única e uniforme que é expressa através de várias métricas de diferentes gradientes. A saída modular do RSD C504 é fornecida como uma entrada modular para o Jogo de Perceção (PM) C503. Na PM C503, uma unidade de formato variável comparável (CVF) é formada a partir da percepção recebida do RSD C504. 0 CVF recém-formado é usado para procurar percepções relevantes no C478 Armazenamento de Perceção (PS) com índices semelhantes. As correspondências em potencial são enviadas como entrada modular para Geração de Regras de Sintaxe (GSR) C505. 0 RSG C505 recebe percepções confirmadas anteriormente que são armazenadas no Formato de Perceção e acessa a estrutura métrica interna do Perceção. As percepções são recebidas do PS C478 contendo as percepções C468 confirmadas anteriormente. Tais medidas métricas baseadas em graus tornamse regras binárias e lógicas que emulam o fluxo de informações de entrada/saída da percepção original. Portanto, o RSG C505 produz as Regras de percepção C537, que são percepções consideradas relevantes, populares e que se tornaram regras lógicas. Se uma Percepção (em seu Formato de Percepção original) tinha muitos relacionamentos métricos complexos que definiam muitas áreas cinzas, as regras preto e branco locais abrangem essas áreas cinzentas, expandindo a complexidade do conjunto de regras. Portanto, as regras perceptivas do C537 são armazenadas usando uma coleção de definições de formato de sintaxe da regra (RSF). As regras de percepção C537 são apresentadas como uma entrada modular no Reconhecimento de Memória (MR) C501, onde são contrastadas com o campo caótico produzido pelo PPC C535. Portanto, o MR C501 produz as Regras
Petição 870200056145, de 06/05/2020, pág. 466/1737
464/754 extras C536 que completam as Regras corretas C533 em sua validade.
[907] Os detalhes operacionais referentes à derivação de implicações (ID) C477 do CTMP 124 estão detalhados na Fig. 818. Os ângulos de percepção aplicados C470 do Armazenamento de perceção (PS) C478 são enviados como entrada modular para o ID C477 para produzir mais percepções que pertencem aos ângulos implícitos de percepção C471. Os ângulos de percepção aplicados do C470 são enviados especificamente para a combinação métrica ID C477 C493. A combinação de métricas C493 separa os ângulos de percepção recebidos C650 em categorias de métricas: Faixa C739, Tipo C740, Consistência C741, Intensidade C742. A disponibilidade e referência de métricas no sistema não são necessariamente limitadas a esses quatro tipos. Os ângulos de percepção de entrada do C650 estão relacionados à Substituição de Propósito 8258, que foi produzida pelo módulo 132 Construção de Afirmação de LOM C328A (AC) . A Complexidade Métrica C736 é apresentada como uma entrada modular para a Expansão Métrica (ME) C495. Com o ME C495, as métricas de múltiplos e variados ângulos de percepção C650 são categorizadas em bancos de dados individuais C739/C740/C741/C742 . O ME C495 aprimora o lote atual de métricas recebidas com detalhes/complexidade extraídos de métricas conhecidas/encontradas anteriormente. Depois de concluir o aprimoramento e enriquecimento da complexidade, as métricas são retornadas como uma saída modular ME C495 como um Conjunto de Complexidade Métrica B C737 e, em seguida, convertidas de volta em Ângulos de Percepção C650 para serem armazenadas em Ângulos de Percepção Implícitos C471, conforme ilustrado na Fig. 819.
Petição 870200056145, de 06/05/2020, pág. 467/1737
465/754
[908] A Fig. 819 continua o fluxo lógico do Derivação de Implicação (ID) C477 da Fig. 818, ilustrando o Conjunto de Complexidade Métrica C737 que está sendo processado pela Conversão Métrica C494, que inverte as métricas individuais de volta aos Ângulos de Percepção C650 completo. Apesar do processo de enriquecimento e conversão realizado pelo ID C477, os Ângulos de perceção C650 resultantes ainda fornecem uma representação razoavelmente precisa da Substituição de Propósitos 8258 produzida pelo módulo de Afirmação de Construção de LOM 132 (AC) C808A. Portanto, o processo de conversão métrica C494 sujeita os novos ângulos de percepção derivados ou implícitos C650 aos ângulos implícitos de percepção C471 no armazenamento de percepção (PS) C478.
[909] A Fig. 820 detalha os detalhes operacionais relacionados a CTM62 Saída de Decisão Crítica (CDO) 124 C462. O CDO C462 recebe saída modular dos dois principais ramos do CTMP 124 do Emulador de Observador de Perceção (POE) C475 (como ramo de intuição) e Execução das Regras (RE) C461 (como ramo lógico). Cada ramificação C475/461 apresenta sua respectiva Decisão C521 (a principal saída modular), bem como os correspondentes Metametadados C521, que fornecem variáveis contextuais que justificam por que a decisão crítica inicial foi tomada. Os conjuntos de decisões C521 que representam as percepções C516 da PO5 C475 e as regras C517 da RE C461 são enviados ao módulo de categorização de metadados (MCM) C488. O MCM C488 separa os rastreamentos de depuração e algoritmo em diferentes categorias usando a categorização baseada em sintaxe das informações. Essas categorias podem ser usadas para organizar e produzir respostas
Petição 870200056145, de 06/05/2020, pág. 468/1737
466/754 de segurança diferentes com uma correlação com riscos e problemas de segurança. A Decisão Intuitiva C514, representando as Percepções C526 do POE C475, e a Decisão Pensante C515, representando as Regras C517 de RE C461, são enviadas pelo MCM C488 à Lógica de Processamento Interno 5520 da Comparação de Decisões de Gerenciamento (DDC) C512. A Lógica de Processamento Interno DDC C512 5520 verifica se há corroboração ou conflito entre a Decisão Intuitiva C514 e a Decisão Pensada C515. O DDC C512 refere-se a uma variável cut-off da política estática de código rígido (SHP) 488. Se a variável cut-off não for alcançada pela similaridade entre a Decisão Intuitiva C514 e a Decisão de Pensamento C515 (ou seja, 90% +) , ocorre a diretiva de Cancelar Comparação 5524 direta, que pode levar o Controlo de Saída de Terminal (TOC) C513 a registrar um Voto de Não-Confiança 5544, conforme mostrado na Fig. 821. No estágio Cancelar Comparação 5524 direita implica que o CTMP 124 não pôde atuar internamente de maneira consistente com relação à entrada Ask 8268 no RIP 8266. Se a variável cut -off foi suficientemente atendida de acordo com a lógica de processamento interno 5520, fase 5522 da decisão final, que combina as decisões C514/C515 em uma única saída modular que é recebida e processada pelo TOC C513 .
[910] A Fig. 821 continua o fluxo lógico da Saída de Decisão Crítica (CDO) C462 da Fig. 794 e elabora os detalhes operacionais do Controlo de Saída do Terminal (TOC) C513. O TOC C513 começa com o Aviso 5526, que verifica se a Comparação Direta de Decisão (DDC) C512 foi capaz de fornecer uma saída de decisão final 5522 (em vez da diretiva de Comparação de Cancelamento
Petição 870200056145, de 06/05/2020, pág. 469/1737
467/754
Direta 5524) . Se a resposta à pergunta 5526 for Sim 5528, a decisão final combinada fornecida pelo DDC C512 na Saída de decisão final 552 será apresentada como a saída modular do TOC C513 e, portanto, como a saída modular de toda a instância do CTMP 124 como a saída da Decisão Crítica Final 5542. Se a resposta à Pergunta 5526 for a 5555, o estágio 5532 será chamado, o que, por sua vez, invoca a execução do Correspondência de Perceção (PM) 5532 e obtém os resultados correspondentes. As Regras Cumpridas C517 são extraídas da Decisão Crítica + Meta-metadados C521 da Regra de Execução (RE) C461. As regras C517 são convertidas em percepções por derivação de sintaxe de regras (RSD) C504. A MP 5532 refere-se então aos meta-metadados para determinar, no Aviso 5534, se houve forte sobreposição interna e corroboração das percepções utilizadas. Se a resposta à pergunta 5534 for Sim 5538, isso indica um voto de não confiança 5544 em nome do CTMP 124 como uma saída modular. Se a resposta à pergunta 5534 for n° 5536, a Etapa 5540 será ativada, que seleciona a decisão de menor risco percebida entre a Decisão Intuitiva C514 e a Decisão Pensante C515. Portanto, a Decisão Crítica Final 5542 é subsequentemente apresentada como uma saída modular para CDO C462, TOC C513 e CTMP 124. A lógica na Etapa 5534 ocorre para determinar se a falta de unidade entre a Decisão Intuitiva C514 e a Decisão de Pensamento C515. Isso ocorre devido a uma falta geral de confiança algorítmica ou devido a visões altamente opostas entre os dois. Portanto, se este último ocorrer, uma possível Decisão Crítica Final 5542 ainda é discernível como uma saída modular. Um Voto de Não Confiança 5544 sempre leva ao Resultado de Baixa Confiança C845 por lógica dentro do Apelo
Petição 870200056145, de 06/05/2020, pág. 470/1737
468/754
Racional (RA) C811A. A decisão critica final 5542 pode levar a um resultado de alta confiança C846 ou a um caminho lógico de resultado de baixa confiança C845 no AR C811A, dependendo da confiança algorítmica por trás da decisão crítica final 5542.
[911] A Fig. 822 mostra detalhes de como o LIZARD 120 funciona para converter a Configuração ideal de hardware 8824 em um Mapa de hierarquia de finalidades 8826. A configuração ideal de hardware 8824 é enviada ao módulo de sintaxe C35 (SM), que pertence à jurisdição do núcleo externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código; recebe o formato de finalidade complexo C325 do módulo de finalidade (PM) C36. O formato de finalidade complexa do C325 é escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de cálculo que são mais comuns entre todas as linguagens de programação, como instruções yes/no, loops etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real, com base na sintaxe de computação de destino desejada (linguagem de computador) . Para a leitura do código, o SM C35 fornece uma interpretação sintática do código do computador, para que o PM C36 obtenha um objetivo para a funcionalidade do código. A Configuração Ideal de Hardware 8824 é recebida no formato Sintaxe de Hardware 8825 através da Conversão de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de converter linguagens de cálculo conhecidas em tipos
Petição 870200056145, de 06/05/2020, pág. 471/1737
469/754 de sintaxe arbitrários. A saída da execução completa da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, uma vez concluída a execução da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para obter uma finalidade no formato de finalidade complexa C325 a partir do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada no SM C35. 0 PM C36 também é capaz de detectar fragmentos de código imersos em dados (binários/ASCII, etc.). A Interpretação Iterativa C328 itera através de todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325) referente às Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área LIZARD 120 que não é submetida a manutenção/autoprogramação automatizada e é programada direta e exclusivamente por especialistas da área relevante. O elemento de código principal C335 do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do
Petição 870200056145, de 06/05/2020, pág. 472/1737
470/754
Sistema C336 do IC C333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[912] A Fig. 823 continua o fluxo lógico da Fig. 822 para ilustrar como o LIZARD 120 funciona para converter a Configuração de hardware ideal 8824 no Mapa de hierarquia de finalidades 8826. A Redução Lógica C323 do Módulo de sintaxe (SM) C35 envia sua saída à Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 itera através de todas as funções interconectadas para produzir uma definição de propósito interpretada consultando Associações de Propósito C326. A saída de definição de finalidade existe no formato de finalidade complexo C325, que é apresentado como uma saída modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e, portanto, para o LIZARD 120. A saída é rotulada como o Mapa de Hierarquia de Propósito 8826 que é apresentado como a versão C325 de Formato de Propósito Complexo da Configuração de Hardware Ideal 8824. A mesma definição e aplicação do núcleo interno (IC) C333 se aplica às funções e módulos mencionados acima.
[913] A Fig. 824 mostra o processo de Desenvolvimento de Hardware Melhorado (EHD) 8056, em que o Aviso de Chamada de Configuração Idealista (ICIP) 8830 fornece a configuração ideal de hardware 8824. O LIZARD 120 converte a Configuração de hardware ideal 8824 em um mapa de hierarquia de finalidades no Estágio 8834. No estágio 8836, o LOM 132 produz os Princípios de Engenharia Elétrica 8838 da CKR 648 e os envia para o LIZARD 120. O LIZARD 120 converte os Princípios de Engenharia Elétrica 8838
Petição 870200056145, de 06/05/2020, pág. 473/1737
471/754 no Mapa de Hierarquia de Propósitos 8842 em Etapa 8840. O Processamento de Simetria de Propósito a Propósito (P2SP) 7000 usa o Mapa de Hierarquia de Propósito 8842 e o Mapa de Hierarquia de Propósito 882 6 e cria um Resultado de Processamento de Simetria 8844 que determina se o Mapa de Hierarquia de Propósito 8826 da Configuração Ideal de Hardware 8824 é compatível com o Mapa de Hierarquia de Finalidade 8842 dos Princípios de Engenharia Elétrica 8838 em etapa 8846.
[914] A Fig. 825 mostra o processo 8056 de Desenvolvimento de hardware aprimorado (EHD), em que o LOM 132 produz os Princípios de engenharia elétrica 8838 da CKR 648 Retenção de conhecimento central na etapa 8836, com base no Aviso de invocação do princípio de design (DPIP) 8648. LOM construir conceitos de horas extras no CKR 648 a partir de dados recuperados pelo ARM 134 que facilitam o processo de determinação dos Princípios de Engenharia Elétrica 8838. O CKR 648 constrói uma base sólida de definições por meio de raciocínio avançado inato, e é capaz de justificar qualquer conclusão de que o LOM produz 8838. Com a Criação de Cluster C854F, o CKR 648 chega a conclusões conceituais através do empilhamento de blocos de informações conhecidos como Clusters no Formato de Conhecimento da Unidade (UKF) C854F. Esses grupos abrangem uma ampla gama de metadados relacionados às informações de destino, como fontes atribuíveis, tempos de criação de informações suspeitas, eficiência, design etc. Cada cluster UKF C854F contém o formato de Sintaxe de Regras (RSF) C538.
[915] A Fig. 826 mostra detalhes de como o LIZARD 120 trabalha para converter os Princípios de Engenharia Elétrica 8838
Petição 870200056145, de 06/05/2020, pág. 474/1737
472/754 em um Mapa de Hierarquia de Propósitos 8842. Os Princípios de Engenharia Elétrica 8838 são submetidos ao Módulo de sintaxe (SM) C35, que pertence à jurisdição do Núcleo externo (OC) C329. 0 SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código; recebe o formato de finalidade complexo C325 do módulo de finalidade (PM) C36. 0 formato de finalidade complexa do C325 é escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. 0 pseudocódigo contém implementações básicas de operações de cálculo que são mais comuns entre todas as linguagens de programação, como instruções yes/no, loops etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real, com base na sintaxe de computação de destino desejada (linguagem de computador) . Para a leitura do código, o SM C35 fornece uma interpretação sintática do código do computador, para que o PM C36 obtenha um objetivo para a funcionalidade do código. Os Princípios da engenharia elétrica 8838 são recebidos no formato de sintaxe dos Princípios 8147 por meio da tradução de código C321. A Tradução de Código C321 converte código arbitrário (genérico) reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de converter linguagens de cálculo conhecidas em tipos de sintaxe arbitrários. A saída da execução completa da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, uma vez concluída a execução da Redução
Petição 870200056145, de 06/05/2020, pág. 475/1737
473/754
Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para obter uma finalidade no formato de finalidade complexa C325 a partir do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada no SM C35. 0 PM C3 6 também é capaz de detectar fragmentos de código imersos em dados (binários/ASCII, etc.). A Interpretação Iterativa C328 itera através de todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325) referente às Associações de Objetivo C326. 0 Núcleo Interno (IC) C333 é a área LIZARD 120 que não é submetida a manutenção/autoprogramação automatizada e é programada direta e exclusivamente por especialistas da área relevante. 0 elemento de código principal C335 do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento de Objetivos do Sistema C336 do IC C333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[916] A Fig. 827 continua o fluxo lógico da Fig. 826 para ilustrar a operação do LIZARD 120 para converter os
Petição 870200056145, de 06/05/2020, pág. 476/1737
474/754
Princípios de engenharia elétrica 8838 em um Mapa de hierarquia de finalidades 8842. A Redução Lógica C323 do Módulo de sintaxe (SM) C35 envia sua saída à Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 itera através de todas as funções interconectadas para produzir uma definição de propósito interpretada consultando Associações de Propósito C326. A saída de definição de finalidade existe no formato de finalidade complexo C325, que é apresentado como uma saída modular para PM C36 e, portanto, para o C329 Núcleo Exterior (OC) e, portanto, para o LIZARD 120. A saída é rotulada como Mapa de Hierarquia de Propósito 8842, que é apresentado como a versão do Formulário de Propósito Complexo C325 dos Princípios de Engenharia Elétrica 8838. A mesma definição e aplicação do núcleo interno (IC) C333 se aplica às funções e módulos mencionados acima.
[917] A Fig. 828 mostra o processo de Desenvolvimento de Hardware Melhorado (EHD) 8056 para o Mecanismo Dinâmico de Implementação de hardware (DHDM) 8860. O resultado do processamento de simetria 8844 é determinado na Etapa 8846 para verificar se o Mapa de Hierarquia de Propósitos da configuração ideal de hardware é compatível com o mapa da hierarquia de finalidades dos princípios de projeto de engenharia elétrica. Se Não, não é compatível com 8850, envia um DLU 1182 com o Token 1184 do Sistema Oficial para o Envio de Registro de Diagnóstico do Mecanismo de Investigação Automatizada (ARM) 1160 (DLS) 114. Se o resultado da etapa 8846 for Sim, compatível com o estágio 8848, envia a configuração de hardware ideal para o DHDM 8860 no estágio 8852.
Petição 870200056145, de 06/05/2020, pág. 477/1737
475/754
[918] A Fig. 829 continua o fluxo lógico da Fig. 828 para o processo 8056 de Desenvolvimento de Hardware Aprimorado (EHD) para o Mecanismo de Implantação Dinâmica de Hardware (DHDM) 8860 com placa condutora dinâmica líquida (DLCB) 8856 direcionada à coleção DLCB 8858 para estudar o DLCB 8862. Na Etapa 8864, acessa os Chips de Invocação de Modificação Dinâmica DMIC da Coleção Alvo DLCB e, na Etapa 8866, categoriza os DLCB entre aqueles que possuem uma DMIC bloqueada e aqueles com uma DMIC desbloqueada. Na etapa 8872, envie todos os DLCB da DLCB DM70 (UDCR) 8870 para o Mecanismo de Especificações de Lançamento (SRM) 8786 para a instalação da Configuração de hardware ideal. Na etapa 8874, estabelece o Contrato de negociação do fabricante (MNS) para todos os DLCB de retenção de cache DMIC bloqueado 8868. (LDCR) 8854 interage com o MNS 8876, que entra no mecanismo de implantação de especificações (SRM) 8786.
[919] As Fig. 830 a 832 mostram o processo para Implantação automatizada da UBEC (UAD) 8900 a partir da Etapa 188, onde o SPSI 130 envia atualizações de software, firmware e hardware para a estrutura de código principal do UBEC 192. O Mecanismo de Destino de Implantação (DTM) 8902 encaminha as atualizações recebidas para o destino de implantação 8904. Na etapa 8906, uma instância da Lógica Básica Híbrida da UBEC/BCHAIN 190 é preparada para implantação no destino de implantação 8904. Os controladores de interface 212 são atualizados para cumprir totalmente as especificações atualizadas relevantes do destino de implantação 8904 na etapa 8908. Na etapa 8910, os controladores de interface são instalados na instância selecionada da lógica de Núcleo Híbrido da UBEC/BCHAIN da Lógica
Petição 870200056145, de 06/05/2020, pág. 478/1737
476/754
Central 190. O aplicativo atualizado, que foi montado a partir da instância lógica híbrida da UBEC/BCHAIN 190, é enviado para o objetivo de implementação 8904, na etapa 8912.
[920] A Fig. 831 continua o processo da Fig. 830 para a Implantação automatizada da UBEC (UAD) 8900. Na Etapa 8906, um exemplo da Lógica Central Híbrida da UBEC/BCHAIN 190 é preparado para implantação no destino de implantação. Na Etapa 8914, o Repositório Autorizado da Appchain para armazenar a Lógica Híbrida da UBEC/BCHAIN na Lógica Centrall90. Lógica Híbrida é consultada nas atualizações 846 da Appchain Metachain 834 de acordo com a identidade da Appchain fornecida por Appchains registradas 776. Na etapa 8916, uma solicitação de conteúdo é feita a partir da Lógica Central Híbrida da UBEC/BCHAIN por meio do Gerador de Reclamação de Conteúdo (CCG) 3050 para o BCHAIN 196 .
[921] A Fig. 832 continua o processo da Fig. 831 para a Implantação automatizada da UBEC (UAD) 8900 na etapa 8908. Os drivers de interface são atualizados para atender totalmente às especificações atualizadas relevantes do destino de implantação. Na etapa 8918, é feita referência às especificações de interface 8920 a partir das definições da meta de implantação 8904. Na etapa 8922, uma base genérica de drivers de interface 212 é referenciada para ser modificada e compatível com Especificação da interface 8920. O LIZARD 120 converte os drivers de interface base 212 em um mapa de hierarquia de finalidades 8928 na etapa 8924. O LIZARD converte as especificações de interface 8920 em um mapa de hierarquia de finalidades 8930 na etapa 8926.
[922] A Fig. 833 mostra detalhes de como o LIZARD 120
Petição 870200056145, de 06/05/2020, pág. 479/1737
477/754 funciona para converter os Controladores de interface 212 em um Mapa de hierarquia de finalidades 8928. Os controladores de interface 212 são enviados para o módulo de sintaxe C35 (SM), que pertence à jurisdição principal externo (OC) C329. 0 SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código; recebe o formato de finalidade complexo C325 do módulo de finalidade (PM) C36. 0 formato de finalidade complexa do C325 é escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. 0 pseudocódigo contém implementações básicas de operações de cálculo que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real, com base na sintaxe de computação de destino desejada (linguagem de computador) . Para a leitura do código, o SM C35 fornece uma interpretação sintática do código do computador, para que o PM C36 obtenha um objetivo para a funcionalidade do código. Os Controladores da Interface 212 foram recebidos no formato 8925 das Especificações do Controlador pela Tradução de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de converter linguagens de cálculo conhecidas em tipos de sintaxe arbitrários. A saída da execução completa da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe
Petição 870200056145, de 06/05/2020, pág. 480/1737
478/754
C322. Portanto, uma vez concluída a execução da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para obter uma finalidade no formato de finalidade complexa C325 a partir do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada no SM C35. 0 PM C3 6 também é capaz de detectar fragmentos de código imersos em dados (binários/ASCII, etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325) referente às Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área LIZARD 120 que não é submetida a manutenção/autoprogramação automatizada e é programada direta e exclusivamente por especialistas da área relevante. 0 elemento de código principal C335 do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[923] A Fig. 834 continua o fluxo lógico da Fig. 833
Petição 870200056145, de 06/05/2020, pág. 481/1737
479/754 para ilustrar como o LIZARD 120 funciona para converter os controladores de interface 212 em uma hierarquia de mapa de objetivos 8928. A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saída para Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada referente às Associações de Propósito C326. A saída de definição de finalidade existe no formato de finalidade complexo C325, que é apresentado como uma saída modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e, portanto, para o LIZARD 120. A saída é rotulada como o Mapa da Hierarquia de Propósito8928, apresentado como a versão C325 Formato de Propósito Complexo dos Controladores de Interface 212. A mesma definição e aplicação do Núcleo Interno C333 (IC) se aplica às funções e módulos mencionados acima.
[924] A Fig. 835 mostra detalhes de como o LIZARD 120 funciona para converter as especificações da interface 8920 em um mapa de hierarquia de finalidades 8930. As especificações da interface 8920 são enviadas ao Módulo de Sintaxe C35 (SM) pertencente à jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código; recebe o formato de finalidade complexo C325 do módulo de finalidade (PM) C36. O Formato de Finalidade Complexa do C325 é escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de cálculo que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Em seguida, uma função auxiliar
Petição 870200056145, de 06/05/2020, pág. 482/1737
480/754 converte o pseudocódigo em código executável real, com base na sintaxe de computação de destino desejada (linguagem de computador) . Para a leitura do código, o SM C35 fornece uma interpretação sintática do código do computador, para que o PM C36 obtenha um objetivo para a funcionalidade do código. As especificações da interface 8920 são recebidas no formato das especificações da estrutura 8975 usando a Tradução de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de converter linguagens de cálculo conhecidas em tipos de sintaxe arbitrários. A saida da execução completa da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, uma vez concluída a execução da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para obter uma finalidade no formato de finalidade complexa C325 a partir do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada no SM C35. O PM C3 6 também é capaz de detectar fragmentos de código imersos em dados (binários/ASCII, etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de
Petição 870200056145, de 06/05/2020, pág. 483/1737
481/754
Propósito Complexo C325) referente às Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área LIZARD 120 que não é submetida a manutenção/autoprogramação automatizada e é programada direta e exclusivamente por especialistas da área relevante. 0 elemento de código principal C335 do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[925] A Fig. 836 continua o fluxo lógico da Fig. 835 para ilustrar a operação do LIZARD 120 para converter as especificações da interface 8920 em um mapa de hierarquia de finalidades 8930. A redução lógica C323 do módulo de sintaxe (SM) C35 envia sua saída para Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada referente às Associações de Propósito C326. A saída de definição de finalidade existe no formato de finalidade complexo C325, que é apresentado como uma saída modular para PM C36 e, portanto, para o C329 Núcleo Exterior (OC) e, portanto, para o LIZARD 120. A saída é rotulada como o Mapa de Hierarquia de Propósito 8930, apresentado como a versão C325
Petição 870200056145, de 06/05/2020, pág. 484/1737
482/754
Formato de Propósito Complexo das Especificações da interface 8920. A mesma definição e aplicação do núcleo interno C333 (IC) se aplica às funções e módulos mencionados acima.
[926] A Fig. 837 mostra os detalhes do Implantação Automatizada da UBEC 8900 na Etapa 8908. Os controladores de interface são atualizados para cumprir totalmente com as especificações relevantes dos Objetivos de Implantação atualizados. Na Etapa 8932, os Mapas de Hierarquia de Propósito 8930 e 8932 passam pelo PRP (Processamento de Realinhamento de Propósito) 7050, com o Mapa derivado dos Controladores da Interface 8928 como Escravo e o Mapa derivado das Especificações da Interface 8920 como a Afinidade Mestre/Escravo 1480. Na Etapa 8936, um Mapa de Finalidade 8934 atualizado é produzido representando os Controladores de Interface 212 compatíveis com as Especificações de Interface 8920. O LIZARD 120 converte o Mapa de Finalidade 8934 atualizado em Interface 212 Drivers na Etapa 8938 .
[927] A Fig. 838 mostra detalhes da implantação automatizada do UBEC 8900 na etapa 8910. Os drivers de interface são instalados na instância selecionada do kernel hibridizado. Na Etapa 8940, o Plug-in de interface modular 194 é selecionado na Instância lógica do núcleo híbrido 8918. O LIZARD 120 instala os drivers de interface 212 no plug-in de interface modular 194 usando as referências de gancho 8944 predefinidas da API, na etapa 8942.
[928] A Fig. 839 mostra os detalhes da Implantação Automatizada da UBEC 8900 na Etapa 8942, a LIZARD instala os drivers de interface no plug-in de interface modular usando
Petição 870200056145, de 06/05/2020, pág. 485/1737
483/754 ganchos de API predefinidos. Na etapa 8942, o LIZARD 120 instala os drivers de interface 212 no plug-in de interface modular 194 usando as referências de gancho predefinidas da API 8944. Na etapa 8946, percorre todas as referências de gancho da API 8944 definidas. Na etapa 8950, verifica se a Unidade de referência de gancho da API selecionada 8948 existe no plug-in de interface modular 194. Se a unidade não existir 8952, envie a DLU com ο sistema oficial 5600. Se a unidade existir 8954, vá para a etapa 8956, onde armazena uma referência à parte 194 do plug-in de interface modular que corresponde à unidade de referência de gancho de API selecionada 8948 em o do Gancho de Retenção de Cache de Localização (HLCR) 8958. Na etapa 8960, verifica se a Unidade de referência de API de gancho 8948 selecionado existe na interface. Se a unidade não existir 8964, envia uma DLU com o sistema oficial para 5600. Se a unidade existir 8962, ela armazenará uma referência da parte dos controladores de interface que corresponde à unidade de gancho API 8948 selecionada.
[929] A Fig. 840 continua a lógica da Fig. 839 para mostrar os detalhes da Implantação Automatizada da UBEC 8900 na Etapa 8942. A LIZARD instala os drivers de interface no plug-in de interface modular usando ganchos de API predefinidos. Na Etapa 8966, recupera as partes dos controladores de interface 212 e do plug-in de interface modular 194 que são referenciados com a Unidade de Referência do Gancho de Retenção de Cache de Localização (HLCR) 8964 8958. Na Etapa 8970 O LIZARD 120 converte a parte do plug-in de interface modular 194 referenciada ao mapa de hierarquia de finalidades 8972 e na etapa 8976, o LIZARD 120 converte a parte dos drivers de interface 212 referenciada ao
Petição 870200056145, de 06/05/2020, pág. 486/1737
484/754 mapa de hierarquia de finalidades 8978.
[930] A Fig. 841 mostra detalhes de como o LIZARD 120 funciona para converter a parte 8968 referente ao Plug-in de Interface Modular em um Mapa de Hierarquia de Propósitos 8972. A parte referenciada 8968 do plug-in de interface modular passa pela sintaxe (SM) C35, que pertence à jurisdição do kernel externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código; recebe o formato de finalidade complexo C325 do Módulo de finalidade (PM) C36. O formato de finalidade complexa do C325 é escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de cálculo que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real, com base na sintaxe de computação de destino desejada (linguagem de computador) . Para a leitura do código, o SM C35 fornece uma interpretação sintática do código do computador, para que o PM C36 obtenha um objetivo para a funcionalidade do código. O plug-in de interface modular mencionado na parte 8968 é recebido no formato 8925 das especificações do driver pela Tradução de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de converter linguagens de cálculo conhecidas em tipos de sintaxe arbitrários. A saida da execução completa da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução
Petição 870200056145, de 06/05/2020, pág. 487/1737
485/754
Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, uma vez concluída a execução da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para obter uma finalidade no formato de finalidade complexa C325 a partir do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada no SM C35. 0 PM C36 também é capaz de detectar fragmentos de código imersos em dados (binários/ASCII, etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325) referente às Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área LIZARD 120 que não é submetida a manutenção/autoprogramação automatizada e é programada direta e exclusivamente por especialistas da área relevante. O elemento de código principal C335 do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis
Petição 870200056145, de 06/05/2020, pág. 488/1737
486/754 de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[931] A Fig. 842 continua o fluxo lógico da Fig. 841 para ilustrar a operação do LIZARD 120 para converter a parte 8968 referente ao Plug-in de Interface Modular em um Mapa de Hierarquia de Propósitos 8972. Redução lógica C323 do Módulo de sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada referente às Associações de Propósito C326. A saída de definição de finalidade existe no formato de finalidade complexo C325, que é apresentado como uma saída modular para PM C36 e, portanto, para o Núcleo Exterior C329 (OC) e, portanto, para o LIZARD 120. A saída é rotulada como o Mapa de Hierarquia de Finalidade 8972, apresentado como a versão C325 Formato de Propósito Complexo do Plug-in de Interface Modular mencionado na Parte 8968. A mesma definição e aplicação do núcleo interno C333 (IC) se aplica a funções e módulos mencionados acima.
[932] A Fig. 843 mostra detalhes sobre como o LIZARD 120 trabalha para converter a parte 8974 dos controladores de interface em uma hierarquia de mapa de objetivos 8978. A parte 8974 dos controladores de interface referenciados é submetida ao Módulo de Sintaxe (SM) C35, que pertence à jurisdição do núcleo externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código; recebe o formato de finalidade complexo C325 do módulo de finalidade (PM) C36. O formato de finalidade complexa do C325 é escrito em sintaxe
Petição 870200056145, de 06/05/2020, pág. 489/1737
487/754 de código arbitrária, também conhecida como 'pseudocódigo'. 0 pseudocódigo contém implementações básicas de operações de cálculo que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real, com base na sintaxe de computação de destino desejada (linguagem de computador) . Para a leitura do código, o SM C35 fornece uma interpretação sintática do código do computador, para que o PM C36 obtenha um objetivo para a funcionalidade do código. A parte 8974 dos drivers de interface referenciados é recebida no formato 8975 das especificações da estrutura pela Tradução de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de converter linguagens de cálculo conhecidas em tipos de sintaxe arbitrários. A saída da execução completa da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, uma vez concluída a execução da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para obter uma finalidade no formato de finalidade complexa C325 a partir do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada
Petição 870200056145, de 06/05/2020, pág. 490/1737
488/754 no SM C35. O PM C3 6 também é capaz de detectar fragmentos de código imersos em dados (binários/ASCII, etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325) referente às Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área LIZARD 120 que não é submetida a manutenção/autoprogramação automatizada e é programada direta e exclusivamente por especialistas da área relevante. 0 elemento de código principal C335 do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[933] A Fig. 844 continua o fluxo lógico da Fig. 843 para ilustrar a operação do LIZARD 120 para converter a parte 8974 referente aos controladores de interface em um mapa de hierarquia de finalidades 8978. Redução lógica C323 do módulo de sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada referente às Associações de Propósito C326. A saída de definição de finalidade existe no
Petição 870200056145, de 06/05/2020, pág. 491/1737
489/754 formato de finalidade complexo C325, que é apresentado como uma saída modular para PM C36 e, portanto, para o Núcleo Exterior C329 (OC) e, portanto, para o LIZARD 120. A saída é etiqueta como Mapa de hierarquia de finalidades 8978, que é apresentada como a versão C325 Formato de Propósito Complexo da Parte 8974 do controlador de interface mencionada. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às funções e módulos mencionados acima.
[934] A Fig. 845 mostra os detalhes da Implantação automatizada da UBEC (UAD) 8900 na Etapa 8942, o LIZARD 120 instala os drivers de interface no plug-in de interface modular usando ganchos de API predefinidos. A Simetria de objetivo a objetivo (P2SP) 7000 analisa o mapa de hierarquia de finalidades 8972 com a parte de referência 8968 do plug-in de interface modular e o mapa de hierarquia de finalidades 8978 com a parte de referência 8974 dos controladores de interface. O resultado do processamento de simetria 8980 é revisado na Etapa 8982 para verificar se o Mapa de Hierarquia de Propósito 8972 da Parte 8968 do Plug-in de Interface Modular é consistente com o Mapa de Hierarquia de Propósito 8978 do Mapa de Hierarquia de Propósito 8978 de os controladores de interface referenciados, parte 8974. Sim, 8984 congruente, prossiga para a etapa 8988, onde usando o módulo de sintaxe C35 (SM) via LIZARD 120, a parte referenciada do plug-in de interface modular é modificada para ser aplicada pelos controladores correspondentes Interface referenciada. Se a resposta for Não, não for consistente, 8986, ela apresenta uma DLU com o Sistema Oficial 5600.
[935] A Fig. 846 mostra os detalhes da Implementação
Petição 870200056145, de 06/05/2020, pág. 492/1737
490/754
Automatizada (DUA) 8900 da UBEC na Etapa 8912, onde o Aplicativo atualizado, que foi montado a partir da instância da Lógica Híbrida do Núcleo, é enviado para a Meta de Implementação. O LIZARD 120 instala os controladores de interface 212 no plug-in de interface modular 194 usando ganchos de API predefinidos na etapa 8942. Na etapa 8990, o LIZARD 120 altera as referências de contêiner para a Instância 8918 da lógica do núcleo híbrido modificado para que se manifesta como um pacote de aplicativos que contém. Na Etapa 8992, verifica se o destino de implantação 8904 exige que o aplicativo seja apresentado no 8994 bruto ou no 8996 binário.
[936] A Fig. 847 continua a lógica da Fig. 846 para obter os detalhes da Instalação automatizada UBEC (UAD) 8900 na Etapa 8912, onde o Aplicativo atualizado, que foi montado a partir da instância da Lógica do Núcleo Híbrido, é enviado para o destino de implantação. Na etapa 9001 (rotulada como 9000), é verificado se a meta de implantação 8904 define uma rotina atualizada da estratégia de implantação 9000. Se sim, 9004, prossegue para a Etapa 9006, onde o aplicativo UBEC/BCHAIN é enviado para o destino de implantação 8904 por meio da Rotina de Estratégia de Implantação 9000 definida. Se não for o 9002, ele envia um DLU 1182 com o Token 1184 do sistema oficial na Etapa 5000 para o ARM 134 1160 da Submissão de Registo de Diagnóstico (DLS) .
[937] A Fig. 848 mostra os estágios de adoção da Appchain (SA2) 9100 com o Estágio 1 - Legado 9102 completo, que contém o Sistema Legado 9104, que consiste na API de Legado e no Framework 9106. No 9112, ele converte o programa da operação 9108
Petição 870200056145, de 06/05/2020, pág. 493/1737
491/754 para a Appchain 9118. 0 SPSI executa atualizações de eficiência e funcionalidade, manutenção e modificações gerais no Programa como um Legado 9110. Estágio 2 - Appchain Emulado Sobre o Legado 9116 contém o Sistema Legado 9104, que consiste na API de Legado e Framework 9106 que contém a Camada de emulação da Appchain (AEL) 8058. O SPSI executa atualizações de eficiência e funcionalidade, manutenção e modificações gerais no Programa como uma Appchain 9120.
[938] A Fig. 849 mostra os estágios da Adoção da Appchain (SA2) 9100 com o estágio 2 - o estágio emulado da Appchain de Legado 9116 contém o sistema herdado 9104 que consiste na API herdada e o Framework 9106 que contém a Camada de Emulação da Appchain (AEL) 8058. O SPSI executa atualizações de eficiência e funcionalidade, manutenção e modificações gerais no Programa como uma Appchain 9120. Na Etapa 9122, o Programa é implantado como uma Appchain 9126 na Rede BCHAIN para aumentar a disponibilidade, confiabilidade, velocidade, eficiência, segurança etc. O SPSI executa atualizações de eficiência e funcionalidade, manutenção e modificações gerais no Programa como uma Appchain 9128.
[939] A Fig. 850 mostra o Legado para a Implantação da BCHAIN (LBD) 9200 com os estágios de adoção da Appchain (SA2) 9100 com o Programa de Implantação como uma Appchain para a rede BCHAIN para aumentar a disponibilidade, confiabilidade, velocidade, etc. 9122. A Administração de Legado 8086 opta explicitamente que o aplicativo Appchain alvo seja implantado na rede BCHAIN em 9202. No 9204, a Administração de Legado 8086 se compromete a autenticar com a Interação do Nó do Utilizador (UNI)
Petição 870200056145, de 06/05/2020, pág. 494/1737
492/754
470 do Protocolo BCHAIN por meio de um Sessão de usuário autenticado 522. No 9208, os fundos apropriados são creditados no UPFA 718 correspondente, relacionado à Lista de nós associados 518, que é descompactada da Sessão de usuário autenticado 522. O Programa Direcionado como Appchain 9126 é implantado no Rede BCHAIN.
[940] A Fig. 851 continua a lógica da Fig. 850, mostrando o Legado para a Implantação da BCHAIN (LBD) 9200 no Programa Direcionado à medida que uma Appchain é implementada na rede BCHAIN. Na Etapa 9212, o Programa como uma Appchain 9126 é enviado para a Rede BCHAIN através do Novo Anúncio de Conteúdo (NCA) 2544. Em 606, o conteúdo é enviado para o Armazenamento de Dados de Mempool (MDS) dos mineradores, onde é eventualmente extraído no próximo bloco da Appchain por meio do Módulo de Interface da Customchain (CIM) 2470. Em 608, o conteúdo do bloco recém-extraído é cortado em partes do cache e transferido para os nós do cache pelo cache de fornecimento de nós de Seeding de Mineração (MNSCS) 1850. No 610, as partes do cache migram gradual e automaticamente para áreas otimizadas para serviço, garantindo o melhor tempo de atividade possível e velocidade de download para nós que solicitam dados usando o algoritmo de seleção Cache (CSA) 2350. Na 612, os Nós recuperam o conteúdo dos nós de armazenamento em cache do CCG 3050. Após o download, esses nós podem executar o fluxo de execução através do ESR, levando a manifestação do aplicativo desejado.
[941] A Fig. 852 mostra a implantação da camada de emulação (ELD) 9250, em que a administração herdada 8086 interage com a interface de implantação 9272 na etapa 9252. Na etapa 9252,
Petição 870200056145, de 06/05/2020, pág. 495/1737
493/754 a administração anterior envia o tipo de sistema de destino 9256 para a interface Implantação (DI) 9272. No estágio 9260, o DI 9272 responde com um binário 9258 pré-compilado que é compatível com o tipo de sistema de destino 9256. Na Etapa 9262, a assinatura do binário pré-compilado 9258 é verificada para garantir que se origina de Dl 9272. Na Etapa 9266, a Administração Legada concede permissões de raiz binária persistente pré-compilada 9264. O binário pré-compilado e executado no sistema de destino pretendido, levando à execução da Camada de Emulação de Appchain (AEL) 8058.
[942] A Fig. 853 mostra a operação da Interface de implementação (Dl) 9272. Na Etapa 9274, circula todos os tipos de sistema 9270 disponíveis. O LIZARD 120 converte as dependências modulares da cadeia de notas 9284 no mapa de hierarquia de finalidades 928 6 e no mapa de hierarquia de finalidades 9288 na etapa 9278. Na etapa 9290, os mapas de hierarquia de finalidades das dependências modulares Nota A cadeia 9284 é integrada ao Mapa de hierarquia de finalidades 9282 do Código-fonte AEL 9280 via PRP 7050 para o Mapa de finalidades atualizado 9292.
[943] A Fig. 854 mostra detalhes de como o LIZARD 120 funciona para converter as dependências modulares da Appchain 9284 em relação ao LIZARD 120 em um mapa da Hierarquia de finalidades 9286. As dependências modulares da cadeia de recursos 9284 relacionadas ao LIZARD 120 são enviadas ao módulo de sintaxe (SM) C35 que pertence à jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código; recebe o formato de
Petição 870200056145, de 06/05/2020, pág. 496/1737
494/754 finalidade complexo C325 do módulo de finalidade (PM) C36. 0 formato de finalidade complexa do C325 é escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. 0 pseudocódigo contém implementações básicas de operações de cálculo que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real, com base na sintaxe de computação de destino desejada (linguagem de computador) . Para a leitura do código, o SM C35 fornece uma interpretação sintática do código do computador, para que o PM C36 obtenha um objetivo para a funcionalidade do código. As dependências modulares da Appchain 9284 relacionadas ao LIZARD 120 são recebidas no formato Sintaxe de Appchain 9285 por meio da Tradução de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A tradução de código C321 também executa a função inversa de converter linguagens de computador conhecidas em tipos de sintaxe arbitrários. A saída da execução completa da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, uma vez concluída a execução da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para obter uma finalidade no formato de finalidade complexa C325 a partir do
Petição 870200056145, de 06/05/2020, pág. 497/1737
495/754 código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada no SM C35. 0 PM C36 também é capaz de detectar fragmentos de código imersos em dados (binários/ASCII, etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325) referente às Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área LIZARD 120 que não é submetida a manutenção/autoprogramação automatizada e é programada direta e exclusivamente por especialistas da área relevante. O elemento de código principal C335 do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[944] A Fig. 855 continua o fluxo lógico da Fig. 854 para ilustrar a operação do LIZARD 120 para converter as dependências modulares da Appchain 9284 em relação ao LIZARD 120 em um mapa da Hierarquia de finalidades 9286. A redução lógica C323 do módulo de A sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A
Petição 870200056145, de 06/05/2020, pág. 498/1737
496/754
Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada referente às Associações de Propósito C326. A saida de definição de finalidade existe no formato de finalidade complexo C325, que é apresentado como uma saída modular para PM C36 e, portanto, para o C329 Núcleo Exterior (OC) e, portanto, para o LIZARD 120. A saída é rotulada como Mapa de Hierarquia de Propósito 9286, que é apresentado na versão C325 do Formulário de Propósito Complexo da Cadeia de Dependências Modulares 9284 referente ao LIZARD 120. A mesma definição e aplicação do núcleo interno (IC) C333 se aplica a as funções e módulos acima mencionados.
[945] A Fig. 856 mostra detalhes sobre como o LIZARD 120 funciona para converter as dependências da Appchain modular 9284 em relação ao I2GE 122 em um mapa da Hierarquia de finalidades 9288. As dependências modulares da Appchain 9284 relativas ao I2GE 122 são enviadas ao módulo de sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código; recebe o formato de finalidade complexo C325 do módulo de finalidade (PM) C36. O formato de finalidade complexa do C325 é escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de cálculo que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real, com base na sintaxe de computação de destino desejada (linguagem de
Petição 870200056145, de 06/05/2020, pág. 499/1737
497/754 computador) . Para a leitura do código, o SM C35 fornece uma interpretação sintática do código do computador, para que o PM C36 obtenha um objetivo para a funcionalidade do código. As dependências modulares da Appchain 9284 relacionadas ao I2GE 122 são recebidas no formato de Sintaxe da Appchain 9285 pela Tradução De código C321. A Tradução de Código C321 converte código arbitrário (genérico) reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A tradução de código C321 também executa a função inversa de converter linguagens de cálculo conhecidas em tipos de sintaxe arbitrários. A saída da execução completa da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, uma vez concluída a execução da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para obter uma finalidade no formato de finalidade complexa C325 a partir do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada no SM C35. 0 PM C36 também é capaz de detectar fragmentos de código imersos em dados (binários/ASCII, etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325) referente às Associações de Propósito C326. 0 Núcleo Interno (IC)
Petição 870200056145, de 06/05/2020, pág. 500/1737
498/754
C333 é a área LIZARD 120 que não é submetida a manutenção/autoprogramação automatizada e é programada direta e exclusivamente por especialistas da área relevante. O elemento de código principal C335 do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[946] A Fig. 857 continua o fluxo lógico da Fig. 856 para ilustrar a operação do LIZARD 120 para converter as dependências da cadeia de apendicite modular 9284 em relação ao I2GE 122 em um mapa da hierarquia de finalidades 9288. A Redução Lógica C323 do Módulo de A sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de propósito interpretada, consultando as Associações de Propósito C326. A saída de definição de finalidade existe no formato de finalidade complexo C325, que é apresentado como uma saída modular para PM C36 e, portanto, para o Núcleo Exterior C329 (OC) e, portanto, para o LIZARD 120. A saída é etiqueta como o Mapa de Hierarquia de Propósito 9288, que é apresentado como a versão C325 do Formato
Petição 870200056145, de 06/05/2020, pág. 501/1737
499/754 de Propósito Complexo das Dependências Modulares da Cadeia de Notas 9284 referente ao I2GE 122. A mesma definição e aplicação do núcleo interno (IC) C333 se aplica a as funções e módulos mencionados acima.
[947] A Fig. 858 mostra a operação da Interface de Implantação (Dl) 9272, na Etapa 9290, os Mapas de Hierarquia de Propósito da Unidade Modular da Cadeia de Notas 9284 são integrados no Mapa de Hierarquia de Propósito 9292 do Código Fonte da AEL via PRP 7050. Na Etapa 9294, o LIZARD 120 converte o Mapa de Finalidade Atualizado 9292 em uma Sintaxe Apropriada para o Tipo de Sistema Selecionado 9296. Na Etapa 9298, o binário 9296 pré-compilado resultante é armazenado no Armazenamento em Cache Binário. Pré-compilado (PBCR) 9302 e substitui um binário antigo pelo tipo de sistema, se existir. Na etapa 9300, o loop avança para o próximo sistema e loops disponíveis através de todos os tipos de sistema disponíveis 9274 para identificar o tipo de sistema selecionado 9296.
[948] A Fig. 859 mostra detalhes de como o LIZARD 120 funciona para converter o Mapa de Finalidade Atualizado 9292 em um Binário 9296 pré-compilado. O Mapa de Finalidade Atualizado 9292 existe no Formato de Finalidade Complexa C325 e é apresentado à Expansão Iterativa C327 do Finalidade C36 dentro do núcleo externo do LIZARD 120 C329. A Expansão iterativa C327 adiciona detalhes e complexidade para converter um único destino em uma definição específica de finalidade complexa. Portanto, o potencial máximo da entrada de associação de finalidade C326 é realizado e mantido como um formato de finalidade complexo C325, antes de ser enviado para a derivação lógica C320 do módulo de
Petição 870200056145, de 06/05/2020, pág. 502/1737
500/754 sintaxe (SM) C35. O Elemento de Código Principal C335 do Núcleo Interior (IC) C333 contém estruturas e bibliotecas principais, scripts de balanceamento de carga e gerenciamento de encadeamento, protocolos de criptografia e comunicação e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[949] A Fig. 860 continua o fluxo lógico da Fig. 859 para ilustrar a operação do LIZARD 120 para converter o Mapa de Finalidade Atualizado 9292 em um Binário Pré-compilado 9296. Os dados de entrada são recebidos no formato de finalidade complexa C325 a partir do módulo de finalidade (PM) C36 e transferido para a derivação lógica C320 do módulo de sintaxe (SM) C35. A derivação lógica C320 deriva funções logicamente necessárias de funções inicialmente mais simples. Isso significa que, se uma função pode ser formada como uma função derivada devido à implicação de uma função mãe mais simples, ela é formada pela Derivação Lógica C320. A saída produzida é uma árvore de dependências de funções que são construídas de acordo com os dados definidos no formato de propósito complexo C325. A Derivação Lógica C320 opera de acordo com as definições das Regras e Sintaxe C322 que são herdadas do elemento do Código Central C335 do Núcleo Interno (IC) C333. 0 Bypass Lógico C320 envia sua saída para a Conversão de Código C321. A tradução de código C321 converte código
Petição 870200056145, de 06/05/2020, pág. 503/1737
501/754 arbitrário (genérico) reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de converter linguagens de cálculo conhecidas em tipos de sintaxe arbitrários. Portanto, o PM C36 chama o SM C35 para produzir a versão da sintaxe resultante da entrada atualizada 9292 no Mapa de Propósitos usando a conversão de código C321. A unidade binária pré-compilada resultante 9296 que é produzida terminalmente pela Conversão de código C321 é a saída modular do SM C35, Núcleo Externo (OC) C329 e LIZARD 120.
[950] A Fig. 861 mostra a Interface de Implantação (Dl) 9272 iniciando na Etapa 9298, o binário pré-compilado 9296 resultante é armazenado no PBCR 9302 e substitui o binário antigo pelo Tipo de Sistema, se já existir. Na Etapa 9304, uma solicitação binária pré-compilada 9296 é enviada para o PBCR 9302. Na Etapa 9305 (etiqueta incorreta 9304 na Fig. 861), o binário pré-compilado correspondente 9296 que corresponde ao tipo de sistema de destino solicitado 9256 é enviado para o PBCR 9302. Administração herdada 8086 via ELD 9250 da PBCR 9302. No estágio 9260, o Dl 9272 responde com um binário 9296 pré-compilado que é compatível com o sistema de destino tipo 9256. A administração herdada 8086 envia o tipo de sistema de destino 9256 na etapa 9254 .
[951] [00] Figs. 862 - 879 mostram a operação e a funcionalidade da camada de emulação de cadeia de aparência 8058 (AEL), que permite executar a Appchain 836 em ambientes herdados que não participam da rede BCHAIN 110.
[952] A Fig. 862 mostra a produção de uma instância de
Petição 870200056145, de 06/05/2020, pág. 504/1737
502/754 uma pilha pré-compilada de aplicativos (PAS) 9400 via Processamento Estático Appchain (SAP) 9480. O SAP 9480 interpreta o conteúdo correspondente da Appchain 836, produzindo assim a Retenção Estática da Appchain 9402 e enviando-o como entrada modular para PAS 9400. A Camada de Emulação de Aplicativo 8058 (AEL) é compilada e incorporada no PAS 9400, dando autonomia à instância do PAS 9400 em sistemas legados. Um submódulo da AEL 8058 é a Interpretação e detecção do sistema de destino (TSID) 9404. Portanto, se esse PAS 9400 fosse invocado em um sistema arbitrário, o AEL 8058 executaria um conjunto de instruções básicas preliminares e procuraria detectar o sistema operacional 9408, Drivers de dispositivo 9410 e Hardware 9412 do sistema de destino 9406. Portanto, o AEL 8058 invocaria o mecanismo de conversão adequado para executar código complexo no sistema de destino 9406, permitindo que a Retenção Estática da Appchain 9402 fosse executada completamente. A retenção 9402 contém os Segmentos de Execução Appchain 836 Segmentos 551 e Dados 553 para a Appchain de destino 836, juntamente com outras 836 Appchains dos quais a Appchain 836 de destino depende para sua operação, como LOM 132 e LIZARD 120.
[953] A Fig. 863 mostra a operação e a funcionalidade da Camada de Emulação da Appchain 8058 (AEL). O Processamento Estático da Appchain (SAP) 9480 produz uma instância de Retenção Estática da Appchain 9402 que contém a Appchain 836 direcionada. A Retenção Estática da Appchain 9402 é apresentada como uma entrada modular para o módulo 9430 de Execução e Extração de Segmento de Dados (EDSE) AEL 8058. O EDSE 9430 é um módulo de contêiner para chamada Coleção de Execução (ESC) 6700 na Etapa
Petição 870200056145, de 06/05/2020, pág. 505/1737
503/754
9432 e para chamada do DSS 6800 na Etapa 9434. O módulo 9404 de Interpretação e Detecção do Sistema de Destino (TSID) 9404 interpreta o sistema de destino 9406 considerando a coleção estática da Biblioteca do Sistema de Destino 9442. A coleção 9442 define conjuntos de Instruções 9444 apropriadas aplicáveis a vários tipos de sistemas 9406. Portanto, o TSID 9404 produz o conjunto de instruções 9444 do sistema de destino, que permite que o AEL 8058 funcione internamente para enviar as instruções de cálculo corretas ao sistema de destino 9406. A tradução por segmento de execução (EST) 9436 é chamada a partir da etapa 9432 para interpretar o conjunto de instruções do sistema de destino 9 444, que, portanto, converte a sintaxe do Appchain 836 nas instruções herdadas apropriadas. A tradução por segmento de dados (DST) 9438 é chamada a partir da etapa 9434 para interpretar o conjunto de instruções do sistema de destino 9444, o que traduz a sintaxe da Appchain 836 nos segmentos de dados herdados apropriados. As saídas modulares do EST 9436 e do DST 9438 são submetidas à Unificação de Instruções do Legado (LIU) 9440, que chama uma instância ao vivo do Renderização do Fluxo de Execução (ESR) 6400 para Renderizar a Retenção Estática da Appchain 9402 de acordo com o conjunto de instruções do sistema alvo 9444 definido. Qualquer tentativa de manipular itens fora da jurisdição AEL 8058 e dentro do sistema de destino 9408 (como gravar um arquivo no sistema de arquivos herdado do sistema de destino 9406) é tratada pelo Middleware de Instrução Externa (EIM) 9450. Portanto, Assim, a saída modular do LIU 9440 é um fluxo implementável de instruções 9446 que é entendido e executado pelo sistema de destino 9406 e envolve a manifestação
Petição 870200056145, de 06/05/2020, pág. 506/1737
504/754 prática da execução da cadeia de retenção de aplicativos estáticos 9402, que envolve a execução a cadeia de instruções de destino do Appchain 836 em um sistema legado.
[954] A Fig. 864 mostra a operação e a funcionalidade do Middleware de Instrução Externa 9450. A operação da Retenção da Appchain 9402 da Cadeia de Retenção Estática na instância do Renderização do Fluxo de Execução (ESR) 6400 do módulo 9440 da Unificação de Instruções do Legado (LIU) faz com que o LIU 9440 produza a Proposta de instrução externa 9452 e o índice de prontidão para isolamento da instrução 9454 como uma saída modular. Tais saídas 9452 e 9454 são apresentadas como uma entrada modular para o EIM 9450, portanto a saída 9452 é recebida na etapa 9456. O estágio 9458 chama o LIZARD 120 para converter a Proposta de Instrução Externa 9452 em um Mapa de Hierarquia de Propósito 9462 a seguir, sendo executada a Etapa 9466, que invoca o módulo de processamento de realinhamento de finalidade (PRP) 7050 para a coleção de finalidade de instrução de entradas modulares 9460 e o mapa de hierarquia de finalidade de 9462. A afinidade de mestre/escravo 1480 define a coleção de finalidade de instrução 94 60 como escravo. Portanto, o PRP 7050 produz a nova iteração da Recolha de Propósitos de Instrução 9464 como uma saída modular. Na Etapa 9468, a LIU é chamada para produzir a Preparação para Isolamento da Instrução 9454 através do submódulo LIZARD 120 e a Necessidade de Correspondência de Mapa (NMM) C114. A aplicabilidade da Preparação para Isolamento da Instrução 9454 é ilustrada na Fig. 1230.
[955] A Fig. 865 mostra detalhes de como o LIZARD 120 trabalha para converter a Proposta de Instrução Externa 9452 em
Petição 870200056145, de 06/05/2020, pág. 507/1737
505/754 um Mapa de Hierarquia de Propósitos 9462. A Proposta de Instrução Externa 9452 é submetida ao Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código; recebe o formato de finalidade complexo C325 do módulo de finalidade (PM) C36. O formato de finalidade complexa do C325 é escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de cálculo que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real, com base na sintaxe de computação de destino desejada (linguagem de computador) . Para a leitura do código, o SM C35 fornece uma interpretação sintática do código do computador, para que o PM C36 obtenha um objetivo para a funcionalidade do código. A proposta de instrução externa 9452 é recebida no formato de sintaxe de instrução/comando ESR 5630 via Tradução de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de converter linguagens de cálculo conhecidas em tipos de sintaxe arbitrários. A saida da execução completa da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, uma vez concluída a execução da Redução
Petição 870200056145, de 06/05/2020, pág. 508/1737
506/754
Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para obter uma finalidade no formato de finalidade complexa C325 a partir do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada no SM C35. O PM C3 6 também é capaz de detectar fragmentos de código imersos em dados (binários/ASCII, etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325) referente às Associações de Propósito C326. O Núcleo Interno (IC) C333 é a área do LIZARD 120 que não é submetida a manutenção/autoprogramação automatizada e é programada direta e exclusivamente por especialistas na área relevante. 0 elemento de código principal C335 do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[956] A Fig. 866 continua o fluxo lógico da Fig. 865 para ilustrar a operação do LIZARD 120 para converter a proposta
Petição 870200056145, de 06/05/2020, pág. 509/1737
507/754 de instrução externa 9452 em um mapa de hierarquia de finalidades 9462. A redução lógica C323 do módulo de sintaxe (SM) C35 envia sua saida à Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada referente às Associações de Propósito C326. A saida de definição de finalidade existe no formato de finalidade complexo C325, que é apresentado como uma saida modular para PM C36 e, portanto, para o C329 Núcleo Externo (OC) e, portanto, para o LIZARD 120. A saida é rotulada como um Mapa de Hierarquia de Finalidade 9462 que é apresentado na versão C325 do Formulário de Finalidade Complexa da Proposta de Instrução Externa 9452. A mesma definição e aplicação do núcleo interno (IC) C333 se aplica às funções e módulos mencionados acima.
[957] A Fig. 867 continua o fluxo lógico do Middleware de Instrução Externa (EIM) 9450 da Fig. 864 na Etapa 9468, que invoca a Unificação de Instruções Herdadas (LIU) 9440 para produzir a variável de prontidão para isolamento da instrução 9454. A variável de prontidão 9454 define se a Coleção de finalidades de instrução 9460 é isolada o suficiente no sistema de destino 9406 para executar sem interferência da sintaxe de execução alternativa. Portanto, o sinalizador 9470 está ativado, que avalia se a variável 9454 de prontidão para isolamento de instruções indica que o sinalizador 9470 de coleta de instruções de instruções pode ser exibido no sistema de destino 9406. Se a resposta ao aviso 9470 para Implantação não Pronta 9474, a etapa 9478, que suspende a execução do EIM 9450 até que a próxima proposta de instrução externa 9464 seja produzida pela
Petição 870200056145, de 06/05/2020, pág. 510/1737
508/754
Renderização de Fluxo Executada (ESR) 6400 por meio da Unificação de Instruções Legadas (LIU) 9440. Se a resposta ao Aviso 9470 para a Implantação 9472, então o estágio 9476 chama o LIZARD 120 para converter a Coleção de Finalidade da Instrução 9464 na sintaxe correspondente definida pela Interpretação e Detecção do Sistema de Destino (TSID) 9404. Portanto, o estágio 9476 produz um fluxo de instruções de implantação 944 6, que é uma saída modular para EIM 9450 e é executado nativamente no sistema de destino 9406.
[958] A Fig. 868 mostra a operação e a funcionalidade da Necessidade de Correspondência de Mapa C114 (NMM) que funciona como um submódulo do Shell Dinâmico do LIZARD 120 C198. A instância do NMM C114 é gerada para atender à operação da Etapa 9468 do módulo da Unificação de Instruções Legadas (LIU) 9440. A Interpretação e Detecção do Sistema de Destino (TSID) 9404 é apresentada para armazenamento na Necessidade de Acesso e Desenvolvimento e Armazenamento 5550. Por portanto, o TSID 9404 é dividido em subcategorias e Preservado no Armazenamento 5550 como uma série de ramificações e camadas hierárquicas. Após a chamada modular do NMM C114, a varredura inicial C148 baixa cada ramo de jurisdição do Armazenamento 5550 para retê-lo temporariamente para referência na instância atual do NMM C114. Com Calcular requisitos da filial C149: de acordo com as definições associadas a cada filial, as necessidades são associadas ao seu departamento correspondente. Dessa maneira, as verificações de permissão podem ser formadas na instância do NMM C114. Por exemplo: O NMM C114 aprovou a solicitação de que o departamento de RH baixe todos os funcionários retomados conforme
Petição 870200056145, de 06/05/2020, pág. 511/1737
509/754 solicitado na área anual de análise de desempenho para funcionários com base em suas habilidades. Portanto, foi demonstrado que era uma necessidade válida da jurisdição do departamento. Portanto, o índice de Necessidades C145 é o principal armazenamento para as Agências de Jurisdição e suas respectivas necessidades. Como essa referência interna é um gargalo de recursos para a operação do NMM C114 e, portanto, de todos os módulos que atende, ela é pré-otimizada para consulta rápida ao banco de dados, a fim de aumentar a eficiência geral do sistema. A etapa 9468 fornece a finalidade de entrada C139 como uma entrada modular para o algoritmo de pesquisa NMM C114 C144. O algoritmo de pesquisa C144 faz referência e pesquisa o índice de Necessidades C145 compilado, determinando se o Objetivo de Entrada C139 define uma necessidade válida de acordo com os ramos de jurisdição inicialmente definidos em Desenvolvimento e Armazenamento de Acesso a Necessidades 5550. Por Portanto, a execução completa do algoritmo de pesquisa C144 através do índice de necessidade C145 produz uma resposta Aprovar/Bloquear C146 que é apresentada como a saída modular do C114 NMM e referenciada como resultado da necessidade C141. Portanto, o resultado do requisito C141 é retornado à lógica interna 9450 do Middleware de Instrução Externa (EIM) como a variável 9454 da Prontidão de isolamento da instrução.
[959] A Fig. 869 mostra detalhes de como o LIZARD 120 funciona para converter a coleção de instruções de finalidade específica 9462 em um fluxo de instruções pull-down 9446. A coleção de finalidade de instrução 9462 existe no formato de
Petição 870200056145, de 06/05/2020, pág. 512/1737
510/754 finalidade complexa C325 e sofre expansão Iterativa C327 do Módulo de Propósito C36 no Núcleo Externo (OC) C329 do LIZARD 120. A Expansão Iterativa C327 adiciona detalhes e complexidade para evoluir uma meta simples (definida indiretamente na Coleção de Propósitos Instrucionais 9462) em direção a uma definição de finalidade complexa específico. Portanto, o potencial máximo da entrada de associação de finalidade C326 é realizado e mantido como um formato de finalidade complexo C325, antes de ser enviado para a derivação lógica C320 do módulo de sintaxe (SM) C35. O elemento de Código Principal do Núcleo Interno (IC) C335 C333 contém estruturas e bibliotecas principais, scripts de balanceamento de carga e gerenciamento de encadeamento, protocolos de criptografia e comunicação e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[960] A Fig. 870 continua o fluxo lógico da Fig. 869 para ilustrar a operação do LIZARD 120 para converter a coleção de finalidade de instrução 9462 em um fluxo de instruções implantável 9446. Os dados de entrada são recebidos no formato de finalidade complexa C325 a partir do módulo de propósito (PM) C36 e transferido para o lead Lógico C320 do módulo de sintaxe (SM) C35. A derivação lógica C320 deriva funções logicamente necessárias de funções inicialmente mais simples. Isso significa
Petição 870200056145, de 06/05/2020, pág. 513/1737
511/754 que, se uma função puder ser formada como uma função derivada devido à implicação de uma função mãe mais simples, ela será formada pela Derivação Lógica C320. A saida produzida é uma árvore de dependências de funções que são construídas de acordo com os dados definidos no formato de propósito complexo C325. A Derivação Lógica C320 opera de acordo com as definições das Regras e Sintaxe C322 que são herdadas do elemento do Código Central C335 do Núcleo Interno (IC) C333 e da Coleção da Biblioteca do Sistema de Destino 9442 por Detecção de Interpretação Sistema de destino (TSID). 0 Bypass Lógico C320 envia sua saída para a Conversão de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de converter linguagens de cálculo conhecidas em tipos de sintaxe arbitrários. Portanto, o PM C36 chama o SM C35 para produzir a versão resultante da entrada da Finalidade de Colecção da Instrução 9462 usando a Tradução de Código C321. A sintaxe dessa versão é definida como saída modular 9404 da Interpretação e Detecção do Sistema de Destino (TSID). O fluxo de instruções suspensa resultante 9446 que é produzido terminalmente pela Tradução de Código C321 é a saída modular SM C35, Núcleo Externo (OC). C329 e LIZARD 120.
[961] A Fig. 871 mostra a operação e a funcionalidade do Processamento Estático da Appchain (SAP) 9480, que converte 836 Appchains ativas em uma Retenção Estática de Appchain 9402 implementável. A execução do SAP 9480 geralmente é chamada manualmente, por um Usuário da UBEC 106 ou Genérico 5068 e por
Petição 870200056145, de 06/05/2020, pág. 514/1737
512/754 meio de uma interface administrativa 9482. Na etapa 9482, uma proposta para coleção da Appchain 9488 é produzida a partir da interface administrativa 9482, portanto o escopo das 836 Appchain é definido que o Usuário da UBEC 106/Usuário Genérico 5068 deseja incluir na saída modular final da Retenção Estática da Appchain 9402. Na Etapa 9484, as Coleções de Segmentos de Execução e Dados 6902/6904 são produzidos a partir das referências da Proposta de coleção da Appchain 9484. Na Etapa 9486, a Proposta de coleção da Appchain 9488 é processada por uma instância gerada da Renderização de Fluxo de Execução (ESR) 6400 a partir do Ambiente de captura modificado (MCE) 6174. MCE 6174 é um ambiente de tempo de execução personalizado que instala pontos de acionamento para vários eventos, para que informações sobre dependência e depuração possam ser derivadas da sessão de tempo de execução em diante. Em seguida, o módulo 6176 do cumprimento da solicitação de dependência (DRF) é chamado na instância do SAP 9480 junto com a instância do MCE 6174. Na etapa 9490, a instância do ESR 6400 executa uma solicitação de execução ou de dados. O Aviso 9492 avalia as Coleções de Segmentos de Execução 6902 e Data 6904 para determinar se a solicitação ou execução de dados do ESR 6400 existe nessas coleções 6902/6904. Se a resposta ao Aviso 9492 for Não existe 9494, o Aviso 9498 é chamado para avaliar se a execução ou segmento de dados correspondente (do ESR 6400) é justificado no submódulo LIZARD 120 de Necessidade de Correspondência no Mapa (NMM) . A resposta no 9496 da pergunta 9492 é avaliada na Fig. 875.
[962]Os detalhes operacionais da Etapa 9498 do módulo Processamento Estático da Appchain (SAP) 9480 estão detalhados
Petição 870200056145, de 06/05/2020, pág. 515/1737
513/754 na Fig. 872. A proposta para a coleção Appchain 9488 é enviada como uma entrada modular para a etapa 9500, que separa a coleção 9500 em referências separadas da Appchain 836 que são posteriormente armazenadas no Retenção de Cache de Referência da Appchain (ARCR) 9502. A etapa 9504 gera um loop que circula por todas as instâncias da Appchain 836 no ARCR 9502. A etapa 9508 recupera a instância da Appchain 9506 selecionada de um nó do cache 786 relevante da Rede BCHAIN 110 e através do Protocolo BCHAIN 794. Portanto, a Etapa 9508 (detalhada na Fig. 1236) produz a Instância da cadeia de aplicativos 9510, que é processada na Etapa 9512 usando invocações da Coleta de Fluxo de Execução. (ESC) 6700 e Classificação do Fluxo de Dados (DSS) 6800. O ESC 6700 produz um fluxo de execução 9514 que é enviado como uma entrada modular para a etapa 9518 e o DSS 6800 produz um fluxo de dados 9516, que também é enviado como uma entrada modular para a etapa 9518. Portanto, a Etapa 9518 coleta os diferentes Fluxos de Execução 9514 e Dados 9516 no Segmento de Execução 6902 e no Segmento de Dados 6904. O estágio é subsequentemente processado. 9519, que avança o loop iniciado pela etapa 9504 para a próxima instância disponível da Appchain 9506.
[963] A Fig. 873 delineia os detalhes operacionais da Etapa 9508 do módulo Processamento Estático da Appchain (SAP) 9480. A Etapa 9508 chama a função do Protocolo BCHAIN 794 no Gerador de Reivindicação de Conteúdo (CCG) 3050. Portanto, uma Solicitação de Reivindicação de Conteúdo (CCR) 2308 ocorre com uma proposta de caminho de lúpulo de linha de base (PBHP) 2322. O CCR 2308 é enviado à rede BCHAIN 110 para finalmente alcançar
Petição 870200056145, de 06/05/2020, pág. 516/1737
514/754 um nó de cache 3260 contendo partes da instância solicitada da Appchain 9506. O Nó de Cache 6526 está em conformidade com a CCR 2322, sendo compensado financeiramente pelo Protocolo BCHAIN 794 e aproveitando a Economia de Potência do Metachain 834. O Nó de Cache 6526 produz uma unidade correspondente de conformidade com reivindicações de conteúdo (CCF) 2318 em resposta à CCR 2308 correspondente. O recém-produzido CCF 2318 viaja ao longo da Rede BCHAIN 110 para alcançar o módulo 3300 da Renderização de Reivindicação de Conteúdo (CCR) do Nó 786 que está sendo processado pela instância 9480 do SAP. As instruções de decodificação do conteúdo 3316 são referenciadas para gerar a resposta do CCF. 2318, que, portanto, produz a instância Realizada da Appchain 9510. Portanto, os Segmentos de Execução 551 e Data 553 da Appchain 836 selecionado foram recuperados.
[964] A Fig. 874 explica o fluxo lógico do submódulo 6176 da Atendimento de Solicitação de Dependência (DRF) na instância 9480 do Processamento Estático da Cadeia de Apelação (SAP) e, portanto, é retomado na Fig. 871. A resposta Existe 9494 para o Aviso 9492 invoca a Etapa 9498 que verifica se a Execução ou o Segmento de Dados correspondente é Justificado 9520 de acordo com o NMM C114. Se a resposta 9520 justificada ocorrer ao Aviso 9498, é chamada a Etapa 9524 que marca o segmento de Execução ou Dados para inclusão na Retenção de Cache do Segmento Marcado (MSCR) 8652. O fluxo lógico da resposta Não Justificado 9522 na consulta 9498 é mostrado na Fig. 875. A conclusão da Etapa 9524 implica a conclusão da instância de processamento DARE 6176. Portanto, após a Etapa 9524, a Etapa 9526 é chamada, associando a Instância Completa da Appchain 9510 a seus segmentos
Petição 870200056145, de 06/05/2020, pág. 517/1737
515/754 marcados correspondentes encontrados no MSCR 8652. A etapa 9508 recupera a Instância da Appchain selecionada 9506 de um Nó de cache relevante 786 através do Protocolo BCHAIN 794, produzindo assim a Instância Appchain 9510 atendida, conforme ilustrado na Fig. 873.
[965] A Fig. 875 explica o fluxo lógico do submódulo 6176 da Conformidade com Solicitação de Dependência (DRF) na instância 9480 do Processamento Estático da APPCHAIN (SAP) em relação à Etapa 9486 do Ambiente de captura modificado (MCE) 6174. A resposta Não Existe 9496 ao Aviso 9492 e a resposta injustificada 9522 ao Aviso 9498 levam à ativação da Etapa 5600, que gera e envia uma Unidade de Registro de Diagnóstico (DLU) 1182 que contém um Token Oficial do Sistema 1184. Este Token 1184 está incluído para indicar que a função ou programa correspondente atingiu um estado não ideal se for uma função oficial na Plataforma UBEC 100. O DLU 1182 é enviado ao módulo Envio de Registro de Diagnóstico (DLS) 1160, que é chamado por o Mecanismo de Pesquisa Automatizado (ARM) 134 da LOM 132 para fornecer DLU 1182 ao SPSI 130. Portanto, o SPSI 130 é capaz de processar as informações de diagnóstico encontradas no DLU 1160 com o Módulo de Registro de Diagnóstico. O Análise de Unidade (DLUA) 8048 leva à Etapa 13005, representando o DLUA 8048, sendo chamada para fazer as modificações correspondentes no I2GE 122 e/ou no MCE 6174 para evitar o motivo inicial pelo qual as respostas especificadas para os Avisos foram chamadas. 9492 e 9498. A resposta 9520 justificada ao Aviso 9498 chama o TBM (62) para a instância da Renderização de Fluxo de Execução (ESR) 6400 que está sendo emulada no I2GE 122. Portanto, o TBM 6240 permite
Petição 870200056145, de 06/05/2020, pág. 518/1737
516/754 o processo de variação evolutiva I2GE 122 continua enquanto o encadeamento original DRF 6176 é processado, o que é feito para obter eficiência operacional.
[966] A Fig. 876 mostra a operação e a funcionalidade do Necessidade de Correspondência de Mapa (NMM) C114 que funciona como um submódulo do LIZARD 120 do Shell Dinâmico C198. A instância NMM C114 é gerada para atender à operação da Etapa 9528 do módulo 6176 do Pedido de Entrega de Dados (DRF) do módulo de Processamento Estático da Appchain (SAP) 9480. O segmento de execução de coleção 6902 e o segmento de dados de coleção 6904 se apresentam para armazenamento na Necessidade de Acesso e Desenvolvimento e Armazenamento 5550. Assim, as coleções 6902/6904 são divididas em subcategorias e são preservadas no Armazenamento 5550 como uma série de ramificações e camadas hierárquicas. Após a chamada modular do NMM C114, a varredura inicial C148 baixa cada ramo de jurisdição do Armazenamento 5550 para retê-lo temporariamente para referência na instância atual do NMM C114. Com Calcular requisitos da filial C149, de acordo com as definições associadas a cada filial, as necessidades são associadas ao seu departamento correspondente. Dessa maneira, as verificações de permissão podem ser formadas na instância do NMM C114. Por exemplo: O NMM C114 aprovou a solicitação de que o departamento de RH baixe todos os funcionários retomados conforme solicitado na área anual de análise de desempenho para funcionários com base em suas habilidades. Portanto, foi demonstrado que era uma necessidade válida da jurisdição do departamento. Portanto, o índice de Necessidades C145 é o principal armazenamento para as Agências de Jurisdição e suas
Petição 870200056145, de 06/05/2020, pág. 519/1737
517/754 respectivas necessidades. Como essa referência interna é um gargalo de recursos para a operação do NMM C114 e, portanto, de todos os módulos que atende, é pré-otimizada para consulta rápida ao banco de dados, a fim de aumentar a eficiência geral do sistema. A etapa 9530 fornece a finalidade de entrada C139 como entrada modular ao algoritmo de pesquisa NMM C114 C144. O algoritmo de pesquisa C144 faz referência e pesquisa o índice de Necessidades C145 compilado, determinando se o Objetivo de Entrada C139 define uma necessidade válida de acordo com os ramos de jurisdição inicialmente definidos em Desenvolvimento e Armazenamento de Acesso a Necessidades 5550. Por Portanto, a execução completa do algoritmo de pesquisa C144 através do índice de necessidade C145 produz uma resposta Aprovar/ Bloquear C146 que é apresentada como a saída modular do C114 NMM e referenciada como resultado da necessidade C141. Portanto, o resultado do requisito C141 é retornado à Etapa 9498 da DRF 6176 e SAP 9480.
[967] A Fig. 877 mostra detalhes de como o LIZARD 120 funciona para converter a instância da Renderização de Fluxo de Execução (ESR) 6400 da instância 9517 e 9534 do Ambiente de Captura Modificado (MCE) 6174 em um Mapa de Hierarquia de Finalidade 9536. A Instrução externa 9452 é enviada ao Módulo de sintaxe (SM) C35 que pertence à jurisdição do Núcleo Externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever código; recebe o formato de finalidade complexo C325 do módulo de finalidade (PM) C36. O formato de finalidade complexa do C325 é escrito em sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém implementações básicas de operações de
Petição 870200056145, de 06/05/2020, pág. 520/1737
518/754 cálculo que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Em seguida, uma função auxiliar converte o pseudocódigo em código executável real, com base na sintaxe de computação de destino desejada (linguagem de computador) . Para a leitura do código, o SM C35 fornece uma interpretação sintática do código do computador, para que o PM C36 obtenha um objetivo para a funcionalidade do código. A proposta de instrução externa 9452 é recebida no formato de sintaxe de instrução/comando ESR 5630 via Tradução de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) reconhecido e entendido pelo SM C35 em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de converter linguagens de cálculo conhecidas em tipos de sintaxe arbitrários. A saída da execução completa da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, uma vez concluída a execução da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para obter uma finalidade no formato de finalidade complexa C325 a partir do código do computador. Essa definição de finalidade descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada no SM C35. O PM C3 6 também é capaz de detectar fragmentos de código imersos em dados (binários/ASCII, etc.). A Interpretação
Petição 870200056145, de 06/05/2020, pág. 521/1737
519/754
Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325) referente às Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não é submetida a manutenção/autoprogramação automatizada e é programada direta e exclusivamente por especialistas na área relevante. 0 elemento de código principal C335 do IC C333 contém estruturas e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o código principal C335 permite a funcionalidade geral e a funcionalidade do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a política de segurança e os objetivos da empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[968] A Fig. 878 continua o fluxo lógico da Fig. 877 para ilustrar a operação do LIZARD 120 para converter solicitações de Execução 9532 e Dados 9534 em um Mapa de Hierarquia de Propósito 9536. A Redução Lógica C323 do Módulo Sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de propósito interpretada, consultando as Associações de Propósito C326. A saída de definição de finalidade existe no formato de finalidade complexo C325, que é apresentado como uma saída modular para PM C36 e, portanto, para o C329 Núcleo Externo
Petição 870200056145, de 06/05/2020, pág. 522/1737
520/754 (OC) e, portanto, para o LIZARD 120. A saida é Rotule como um Mapa de Hierarquia de Propósito 9536 que é apresentado como Formulário de Propósito Complexo C325 de Solicitações de Execução 9532 e Dados 9534. A mesma definição e aplicação do núcleo interno (IC) C333 se aplica às funções e módulos mencionados acima.
[969] A Fig. 879 mostra um resumo final dos aspectos macro do Processamento Estático das Appchain (SAP) 9480. O SAP 9480 é chamado manualmente por um Usuário da UBEC 106 ou um usuário genérico 5068 através de uma interface administrativa 9482. A Etapa 9482 recebe uma proposta da Coleção da Appchain 9488 como uma entrada modular. Um loop é iniciado na Etapa 9504 que atravessa todas as Instâncias da Appchain 9506 da Retenção de Cache de Referência da Appchain (ARCR) 9502. Na Etapa 9538, a Instância da Appchain concluída 9510 da Retenção de cache de retenção marcada (MSCR) 8652 é recuperada, leva ao Estágio 9540. As Instâncias Appchain cumpridas 9510 contêm o conjunto completo de Segmentos de Execução 551 e Data 553 necessários para executar a Appchain 836 escolhida, incluindo quaisquer dependências modulares, como a Appchain 836 completa para LOM 132, CTMP 124 e LIZARD 120. A etapa 9540 instala gradualmente todas as instâncias da cadeia de aplicativos concluída na cadeia de aplicativos estática 9402, para que cada segmento da execução de saída 551 ou dos Dados 553 seja verificado pelo MSCR 8652 para verificar se possui o status marcado. Portanto, a Retenção Estática da Appchain 9402 é produzida como a saída modular final do SAP 9480 e, posteriormente, é enviada como entrada modular para o módulo de Execução e Extração de Dados (EDSE) 9430 da Camada de Emulação da Appchain (AEL) 8058.
Petição 870200056145, de 06/05/2020, pág. 523/1737
521/754
[97Ο] Conteúdo metafísico Neuroeconómico (NMC)
[971] [00] As Figs. 1000 - 10018 mostram uma Estrutura de doações (ES) 12008 que gerencia fundos que são operados por um Conselho de Administração (BD) 12018 ou por um Diretor independente (ID) 12020.
[972] A Fig. 1000 mostra o Conselho de Administração (BD) 12018 como uma coleção de Diretores Registrados 12006 que operam na Plataforma UBEC 100 como Usuários UBEC 106. Os fundos pessoais de um Diretor 12006 são armazenados na Economia de Watt da Metachain 834 862 no Estágio 12014, os Diretores 12006 podem comprometer criptograficamente seus fundos com a instância 12012 do Capital de investimento (ES) 12012 do ES 12008 através do Procedimento de penhor de unidade de watt (WUP2) 12016. As Funções criptográficas que operam dentro do WUP2 12016 são ativadas por um núcleo de criptografia 786. Portanto, uma alocação virtual de fundos comprometidos é registrada no IC 12012, enquanto a alocação de criptografia baseada em hardware desses fundos ocorre no UPFA 718 dentro dos nós. BCHAIN 786.
Dentro da estrutura do BD 12018, a Retenção de Rastreamento de Estaca (STR) 12000 mantém um registro digital de todos os investimentos atuais e passados, indicando a participação atual no portfolio do BD 12018. O registro digital STR 12000 pode ser tornado público aos usuários do UBEC 106 que não são conselheiros ou podem ser tornados exclusivamente privados para os conselheiros 12006 do Conselho 12018. Essa distinção em relação ao acesso à informação é definida na Política de Retenção Estabelecida (EPR) 12002, que registra as variáveis que definem as características do Investimento da diretoria 12018. Retenção
Petição 870200056145, de 06/05/2020, pág. 524/1737
522/754 de acompanhamento de propostas (PTR) 12004 acompanha as propostas feitas pelos Diretores 12006. As propostas rastreadas em PTR 12004 são frequentemente referências a definições de políticas no EPR 12002. Tais propostas são votadas por Diretores 12006 através do Mecanismo de Votação do Diretor (DUM) 12030.
[973] A Fig. 1001 mostra o Diretor Independente (ID) 12020 operando dentro da Estrutura de Dotações (ES) 12008. O escopo da funcionalidade do ID 12020 é o mesmo do BD 12018, exceto que existe um único Diretor 12022 exclusivo. Manipula políticas no EPR 12002 e envia e vota propostas no PTR 12004 por meio do Mecanismo de Votação do Diretor (DVM) 12030.
[974] [00] Figs. 1002 - 1008 mostra a Troca Econômica Criptográfica (CDEE) 705 e detalhes sobre seu módulo de dependência LUIGI 116.
[975] A Fig. 1002 mostra a funcionalidade de monitoramento de segurança do CDEE 705. O módulo principal do NMC é a Avaliação abrangente do estado (CSE) 12400. A operação do CSE 12400 aciona o estágio 12024 do CDEE 705. O estágio 12024 inclui monitoramento e o regulamento, realizado através da Supervisão do Movimento de Fundos (FMO) 392, dos fundos que são transferidos para uma instância de Alocação de fundos de aplicativos públicos (APFA) 720. A instância APFA 720 pertence ao aplicativo UBEC designado que foi selecionado para investimento pelo ES 12008 relevante. O acesso criptográfico aos fundos mantidos no APFA 720 é mantido por meio dos nós BCHAIN 786. Esses nós 786 pertencem aos mantenedores do aplicativo UBEC relevante. O BD 12018 e o ID 12020 da ES 12008 têm acesso ao Mecanismo de recuperação de fundos (FRM) 398 da LUIGI 116. O
Petição 870200056145, de 06/05/2020, pág. 525/1737
523/754 saldo final da instância APFA 720 e as informações de ganhos da Distribuição de benefícios de aplicativos (APD) 726, são enviadas ao Relatório de Status do Digital Exchange (DESR) 12418. Essas informações são processadas pela DESR 12418 e enviadas ao CSE 12400. Portanto, o CSE 12400 tem acesso a mais informações financeiras, o que leva o CSE 12400 a calcular de forma inteligente a tomar decisões de investimento ideais. Quando um BD 12018 ou ID 12020 faz um investimento em um aplicativo UBEC, Sua identificação é registrada no aplicativo Registro de Investimento do Aplicativo UBEC (AIR) 722. Isso permite a distribuição correta dos ganhos pelo APD 726.
[976] A Fig. 1003 mostra o LUIGI 116 operando como um Appchain 836 na plataforma UBEC 100. O LUIGI 116 é invocado pelos módulos Supervisão de Movimentação de Fundos (FMO) 392 e Mecanismo de Recuperação de Fundos (FRM) 398 dentro do CDEE 705. Tais invocações LUIGI 116 regulam o movimento da Unidade Watt e garantem a segurança da atribuição da Unidade Watt dentro do CDEE 705. A Gateway da UBEC 368 recebe informações de transferência de dados da Appchains 836 operando na plataforma UBEC. 100. Portanto, o tráfego e a atividade no CDEE 705 são inerentemente vinculados ao link da Gateway da UBEC 368. A Delegação de Tarefas (LTD) da LUIGI 370 determina se os dados recebidos do Gateway UBEC 368 devem ser processados. Para LIZARD 120, LOM 132 ou ambos. Uma chamada do LIZARD 120 Appchain 836 indica que o modo de processamento 376 Conformidade Jurisdicional e Leitura de Intenção 37 6 foi selecionado. Uma chamada do LOM 132 da Appchain 836 indica que o modo de processamento 372 Consultas foi selecionado de conhecimento e arbitragem judicial.
Petição 870200056145, de 06/05/2020, pág. 526/1737
524/754
Posteriormente, o fluxo lógico continuará para a Personalização Dinâmica da API (DAC) 384. A função do DAC 384 é interpretar o Tipo de Tarefa 372/376 e, portanto, personalizar a interface da API selecionada com Tipo Tarefa 372/376 selecionada. Os algoritmos correspondentes LOM 132 e LIZARD 120 são executados à medida que são invocados, produzindo resultados analíticos enviados à Unificação de Conclusão Inteligente (UCI) 374. O UCI 374 reconcilia qualquer conclusão interpretativa/subjetiva entre LOM 132 e LIZARD 120, assumindo que os dois módulos sejam chamados em paralelo.
[977] A Fig. 1004 continua mostrando a operação e a aplicação do LUIGI 116 em relação ao NMC 13300 e, mais especificamente, ao módulo de avaliação abrangente do estado (CSE) 12400. Conforme indicado na Etapa 12026, o Ajuste ideal de decisão de investimento 12404 da CSE 12400 é recebido através do Gateway UBEC 368. LUIGI 116 percebe que o Ajuste 12404 atua como Contêiner 12590 de vários subelementos de Investimento das Alocações 12592, Retiradas de Investimento 12594, Benefícios de Restauração 12596 e Diretor de Notificação 12598. Posteriormente, na Etapa 12028, o módulo Delegação de Tarefas de LUIGI (LTD) 370 é chamado para delegar a saída de dados correspondente ao Ajuste 12404 a ser analisada pelos ramos de análise apropriados do LUIGI 116: Consultas de Conhecimento e Arbitragem Judicial 372 (LOM 132) e Leitura Jurisdicional de Conformidade e Intenção 376 (LIZARD 120).
[978]A Fig. 1005 mostra várias 836 Appchains que
interagem com o LUIGI 116 (como Appchain ) para ativar sua
funcionalidade. A plataforma UBEC 100 se manifesta como um
Petição 870200056145, de 06/05/2020, pág. 527/1737
525/754
Appchain 836 com o UBEC Appchain 118, que se liga ao UBEC 368 Gateway para fornecer entrada de dados modular ao LUIGI 116. Após a conclusão do processamento LUIGI 116, o retorno abrangente do UBEC 388 envia os dados de volta ao UBEC Appchain 118 para que eles possam continuar ao longo de seu fluxo lógico original. 0 LOM 132 atua como a Appchain 836 central para permitir o processamento na filial de Arbitragem do Conhecimento e Arbitragem Judicial 372. 0 LOM 132 e o LIZARD 120 também fornecem informações de personalização da API para a Personalização Dinâmica da API (DAC) 384. Portanto, O DAC 384 tem acesso às informações apropriadas da API para executar as personalizações relevantes do processo lógico conforme necessário (dependendo de qual Appchain 132/120 for chamada). O SPSI 130 monitora periódica e consistentemente, mantém e atualiza a composição e operação do LUIGI 116.
[979] A Fig. 1006 descreve os detalhes operacionais relacionados ao módulo 384 de Personalização de API Dinâmica (DAC) em relação à sua interface com a Filial 376 das Leis de Intenção e Conformidade Jurisdicional. Como a Filial 376 selecionada chama o LIZARD 120, a API de uso do LIZARD 402 é fornecida na operação DAC 384. A Delegação de Tarefas LUIGI (LTD) 370 determina o Tipo de Tarefa definido no Recebimento de Tarefas 410. Portanto, o Tipo de tarefa é encaminhado para a Etapa 408 Interpretação do tipo de tarefa no DAC 384. Portanto, o Tipo de tarefa fornecido indica o escopo de personalização do Estágio 406 no DAC 384. Isso produz o conjunto de instruções modular 416 que é fornecido para a ramificação 376 selecionada. O conjunto de instruções modular 416 é programado de acordo com a API LIZARD
Petição 870200056145, de 06/05/2020, pág. 528/1737
526/754
402 para uso e, portanto, é enviado como uma entrada modular para a entrada 414 da LIZARD. Portanto, a Entrada 414 recebe os dados relacionados à tarefa com o Conjunto de Dados da Tarefa 412 e instruções para processá-lo com o Conjunto de Instruções Modular 416. Isso leva à Execução Modular real 418 do LIZARD 120 para atender ao duas entradas 412/416. A execução bem-sucedida e completa 418 da instância LIZARD 120 produz a saida LIZARD 420. A saida 420 é encaminhada para o módulo 374 de Unificação de Conclusão Inteligente (ICU). O UCI 374 reconcilia várias saídas de diferentes execuções do módulo 418/423 (LOM 132/LIZARD 120) para garantir uma saída unificada singular das filiais 372/376. Isso permite a recepção de entrada simplificada da Ação Corretiva (LCA) LUIGI 378.
[980] A Fig. 1007 descreve os detalhes operacionais relacionados ao módulo DAC 384 em relação à sua interface com o Ramo de Arbitragem do Conhecimento e o Arbitragem Judicial 372. Como o Ramo 372 selecionado invoca o LOM 132, a API de uso do LOM 402 é fornecida dentro da operação do DAC 384. O LTD 370 determina o tipo de tarefa definida em Recebendo tarefas 410, operando assim a mesma lógica que a Fig. 1006 para a Filial 376. O Tipo de Tarefa é encaminhado para a Etapa 408 Interpretar tipo de tarefa no DAC 384. Isso produz o conjunto de instruções modular 416 fornecido à ramificação 372 selecionada. O Conjunto de Instruções Modular 416 é programado de acordo com a LOM API 404 e, portanto, é enviado como uma entrada modular para a Entrada LOM 422. Portanto, a Entrada 422 recebe os dados relacionados à tarefa com o Conjunto de Dados da Tarefa 412 e instruções para processá-lo com o Conjunto de Instruções Modular 416. Isso leva
Petição 870200056145, de 06/05/2020, pág. 529/1737
527/754 à Execução Modular real 423 do LOM 132 para atender aos requisitos duas entradas 412/416. A execução 423 da LOM, com êxito e completa, produz a Saída 424 da LOM. A saída 424 é encaminhada para a UCI 374, que reconcilia várias saídas dos diferentes Módulos de Execução 418/423 (LOM 132/LIZARD 120) para garantir uma saída unificada singular das Filiais 372/376. Isso permite a recepção de entrada simplificada do LCA 378. A recepção de entrada simplificada é necessária se o LTD 370 chamar as Execuções Modulares 418 e 423.
[981] A Fig. 1008 mostra as funções de manipulação de liquidez monetária pertencentes exclusivamente ao LUIGI 116 na Manipulação de liquidez financeira 382. O Enclave Seguro da LUIGI (LSE) 380 é uma zona segura de retenção de informações que somente o LUIGI 116 pode acessar. Portanto, teoricamente não há observadores humanos possíveis para o conteúdo do LSE 380, pois as permissões para escrever o código LUIGI 116 pertencem exclusivamente ao SPSI 130 e as permissões para executar o código LUIGI 116 pertencem exclusivamente ao próprio LUIGI 116. No LSE 380, existe uma Chave de Descriptografia de Retenção 394 que permite ao LUIGI 116 descriptografar a Retenção Criptografada de Chaves Privadas 396. Isso permite que o Mecanismo de Manuseio de Fundos (FMM) 400 manipule fundos na Economia Metachain 834 Watt 862 em uma recuperação de fundos. O Governador de Liquidez da Watt (WLG) 390 é um módulo de subconjunto LUIGI 116 que monitora e potencialmente bloqueia picos excessivos nos movimentos de liquidez dentro e fora da UBEC 100. Isso garante uma economia gradual e previsível dentro da UBEC 100. O Monitoramento de Movimentação de Fundos (FMO) 392 é um subconjunto do LUIGI 116
Petição 870200056145, de 06/05/2020, pág. 530/1737
528/754 que monitora e potencialmente bloqueia movimentos de liquidez correlacionados com fraudes. 0 Mecanismo de Recuperação de Fundos (FRM) 398 é um módulo de subconjunto do LUIGI 116 que permite que proprietários legítimos de fundos -U- (Unidade Watt) os reivindiquem da Metachain 834 da Economia de Watt 862 se forem perdidos, roubados ou mal gerenciado. A Prova de Autoridade 402 é uma chave criptográfica exclusiva que é garantida criptograficamente para ser produzida apenas pelo LUIGI 116 devido à logística LSE 380. Portanto, a Prova de Autoridade 402 é usada para invocar um UBMA 4260 Chip para fornecer sua Chave Privada 4314 exclusiva sensível à segurança, conforme ilustrado nas figs. 362 e 363.
[982] [00] As Figs. 1009-1011 mostram a funcionalidade e o uso do 12030 Diretor do Mecanismo de Voto (DVM).
[983] A Fig. 1009 mostra os Diretores 12006/12022 do Conselho de Administração (BD) 12018 e o Diretor Independente (ID) 12020 interagindo com o DVM 12 030 através da Interface de Proposta de Voto (PVI) 12.010. Na Etapa 12034, um Diretor 12006/12022 envia uma Proposta Autorizada 12036. O Diretor 12006/12022 pode fazer vários tipos de Possíveis Propostas Autorizadas 12036. Com um Diretor Independente (ID) 12020, as propostas 12036 são efetivamente tratadas como comandos na Estrutura de doações (ES) 12008, porque são apenas um único diretor 12022 e não há dilema acordado. A admissão do novo diretor 12038 implica a possível aceitação pelo Conselho 12018 de um novo diretor 12006. Portanto, os atuais diretores 12006 votam se um novo diretor potencial 12006 deve ser aprovado ou não. Esta Proposição 12036 é aplicável apenas ao BD 12018 e não ao ID
Petição 870200056145, de 06/05/2020, pág. 531/1737
529/754
12020. A aplicabilidade da Admissão de Novos Diretores 12038 depende da política definida na Política de Retenção Estabelecida (EPR) 12002. Portanto, o Conselho 12018 pode aceitar novos Diretores 12006 com ou sem verificação de consenso através da Admissão de Novos Diretores 12038, de acordo com as definições de Políticas na EPR 12002. A Retirada do Diretor com Suporte 12044 implica que um Diretor 12006 renuncie à sua participação no Conselho 12018 e imediatamente Retire seu Capital de Investimento (IC) 12012 de Participação em Investimentos. Um Conselho 12018 pode optar por impedir que um Diretor 12006 retire todo o seu investimento imediatamente através da aplicação da Política EPR 12002. Isso garante o compromisso com o projeto de investimento e melhora as relações de confiança entre os Diretores 12006, se escolhido. A adição das regras de política 12042 implica a possível aceitação pela diretoria de 12018 de uma nova política que é preservada e mencionada na EPR 12002. Essas políticas regem o comportamento geral das funções da diretoria 12018 e, portanto, Portanto, as Alocações de Investimento 12592, realizadas pela Avaliação Integral do Estado (CSE) 12400. As referidas políticas podem ser eliminadas através da correspondente Norma Normativa 12048 e Proposição 12036. Portanto, uma ação iniciada pelos Diretores 12006/12022 para modificar uma política preexistente no EPR 12002 resultará na exclusão da regra 12048 da política imediatamente antes do evento de adição da regra 12042. Portanto, os votos dos diretores 12006 através do DVM 12030 modificar uma Política preexistente são votos efetivos para um par de Propostas 12036 Adição da Regra de Política 12042 e Eliminação de Regra de Política 12048, que são
Petição 870200056145, de 06/05/2020, pág. 532/1737
530/754 tratados como uma única unidade. A Adição da Medida de Anulação Manual 12040 introduz uma nova regra personalizada para a OMR (120), que influencia a Composição Ideal da Decisão de Investimento 12404, produzida pela CSE 12400. Tais medidas de anulação 12064 definem recursos personalizados que tornar um BD 12018 ou ID 12020 especifico exclusivo em relação aos seus Ajustes de investimento correspondentes 12404. Qualquer ES 12008 que não possua Medidas de anulação definidas no OMR 12064 geralmente receberá um Ajuste ideal para a Decisão de investimento 12404 da CSE 12400 Se duas Estruturas de Dotação (ES) 12008 foram geradas ao mesmo tempo, ambas com um OMR 12064 idêntico (que não pode incluir Medidas Definidas), em teoria elas receberão exatamente a mesma Composição de Decisão de Investimento 12404 da CSE 12400. Quando o diretor 12006/12022 envia uma proposta autorizada 12034 no estágio 12034, o estágio 12050 é chamado para interpretar o Desempenho da proposta através do procedimento de conformidade da proposta (PCP) 12220, a execução do PCP 12220 até o estágio 12050 ocorre para garantir que a nova proposta autorizada 12034 seja compatível com as propostas anteriores do PTR 12004 e as políticas predefinidas do EPR 12002. Um exemplo de um potencial conflito de conformidade é um Retirado de diretor com o Suporte 12044 com a Proposição 12036 que é enviado por um Diretor 12006, enquanto o EPR 12002 relevante do BD 12018 define que nenhuma Proposta 12044/12036 desse tipo não é obrigatório nem aplicável a um diretor 12006 que retire imediatamente toda sua participação no investimento da instância 12012 do capital de investimento (IC) . Outro exemplo de uma proposição 12036 que não é uma reclamação é uma regra de supressão
Petição 870200056145, de 06/05/2020, pág. 533/1737
531/754 da política 12048 da proposição 12036 que se refere a uma política que não existe na EPR 12002. Um outro exemplo de uma proposta 12036 que não é compatível é a eliminação da medida Manual de Anulação 12046 da Proposição 12036 que se refere a uma Medida de Anulação que não foi encontrada no OMR 12064.
[984] A Fig. 1010 mostra a conclusão lógica do estágio 12050 com um Sim, no cenário de conformidade 12054. Se o PCP 12220 considerar que a Proposta potencial autorizada 12036 está em conformidade com propostas anteriores e políticas préestabelecidas, a Proposição 12036 é enviada à Interface do Votação da proposta (PVI) 12010. Com o PVI 12010, os Diretores 12006 podem votar a favor ou contra uma Proposta potencial autorizada 12036. Se a votação indicar aprovação 12058 para a Proposição 12036, que é uma adição à Medida de substituição manual 12040 ou uma Eliminação da Medida de Substituição Manual 12046, a Proposição 12060 é enviada para Manipulação da Medida de Substituição Manual (M0M2) 12062 até a Etapa 12060. Isso leva à Proposição 12036 em relação a alterações na Medida de Substituição Manual. 12040/12046 se manifesta na retenção da medida de anulação (OMR) 12064.
[985] A Fig. 1011 mostra o fluxo lógico de Sim, no cenário de Conformidade 12054 destacado na Fig. 1010, bem como o Não, Não na Conformidade 12074. Se o Cenário 12074 ocorrer, o Estágio 12078 será realizado, que rejeita a apresentação da proposição 12036 e informa o diretor 12006 (que apresentou a proposição 12036) através do PVI 12010 dos requisitos necessários para apresentar uma proposta conforme. Esses requisitos podem ser personalizados para serem relevantes para a Proposta 12036
Petição 870200056145, de 06/05/2020, pág. 534/1737
532/754 especifica que foi rejeitada assim, o Diretor de referência 12006 é informado dos aspectos exatos que fizeram com que a Proposição 12036 fosse rejeitada e as modificações exatas da Proposição 12036 necessárias para executá-la. Também ilustrado na Fig. 1011 é como o PCP 12220 faz solicitações e recebe solicitações para Retenção de acompanhamento de proposta (PTR) 12004. As propostas anteriores são registradas na PTR 12004, que permite ao PCP 12220 determinar a conformidade com o Envio de proposta atual. Estágio 12034 12036. O Diretor 12022 do Diretor Independente (ID) 12020 não tem acesso à Interface de Voto da Proposta (PVI) 12010, assim como o Diretor 12006 do Conselho de Administração (BD) 12018. Isso ocorre porque Todas as medidas promulgadas pelo Diretor 12022 são imediatamente aceitas e implementadas na Estrutura de doações (ES) 12008 devido à falta da necessidade de alcançar consenso entre os vários Diretores 12006 com ideais potencialmente conflitantes.
[986] [00] As Figs. 1012-1014 demonstram a funcionalidade e o uso da Iniciação Preliminar do Encadeamento (PTI) 12080, que atua como uma sequência de iniciação para se preparar para a execução adequada da Avaliação Abrangente do Estado (CSE) 12400.
[987] A Fig. 1012 mostra a operação inicial do PTI 12080 na Etapa 12082. Na Etapa 12082, o Intervalo de Chamada CSE 12084 é recuperado da Política de Retenção Estabelecida (EPR) 12002 do Conselho de Administração selecionado (BD) 12018 ou do Diretor Independente (ID) 12020. O intervalo 12084 define com que frequência a Estrutura de Dotação (ES) 12008 relevante pretende gerar uma instância do CSE 12400. Um intervalo menor 12084
Petição 870200056145, de 06/05/2020, pág. 535/1737
533/754 implica que o EPR 12002 do ES 12008 indica que eles devem ser gastos mais Unidades de Watts em Taxas de BCHAIN para hospedar mais iterações de instâncias do CSE 12400 para obter uma representação da Configuração de Decisão de Investimento Ideal 12404, mais atualizada com os dados do mercado e corporativos. Posteriormente, na Etapa 12086, o tempo da Última Chamada CSE 12088 é recuperado de um armazenamento de valor definido no EPR 12002. O valor da Última Chamada CSE 12088 é uma variável específica relacionada à instância especificada BD 12018 ou ID 12020. Posteriormente, a Etapa 12090 é executada para verificar se o tempo entre a hora atual e a Última Invocação 12088 é maior que o Intervalo de Convocação 12084. Se a diferença de tempo calculada for maior que 12092, o Intervalo de Convocação 12084, CSE 12400 será chamado da Etapa 12094. Se a diferença horária calculada for menor que 12096, o Intervalo de Invocação 12084, CSE 12400 não será chamado de acordo com a Etapa 12098. A operação da Etapa 12094 leva à execução da Interpretação das Circunstâncias de Investimento Alvo (TICI) 12380. A operação do TICI 12380 e do CSE 12400 implica a conformidade com o Estágio 12100, que descreve a transferência de liquidez da instância relevante do Capital de Investimento (IC) 12012 para os BCHAIN Nodes 786 que abrigam as instâncias de TICI 12380 e CSE 12400. Portanto, a Estrutura de Doações (ES) 12008 está efetivamente alugando o serviço de análise de investimento inteligente realizado pelo CSE 12400 por meio de através da rede BCHAIN 110, as taxas de BCHAIN sendo pagas aos correspondentes 786 nós BCHAIN. A execução do TICI 12380 produz Circunstâncias de Investimento Objetivo 12160, que o CSE 12400 interpreta para
Petição 870200056145, de 06/05/2020, pág. 536/1737
534/754 produzir um Ajuste Ideal de Decisão de Investimento 12404 que reflete corretamente o estado atual dos mercados e empresas. O cache de resultados TICI 12112 é um clone compactado das Circunstâncias de Investimento Alvo 12160, que podem ser referenciadas posteriormente por Manipulação Automática de Violação (A0M2) 12140. O cache 12112 é produzido e referenciado por evite ter que chamar uma instância separada do TICI 12380, que custaria mais recursos computacionais e produziría os mesmos resultados.
[988] A Fig. 1013 mostra uma lógica operacional adicional referente à Iniciativa Preliminar de Ameaças (PTI) 12080, que é retomada a partir do Estágio 12100. Após o financiamento bem-sucedido dos correspondentes 786 BCHAIN Nodes do correspondente Capital de Investimento (IC) 12012, de acordo com Na Etapa 12100, é chamada a Etapa 12102, que avalia se a Manipulação de medida de substituição automática (A0M2) 12140 foi marcada para chamada no EPR 12002 correspondente da Estrutura de doações (ES) 12008 relevante 12008 pode optar por ativar o A0M2 12140 se uma Mente-Alvo 12702 específica for orientar as decisões de investimento tomadas pelo CSE 12400. Se o EPR 12002 indicar que a operação do A0M2 12102 foi desativada 12106, a Etapa 12110 será executada indicando que a execução modular do PTI 12080 e, portanto, o cache de resultados TICI 12112 pode ser removida com segurança para aumentar a eficiência ciência no sistema. Se o EPR 12002 indicar que a operação do A0M2 12104 está ativada, a Etapa 12108 será executada para recuperar a Invocação de Intervalo A0M2 12114 definida do EPR 12002. Posteriormente, na Etapa 12116, o BD 12018 ou ID 12020 correspondente invocado
Petição 870200056145, de 06/05/2020, pág. 537/1737
535/754 por esta instância do Processo de Iniciação de Encadeamento (PTI) 12080 recupera o horário da Última Invocação do A0M2 12118. A operação subsequente solicita a Etapa 12120, que verifica se a diferença horária calculada entre o horário atual e a Última Invocação do A0M2 12118 é maior que o Intervalo de Chamada A0M2 12114. Se a diferença de tempo calculada for Menor que 12130, é promulgado o Intervalo de Chamada A0M2 12114, Etapa 12132, que remove o Cache de Resultados TICI 12112 e implica a Falha de Chamada A0M2 12140. Se a diferença de tempo calculada for Maior que 12122, o Intervalo de Invocação A0M2 12114, a Identidade Mental de Destino A0M2 12130 será recuperada no Estágio 12 124, levando à invocação da A0M2 12140 na Etapa 12126. Posteriormente, na Etapa 12128, os fundos para hospedar/iniciar/executar A0M2 12140 na Rede BCHAIN 110 são retirados do Capital de Investimento (IC) 12012 correspondente dos nós 786 BCHAIN correspondentes que hospedam a instância A0M2 12140.
[989] A Fig. 1014 mostra mais detalhes sobre a lógica ilustrada anteriormente na Fig. 1013, iniciando na Etapa 12124. A Etapa 12124 recupera a Identidade Mental Objetiva A0M2 12130 de Retenção de Política Estabelecida (EPR) 12002 e a envia para a Manipulação Automática de Medidas de anulação (A0M2) 12140. Posteriormente, o estágio 12124 leva ao estágio 12126, que envolve a invocação do próprio A0M2 12140. A invocação do A0M2 12140 no estágio 12126 é o que leva à transferência das taxas de BCHAIN para que ocorre na Etapa 12128 para facilitar a execução do A0M2 12140. O Rastreamento Mental Digital (DMT) 12700 é capaz de emular a Mente-alvo 12702 associada à A0M2 da Identidade da Mente-alvo 12130. Os resultados do cache TICI 12112 são
Petição 870200056145, de 06/05/2020, pág. 538/1737
536/754 produzidos a partir de Circunstâncias de Investimento Alvo (TICI) 12380 e são enviados como entrada modular para A0M2 12140 para fornecer as circunstâncias relevantes de Investimento Alvo 12160 que devem ser consideradas exigidas pela Mente-alvo 12702. Portanto, a execução completa do A0M2 12140 leva a modificações feitas pelo A0M2 12140 na substituição de retenção de medida (OMR) 12064. Tais modificações requerem a leitura das medidas de anulação pré-existentes que existem no OMR 12064, portanto, uma seta bidirecional é exibida entre A0M2 12140 e OMR 12064 do BD 12018 ou 12020 relevante.
[990] [00] As Figs. 1015-1026 mostram a funcionalidade e operação da Manipulação Automática de Medidas de Anulação (A0M2) 12140. A0M2 12140 emula os critérios reacionários de uma
Mente Meta 12702, que foi identificada através da Identidade Mental de Alvo 12130 da A0M2, para promulgar, modificar ou excluir as Medidas de Anulação promulgadas retendo a Medida de Anulação (OMR) 12064 de uma Estrutura de Dotação (ES) 12008 relevante. O efeito prático da operação da A0M2 12140 é que o ES 12008 relevante contém uma OMR 12064 conduzindo às reações e tendências esperadas da Target Mind 12702, identificadas pela A0M2 Identidade Mental do Alvo 12130. A composição resultante do OMR 12064 influencia as Circunstâncias de Investimento Alvo 12160, produzidas pela Interpretação das Circunstâncias Alvo do investimento (TICI) 12380 e, portanto, no Ajuste de decisão de investimento ideal 12404, produzido pela CSE 12400.
[991] A Fig. 1015 mostra a operação inicial do A0M2 12140 da Etapa 12152, que recebe o cache de resultados TICI 12112 do TICI 12380. Subsequentemente, o cache de resultados TICI 12112
Petição 870200056145, de 06/05/2020, pág. 539/1737
537/754 é descompactado e extraído na etapa 12150 para produzir as circunstâncias de o Investimento Alvo 12160 que foi processado originalmente pelo TICI 12380. Posteriormente, é processada a Etapa 12148, que recupera a Posição de aposta atual 12146 da Carteira retida na fonte (PSR) 12003. A Posição de ação atual 12146 representa os vários investimentos ativos nos quais o ES 12008 está participando atualmente. Subsequentemente, a Etapa 12142 é processada, recuperando todas as Medidas de anulação OMR 12064 atualmente ativas e produzindo-as como Medidas de anulação ativa 12144. Posteriormente, a Etapa 12154 que acumula todas as variáveis processadas anteriormente é processada. O Código de Cancelamento 12144, Posição Atual na Aposta 12146, Circunstâncias de Investimento ou Objetivo 12160 e Identidade Mental Objetiva A0M2 12130. Após a acumulação, as variáveis mencionadas acima são fornecidas ao Módulo de Solicitação de Emulação Mental (MERM) 12952 para invocar corretamente instâncias do Digital Mental Tracking (DMT) 12700.
[992]A Fig. 1016 continua o fluxo lógico do A0M2 12140 da Etapa 12154. O Estágio subsequente 12164 destaca a operação do MERM 12952 e DMT 12700 que produz as Medidas de substituição preferidas 12162. O Estágio 12154 invoca o MERM 12952 que, por sua vez, produz uma solicitação da Emulação Mental 12910 que é enviada à DMT 12700. A DMT usa a tecnologia CTMP 124 para emular a Mente-Alvo 12702 representada pela Identidade-Alvo Mental A0M2 12130, produzindo o Resultado de Percepção Mental 12950 associado a Mente-Alvo 12702 especificado. O resultado da percepção mental 12950 é enviado de volta ao MERM 12952, que é onde o DMT 12700 original foi chamado. Portanto, o MERM 12952 chama várias
Petição 870200056145, de 06/05/2020, pág. 540/1737
538/754 instâncias do DMT 12700 conforme necessário para produzir com precisão o resultado final das Medidas de anulação preferidas 12162. As medidas de anulação preferidas 12162 representam as medidas de anulação que devem ser selecionadas e, portanto, preferidas pela Mente alvo 12702 especificada. Portanto, após a produção das Medidas de Cancelamento Preferidas 12162, a Etapa 12164 é concluída e a Etapa 12166 é posteriormente processada. A etapa 12166 chama o LIZARD 120 para converter as Medidas de Substituição Preferidas 12162 em um Mapa de Hierarquia de Finalidades 12168. Posteriormente, o LIZARD 120 também é chamado para converter as Medidas de Substituição Ativas 12170 em um Mapa de Hierarquia de Finalidades 12174 no estágio 1272.
[993] A Fig. 1017 mostra detalhes de como o LIZARD 120 trabalha para converter as Medidas de invalidação preferenciais 12162 em um mapa de hierarquia de finalidades 12166. As Medidas de vazios preferenciais 12161 são enviadas ao Módulo de sintaxe (SM) C35 pertencente à jurisdição do Núcleo externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Escrever códigos; recebe o Formulário de finalidade complexa C325 do Módulo de finalidade (PM) C36. O formato de finalidade complexa C325 é escrito em sintaxe de código arbitrária, também conhecida como pseudocódigo. O pseudocódigo contém implementações básicas de operações de cálculo que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops while, etc. Posteriormente, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação de destino desejada (linguagem de computador). Para leitura de
Petição 870200056145, de 06/05/2020, pág. 541/1737
539/754 código, o SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar uma finalidade para a funcionalidade desse código. A medida 12162 é recebida no formato de sintaxe da medida substituta 12161 para a Tradução de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) que o SM C35 reconhece e entende em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em tipos de sintaxe arbitrários. A saida da execução de Conversão de Código C321 concluída é transferida como entrada para Redução Lógica C323. A Redução lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, uma vez concluída a execução da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma finalidade no Formato de Finalidade Complexa C325 do código do computador. Esta definição de finalidade descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada por SM C35. 0 PM C36 também pode detectar trechos de código secretamente imersos nos dados (binários/ASCII, etc.). A Interpretação Iterativa C328 passa por todas as funções interconectadas para produzir uma definição de finalidade interpretada no Formato de Propósito Complexo (C325) ao se referir às Associações de Propósito C326. 0 C333 Núcleo central (IC) é a área LIZARD 120 que não é submetida a manutenção/autoprogramação automática e é
Petição 870200056145, de 06/05/2020, pág. 542/1737
540/754 programada direta e exclusivamente por especialistas na área relevante. O elemento Código Central C335 do IC C333 contém quadros e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o Código Central C335 permite a operação e operação geral do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[994] A Fig. 1018 continua o fluxo lógico da Fig. 1017 para ilustrar como o LIZARD 120 funciona para converter as Medidas de substituição preferenciais 12162 em um Mapa de hierarquia de finalidades 12166. A Redução Lógica C323 do Módulo Sintaxe (SM) C35 envia sua saída à Interpretação Iterativa C328 do Módulo de Propósito (PM) C36.A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de propósito interpretada, consultando Associações de Propósito C326. A saída de definição de finalidade existe no Formato de Finalidade Complexa C325, que é enviado como uma saída modular para PM C36 e, portanto, o Núcleo Externo (OC) C329 e, portanto, o LIZARD 120. O resultado é rotulado como um Mapa de Hierarquia de Finalidade 12168 que é apresentado como versão C325 do Formato de Finalidade Complexa das Medidas de Anulação Preferidas 12162. A mesma definição e aplicação do Núcleo Central (IC) C333 se aplica às funções e módulos mencionados acima.
Petição 870200056145, de 06/05/2020, pág. 543/1737
541/754
[995] A Fig. 1019 mostra detalhes de como o LIZARD 120 trabalha para converter as Medidas de substituição ativas 12170 em um mapa de hierarquia de finalidades 12174. As Medidas de substituição ativas 12170 são enviadas ao Módulo de sintaxe (SM) C35 pertencente à jurisdição do Núcleo externo (OC) C329. O SM C35 fornece uma estrutura para leitura e gravação de código de computador. Escrever códigos; recebe o Formulário de finalidade complexa C325 do Módulo de Finalidade (PM) C36. O formato de finalidade complexa C325 é escrito em sintaxe de código arbitrária, também conhecida como pseudocódigo. O pseudocódigo contém implementações básicas de operações de cálculo que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops while, etc. Posteriormente, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação de destino desejada (linguagem de computador) . Para leitura de código, o SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar uma finalidade para a funcionalidade desse código. As medidas 12162 são recebidas na forma de Substituir sintaxe de medida 12161 pela conversão de código C321. A Tradução de Código C321 converte código arbitrário (genérico) que o SM C35 reconhece e entende em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em tipos de sintaxe arbitrários. A saida da execução de Conversão de Código C321 concluída é transferida como entrada para Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para maneiras mais simples de produzir um mapa de funções
Petição 870200056145, de 06/05/2020, pág. 544/1737
542/754 interconectadas, de acordo com as definições de Regras e Sintaxe C322. Portanto, uma vez concluída a execução da redução lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma finalidade no Formato de Finalidade Complexa C325 do código do computador. Esta definição de finalidade descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada por SM C35. 0 PM C36 também pode detectar trechos de código secretamente imersos nos dados (binários/ASCII, etc.). A Interpretação Iterativa C328 passa por todas as funções interconectadas para produzir uma definição de finalidade interpretada (no Formato de Propósito Complexo C325) ao se referir às Associações de Propósito C326. 0 C333 Núcleo Central (IC) é a área LIZARD 120 que não é submetida a manutenção/autoprogramação automática e é programada direta e exclusivamente por especialistas na área relevante. O elemento Código Central C335 do IC C333 contém quadros e bibliotecas fundamentais, scripts de gerenciamento de threads e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o Código Central C335 permite a operação e operação geral do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
Petição 870200056145, de 06/05/2020, pág. 545/1737
543/754
[996] A Fig. 1020 continua o fluxo lógico da Fig. 1019 para ilustrar como o LIZARD 120 funciona para converter as Medidas de substituição ativas 12170 em um mapa de hierarquia de finalidades 12166. A Redução Lógica C323 do Módulo de sintaxe (SM) C35 envia sua saida à Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de propósito interpretada, consultando Associações de Propósito C326. A saida de definição de finalidade existe no Formato de Finalidade Complexa C325, que é enviado como uma saida modular para PM C36 e, portanto, o Núcleo Externo (OC) C329 e, portanto, o LIZARD 120. O resultado é rotulado como um mapa de hierarquia de finalidade 12174 que é apresentado como versão C325 do Formato de finalidade complexa das medidas de substituição ativas 12170. A mesma definição e aplicação do Núcleo central (IC) C333 se aplica às funções e módulos mencionados acima.
[997] A Fig. 1021 continua o fluxo lógico da Fig. 1016. O Mapa de Hierarquia de Propósito 12174 das Medidas de Substituição Ativas 12170 é enviado para a Etapa 12180 que chama o LIZARD 120 para converter o Mapa 12174 na sintaxe da cadeia de os aplicativos 9285 que são referidos como Retenção da Appchain original 12184. O Mapa de Hierarquia de Propósito 12168 das Medidas de Invalidação Preferidas 12162 é enviado para a Etapa 12186 que chama o LIZARD 120 para converter o Mapa 12162 na Sintaxe da Appchain 9285 referida como Retenção Aprimorada da Cadeia de Aplicativos 12188. O Mapa de Hierarquia de Finalidade de 12174 e 12168 se torna a Sintaxe da Appchain 9285 para que a Etapa 12190 possa chamar o Conjunto de Implementação de Patch
Petição 870200056145, de 06/05/2020, pág. 546/1737
544/754 (DPA) 6260 para criar um patch 12192 de correção da Appchain. Esse patch 12192 contém as diferenças entre as retenções da Appchain 12184 que praticamente e correlacionamos com as medidas de anulação ativa (original) 12170 e as novas medidas de anulação preferida 12162 propostas pela Mente Objetivo 12702 como emuladas pelo A0M2 12140.
[998] A Fig. 1022 mostra detalhes de como o LIZARD 120 funciona para converter o Mapa de Hierarquia de Propósito 12174 das Medidas de Substituição Ativa 12170 na Sintaxe da Appchain. O mapa 12174 existe no Formato de Propósito Complexo C325 e é enviado para a Expansão Iterativa C327 do Módulo de Propósito C36 no Núcleo Externo (OC) C329 do LIZARD 120. A Expansão Iterativa C327 adiciona detalhes e complexidade para desenvolver um objetivo simples (indiretamente definido no Mapa 12174) em uma definição especifica de finalidade complexa. Portanto, o potencial máximo da Associação de Propósito C326 da entrada é realizado e retido como um Formato de Propósito Complexo C325, antes de enviá-lo à Derivação Lógica C320 do Módulo de Sintaxe (SM) C35. 0 Código principal C335 do elemento C333 do Código Principal (IC) contém quadros e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o Código Central C335 permite a operação e operação geral do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento de Objetivos do Sistema C336 do IC C333 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para
Petição 870200056145, de 06/05/2020, pág. 547/1737
545/754 orientar várias funções dinâmicas e estáticas no LIZARD 120.
[999] A Fig. 1023 continua o fluxo lógico da Fig. 1022 para ilustrar a operação do LIZARD 120 para converter as Medidas de substituição ativas 12170 na sintaxe da Appchain, denominada Retenção original da Appchain 12184. Os dados de entrada recebem no formato de finalidade complexa 0325 do módulo de finalidade (PM) 036 e são transferidos para a derivação lógica 0320 do módulo de sintaxe (SM) 035. A Derivação lógica 0320 deriva funções logicamente necessárias de funções inicialmente mais simples. Isso significa que se uma função pode ser formada como uma função derivada devido à implicação de uma função principal mais simples; então é formado pela derivação lógica 0320. A saída produzida é uma árvore de dependências de funções que são criadas de acordo com os dados 0325 definidos no Formato de Propósito Complexo. A derivação lógica C320 funciona de acordo com as definições das regras e sintaxe C322 que são herdadas do elemento do código central C335 do núcleo central (IC) C333. A derivação lógica C320 envia sua saída para a Tradução de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) que o SM C35 reconhece e entende em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em tipos de sintaxe arbitrários. Portanto, o PM C36 chama o SM C35 para produzir a versão 12184 da sintaxe da Appchain resultante das medidas de substituição ativa de entrada 12170 através da conversão de código C321. A Retenção de Appchain Original 12184 resultante, produzida pela Conversão de Código C321, é a saída modular do SM C35, Núcleo Externo (OC) C329 e
Petição 870200056145, de 06/05/2020, pág. 548/1737
546/754
LIZARD 120.
[1000] A Fig. 1024 mostra detalhes de como o LIZARD 120 funciona para converter o Mapa de Hierarquia de Finalidades 12168 das Medidas de invalidação preferidas 12170 para a sintaxe da Appchain. 0 mapa 12168 existe no Formato de Propósito Complexo C325 e é enviado para a Expansão Iterativa C327 do Módulo de Propósito C36 no Núcleo Externo (OC) C329 do LIZARD 120. A Expansão Iterativa C327 adiciona detalhes e complexidade para desenvolver um objetivo simples (indiretamente definido no Mapa 12168) em uma definição especifica de finalidade complexa. Portanto, o potencial máximo da Associação de Propósito C326 da entrada é realizado e retido como um Formato de Propósito Complexo C325, antes de enviá-lo à Derivação Lógica C320 do Módulo de Sintaxe (SM) C35. O Código principal C335 do elemento C333 do código principal (IC) contém quadros e bibliotecas fundamentais, scripts de gerenciamento de encadeamento e balanceamento de carga, protocolos de comunicação e criptografia e sistemas de gerenciamento de memória. Portanto, o Código Central C335 permite a operação e operação geral do SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a Política de Segurança e os Objetivos de Negócios. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1001] A Fig. 1025 continua o Fluxo Lógico da Fig. 1024 para ilustrar a operação do LIZARD 120 para converter as Medidas de substituição preferenciais 12162 na sintaxe da Appchain, denominada Retenção aprimorada da Appchain 12188. Os
Petição 870200056145, de 06/05/2020, pág. 549/1737
547/754 dados de entrada são recebidos em Formato de finalidade complexa C325 do Módulo de finalidade (PM) C36 e transfira para Derivação lógica C320 do Módulo de sintaxe (SM) C35. A Derivação lógica C320 deriva funções logicamente necessárias de funções inicialmente mais simples. Isso significa que se uma função pode ser formada como uma função derivada devido à implicação de uma função principal mais simples; então é formado pela derivação lógica C320. A saída produzida é uma árvore de dependências de funções que são criadas de acordo com os dados C325 definidos no Formato de Propósito Complexo. A derivação lógica C320 funciona de acordo com as definições das regras e sintaxe C322 que são herdadas do elemento do código central C335 do Núcleo Central (IC) C333. A derivação lógica C320 envia sua saída para a Tradução de Código C321. A Tradução de Código C321 converte código arbitrário (genérico) que o SM C35 reconhece e entende em qualquer idioma de cálculo conhecido e escolhido. A Tradução de Código C321 também executa a função inversa de traduzir linguagens de computador conhecidas em tipos de sintaxe arbitrários. Portanto, o PM C36 chama o SM C35 para produzir a versão 12188 da sintaxe da Appchain resultante das medidas de cancelamento preferenciais de entrada 12162 por meio da Tradução de Código C321. A versão 12188 da sintaxe da Appchain resultante, produzida pela Tradução de Código C321, é a saída modular do SM C35, Núcleo Externo (OC) C329 e LIZARD 120.
[1002] A Fig. 1026 resume e segue a lógica mostrada na Fig. 1021. No estágio 12194: Antes do DPA 6260 produzir com êxito o Patch de Correção de Appchain 12192 até a Etapa 12190, que se comprometeu com uma Substituição Persistente de Retenção
Petição 870200056145, de 06/05/2020, pág. 550/1737
548/754 de Medida (OMR) 12064 do BD 12018 ou ID 12020 relevante através do Construtor de Ecossistemas de Customchain (CEB) 584. 0 CEB 584 modifica a Appchain subjacente que representa o exemplo OMR 12064 correspondente, portanto, a instalação da Appchain Patch de correção 12192.
[1003] [00] A Fig. 1027 mostra o conceito de injeção de liquidez 12200, que ilustra mais detalhes sobre os conceitos econômicos mostrados na etapa 12100 da Fig. 1012 e na etapa 12128 da Fig. 1013. O conceito 12200 começa com o estágio 12202, onde decisões baseadas em consenso de investir em serviços inteligentes de previsão de investimentos se tornam uma Estrutura de doações (ES) 12008. O ES 12008 financia o serviço de previsão, Avaliação Abrangente do Estado (CSE) 12400, através do Capital Plano de Investimento (IC) 12012. Posteriormente, a Etapa 12204 é executada, que chama instâncias do CSE 12400 de acordo com o Intervalo de Invocação do CSE 12084 definido na Política de Retenção Estabelecida (EPR) 12002 do ES 12008 relevante. Um intervalo 12084 maior significa que menos dinheiro será gasto, o que resulta em uma previsão de investimento menos precisa do CSE 12400, enquanto o inverso também se aplica. Após a invocação do CSE 12400 pela Etapa 12204, a operação da Etapa 12206 é ativada, o que implica que o trabalho de cálculo seja realizado através dos nós BCHAIN 786 que operam o Protocolo BCHAIN 794, formando assim a Rede BCHAIN 110. A operação do Estágio 12206 envolve a operação do Estágio 12208, que indica a manipulação de fundos que são estrategicamente alocados na instância relevante do Capital de Investimento (IC) 12012 que acumula a Economia de Watt 862 da Metachain 834. Os fundos nunca existem criptograficamente
Petição 870200056145, de 06/05/2020, pág. 551/1737
549/754 diretamente na instância do IC 12012, mas são confirmados via WUP2 12016 pelos nós BCHAIN 786 que mantêm os fundos. Portanto, todas as unidades de watt são gerenciadas pela Economia de Watt 862 enquanto residem criptograficamente nos nós físicos do BCHAIN 786. Portanto, o Conceito de Injeção de Liquidez 12200 indica que a demanda do Investidor/Diretor 12006/12022 inicia transferências de Unidades de Watt dentro da Economia de Watt
62 dos Nós BCHAIN 78 6 (que prometeram fundos através da WUP2 12016 para a instância relevante do Capital de investimento (IC) 12012) para outros nós BCHAIN 786 que realizaram o trabalho computacional para hospedar o correspondente Interpretação de Objetivos de Circunstâncias de Investimento (TICI) 12380, Avaliação Abrangente do Estado (CSE) 12400 e Manipulação de Medidas de cancelamento automatizadas (A0M2) 12140.
[1004] [00] As Figs. 1028-1030 mostra, a funcionalidade e operação do Procedimento de conformidade da proposta (PCP) 12220 e sua interação correspondente com a Interface de votação da proposta (PVI) 12010.
[1005] A Fig. 1028 mostra como a lógica é iniciada na Etapa 12034 da PVI 12010, que indica a submissão de uma Proposta Autorizada 12222 (das várias Propostas de Potenciais Autorizadas 12036) por um Diretor 12006/12022 a PCP 12220. Portanto, o estágio 12228 da justificativa para PCP 12220 está ativado, que verifica se a Proposta Autorizada 12222 é enviada por um Conselho de Administração 12018/12230 ou por um Diretor Independente 12020/12232. Se a Opção 12230 for incorrida, a Etapa 12234 será ativada subsequentemente, o que determinará o Suporte ao Investimento em Capital de Investimento (IC) 12012 relevante;
Petição 870200056145, de 06/05/2020, pág. 552/1737
550/754 instância que foi executada pelo Diretor 12006 de acordo com as informações armazenadas na retenção 12000 do Rastreamento de Suporte. Portanto, ocorre a Participação no Investimento 12236. Se a Opção 12232 for incorrida, a lógica saltará para Estágio 12224 ao qual a Opção 12230 também leva. Após a recuperação da Participação no Investimento 12236 até o Estágio 12234, o Estágio 12238 recupera subsequentemente o Registro de Proposta 12242 do Diretor 12238 relevante, de acordo com a Retenção na Fonte de Acompanhamento de propostas (PTR) 12004. O referido registro 12242 da proposta contém todas as propostas anteriores feitas pelo diretor 12238 especificado, registradas no ES 12008 a PTR 12004. Posteriormente, a Etapa 12240 calcula com que frequência o diretor 12006 especificado pode enviar uma proposta por meio da atribuição de proposta de diretor (DPA) 12260. A lógica executada após o estágio 12240, não ilustrado na Fig. 1028, eventualmente leva à ativação da Etapa 12224 se a Proposta Autorizada 12222 estiver em conformidade. Isso leva a que a proposta 12226 seja enviada como saida modular do PCP 12220 para o estágio 12012 do PVI 12010. O estágio 12012 implica que a proposta 12226 seja submetida aos diretores relevantes 12006 (do Conselho de Administração (BD) 12018) ou para o diretor 12022 (do diretor independente (ID) 12020). Múltiplos Diretores 12006 podem votar a favor ou contra a Proposição 12226, garantindo assim consenso entre a Diretoria 12018. Para o único Diretor 12022, a Proposta de Conformidade 12226 é automaticamente aceita pela Estrutura de Dotações 12008 e, portanto, Portanto, é adicionado à instância relevante da Proposta de retenção de acompanhamento (PTR) 12004.
Petição 870200056145, de 06/05/2020, pág. 553/1737
551/754
[1006] A Fig. 1029 mostra a Interface de votação para propostas (PVI) 12010 que funciona como um subconjunto do Mecanismo de votação para diretores (DVM) 12030; portanto, mostra uma integração adicional com o Procedimento de conformidade da proposta (PCP) 12220. A lógica é retomada da Etapa 12240; invocando o Subsidio de Proposta de Diretor (DPA) 12260 para calcular o Subsidio de Diretor 12244 a partir do Diretor 12006 especificado. O estágio 12250 é processado posteriormente e considera se o preenchimento da Proposta Autorizada 12222 está em conformidade com o Regulamento 12246 ou se não está em conformidade com o Regulamento 12248, de acordo com a Designação do Diretor 12244 e o registro da Proposição 12242. Se a frequência recente de as propostas feitas pelo diretor 12006, conforme indicado no registro 122242 da proposta, excedem a atribuição 12244 do diretor; a proposta 12222 é considerada Não-conforme 12248. Diante do cenário 12248 não conforme, o PCP 12220 informa ao DVM 12030 que o envio da Proposição 12222 deve ser rejeitado de acordo com a Etapa 12078. O cenário Está em Conformidade com 12246 e é promulgado se a frequência das propostas indicadas no Registro da proposta 122242 está dentro do limite definido na Cessão do Diretor 12244. Portanto, o cenário que Cumpre 12246 leva ao Estágio 12224, que apresenta a Proposta agora em Conformidade com 12226 ao Estágio 12012 do PVI 12010. Portanto, o Estágio 12056 do DVM 12030 apresenta a Proposta sob 12226 para votar nos outros Diretores 12006 através do PVI 12010.
[1007] A Fig. 1030 mostra detalhes adicionais sobre a operação da Etapa 12240 que produz a variável de atribuição de diretor 12244 por meio da operação de atribuição de proposta de
Petição 870200056145, de 06/05/2020, pág. 554/1737
552/754 diretor (DPA) 12260. Na etapa 12262, o multiplicador de atribuição de diretor 12264 é recuperado da retenção estabelecida da política (EPR) 12002 da instância relevante do Conselho de Administração (BD) 12018. O Multiplicador 12264 representa uma proporção selecionada que representa a Permissão do Diretor 12244 fornecida em correlação com a Participação do Investidor do Diretor 12236. Portanto, a Subvenção 12244 da Proposta do Diretor 12006 está correlacionada com a magnitude dos investimentos que eles fizeram em nome da Estrutura de Dotações (ES) 12008. Posteriormente, nas Etapas 12266 e 12268, a Atribuição do Diretor 12244 é produzido pela multiplicação do multiplicador 12264 pela parcela de investimento 12236. Conforme indicada na Etapa 1 2268, a atribuição 12244 do diretor representa o intervalo de horas em horas em que o diretor 12006 pode enviar uma proposta. Portanto, se a Tarefa 12244 for de vinte e quatro horas, o Diretor 12006 poderá enviar uma proposta dentro desse período de vinte e quatro horas, mas não mais (até que o período da Tarefa 12244 seja restabelecido). Essa implementação da atribuição 12244 atua como um mecanismo de prevenção de abuso de spam, o que pode ser especialmente útil para as diretorias 12002 que contêm muitos diretores 12006 que podem facilmente obter associação (ou seja, financiamento coletivo). Portanto, a tarefa 12244 do diretor é encaminhada para a etapa 12250, ilustrada em detalhes. A etapa 12268 indiretamente leva à ativação da etapa 12270; que inspeciona o Registro da proposta 12274 para discernir quando o Diretor 12006 enviou a última Proposta em conformidade 12272. As Propostas não em conformidade 12222 não contam para a taxa do Diretor 12006. Portanto, a última Proposta em conformidade 12272
Petição 870200056145, de 06/05/2020, pág. 555/1737
553/754 é produzida e interpretada na Fase 12276. 0 estágio 12276 verifica se o tempo calculado desde a última proposta de acordo com 12272 é maior que 12276 ou menor que 12280, a designação do diretor 12244. Se o tempo calculado for maior que 12276, a proposta autorizada 12222 será considerada cumprida para 12278 se o tempo calculado for Menor que 12280, a Proposta Autorizada 12222 será considerada Não Conforme para 12282.
[1008] [00] A Fig. 1031 mostra a operação e operação do Relatório de status corporativo (CSR) 12304. O CSR 12304 gerencia relatórios de informações realizados por entidades corporativas registradas que enviam informações operacionais para a Appchain de rastreamento de entidades corporativas correspondente. Isso, por sua vez, permite que a Avaliação Abrangente do Estado (CSE) 12400 considere a atividade operacional de todas as entidades corporativas registradas no processamento de uma Estrutura de Doações (ES) 12008 correspondente à Decisão de Investimento de Ajuste Ideal 12404. Uma entidade corporativa é registrada no sentido de ter escolhido anunciar os principais elementos dos dados registrados relacionados às suas atividades operacionais (como inventário, vendas, composição de funcionários etc.) ao Appchain de acompanhamento de entidades corporativas 12302. O CSR 12304 foi iniciado pelo CSE 12400, no Estágio 12288, que passa por todas as Entidades corporativas rastreadas em 12286 no Rastreamento de Entidade Corporativa (CET) 12284. Posteriormente, no Estágio 12290, a Identidade de entidade corporativa 1286 é recuperada da unidade selecionada do loop iniciado na Etapa 12288. Posteriormente, na Etapa 12292, o Nó BCHAIN 786 que hospeda essa
Petição 870200056145, de 06/05/2020, pág. 556/1737
554/754 instância de execução do CSR 12304 verifica se a Appchain de rastreamento de entidade corporativa 12302 que se correlaciona com a identidade de entidade corporativa 12286 existe e é atualizado localmente (nó 786) no caso contrário, ocorreu o cenário 12296 Não, não atualizado, que é recuperado posteriormente pelo Appchain de acompanhamento de entidades corporativas 12302 relevante referente ao Metachain 834 por meio do Gerador de Reivindicação de Conteúdo (CCG) 3050. O CCG 3050 é uma função principal do protocolo BCHAIN 794 que permite recuperar o conteúdo de vários nós BCHAIN 786 na rede BCHAIN 110. O Módulo de Reconhecimento de Customchain (CRM) 3060 é outra função principal do protocolo da BCHAIN 794, que mantém automaticamente 836 aplicativos (e, por extensão, Microchains 838) definidas nos Aplicativos Registrados 776. Portanto, as atualizações em tempo real 3062 vêm das atualizações do Metachain 834 da Appchain 846 para indicar se o novo conteúdo está disponível na Appchain 836 especificado. Portanto, o CRM 3060 calculará se a Appchain 836 especificada está sendo mantida localmente (registrado via 776 Appchains registrados) e informará a Etapa 12292 se a retenção local da Appchain 836 especificado está atualizada 12294 ou não atualizada 12296. Se o CCG for chamado 3050 para atualizar a Appchain 836 especificado, vários elementos do Metachain 834 são fornecidos ao CCG 3050, como o roteamento de setor otimizado 858, o local de cache da Appchain 848, o rastreamento de ambiente caótico 856 e a associação de localização 840. Isso permite que o CCG 3050 invoque Corretamente à rede BCHAIN 110 para o conteúdo solicitado, eventualmente levando a Representação de Reivindicação de Conteúdo (CCR) 3300
Petição 870200056145, de 06/05/2020, pág. 557/1737
555/754 a receber e validar a versão atualizada da Appchain de rastreamento de entidade corporativa 12302. Portanto, os cenários 1294 e 12296 acabará por levar ao estágio 12300, que verifica se há uma referência à identidade da Entidade Corporativa 12286 na Appchain de rastreamento de entidades corporativas 12302.
[1009] A Fig. 1032 contínua da Fig. 1031 para descrever o Relatório de status corporativo (CSR) 12304, continuando na Etapa 12300. Se houver uma referência sobre a Identidade da entidade corporativa 12286 na Appchain de rastreamento de entidade corporativa 12302, ativa o cenário 12303 Sim, a referência existe. O cenário 12303 leva à referência da Appchain de rastreamento de entidade corporativa correspondente 12310; que contém as informações de operações relatadas da própria entidade corporativa. Com um cenário 12306 Não, a referência não existe, a execução do CSR 12304 atinge um estado de erro, o que implica que uma Unidade de Registro de Diagnóstico (DLU) 1182 é enviada para o DLS (Envio de Registro de Diagnóstico) 1160 até o estágio 5602. Posteriormente, o Mecanismo de investigação automatizado (ARM) 134 encaminha o relatório de erros na forma de DLU 1182 para a Autoprogramação e a AutoInovação (SPSI) 130, que processa o relatório de erros através do submódulo de análise Unidade de Registro de Diagnóstico (DLUA) 8048. Esse loop de feedback do Relatório de Erros com o SPSI 130 leva à programação do CSR 12304 para eventualmente mudar, para acomodar uma solução comprovada ao Relatório de Erros inicial demonstrado pelo DLU 1182. Isso segue o conceito SRIA ilustrado nas Figs. XYZ. Na continuação da ramificação lógica do Cenário 12303, a Identidade Corporativa 12310 recupera da Appchain,
Petição 870200056145, de 06/05/2020, pág. 558/1737
556/754 especifica da Identidade Corporativa 12286, é processada a partir da Etapa 12308 através dos módulos da BCHAIN 794 de Coleta de Sequências de Protocolos (ESC) 6700, Classificação de Fluxo de Dados (DSS) 6800 e Execução de Fluxo de Representação (ESR) 6400. Portanto, a lógica continua na Fig. 1033.
[1010] A Fig. 1033 continua a ramificação lógica do cenário 12303. A representação bem-sucedida da Appchain de identidade corporativa 12310 no ESR 6400 produz os resultados de representação da Appchain 12314. Os resultados de representação da Appchain 12314 contêm todos os pontos de acesso da API necessários para a entidade corporativa que corresponde à identidade corporativa Appchain 12310 e, portanto, à identidade corporativa 12286. Esses pontos de API são enviados como entrada modular para o módulo 12316 do Relatório de API de entidade corporativa (CEAR), que opera no Etapa 12312. A chamada da API realizada no CEAR 12316 é feita através da Rede BCHAIN 110. Portanto, a Entidade Corporativa registrada deve ter um Nó BCHAIN 786 ativo em sua jurisdição, para publicar corretamente a API no CEAR 12316. Portanto, o CEAR 12316 produz os resultados correspondentes da API da entidade corporativa 12318. Posteriormente, o estágio 12320 associa os resultados da API 12318 à sua identidade corporativa 12322 correspondente e envia o par para a retenção de cache de coleção corporativa (C3R) 12324 para armazenamento temporário da sessão. Posteriormente, a lógica do loop é mantida através da Mensagem 12326, que verifica se há Entidades Corporativas no loop, iniciadas pela Etapa 12288. Se a resposta à Solicitação 12326 for Sim 12328; então o fluxo lógico retorna à Etapa 12332, que continua a iterar pelas Entidades
Petição 870200056145, de 06/05/2020, pág. 559/1737
557/754
Corporativas 12286 rastreadas do Rastreamento de Entidades Corporativas (CET) 12284. A Fig. 1034 continua o fluxo lógico e detalha o cenário de uma resposta N° 12330 a Aplicação 12326.
[1011] A Fig. 1034 sobrepõe parte da lógica da Fig.
1033 para continuar o fluxo da lógica da Etapa 12320 e da Solicitação 12326. Se a Resposta à Solicitação 12326 for No 12330, a Etapa 12334 será ativada, confirmando os resultados de a sessão de Execução de Fluxo de Representação (ESR) 6400, da Retenção de Cache de Coleta Corporativa (C3R) 12324 até a Retenção Central de Conhecimento (CKR) 648 da LOM 132. O armazenamento de dados executado pelo C3R 12324 é mantido pelo armazenamento de sessão temporária nos nós BCHAIN 786 através da rede BCHAIN 110. Esse armazenamento de sessão temporária geralmente está na forma de Memória de Acesso Aleatório (RAM) , que é um meio eficiente de manter resultados de armazenamento temporário, mas não pode manter informações após a reinicialização do sistema. Portanto, quando C3R 12324 estiver operando dentro do Protocolo BCHAIN 794, o ESR 6400 usa o Tipo de comando 6420 do segmento de dados de gravação de sessão para operar as instruções de dados para C3R 12324. A definição da Sessão de gravação 6420 do Comando 6408 é definida pelos segmentos de execução 551 existentes na Appchain 836, que representa o CSR 12304. Portanto, ao contrário do uso temporário do Comando 6408 do segmento de dados de gravação de sessão 648, o comando 64022 do segmento de dados de gravação persistente é usado na Etapa 12334, que confirma a sessão temporária ESR 6400 persistente 6422 resulta em armazenamento CKR 648. Lá, a seção da Appchain 836 que define especificamente o Estágio 12334 contém
Petição 870200056145, de 06/05/2020, pág. 560/1737
558/754 os Segmentos de Execução 551 que indicam um Comando de Gravação Persistente 6408 6422. O Estágio 12326 percebe as Entidades Corporativas restantes no Loop por meio de informações do Estágio 12332 que o próprio loop inicia. Portanto, o contador de loop é mantido na etapa 12332.
[1012] A Fig. 1035 mostra a funcionalidade e operação do Procedimento de pesquisa de mercado (MRP) 12340. O MRP 12340 é iniciado pela operação da Avaliação abrangente do estado (CSE) 12400 por meio do submódulo de solicitação de chamada de pesquisa (RIP) 12338. O RIP 12338 invoca uma instância do LOM 132 que investiga atividades e eventos de mercado por meio do Mecanismo de Investigação Automatizado (ARM) 134 na Etapa 12342. Os resultados da pesquisa realizada pela ARM 134 são processados na Etapa 12344 que armazena informações novas e não confirmadas na Retenção Central de Conhecimento (CKR) 12344. Posteriormente, na Etapa 12346, em uma grande escala de tempo, o LOM 132 interage gradualmente com informações novas e não confirmadas armazenadas na CKR 648 para produzir afirmações e conclusões significativas e utilizáveis relacionadas à Atividade e Eventos do Mercado. Portanto, o LOM 132 produz Conhecimento da Atividade de Mercado 12348 na Etapa 12346 e o Conhecimento 12348 é subsequentemente armazenado no CKR 648 para referência posterior pelo CSE 12400.
[1013] A Fig. 1036 descreve os detalhes de execução relacionados à Etapa 12346 do MRP 12340. Inicialmente, o ARM 134 recupera informações não confirmadas de fontes públicas e privadas na Etapa 12350. Posteriormente, na Etapa 12354, o LOM 132 e o CTMP 124 verificam as informações não confirmado e
Petição 870200056145, de 06/05/2020, pág. 561/1737
559/754 expandi-lo para produzir conceitos verdadeiros. 0 elemento de verdade encontrado em um conceito/afirmação é determinado pela programação de objetividade 132 da LOM, que é ativada pelas habilidades de pensamento critico do CTMP 124 . Portanto, no Estágio 12356, o conhecimento confirmou que a LOM 132 alega concordar com a busca objetiva da verdade é produzida como Conhecimento da atividade de mercado 12348 e é posteriormente armazenada na CKR 648 para referência posterior pelo CSE 12400.
[1014] A Fig. 1037 mostra a funcionalidade e operação do Procedimento de Investigação Regulatória/Fiscal (RTRP) 12360. O RTRP 12360 é iniciado através da operação da Avaliação Integral do Estado (CSE) 12400 através do submódulo de Solicitação de Invocação de Investigação (RIP) 12338. O RIP 12338 chama uma instância do LOM 132 que investiga os Códigos Tributários e Regulatórios por meio do Mecanismo de Investigação Automatizado (ARM) 134 na Etapa 12362. Os resultados da investigação realizada pela ARM 134 são processados na Etapa 12364 que armazena Informações novas e não confirmadas na Retenção Central de Conhecimento (CKR) 12344. Posteriormente, no Estágio 12366, em uma grande escala de tempo, o LOM 132 interage gradualmente com informações novas e não confirmadas armazenadas na CKR 648 para produzir afirmações e conclusões significativas e utilizável relacionadas a códigos tributários e regulatórios. Portanto, o LOM 132 produz o Conhecimento de Responsabilidade Fiscal 12364 e o Conhecimento de Responsabilidade Normativa 12370 no Estágio 12366, que são armazenados posteriormente no CKR 648 para consulta subsequente pelo CSE 12400.
[1015] A Fig. 1038 detalha os detalhes de execução
Petição 870200056145, de 06/05/2020, pág. 562/1737
560/754 relacionados ao Estágio 12366 do RTRP 12360. Inicialmente, o ARM 134 recupera informações não confirmadas de fontes públicas e privadas no Estágio 12350. Posteriormente, no Estágio 12376, o LOM 132 e o CTMP 124 verificam as informações não confirmado e expandi-lo para produzir conceitos verdadeiros. O elemento de verdade encontrado em um conceito/afirmação é determinado pela programação de objetividade 132 da LOM, que é ativada pelas habilidades de pensamento critico do CTMP 124 . Portanto, no Estágio 12378, o conhecimento confirmou que a LOM 132 alega concordar com a busca objetiva por candidiase é produzida como Conhecimento da responsabilidade fiscal 12364 e Conhecimento da responsabilidade normativa 12370 e é posteriormente armazenada no CKR 648 para consulta posterior pelo CSE 12400.
[1016] [00] As Figs. 1039-1087 mostram a operação e operação do módulo 12400 da Avaliação Abrangente do Estado (CSE), que é o programa principal que realiza pesquisas/cálculos inteligentes sobre investimentos em nome da NMC 114 como um todo.
[1017] A Fig. 1039 mostra como o CSE 12400 é inicializado pela Interpretação de Circunstâncias de Investimento Alvo (TICI) 12380, que fornece as Circunstâncias de Investimento Alvo 12160 como uma entrada modular para CSE 12400 (na Etapa 12402) . O TICI 12380 começa com o Estágio 12382, que extrai o Ajuste da carteira de investimento 12384 da instância relevante da Retenção de carteira de investimento (PSR) 12003 da Estrutura de dotação (ES) 12008 correspondente. Posteriormente, na Etapa 12386, as Medidas de Anulação 12388 são extraídas da correspondente Medida de Anulação Retida na fonte (OMR) 12064 da Estrutura de Dotação (ES) 12008 correspondente. As Medidas de
Petição 870200056145, de 06/05/2020, pág. 563/1737
561/754
Anulação 12388 induzem um efeito de personalização previsto para a Decisão 12404 da Composição do Investimento Ideal, resultante dos critérios escolhidos e votados pelos Diretores 12006/12022 por meio do Mecanismo de Voto por Diretor (DVM) 12030. As Referidas Medidas 12388 podem ser escolhidas manualmente para personalizar investimentos (como: não fazer nenhum investimento de valor que dependa de um setor/mercado automatizado saudável) ou automaticamente escolhido por personalidades especificas por meio de emulações feitas no 12700 Digital Mental Tracking (DMT). 12390, as informações contidas no Ajuste da carteira de investimento 12384 e nas Medidas de anulação 12388 são mescladas em um contêiner de abstração que se torna as circunstâncias de investimento alvo 12160. Portanto, o contêiner de abstração 12160 é enviado ao CSE 12400 como entrada modular e, em seguida, geralmente processado na Etapa 12402. Após a conclusão da invocação de LOM 132 e CTMP 124 pela Etapa 12402, o ajuste ideal da decisão de investimento 12404 finalmente ocorre. A configuração 12404 é a saida modular final do CSE 12400.
[1018] A Fig. 1040 continua o fluxo de iniciação lógica do CSE 12400. A Etapa 12406 invoca o Procedimento de Pesquisa de Mercado (MRP) 12340 para CKR 846 através da LOM 132 para produzir o Conhecimento de Atividade de Mercado 12348 (ver Fig. 1035) para processamento de CSE 12400. A etapa subsequente 12408 continua o fluxo lógico após a conclusão do processamento instantâneo do MRP 12340. A conclusão do processamento instantâneo do MRP 12340 é definida como a conclusão da Etapa 12352, onde/quando as informações iniciais não são confirmadas são armazenadas na CKR 648. As etapas 12354 e 12356
Petição 870200056145, de 06/05/2020, pág. 564/1737
562/754 posteriormente no MRP 12340 são consideradas processamento pósinstantâneo. Isso ocorre porque essas etapas 12354 e 12356 ocorrem durante um periodo significativamente longo, no qual o LOM 132 e o CTMP 124 processam gradualmente informações não confirmadas e derivam declarações e conclusões verdadeiras relacionadas a essas informações. Portanto, o gerenciamento de encadeamento CSE 12400 na Etapa 12408 bloqueia a continuação da Etapa 12410 até a Etapa 12352 do MRP 12340. Após a continuação e operação da Etapa 12410, o Procedimento de investigação é chamado Fiscal/Regulatório (RTRP) 12360 para CKR 846 através da LOM 132 para produzir o Conhecimento de Responsabilidade Fiscal 12364 e o Conhecimento de Responsabilidade Normativa 12370 para o processamento do CSE 12400. A próxima etapa 12410 continua o fluxo lógico quando o Processamento Instantâneo RTRP 12360. A conclusão do Processamento Instantâneo RTRP 12360 é definida como a conclusão da Etapa 12374, onde/quando informações iniciais não confirmadas são armazenadas no CKR 648. As etapas 12376 e 12378 posteriormente no RTRP 12360 são consideradas processamento pósinstante. Portanto, o gerenciamento de encadeamento CSE 12400 na Etapa 12412 bloqueia a continuação da Etapa 12414 até a Etapa 12374 do RTRP 12360. Após a continuação e operação da Etapa 12414, o Relatório de status é chamado Corporate (CSR) 12304 para CKR 84 6 através de LOM 132 para produzir resultados da API de status corporativo para o processamento CSE 12400. A próxima etapa 12410 continua o fluxo lógico quando o processamento instantâneo de CSR 12304 for concluído. O processamento do CSR 12304 é definido como o início do loop da Etapa 12288. Todas as operações do Loop da Etapa 12288 no CSR 12304 são consideradas
Petição 870200056145, de 06/05/2020, pág. 565/1737
563/754 processamento pós-instantâneo. Portanto, o gerenciamento de encadeamento CSE 12400 na Etapa 12416 bloqueia a continuação da Etapa 12422 até que a Etapa 12288 da CSR 12304 tenha sido iniciada.
[1019] A Fig. 1041 continua o fluxo lógico da Etapa 12416, que recebe informações do Procedimento de Investigação de Mercado (MRP) 12340, do Procedimento de Investigação Regulatória/Fiscal (RTRP) 12360 e do Relatório de Status Corporativo (CSR) 12304. Posteriormente, Na Etapa 12422, o Relatório de Status do Digital Exchange (DESR) 12418 é chamado para o CKR 648 através do LOM 132 para obter atualizações de informações dos Aplicativos da plataforma UBEC 100 da Troca Econômica Digital por Criptografia (CDEE) 705. A etapa 12424 continua o fluxo lógico após a conclusão do processamento instantâneo do DESR 12418. Posteriormente, a etapa 12426 interrompe a lógica de execução até que uma condição de execução seja atendida. Essa condição é definida como quando MRP 12340, RTRP 12360, CSR 12304 e DESR 12418 concluiram suas operações lógicas de execução de processamento a longo prazo. Isso se correlaciona com a saída modular final uma da outra, o conhecimento confirmado, enviado à CKR 648.
[1020] A Fig. 1042 continua o fluxo lógico da Etapa 12426. Uma relação denominada magnitude X é definida na Política de codificação estática (SHP) 488 é levada em consideração na verificação de condição da Etapa 12426. Portanto, se a magnitude X é de maior valor, a Etapa 12426 levará exponencialmente mais tempo para atingir sua ativação de condição. A correlação inversa é aplicada. Se a execução instantânea da Etapa 12426 indicar uma
Petição 870200056145, de 06/05/2020, pág. 566/1737
564/754 resposta No 12430 à verificação da condição, a Etapa 12432 será ativada, parando a execução do CSE 12400 por um período Y, definido na SHP 488. Após o tempo Y decorrido, a Etapa 12426 é executada novamente como uma tentativa subsequente de obter uma resposta Sim 12428. Uma resposta Sim 12428 à Etapa 12426 indica que o gatilho da condição foi atendido na Etapa 12426. Por Portanto, é executado o Estágio 12434, que produz Conhecimento da Atividade de Mercado 12348 da CKR 648. Posteriormente, o Estágio 12436 processou uma lógica semelhante ao Estágio 12434, que produz o Conhecimento de Responsabilidade Fiscal 12368. Conhecimento da Atividade de Mercado 12348 e Consciência de responsabilidade fiscal 12368 continuam no estágio 12402. O estágio 12402 é uma operação em larga escala que invoca LOM 132 e CTMP 124 para produzir o resultado Fim do CSE 12400: Configuração ideal de decisão de investimento 12404. A etapa 12402 recebe as circunstâncias alvo de investimento 12160 como entrada, pois é a principal entrada modular no CSE 12400 que fornece a Interpretação das circunstâncias alvo de investimento (TICI) 12380.
[1021] A Fig. 1043 ilustra a mesma lógica da Fig. 1042, mas com os detalhes adicionais das etapas 12440 e 12442 que são executadas antes da etapa 12402. A etapa 12440 produz a Declaração de responsabilidade regulamentar CKR 648 12370 e a envia para a etapa 12402. A etapa 12442 produz o 648 Conhecimento de Operações Corporativas CKR 12444 e o envia para a etapa 12402. Isso facilita a operação de instâncias invocadas do LOM 132 e CTMP 124 através da etapa 12402 para produzir a decisão de decisão de Investimento Ideal 12404. Embora o CSE 12400 seja o módulo
Petição 870200056145, de 06/05/2020, pág. 567/1737
565/754 principal da NMC, o Estágio 12402 é o contêiner central de operações do CSE 12400, com entradas e saídas terminais das Circunstâncias de Investimento Alvo 12160 e Configuração de Decisão de Investimento Ideal 12404, respectivamente.
[1022] A Fig. 1044 mostra detalhes relacionados à Etapa 12434 do CSE 12400, em que o LOM 132 produz Conhecimento da Atividade de Mercado 12348 a partir do CKR 648. O LOM 132 é chamado para produzir esse Conhecimento 12348 pelo Módulo 12446 do NMC Invocar Mensagem de Conhecimento (NKIP). O conhecimento da atividade de mercado 12348 é ilustrado como construído a partir de várias instâncias de clusters UKF C854F. O Elemento de Cluster Individual (UKF) C854F é elaborado em detalhes como consistindo nas subunidades UKF1, UKF2 e UKF3 que são armazenadas no formato de sintaxe da regra C538.
[1023] A Fig. 1045 mostra detalhes sobre a Etapa 12436 do CSE 12400, em que o LOM 132 produz Conhecimento de Responsabilidade Fiscal 12368 a partir do CKR 648. O LOM 132 é invocado para produzir esse Conhecimento 12368 pela Mensagem de Invocação de Conhecimento (NKIP) 12446 da NMC. O Reconhecimento de atividade fiscal 12368 é ilustrado como construído com várias instâncias de cluster UKF C854F. O Elemento de Cluster Individual UKF C854F é elaborado em detalhes como feito das subunidades UKF1, UKF2 e UKF3 que são armazenadas no Formato de Sintaxe da Regra C538.
[1024] A Fig. 1046 mostra detalhes sobre a Etapa 12440 do CSE 12400, onde o LOM 132 produz o Conhecimento de Responsabilidade Normativa 12370 do CKR 648. O LOM 132 é invocado para produzir esse Conhecimento 12370 pela Mensagem de Invocação
Petição 870200056145, de 06/05/2020, pág. 568/1737
566/754 de Conhecimento do NMC (NKIP) 12446. 0 Conhecimento de responsabilidade regulatória 12370 é ilustrado como construído a partir de várias instâncias de clusters UKF C854F. O Elemento de Cluster Individual UKF C854F é elaborado em detalhes como feito das subunidades UKF1, UKF2 e UKF3 que são armazenadas no Formato de Sintaxe da Regra C538.
[1025] A Fig. 1047 mostra detalhes sobre a Etapa 12442 do CSE 12400, onde o LOM 132 produz o Conhecimento de Operações Corporativas 12444 a partir do CKR 648. O LOM 132 é invocado para produzir esse Conhecimento 12444 pela Mensagem de Invocação de Conhecimento do NMC (NKIP) 12446. O Conhecimento de Operações Corporativas 12370 é ilustrado como construído com várias instâncias de cluster UKF C854F. O Elemento de Cluster Individual UKF C854F é elaborado em detalhes como feito das subunidades UKF1, UKF2 e UKF3 que são armazenadas no Formato de Sintaxe da Regra C538.
[1026] A Fig. 1048 mostra o procedimento operacional interno do LOM 132 e CTMP 124 em relação ao Estágio 12402 do CSE 12400. As circunstâncias alvo de investimento 12160 são fornecidas como entrada inicial do Aviso de chamada de configuração idealística (ICIP) 12403. ICIP 12403 produz uma mensagem 12448 que interage diretamente com o LOM 132 para invocar a produção da definição ideal de decisão de investimento 12404, levando em consideração os critérios de entrada das circunstâncias objetivas de investimento 12160. A mensagem 12448 produzida pelo ICIP 12403 é enviada ao módulo de raciocínio C802A de Consultas Iniciais (IQR) do LOM 132. Quando um usuário do UBEC 106 invoca diretamente o LOM 132 diretamente na plataforma 100
Petição 870200056145, de 06/05/2020, pág. 569/1737
567/754 do UBEC, o IQR C802A recebe a pergunta/asserção inicial fornecida pelo usuário do UBEC 106. No entanto, esta instância do LOM 132 é chamada automaticamente pelo ICIP 12403. A Mensagem fornecida 12448 é analisada chamando Retenção central de conhecimento (CKR) 648 para decifrar os detalhes ausentes da mensagem 12448 que são cruciais para concluir o entendimento virtual correto pelo LOM 132 do LOM 132 para que o LOM 132 atenda/responda totalmente à mensagem 12448. Os detalhes ausentes resultantes produzidos pelo IQR C802A são enviados como entrada modular para o Esclarecimento da Pesquisa (SC) C803A. O SC C803A se engaja com a origem da Mensagem 12448 para recuperar informações suplementares, para que a Mensagem 12448 possa ser analisada objetivamente e em todo o contexto necessário. Quando um Usuário da UBEC 106 invoca diretamente o LOM 132 diretamente na Plataforma UBEC 100, o SC
C803A se envolve com esse Usuário 106 como a origem da
pergunta/resposta. No entanto, essa instância do LOM 132 é
automaticamente chamada pelo ICIP 12403 portanto, o SC C803A se
envolve com o ICIP 12403 para recuperar informações suplementares
sobre a Mensagem 12448. A versão totalmente formada e refinada da Mensagem 12448 é produzida a partir de SC C803A e é apresentada como uma entrada modular para Construção de Asserção (AC) C808A. O AC C808A tenta formar uma resposta consistente à Mensagem 12448, consultando o CKR 648 diretamente e através do Mapeamento Hierárquico (HM) C807A. O Apelo Racional (RA) C811A é um módulo de contêiner que hospeda uma interface de fluxo lógico com o CTMP 124. O RA C811A usa o CTMP 124 para criticar reivindicações. Tais criticas podem ter a forma de autocrítica (criticar o resultado do AC C808A) ou crítica externa da origem da pergunta/declaração
Petição 870200056145, de 06/05/2020, pág. 570/1737
568/754 processada pelo IQR C802A (Usuário da UBEC 106 ou ICIP 12403). Se uma afirmação produzida a partir do AC C808A falhar, uma medida significativa do teste de autocrítica processada pelo RA C811A; uma nova instância do AC C808A é então chamada para dar conta de qualquer crítica válida. Se o AC C808A produz uma declaração de alta confiança, ele passa constantemente nos testes de autocrítica processados pelo RA C811A; a afirmação ocorre como saída modular LOM 132, referida como a Decisão de investimento de Ajuste Ideal 12404 no contexto do Aviso inicial 12448 fornecido pelo ICIP 12403.
[1027] A Fig. 1049 mostra mais detalhes do procedimento de operação interna do LOM 132 da Aprovação Racional (RA) referente à etapa 12402 do CSE 12400. A Aprovação da Construção (AC) C808A fornece um envio de resposta C843 ao Apelo Racional (RA) C811A na afirmação produzida pela AC C808A em relação ao pedido de entrada correspondente 12448. Nesta fase do fluxo lógico, a afirmação produzida é classificada como uma Decisão Pré-Crítica C847. Isso indica que ele ainda não foi processado pelas críticas do CTMP 124. Portanto, a asserção produzida é enviada diretamente à instância do CTMP 124 como uma entrada Opinião subjetiva' do C848 e à Construção de Contexto (CC) C817A que fornece a entrada de Fato Alvo do C850 para o CTMP 124. CC C817A refere-se aos metadados do AC C808A e a evidência potencial fornecida pelo ICIP 12403 para apresentar fatos cruciais ao CTMP 124 para o pensamento crítico. Esses metadados de entrada são representados pelo arquivo Agregado de Registro de LOM 5502. O Agregado de Registro de LOM 5502 contém uma coleção de arquivos de Registro relevantes que são produzidos
Petição 870200056145, de 06/05/2020, pág. 571/1737
569/754 a partir das principais funções operacionais do LOM 132. Após a instância CTMP 124 conclui sua operação, uma Decisão Pós-Critica C851 é produzida como uma saída modular. A decisão pré-crítica inicial C847 e a decisão pós-crítica C851 são enviadas ao módulo de comparação de decisão (DC) C818A, que determina a extensão da sobreposição potencial entre as duas entradas C847 e C851. A saída unificada fornecida pelo DC 818A pode indicar CTMP 124 Grant C852 (incorreto) em nome da declaração de produção do AC C808A ou um aprimoramento percebido no C853 em nome da declaração de produção do AC C808A. As respostas argumentativas C852 e C853 podem ser classificadas como Resultados de baixa confiança C845 ou Resultados de alta confiança C846. Um resultado de baixa confiança do C845 indica que a reivindicação original produzida pelo AC C808A é falha e precisa ser reconstruída; portanto, o fluxo lógico continua para uma nova instância do AC C808A. Um resultado de alta confiança C846 indica que a declaração original produzida pela AC C808A tem mérito; portanto, as conclusões tiradas (juntamente com qualquer evidência, premissa, etc.) correspondentes são enviadas para a validação de conhecimento (KV) C805A. Portanto, o fluxo lógico continua para uma nova instância do KV C805A, para que o CKR 846 e, portanto, o LOM 132 possam se beneficiar da reivindicação recém-processada.
[1028] A Fig. 1050 continua o fluxo lógico da Etapa 12402 do CSE 12400 para ilustrar a produção do arquivo Agregado de Registro de LOM 5502. As saídas modulares produzidas a partir do Raciocínio Inicial da Consulta (IQR) C802A, Clarificação de pesquisa (SC) C803A, Construção de Afirmações (AC) C808A, Mapeamento de Hierarquia (HM) C807A e Validação de Conhecimento
Petição 870200056145, de 06/05/2020, pág. 572/1737
570/754 (KV) C805A são enviados para o Módulo 5500 da Coleção de Registros Modulares da LOM (LMLC). Portanto, o LMLC 5500 combina os dados do Registro de entrada em um único arquivo legível conhecido como Agregado de Registro de LOM 5502. O arquivo 5502 cobre o status operacional geral da instância correspondente do LOM 132, fornecendo informações sobre como a instância do LOM 132 chegou a várias conclusões. O Agregado de Registro de LOM 5502é enviado para o CC C817A Apelo Racional (RA) C811A.
[1029] A Fig. 1051 expande os detalhes operacionais relacionados à Fig. 1049 para ilustrar o funcionamento interno do CTMP 124 em relação aos canais de entrada e saída definidos no Apelo Racional (RA) C811A. A decisão pré-crítica C847 apresenta C843 como a aprovação modular de Saída de Construção (AC) C808A. A decisão C847 é marcada como uma Opinião Subjetiva C848, cumprindo assim uma das duas principais entradas do CTMP 124. A Opinião Subjetiva C848 é enviada aos Sistemas de Entrada de Metadados C484, que atua como a principal entrada modular do CTMP 124 e Representação interna do algoritmo de correspondência de padrões selecionados (SPMA) . Para esta configuração de instância; o SPMA é LOM 132. Os sistemas de entrada de metadados C484 são enviados para processamento no C456 Processamento de Razões e Produção de Percepção Bruta (RP 2) C465. O Processamento de Motivos C456 entenderá logicamente as reivindicações feitas ao comparar atributos de propriedade. O RP 2 C465 analisa os sistemas de entrada de metadados do LOM 132 C484 para produzir uma percepção no formato de percepção complexo (PCF) que representa a percepção algorítmica do LOM 132. Essa percepção produzida é enviada ao emulador de percepção de observação (POE)
Petição 870200056145, de 06/05/2020, pág. 573/1737
571/754
C475 que emula a percepção algorítmica do LOM 132. 0 Motivo de Processamento C456 chama as Regras de processamento que finalmente produzem conjuntos de regras que refletem o algoritmo SPMA que, neste caso, é o LOM 132. Portanto, dois modos de 'pensamento' são executados, percepção 'analógica' e processamento de conjunto de regras 'digital'. Esses dois ramos 0461 e 0475 representam semelhanças com intuição e lógica. Os resultados produzidos pelos dois ramos do pensamento 0461 e 0475 são transferidos para a Saída de Decisão Crítica (CDO) C462, que avalia os elementos fundamentais de conflito ou corroboração entre os resultados. Encontrando uma grande magnitude de corroboração interna e uma baixa magnitude de conflito interno, o CTMP 124 fornece uma decisão binária de Aprovar ou Bloquear, com relação à Opinião Subjetiva Inicial C848, que é chamada de Resultado de Alta Confiança C846. Se houver uma baixa magnitude de corroboração interna e uma alta magnitude de conflito interno, o CTMP 124 apresenta um voto de não confiança que é chamado de Resultado de Baixa Confiança C845. Portanto, a saída resultante do CTMP 124 é considerada uma decisão pós-crítica C851.
[1030] A Fig. 1052 mostra mais detalhes sobre a invocação da Produção de Percepção Não Processada (RP 2) C465 no CTMP 124. 0 LOM 132 produz a Definição de Decisão de Investimento Ideal 12404 invocando a Aprovação de Construção (AC) C808A. Em seguida, a configuração 12404 é enviada para a etapa 5506 do RP2 C465, que descompacta os dados para produzir instâncias de um rastreamento de depuração C485 e rastreamento de algoritmo C486 nos sistemas de entrada de metadados C484 originários da instância AC correspondente C808A. 0 Rastreio de Depuração C485
Petição 870200056145, de 06/05/2020, pág. 574/1737
572/754 é um rastreamento de nível de codificação que fornece variáveis, funções, métodos e classes que são usadas juntamente com seu tipo e conteúdo de entrada e saída de variáveis correspondentes. A cadeia de chamada de função completa é fornecida (rastreamento de função: funções que chamam outras funções). 0 Rastreamento de Algoritmos C486 é um rastreamento no nível do software que fornece dados de segurança junto com a análise de algoritmos. A decisão de segurança resultante (aprovar/bloquear) é fornecida junto com um registro logístico de como chegou à Decisão C847. 0 peso apropriado é incluído para cada fator que contribuiu para produzir a Decisão C847. Posteriormente, o RP 2 C465 transfere os dados referentes ao resultado da percepção produzido para o Emulador Observador da Percepção (POE) 0475 para processamento.
[1031] A Fig. 1053 explica a operação da produção de percepção bruta 0465 (RP 2) a partir do CTMP 124. Inicialmente, a Etapa 5506 ocorre, como ocorre na Fig. 1052, para descompactar os dados para produzir instâncias de um rastreamento de depuração. 0 Rastreamento de algoritmo 0485 e 0486 nos sistemas de entrada de metadados 0484 originários da instância correspondente do AC C808A. Na etapa 5508, o Processamento Métrico C489 realiza engenharia reversa das variáveis LOM 132 para extrair as percepções da inteligência artificial exibida pelo LOM 132. Posteriormente, os Sistemas de entrada de metadados C484 processados na Etapa 5510 separam os metadados C484 em Relacionamentos significativos de segurança de causa-efeito por meio da Separação de metadados do sistema (SMS) C487. Como também indicado na Fig. 1052, o RP 2 C465 transfere os dados referentes ao resultado da percepção produzido para o Emulador Observador
Petição 870200056145, de 06/05/2020, pág. 575/1737
573/754 da Percepção (POE) 0475 para processamento.
[1032] A Fig. 1054 explica a operação do Emulador de percepção de observação (POE) 0475, inclui a relação da produção de percepção bruta (RP 2) 0465 relacionada ao armazenamento de percepção (PS) 0478. A operação do Processamento Métrico 0489 e Sistema de Separação de Metadados (SMS) 0487 leva à produção das percepções 5512/5514/5516 que são armazenadas no PS 0478. 0 resultado das percepções 5512/5514/5516 representa a resposta modular da LOM 132 para produzir a decisão de investimento ideal Fit 12404 através da aprovação de construção (AC) C808A. 0 RP 2 C465 produz um ponto de dados de formato variável comparável, que é alimentado pela Pesquisa de Armazenamento (SS) C480 como critério de pesquisa. Posteriormente, o SS C480 realiza uma pesquisa pelo PS C478 para encontrar correspondências com as percepções já existentes armazenadas no PS C478. Os resultados C716 da execução do SS C480 são produzidos, o que leva a um C718 Cálculo de Peso. Esse cálculo C718 tenta encontrar a distribuição correta das percepções correspondentes do PS C478 para replicar e corresponder ao formato de variável comparável que representa a execução do algoritmo LOM 132 que produz a Decisão Ideal para Investimento 12404.
[1033] A Fig. 1055 continua a lógica do Emulador de observação e percepção (POE) C475 da Fig. 1054. Após a produção dos resultados de pesquisa de armazenamento (SS) C716 C480, o cálculo de peso C718 é concluído para levar ao C729, aplicação das percepções 5512/5514/5516 para tomar uma decisão ativa para Aprovar C731 ou Bloquear C730. O Ajuste Ideal da Decisão de
Petição 870200056145, de 06/05/2020, pág. 576/1737
574/754
Investimento 12404 produzido pela LOM 132 e o Agregado de Registro de LOM 5502 correspondente estão sujeitos à Análise de Dados 0724 que leva a Registros de Dados 0723 Aprimorados que são executados no Aplicativo 0729 para obter uma Interpretação Dicotômica 5518 de um sentimento positivo (aprovar) 0731 ou sentimento negativo (bloquear) 0730 em relação à entrada 12404 da definição ideal de decisão de investimento. Após a conclusão bem-sucedida da execução do aplicativo 0729, ocorre uma ação corretiva de substituição 0476 que é processada através da Decisão de Saída Crítica (CDO) C462 em paralelo à saída modular da Execução de Regras (RE) C461. 0 módulo C474 de Densidade do conhecimento autocrítico (SCKD) estima o escopo e o tipo de conhecimento potencial desconhecido que está além do escopo do agregado de registro reportável do LOM 5502. Dessa maneira, as características subsequentes de pensamento crítico da instância de processamento do CTMP 124 podem tirar proveito do escopo potencial de todo o conhecimento envolvido, conhecido e desconhecido diretamente pela instância.
[1034] A Fig. 1056 mostra o processo da Memória Web C460 operando em paralelo com a execução do Emulador de Percepção de Observação (POE) C475 na Fig. 1055. A configuração ideal de decisão de investimento 12404 produzida pela LOM 132 é apresentada como uma entrada modular para o Motivo do Processamento C456. 0 Motivo do Processamento C456 processa como o LOM 132 alcançou a decisão de produzir o Ajuste 12404 em resposta ao Aviso 12448 fornecido pelo ICIP 12403. A conclusão do processamento do Motivo do Processamento 0456 é a execução do Motivo do Processamento 0457, que define as regras que são
Petição 870200056145, de 06/05/2020, pág. 577/1737
575/754 terceiro, consistente com o comportamento de execução do LOM 132. Se forem encontradas inconsistências no comportamento da regra em relação ao comportamento de execução da LOM 132, as regras existentes no momento serão modificadas ou novas regras serão adicionadas. Essas regras são usadas posteriormente na instância do CTMP 124 para criticar os comportamentos de tomada de decisão encontrados na instância correspondente do LOM 132. 0 Extensor de Escopo de Regras Críticas (RSFS) utiliza percepções conhecidas para expandir o escopo do pensamento crítico dos conjuntos de regras, aprimorando os conjuntos de regras para produzir as Regras Corretas C459. As Regras Corretas C459 são enviadas como entrada modular para a Separação do Formato da Sintaxe da Regra RSFS C499 da jurisdição de operação da memória da web C4 60. 0 RSFS C499 separa e organiza as regras C459 corretas por tipo. Portanto, todas as ações, propriedades, condições e objetos são listados separadamente após o processamento do RSFS C499. Isso permite que a instância do CTMP 124 discernir quais partes foram encontradas no campo caótico e quais não. A Análise de Campo Caótico (CFP) C535 combina e formata o Agregado de Registros de LOM 5502 em uma única unidade digitalizável referida como Campo Caótico. O campo Caótico é enviado como uma entrada modular para o reconhecimento de memória (MR) C501. O MR C501 também recebe as Regras originais C555, que são o resultado da execução do RSFS C499. O MR C501 varre o Campo Caótico fornecido pelo CFP C535 para reconhecer os conceitos conhecidos e definidos nas Regras Originais C555. Esta instância executada pela MR C501 produz Segmentos de Regra Reconhecidos C556. Posteriormente, o Analisador de conformidade de regras (REP) C498 recebe partes
Petição 870200056145, de 06/05/2020, pág. 578/1737
576/754 individuais das Regras originais C555 que foram rotuladas de acordo com seu reconhecimento ou falta delas dentro do campo caótico por MR C501. 0 RFP C498 pode deduzir logicamente qual conjunto de regras completo (a combinação de todas as suas partes) foi suficientemente reconhecido no Campo Caótico para garantir o processamento pela Execução de Regras (RE) C461. Após a conclusão bem-sucedida da execução do RE C461, ocorre uma Ação Corretiva de Substituição do C476, que é processada pela Decisão de Saída Crítica (CDO) C462 em paralelo à saída modular do Emulador de Observação e Percepção (POE) C475.
[1035] A Fig. 1057 desenvolve a interação do fluxo lógico entre a Percepção de Armazenamento (PS) C478 e o Mecanismo de Descoberta Automática de Percepção (APDM) C467. O PS C478 contém quatro subconjuntos de percepções: Ângulos de percepção desconhecidos seduzidos C473, Todos os ângulos de percepção C472, Ângulos de percepção implícitos C471 e Ângulos de percepção aplicados C470. Os ângulos de percepção aplicados C470 são percepções que foram importadas diretamente ao estudar o comportamento algorítmico do algoritmo de correspondência de padrões selecionados (SPMA), que neste caso é o LOM 132. Os ângulos de percepção implícitos 0471 são percepções derivadas dos ângulos de Percepção Aplicada 0470 por meio da execução modular de desvio de implicação (ID) 0477 e APDM 0467. Todos os ângulos de percepção 0472 representam o escopo completo das percepções conhecidas da instância do CTMP 124 que não foram incluídas pelos ângulos de percepção aplicados 0470 e pelos ângulos de percepção implícitos 0471. Os Ângulos de Percepção desconhecidos deduzidos 0473 representam o escopo de percepções
Petição 870200056145, de 06/05/2020, pág. 579/1737
577/754 que se espera que exista, mas a instância CTMP 124 ainda não foi descoberta de acordo com o módulo C474 da Densidade de conhecimento autocritico (SCKD). 0 ID C477 analisa as métricas individuais dos Ângulos de Percepção Aplicados C470 para derivar Ângulos de Percepção Implícitos C470 de uma certa maneira, enquanto o APDM C467 varia criativamente as Composições dos Ângulos de Percepção C650 através do Módulo de Criatividade 112 para produzir uma Nova Iteração C653 combinando os dois pesos iniciais de entrada C652. Portanto, todos os ângulos de percepção C650 envolvidos no processamento do C467 APDM correspondem e representam a configuração ideal de decisão de investimento 12404 produzida pelo módulo LOM C808A 132 Aprovação de construção (CA) .
[1036] A Fig. 1058 destaca os detalhes operacionais relacionados ao CTMP 124. O Extensor de Escopo de Regra Crítica (CRSE) C458. Uma instância de Avaliação Racional (RA) do C811A opera no LOM 132 e chama a Construção de Contexto (CC) C817A para processar o Agregado do registro do LOM 5502 à análise do Campo Caótico (CFP) C535. O CFP produz um campo caótico a partir da saída DC modular do C817A, referenciada pelo reconhecimento de memória (MR) C501. As regras atuais C534 exibem conjuntos de regras indicativas do estado atual de operação do algoritmo de correspondência de padrões selecionados (SPMA), que neste caso é o LOM 132. As regras atuais C534 são enviadas como entrada modular para a derivação de sintaxe da regra (RSD) C504, onde as regras lógicas 'preto e branco' se tornam insights baseados em métricas. Portanto, o arranjo complexo de várias regras se torna uma única percepção uniforme que é expressa por meio de várias métricas de gradiente variável. A saída modular RSD C504 é fornecida como
Petição 870200056145, de 06/05/2020, pág. 580/1737
578/754 uma entrada modular para a Correspondência de Percepção (PM) C503. Na PM C503, uma unidade de formato variável comparável (CVF) é formada a partir da percepção recebida do RSD C504. 0 CVF recém-formado é usado para procurar percepções relevantes na Percepção de Armazenamento (PS) C478 com indices semelhantes. As correspondências possíveis são enviadas como entrada modular para a Geração de Regras de Sintaxe (RSG) C505. 0 RSG C505 recebe percepções confirmadas anteriormente que são armazenadas no formato de percepção e acessam a composição métrica interna das percepções. As percepções são recebidas do PS C478, que contém as percepções confirmadas anteriormente C468. Essas medidas métricas baseadas em gradiente tornam-se conjuntos de regras binárias e lógicas que emulam o fluxo de informações de entrada/saída da percepção original. Portanto, o RSG C505 produz as Regras de percepção C537, que são percepções consideradas relevantes, populares e que se tornaram regras lógicas. Se uma Percepção (em seu Formato de Percepção original) tivesse muitos relacionamentos métricos complexos que definissem muitas 'áreas cinzas', as regras locais 'preto e branco' abrangeríam essas áreas 'cinza', expandindo a complexidade do conjunto de regras. Portanto, as regras perceptivas do C537 são armazenadas usando uma coleção de definições de formato de sintaxe da regra (RSF). As regras de percepção C537 são enviadas como uma entrada modular para o Reconhecimento de Memória (MR) C501, onde são digitalizadas no campo caótico produzido pelo CFP C535. Portanto, o MR C501 produz as Regras adicionais C536 que concluem as Regras corretas C533 e as validam.
[1037] A Fig. 1059 delineia os detalhes
Petição 870200056145, de 06/05/2020, pág. 581/1737
579/754 operacionais relacionados ao Bypass de Implicação (ID) C477 do CTMP 124. Os Ângulos de Percepção Aplicados C470 do Armazenamento de Percepção (PS) C478 são enviados como entrada modular para o ID C477 para produzir mais informações pertencentes a ângulos implícitos de percepção C471. Os ângulos de percepção aplicados do C470 são enviados especificamente para a combinação métrica ID C477 C493. A combinação métrica C493 separa os ângulos de percepção C650 recebidos em categorias de métricas: Faixa C739, Tipo C740, Consistência C741, Intensidade C742. A disponibilidade e referência de métricas no sistema não são necessariamente limitadas a esses quatro tipos. Os ângulos de entrada de percepção do C650 estão relacionados à configuração ideal de decisão de investimento 12404, produzida pelo módulo C808A do LOM 132 de Aprovação de Construção (AC). O Conjunto de Complexidade Métrica A C736 é enviado como uma entrada modular para a expansão métrica (ME) C495. Com o ME C495, as métricas de ângulo de percepção C650 múltiplas e variáveis são armazenadas categoricamente em bancos de dados individuais C739/C740/C741/C742. O ME C495 aprimora o lote atual de métricas recebidas com detalhes/complexidade extraídos de métricas conhecidas/encontradas anteriormente. Após a conclusão do aprimoramento e enriquecimento da complexidade, as métricas são retornadas como saída modular ME C495 como Complexidade Métrica B C737 e, em seguida, convertidas novamente nos Ângulos de Percepção C650 para armazenar nos Ângulos de Percepção Implícitos C471, conforme ilustrado na Fig. 1060.
[1038] A Fig. 1060 continua o fluxo lógico do Derivação de Implicação (ID) C477 da Fig. 1059, ilustrando o
Petição 870200056145, de 06/05/2020, pág. 582/1737
580/754
Conjunto de Complexidade Métrica C737 processado pela Conversão Métrica C494 que inverte as métricas individuais novamente em Ângulos de Percepção C650 completos. Apesar do processo de enriquecimento e conversão realizado pelo ID C477, os Ângulos de Percepção C650 resultantes ainda fornecem uma representação razoavelmente precisa da Configuração Ideal de Investimento 12404 produzida pelo módulo LOM 132 de Aprovação de Construção (AC) C808A. Portanto, o processo de conversão métrica C494 envia os ângulos de percepção C650 recém-derivados/implícitos para os ângulos de percepção implícitos C471 no armazenamento de percepção (PS) C478.
[1039] A Fig. 1061 detalha os detalhes operacionais relacionados ao CTMP 124. Saída de decisão crítica do C462 (CDO), o CDO C462 recebe saída modular dos dois principais ramos do CTMP 124: Emulador de observação e percepção (POE) C475 (como a intuição) e Execução das Regras (RE) C461 (como ramo lógico). Cada Filial C475/461 apresenta sua respectiva Decisão Crítica C521 (a principal saída modular), bem como os 'Meta-metadados' correspondentes para C521, que fornecem variáveis contextuais que justificam por que a decisão crítica inicial foi alcançada. Os conjuntos de decisões C521 que representam as percepções C516 da PO5 C475 e as regras de conformidade da RE C461 C517 são enviados ao Módulo de Categorização de Metadados (MCM) . O MCM C488 separa os rastreios de depuração e algoritmo em diferentes categorias usando a categorização de informações tradicional baseada em sintaxe. Essas categorias podem ser usadas para organizar e produzir respostas de segurança diferentes com uma correlação com riscos e problemas de segurança. A Decisão
Petição 870200056145, de 06/05/2020, pág. 583/1737
581/754
Intuitiva C514, que representa as Percepções C526 da POE C475, e a Decisão de Pensamento C515, que representa as Regras Cumpridas C517 de RE C461, são apresentadas pelo MCM C488 da Lógica de Processamento Interno 5520 da Comparação de Decisões de Gerenciamento (DDC) C512. A lógica de processamento interno DDC C512 5520 verifica a corroboração ou conflito entre a Decisão intuitiva C514 e a Decisão ponderada C515. O DDC C512 refere-se a uma variável 'cut' da Política Estática Codificada (SHP) 488. Se a variável 'cut' não for alcançada devido à semelhança entre a Decisão Intuitiva C514 e a Decisão de Pensamento C515 (ou seja, 90% +), ocorre o cancelamento de comparação direta 5524, o que podería levar o Controle de Saída do Terminal (TOC) C513 a enviar um voto de não confiança 5544, como mostrado na Fig. 1062. O estágio Cancelar comparação direta 5524 implica que o CTMP 124 não pôde atuar internamente de maneira consistente com relação ao Pedido de Entrada 12448 do ICIP 12403. Se a variável 'cutoff' foi suficientemente atendida de acordo com a Lógica de Processamento Interno 5520, o Estágio de Saída é chamado da Decisão Final 5522, que combina as Decisões C514/C515 em uma única saída modular que é recebida e processada pelo TOC C513.
[1040] A Fig. 1062 continua o fluxo lógico da Saída de Decisão Crítica (CDO) C462 da Fig. 1061 e elabora os detalhes operacionais do Controle de Saída do Terminal (TOC) C513. O TOC C513 inicia com a Solicitação 5526, que verifica se a Comparação Direta de Decisão (DDC) C512 foi capaz de fornecer a Saída Final de Decisão 5522 (em vez da diretiva de Comparação de Cancelamento Direta 5524). Se a resposta à Solicitação 5526 for Sim 5528, a decisão final combinada fornecida pelo DDC C512 na Saída de
Petição 870200056145, de 06/05/2020, pág. 584/1737
582/754
Decisão Final 552 será apresentada como saida modular do TOC C513 e, portanto, como saida modular de toda a instância do CTMP. 124 como Saida final de decisão critica 5542. Se a resposta à Solicitação 5526 for No 5530, a Etapa 5532 será chamada, o que invoca a execução da Correspondência de Percepção (PM) 5532 e obtém os resultados correspondentes. As Regras Cumpridas C517 são extraídas da Decisão Crítica + Meta-metadados C521 da Execução das Regras (RE) C461. As regras C517 tornam-se percepções por derivação de sintaxe de regras (RSD) C504. O PM 5532, em seguida, faz referência a meta-metadados para determinar, na solicitação 5534, se houve forte sobreposição interna e corroboração das percepções usadas. Se a resposta à Solicitação 5534 for Sim 5538, isso indica um Voto de ausência de confiança 5544 em nome do CTMP 124 como uma saída modular. Se a resposta à Solicitação 5534 for No 5536, a Etapa 5540 será ativada, que seleciona a decisão de menor risco percebida entre a Decisão Intuitiva C514 e a Decisão Pensante C515. Portanto, a Decisão Crítica Final 5542 é subsequentemente apresentada como saída modular para CDO C462, TOC C513 e CTMP 124. A lógica na Etapa 5534 ocorre para determinar se a falta de unidade entre a Decisão Intuitiva C514 e a Decisão de Pensamento C515. Isso ocorre devido a uma falta geral de confiança algorítmica ou devido a visões altamente opostas entre os dois. Portanto, se este último ocorrer, uma possível Decisão Crítica Final 5542 ainda é discernível como uma saída modular. Um Voto de Não Confiança 5544 sempre leva ao caminho lógico do Resultado de Baixa Confiança C845 na Aprovação Racional (RA) C811A. A Decisão Crítica Final 5542 pode levar a um caminho lógico de Resultado
Petição 870200056145, de 06/05/2020, pág. 585/1737
583/754 de Alta Confiança C846 ou Resultado de Baixa Confiança C845 dentro do RA C811A, dependendo da confiança algorítmica por trás da Decisão Crítica Final 5542.
[1041] A Fig. 1063 continua a lógica sumária do CSE 12400 das Figs. 1042 e 1043. A funcionalidade do núcleo CSE 12400 como um algoritmo reside na Etapa 12402; onde são feitas as principais invocações do LOM 132 e CTMP 124. A execução completa da Etapa 12402 produz a Decisão ideal de decisão de investimento 12404. Posteriormente, a Configuração 12404 é enviada para o Estágio 12450, onde é testado quanto a estresse e ajustado através do I2GE 122. O estágio 12450 chama o I2GE 122 para gerar várias vias evolutivas que simulam o desempenho da Decisão Ideal de Ajuste de Investimento 12404 em um ambiente definido pelas variáveis: Conhecimento de Responsabilidade Fiscal 12368, Conhecimento de Atividade de Mercado 12348, Conhecimento de conformidade regulatória 12370 e Conhecimento de operações corporativas 12444. Os resultados da operação do Estágio 12450 são enviados para a Solicitação 12452, que discerne se o Ajuste Ideal da Decisão de Investimento 12404 pode passar nos requisitos de estabilidade definidos no Política Estática Codificada (SHP) 488. As duas respostas possíveis à Solicitação 12452 são que a Configuração Ideal de Decisão do investimento 12404 é 12454 suficientemente estável ou 12456 não é suficientemente estável. A resposta 12454 suficientemente estável leva à produção final da definição de decisão de investimento refinado 12458 como uma saída modular para o CSE 12400.
[1042] A Fig. 1064 explica a operação do Estágio 12450 do CSE 12400. Inicialmente, o Estágio 12460 é executado,
Petição 870200056145, de 06/05/2020, pág. 586/1737
584/754 invocando o LIZARD 120 para converter as Circunstâncias de Investimento Alvo 12160 em um Mapa de Hierarquia de Finalidades 12462. O Mapa 12462 é posteriormente encaminhado para Etapa 12464; que cria uma declaração de status holistico em branco 12466. O estado 12466 é praticamente um clone do Mapa 12464 neste estágio 12464 do fluxo lógico, que é mais tarde referido como uma única variável para encapsular todo o intervalo de variáveis que definem o 'ambiente' para o qual a decisão de investimento de Ajuste Ideal 12458 é medido em relação ao I2GE 122. Na Etapa 12468, o LIZARD 120 é chamado para converter o Conhecimento da Atividade de Mercado 12348 em um Mapa de Hierarquia de Propósito 12472. Na Etapa 12470, o LIZARD 120 é chamado converter o conhecimento de responsabilidade fiscal 12368 em um mapa de hierarquia de finalidades 12474.
[1043] O elemento C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite a operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem, a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a Política de Segurança e os Objetivos da Empresa. Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1044] Fig. 1066 continua o fluxo lógico da Fig. 1065 para ilustrar a operação do LIZARD 120 para converter as Circunstâncias de Investimento Alvo 12160 em um Mapa de
Petição 870200056145, de 06/05/2020, pág. 587/1737
585/754
Hierarquia de Propósito 12462.
[1045] A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula através de todas as funções interconectadas para produzir uma definição de propósito interpretada consultando Associações de Propósito C326. A saída de definição de propósito existe no Formato de Propósito Complexo C325, que é enviado como saída modular para PM C36 e, portanto, o Núcleo Exterior (OC) C329 e, o LIZARD 120. A saída é rotulada como um Mapa de Hierarquia de Propósito 12462, que é apresentada como a versão do Formato de Propósito Complexo C325 das Circunstâncias de Investimento Alvo 12160. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às funções e módulos mencionados acima.
[1046] A Fig. 1067 mostra detalhes sobre a operação do LIZARD 120 para converter o Conhecimento da Atividade de Mercado 12348 em. um. Mapa de Hierarquia de Propósitos 12472. O Conhecimento da Atividade de Mercado 12348 é enviado ao Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. 0 SM C35 fornece uma estrutura para leitura e gravação de código de computador. Para escrever códigos; recebe o Formato de Propósito Complexo C325 do Módulo de Propósito (PM) C36. O Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecida como ’pseudocódigo’. O pseudocódigo contém implementações básicas das operações de computação que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Depois, uma.
Petição 870200056145, de 06/05/2020, pág. 588/1737
586/754 função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação de alvo desejada (linguagem de computador) . Para ler códigos; o SM C35 oferece uma interpretação sintática do código de computador para o PM C36 para derivar um propósito para a funcionalidade de tal código. 0 Conhecimento da Atividade de Mercado 12348 é recebido no formato Sintaxe de Conhecimento 5620 pela Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pelo SM C35 em qualquer linguagem de computação conhecida e selecionada. A Conversão de Código C321 também executa a função inversa de converter linguagens de computação conhecidas em. tipos de sintaxe arbitrários. A saída da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas, de acordo com as definições das Regras e Sintaxe C322. Portanto, depois da execução completa da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída, modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para derivar uma Propósito no Formato de Propósito Complexo C325 do código do computador. Essa definição de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme interpretada pelo SM C35. O PM C36 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A Interpretação Iterativa C328 circula através de todas as funções
Petição 870200056145, de 06/05/2020, pág. 589/1737
587/754 interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325) , consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a
área do LIZARD 120 que não passa por manutenção automática/ auto
programação e e dir eta e e x c1u sivame n t e programada por
especialistas i j. d área relevante 0 elemento C 3 35 do IC C3 33
contém Estrutur as e Bib liotecas Ϊ fundamentais, Sc iripts de Ge stão
de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite as operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas padronizadas e scripts que permitem a funcionalidade básica. 0 elemento Objetivos do Sistema C336 do IC C333 define a Diretiva de Segurança e as Metas Corporativas. Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1047] A Fig. 1068 continua o fluxo lógico da Fig. 1067 para ilustrar a operação do LIZARD 120 para converter o Conhecimento da Atividade de Mercado 12348 em um Mapa de Hierarquia de Propósito 12472. A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saida para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula através de todas as funções interconectadas para produzir uma definição de propósito interpretada por referência às Associações de Propósito C326. A saida de definição de propósito existe no Formato de Propósito Complexo C325, que é enviado como saida modular para o PM C36 e, portanto, o Núcleo Exterior (OC) C329 e, então, o LIZARD 120. A
Petição 870200056145, de 06/05/2020, pág. 590/1737
588/754 saída é rotulada como um Mapa de Hierarquia de Propósito 12472, que é apresentado como a versão do Formato de Propósito Complexo C325 do Conhecimento da Atividade de Mercado 12348. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às funções e módulos mencionados acima.
[1048] A Fig. 10 69 continua o fluxo lógico do Estágio 12450 do CSE 12400. A lógica contínua da Fig. 1064 e é retomada no Estágio 12470, que produz um Mapa de Hierarquia de Propósito 12474 do Conhecimento de Responsabilidade Fiscal 12368. No Estágio 12476, o LIZARD 120 é invocado para converter o Conhecimento de Conformidade Regulatória 12370 para um Mapa de Hierarquia de Propósito 12478. No Estágio 12480, o LIZARD 120 é invocado para converter o Conhecimento de Operações Corporativas 1244 em um Mapa de Hierarquia de Propósitos 12482. Posteriormente, é executado o Estágio 12484, que invoca o Processamento de Simetria de Propósito para o Propósito (P2SP) 7000 para processar o Estado de Situação Holística 12466 e o Mapa de Hierarquia de Propósito 12472 do Conhecimento da Atividade de Mercado 12348. Neste Estágio 12484; o Estado de Situação Holística 12466 contém o conteúdo equivalente do Mapa de Hierarquia de Propósito 12462 das Circunstâncias de Investimento Alvo 12160. A execução do P2SP 7000 produz uma medida de compatibilidade/congruência das duas variáveis de entrada.
[1049] A Fig. 1070 mostra detalhes sobre a operação do LIZARD 120 para, converter o Conhecimento de Responsabilidade Fiscal 12368 em um Mapa de Hierarquia de Propósito 12474. Conhecimento de Responsabilidade Fiscal é enviado ao Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior
Petição 870200056145, de 06/05/2020, pág. 591/1737
589/754 (OC) C329. O SM C35 fornece uma estrutura para leitura e escrita de código de computador. Para escrever código, ele recebe o Formato de Propósito Complexo C325 do Módulo de Propósito (PM) C36. 0 Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecida como 'pseudocódigo*. 0 pseudocódigo contém, implementações básicas das operações de computação que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Posteriormente, uma função auxiliar converte o pseudocódigo em código real executável, dependendo da sintaxe de computação alvo desejada (linguagem de computador). Para leitura de código; 0 SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar um propósito para a funcionalidade desse código. 0 Conhecimento de Responsabilidade Fiscal 12368 é recebido no formato Sintaxe de Conhecimento 5620 pela Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pelo SM C35 em qualquer linguagem de computação conhecida e escolhida. A Conversão de Código C321 também executa, a função inversa de traduzir linguagens de computação conhecidas em tipos de sintaxe arbitrários. A salda da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas mais simples para produzir um. mapa de funções interconectadas, de acordo com as definições das Regras e Sintaxe C322. Portanto, depois da execução concluída da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada, para a Interpretação Iterativa C328
Petição 870200056145, de 06/05/2020, pág. 592/1737
590/754 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para derivar uma Propósito no Formato de Propósito Complexo C325 do código do computador. Essa definição de Propósito descreve adequadamente o propósito pretendido da seção de código relevante, conforme interpretada por SM C35. O PM C36 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A Interpretação Iterativa C328 circula através de todas as funções interconectadas para produzir uma definição de propósito interpretado (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. O Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção automática/autoprogramação e é direta e exclusivamente programada por especialistas na área relevante. O elemento C335 do IC C333 contém. Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a Política de Segurança e Objetivos da Empresa. Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1050] A Fig. 1071 continua o fluxo lógico da Fig.
1070 para ilustrar a operação do LIZARD 120 para converter o
Conhecimento de Responsabilidade Fiscal 123 68 em. um. Mapa de
Hierarquia de Propósito 12474.
A Redução Lógica C323 do Módulo
Petição 870200056145, de 06/05/2020, pág. 593/1737
591/754 de Sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula através de todas as funções interconectadas para produzir uma definição de propósito interpretada consultando Associações de Propósito C326. A saída de definição de propósito existe no Formato de Propósito Complexo C325, que é enviado como saída modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e, para o LIZARD 120. A saída é rotulada como um Mapa de Hierarquia de Propósito 12474, que é apresentada como a versão do Formato de Propósito Complexo C325 do Conhecimento de Responsabilidade Fiscal 12368. A mesma definição e aplicação do Núcleo Interno (IC) C333 aplica-se às funções e módulos mencionados acima.
[1051] A Fig. 1072 mostra detalhes da operação do LIZARD 120 para converter o Conhecimento de Conformidade Regulatória 12370 em um Mapa de Hierarquia, de Propósitos 12478. O Conhecimento de Conformidade Regulatória 12370 é enviado ao Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura, e escrita de código de computador. Para escrever código; ele recebe o Formato de Propósito Complexo C325 do Módulo de Propósito (PM) C36. O Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecido como 'pseudocódigo'' . O pseudocódigo contém, implementações básicas das operações de computação que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Posteriormente, uma função auxiliar converte o pseudocódigo em.
código executável real, dependendo da sintaxe de computação alvo
Petição 870200056145, de 06/05/2020, pág. 594/1737
592/754 desejada (linguagem de computador). Para leitura de código; 0 SM C35 fornece uma interpretação sintática do código do computador para o PM C3 6 para derivar um. proposito para a funcionalidade desse código. 0 Conhecimento de Conformidade Regulatória 12370 é recebido no formato Sintaxe de Conhecimento 5620 pela Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e compreendido pela SM C35 em qualquer linguagem de computação conhecido e selecionado. A Conversão de Código C321 também executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saida da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A. Redução Lógica C323 reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas, segundo as definições de Regras e Sintaxe C322. Portanto, depois da execução completa da Redução Lógica C323, a execução da instância, correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para derivar uma. Propósito no Formato de Propósito Complexo C325 do código do computador. Esta definição do propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada pelo SM C35. O PM C36 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. O Núcleo Interno
Petição 870200056145, de 06/05/2020, pág. 595/1737
593/754 (TC) C333 é a área do LIZARD 120 que não passa por manutenção automática/autoprogramação e é direta e exclusivamente programada, por especialistas na área relevante. O elemento C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite operação e funcionalidade gerais para o SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define Diretiva de Segurança e Metas Corporativas. Essas definições operam, como variáveis de política estática para orientar algumas funções dinâmicas e estáticas do LIZARD 120.
[1052] A Fig. 1073 continua o fluxo lógico da Fig. 1072 para ilustrar a operação do LIZARD 120 para converter o Conhecimento de Conformidade Regulatória 12370 em um Mapa de Hierarquia de Propósito 12478. A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula em todas as funções interconectadas para produzir uma definição de propósito interpretado, pela consulta das Associações de Propósito C326. A saída de definição de Propósito existe no Formato de Propósito Complexo C325, é enviado como saída modular para PM C3 6 e, portanto, para o Núcleo Exterior (OC) C329 e, o LIZARD 120. A saída é rotulada, como um Mapa de Hierarquia de Propósito 12478, que é apresentado como a versão do Formato de Propósito Complexo C325 do Conhecimento de Conformidade Regulatória 12370. A mesma, definição e aplicação do
Petição 870200056145, de 06/05/2020, pág. 596/1737
594/754
Núcleo Interno (IC) C333 aplica-se às funções e módulos mencionados acima.
[1053] A Fig. 1074 mostra detalhes sobre a operação do LIZA^RD 120 para converter o Conhecimento de Operações Corporativas 12444 em um Mapa de Hierarquia de Propósito 12482. O Conhecimento de Operações Corporativas 12444 é enviado ao Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura e escrita do código do computador. Para escrever código; ele recebe o Formato de Propósito Complexo C325 do Módulo de Propósito (PM) C36. O Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém implementações básicas das operações de computação mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Posteriormente, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação alvo desejada (linguagem de computador) . Para leitura de código; O SM C35 fornece uma interpretação sintática do código do computador para.
o PM C36 para derivar um propósito para a funcionalidade desse código. O Conhecimento de Conformidade Regulatória 12370 é recebido no formato Sintaxe de Conhecimento 5620 pela conversão do código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e compreendido pela SM C35 em qualquer linguagem de computação conhecido e selecionado. A. Conversão de Código C321 também executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saida da execução concluída da Conversão de Código
Petição 870200056145, de 06/05/2020, pág. 597/1737
595/754
C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas, segundo as definições de Regras e Sintaxe C322. Portanto, depois da execução completa da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de
Propósito (PM) C3 6 . 0 PM C3 6 usa o SM C35 para derivar uma
Prop ó s i t ο η o F 'orma to c le P ropós ito Complt 2XO C32 5 do código do
computador. Ess ;a de finição de pr opósito ds !SCI ?eve adequadamente a
funcionalidade pret endida c ia seç ão de códi .go relevante, conforme
é interpretada por SM C35.
[1054] O PM C3 6 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A Interpretação Iterativa C328 circula em. todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. O Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa, por manutenção automatizada/autoprogramação e é programada direta e exclusivamente por especialistas na área relevante. O elemento C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite operação e funcionalidade gerais para o SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem, a funcionalidade básica. O elemento Objetivos do Sistema C336 do
Petição 870200056145, de 06/05/2020, pág. 598/1737
596/754
IC C333 define Diretiva de Segurança e Metas Corporativas. Essas definições operam como variáveis de política estática para orientar algumas funções dinâmicas e estáticas do LIZARD 120.
[1055] A Fig. 1075 continua o fluxo lógico da Fig. 1074 para ilustrar a operação do LIZARD 120 para converter o Conhecimento de Operações Corporativas 12444 em um Mapa de Hierarquia de Propósito 12482.
[1056] A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa. C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula em todas as funções interconectadas para produzir uma definição de propósito interpretado, pela consulta das Associações de Propósito C326. A saída de definição de Propósito existe no Formato de Propósito Complexo C325, é enviado como saída modular para PM C3 6 e, portanto, para o Núcleo Exterior (OC) C329 e, o LIZARD 120. A saída é rotulada, como um Mapa de Hierarquia de Propósito 12478, que é apresentada como a versão do Formato de Propósito Complexo C325 do Conhecimento de
Operações Corpora tiva s 12444 . A mesma definição e ap licação do
Núcleo Interno (IC) C33 3 aplica-se às funções e módulos
mencionados acima
[1057] Fig. 1076 continua o fluxo lógico do
Estágio 12450 do CSE 12400. A lógica contínua da Fig 1 0 6 9 e é
retomada no Estágio 12484. O Estágio 12484 invoca o P2SP 7000 para produzir um Resultado de Processamento de Simetria 12486, que corresponde às duas entradas Estado de Situação Holística 12466 e ao Mapa da Hierarquia de Propósito 12472 do Conhecimento da Atividade de Mercado 12348. O Resultado do Processamento de
Petição 870200056145, de 06/05/2020, pág. 599/1737
597/754
Simetria 12486 é enviado ao Prompt 12488, que avalia se o Mapa de Hierarquia de Propósito 12472 do Conhecimento da Atividade de Mercado 12348 é congruente/compatível com. o Estado de Situação Holistica 12466. 0 resultado esperado pelo sistema é que eles são congruentes, porque as variáveis definidas nas Circunstâncias Alvo de Investimento 12160 não devem conter incompatibilidades com o Conhecimento em Atividade de Mercado 12348. As
Circunstâncias de Investimento Alvo 12160 são referenciadas
porque o Estágio 12484 é idên tico em conteúdo ao Estado de
Situação Holistica 12466. A exe cução continua do Estágio 12450
exige que o Conhecimento da Atividade de Mercado 12348 não contenha variáveis que contradigam as variáveis estabelecidas das Circunstâncias de Investimento Alvo 12160. Isso ocorre porque o Conhecimento da Atividade de Mercado 12348 é categoricamente um elemento das circunstâncias que influenciam o comportamento/resposta ideal do investimento. Portanto, se a resposta ao Prompt 12488 Não for Congruente 12492, o Envio de Registro de Diagnóstico (DLS) 1160 será invocado com. uma Unidade de Registro de Diagnóstico (DLL) 1182 que atua como um Envio de Relatório de Erro. Se a resposta ao Prompt 12488 for considerada Congruente 12490, o Estágio 12496 será invocado, o que ajustará o Estado de Situação Holistica 12466 para corresponder ao Mapa de Hierarquia de Propósito 12472 do Conhecimento de Atividade de
Mercado 12 34 8 via PRP (' 7050) . A afinidade de mestre/escr avo 12 4 94
é fornecic ia ao Estágio 12496 p ara definir o Estado de Situação
Holistica 12466 como o Ϊ Mestre e o Mapa de Hierarquia de Propósito
12472 do C o n h e c i m. e n t o da Ativi dade de Mercado 12348 < é tratado
como o escravo. Isso implica que quaisquer alterações
Petição 870200056145, de 06/05/2020, pág. 600/1737
598/754 diferenciais a serem feitas entre as duas entradas 12466 e 12472 são transferidas para o Estado de Situação Holistica 12466, que é então submetido como a saída resultante do Estágio 12496. Portanto, o Estado de Situação Holistica 12466 é transferido para a Fig. 1077 e subsequentemente processado pelo Estágio 12500.
[1058] A Fig. 1077 continua o fluxo lógico do
Estágio 12450 do CSE 12400 . A lógica contínua ( da Fig. li 07 6 e
retomada no Estágio 12500. 0 Estágio 12500 invo ca o P2SP 7000
para pro duzir um Resultado de Processamento de Simetria 12502
que corresponde às duas entradas do Estado da situação holistica 12466 e ao Mapa da Hierarquia de Propósito 12474 do Conhecimento de Responsabilidade Fiscal 12368. O Resultado do Processamento de Simetria 12502 é enviado ao Prompt 12504, que avalia se o Mapa de Hierarquia de Propósito 12474 do Conhecimento de Responsabilidade Fiscal 12368 é congruente/compatível com o Estado de Situação Holistica 12466. O resultado esperado pelo sistema é que eles são congruentes porque as variáveis definidas nas Circunstâncias de Investimento Alvo 12160 e no Conhecimento de Atividade de Mercado 12348 não devem conter incompatibilidades com o Conhecimento de Responsabilidade Fiscal 12368. As Circunstâncias de Invéstimento Alvo 12160 e o Conhecimento da Atividade de Mercado 12348 são referenciados porque, no Estágio 12500, estão contidos e representados no conteúdo do Estado de Situação Holistica 12466. A execução contínua do Estágio 12450 exige que o Conhecimento de Fiesponsabilidade Fiscal 123 68 não contenha variáveis que contradigam as variáveis estabelecidas das Circunstâncias de Investimento Alvo 12160.
[1059] Isso ocorre porque o Conhecimento de
Petição 870200056145, de 06/05/2020, pág. 601/1737
599/754
Responsabilidade Fiscal 12368 é categoricamente um elemento das circunstâncias que influenciam o comportamento/resposta ideal de
investimento. Portanto, se a resposta a< 2 Prompt 125C )4 nãc ) for
Congruente 125 08, o Envio de Registro de Diagnóstico (DLS) 1160
será invocado de Unidade de Registro de Diagnóstico (DLU) 1182
que atua como um Envio de Relatório de Erro. Se a resposta ao Prompt 12504 for considerada Congruente 12506, o Estágio 12512 será invocado, o que ajustará o Estado de Situação Holistica 124 66 para corresponder ao Mapa de Hierarquia, de Propósito 12474 do Conhecimento de Responsabilidade Fiscal 12368 através do PRP 7050. A Afinidade de Mestre/Escravo 12510 é fornecida ao Estágio 12496 para definir o Estado de Situação Holistica 12466 como o Mestre e o Mapa de Hierarquia de Propósito 12474 do Conhecimento de Responsabilidade Fiscal 12368 é tratado como o escravo. Isso implica que quaisquer alterações diferenciais a serem, feitas entre as duas entradas 12466 e 12474 são transferidas para o Estado de Situação Holistica 12466, que é então submetido como a saida resultante do Estágio 12512. Portanto, o Estado de Situação Holistica 12466 é transferido para a Fig. 1078 e subsequentemente processado pelo Estágio 12520.
[10 60] A Fig. 1.078 continua o fluxo lógico do Estágio 12450 do CSE 12400. A lógica contínua da Fig. 1077 e é retomada no Estágio 12500. O Estágio 12500 invoca o P2SP 7000 para produzir um Resultado de Processamento de Simetria 12522 que corresponde às duas entradas do Estado de Situação Holistica. 12466 e ao Mapa de Hierarquia de Propósito 12478 do Conhecimento de Conformidade Regulatória 12370. O Resultado do Processamento de Simetria 12522 é enviado ao Prompt 12524, que avalia se o Mapa.
Petição 870200056145, de 06/05/2020, pág. 602/1737
600/754 de Hierarquia de Propósito 12478 do Conhecimento de Conformidade Regulatória 12370 é congruente/compatível com o Estado de Situação Holistica 12466. O resultado esperado pelo sistema é que eles são congruentes, porque as variáveis definidas nas Circunstâncias de Investimento Alvo 12160, no Conhecimento de Atividade de Mercado 12348 e no Conhecimento de Responsabilidade Fiscal 12368 não devem conter incompatibilidades com o Conhecimento de Conformidade Regulatória 12370. As Circunstâncias de Investimento Alvo 12160, Conhecimento da Atividade de Mercado 12348 e Conhecimento de Responsabilidade Fiscal 12368 são referenciadas porque, no Estágio 12520, elas estão contidas e representadas no conteúdo do Estado de Situação Holistica 12466. A execução contínua do Estágio 12450 exige que o Conhecimento de Conformidade Regulatória 12370 não contenha variáveis que contradizer as variáveis estabelecidas das Circunstâncias de Investimento A.lvo 12160. Isso ocorre porque o Conhecimento de Conformidade Regulatória 12370 é categoricamente um elemento das circunstâncias que influenciam o comportamento/resposta ideal do investimento. Portanto, se a resposta ao Prompt 12524 não for Congruente 12528, o Envio de Registro de Diagnóstico (DLS) 1160 será invocado com. uma Unidade de Registro de Diagnóstico (DLU) 1182 que atua como um Envio de Relatório de Erro. Se a resposta ao Prompt 12524 for considerada Congruente 12526, o Estágio 12532 será, invocado, o que ajustará o Estado de situação holistica 12466 para corresponder ao Mapa, de hierarquia de Propósitos 12478 do Conhecimento de conformidade regulamentar 12378 do Conhecimento de conformidade regulamentar 12370 por meio do Processamento de realinhamento de Propósito
Petição 870200056145, de 06/05/2020, pág. 603/1737
601/754 (PRP) 7050. A Afinidade de Mestre/Escravo 12530 é fornecida ao Estágio 12532 para definir o Estado de Situação Holística 12466 como o Mestre e o Mapa de Hierarquia de Propósito 12478 do Conhecimento de Conformidade Regulamentar 12370 é tratado como o Escravo. Isso implica que quaisquer alterações diferenciais a serem feitas entre as duas entradas 12466 e 12478 são transferidas para o Estado de Situação Holística 12466, que é então submetido como a saída resultante do Estágio 12532. Portanto, o Estado de Situação Holística. 12466 é transferido para a Fig. 1079 e subsequentemente processado pelo Estágio 12540.
[1061] A. Fig. 1079 continua o fluxo lógico do Estágio 12450 do CSE 12400. A lógica continua a partir da Fig. 1078 e é retomada no Estágio 12540. O Estágio 12540 invoca o P2SP 7000 para produzir um Resultado de Processamento de Simetria 12542 que corresponde às duas entradas de Estado de Situação Holística 12466 e ao Mapa de Hierarquia de Propósito 12482 do Conhecimento de Operações Corporativas 12444. O Resultado do Processamento de Simetria 12542 é enviado ao Prompt 12544, que avalia se o Mapa de Hierarquia de Propósito 12482 do Conhecimento de Operações Corporativas 12444 é congruente/compatível com o Estado de Situação Holística 12466. O resultado esperado pelo sistema é que sejam congruentes, porque as variáveis definidas nas Circunstâncias de Investimento Alvo 12160, no Conhecimento de Atividade de Mercado 12348, Conhecimento de Responsabilidade Fiscal 12368 e Conhecimento de Conformidade Regulatória 12370 não devem conter incompatibilidades com o Conhecimento de Operações Corporativas 12444. As Circunstâncias de Investimento Alvo 12160, o Conhecimento da Atividade de Mercado 12348, o
Petição 870200056145, de 06/05/2020, pág. 604/1737
602/754
Conhecimento de Responsabilidade Fiscal 12368 e o Conhecimento de Conformidade Regulatória 12370 são referenciados porque, no Estágio 12540, eles estão contidos e representados no conteúdo do Estado de Situação Holistica 12466. A execução contínua do Estágio 12450 exige que o Conhecimento de Operações Corporativas 12444 não contenha variáveis que contradigam, as variáveis estabelecidas das Circunstâncias de Investimento AfLvo 12160. Isso ocorre porque o Conhecimento em Operações Corporativas 12444 é categoricamente um elemento das circunstâncias que influenciam o comportamento/resposta ideal do investimento. Portanto, se a resposta ao Prompt 12544 não for Congruente 12548, o Envio de Registro de Diagnóstico (DLS) 1160 será invocado com. uma Unidade de Registro de Diagnóstico (DLL) 1182 que atua como um Envio de Relatório de Erro. Se a resposta ao Prompt 12544 for considerada Congruente 12546, será invocado o Estágio 12552 que ajusta o Estado de Situação Holistica 12466 para, corresponder ao Mapa, de Hierarquia de Propósito 12482 do Conhecimento de Operações Corporativas 12444 através do PRP (7050) . A Afinidade de Mestre/Escravo 12550 é fornecida ao Estágio 12552 para definir o Estado de Situação Holistica 12466 como o Mestre e o Mapa de Hierarquia de Propósito 12482 do Conhecimento de Operações Corporativas 12444 é tratado como o Escravo. Isso implica que quaisquer alterações diferenciais a serem feitas entre as duas entradas 12466 e 12482 são transferidas para o Estado de Situação Holistica 12466, que é então submetido como a saída resultante do Estágio 12552. Portanto, o Estado de Situação Holistica 12466 é transferido para a Fig. 1080 e subsequentemente processado pelo Estágio 12554.
Petição 870200056145, de 06/05/2020, pág. 605/1737
603/754
[1062] A Fig. 1080 continua o fluxo lógico do Estágio 12450 do CSE 12400. O Estado de Situação Holistica 12466 é recebido pelo Estágio 12552 da Fig. 1079. Portanto, o Estágio 12554 fornece o Estado 12466 para a Necessidade de Correspondência de Mapa (NMM) C114, que é um submódulo existente no Shell Dinâmico (DS) C198 do LIZARD 120. O NMM C114 disseca o Estado 12466 nas filiais jurisdicionais que categorizam os vários elementos encontrados no Estado 12466. Portanto, o Estágio 12556 invoca a Ameaça de Segurança. Artificial (AST) 123 para fazer referência a cenários potenciais, conforme definido pelas filiais jurisdicionais formadas na instância correspondente do WM C114. Posteriormente, no Estágio 12558, os resultados do processo AST 123 são que os cenários definidos pelas filiais jurisdicionais do NMM C114 são criativamente variados por meio do Módulo de Criatividade 112.
[1063] A Fig. 1081 mostra a operação e a funcionalidade da Necessidade de Correspondência de Mapa (NMM) C114 operando como um. submódulo do Shell Dinâmico C198 do LIZARD 120. A instância do NMM C114 é gerada para atender à operação do Estágio 12450 da Avaliação de Estado Abrangente (CSE) 12400. O Estado de Situação Holistica 12466 é enviado para ser armazena nas Necessidade de Acesso, Desenvolvimento e Armazenamento 5550. Portanto, o Estado de Situação Holistica 12466 é dividido em subcategorias e retido no Arm.azenam.ento 5550 como uma série de filiais e camadas hierárquicas. Com a invocação modular do NMM C114, a Análise Inicial C148 baixa cada filial da jurisdição do Armazenamento 5550 para reter temporariamente para referência na instância em andamento do NMM C114. Com Calcular as Necessidades
Petição 870200056145, de 06/05/2020, pág. 606/1737
604/754 da Filial C149: de acordo com as definições associadas a cada filial, as necessidades são associadas ao departamento correspondente. Dessa forma, as verificações de permissão podem, ser formadas na instância do NMM C114. Por exemplo: O NMM C114 aprovou a solicitação para o departamento de Recursos Humanos fazer o download de todos os Currículos dos empregados, porque ela foi solicitada dentro da zona da reavaliação anual do desempenho dos empregados, de acordo com suas capacidades. Portanto, foi provado ser uma necessidade válida da jurisdição do departamento. Portanto, o índice de Necessidade C145 é o principal armazenamento das Filiais Jurisdicionais e suas respectivas necessidades. Como essa referência interna é um. gargalo de recursos para a operação do NMM C114 e, portanto, todos os módulos que ele serve, é otimizada com antecedência para consultas rápidas ao banco de dados, a fim. de aumentar a eficiência geral do sistema. A Ameaça Artificial à Segurança. (AST) 123 fornece um Propósito de Entrada C139 como entrada modular para o Algoritmo de Pesquisa C144 do NMM C114. O Algoritmo de Pesquisa C144 faz referência e pesquisa no índice de Necessidade C145 compilado, determinando, portanto, se o Propósito de Entrada C139 define uma necessidade válida de acordo com as filiais de jurisdição definidas inicialmente nas Necessidades de Acesso, Desenvolvimento e Armazenamento 5550. Portanto, a execução concluída do Algoritmo de Pesquisa C144 através do índice de Necessidade C145 produz uma resposta para. Aprovar/Bloquear C14 6 que é enviada como saída modular do NMM C114 e referenciada como Resultado da Necessidade C141. Portanto, o Resultado da Necessidade C141 é retornado de volta ao AST 123
Petição 870200056145, de 06/05/2020, pág. 607/1737
605/754 em resposta à sua submissão C139 de uso final.
[1064] A. Fig. 1082 continua o fluxo lógico do Estágio 12450 do CSE 12400. A lógica é retomada no Estágio 12558. Posteriormente, é executado o Estágio 12560, que recebe a Composição de Decisão de Investimento Ideal 12404 como entrada modular. A Composição 12404 é interpretado pelo Variação do Criativo de Entrada (ICV) 12405 para criar pequenas Variações 12562 em qualquer escopo de ambiguidade que possa existir no
conj unt o de vari áve i s definem a Composição 12404. Portanto,
as Vari ações de Compos :içãc ) 12562 produzidas são enviadas para o
Estágio 12564, para qu e ρο ssam se :r usadas como P ersonalidades da
Trilha C8 67D com as I ’ri 11 i.as de E vo 1 u ç ã o C 8 6 7A correspondentes
que são emuladas pelo i2ge 122 .
[1065] A Fig, i o (”) 3 se expande no Estágio 12564 a
partir do CSE 12400. Parte do fluxo lógico da Fig. 1082 é resumido aqui, para mostrar a Composição de Decisão de Investimento Ideal 12404 sendo processada pelo ICV 12405 para produzir Variações de Composição 12562. As Variações 12562 são logisticamente descompactadas no Estágio 12565, o que implica que qualquer camada de criptografia, compactação e otimização seja revertida para permitir o acesso à execução. Posteriormente no Estágio 12566; as Variações de Composição 12562 são instaladas como Personalidades de Trilha C867DA / C867DB por meio do Sistema de Interação com Monit.oram.ento C8 68D. 0 Sistema de Interação com. Monitoramento C868D atua como uma camada API para funções externas assistindo e manipulando à emulação executada pelo I2GE 122. As Variações 12562 instaladas correlacionam-se cada uma com. uma Personalidade de Trilha C867D individual, que define a
Petição 870200056145, de 06/05/2020, pág. 608/1737
606/754
direção em que a Trilha de Evolução C867A evolui. Portanto,
devido às múltipl; as Variações 12562, é provável que pelo menos
uma das Trilhas de Evolução C867A atinja com sucesso a composição
que é procurada pe 3I0 sistema. A composição específica procurada
nesta instância es ipecífica é uma Variação 12562 da Composição de
Decisão de Investimento Ideal 12404 que é mais compatível, com as
Filiais Jurisdicionais NMM C114 fornecidas do Estado de Situação
Holística 12466. As instâncias independentes das Trilhas de
Evolução C8 67A sã< o separadas pelo Isolamento Virtual 390, que
garante a indepenc iência dos dados e a ausência de contaminação
cruzada. Assim, o resultado é louisticamente uarantido como um
derivado da correspondente Personalidade de Trilha C867D.
[1066] A Fig. 1084 continua o fluxo lógico que foi
fornecido na Fig. 1083, ainda no contexto do Estágio 12450 do
CSE 12400. A mesma lógica é mostrada em. relação à I2GE 122, mas o Sistema de Interação de Monitoramento C868D fornece saída de
produção referent e aos resultados da emulação da Trilha de
Evolução C867A ao Processador de Conclusão de Iteração 5554. 0
Processador 5554 chega a conclusões significativas sobre os
resultados da emul ação I2GE 122, levando, assim, ao Promot 12568,
que verifica se a Composição de Decisão de Investimento ideal
12404 foi capaz de passar pelos requisitos de estabilidade
definidos no Proce; ssamento estático codificado (SHP) 488. As duas
c o n c 1 u s õ e s / r e s p o s t. as em. potencial que poderíam ter sido
consideradas pelo Processador de Conclusão de Iteração 5554 são
Suficientemente E 1 o ti -/ 9 stável 12570 e Não Suficientemente Estável
1. Z -j / Z , [1067] A Fig. 1085 elabora o fluxo lógico mostrado
Petição 870200056145, de 06/05/2020, pág. 609/1737
607/754 na Fig. 1084, mostrando iterações geracionais específicas da Composição de Decisão de Investimento Ideal 12404 sendo iteradas dentro de uma única Trilha de Evolução C8 67A. Assim., a Trilha C867A esta em conformidade com as métricas definidas no Personalidade de Trilha C867D. Portanto, define-se a direção evolucionária. A Designação da Trilha 12407 determina o estado de qualquer Trilha de Evolução C867A. Esses estados podem ser designados como Passado como Estável, Evolução Pendente ou Ab a n d o n a d o / E x c 1 u í d o .
[1068] A Fig. 1086 conti nua o fluxo lógico principal
do CSE 12400, que é retomado a parti: r do Prompt 12568.
[1069] 0 Estágio 12450 é o Estágio principal que
invoca o I2GE 122, o que leva . ao Prompt 12568. Se a resposta ao
Prompt 12568 for ' que a emulaç ão Não ; é Suficientemente Estável
12584, o I2GE 122 receberá o códi g o de resposta com. a maior
probabilidade, a seu critério, para executar novamente a emulação com uma variação de variáveis que definem uma distinção com a emulação com faina anterior. Se a resposta ao Prompt. 12568 for Suficientemente Estável 12582; o Estágio 12586 é invocado, o que produz os resultados da emulação como Composição de Decisão de Investimento Refinado 12458. Posteriormente, no Estágio 12588, a Composição de Decisão de Investimento Refinado 12458 é dividida de forma logística para produzir elementos individuais: Alocações de Investimento 12592, Retiradas de Investimentos 12594, Alocações de Lucros 12596 e Notificação do Diretor 12598.
[1070] A. Fig. 1087 mostra um resumo geral final da Avaliação Abrangente de Estado (CSE) 12400. O módulo Iniciação de Segmento Preliminar (PTI) 12080 inicia uma instância da
Petição 870200056145, de 06/05/2020, pág. 610/1737
608/754
Interpretação das Circunstâncias de Investimento Alvo (TICI) 12380. O TICI 12380 produz as Circunstâncias de Investimento Alvo 12160 para o mecanismo de Processamento Interno 12600 do CSE 12400. Todo o processamento do CSE 12400 leva ao Estágio 12602, que descompacta a Composição de Decisão de Investimento Refinado 12458 para seus elementos individuais listados na Seção 12590. As Alocações de Investimento 12592 indicam em quais empresas a Estrutura de Doação (ES) 12008 solicitante deve investir. 12594 indica que investimentos preexistentes da Estrutura de Doação (ES) 12008 especificada devem ser retirados. Esses investimentos preexistentes são inicialmente definidos pela Composição de Estaca do Portfolio 12384, extraído da instância relevante da Composição de Estaca do Portfolio (PSR) 12003. Portanto, a Composição de Estaca 12384 é assimilada nas Circunstâncias de Invéstimento Alvo 12160 que são recebidas e consideradas pelo CSE 12400. As Alocações de Lucro 12596 indicam para onde os lucros dessas empresas devem ser retirados (ou seja, na instância relevante do Capital de Investimento (IC) 12012, ou diretamente para os fundos privados de um Diretor Relevante 12006/12022 etc.).
[1071] A Notificação do Diretor 12598 indica que uma mensagem é enviada ao pretendido Diretor 12006/12022 para recomendar determinadas ações de investimento a serem executadas que podem, ser muito complexas ou excederem, a permissão para, que a Atuação na Decisão de Investimento (IDA) 12604 seja diretamente executada. Assim, o IDA 12604 executa os Elementos Individuais 12590 fornecidos para desenvolver as consequências pretendidas para a instância relevante da Estrutura, de Doação (ES) 12008;
Petição 870200056145, de 06/05/2020, pág. 611/1737
609/754
Conselho de Diretores (BD) 12018 ou Diretor Independente (ID) 12020.
[1072] [00] As Figs. 1088 - 1115 mostram a operação e a funcionalidade do Rastreamento de Mente Digital (DMT) 12700, que emula as 'percepções' e 'pensamentos' de um mecanismo de reação digital que se propõe a emular alvos humanos específicos.
[1073] A Fig. 1088 mostra detalhes sobre a operação do Rastreamento de Mente Digital (DMT) 12700. O módulo Gravação do Comportamento Alvo (TBR) 12704 recebe informações do Conjunto de Dados de Comportamento (BDS) 127 0 6 diretamente da Mente AfLvo 12702 especificada e associações de mapeamento neurológico feitas por o módulo de Aprimoramento de Mapeamento Neurológico (NME) 13090. O BDS 12706 contém informações sobre as Ações 12708, Declarações 12710 e Metadados 12712 sobre a Mente Alvo 12702. A instância do BDS 12706 é fornecida como entrada modular para o DMT 12700 e recebida no Estágio 12714. O Estágio 12714 leva ao Estágio 12718, onde as informações do BDS 12706 são normalizadas via LIZARD 120, que o converte do formato de sintaxe para o formato de propósito. Assim, um Mapa de Propósitos de Comportamento 12720 é construído a partir da instância BDS 12706 por meio da execução modular do LIZARD 120. Posteriormente, no Estágio 12722, o Mapa de Propósitos do Comportamento 12720 é armazenado e retido em uma instância do Perfil de Inteligência Pessoal (PIP) 136 que é logisticamente associado à Mente Alvo 12702. Depois, o LOM 132 é invocado no Estágio 12724 para produzir os Tipos de Modelo de Personalidade 12726, que são coleções que classificam, vários tipos de personalidades humanas com. definições psicológicas complexas (por exemplo, introvertidas, julgadoras.
Petição 870200056145, de 06/05/2020, pág. 612/1737
610/754 c i n ± c a s, narcisistas etc.).
[1074] A Fig. 1089 expande os detalhes operacionais relativos ao Estágio 12724 do Rastreamento de Mente Digital. (DMT) 12700, que define o LOM 132 e seus submódulos (como Appchains 836) sendo invocados para produzir Tipos de Modelo de Personalidade 12724. O fluxo lógico é iniciado no Estágio 12728, que descreve o LOM 132 invocando regularmente o Mecanismo de Pesquisa Automatizado (ARM) 134 para pesquisar tipos de personalidade por meio das suas fontes (por exemplo, documentos de pesquisa em psicologia etc.). No Estágio 12730, as informações de pesquisa resultantes produzidas pelo ARM 134 são armazenadas no Retentor Central de Conhecimento (CKR) 648 como conhecimento não confirmado. Depois, o Estágio 12732 é executado, onde o LOM 132 e o CTMP 124 extraem afirmações e conclusões significativas sobre os Tipos de Personalidade a partir de conhecimento não confirmado armazenado no CKR 64 8 (que foi enviado para, o Estágio 12730). Quando o LOM 132 e o CTMP 124 concluem sua análise sobre os conhecimentos não confirmados, quaisquer afirmações e
conclusões significativas são enviadas para o Retentor no CKR.
648. Posteriormente, o Estágio 12/34 é invocado para produzir os
Tipos de Modelo de Personalidade 12726 da CKR 648, que
representam as asserções e conclusões significativas derivadas no Estágio 12732.
[1075] A Fig. 1090 continua o fluxo lógico do Rastreamento de Mente Digital (DMT) 12700 da Fig. 1088. Depois que o LOM 132 produz os Tipos de Modelo de Personalidade 12726 no Estágio 12724, o Estágio 12736 é invocado para produzir uma Composição do Modelo de Personalidade 12738 do Cumprimento de
Petição 870200056145, de 06/05/2020, pág. 613/1737
611/754
Modelo de Personalidade (PTF) 12760. Composição do Modelo de Personalidade 12738 captura elementos de personalidade que existem nos Tipos de Modelo de Personalidade 12726, de acordo com os Critérios de Modelo de Personalidade 12752 da Mente Alvo 12702. No Estágio 12742, o LOM 132 é invocado para produzir a Definição de Nuance de Personalidade que corresponde à Mente Alvo 12702 da instância PIP 136 correspondente.
[1076] A. Fig. 1091 cria os detalhes operacionais do Estágio 12736 do Rastreamento de Mente Digital (DMT) 12700. No Estágio 12734, o LOM 132 é chamado para produzir os Tipos de Modelo de Personalidade 12726 da CKR 648. Isso faz com que o Estágio 12750 seja invocado, onde os Critérios de Modelo de Personalidade 12752 da Mente Alvo são produzidos a partir da instância PIP 136 correspondente através do LOM 132. Os Critérios de Modelo de Personalidade 12752 representam, dados individuais relativos à Mente Alvo que têm potencial para ativar determinadas classificações do Modelo de Personalidade 12726 que permitiríam a produção de uma Composição do Modelo de Personalidade 12738.
[1077] A Fig. 1092 mostra detalhes sobre o Estágio 12734 da DMT 12700, onde o LOM 132 produz os Tipos de Modelo de Personalidade 12726 da CKR 648. O LOM 132 é chamado para produzir esse Conhecimento 12370 pelo módulo 12754 do Prompt de Invocação do Modelo de Personalidade (PTIP). O Conhecimento de Conformidade Regulatória 12370 é ilustrado como sendo construído com. várias instâncias dos Clusters UKF C854F. O elemento individual do Cluster UKF C854F é elaborado em detalhes como sendo feito das subunidades UK.F1, UK.F2 e UKF3 que são armazenadas no Formato de Sintaxe de Regra C538.
Petição 870200056145, de 06/05/2020, pág. 614/1737
612/754
[1078] A Fig. 109.3 elabora a operação do Cumprimento de Modelo de Personalidade (PTF) 12760 no Estágio 12736 da DMT 12700. No Estágio 12750, os Critérios de Modelo de Personalidade 12752 da Mente Alvo 12702 são produzidos a partir da instância LOM 132 correspondente do PIP 136. Depois, é executado o Estágio 12756, que invoca o PTF 127 60 para atender às definições dos Critérios de Modelo de Personalidade 12752 com Tipos de Modelo de Personalidade 12726.
[1079] Portanto, o PTF 12760 é invocado no Estágio 12762, que inicia um Loop para circular em cada um dos Critérios de Modelo de Personalidade 12752. Os Critérios de Modelo de Personalidade Selecionados 12764 da Iteração do Loop são processados pelo Estágio 12766, que recupera os Tipos de Modelo de Personalidade 12726 correspondentes de acordo com os Tipos de Modelo de Personalidade 12726 que são referenciados nos Critérios de Modelo de Personalidade Selecionados 12764. Portanto, o Tipo de Modelo de Personalidade Selecionado 12768 é produzido a partir do Estágio 12766. No Estágio 12770, o Tipo de Modelo de Personalidade Selecionado 12768 é atribuído de acordo com a Magnitude de presença definida nos Critérios de Modelo de Personalidade Selecionados 12764.
[1080] Portanto, essas atribuições fazem com que o
Estágio 12770 produza a Composição do Modelo de Personalidade
12738 .
[1081] A Fig. 1094 continua o fluxo lógico do Cumprimento do Modelo de Personalidade (PTF) 12760 da Fig. 1093. O Estágio 12770 produz a Composição do Modelo de Personalidade 12738 como saída modular processando duas entradas modulares:
Petição 870200056145, de 06/05/2020, pág. 615/1737
613/754
Critérios de Modelo de Personalidade Selecionados 12764 e Tipo de Modelo de Personalidade Selecionado 12768. 0 Prompt 12772 é processado posteriormente, verificando se há alguma unidade não processada restante dos Critérios de Modelo de Personalidade 12752 do Loop que foi iniciado no Estágio 12762. Se a resposta ao Prompt. 1.2772 for Não 1277 6, o Estágio 12780 será ativado e enviará a Composição do Modelo de Personalidade 12738 como saída modular para o PTF 12760. 0 Estágio 12756 é o invocador original do PTF 12760 que causou a produção da Composição do Modelo de Personalidade 12738.
[1082] A Fig. 1095 continua o fluxo lógico principal do Rastreamento de Mente Digital (DMT) 12700 e é resumida novamente na Fig. 1090 no Estágio 12742. A Definição de Nuance de Personalidade 12744 é produzida a partir do Estágio 12742 e transferida para o Estágio 12784, que invoca o LIZARD 120 para converter a Definição de Nuance de Personalidade 12744 em um Mapa de Hierarquia de Propósito 12786. No Estágio 12788, o LIZARD converte a Composição do Modelo de Personalidade 12738 em. um Mapa de Hierarquia de Propósito 12790. No Estágio 12792, os Mapas de Hierarquia de Propósito 12790 e 12786 são processados pelo módulo Propósito do Processamento de Simetria de Propósito (P2SP) 7000 no Estágio 12792. O P2SP 7000 determina a congruência/compatibilidade entre as duas entradas, produzindo o Resultado de Processamento de Simetria 12794.
[1083] A Fig. 1096 mostra detalhes sobre a operação do LIZARD 120 para converter a Definição de Nuance de Personalidade 12744 em um Mapa de hierarquia de Propósito 12786. A Definição de Nuance de Personalidade 12744 é enviada, ao Módulo
Petição 870200056145, de 06/05/2020, pág. 616/1737
614/754
de S iintaxe (S M) C 3 5, que pertence à jurisdição do Núcleo Exterior
(OC) C32 9 . 0 SM C35 fornece uma esuruuura para leitura e escrita
de código dc ? compu tador. Para escrever códi go; ele recebe o
rato de P ropósit o Complexo C325 do Módulo de Propósito (PM)
C36. 0 Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. 0 pseudocódigo contém implementações básicas das operações de computação mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Depois, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação alvo desejada (linguagem do computador) . Para leitura de código; 0 SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar um propósito para a funcionalidade desse código. A Definição de Nuance de Personalidade 12744 é recebida no formato Sintaxe de Estado 5624 pela Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e compreendido pela SM C35 em qualquer linguagem de computação conhecido e selecionado. A conversão de código C321 também executa a função inversa de converter linguagens de computação conhecidas em. tipos de sintaxe arbitrários. A saída da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas miais simples para produzir um mapa de funções interconectadas, segundo as definições de Regras e Sintaxe C322. Portanto, depois da execução completa da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35
Petição 870200056145, de 06/05/2020, pág. 617/1737
615/754 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma Propósito no Formato de Propósito Complexo C325 do código do computador. Essa definição de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada por SM C35. 0 PM C36 também é capaz, de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.) . A Interpretação Iterativa C328 circula por todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326.O Núcleo Interno (IC) C333 é a área do LIZARD 120 que não tem. manutenção automática/ autoprogramação e é direta e exclusivamente programada por especialistas na área relevante. O elemento Código Principal C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória Portanto, o Código Principal C335 permite operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a Política de Segurança e Objetivos da Empresa. Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1084] A Fig. 1097 continua o fluxo lógico da Fig. 1096 para ilustrar a operação do LIZARD 120 para converter a Definição de Nuance de Personalidade 12744 em. um. Mapa de Hierarquia de Propósito 12786. A redução lógica C323 do Módulo
Petição 870200056145, de 06/05/2020, pág. 618/1737
616/754 de Sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula através de todas as funções interconectadas para produzir uma definição de propósito interpretada consultando Associações de Propósito C326. A saída de definição de propósito existe no Formato de Propósito Complexo C325, que é enviado como saída modular para o PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e o UZARD 120. A saída é rotulada como um Mapa de Hierarquia de Propósito 12786, que é apresentado como a versão do Formato de Propósito Complexo C325 da Definição de Nuance de Personalidade 12744.A mesma definição e aplicação do Núcleo Interno (IC) C333 aplica-se às funções e módulos mencionados acima.
[1085] A Fig. 1098 mostra detalhes da operação do LIZARD 120 para converter a Composição de Modelo de Personalidade 12738 em um Mapa de Hierarquia de Propósito 12790. A Definição de Nuance de Personalidade 12744 é enviada para o Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. 0 SM C35 fornece uma estrutura, para, leitura, e escrita, de código do computador. Para escrever código; ele recebe o Formato de Propósito Complexo C325 do Módulo de Propósito (PM) C36. O Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém, implementações básicas das operações de computação mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Depois, uma função auxiliar converte o pseudocódigo em. código executável real, dependendo da sintaxe de computação alvo desejada.
Petição 870200056145, de 06/05/2020, pág. 619/1737
617/754 (linguagem do computador) . Para leitura de código; 0 SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar um. propósito para a funcionalidade desse código. A Definição de Nuance de Personalidade 12744 é recebida no formato Sintaxe de Estado 5624 pela Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e compreendido pela SM C35 em qualquer linguagem de computação conhecido e selecionado. A conversão de código C321 também executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saída da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A. Redução Lógica C323 reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas, segundo as definições de Regras e Sintaxe C322. Portanto, depois da execução completa da Redução Lógica C323, a execução da instância, correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma. Propósito no Formato de Propósito Complexo C325 do código do computador. Essa definição de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada por SM C35. 0 PM C36 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.) . A Interpretação Iterativa C328 circula, por todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326.O Núcleo
Petição 870200056145, de 06/05/2020, pág. 620/1737
618/754
Interno (IC) C333 é a área do LIZARD 120 que não tem manutenção automática/ autoprogramação e é direta e exclusivamente programada por especialistas na área relevante. O elemento Código Principal C335 do IC C333 contém Estruturas e Bibliotecas
Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória Portanto, o Código Principal C335 permite operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a Política de Segurança e Objetivos da Empresa. Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1086]
A. Fig. 1099 continua o fluxo lógico da Fig.
1098 para ilustrar a operação do LIZARD 120 para converter a Composição de Modelo de Personalidade 12738 em um Mapa de Hierarquia de Propósito 12790. A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula através de todas as funções interconectadas para produzir uma definição de propósito interpretada consultando Associações de Propósito C326. A saída de definição de propósito existe no Formato de Propósito Complexo
C325, que é enviado como saída modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e, para o LIZARD 12 0. A* saída é rotulada como um Mapa de Hierarquia de
Propósito 12490, que é apresentado como a versão do Formato de
Propósito Complexo C325 da Composição do Modelo de Personalidade
12738
A mesma definição
Petição 870200056145, de 06/05/2020, pág. 621/1737
619/754 e aplicação do Núcleo Interno (IC) C333 aplica-se às funções e módulos mencionados acima.
[1087] Ά Fig. 1100 continua o fluxo lógico da Fig. 1095 em relação à operação da instância invocada pelo Propósito do Processamento de Simetria de Propósito (P2SP) 7000 para processar o Mapa de Hierarquia de Propósito 12790 da Composição do Modelo de Personalidade 12738 e o Mapa de Hierarquia de Propósito 12786 da Definição de Nuance de Personalidade 12744. Depois do Estágio 12792 concluir seu processo operacional, o Prompt 12796 verifica se o Mapa 12790 é congruente e compatível com o Mapa 12786. Se a resposta ao Prompt 12796 for Sim, Congruente 12798, o Estágio 12802 será invocado, o que produzirá o Mapa de Propósito de Personalidade 12804 como um clone do Mapa de Hierarquia de Propósito 12790 da Composição do Modelo de Personalidade 12738. Isto é feito porque se percebe que o Mapa de Hierarquia de Propósitos 12786 da Definição de Nuance de Personalidade 12744 não contribuiría com nenhuma informação significativa ao Mapa de Propósitos de Personalidade 12804, devido ao alto grau de congruência/compatibilidade entre os dois Mapas 12790/12786. Se a resposta ao Prompt 12796 for Não, não é Congruente 12800, então o módulo de Processamento de Realinhamento de Propósito (PROP) 7050 será invocado para produzir o Mapa de Propósito de Personalidade 12804 (como se mostra na Fig. 1101) .
[1088] A Fig. 1101 elabora, o fluxo lógico da Fig. 1100 com relação à resposta Não, Não é Congruente 12800 do Prompt 12796. O Estágio 12806 invoca o Processamento de Realinhamento de Propósito (PRP) 7050 para ajustar o Mapa de Hierarquia de
Petição 870200056145, de 06/05/2020, pág. 622/1737
620/754
Propósito 12790 da Composição do Modelo de Personalidade 12738 para Corresponder ao Mapa de Hierarquia de Propósito 12786 da Definição de Nuance da Personalidade 12744. Portanto, quaisquer elementos representados no Mapa 12786 são inseridos no Mapa 12790. O resultado do Estágio 12806 é processado no Estágio 12808 para produzir o Mapa de Propósito de Personalidade 12804. No Estágio 12810, o LIZARD converte o Mapa de Propósito de Personalidade 12804 em Sintaxe Reacional de Personalidade, que é referenciada como Sistema de Reação de Personalidade 12812.
[1089] A Fig. 1102 mostra detalhes sobre a operação do LIZARD 120 para converter o Mapa de Propósito de Personalidade 12804 na Sintaxe de Reação da Personalidade. O Mapa 12804 existe no Formato de Propósito Complexo C325 e é submetido à Expansão Iterativa C327 do Módulo de Propósito C36 dentro do Núcleo Exterior (OC) C329 do LIZARD 120. A Expansão Iterativa C327 adiciona, detalhes e complexidade para desenvolver um objetivo simples (definido indiretamente dentro do Mapa 12804) em uma definição específica de propósito complexo. Portanto, o potencial máximo da Associação de Propósito C326 da entrada é realizado e retido como um Formato de Propósito Complexo C325, antes de ser submetido à Derivação Lógica C320 do Módulo de Sintaxe (SM) C35. O elemento Código Principal C335 do Núcleo Interior (IC) C333 contém Estruturas e Bibliotecas fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite as operações e funcionalidades gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento
Petição 870200056145, de 06/05/2020, pág. 623/1737
621/754
Objetivos do Sistema C336 do IC C333 define a Politica de
Segurança e Objetivos da Empresa. Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1090] A. Fig. 1103 continua o fluxo lógico da Fig. 1102 para ilustrar a operação do LIZARD 120 para converter o Mapa de Propósito de Personalidade 12804 na Sintaxe de Reação da Personalidade que é referida como o Sistema de Reação da Personalidade 12812. Os dados de entrada, são recebidos no Formato de Propósito Complexo C325 do Módulo de Propósito (PM) C36 e são transferidos para a Derivação Lógica C320 do Módulo de Sintaxe (SM) C35. A Derivação Lógica C320 deriva funções logicamente necessárias de funções inicialmente mais simples. Isso significa que se uma função puder ser formada como uma função derivada devido à implicação de uma função pai mais simples; então é formado pela Derivação Lógica C32 0. O resultado produzido é uma. árvore de dependências de funções construídas de acordo com os dados definidos Pelo Formato de Propósito Complexo C325. A. Derivação Lógica C320 opera de acordo com as definições de Regras e Sintaxe C322 que são herdadas do elemento Código Principal C335 do Núcleo Interior (IC) C333. A Derivação Lógica C320 envia sua saída para a Conversão de Código C321. A conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e compreendido pela SM C35 em qualquer linguagem, de computação conhecido e selecionado. A Conversão de Código C321 também executa a função inversa de conversão de linguagens de computação conhecidas em. tipos de sintaxe arbitrários. Portanto, o PM C36 invoca o SM C35 para, produzir a Versão da Sintaxe do Appchain
Petição 870200056145, de 06/05/2020, pág. 624/1737
622/754
12184 resultante das Medidas de Substituição Ativas de entrada 12170 através da Conversão do Código C321. A versão resultante da Sintaxe de Reação da Personalidade 12812, produzida pela Conversão de Código C321, é a saída modular do SM C35, do Núcleo Exterior (OC) C329 e do LIZARD 120.
[1091] A Fig. 1104 mostra a operação e o fluxo lógico do Rastreamento de Mente Digital (DMT) 12700 sendo retomado no Estágio 12810 da Fig. 1101. Depois do Estágio 12810 produzir o Sistema de Reação de Personalidade 12812 através do LIZARD 120, o Estágio 12814 é invocado para recuperar a identidade da Mente Alvo 12816 da Mente Alvo 12702. O Estágio 12818 recupera a instância da Retenção do Cache Instantâneo de Personalidade (PSCR) 12822, associada à Identidade da Mente Alvo 12816. O Prompt 12820 verifica se há uma iteração anterior do Sistema de Reação da Personalidade 12812 que é armazenada na instância PSCP. 12822 que corresponde à Era de Tempo Definido. A Era de Tempo Definido é referenciada na Identidade da Mente Alvo 12816, pois define o período que representa a composição na Mente Alvo. Por exemplo: as pessoas geralmente sofrem mudanças com a maturidade ao longo da vida, compreensão, experiência e personalidade. Dessa forma, a Era do Tempo Definido pode fazer distinções entre as versões mais antigas e mais recentes das pessoas como elas eram. Se a resposta ao Prompt 12820 for Sim 12824, o Estágio 12828 será ativado, o que excluirá a iteração anterior do Sistema de Reação da Personalidade 12812 da instância, do PSCR. 12822. Dessa forma, existe apenas um PSC.R 12822 por Era de Tempo Definido. O Estágio 12828 e a resposta Não 12826 ao Prompt 12820 levam à ativação do Estágio 12830, que converte
Petição 870200056145, de 06/05/2020, pág. 625/1737
623/754 armazena e retém o atual Sistema de Reação da Personalidade 12812 na instância PSCR 12822 associada à Mente Alvo 12702 da Era do Tempo Definido de acordo com. a Identidade da Mente Alvo 12816.
[1092] A Fig. 1105 elaborada no Estágio 12830 do DMT 12700, que converte o Sistema de Reação da personalidade 12812 e o armazena na instância correspondente do PSCR. 12822. No Estágio 12832, um Conjunto de Comandos Personalizados 12834 é enviado ao ESR 6400, que o instrui a extrair o conteúdo do Appchain 836 do CTMP 124 sem dados pré-existentes. No Estágio 12836, é produzida uma Base de Execução 12838 Vazia CTMP, que é uma captura instantânea da instância do ESR 6400. Como a instância do CTMP 12 4 na instância do ESR 64 00 ainda não processou nem reteve nenhum dado, a captura instantânea é considerada 'Vazio'. No Estágio 12840, a Base de Execução CTMP Vazia 12838 é processado em. uma nova instância do ESR 6400. Portanto, o Estágio 12840 executa a função inversa do Estágio 12836. No Estágio 12844, o Appchain CTMP Personalizado 12842 processado, interage com. o Sistema de Reação de Personalidade 12812, capturando, portanto, efetivamente a personalidade da Mente Alvo 12702 na Instância CTMP Personalizadal2842.
[1093] A Fig. 1.106 continua o fluxo lógico do Estágio 12830 do DMT 12700 da Fig. 1105. Depois de terminar o processamento do Estágio 12844, um Conjunto de Comandos Personalizado 12834 é enviado como uma. instrução à instância do ESR 6400 para confirmar todas as alterações no armazenamento persistente. A instrução do Conjunto de Comandos Personalizado 1.2834 contém o Tipo de Comando 6408 do Segmento de Dados de Escritura Persistente 6422. Depois que o ESR 6400 processou os
Petição 870200056145, de 06/05/2020, pág. 626/1737
624/754
Comandos 12834 do Segmento de Dados de Escritura Persistente 6422, a Instância CTMP Personalizada 12842 é capturada efet.ivam.ente em um arquivo de Retenção do Appchain de Captura Instantânea do CTMP 12850.
[1094] A. Fig. 1107 elabora os detalhes operacionais do Estágio 12846 do Rastreamento de Mente Digital (DMT) 12700. O Sistema de Reação de Personalidade 12812 é transferido para o Estágio 12852 como entrada modular, que produz um conjunto de Cenários de Emulação Relevantes 12854 por meio da Produção de Cenários de Emulação. (ESP) 12856. O ESP 12856 produz Cenários de Emulação Relevantes 12854 que são relevantes para o escopo, jurisdição e capacidades do Sistema de Reação de Personalidade 12812. Por exemplo, uma personalidade com formação em engenharia elétrica derivaria cenários relacionados à fiação elétrica da casa etc. No Estágio 12858, é iniciado um loop que itera pelos Cenários de Emulação Relevantes 12854, produzindo, portanto, uma. única unidade do Cenário de Emulação Selecionado 12860 por iteração do loop. No Estágio 12862, o Cenário de Emulação Selecionado 12860 é descompactado para produzir as duas variáveis principais que ele contém: a Proposição de Emulação 12864 e o Ambiente de Emulação 12866. A Proposição de Emulação 12864 atua como uma afirmação de cenário, por exemplo: o soquete elétrico em uma parede pode não estar aterrado adequadamente. O Ambiente de Emulação 12866 define variáveis que podem afetar a reação da instância CTMP Personalizadal2842 relacionada, ao Sistema de Reação de Personalidade 12812, como a nora e o local do evento.
[1095] A Fig. 1108 continua o fluxo lógico da Fig. 1107, que detalha a operação do Estágio 12846 da DMT 12700. O
Petição 870200056145, de 06/05/2020, pág. 627/1737
625/754
Estágio 12862 descompacta a Proposição de Emulação 12864 e o Ambiente de Emulação 12866 do Cenário de Emulação Selecionado 12860. No Estágio 12868, a Proposição de Emulação 12864 é enviada para a instância CTMP Personalizadal2842 como Metadados do Sistema de Entrada C484. Isto indica que a Proposição de Emulação 12864 é enviada como entrada modular para a instância CTMP Personalizadal2842 com a classificação de Opinião Subjetiva. O Estágio 12870 envia o Ambiente de Emulação 12866 como registros para, a instância CTMP Personalizadal2842 com a Classificação Objetiva dos Fatos. Portanto, as duas entradas modulares primárias da especificação CTMP 124 foram atendidas para esta instância CTMP Personal!zadal2842, o que lhe permite implementar um pensamento critico em relação à entrada e saída que é classificada como Fato Objetivo.
[1096] A Fig. 1109 continua o fluxo lógico da Fig. 1108, ilustrando as duas entradas modulares para, a instância CTMP Personalizadal2842, enquanto também mostra as duas ramificações principais para a operação CTMP 124: Execução de Regras (RE) C461 (Pensamento lógico) e Emulador de Observador de Percepção (POE) C47.5 (Pensamento intuitivo) . Nesse Estágio de operação, a instância CTMP Personalizada.12842 está operando sem. preconceito ou afinidade em relação ao correspondente Sistema de Reação de Personalidade 12812. A Saída de Decisão Crítica (CDO) C462 processa os duas Filiais C461/C475 da especificação CTMP 124. O aspecto destacado desta Fig. é que os Ângulos de Percepção C473/C472/C471/C470 habilitam as Filiais C461/C475 da especificação CTMP 124.
[1097] A Fig. 1110 continua o fluxo lógico da Fig.
Petição 870200056145, de 06/05/2020, pág. 628/1737
626/754
1109, elaborando, portanto, os detalhes referentes à operação do Estágio 12846 do DMT 12700. A. instância CTMP Personalizadal2842 opera dentro de uma instância da Renderização do Fluxo de Execução (ESR) 6400, produzindo o Resultado da Decisão do CTMP 12874 como saida modular. As duas entradas modulares para a instância CTMP Personalizada.12842 estão representadas nos Estágios 12868 (Proposição de Emulação 12864) e 12870 (Ambiente
de Emulação 12866). Os Estágios 12868 e j_ 2 <) 7 0 1 e van i á atualização
e conclusão do Estágio 12872, que repr θ s θ 111 a. a ex eci rção interna
da Sarda de Decisão Crí .tica (CDO) C462 para produz ir o Resultado
da Decisão CTMP 12874 Posteriormente s, é execut ad: o o Estágio
12 876, que < iescompacta a i n s t â n c _i a c o r respondente ac 3 Cenário de
Emulação Selecionado 12878 para produzir o Escopo de Resultado Aceitável 12880 definido. Este Escopo 12880 define um intervalo, com. um. limite superior e inferior, para o que o Resultado da Decisão CTMP 12874 seria considerado compatível com a personalidade do correspondente Sistema de Reação de Personalidade 12812. Portanto, o Prompt 12882 é ativado para verificar se o Resultado da. Decisão CTMP 12882 pertence ao Escopo de Resultado Aceitável 12880.
[1098] A Fig. 1111 continua o fluxo lógico da Fig. 1110, elaborando, portanto, os detalhes referentes à operação do Estágio 12846 do DMT 12700. Uma resposta Sim 12884 para o Prompt 12882 leva à execução do Estágio 12888. O Estágio 12888 confirma a instância dos Ângulos de Percepção C473/C472/C471/C470 da instância CTMP Personalizadal2842 no armazenamento persistente por meio do Tipo de Comando 6408 8 do Segmento de Dados de Escritura Persistente 6422 do ESR 6400. Isso faz com que
Petição 870200056145, de 06/05/2020, pág. 629/1737
627/754 quaisquer percepções de especificação CTMP 124 associadas e compatíveis com o Sistema de Reação de Personalidade 12812 sejam retidas permanentemente na instância CTMP Personal!zadal24. Se a resposta ao Prompt 12882 for Não 12886, as percepções correspondentes da instância dos Angulos de Percepção C473C472 /C471/C470 do CTMP Personalizado 12842 serão excluídas por meio do Tipo de Comando 6408 Segmento de Dados de Exclusão de Sessão 6424 do ESR 6400. Portanto, quaisquer percepções de especificação CTMP 124 que não confirmarem por meio de medidas de compatibilidade com o Sistema de Reação de Personalidade 12812 serão excluídas e, portanto, não serão retidas na instância CTMP
Person a .1 i z a d a 12 8 4 2 .
[1099] A Fig. 1112 continua o fluxo lógico da Fi
1111, elaborando, portanto, os detalhes referentes â operação do Estágio 12846 do DMT 12700. Se ocorrer o Estágio 12890, também ocorrerá o Estágio 5602, que envia uma Unidade de Registro de Diagnóstico (DLL) 1182 para o módulo de Registro de Envio de Diagnóstico (DLS) 1160. Isto permite que o módulo SPSI faça possíveis modificações na estrutura e operação do DMT 12700 e/ou CTMP 124 para permitir uma funcionalidade mais eficiente e produzir instâncias futuras dos programas. O Estágio 12888 e o 12890 invocam o Prompt 12892, que verifica se há algum Cenário de Emulação Relevante 12854 deixado no Loop iniciado pelo Estágio 12858. Se a resposta ao Prompt 12892 for Sim 12894, será invocado o Estágio 12898, que itera o Loop do Estágio 12858 para o próximo Cenário de Emulação Selecionado 12860 disponível. Se a resposta ao Prompt 12892 for Não 12896, o Estágio 12900 será ativado, finalizando a sequência de loop do Estágio 12858. Portanto, a
Petição 870200056145, de 06/05/2020, pág. 630/1737
628/754 ativação do Estágio 12900 implica a conclusão da operação do Estágio 12846.
[1100] A Fig. 1113 detalha a funcionalidade e operação do Estágio 12830 do DMT 12700. O Estágio 12902 envia um conjunto de Comandos Personalizados 12904 para a instância correspondente do ESR 6400, que registra a instância CTMP Personalizada 12842 ativa em uma Retenção do Appchain de Captura Instantânea do CTMP 12850. Portanto, no Estágio 12906, todas as percepções da instância C473/C472/C471/C470 dos Angulos da Percepção na instância CTMP Personalizada 12842 são retidas na recém-gravada Retenção de Captura Instantânea 12850. No Estágio 12908, a Retenção do Appchain de Captura Instantânea do CTMP 12850 é associada à correspondente Identidade da Mente Alvo 12816 e armazenada no módulo Retenção do Cache Instantâneo de Personalidade (PSCR) 12822. Portanto, o Retenção de Captura Instantânea 12850 pode ser recuperada posteriormente em correlação com a Identidade da Mente A_lvo 12816.
[1101] A Fig. 1114 continua o fluxo lógico do Rastreamento de Mente Digital (DMT) 12700, ilustrando assim os meios de invocação, processamento principal e produção de saida modular do módulo DMT 12700. No Estágio 12912, uma Solicitação de Emulação da Mente 12910 é recebida de um Usuário UBEC 106 invocado através do Módulo de Solicitação de Emulação da Mente (MERM) 12952. No Estágio 12914, a Solicitação de Emulação da Mente 12910 é descompactada para revelar as variáveis armazenadas: Cenário de Emulação Plausível 12916 e Identidade da Mente Alvo 12816. A Identidade da Mente Alvo 12816 refere-se a informações de identificação relativas à emulação da Mente Alvo
Petição 870200056145, de 06/05/2020, pág. 631/1737
629/754
12702 que o Usuário UBEC 106 está buscando direta ou indiretamente. O Cenário de Emulação Plausível 12916 é uma variável produzida pelo MERM 12952 para fornecer um. cenário de emulação para a versão renderizada da Mente Alvo 12702. Cada vez que o MERM 12952 é direta ou indiretamente invocado por um Usuário UBEC 106, o MERM 12952 invoca várias instâncias do DMT 12700, cada uma com um Cenário de Emulação Plausível diferente 12916.
Portantof a soma de todas as instân cias do DMT 12700 invocadas
leva a uma i reconstrução ac iequada da Mente T ílvo 12 7 02 na camada
de process sarnento do MERM 12952, c ) que 1 eva a uma resposta
unificada adequada à solic itação do Usuário UBEC 106. 0 Estágio
12918 recupera o Appchain 836 que lista todas as instâncias das Retenções de Cache Instantâneo de Personalidade (PSCR) 12822 disponíveis na rede BCHAIN Network 110. Posteriormente, o Prompt 12920 é ativado, verificando se existe urna instância do PSCR. 12822 no Appchain 836 recuperado do Estágio 12918 que corresponde à Identidade da Mente Alvo 12816. Uma resposta Não 12922 ao Estágio 12920 leva ao encerramento da execução modular da instância DMT 12700 no Estágio 12926 devido à indisponibilidade do Atendimento de Solicitação de Emulação. Uma resposta Sim 12924 ao Prompt. 12920 leva à execução do Estágio 12928, que recupera a instância PSCR 12822 correspondente que foi encontrada no Prompt 12920. O Estágio 12928 leva à ativação do Prompt 12930, que verifica se existe uma Captura. Instantânea de Personalidade 12850 na instância correspondente do PSCR 12822 para a Era do Tempo Definido (a Era do Tempo é definida na Identidade da Mente Alvo 12816). Se a resposta ao Prompt 12930 for Não 12932, o Estágio 12926 será ativado, finalizando a execução modular da instância
Petição 870200056145, de 06/05/2020, pág. 632/1737
630/754 atual do DMT 12700. Uma resposta Sim 12934 ao Prompt 12930 leva à execução do Estágio 12936, que invoca a Renderização de Reação de Personalidade (PR2) 12942 para processar a correspondente Captura Instantânea de Personalidade 12850 e o Cenário de Emulação Plausível 12916 que foi produzido pela instância MERM 12952 correspondente. Portanto, o PR2 12942 invoca a interpretação da Mente Alvo 12702 por meio da instância PSCR. 12822 correspondente, que mantém uma instância executável da CTMP Personalizada 12842.
[1102] A Fig. 1115 continua o fluxo lógico do Rastreamento de Mente Digital (DMT) 12700 no que diz respeito à invocação da Renderização de Reação de Personalidade (PR2) 12942. O DMT 12700 retoma da Fig. 1114 no Estágio 12936, onde a Captura Instantânea de Personalidade 12850 e o Cenário de Emulação Plausível 12916 são processados pela Renderização de Reação de Personalidade (PR2) 12942. Isso leva à execução do Estágio 12938, que extrai a Retenção do Appchain de Captura Instantânea CTMP 12850 relevante da instância correspondente da Retenção de Cache Instantâneo de Personalidade (PSCR) 12822 e envia a Retenção do Appchain 12850 como entrada modular para o PR2 12942. Portanto, o PR2 12942 é invocado no Estágio 12944, que envia a Retenção do Appchain 12850 para processamento pela Classificação do Fluxo de Dados (DSS) 6800, Coleta de Fluxo de Execução (ESC) 6700 e, portanto, Renderização do Fluxo de Execução (ESR) 6400. A instância CTMP Personalizada 12842 que corresponde à Retenção do Appchain 12850 da Captura Instantânea CTMP agora está sendo renderizada ativamente no ESR 6400. O Estágio 12946 invoca o encadeamento principal da instância. DMT 127 00 correspondente para.
Petição 870200056145, de 06/05/2020, pág. 633/1737
631/754 fornecer o Cenário de Emulação Plausível 12916 relevante para o PR2 12942 como entrada modular. Portanto, o Cenário de Emulação Plausível 12916 é enviado à instância CTMP Personalizada 12842 renderizada, pois representa os Ângulos de Percepção C473/C472/C471/C470 que representam a emulação da Mente Alvo 12702. No Estágio 12948, a instância CTMP Personalizada 12842 produz o Resultado da Percepção da Mente 12950, que é enviado como saída modular para a instância PR2 12942 e é retornado de volta ao segmento principal da instância. DMT 12700 correspondente. Portanto, o Resultado da Percepção da Mente 12950 é processado no Estágio 12940 da DMT 12700, que o envia para a instância correspondente do MERM 12 952 em. resposta à. Solicitação original da Emulação da Mente 12910.
[1103] [00] As Figs. 1116-1145 mostram a operação e a funcionalidade do Módulo de Solicitação de Emulação da Mente (MERM) 12 952, que opera como um mecanismo de invocação de encadeamento para o Rastreamento de Mente Digital (DMT) 12700.
[1104] A Fig. 11.16 mostra a operação e a funcionalidade do Módulo de Solicitação de Emulação da Mente (MERM) 12952. Um Usuário UBEC 106 pode invocar diretamente o MERM 12952 (e, portanto, o DMT 12700) por meio de urna plataforma intermediária simples 12954 (interface do usuário) ou indiretamente por meio de uma plataforma intermediária complexa e autônoma 12954. Um exemplo de uma Plataforma. Intermediária 12 954 é uma Estrutura de Dotação (ES) 12 008 para. NMC que invoca, o MERM 12952 e, portanto, o DMT 12700 para emular uma Mente Alvo 12700 especificada para aprovar as Medidas de Substituição 12388 especificadas. A Plataforma Intermediária 12954 produz uma.
Petição 870200056145, de 06/05/2020, pág. 634/1737
632/754
Definição de Cenário Complexa 12956 que é processada no Estágio 12958 para que seja fornecida a uma instância de Correspondência de Mapa de Necessidades (NMM) C114 para criar filiais jurisdicionais relativas a potenciais cenários que são derivados por essa Definição 12956. Posteriormente, é executado o Estágio 12960, que processa várias Sequências de Execução 12964 da Definição de Cenário Complexo 12956 via I2GE 122 e das filiais jurisdicionais formadas pela instância correspondente do NMM
C114. As Sequênci as de Exec ução 12964 representam vária .s maneiras
diferentes de a Definição Ο.Θ 0θΏ.3.ΖΊ o Complexo 12956 poder ser
executada. Os Cri .térios de Saturação 12962 que são env iados como
entrada modular p 3 I? 3. 3. instância da Ameaça de Segurança
Artificial (AST) 123 correspondente são posteriormente referenciados para avaliar se foi produzida uma quantidade suficiente de Sequências de Execução 12964. Portanto, o I2GE 122 pode discernir a quantidade de processo que precisa ocorrer para, produzir uma quantidade suficientemente estável de Sequências de E X e c u. ç ã. o 12 9 6 4 .
[1105] A Fig. 1117 mostra a operação e a funcionalidade da Correspondência de Mapa de Necessidades (NMM) C114 operando como um. submódulo de Shell Dinâmico C198 do LIZARD 120. A instância do NMM C114 é gerada para atender à operação do Estágio 12960 do Módulo de Solicitação de Emulação da Mente (MERM) 12952. A Definição de Cenário Complexo 12956 é enviada para armazenamento nas Necessidade de Acesso ao Desenvolvimento e Armazenamento 5550. Portanto, a Definição de Cenário Complexo 12956 é dividida em subcategorias e mantida no Armazenamento 5550 como uma série de filiais e camadas hierárquicas. Depois da
Petição 870200056145, de 06/05/2020, pág. 635/1737
633/754 invocação modular do NMM C114, a Análise Inicial C148 baixa cada filial de jurisdição do Armazenamento 5550 para reter temporariamente para referência na instância em. andamento do NMM C114. Com o Cálculo das Necessidades de Filiação C149: de acordo
com as definições associadas a cada filial, as necessidades são
associadas ao seu. departamento corr iespondente. Dessa. forma, as
verificações de permissão podem ser formadas na instância do NMM
C114. Por exemplo: 0 NMM C114 aprovou a solicitação do
departamento de Recursos Humanos pa: ra fazer o download de todos
os currículos dos empregados, porque foi solicitado dentro
zona da revisão anual do desempenho dos funcionários, de acordo
com. suas capacidades. Portanto, foi provado ser uma necessidade
válida da jurisdição do departamei ito. Portanto, o índice de
Necessidade C145 é ο orinciioal armazenamento das Filiais
Jurisdicionais e suas respectivas necessidades. Como essa
referência interna, é um gargalo de recursos para a operação do
NMM C114 e, portanto, todos os módulo s que atende, ela é otimizada
para consultas rápidas ao banco de dados para aumentar a
eficiência geral do sistema. 0 I2GE 122 fornece um Propósito de
Entrada C139 como entrada modular para o Algoritmo de Pesquisa C144 do NMM C114. O Algoritmo de Pesquisa C144 faz referência e pesquisa o índice de Necessidades C145 compilado, determinando,
portanto, se o Propósito de Entrada C139 define uma necessidade
válida de acordo com as filiais de jurisdição inicialmente
definidas nas Necessidade de Acn ssso ao Desenvolvimento e
Armazenamento 5550. Portanto, a exe cução completa do Algoritmo
de Pesquisa C144 por meio do índice : de Necessidade C145 produz
uma resposta de Aprovação/Bloqueio C14 6 que é enviada como saída.
Petição 870200056145, de 06/05/2020, pág. 636/1737
634/754 modular do NMM C114 e referenciada como Resultado da Necessidade C141. Portanto, o Resultado da Necessidade C141 é retornado ao I2GE 122 em. resposta ao envio do Propósito de Entrada C139.
[1106] A Fig. 1118 detalha os detalhes operacionais relativos ao Estágio 12960 do MERM 12952.
[1107] A Definição de Cenário Complexo 21956 é submetida ao módulo de Correspondência do Mapa de Necessidade (NMM) C114 do LIZARD 120 para produzir filiais de categorização jurisdicional. Essas filiais são descompactadas no Estágio 12966, o que leva à execução do Estágio 12968. No Estágio 12968, as filiais jurisdicionais da Definição de Cenário Complexo 12956 são instaladas como a geração base (Nl) de cada Trilha de Evolução C867A da instância I2GE 122 recém-invocada. Essa instalação ocorre através do Sistema de Interação de Monitoramento C868D do I2GE 122. Uma vez iniciada a emulação I2GE 122, a Trilha de Evolução C867A evolui de acordo com as definições correspondentes da Personalidade de Trilha C867D. Tais Personalidades de Trilha
C867D são instaladas no Estágio 12970 subsequente, que recebe a coleção de variáveis das Metodologias de Interpretação de Sequência 12972 e as instala como as Personalidades C867D correspondentes na instância I2GE 122. A variável. Metodologias 12972 é produzida e mantida sob a jurisdição do MERM 12952,
portanto o MERM 12952 já e :stá equipado em uma composição para
c ours mp .1. a r vários métodos e : estilos para interp '.retar sequências
de cenário s. Cada Trilha de Evolução C867A t é logisticamente
separada ρ elos outros via Isolamento Virtual ( 390 na instância
I2GE 122. Portanto, há. uma garantia implíc ?..ita de que os
resultados produzidos a par tir das Trilhas de E\ io! u ç a o C 8 6 / A s a o
Petição 870200056145, de 06/05/2020, pág. 637/1737
635/754 imparciais e não são afetados por outros fatores em potencial.
[1108] A Fig. 1119 detalha a funcionalidade e operação do Estágio 12960 do MERM 12952.
[1109] A Definição de Cenário Complexo 12956 está sendo emulada por várias Trilhas de Evolução C867A paralelas, que recebem testes ambientais pelo módulo 123 de Ameaça de Segurança Artificial (AST). Depois de concluir o processamento de emulação I2GE 122, os resultados são processados pelo processador Iteração Conclusão 5554, que envia a saida modular para o Prompt 12974. O Prompt 12974 avalia a quantidade de Sequências de Execução 12964 estabilizadas que foram produzidas pela sessão de emulação I2GE 122. A resposta ao Prompt 12974 é considerada Sim, Suficientemente Estável 12976 é os Critérios de Saturação 12962 são atendidos para a variação e estabilidade da Sequência de Execução 12964.
[1110] A Fig. 1120 descreve a funcionalidade das
Figs. 1118 e 1119, mostrando as várias Gerações 5658 que são construídas sequencialmente dentro da Trilha de Evolução C867. As filiais jurisdicionais que representam a Definição de Cenário Complexo 12956 e são produzidas pelo módulo de Correspondência de Mapa de Necessidades (NMM) C114 do LIZARD 120 correlacionam, e representam as Gerações 5658 sequenciais que são produzidas na sessão de emulação I2GE 122. Enquanto a sessão continua, y está hospedada na Rede BCHAIN 110, a Designação de Trilha 5650 representa os três estados que podem se tornar em uma trilha de Evolução C867:
[1111] Aprovado como Estável. 5652, Evolução Pendente 5654 e Abandonado/Excluído 5656. Uma Trilha C867 pode
Petição 870200056145, de 06/05/2020, pág. 638/1737
636/754 ser Excluída 5656 se a Personalidade de Trilha C867D correspondente exibir uma falha inerente na composição e/ou uma incompatibilidade inerente ao estado inicial da Trilha C867.
[1112] A Fig. 1121 continua o fluxo lógico do Módulo de Solicitação de Emulação da Mente (MERM) 12952.
[1113] 0 Estágio 12960 produz várias Sequências de Execução 12964 que são derivadas da Definição de Cenário Complexo 12956. No Estágio 12980, o LIZARD 120 é invocado para converter a Definição de Cenário Complexo 12956 em um Mapa de Hierarquia de Propósito 12982. No Estágio 12984, as Sequências de Execução 12984 são iteradas em um loop recentemente invocado. No Estágio 12986, o Mapa da Hierarquia de Propósito 12982 é clonado no conteúdo e referenciado como uma instância separada, rotulada como Mapa da Hierarquia de Propósito Base 12988. Esse Mapa 12988 é usado posteriormente como uma instância individual dentro de uma única iteração do Loop iniciada no Estágio 12984. Portanto, no início de cada iteração do Loop do Estágio 12984, o Mapa de Hierarquia de Propósito Base 12988 é redefinido para o conteúdo do Mapa de Hierarquia, de Propósito 12982. No Estágio 12992, o LIZARD 120 converte a Sequência de Execução Selecionada 12990 em um Mapa de Hierarquia de Propósito 12994.
[1114] A Fig. 1122 mostra detalhes sobre a operação do LIZARD 120 para converter a Definição de Cenário Complexo 12956 em um. Mapa de Hierarquia de Propósito 12982. A. Definição de Cenário Complexo 12956 é submetida ao Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura e escrita do código do computador. Para escrever código; ele recebe o Formato de
Petição 870200056145, de 06/05/2020, pág. 639/1737
637/754
Propósito Complexo C325 do Módulo de Propósito (PM) C36. 0 Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. 0 pseudocódigo contém implementações básicas das operações de computação mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Posteriormente, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação alvo desejada (linguagem de computador) . Para, leitura de código; 0 SM C35 fornece uma interpretação sintática do código do computador para o PM C36
para deri var um propó sito p ara a funcionalidade desse código. , A
TJef iniçãc de Cenário Compl exo 12956 é recebida no formato de
Sintaxe de Cenário 12 957 pela Conversão de ( lódigo C321. A
Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pelo SM C35 em qualquer linguagem, de computação conhecido e escolhido. A Conversão de Código C321 também executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saída da execução concluída da Conversão de Código C321 é transferida, como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas, segundo as definições de Regras e Sintaxe C322. Portanto, depois da execução completa da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma. Propósito no Formato de Propósito Complexo C325 do código do computador. Essa definição
Petição 870200056145, de 06/05/2020, pág. 640/1737
638/754 de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada por SM C35.
[1115] 0 PM C36 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A Interpretação Iterativa C328 circula em todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as A_ssociações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção automatazada/autoprogramação e é programada direta e exclusivamente por especialistas na área relevante. O elemento C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite operação e funcionalidade gerais para, o SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define Diretiva, de Segurança e Metas Corporativas. Essas definições operam como variáveis de política estática para orientar algumas funções dinâmicas e estáticas do LIZARD 120.
[1116] A Fig. 1123 continua o fluxo lógico da Fig. 1122 para ilustrar a operação do LIZARD 120 para converter a Definição de Cenário Complexa 12956 em um Mapa de Hierarquia de Propósito 12982. A. Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saída para a Interpretação Interativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula através de todas as funções interconectadas para produzir
Petição 870200056145, de 06/05/2020, pág. 641/1737
639/754 uma definição de propósito interpretada consultando Associações de Propósito C326. A saída de definição de propósito existe no Formato de Propósito Complexo C325, que é enviado como saída modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e, para o LIZARD 120. A saída é rotulada como um Mapa de Hierarquia de Propósito 12786, que é apresentada como a versão Formato de Propósito Complexo C325 da Definição de Cenário Complexo 12956. A mesma definição e aplicação do Núcleo Interno (IC) C333 aplica-se às funções e módulos mencionados acima.
[1117] A Fig. 1124 mostra detalhes sobre a operação do LIZARD 120 para converter a Sequência de Execução Selecionada 12990 em um Mapa de Hierarquia de Propósito 12994. A Sequência de Execução Selecionada 12990 é submetida ao Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura e escrita do código
do compi. itador. Para. escrever código ; ele recebe o Formato de
Propósit o Complexo C325 do Módulo de Propósito (PM) C36. 0
Formato de Propósito C omp .1 e x o C 3 2 5 é então escrito na sintaxe de
código arbitrária, também conhecid (a como /pseudocódigo' . 0
pseudocó digo contém implementações básicas das operações de
computação mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Posteriormente, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação alvo desejada (linguagem, de computador) . Para leitura de código; O SM C35 fornece uma. interpretação sintática do código do computador para o PM C36 para derivar um. propósito para a funcionalidade desse código. A Definição de Cenário Complexo 12956 é recebida no formato de
Petição 870200056145, de 06/05/2020, pág. 642/1737
640/754
Sintaxe de Cenário 12957 pela Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pelo SM C35 em qualquer linguagem, de computação conhecido e escolhido. A Conversão de Código C321 também executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saida da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas, segundo as definições de Regras e Sintaxe C322. Portanto, depois da execução completa da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para derivar uma. Propósito no Formato de Propósito Complexo C325 do código do computador. Essa definição de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada por SM C35.
[1118] O PM C36 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A Interpretação Iterativa C328 circula em. todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. O Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa, por manutenção automatizada/autoprogramação e é programada direta e exclusivamente por especialistas na área relevante. O elemento C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais,
Petição 870200056145, de 06/05/2020, pág. 643/1737
641/754
Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite a operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. 0 elemento Objetivos do Sistema C336 do IC C333 define Diretiva de Segurança e Metas Corporativas. Essas definições operam como variáveis de política estática para orientar algumas funções dinâmicas e estáticas do LIZARD 120.
[1119] A Fig. 1125 continua o fluxo lógico da Fig. 1124 para ilustrar a operação do LIZARD 120 para converter a Sequência de Execução Selecionada 12990 em. um Mapa de Hierarquia de Propósito 12994.
[1120] A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula em todas as funções interconectadas para produzir uma definição de propósito interpretado, pela. consulta das Associações de Propósito C326. A saída de definição de Propósito existe no Formato de Propósito Complexo C325, é enviado como saída modular para. PM C3 6 e, portanto, para o Núcleo Exterior (OC) C329 e, o LIZARD 120. A saída é rotulada como um Mapa de Hierarquia de Propósito 12994, que é apresentado como a versão do Formato de Propósito Complexa C325 da Sequência de Execução Selecionada. 12990. A mesma, definição e aplicação do Núcleo Interno (IC) C333 aplica-se âs funções e módulos mencionados acima.
[1121] A Fig. 1126 constrói os detalhes
Petição 870200056145, de 06/05/2020, pág. 644/1737
642/754 operacionais do Módulo de Solicitação de Emulação da Mente (MERM) 12952, continuando o fluxo lógico da Fig. 1121. Portanto, o fluxo lógico é retomado no Estágio 12992, que é onde o LIZARD 120 converte a Sequência de Execução Selecionada 12990 em um Mapa de Hierarquia de Propósito 12994. No Estágio 12996, o Mapa de Hierarquia de Propósito 12982 da Definição de Cenário Complexo 12956 e o Mapa de Hierarquia de Propósito 12994 da Sequência de Execução Selecionada 12990 são processados por meio de uma instância invocada de Propósito para o Processamento de Simetria de Propósito (P2SP) 7000, portanto, produz o Processamento de Simetria Resultado 12998. Isso leva à ativação do Prompt 13000, que interpreta o Resultado do Processamento de Simetria 12998, verificando se os dois Mapas de Hierarquia de Propósito 12982 e o 12994 são congruentes e compatíveis entre si. Uma resposta ao Prompt 13000 indicando Não, Não é Congruente 13004 é ilustrada na Fig. 1127. Uma resposta Sim, é Congruentel3002 leva, à ativação do Estágio 13006, que invoca o módulo de Processamento de Real.inham.ento de Propósito (PRP) 7050 para reajustar o Mapa de Hierarquia de Propósito 12994 da Sequência de Execução Selecionada 129990 para corresponder ao Mapa de Hierarquia de Propósito 12982 da Definição do Cenário Complexo 12956. Portanto, a variável Afinidade Mestre/Escravo 13008 é fornecida à instância correspondente do PRP 7050 como entrada modular para indicar que o Mapa 12 982 é o Escravo e o Mapa 1.2 994 é o Mestre. Tal Afinidade
13008 é definida como uma variável fixa de acordo com a estrutura.
do fluxo lógico.
Portanto, a conclusão do Estágio 13006 produz o
Cenário de Emulação Plausível 12916, que é referenciado para uso no Estágio 13012 da Fig. 1128.
Petição 870200056145, de 06/05/2020, pág. 645/1737
643/754
[1122] A Fig. 1127 continua o fluxo lógico da Fig.
1126 para ilustrar o fluxo lógico referente à resposta de Não, não Congruente 13004 em relação ao Prompt 13000. Posteriormente, ocorre o Estágio 5600, que envia uma Unidade de Registro de Diagnóstico (DLU) 1182 que contém o token oficial do sistema 1184. Este Token 1184 está incluído para indicar que a função ou programa correspondente atingiu um estado não ideal se uma função oficial entrar na Plataforma UBEC 100.
[112 3] O DLU 1182 é submetido ao módulo Envio de Registro de Diagnóstico (DLS) 1160, invocado pelo Mecanismo de Pesquisa Automatizado (ARM) 134 da LOM 132 para fornecer o DLU
1182 ao SPS — Ί 30. Portanto, o SPSI 13C ! é capaz de processar as
informações de diagnóstico encontradas na DLU 1160 com o módulo
de Análise da Unidade de Registro de Diagnóstico (DLUA) 8048.
Isso leva ao Estágio ' L3005, que representa o DLUA 8C )4 8 a ser
invocado para executar modificações correspondentes ao 12 GE 122
e/ou o MERM 12952, pa ra evitar o motivo inicial pel a qua 1 a
resposta Não, não é congruente 13004 foi invocada no Prompt 13000.
[1124] A Fig. 1128 continua o fluxo lógico do Módulo de Solicitação de Emulação de Mente (MERM) 12952, que é retomado da Fig. 1126. Depois que o Estágio 13006 conclui módulo de Processamento de Realinhamento de 7050 para o Mapa 12994, o Estágio 13010 é executado, recebendo a Identidade da Mente AfLvo 12816 como entrada modular para a instância MERM 12952 pelo Usuário UBEC 106 através da Plataforma Intermediária 12954. O Estágio 13012 é então processado para, empacotar a Identidade da Mente Alvo 12816 no Estagio 1300o a invocação do Propósito (PRP)
Petição 870200056145, de 06/05/2020, pág. 646/1737
644/754 e o Cenário Plausível de Emulação 12916 em uma Solicitação de Emulação da Mente 12910. No Estágio 13014, a Solicitação de Emulação da Mente 12910 é submetida à posição 12700 do Rastreamento da Mente Digital (DMT) correspondente. Portanto, o DMT 12700 estabelece o seu procedimento para produzir o Resultado da Percepção Mental 12950 como saída modular. No Estágio 130016, o Resultado da Percepção Mental 12950 é recebido da instância DMT 12700 e enviado como entrada do módulo para o Estágio 13018, que invoca o LIZARD para, convertê-lo em um Mapa, de Hierarquia de Propósito 13020.
125]
A. Fig. 1129 continua o fluxo lógico do MERM
1128 .
Estágio 13018 produz o Mapa d<
Hierarquia de Propósito 13020 a partir do Resultado da Percepção Mental 12950. No Estágio 13022, o LIZARD 120 converte o cenário de emulação plausível 12916 em um Mapa de Hierarquia de Propósito
13024. O stág
Simetria de Propósito (P2SP) 7000 para processar os Mapas 13020 e 13024, produzindo, portanto, o Resultado do Processamento de Simetria 13028. No Prompt 13030, o Resultado 13028 é analisado para interpretar se o Mapa da Hierarquia de Propósitos 13020 do Resultado da Percepção Mental 12950 é congruente/compatível com o Mapa da Hierarquia de Propósitos 13024 do Cenário de Emulação Plausível 12916. Se a resposta ao Prompt 1.3030 for Não, Não é Congruente 13034, o fluxo lógico seguirá o mesmo procedimento mostrado na resposta Não, Não é Congruente 13004 da Fig. 1127 que indica que, no Estágio 5602, um (DLL) 1182 é enviado ao módulo de Envio de Registro de Diagnóstico (DLS) 1160. O fluxo
Petição 870200056145, de 06/05/2020, pág. 647/1737
645/754 lógico referente à resposta Sim, é Congruente 13032 ao Prompt 13030 é mostrado na Fig. 1134.
[1127] A Fig. 1130 mostra detalhes sobre a operação do LIZARD 120 para converter o Resultado da Percepção Mental 12950 em um Mapa de Hierarquia de Propósitos 13020. O Resultado da Percepção Mental 12950 é enviada para o Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura e escrita de código de computador. Para escrever o código; recebe o Formato de Propósito Complexo C325 do Módulo de Propósito (PM) C36. O Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém implementações básicas das operações de computação que são mais comuns entre todas as linguagens de programação, como
instruções if /else, loops etc. Posteriormente, ums 1 função
auxiliar conv< srte o pseud o c ó d i g o e m c ó d i g o e x e c u t á v el real.
dependendo da sintaxe de computação ! de alvo desejada (I Linguagem
do computador) Para leitura de c.í cdigo; 0 SM C35 for nece uma
i n t e r p r e t a ç ã o s i n t a 11 ca do código do computador para o PM C36
para derivar um propósito para a funcionalidade desse código. A Definição de Cenário Complexo 12956 é recebida no formato de Sintaxe de Cenário 12957 pela Conversão de Código C321.
[1128] A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e compreendido pela SM C35 em qualquer linguagem de computação conhecido e escolhido. A Conversão de Código C321 também executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saída da execução concluída da Conversão de Código
Petição 870200056145, de 06/05/2020, pág. 648/1737
646/754
C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas de acordo com as definições de Regras e Sintaxe C322. Portanto, depois da execução completa da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma. Propósito no Formato de Propósito Complexo C325 do código do computador. Essa definição de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada pelo SM C35. 0 PM C36 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção automatizada/autoprogramação e é direta, e exclusivamente programada por especialistas relevantes no campo. O elemento C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a Política, de Segurança e Objetivos da Empresa.
Petição 870200056145, de 06/05/2020, pág. 649/1737
647/754
Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1129] A Fig. 1131 continua o fluxo lógico da Fig.
1130 para ilustrar a operação do LIZARD 120 para converter o Resultado da Percepção da Mente 12950 em um Mapa de Hierarquia de Propósitos 13020. A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula através de todas as funções interconectadas para produzir uma definição de propósito interpretada consultando Associações de Propósito C326. A saída de definição de propósito existe no Formato de Propósito Complexo C325, que é enviado como saída modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e, para o LIZARD 120. A saída é rotulada como um Mapa de Hierarquia de Propósito 13020, que é apresentada como a versão do Formato de Propósito Complexo C325 do Resultado da Percepção Mental 12950. A mesma definição e aplicação do Núcleo Interno (IC) C333 aplica-se às funções e módulos mencionados acima.
[1130] A Fig. 1132 mostra detalhes sobre a operação do LIZARD 120 para converter o Cenário de Emulação Plausível
12 916 em um Mapa d? e Hierarquia de ' Propôsi to 13024. 0 C e n á r i o de
Emulação Plausível 12916 é submetí do ao 1' iódulo de Sintaxe 3M)
C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. 0
SM C35 fornece uma estrutura para 1 eitura e escrita de código de
computador. Para, escrever o código; ele recebe o formato de
Propósi to Complexo C325 do Módulo de Propósito (PM) C36. 0
Formato de Propósito Complexe 7 C325 é ent ão escrito na sintaxe de
código arbitrária, também conhecida como /pseudocódigo' . 0
Petição 870200056145, de 06/05/2020, pág. 650/1737
648/754 pseudocódigo contém implementações básicas das operações de computação que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Posteriormente, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação alvo desejada (linguagem de computador) . Para leitura de código; 0 SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar um propósito para a funcionalidade desse código. A Definição de Cenário Complexo 12956 é recebida no formato de Sintaxe de Cenário 12957 pela Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pelo SM C35 em qualquer linguagem de computação conhecido e escolhido. A Conversão de Código C321 também executa a função inversa de converter linguagens de computação conhecidas em. tipos de sintaxe arbitrários. A saida da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas, segundo as definições de Regras e Sintaxe C322. Portanto, depois da execução completa da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35
Θ Θ nviada para a Interpretação Iterativa C Í328 dO Módulo de
Pro'f (PM) C36. 0 PM C36 usa o SM C35 par a de irivar uma
ProT 2>ÓSÍtO no Formato de Propósito Complexo C32 5 do código do
computador . Essa definição de propósito descre \/ oL dequ adament e a
f une ?.i ona l i dade pretendida da seção de código ϊ ?elev ante , conto rme
é interpretada por SM C35.
Petição 870200056145, de 06/05/2020, pág. 651/1737
649/754
[1131] 0 PM C36 também, é capaz de detectar fragmentos de código que estão secretamente imersos em dados (binários/ASCII etc.) . A. Interpretação Iterativa C328 circula em. todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção automatizada/autoprogramação e é programada direta e
exclusivamente por especú talistas na área relevante. 0 elemento
C335 do IC C333 contém l· iistrutur as e Bibliotecas Ft mdamentais,
Scripts de Gestão de Tópicos e Balanceamento de Cargas,
Protocolos de Comunicai ção e Criptografia e S istemas de
Gerenciamento de Memória. Portanto, o Código Principal C335 permite operação e funcionalidade gerais para o SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem, a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define Diretiva de Segurança e Metas Corporativas. Essas definições operam, como variáveis de política estática para orientar algumas funções dinâmicas e estáticas do LIZARD 120. [1132] A Fig. 1133 continua o fluxo lógico da Fig.
1132 para ilustrar a operação do LIZARD 120 para converter o Cenário de Emulação Plausível 12916 em um Mapa de Hierarquia de Propósito 13024.
[1133] A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula em todas as funções interconectadas para produzir uma definição de propósito interpretado, pela consulta
Petição 870200056145, de 06/05/2020, pág. 652/1737
650/754
Associações de Propósito C326. A saída de definição de Propósito existe no Formato de Propósito Complexo C325, é enviado como saída modular para PM C3 6 e, portanto, para o Núcleo Exterior (OC) C329 e, o LIZARD 120. A saída é rotulada como um Mapa de Hierarquia de Propósito 13024, que é apresentada como a versão do Formato de Propósito Complexo C325 do Cenário de Emulação Plausível 12916. A mesma definição e aplicação do Núcleo Interno (IC) C333 aplica-se às funções e módulos mencionados acima.
[1134] A Fig. 1134 continua o fluxo lógico do Módulo de Solicitação de Emulação da Mente (MERM) 12952 da Fig. 1129. A resposta Sim, é Congruente 13032 ao Prompt 13030 leva à execução do Estágio 13036. O Estágio 13036 ajusta o Mapa de Hierarquia de Propósito 13024 do Cenário de Emulação Plausível 12916 para corresponder ao Mapa de Hierarquia de Propósito 13024 do Resultado da Percepção da Mente 13036 por meio do módulo 7050 de Processamento de Realinhamento de Propósito (PRP). A Afinidade Mestre/Escravo 13038 é enviada à instância correspondente do PRP 7050 como entrada modular para incitar que o Mapa 13024 seja designado Escravo e o Mapa 13020 seja designado Mestre. Portanto, o Estágio 13036 produz o Cenário de Emulação Cumprido 13040, que representa o cumprimento da Mente Alvo 12702 do cenário potencial que existia na variável Cenário de Emulação Plausível 12916. No Estágio 13042, o Mapa de Hierarquia de Propósito Base 12988 da Definição de Cenário Complexo 12956 e o Cenário de Emulação Cumprido 13040 são processados pelo Propósito do Processamento de simetria de Propósito (P2SP) 7000 para produzir o Resultado de Processamento de Simetria 13044.
[1135] A Fig. 1135 continua o fluxo lógico do MERM
Petição 870200056145, de 06/05/2020, pág. 653/1737
651/754
12952 da Fig. 1134 no Estágio 13042. Depois do Estágio 12042 produzir o Resultado do Processamento de Simetria 13044, ο Resultado 13044 é submetido ao Prompt 13046. O Prompt 13046 interpreta a congruência e a compatibilidade entre o Cenário de Emulação Cumprido 13040 e o Mapa de Hierarquia de Propósito Base 12988 da Definição de Cenário Complexo 12956. Se a resposta ao Prompt 13046 for Não, Não é Congruente 13050, o fluxo lógico seguirá o mesmo procedimento mostrado na resposta Não, Não é Congruente 13004 da Fig. 1127, que indica que, no Estágio 5602, um DLU 1182 é enviado ao módulo de Envio de Registro de Diagnóstico (DLS) 1160. Se a resposta ao Prompt 13046 for Sim, é Congruente 13048, ocorrerá o Estágio 13052, que invocará o Processamento de Realinhamento de Propósito (PRP) 7050 para ajustar o Mapa de Hierarquia de Propósito Base 12988 da Definição de Cenário Complexo 12956 para corresponder ao Cenário de Emulação Cumprido. Portanto, a Afinidade Mestre/Escravo 13054 é fornecida à instância PRP 7050 correspondente como entrada modular para definir o Mapa de Hierarquia de Propósito Base 1988 como o Escravo e o Cenário de Emulação Cumprido 13040 como Mestre.
[1136] A. Fig. 1136 continua o fluxo lógico do MERM 12952 da Fig. 1135 no Estágio 13052. A execução do Estágio 13052, conforme demonstrado na Fig. 1135, produz o Mapa de Propósito A_tualizado 13056 como saída modular. No Estágio 13058, o Mapa de Propósito Atualizado 13056 substitui. o Mapa de Hierarquia de Propósito base 12988 da Definição de Cenário Complexo 12956. Portanto, conclui a iteração do Loop, de modo que o Prompt 12060 interpreta se o Loop do Estágio 12984 tem quaisquer Sequências de Execução restantes que ainda não foram processadas. Uma.
Petição 870200056145, de 06/05/2020, pág. 654/1737
652/754 resposta Sim 13062 ao Prompt 13060 faz com que o Estágio 13066 avance o Loop para a próxima Sequência de Execução disponível no Estágio 12984. Uma resposta Não 13064 ao Prompt 13060 leva ao Estágio 13068 a invocar o LIZARD 120 para converter o Mapa de Hierarquia de Propósito Base 12988 na Sintaxe do Appchain (e, portanto, não está mais no Formato de Propósito).
[1137] A Fig. 1137 mostra detalhes da operação do LIZA.RD 120 para converter o Mapa de Hierarquia de Propósito Base 12988 da Definição de Cenário Complexo 12956 na Sintaxe da Appchain. O Mapa 12988 existe no Formato de Propósito Complexo C325 e é submetido à Expansão Iterativa C327 do Módulo de Propósito C36 dentro do Núcleo Exterior (OC) C329 do LIZARD 120. A Expansão Iterativa C327 adiciona detalhes e complexidade para desenvolver um objetivo simples (indiretamente definido no Mapa 12174) em. uma definição específica do propósito complexo. Portanto, o potencial máximo da Associação de Propósito C326 da entrada é realizado e mantido como um Formato de Propósito Complexo C325, antes de ser submetido à Derivação Lógica C320 do Módulo de Sintaxe (SM) C35. O elemento Código Principal C335 do Núcleo Interior (IC) C333 contém Estruturas e Bibliotecas fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória Portanto, o Código Principal C335 permite operação e funcionalidade gerais para o SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define Diretiva de Segurança e Metas Corporativas. Essas definições operam como variáveis de política estática, para.
Petição 870200056145, de 06/05/2020, pág. 655/1737
653/754 orientar algumas funções dinâmicas e estáticas do LIZARD 120.
[1138] A. Fig. 1138 continua o fluxo lógico da Fig.
1137 para ilustrar a operação do LIZARD 120 para converter o Mapa de Hierarquia de Propósito Base 12988 na Sintaxe do Appchain que é referida como P.etenção Atualizada do Appchain 12188. Os dados de entrada são recebidos no Formato de Propósito complexo C325 do Módulo de Propósito (PM) C36 e são transferidos para a Derivação Lógica 0320 do Módulo de Sintaxe (SM) C35. A Derivação Lógica C320 deriva funções logicamente necessárias de funções
inic :ialmente maií 5 simples. Isso significa que s* e uma funçã< o puder
ser formada como uma função derivada devido à implicação de uma
f une ;ão pai mais simples; então é formado pela Derivação Lógica
0320. O resultado produzido é uma árvore de dependências de funções construídas de acordo com os dados definidos Pelo Formato de Propósito Complexo 0325. A Derivação Lógica 0320 opera de acordo com as definições de Regras e Sintaxe 0322 que são herdadas do elemento Código Principal 0335 do Núcleo Interior (10) 0333. A Derivação Lógica 0320 envia sua saída para a Conversão de Código 0321. A Conversão de Código 0321 converte código arbitrário (genérico) que é reconhecido e compreendido pela SM 035 em qualquer linguagem de computação conhecido e selecionado. A Conversão de Código 0321 também executa a função inversa de conversão de linguagens de computação conhecidas em tipos de sintaxe arbitrários. Portanto, o PM 036 invoca o SM 035 para produzir a Versão da sintaxe do Appchain 12188 resultante da Definição de Cenário Complexo 12988 de entrada através da Conversão de Código 0321. A Retenção Atualizada do Appchain 12188 resultante, produzida de forma terminal pela. Conversão de Código
Petição 870200056145, de 06/05/2020, pág. 656/1737
654/754
C321, é a saída modular do SM c35, o Núcleo Exterior (OC) C329 e o LIZARD 120.
[1139] A Fig. 1139 continua o fluxo lógico do MERM 12952 da Fig. 1136 no Estágio 13068. O Estágio 12068 produz a Retenção do Appchain Atualizada 12188, que é enviada como entrada modular ao Conjunto de Patches de Implantação (DPA) 6260 para referência posterior no Estágio 13078. No Estágio 12070, o LIZARD 120 converte o Mapa de Hierarquia de Propósito 13072 na Sintaxe do Appchain, produzindo, portanto, a Retenção do Appchain
Original 130 /4 como saída modular . A Retenção do Appchain 13074
original também é env iada ao DPA 6260 como entr ada modul ar. 0
Estágio 1.307 8 é então processado para invocar o DPA 6260 para
produzir a Trilha de Correção do Appchain 13 C )7 6 como saída
modular das entradas modulares 12188 e 13074. , A Trill ia de
Correção d.O Appchain 1.307 6 é en tão convertida na Sintaxe de
Cenário pelo LIZARD 120 no Estági .o 13080. Portanto, no Es tágio
13082, a Resposta de Emulação da Mente 13084 é submetida ao Usuário UBEC 106 através da Plataforma Intermediária 12954.
[1140] A Fig. 1140 mostra detalhes sobre a operação do LIZARD 120 para converter o Mapa de Hierarquia de Propósito 13072 da Definição de Cenário Complexo 12956 Na Sintaxe do Appchain. O Mapa 13072 existe no Formato de Propósito Complexo C325 e é submetido à Expansão Iterativa C327 do Módulo de Propósito C36 dentro do Núcleo Exterior (OC) C329 do LIZARD 120. A Expansão Iterativa C327 adiciona detalhes e complexidade para, desenvolver um objetivo simples (definido indiretamente dentro do Mapa 12174) em. uma definição específica de Propósito complexa. Portanto, o potencial máximo da Associação de Propósito C326 da
Petição 870200056145, de 06/05/2020, pág. 657/1737
655/754 entrada é realizado e mantido como um Formato de Propósito Complexo C325, antes de ser submetido â Derivação Lógica C320 do Módulo de Sintaxe (SM) C35. 0 elemento Código Principal C335 do Núcleo Interior (IC) C333 contém Estruturas e Bibliotecas fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória Portanto, o Código Principal C335 permite operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. 0 elemento Objetivos do Sistema C336 do IC C333 define a Politica de Segurança e Objetivos da Empresa. Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1141] A. Fig. 1141 continua o fluxo lógico da Fig. 1140 para ilustrar a operação do LIZARD 120 para converter o Mapa de Hierarquia de Propósito 13072 na Sintaxe do Appchain, referenciada como Retenção original do Appchain 13074.Os dados de entrada são recebidos no Módulo de Propósito Complexo C325 do Módulo de Propósito (PM) C36 e são transferidos para a Derivação Lógica C320 do Módulo de Sintaxe (SM) C35 . A Derivação Lógica C320 deriva funções logicamente necessárias de funções inicialmente mais simples. Isso significa que se uma função puder ser formada como uma função derivada devido à implicação de uma
função pai ma .is simples; então é formado pela Derivação Lógica
C320. 0 resu Itado produzido é t ima árvor e de dependências de
funções const: ruídas de acordo com os dados de f in idos Pelo Formato
de Propósito C omp 1 e x o C 3 2 5 . A D erivação Logic :a C32 0 opera de
acordo com as definições de Regras e Sintaxe C322, que são
Petição 870200056145, de 06/05/2020, pág. 658/1737
656/754 herdados do elemento Código Principal C335 do Núcleo Interior
(IC) C333. A Derivação Lógica C320 submete sua saida para a
Conversão de Código C32Í .. A Conversão do Código C321 converte
código arbitrário (genér ?ico), reconhecido e entendido pelo SM
em qualquer linguagem de computação conhecido e escolhido. A
Conversão de Código C32 1 também executa a função inversa de
conversão de linguagens de computação conhecidas em tipos de
sintaxe arbitrários. Por (tanto, o PM C36 invoca o SM C35 para
produzir a Versão da Sintaxe do Appchain 13074 resultante da
Definição de Cenário Complexo 12988 de entrada por meio da
Conversão de Código C321 . A Retenção do Appchain Original 13074
resultante, produzida de forma terminal pela Conversão de Código
C321, é a saida modular < de SM C35, do Núcleo Exterior (OC) C329
e do LIZARD 120.
[1142] A Fig. 1142 mostra detalhes sobre a operação do LIZAJRD 120 para converter a Trilha, de Correção do Appchain 13076 em um Mapa de Hierarquia de Propósito 13086. A Trilha de Correção do Appchain 13076 é enviada para o Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura e escrita de código de computador. Para escrever código; ele recebe o Formato de
Propósito Cc emplexo C325 do Módulo de Propósito (PM) C36. 0
Formato de P ropósito Complexo C325 é então escrito na sintaxe de
código arbi trária, também conhecí da como ''pseudocódigo' . 0
P s o udo co di ei o contém i mp1eme n t a çõ e s básicas das operações de
computação mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Depois, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da
Petição 870200056145, de 06/05/2020, pág. 659/1737
657/754 sintaxe de computação alvo desejada (linguagem do computador). Para leitura de código; 0 SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar um. propósito para a funcionalidade desse código. A Trilha de Correção do Appchain 13076 é recebida no formato de Sintaxe de Percepção 5638 pela Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pelo SM C35 em qualquer linguagem de computação conhecido e escolhido. A Conversão de Código C321 também executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A. saida da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas, segundo as definições de Regras e Sintaxe C322 . Portanto, depois da execução completa, da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para derivar uma Propósito no Formato de Propósito Complexo C325 do código do computador. Essa definição de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada por SM C35.
[1143] O PM C3 6 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A Interpretação Iterativa C328 circula em todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325),
Petição 870200056145, de 06/05/2020, pág. 660/1737
658/754 consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção automiati zada/autoprogramação e é programada direta e exclusivamente por especialistas na área relevante. O elemento Código Principal C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite operação e funcionalidade gerais para o SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define Diretiva de Segurança e Metas Corporativas. Essas definições operam como variáveis de política estática para orientar algumas funções dinâmicas e estáticas do LIZARD 120.
[1144] A Fig. 1143 continua o fluxo lógico da Fig. 1132 para ilustrar a operação do LIZARD 120 para converter a Trilha de correção do Appchain 13076 em um Mapa de Hierarquia de Propósitos 13086. A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saída para, a Interpretação Iterativa C32 8 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula em todas as funções interconectadas para produzir uma definição de propósito interpretado, pela consulta das Associações de Propósito C326. A saída de definição de Propósito existe no Formato de Propósito Complexo C325, é enviado como saída modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e, o LIZARD 120. A. saída é rotulada como um Mapa de Hierarquia de Propósito 13086, que é apresentada como a versão do Formato de Propósito Complexo C325 da Trilha de Correção do Appchain 13076.
Petição 870200056145, de 06/05/2020, pág. 661/1737
659/754
A mesma definição e aplicação do Núcleo Interno (IC) C333 aplicase às funções e módulos mencionados acima.
[1145] A Fig. 1144 mostra detalhes sobre a operação do LIZARD 120 para converter o Mapa de Hierarquia de Propósito 13086 do Patch de Correção do Appchain 13076 na Sintaxe de Correção de Cenário. O Mapa 13086 existe no Formato de Propósito Complexo C325 e é submetido à Expansão Iterativa C327 do Módulo de Propósito C36 dentro do Núcleo Exterior (OC) C329 do LIZARD 120. A Expansão Iterativa. C327 adiciona detalhes e complexidade para evoluir um objetivo simples (indiretamente definida no Mapa 13086) em uma definição de propósito complexo especifica. Portanto, o potencial, máximo da Associação de Propósito C32 6 da entrada é realizado e mantido como um Formato de Propósito Complexo C325, antes de ser submetido à Derivação Lógica C320 do Módulo de Sintaxe (SM) C35. O elemento Código Principal C335 do Núcleo Interior (IC) C333 contém Estruturas e Bibliotecas fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C3 35 permite operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem, a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a Política de Segurança e Objetivos da Empresa. Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1146] A. Fig. 1145 continua o fluxo lógico da Fig. 1144 para ilustrar a operação do LIZARD 120 para converter o Mapa de Hierarquia de Propósito 13086 na Sintaxe do Cenário que é
Petição 870200056145, de 06/05/2020, pág. 662/1737
660/754 referenciado como a Resposta de Emulação da Mente 13084. Os dados de entrada são recebidos no Formato de Propósito complexo 0325 do Módulo de Propósito (PM) C3 6 e são transferidos para a Derivação Lógica 0320 do Módulo de Sintaxe (SM) 035. A Derivação Lógica 0320 deriva funções logicamente necessárias de funções inic.ialm.ente mais simples. Isso significa que se uma função puder ser formada como uma função derivada devido à implicação de uma função pai mais simples; então é formado pela Derivação Lógica 0320. 0 resultado produzido é uma árvore de dependências de funções construídas de acordo com os dados definidos Pelo Formato de Propósito Complexo 0325. A Derivação Lógica 0320 opera de acordo com as definições de Regras e Sintaxe 0322, que são herdados do elemento Código Principal 0335 do Núcleo Interior (IC) 0333. A Derivação Lógica 0320 submete sua saída para a Conversão de Código 0321. A Conversão do Código 0321 converte código arbitrário (genérico), reconhecido e entendido pelo SM 035 em qualquer linguagem de computação conhecido e escolhido. A Conversão de Código 0321. também executa a função inversa de conversão de linguagens de computação conhecidas em tipos de sintaxe arbitrários. Portanto, o PM 036 invoca o SM 035 para produzir a Versão da Sintaxe do Cenário 13084 resultante da Trilha de Correção do Appchain 13076 via Conversão de Código 0321. A resultante Resposta de Emulação da Mente 13084 que é produzida terminalmente pela Conversão do Código 0321 é a saída modular do SM 035, do Núcleo Exterior (00) 0329 e do LIZARD 120.
[1147] [00] Figs. 1146 - 1183 mostram a operação e a funcionalidade do módulo 1.30 90 do Aprimoramento do Mapeamento Neuro Econômico (NME), que associa os Padrões Neurais 13094 da
Petição 870200056145, de 06/05/2020, pág. 663/1737
661/754
Mente Alvo 12702 aos estados físicos de existência que são capturados no Estado Circunstancial Alvo 13100.
[1148] A Fig. 1146 apresenta o módulo 13090 do Aprimoramento do Mapeamento Neuro Econômico (NME). O Dispositivo de Varredura Neural Discreta (UNSD) 13092 recebe um Padrão Neural em Bruto 13094 da Mente Alvo 12702 que está agindo na sua capacidade como Usuário UBEC 106. O Target Mind 12702, sendo um Usuário UBEC 106, permite que comunicações internas padronizadas da API sejam feitas através da Rede BCHAIN 110 ao módulo UNSD 13092. Portanto, no Estágio 13096, é recebido o Padrão Neural em Bruto 13094 do Usuário UBEC 106 via UNSD 13092. No Estágio 13098, o LOM 132 relata no Estado Circunstancial Alvo 13100 e na Confiança 13102 do Usuário UBEC 106 por meio do correspondente Perfil de Inteligência Pessoal (PIP) 136 e da Automatização da Gestão de Vida (LAA) 138. Portanto, o LOM 132 produz o Estado Circunstancial Alvo 13100 com base nos dados fornecidos pelo PIP 136, que retém informações pessoais relacionadas ao Usuário UBEC
10 6 alvo e LAA 138, que conecta o estilo de vida digital, do
Usuário 106 UBEC por meio da interação da Internet das Coisas
(loT ) . Por exemplo: o carr o habilitado com 1 oT que te: m o Usuário
UBEC 106 está relatando via LAA 138 que o Usuário UBEC 106 está a dirigir e está atualmente preso no trânsito. Assim, essas informações de exemplo são incluídas no Estado Circunstancial Alvo 13100, produzido pela LOM 132. A Confiança do Estado Circunstancial Alvo 13102representa o grau de confiança, que o LOM 132 gerou com tais variáveis em relação ao Estado Círcunstancial 13100. Por exemplo: quão confiante é o LOM 132 e, por extensão, o LAA 138, de que o Usuário UBEC 106 é realmente o
Petição 870200056145, de 06/05/2020, pág. 664/1737
662/754 motorista do carro e que o carro está realmente preso no trânsito. No Estágio 13104, a LOM produz o Conhecimento 13108 da Associação do Estado Neural, que representa correlações aprendidas entre o Estado Neural em potencial e o Estado Circunstancial em potencial. A Confiança de Conhecimento da Associação de Estado Neural 13106 se correlaciona com. a confiança algorítmica que o LOM 132 tem em relação à precisão e confiabilidade do Conhecimento da Associação de Estado Neural 13108. No Estágio 13110, o LIZARD 120 converte o Conhecimento da Associação de Estado Neural 13108 em um Mapa de Hierarquia de Propósito 13112.
[1149] A. Fig. 1147 mostra detalhes do Estágio 13104 da NME 1.3090, onde o LOM 132 produz o Conhecimento da Associação do Estado Neural 13108 da CKR 648. O LOM 132 é invocado para produzir esse Conhecimento 12370 pelo módulo 5640 do Prompt de Invocação de Conhec.im.ento (KIP) . O Conhecimento de Conformidade Regulatória. 12370 é ilustrado como sendo construído com várias instâncias dos Clusters UKF C854F. O elemento individual do UKF
Cluster C854F é elaborado em detalhes sendo feito das subunidades UKF1, UKF2 e UKF3 que são armazenadas no Formato de Sintaxe de Regra C538.
[1150] A Fig. 1148 mostra detalhes da operação do LIZARD 120 para converter o Conhecimento da Associação do Estado Neural 13108 em um Mapa de Hierarquia de Propósito 13112. O Conhecimento 13108 da Associação do Estado Neural é enviada para o Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura e escrita de código de computador. Para escrever código; ele recebe o Formato de Propósito Complexo C325 do Módulo de
Petição 870200056145, de 06/05/2020, pág. 665/1737
663/754
Propósito (PM) C36. 0 Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. 0 pseudocódigo contém, implementações básicas das operações de computação que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Posteriormente, uma função auxiliar converte o pseudocódigo em. código executável real, dependendo da sintaxe de computação alvo desejada (linguagem de computador). Para leitura de código; o SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar um propósito para a funcionalidade desse código. A Trilha Patch de Correção do Appchain 13076 é recebida no formato de Sintaxe de Percepção 5638 pela Conversão de código C321. A Conversão do Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pelo SM C35 em qualquer linguagem de computação conhecido e escolhido. A Conversão de Código C321 também executa, a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saída da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas simples para produzir um mapa de funções interconectadas, de acordo com. as definições das Regras e Sintaxe C322. Portanto, após a execução completa da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para derivar uma Propósito no Formato de Propósito Complexo C325 do código do computador. Essa definição de propósito descreve adequadamente a
Petição 870200056145, de 06/05/2020, pág. 666/1737
664/754
funciona li da; ie pretendida da seção de código relevante, conforme
é interpreta· da por SM C35. 0 PM C36 também é capaz de detectar
fragmentos d .e código que são secretamente submersos em dados
(binários/AS í SII etc.). A Interpretação Iterativa C328 percorre
todas as fun· ções interconectadas para produzir uma definição de
propósito in' terpretada (no Formato de Propósito Complexo C325),
consultando as Associações de Propósito C326. 0 Núcleo Interno
(IC) C333 é a área do LIZARD 120 que não passa por manutenção
a u t omá t i c a / a i atoprogramação e é direta e exclusivamente
programada por especialistas na área relevante. 0 elemento código
Princioal C335 do IC C333 contém Estruturas e Bibliotecas
Fundament a.i s, , Scripts de Gestão de Tópicos e Balanceamento de
as, Protocolos de Comunicação e Criptografia e Sistemas de
Gerenciamento 3 de Memória. Portanto, o Código Principal C335
permite operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. 0 elemento Objetivos do Sistema C336 do IC C333 define a Política de Segurança e os Objetivos da Empresa.
Essas defini ções funcionam como variáveis de política estática.
p 3. Γ â OI? ZL θ Γ1 u a. J r várias funções dinâmicas no LIZARD 120.
I J- J L51] A Fig. 1149 continua o fluxo lógico da Fig.
1148 para ilustrar a operação do LIZARD 120 para converter o
Conhecimento da Associação do Estado Neural 13108 em um Mapa de
Hierarquia d< e Propósito 13112. A Redução Lógica C323 do Módulo
de Sintaxe (SM) C35 envia, sua saída para a Interpretação
Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação
iterativa C3Í 28 circula em todas as funções interconectadas para
produzir uma definição de propósito interpretado, pela, consulta.
Petição 870200056145, de 06/05/2020, pág. 667/1737
665/754 das Associações de Propósito C326. A saída de definição de
Propósito existe no Formato de Propósito Complexo C325, é enviado como saída modular para PM C3 6 e, portanto, para o Núcleo Exterior (OC) C329 e, o LIZARD 120. A saída é rotulada como um Mapa de Hierarquia de Propósito 13112, que é apresentado como a versão do Formato de Propósito Complexo C325 do Conhecimento da Associação do Estado Neural 13108. A mesma definição e aplicação do Núcleo Interno (IC) C333 aplica-se às funções e módulos mencionados acima.
[1152] A Fig. 1150 continua o fluxo lógico do A_primoramento de Mapeamento Neuro econômico (NME) 13090 da Fig. 1146 no Estágio 13104. No Estágio 13104, invoca o LOM 132 para produzir o Conhecimento da Associação do Estado Neural 13108, como mostrado na Fig. 1147. O Estágio 13114 produz Personalidades de Trilha e, portanto, Trilas de Evolução a partir das leves variações resultantes que existem na variável Conhecimento da A_ssociação do Estado Neural 13114. O Estágio 13116 invoca o I2GE 122 para testar o estresse e ajustar o Conhecimento da Associação do Estado Neural 13108 para garantir que seja internamente consistente. O Estágio 13118 recebe saída modular da instância I2GE 122 que foi invocada no Estágio 13116 na forma do Conhecimento da Associação de Estado Neural Refinado 13120. No Estágio 13110, o LIZARD 120 converte o Conhecimento da Associação de Estado Neural 13108 em. um Mapa de Hierarquia de Propósito 13112. O Estágio 13122 invoca, o LIZARD 120 para converter o Conhecimento da Associação de Estado Neural Refinado 13120 em um Mapa de Hierarquia de Propósito 13124. O Propósito do Processamento de Simetria, de Propósito (P2SP) 7000 é então
Petição 870200056145, de 06/05/2020, pág. 668/1737
666/754 invocado para processar os Mapas 13124 e 13112, cujo fluxo lógico é mostrado na Fig. 1156.
[1153] A Fig. 1151 mostra os detalhes operacionais relativos ao Estágio 13114 da NME 13090.
[1154] O Conhecimento da Associação do Estado Neural 13108 é enviado ao módulo 12405 de Variação criativa de entrada (ICV) para produzir Variações de Composição 13128. Tais variações 13128 são descompactadas no Estágio 13130, o que leva à execução do Estágio 13132. A geração base (Nl) de cada. Trilha de Evolução C867A da recém-invocada I2GE 122 em posição é iniciada em branco. Uma vez iniciada a emulação I2GE 122, as Trilhas de Evolução C8 67.A evoluem de acordo com as definições correspondentes da Personalidade de Trilha C867D. Essas Personalidades de Trilha C867D são instaladas no Estágio 13132 subsequente, que recebe a coleção de Variáveis de Composição 13128 variável e as instala. como Personalidades C867D correspondentes na instância I2GE 122. Cada Trilha de Evolução C867A é logisticamente separada pelas outras por meio do Isolamento Virtual 390 na instância. I2GE 122. Portanto, existe uma garantia implícita de que os resultados produzidos a partir da Trilha de Evolução C8 67.A são imparciais e não são afetados por outros fatores potenciais.
[1155] A. Fig. 1152 detalha a funcionalidade e operação do Estágio 13116 da NME 13090. A Definição de Cenário Complexa. 12956 está sendo emulada por múltiplos Caminhos de Evolução C867A paralelos, que recebem testes ambientais pelo módulo Ameaça de Segurança Artificial (AST) 123. Depois que o processamento de emulação I2GE 122 é concluído, os resultados
Petição 870200056145, de 06/05/2020, pág. 669/1737
667/754 são processados pelo Processador de Conclusão da Iteração 5554, que envia a saida modular ao Prompt 13134. 0 Prompt 13134 avalia a quantidade de Conhecimento da Associação do Estado Neural 13134 estabilizado que foi produzido pela sessão de emulação I2GE 122. A. resposta ao Prompt 13134 é considerada Sim, Suficientemente Estável 13136 é o Critério de Saturação 12962 para a variação e estabilidade do Conhecimento da Associação de Estado Neural Refinado 13120.
[1156] A Fig. 1153 descreve a funcionalidade das Figs. 1151 e 1152, mostrando as várias Gerações 5658 que são construídas sequencialmente dentro da Trilha de Evolução C867. As Variações de Composiçãol3128 que são produzidas a partir do Conhecimento da Associação do Estado Neural 13108 e são produzidas pelo módulo Correspondência do Mapa de Necessidade (NMM) C114 da LIZARD 120, relacionam-se e representam as Gerações 5658 sequenciais que são produzidas na sessão de emulação DO I2GE 122. Enquanto a sessão continua, enquanto está hospedado na Rede BCHAIN 110, a Designação Da Trilha 5650 representa os três estados que podem se tornar uma Trilha de Evolução C867: Aprovado como Estável 5652, Pendente de Evolução 5654 e Abandonado/Excluído 5656. Uma Trilha C867 pode ser Excluída 5656 se a Personalidade de Trilha C867D correspondente exibir uma falha de herança na composição e/ou uma incompatibilidade de herança com. o estado inicial da Trilha C8 67.
[1157] A Fig. 1154 mostra detalhes da operação do LIZA.RD 120 para converter o Conhecimento da Associação do Estado Refinado 13120 em um Mapa 13124 da Hierarquia de Propósito. O Conhecimento 13120 da Associação do Estado Neural Refinado é
Petição 870200056145, de 06/05/2020, pág. 670/1737
668/754 enviada para o Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. SM C35 tornece uma estrutura para leitura e escrita de código de computador. Para escrever código; ele recebe o Formato de Propósito Complexo C325 do Módulo de Propósito (PM) C36. 0 Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. 0 pseudocódigo contém implementações básicas das operações de computação mais comuns entre todas as linguagens de programação, como instruções
if/else, loops etc. Posteriormi ente, uma função auxiliar converte
o pseudocódigo em <: código execu .tável real, dependendo da sintaxe
de computação alví c desejada (ling uagem de computador ?) . Para
leitura de cód igo; o SM C35 fc rnece uma interpretação s intática
do código do computador para o PM C36 para derivar um propósito para a funcionalidade desse código. 0 Conhecimento da Associação de Estado Neural Refinado 13120 é recebido no formato Sintaxe de Percepção 5638 pela Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e compreendido pela SM C35 em qualquer linguagem de computação conhecido e selecionado. A Conversão de Código C321 também, executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saida da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica. C323 reduz a lógica do código para formas mais simples para, produzir um mapa de funções interconectadas, segundo as definições de
Regras e Sintaxe C322. Portanto, depois da execução completa da
Redução Lógica C323, a execução da instância correspondente do
Petição 870200056145, de 06/05/2020, pág. 671/1737
669/754
SM C35 é concluída e a saida modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma Propósito no Formato de Propósito Complexo C325 do código do computador. Essa definição de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada por SM C35. 0 PM C36 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A Interpretação Iterativa. C328 percorre todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção automática/autoprogramação e é direta e exclusivamente programada por especialistas na área relevante. O elemento Código Principal C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem, a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a Política de Segurança e os Objetivos da Empresa. Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1158] A Fig. 1155 continua o fluxo lógico da Fig. 1154 para ilustrar a operação do LIZARD 120 para converter o Conhecimento da Associação de Estado Neural Refinado 13120 em um
Petição 870200056145, de 06/05/2020, pág. 672/1737
670/754
Mapa de Hierarquia de Propósito 13124. A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saida para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula em todas as funções interconectadas para produzir uma definição de propósito interpretado, pela consulta das Associações de Propósito C326. A saida de definição de Propósito existe no Formato de Propósito Complexo C325, é enviado como saida modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e, o LIZARD 120. A saida. é rotulada como um Mapa de Hierarquia de Propósito 13112, que é apresentada como a versão do Formato de Propósito Complexo C325 do Conhecimento da Associação de Estado Neural. Refinado 13120. A mesma definição e aplicação do Núcleo Interno (IC) C333 se aplica às funções e módulos mencionados acima.
[1159] A Fig. 1156 continua o fluxo lógico da Fig. 1150 para ilustrar a operação e a funcionalidade do módulo 13090 de Aprimoramento de Mapeamento Neuro Econômico (NME). No Estágio 13140, o Propósito do Processamento de Simetria de Propósito (P2SP) 7000 é invocado para processar o Mapa de Hierarquia de Propósito 13112 do Conhecimento da Associação de Estado Neural 13208 e o Mapa de Hierarquia de Propósito 13124 do Conhecimento da Associação de Estado Neural Refinado 13120, produzindo, portanto, o Resultado do Processamento de Simetria 1.3142. Este processamento do Estágio 13140 leva à ativação do Prompt 13144, que interpreta, o Resultado do Processamento de Simetria. 13142 para avaliar se o Mapa de Hierarquia de Propósitos 13124 é congruente e compatível, com. o Mapa de Hierarquia de Propósitos 13112. Uma resposta Não, Não é Congruente 13148 ao Prompt 13144
Petição 870200056145, de 06/05/2020, pág. 673/1737
671/754 é realocada na Fig. 1162, que segue a mesma lógica de terminação/diagnóstico da Fig. 1127. Uma resposta Sim, é Congruente 13146 ao Prompt 13144 leva aos Estágios 13150 e 13154. O Estágio 13150 invoca o LIZARD 120 para converter o Mapa de Hierarquia de Propósito 13112 do Conhecimento da Associação de Estado Neural 13108 em. Sintaxe do Appchain, produzindo, portanto, a Retenção do Appchain Original 13152 como saída modular. Da mesma forma, o Estágio 13154 invoca o LIZARD 120 para converter o Mapa de Hierarquia de Propósito 13124 do Conhecimento da Associação de Estado Neural Refinado 13120 na Sintaxe do Appchain, produzindo, portanto, a Retenção do Appchain Atualizado 13156. Ambas as Retenções 13151. e 13156 são usadas como entrada modular para o módulo do Conjunto de Patches de Implantação (DPA) 6260, conforme ilustrado na Fig. 1161.
[1160] A Fig. 1157 mostra detalhes sobre a operação do LIZARD 120 para, converter o Mapa de Hierarquia de Propósito 13112 do Conhecimento da Associação do Estado Neurall3108 na Sintaxe do Appchain. O Mapa 1.311.2 existe no Formato de Propósito Complexo C325 e é submetido à Expansão Iterativa C327 do Módulo de Propósito C36 dentro do Núcleo Exterior (OC) C329 do LIZARD 1.20. A expansão iterativa C327 adiciona detalhes e complexidade para evoluir para um objetivo simples (definida indiretamente no Mapa 13112) em uma definição de propósito complexo específica. Portanto, o potencial máximo da Associação de Propósito C326 da entrada é realizado e retido como um Formato de Propósito Complexo C325, antes de ser submetido á Derivação Lógica C320 do Módulo de Sintaxe (SM) C35. O elemento Código Principal C335 do Núcleo Interior (IC) C333 contém Estruturas e Bibliotecas
Petição 870200056145, de 06/05/2020, pág. 674/1737
672/754 fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória Portanto, o Código Principal C335 permite operação e funcionalidade gerais para o SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. 0 elemento Objetivos do Sistema C336 do IC C333 define Diretiva de Segurança e Metas Corporativas. Essas definições operam como variáveis de política estática para orientar algumas funções dinâmicas e estáticas do LIZARD 120.
[1161] A Fig. 1158 continua o fluxo lógico da Fig. 1157 para ilustrar a operação do LIZARD 120 para converter o Mapa de hierarquia de Propósitos 13112 na Sintaxe do Appchain, referenciada como Retenção Original do Appchain 13152. Os dados de entrada são recebidos no Formato de Propósito complexo C325 do Módulo de Propósito (PM) C3 6 e são transferidos para a Derivação Lógica. C320 do Módulo de Sintaxe (SPI) C35. A Derivação Lógica C320 deriva funções logicamente necessárias de funções inicialmente mais simples. Isso significa que se uma função puder ser formada como uma função derivada devido à implicação de uma. função pai mais simples; então é formado pela Derivação Lógica C320. O resultado produzido é uma árvore de dependências de funções construídas de acordo com os dados definidos Pelo Formato de Propósito Complexo C325. A Derivação Lógica C320 opera de acordo com as definições de Regras e Sintaxe C322, que são herdados do elemento Código Principal C335 do Núcleo Interior (IC) C333. A Derivação Lógica C320 submete sua saída para a
Conversão de Código C321. A Conversão do Código C321 converte código arbitrário (genérico), reconhecido e entendido pelo SM
Petição 870200056145, de 06/05/2020, pág. 675/1737
673/754
C35 em qualquer linguagem de computação conhecido e escolhido. A Conversão de Código C321 também executa a função inversa de conversão de linguagens de computação conhecidas em tipos de sintaxe arbitrários. Portanto, o PM C36 invoca o SM C35 para produzir a Versão da Sintaxe do Appchain 13152 resultante do Conhecimento da Associação do Estado Neural 13108 através da Conversão de código C321. A Retenção Original do Appchain 13152 resultante, produzida de forma terminal pela Conversão de Código C321, é a saída modular do SM C35, do Núcleo Exterior (OC) C329 e do LIZARD 120.
[1162] A Fig. 1159 mostra detalhes sobre a operação do LIZARD 120 para converter o Mapa de Hierarquia de Propósito 13124 do Conhecimento da Associação de Estado Neural Refinado 13120 na Sintaxe do Appchain. O Mapa 13124 existe no Formato de Propósito Complexo C325 e é submetido à Expansão Iterativa C327 do Módulo de Propósito C36 dentro do Núcleo Exterior (OC) C329 do LIZARD 120. A expansão iterativa C327 adiciona detalhes e complexidade para evoluir para um objetivo simples (definida indiretamente no Mapa 13112) em uma definição de propósito complexo específica. Portanto, o potencial máximo da Associação de Propósito C32 6 da entrada é realizado e mantido como um. Formato de Propósito Complexo C325, antes de ser submetido à Derivação Lógica C320 do Módulo de Sintaxe (SM) C35. 0 elemento Código Principal C335 do Núcleo Interior (IC) C333 contém Estruturas e Bibliotecas fundamentais. Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite operação e funcionalidade gerais ao SM
Petição 870200056145, de 06/05/2020, pág. 676/1737
674/754
C35 e PM c36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. 0 elemento Objetivos do Sistema
0336 do IC 0333 define a Política de Segurança e Objetivos da
Empresa. Essas definições funcionam cc mo va r i áve i s de política
estática para orientar várias funções dinâmicas e estáticas no
LIZARD 120.
[1163] A Fig. 1160 continua o fluxo lógico da Fig. 1159 para ilustrar a operação do LIZARD 120 para converter o Mapa de Hierarquia de Propósito 13112 na Sintaxe do Appchain que é referenciada como Retenção do Appchain Atualizada 13156. Os dados de entrada são recebidos no Formato de Propósito complexo 0325 do Módulo de Propósito (PM) 03 6 e são transferidos para a Derivação Lógica 0320 do Módulo de Sintaxe (SM) 035. A Derivação Lógica 0320 deriva funções logicamente necessárias de funções inic.ialm.ente mais simples. Isso significa que se uma função puder ser formada como uma função derivada devido à implicação de uma. função pai mais simples; então é formado pela Derivação Lógica 0320. 0 resultado produzido é uma árvore de dependências de funções construídas de acordo com os dados definidos Pelo Formato de Propósito Complexo 0325. A Derivação Lógica 0320 opera de acordo com as definições de Regras e Sintaxe 0322, que são herdados do elemento Código Principal 0335 do Núcleo Interior (IC) 0333. A Derivação Lógica 0320 submete sua saída para a Conversão de Código 0321. A Conversão do Código 0321 converte código arbitrário (genérico), reconhecido e entendido pelo SM 035 em qualquer linguagem de computação conhecido e escolhido. A Conversão de Código 0321. também executa a função inversa de conversão de linguagens de computação conhecidas em tipos de
Petição 870200056145, de 06/05/2020, pág. 677/1737
675/754 sintaxe arbitrários. Portanto, o PM C36 invoca o SM C35 para produzir a versão 13156 da Sintaxe do Appchain resultante do Conhecimento da Associação de Estado Neural Refinado 13120 resultante da Conversão de Código C321. A Retenção do Appchain Atualizada 13156 resultante da Conversão de Código C321 é a saida modular do SM C35, Núcleo Exterior (OC) C329 e do LIZARD 120.
[1164] A Fig. 1161 mostra a operação e a funcionalidade do Aprimoramento do Mapeamento Neuro Econômico (NME) 13090, retomando o fluxo lógico no Estágio 13158 da Fig. 1156. As Retenções do Appchain Originais 13152 e Atualizadas 13156 são enviadas para o Estágio 13158 como entrada modular, para que possam, ser processadas pelo módulo do Conjunto de Patches de Implantação (DPA) 6260, produzindo o Patch de Correção 13160 do Appchain. 0 DPA 6260 mede e define as diferenças entre as entradas 13152 e 13156 na Sintaxe do Appchain, produzindo instruções da Sintaxe do Appchain para converter a Retenção do Appchain Original 13152 na Retenção do Appchain Atualizada 13156. Tais instruções são referenciadas como o Patch de Correção do Appchain 13160, que é inicialmente armazenado como uma. variável de sessão (temporária/não persistente) da instância correspondente do NME 13090. Portanto, o Tipo de Comando 6408 do Segmento de Dados de Gravação de Sessão 6408 é usado na instância 6400 da Renderização de Fluxo de Execução (ESR.) que está hospedando a instância NME 13090. No Estágio 13162, o Patch de Correção do Appchain 13160 está comprometido com o Armazenamento de Retenção de Conhecimento Central (CKR) 648 persistente, por meio da invocação do módulo Construtor de Ecossistemas Customchain (CEB) 584. A operação executada no Estágio 13162 faz
Petição 870200056145, de 06/05/2020, pág. 678/1737
676/754 com que a instância do ESR 6400 hospede, invoque o Tipo de Comando 6408 do Segmento de Dados de Gravação Persistente 64022.
[1165] A Fig. 1162 continua o fluxo lógico da Fig. 1156 para ilustrar o fluxo lógico referente à resposta de Não, Não é Congruente 13004 em relação ao Prompt 13144. Posteriormente, ocorre o Estágio 5600, que envia uma Unidade de Registro de Diagnóstico (DLU) 1182 que contém o Token do Sistema Oficial 1184. Este Token 1184 está incluído para indicar que a função ou programa correspondente atingiu um estado não ideal se uma função oficial dentro da Plataforma UBEC 100.
[1166] O DLU 1182 é enviado ao módulo Envio de Registro de Diagnóstico (DLS) 1160, invocado pelo Mecanismo de Pesquisa Automatizado (ARM) 134 do LOM 132 para fornecer o DLU 1182 ao SPSI 130. Portanto, o SPSI 130 é capaz de processar as informações de diagnóstico encontradas na DLU 1160 com. o módulo de Análise de Unidade de Registro de Diagnóstico (DLUA18048. Isso leva ao Estágio 13005, que representa o DLUA 8048 sendo invocado para executar modificações correspondentes ao I2GE 1.22 e/ou NME 13090 para evitar o motivo inicial pela qual a resposta Não, Não é Congruente 13004 foi invocada no Prompt 13144.
[1167] A Fig. 1163 continua o fluxo lóg.i CO do NME
13090 do Estagio 13110 da Fig. 1146. 0 Es tágio 13110 ir ivoca o
LIZA.RD 12 0 para c onverter o Conhecimento da Associação de Estado
N e u r a 1 131.08 em. um Mapa de Hierarquia de Propósito 1.31 12. No
Estágio 13162, o LIZA.RD 12 0 é chamado par a converter o Padr ao
Neural em Bruto 13094 em um Mapa de Hierarquia de Propósito
13164. No Estágio 13168, o LIZARD 120 é chamado para converter o
Estado Circunstancial Alvo 13100 em um Mapa de Hierarquia de
Petição 870200056145, de 06/05/2020, pág. 679/1737
677/754
Propósito 13168. No Estágio 13170, o Propósito do Processamento de Simetria de Propósito (P2SP) 7000 é invocado para processar o Mapa de Hierarquia de Propósito 13112 e o Mapa de Hierarquia de Propósito 13164, produzindo, portanto, o Resultado do Processamento de Simetria 13172. O Prompt 13174 é então invocado para interpretar o Resultado de Processamento de Simetria 13172,
do qual o fluxo lógico é mostra do na F ig. 1168.
[1168 ] A Fig. 1164 mostra detalhes sobre a operação
do LIZARD 120 p >ara converter o Padrão Neural ei π Bruto 13094 em
um Mapa de Hierarquia de Propósitos 13164. O Padrão Neural em Bruto 13094 é enviada para o Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura e escrita de código de
computador Para escrever c :ódigo; ele recebe o Formato de
Propósito Complexo C325 do Módulo de Propósito (PM) C 3 6 0
Formato de P r op ó s i t o C omp1e x o C325 é então escrito em Sintaxe de
Código Arbitrária, também conhecido como 'pseudocódigo'. O pseudocódigo contém, implementações básicas das operações de computação que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Posteriormente, uma função auxiliar converte o pseudocódigo em. código executável real, dependendo da sintaxe de computação de alvo desejada (linguagem do computador) . Para leitura de código; O SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar um propósito para a funcionalidade desse código. O Padrão Neural em Bruto 13094 é recebido no formato de Sintaxe Neural 13095 pela Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é
Petição 870200056145, de 06/05/2020, pág. 680/1737
678/754 reconhecido e entendido pelo SM C35 em qualquer linguagem de computação conhecida e escolhida. A Conversão de Código C321 também, desempenha a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saída da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica. C323 reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas, segundo as definições de Regras e Sintaxe C322. Portanto, depois da execução completa da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C3.5 é enviada para a Interpretação Iterativa C328 do Module de Propósito (PM) C36.
[1169] 0 PM C36 usa o SM C35 derivar um Propósito no Formato de Propósito Complexo C325 a partir do código do computador. Essa definição de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada por SM C35. 0 PM C36 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325) consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C3.33 é a área do LIZARD 120 que não é submetida a manutenção automática/autoprogramação e é direta e exclusivamente programada por especialistas no campo relevante. O elemento Código Principal C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de
Petição 870200056145, de 06/05/2020, pág. 681/1737
679/754
Gerenciamento de Memória. Portanto, o Código Principal 0335
permite operação e funcionalidade gerais ao SM 035 e PM 036,
f o r n e c e n do b i b1ic >tecas e scripts padronizados que permitem, a
funcionalidade básica. 0 elemento Objetivos do Sistema 0336 do IC C333 define a Política de Segurança e Objetivos da Empresa. Essas definições funcionam como variáveis de política estáticas para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1170] A. Fig. 1165 continua o fluxo lógico da Fig.
1164 para ilustrar a operação do LIZARD 120 para converter
Padrão Neural em l Bruto 13094 em um Mapa de Hierarquia de
Propósitos 13164. A Redução Lógica 0323 do Módulo de Sintaxe (SM)
035 envia sua said .a para a Interpretação Iterativa 0328 do Módulo
de Propósito (PM) 036. A Interpretação Iterativa 0328 circula
através de todas as funções interconectadas para produzir uma
definição de prop ósito interpretada consultando Associações de
Propósito 0326. A saída de definição de propósito existe no Formato de Propósito Complexo 0325, que é enviado como saída modular para PM 036 e, portanto, para o Núcleo Exterior (00) 0329 e, para o LIZARD 120. A saída é rotulada como um Mapa de Hierarquia de Propósito 13164, que é apresentada como a versão Formato de Propósito Complexo 0325 do Padrão Neural em. Bruto 13094. A mesma definição e aplicação do Núcleo Interno (IC) 0333
aplica~se às tunç< ões e módulos mencionados acima.
[ 1171 ] A Fig. 1166 mostra detalhes sobre a operação
do LIZARD 12 0 par- a converter o Estado Circunstancial Alvo 13100
em um Mapa de Hierarquia de Propósitos 13168. 0 Estado
0 i r c u n s t a n. c i a .1 A.1 vo 13100 é submetido ao Módulo de Sintaxe (SM)
035, que pertence à jurisdição do Núcleo Exterior (00) 0329. 0
Petição 870200056145, de 06/05/2020, pág. 682/1737
680/754
SM C35 fornece uma estrutura para leitura e escrita de código de computador. Para escrever o código; ele recebe o Formato de Propósito Complexo C325 do Módulo de Propósito (PM) C36. O Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém, implementações básicas das operações de computação mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Posteriormente, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação alvo desejada (linguagem de computador) . Para leitura de código; O SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar um propósito para a funcionalidade desse código. O Estado Circunstancial Alvo 13100 é recebido no formato Sintaxe de Estado 5624 pela Conversão de código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e compreendido pela SM C35 em qualquer linguagem de computação conhecido e selecionado. A Conversão de Código C321 também executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A. salda da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas de acordo com. as definições das Regras e Sintaxe C322. Portanto, depois da execução completa, da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36.
Petição 870200056145, de 06/05/2020, pág. 683/1737
681/754
PM C3 6 usa o SM C35 para derivar um Formato de Propósito Complexo C325 a partir do código de computador. Essa definição de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada por SM C35. 0 PM C36 também é capaz de detectar fragmentos de código que estão secretamente imersos em dados (binários/ASCII etc.).A
Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não é submetida a manutenção automática/autoprogramação e é direta e exclusivamente programada por especialistas na área relevante. O elemento Código Principal C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a Política de Segurança e Objetivos da Empresa. Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1172] A Fig. 1167 continua o fluxo lógico da Fig. 1166 para ilustrar a operação do LIZARD 120 para converter o Estado Circunstancial A_lvo 13100 em um Mapa de Hierarquia de Propósito 13168. A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saída para, a Interpretação Iterativa C32 8 do Módulo
Petição 870200056145, de 06/05/2020, pág. 684/1737
682/754 de Propósito (PM) C36. A Interpretação Iterativa C328 circula em todas as funções interconectadas para produzir uma definição de propósito interpretado, pela consulta das Associações de Propósito C326. A saida de definição de Propósito existe no Formato de Propósito Complexo C325, é enviado como saida modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e, o LIZARD 120. A saida é rotulada como um Mapa de Hierarquia de Propósito 13168, que é apresentado como a versão do Formato de Propósito Complexa C325 do Estado Circunstancial Alvo 13100. A mesma definição e aplicação do Núcleo Interno (IC) C333 aplicase às funções e módulos mencionados acima.
[1173] A Fig. 1168 continua o fluxo lógico da Fig. 1163 no Prompt 13174 para ilustrar a operação e a funcionalidade do A_primoramento de Mapeamento Neuro Econômico (NME) 13090. O Prompt 13174 interpreta o Resultado do Processamento de Simetria 13172 para determinar se o Mapa Hierárquico de Propósito 13164 do Padrão Neural em Bruto 13094 é congruente e compatível com o Mapa de Hierarquia de Propósito 13112 do Conhecimento da Associação de Estado Neural 13108. Uma resposta ao Prompt 13174 de Não, Não é Congruente 13178 tem seu fluxo lógico mostrado na Fig. 1169. Uma resposta Sim., é Congruente 1317 6 ao Prompt 13174 leva à ativação do Estágio 13180, que invoca o módulo de Pesquisa da Associação do Estado Neural (NSAL) 13194 para processar o Padrão Neural em Bruto 13094 para produzir o Estado Circunstancial Reivindicado 13182 da Mente Alvo 12702. 0 NSAL 13194 faz referência ao Conhecimento da Associação do Estado Neural 13108 (produzido a partir da LOM 132) para interpretar o Padrão Neural em Bruto 13094 e enviar a implicação de associação
Petição 870200056145, de 06/05/2020, pág. 685/1737
683/754 percebida que existe, como o Estado Circunstancial Reivindicado 13182. Por exemplo: de acordo com o Conhecimento da Associação de Estado Neural 13108, a composição do Padrão Neural em Bruto 130 94 indica com um forte grau de confiança que a Mente Alvo 12702 está atualmente presa no tráfego (assim representada no Estado Circunstancial Reivindicado 13182) . No Estágio 13184, o LIZARD 120 é invocado para converter o Estado Circunstancial Reivindicado 13182 em um Mapa de Hierarquia de Propósito 13186. No Estágio 13188, os Mapas de Hierarquia de Propósito 13186 e 13192 são processados pelo Propósito do Processamento de Simetria de Propósito (P2SP) 7000, com o fluxo lógico subsequente mostrado na Fig. 1172.
[1174] A Fig. 1169 continua o fluxo lógico das Figs. 1156 e 1162 para ilustrar o fluxo lógico referente à resposta de Não, Não é Congruente 13178 em relação ao Prompt 13174. Posteriormente, ocorre o Estágio 5600 que envia uma Unidade de Registro de Diagnóstico (DLU) 1182 que contém o Token Oficial do Sistema 1184. Este Token 1184 é incluído para indicar que a função ou programa, correspondente atingiu um estado não ideal se uma função oficial dentro da Plataforma UBEC 100. O DLU 1182 é enviado ao módulo Envio de Registro de Diagnóstico (DLS) 1160, invocado pelo Mecanismo de Pesquisa Automatizado (ARM) 134 do LOM 132 para fornecer o DLU 1182 ao SPSI 130. Portanto, o SPSI 130 é capaz de processar as informações de diagnóstico encontradas na DLU 1160 com o módulo de Análise de Unidade de Registro de Diagnóstico (DLUA)8048. Isso leva ao Estágio 13005, que representa o DLUA 8048 sendo invocado para executar as modificações correspondentes ao I2GE 122 e/ou NME 13090 para.
Petição 870200056145, de 06/05/2020, pág. 686/1737
684/754 evitar o motivo inicial pela qual a resposta Não, Não é Congruente 13004 foi invocada no Prompt 13144.
[1175] A Fig. 1170 mostra detalhes sobre a operação do LIZARD 120 para converter o Estado Circunstancial Reivindicado 13182 em um Mapa de Hierarquia de Propósito 13186. O Estado Circunstancia.! Reivindicado 13182 é submetido ao Módulo Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura e escrita de código de computador. Para escrever código; ele recebe o Formato de Propósito Complexo C325 do Módulo de Propósito (PM) C36. O Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecido como ''pseudocódigo' . O pseudocódigo contém implementações básicas das operações de computação que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Poster.iorm.ente, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação alvo desejada (linguagem de computador) . Para, leitura de código; 0 SM C35 fornece uma interpretação sintática do código do computador para, o PM C36 para derivar um propósito para a funcionalidade desse código. 0 Estado Circunstancia.! Reivindicado 131.82 é recebido no formato Sintaxe do Estado 5624 pela Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pelo SM C35 em qualquer linguagem, de computação conhecido e escolhido. A Conversão de Código C321 também executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saída da execução concluída da Conversão de Código C321 é transferida.
Petição 870200056145, de 06/05/2020, pág. 687/1737
685/754 como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas, segundo as definições de Regras e Sintaxe C322. Portanto, depois da execução completa da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma Propósito no Formato de Propósito Complexo C325 do código do computador. Essa definição de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada por SM C35.
[117 6] 0 PM C3 6 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A Interpretação Iterativa C328 circula em todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as A_ssociações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção automatizada/autoprogramação e é programada direta e exclusivamente por especialistas na área relevante. O elemento C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite operação e funcionalidade gerais para, o SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define Diretiva, de Segurança e Metas Corporativas. Essas
Petição 870200056145, de 06/05/2020, pág. 688/1737
686/754 definições operam como variáveis de política estática para orientar algumas funções dinâmicas e estáticas do LIZARD 120.
[1177] A Fig. 1171 continua o fluxo lógico da Fig. 1170 para ilustrar a operação do LIZARD 120 para converter o Estado Circunstancial Reivindicado 13182 em um Mapa de Hierarquia de Propósitos 13186.
[1178] A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A. Interpretação Iterativa C328 circula em todas as funções interconectadas para produzir uma definição de propósito interpretado, pela consulta das Associações de Propósito C326. A saída de definição de Propósito existe no Formato de Propósito Complexo C325, é enviado como saída modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e, o LIZARD 120. A saída é rotulada como um Mapa de Hierarquia de Propósito 1318 6, que é apresentada como a versão do Formato de Propósito Complexo C325 do Estado Circunstancial Reivindicado 13182. A mesma definição e aplicação do Núcleo Interno (IC) C333 aplica-se às funções e módulos mencionados acima.
[1179] A Fig. 117 2 mostra a operação e a funcionalidade do Aprimoramento de Mapeamento Neuro Econômico (NME) 13090, tendo retomado o fluxo lógico da Fig. 1168. No Estágio 13194, o Propósito do Processamento de Simetria de Propósito 7000 (P2SP) é invocado para processar o Mapa de Hierarquia de Propósito 13186 do Estado Circunstancial Reivindicado 13182 e o Mapa de Hierarquia de Propósito 13192 do Estado Circunstancial Alvo 13100, produzindo, portanto, o
Petição 870200056145, de 06/05/2020, pág. 689/1737
687/754
Resultado de Processamento de Simetria 13196. No Prompt 13198, ο Resultado 13196 é interpretado como se interprete que o Mapa de Hierarquia de Propósitos 13186 é congruente e compatível com o Mapa de Hierarquia de Propósitos 13192. 0 fluxo lógico referente à resposta Não, Não é Congruente 13202 é mostrado na Fig. 1174. Se a resposta ao Prompt 13198 for Sim., é Congruente 1.3200, será solicitado o Prompt 13204 que interpreta se a Confiança do Estado Circunstancial Alvo 13102 é alta ou baixa. Uma resposta de Alta Confiança 13206 ao Prompt 13204 leva à ativação da Conclusão 13208, que afirma que o setor correspondente do Conhecimento da A_ssociação de Estado Neural 13108 provou indicar alta confiança nas reivindicações de associação.
[1180] A Fig. 1173 retoma o fluxo lógico da Fig. 1172 do Prompt 13204 com uma resposta Sim, é Congruente 13200. Depois da ativação da Conclusão 13208, o Estágio 1.321.0 é invocado para transmitir as evidências de alta confiança ao LOM 132 e ao CTMP 124, afetando, portanto, as iterações futuras do Conhecimento da Associação do Estado Neural 1.3108, conforme mantido na CKR 648. Portanto, o ciclo gradual de autoaprendizagem que invoca o LOM 132 e o CTMP 124 se completou. Se a resposta ao Prompt 13204 for de Baixa Confiança 1.321.2, o Estágio 13214 será invocado, o que aumenta a Confiança na Precisão do Estado Circunstancial Alvo 13100. Portanto, no Estágio 13216, o Estado Circuns tancial Alvo 131.00 é submetido ao registro de Comportamento Alvo (TBR) 12704 com referência feita à Mente Alvo 12702. Isso faz com que a instância do Perfil de Inteligência Pessoal (PIP) 136 correlacionada com a Mente Alvo 12702 registre e retenha novas informações sobre o Estado Circunstancial Alvo
Petição 870200056145, de 06/05/2020, pág. 690/1737
688/754
13110.
[1181] A Fig. 1174 retoma o fluxo lógico da Fig. 1172 do Prompt 13204 com. uma resposta Não, Não é Congruente 13202. O Prompt 13218 interpreta se o valor da Confiança 13102 do Estado Circunstancial Alvo é Alto 13220 ou Baixo 13222. Uma resposta de Alta Confiança 13220 invoca a Conclusão 13224, que define que um novo Padrão Neural em Bruto 13094 foi encontrado para o LOM 132 e o CTMP 124 aprenderem. A conclusão 13224 leva ao Estágio 13226, que submete o Padrão Neural em Bruto 13094, juntamente com a variável Estado Circunstancial Alvo 13100 correspondente, para LOM 132 e CTMP 124, afetando, portanto, futuras iterações do Conhecimento da Associação do Estado Neural
13108, conforme retido na CKR 648. Portanto, o ciclo gradual de autoaprendizagem que invoca o LOM 132 e o CTMP 124 se completou. Se a resposta ao Prompt 13218 for Baixa Confiança 13222, o Estágio 13228 será invocado, o que aumentará a Confiança de Precisão do Estado Circunstancial Alvo 13100. Portanto, no Estágio 13216, o Estado Circunstancial Alvo 13100 será submetido à nova gravação do Comportamento Alvo (TBR) 12704, com referência, à Mente Alvo 12702. Isso faz com que a instância do Perfil de Inteligência Pessoal (PIP) 136 correlacionada com a Mente Alvo 12702 registre e retenha novas informações sobre o Estado Circunstancial Alvo
13110.
[1182] A Fig. 1175 retoma o fluxo lógico da Fig. 1172 do Prompt 13198. Enquanto as Respostas 13200 e 13202 do Prompt 13198 conduzem a seus próprios caminhos independentes de fluxo lógico, o Prompt 13198 gera sua própria Invocação de Segmento Paralelo 13232, que é independente do progresso ou
Petição 870200056145, de 06/05/2020, pág. 691/1737
689/754 status de conclusão dos outros dois segmentos 13200 e 13202. A Invocação de Segmento Paralelo 13232 leva ao Prompt 13234, que avalia se a Confiança de Estado Circunstancial Alvo 13102 é alta ou baixa. Se a resposta ao Prompt 13234 for Alta Confiança 13236, o Estágio 13238 será invocado. O Estágio 13238 invoca o módulo de Pesquisa de Associação de Estado Neural (NSAL) 13194 que produz o Padrão Neural Reivindicado 13238, referenciando o Estado Circunstancial Alvo 13100 e o Conhecimento da Associação de Estado Neural 13108. Portanto, o Estágio 13238 executa a função inversa do Estágio 13180 da Fig. 1168. Um exemplo do procedimento no Estágio 13238 é o seguinte: o Estado Circunstancial Alvo 13100 define que a Mente Alvo 12702 está atualmente presa no trânsito e atrasada para o trabalho. Portanto, o Estado 13100 e o Conhecimento da Associação de Estado Neural 13108 são submetidos ao NSAL 13194 como entrada modular. Portanto, o NSAL 13194 produz o Padrão Neural Reivindicado 13238, que define a melhor representação estimada dos padrões neurais atuais existentes na Mente Alvo 12702, enquanto experimentam, o Estado Circunstancial Alvo 13100. No Estágio 13240, o LIZARD 120 é invocado para, converter o Padrão Neural Reivindicado em um Mapa de Hierarquia de Propósito 13242, como mostrado na Fig. 1178.
[1183] A Fig. 1176 mostra detalhes sobre a operação do LIZARD 120 para converter o Padrão Neural Reivindicado 13238 em um Mapa de Hierarquia de Propósito 13242. O Padrão Neural Reivindicado 13238 é enviado para o Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura e escrita de código de computador. Para escrever o código; recebe o Formato de Propósito
Petição 870200056145, de 06/05/2020, pág. 692/1737
690/754
Complexo C325 do Módulo de Propósito (PM) C36. O Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém implementações básicas das operações de computação que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Posteriormente, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação Alvo desejada (linguagem do computador) . Para, leitura de código; O SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar um propósito para a funcionalidade desse código. O Padrão Neural Reivindicado 13238 é recebido no formato de Sintaxe Neural 13095 pela Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e compreendido pela SM C35 em qualquer linguagem, de computação conhecido e selecionado. A Conversão de Código C321 também executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A salda da execução concluída da Conversão de Código C321 é transferida como entrada, para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas miais simples para produzir um mapa de funções interconectadas de acordo com as definições das Regras e Sintaxe C322. Portanto, depois da execução concluída da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para derivar uma. Propósito no Formato de Propósito Complexo C325 do código do computador. Essa definição
Petição 870200056145, de 06/05/2020, pág. 693/1737
691/754 de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada pelo SM C35. 0 PM C36 também, é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A. Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área. do LIZARD 120 que não passa por manutenção automática/autoprogramação e é direta e exclusivamente programada por especialistas na área relevante. O elemento C335 do IC C333 contém. Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória Portanto, o Código Principal C335 permite operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a Política de Segurança, e Objetivos da Empresa. Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1184] A Fig. 1177 continua o fluxo lógico da Fig. 1176 para ilustrar a operação do LIZARD 120 para converter o Padrão Neural Reivindicado 13238 em. um Mapa de Hierarquia de Propósitos 13242. A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de
Petição 870200056145, de 06/05/2020, pág. 694/1737
692/754 propósito interpretada consultando as Associações de Propósito C326. A saída de definição de propósito existe no Formato de Propósito Complexo C325, que é enviado como saída modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e, para o LIZA.RD 120. A. saída é rotulada como um Mapa de Hierarquia de Propósito 132 42, que é apresentada como a versão do Formato de Propósito Complexo C325 do Padrão Neural Reivindicado 13238. A mesma definição e aplicação do Núcleo Interno (IC) C333 aplicase às funções e módulos mencionados acima.
[1185] A Fig. 1178 continua a operação e a funcionalidade do Aprimoramento de Mapeamento Neuro Econômico (NME) 13090, retomando o fluxo lógico no Estágio 13240 da Fig. 1175. O Estágio 13240 invoca o LIZARD 120 para converter o Padrão Neural Reivindicado 13238 em um Mapa de Hierarquia de Propósito 13242. O Estágio 13244 invoca o Propósito para o Mapa de Simetria de Propósito (P2SP) 7000 para processar os Mapas de Hierarquia, de Propósito 13242 e 13164, produzindo, portanto, o resultado 13246 do proc.essam.ento de simetria. 0 Prompt 13248 interpreta o Resultado do Processamento de Simetria 1324 6 para, avaliar se o Mapa de Hierarquia de Propósito 13248 é congruente e compatível com. o Mapa de Hierarquia de Propósito 13164. Ambas as respostas possíveis ao Prompt de 13248 são Sim, é Congruente 13250 e Não, Não é Congruente 13252, a lógica de que é mostrado na Fig. 1179.
[1186] A Fig. 1179 continua o fluxo lógico da Fig. 1178. 0 Prompt 13248 interpreta o resultado do processamento de simetria 13246 que pode levar a uma Resposta 13250/13252. Um fluxo lógico para uma resposta. Não, Não é congruente 13252 é avaliado na Fig. 1181. Uma resposta Sim, é Congruente 13250 leva.
Petição 870200056145, de 06/05/2020, pág. 695/1737
693/754 à ativação do Prompt 13254, que interpreta o valor atual da
Confiança do Conhecimento da Associação do Estado Neural 13106.
Uma resposta de Alta Confiança 13256 ao Prompt 1. 3254 ativa a
Cone lusão 13260, qu .e indica que a confiança algorítmica
rela cionada ao Estado Circunstanc ial A_lvo 1310 0 e ao Conhecimento
da Associação de Estado Neural 13108 aumentou. Portanto, o Estágio 13262 é invocado, o que encaminha as novas evidências de maior confiança algorítmica para o LOM 132 e o CTMP 124, afetando, portanto, as iterações futuras do Conhecimento da Associação do Estado Neural 13108, conforme mantido na CKR 648. Portanto, o ciclo de autoaprendizado gradual que invoca o LOM 132 e o CTMP 124 completou um. círculo. O fluxo lógico para uma resposta 13258 de baixa confiança é mostrado na Fig.
[1187] 1180.
[1188] A Fig. 1180 continua o fluxo lógico da Fig.
1179 no Prompt 13254, exibindo a operação referente à resposta, de Baixa Confiança 13258. Essa Resposta 13258 ativa a Conclusão 1.32 64, que determina que a Confiança da Associação do Estado Neural 13106seja fortalecída/aumentada de acordo com a magnitude da Confiança do Estado Circunstancial A_lvo 13102 correspondente. A Conclusão 13264 leva ao Estágio 1.32 66, que encaminha a evidência correspondente de maior confiança algorítmica no LOM 132 e no CTMP 124, afetando, portanto, as iterações futuras do Conhecimento da Associação do Estado Neural 1.3108, conforme retido na CKR 648. Portanto, o ciclo de autoaprendizagem gradual que invoca o LOM 132 e o CTMP 124 fecha um círculo. A Fig. 1181 continua o fluxo lógico do NME 13090 no Prompt 13248 da Fig.
117 9. A resposta Não, Não é Congruente 13252 ativa, o Prompt
Petição 870200056145, de 06/05/2020, pág. 696/1737
694/754
13268, que avalia se o calor da Confiança do Conhecimento da Associação de estado neural 13106 é alto ou baixo. O fluxo lógico referente à resposta de Baixa Confiança 13272 é mostrado na Fig. 1183. Uma resposta 13270 de alta confiança leva à ativação do
Prompt 132/4, que compara a classific ação algor ítmica de
con t í a n. ç a e n t r e os valores Confiança de Conhec i men. to da
Associação de Es tad< o Neural 13106 e a Confiança do Estado
Circunstancial Al vo 13102. As respostas do Prompt 13274 são
avaliadas na Fig. 1182.
[1189] A Fig. 1182 continua o fluxo lógico do NME 13090 no Prompt 13274 da Fig. 1181. O Prompt 13274 interpreta se a Confiança de Conhecimento da Associação de Estado Neural 13106 ou a Confiança de Estado Circunstancial Alvo 13102 é maior em confiança algorítmica. Se a resposta ao Prompt 13274 for do conhecimento 13276 da Associação de Estado Perto, o Estágio 13280 será chamado, o que marcará a Confiança do Estado Circunstancial A_lvo 13102 como menos confiável. Se a resposta à solicitação 13274 for Conhecimento Perto da Associação Estatal, o Estágio 13282 será invocado, o que marcará a Confiança do Conhecimento da Associação de Estado Neural como menos confiante. Portanto, esse algoritmo de confiança procura encontrar o quadro de referência estável, no que diz respeito à confiança algorítmica, punindo, portanto, o elo mais fraco com uma diminuição na classificação da confiança. Ambas as Respostas potenciais 13280 e 13282 levam ao Estágio 13284, o que encaminha a evidência, correspondente de maior confiança algorítmica para LOM 132 e CTMP 124, afetando, portanto, as iterações futuras do Conhecimento da Associação do Estado Neural 13108, conforme mantido na. CKR 648.
Petição 870200056145, de 06/05/2020, pág. 697/1737
695/754
Portanto, o loop gradual de auto aprendizado que invoca o LOM 132 e o CTMP 124 completou um circulo.
[1190] A Fig. 1183 continua o fluxo lógico do NME 13090 no Prompt 13268 da Fig. 1181. O Prompt 13268 interpreta se a Confiança de Conhecimento da Associação de Estado Neural 13106 é um valor alto ou baixo. É, mostrada a lógica da resposta de Baixa Confiança 13272, que invoca o Estágio 13286, que marca o nível de confiança algorítmica da Confiança de Conhecimento da Associação de Estado Neural 13106. Portanto, o Estágio 13288 encaminha a evidência correspondente de maior confiança
algorítmica para o LOM 12 )2 e O CTMP 124, afetan do, portanto,
futuras iterações do Conhei cime nto da Associação de Estado Neural
13108, conforme mantido na CKR. 648. Portanto, o ciclo de
autoaprendi zado gradual que invoca o LOM 132 e o CTMP 124 completou todo o ciclo.
[1191] [00] A. Fig. 1184 mostra a operação e a aplicação da Agregação de Registro na Estrutura de Dotação (ES) 12008. A Agregação de Registro é uma jurisdição do gerenciamento de informações composta por dois módulos principais: Console de Gerenciamento (MC) 1186 e Gerenciamento Inteligente de Informações e Configurações (I2CM) 1188. Todas as saídas de informações de registro são enviadas como entrada modular ao Serviço de Configuração e Implantação C153 do I2CM 1188. Uma instância do Conselho de Diretores (BD) 12018 ou instância de Diretor Independente (ID) 12020 interage com o em toda a A_gregação de Registros, desta maneira os Diretores 12006/12022 podem interagir com. várias funções do ES 1.2008, como a Interface de Votação da Propostas (PVI) 12010 através do MC 1186. O Serviço
Petição 870200056145, de 06/05/2020, pág. 698/1737
696/754 de Configuração e Implantação C153 é uma interface para implantar novos ativos corporativos (computadores, laptops, telefones celulares) com a configuração de segurança correta e a configuração de conectividade. Depois que um dispositivo é adicionado e configurado, ele pode ser ajustado através do MC 1186 com os Controles de Feedback como intermediário. 0 serviço C153 também gerencia a implantação de novas contas de usuário (como para Usuários UBEC 106). Essa implantação pode incluir a associação de hardware com contas de usuário, personalização da interface (para diferentes fins de uso), lista de variáveis de cliente (por exemplo, tipo de negócio, de produto etc.) . Com Separação por Jurisdição C154, o conjunto de informações marcadas é separado exclusivamente de acordo com a jurisdição relevante do usuário do console de gerenciamento. Com a Separação por Evento 5572, as informações são organizadas de acordo com eventos individuais. Todo tipo de dados é correlacionado com um evento, que adiciona verbosidade ou é removido. Com a Contextualização Inteligente C156, os dados restantes agora parecem, um cluster de ilhas, cada ilha sendo um incidente de evento. São feitas Correlações entre plataformas para amadurecer a análise de eventos. Os dados históricos são acessados (a partir do I2GE 122, em oposição ao LIZARD 120) para entender os padrões de eventos, e o CTMP 124 é usado para a análise do pensamento critico. Com a Apresentação gráfica/Gestão visual 5570, os incidentes de eventos contínuos e históricos são apresentados sem considerar a fonte de informações (qual plataforma), apesar de essas informações estarem disponíveis, se for necessário. A Gestão Direta C161 no MC 1186 implica acesso direto aos controles especificados pelo
Petição 870200056145, de 06/05/2020, pág. 699/1737
697/754
Jsuário UBEC 106 relevante.
[1192] Portanto, a Gestão Direta C161 do MC 1186 se conecta aos Controles Manuais C160 do I2CM 1188. Com Categoria e Jurisdição C162, o Usuário UBEC 106 se autentica através da UNI (Interação do Nó do Usuário) 470, que define sua jurisdição e escopo de acesso à categoria de informação.
[1193] [00] As Figs. 1185 - 1189 ilustram exemplos de usabilidade da Autoprogramação de Auto Inovação (SPSI) 130 com relação à operação dos Appchains 836 e dos Programas Herdados nos Legados do Sistema e BCHAIN 110.
[1194] A. Fig. 1185 ilustra o conceito de autoprogramação da auto inovação (SPSI) 130, além, da Camada de Emulação do Appchain (AEL) 6058, programando e reconfigurando o antigo aplicativo Herdado, Metodologia da Perpetua Doação (MPG) 113 no novo e aprimorado módulo de Conteúdo Metafísico Neuro Econômico (NMC) 13300. Toda, a operação ocorre dentro de um Sistema Herdado 13304 (não compatível com o Protocolo BCHAIN 794) e na API e Estrutura Herdadas 13306. Portanto, o SPSI 130 é um. Appchain 836 que normalmente seria executado exclusivamente na. rede BCHAIN 110. Portanto, o SPSI 130 é executado em o Sistema Herdado 13304 por meio da Camada de Emulação do Appchain (AEL) 6058. A.ssim, o AEL 6058 permite que o SPSI 130 acesse e manipule elementos que existem e operam na API e Estrutura Herdadas 13306. No Estágio 13308, o SPSI 130 executa eficiência e atualizações de funcionalidade, manutenção e modificações gerais no MPG 113.
[1195] No Estágio 13310, o NMC 13300 é produzido como resultado do processamento 130 do SPSI.
[1196] A Fig. 1186 ilustra o conceito de
Petição 870200056145, de 06/05/2020, pág. 700/1737
698/754
Autoprogramação de Auto Inovação (SPSI) 130, além da Camada de Emulação do Appchain (A.EL) 6058, melhorando a iteração já existente do NMC 13300 em. uma Versão Teórica Futura do NMC 13316. Toda a operação ocorre dentro de um Sistema Herdado 13304 (não compatível com o Protocolo BCHAIN 7 94) e na API e Estrutura Herdadas 13306. Portanto, o SPSI 130 é um Appchain 836 que normalmente seria executado exclusivamente na rede BCHAIN 110. Portanto, o SPSI 130 é executado em o Sistema Herdado 13304 por meio da Camada de Emulação do Appchain (AEL) 6058. A^ssim, o AEL 6058 permite que o SPSI 130 acesse e manipule elementos que existem e operam na A.PI e Estrutura Herdadas 13306. No Estágio 1.3308, o SPSI 130 executa eficiência e atualizações de funcionalidade, manutenção e modificações gerais no MPG 113.
[1197] No Estágio 13314, o Future NMC 13316 é produzido como resultado do processamento do SPSI 130.
[1198] A Fig. 1187 ilustra o conceito de Autoprogramação de Auto Inovação (SPSI) 130, além da Camada de Emulação do Appchain (AEL) 6058, convertendo uma versão herdada do NMC 13300 em um Appchain 836 como NMC como um Appchain 114. Toda a operação ocorre dentro de um Sistema Herdado 13304 (não
compatível com o Protocolo BCHAIN 794) e na API e Estrc itura
Herdadas 1 330 6 Portanto, o SPSI 130 é 1 im Appchain 836 que
η o rmaImente ; ser ia executado exclusivamente na rede BCHAIN 110 .
Portanto, o SPSI 130 é executado em o Sistema Herdado 13304 por meio da Camada de Emulação do Appchain (AEL) 6058. Assim, o AEL 6058 permite que o SPSI 130 acesse e manipule elementos que existem e operam na API e Estrutura Herdadas 13306. No Estágio 13318, o SPSI 130 converte o NMC como um Programa Herdado 13300
Petição 870200056145, de 06/05/2020, pág. 701/1737
699/754 em NMC como um Appchain 114 por meio da invocação do Construtor de Ecossistemas Customchain (CEB) 584. No Estágio 13320, o NMC como um Appchain é produzido 114 como resultado do processamento da operação do SPSI 130. Portanto, a NMC final como uma versão Appchain 114 opera a partir da AEL 6058.
[1199] A Fig. 1188 ilustra o conceito de Autoprogramação de Auto Inovação (SPSI) 130, além da Camada de Emulação do Appchain (AEL) 6058, atualizando a eficiência e a funcionalidade da NMC como uma Appchain 114 como uma Appchain 114 de dentro do Sistema Herdado 13304. A versão inicial do NMC 114 existe como um Appchain 836 dentro da Camada de Emulação do Appchain (AEL) 6058. No Estágio 13324, o SPSI 130 realiza atualizações de eficiência e funcionalidade, manutenção e modificações gerais no NMC 114. Isso leva ao Estágio 13326, que define a produção pelo SPSI 130 da Versão Teórica Futura do NMC 13328 como um Appchain 836. Portanto, o Appchains 836 pode ser executado diretamente no Sistema Herdado 13304 e até ser aprimorado no Sistema Herdado 13304.
[1200] A Fig. 1189 ilustra o conceito de A_utoprogramação de A_uto Inovação (SPSI) 130, aprimorando a eficiência e a funcionalidade do NMC como um. Appchain 114 dentro da Rede BCHAIN 110. A versão inicial do NMC 114 existe como um Appchain 836 dentro do Protocolo BCHAIN 794. No Estágio 13332, o SPSI 130 executa atualizações de eficiência e funcionalidade, manutenção e modificações gerais no NMC 114. Isso leva, ao Estágio 13334, que defina a produção pelo SPSI 130 da Versão Teórica Futura do NMC 13328 como um Appchain 836. O 836 pode ser executado diretamente na Rede BCHAIN 110 e até ser atualizado a partir da
Petição 870200056145, de 06/05/2020, pág. 702/1737
700/754
Rede BCHAIN 110.
[1201] [00] A Fig. 1190 mostra uma visão geral dos vários subm.0du.los que operam no Autoprogramação de Auto Inovação (SPSI) 130. O Refinamento Automatizado do Appchain (A2R) 8040 inclui os Appchains 836 e os Programas Herdados para melhorar a eficiência de suas rotinas, e sua usabilidade e confiabilidade. A Manutenção Automatizada do Appchain (A2M) 8042 mantém o Appchain 836 ou o Programa Herdado selecionado, excluindo os Caches Expirados 8725, atualizando as Funções Depreciadas 8726 para as funções utilizáveis, atualizando os Módulos e
Dependências Depreciados 8727 com os módulos utilizáveis, excluindo Pontos de Referência Expirados 8728 (conteúdo ausente etc.) e executando a Calibração de Estabilidade Econômica 8729.
[1202] O Proteção da segurança do Appchain (ASH) 8044 inspeciona autom.aticam.ente pontos de intrusão e exploração em um Appchain 836 ou Programa Herdado. A Conformidade com os Regulamentos do Appchain (ARC) 8046 garante que o Appchain 836 ou. Programa Herdado selecionado esteja em conformidade com vários regulamentos específicos (por exemplo, conformidade com a API REST etc.). A Análise de Unidade de Registro de Diagnóstico (DLUA) 8048 recebe as Unidades de Registro de Diagnóstico (DLU) de rotinas com defeito e estabelece as disposições apropriadas para tentar corrigir essas avarias percebidas. A Correção de
Erros Inatos (IEC) 8050 tenta corrigir falhas fundamentais de procedimentos que podem levar a uma rotina interrompida. O IEC 8050 é destacado para indicar que é usado em caso de usar nas Figs, a seguir em relação ao NMC 13300. O Novo Desenvolvimento Appchain (NAD) 8052 encontra, usos para Aplicativos em um
Petição 870200056145, de 06/05/2020, pág. 703/1737
701/754 ecossistema de Aplicativos especificado (como a Plataforma UBEC 100), que falta um recurso de aplicativo em potencial, o que seria sensivelmente beneficiado para esse ecossistema. O Desenvolvimento Aprimorado do Estrutura (EFD) 8054 inspeciona e aprimora potencialmente as estruturas de software existentes (como linguagens de programação) para os sistemas da Plataforma UBEC 100/Rede BCHAIN 110 e Sistemas Herdado. O Desenvolvimento A_vançado de Hardware (EHD) 8056 modifica sistemas físicos que contêm Placas Condutoras Líquidas Dinâmicas (DLCB) 8856 e, portanto, pode ter sua estrutura de hardware principal otimizada e atualizada. O Mecanismo de Segmentação Appchain (ATM) 8038 processando um algoritmo de seleção inteligente que informa outros módulos para os quais o Appchain 836 eles devem selecionar em seu processamento. O A.TM 8038 informa os módulos A2B. 8040, A2M 8042, ASH 8044, ARC 8046, DLUA 8048 e IEC 8050. Outros módulos possuem seu próprio mecanismo de seleção inato, que difere em lógica do ATM 8038.
[12 03] [00] Figs. 119]. - 1224 mostram a operação e a funcionalidade da Correção de Erros Inatos (IEC) 8050, que é um submódulo de Auto Inovação em Autoprogramação (SPSI) 130 que tenta corrigir falhas fundamentais de procedimentos que podem, levar a uma rotina interrompida.
[1204] A Fig. 1191 mostra a operação e a funcionalidade da Correção de Erros Inatos (IEC) 8050, que é um. submódulo do SPSI 130. O Mecanismo de Segmentação Appchain (A.TM) 8038 seleciona um Appchain Alvo 6060 especificado, que é então enviado como entrada modular para uma instância de Coleção de Fluxo de Execução (ESC) 6700. O Fluxo de Execução que é produzido
Petição 870200056145, de 06/05/2020, pág. 704/1737
702/754 omo saida modular da instância ESC 6700 é enviado como entrada modular para o Estágio 8170 da IEC 8050. O Estágio 8170 separa o Fluxo de Execução do Appchain 836 para produzir o Diagrama 8172 da Estrutura de Código. No Estágio 8174, cada Unidade de Código Selecionada 8188 que existe no Diagrama da Estrutura de Código 8174 é alternada por um loop de programação. Portanto, no Estágio 8178, o LIZARD 120 é invocado para produzir um Mapa de Hierarquia de Propósito 8180 a partir da Unidade de Código Selecionada. No Estágio 8176, o LIZARD 120 é invocado para produzir um Mapa de Hierarquia de Propósito 8182 de todo o Diagrama de Estrutura de Código 8176. Portanto, os Mapas de Hierarquia de Propósito 8180 e 818 2 são enviados como entrada modular para o módulo 7 000 Propósito do Processo de Simetria de Propósito (P2SP) . Depois da conclusão do processamento 7000 do P2SP, o Resultado do Processamento de Simetria 8184 é produzido como a saída modular. Portanto, o Estágio 8186 é executado, executando uma consistência interna, interpretando o Resultado de Processamento de Simetria 8184 para avaliar se cada um dos Mapa de Hierarquia de Propósitos 8180 da Unidade de Código Selecionada está alinhado com o objetivo maior (Mapa de Hierarquia de Propósitos 8182) de todo o Diagrama 8172 da Estrutura de Código.
[1205] A Fig. 1192 mostra detalhes sobre a operação do LIZARD 120 para converter a Unidade de Código Selecionada 8188 em um Mapa de Hierarquia de Propósito 8180. A Unidade de Código Selecionada. 8188 é enviada para o Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura e escrita de código de computador. Para escrever código; ele recebe o Formato de
Petição 870200056145, de 06/05/2020, pág. 705/1737
703/754
Propósito Complexo C325 do Módulo de Propósito (PM) C36. O Formato de Propósito Complexo C325 é então escrito em Sintaxe de Código Arbitrária, também conhecido como ''pseudocódigo' . O pseudocódigo contém implementações básicas das operações de computação que são mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Posteriormente, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação de alvo desejada (linguagem do computador) . Para leitura de código; O SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar um propósito para a funcionalidade desse código. A Unidade de Código Selecionada 8188 é recebida no formato do Fluxo de Execução Cumprido 8189 pela Conversão de Código C321. A. Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e compreendido pela SM C35 em qualquer linguagem de computação conhecido e escolhido. A Conversão do Código C321 também executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saída da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas miais simples para produzir um mapa de funções interconectadas de acordo com as definições de Regras e Sintaxe C322. Portanto, depois da execução completa da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída, modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para derivar uma Propósito no Formato de Propósito Complexo C325 do
Petição 870200056145, de 06/05/2020, pág. 706/1737
704/754 código do computador. Essa definição de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada pelo SM C35. O PM C36 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de
Propósito Complexo C325), consultando as Associações de Propósito C326. O Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção automática/autoprogramação e é direta e exclusivamente programada por especialistas na área relevante. O elemento C335 do IC C333 contém. Estruturas e Bibliotecas
Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória Portanto, o Código Principal C335 permite operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a Política, de Segurança e Objetivos da Empresa. Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1206] A Fig. 1193 continua o fluxo lógico da Fig. 1192 para ilustrar a operação do LIZARD 120 para converter a Unidade de Código Selecionada 81.88 em um. Mapa de Hierarquia de Propósito 8180. A. Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula em. todas as funções interconectadas para produzir uma definição de
Petição 870200056145, de 06/05/2020, pág. 707/1737
705/754 propósito interpretado, pela consulta das Associações de Propósito C326. A saída de definição de Propósito existe no Formato de Propósito Complexo C325, é enviado como saída modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e, o LIZARD 120. A. saída é rotulada como um Mapa de Hierarquia de Propósito 132 42, que é apresentada como a versão do Formato de Propósito Complexo C325 do Padrão Neural Reivindicado 13238. A mesma definição e aplicação do Núcleo Interno (IC) C333 aplicase às funções e módulos mencionados acima.
[1207] A Fig. 1194 mostra detalhes da operação do LIZARD 120 para converter o Diagrama da Estrutura de Código 8172 em um Mapa de Hierarquia de Propósito 8182. O Diagrama de Estrutura de Código 8172 é enviado para o Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura e escrita de código do computador. Para escrever código; ele recebe o Formato de Propósito Complexo C325 do Módulo de Propósito (PM) C36. O Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém implementações básicas das operações de computação mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Depois, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação alvo desejada (linguagem do computador). Para leitura de código; O SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar um propósito para a funcionalidade desse código. O Diagrama da Estrutura de Código 8172 é recebido no formato Fluxos de Execução
Petição 870200056145, de 06/05/2020, pág. 708/1737
706/754
5626 pela Conversão do Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pelo SM C35 em qualquer linguagem de computação conhecido e escolhido. A Conversão de Código C321 também executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A salda da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas, segundo as definições de Regras e Sintaxe C322.
Portanto, depois da execução completa da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. O PM C36 usa o SM C35 para derivar uma Propósito no Formato de Propósito Complexo C325 do código do computador. Essa definição de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada por SM C35.
[12 08] O PM C3 6 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A Interpretação Iterativa C328 circula em. todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. O Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa, por manutenção automatizada/autoprogramação e é programada direta e exclusivamente por especialistas na área relevante. O elemento C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais,
Petição 870200056145, de 06/05/2020, pág. 709/1737
707/754
Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite operação e funcionalidade gerais para o SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define Diretiva de Segurança e Metas Corporativas. Essas definições operam como variáveis de política estática para orientar algumas funções dinâmicas e estáticas do LIZARD 120.
[1209] A Fig. 1195 continua o fluxo lógico da Fig. 1194 para ilustrar a operação do LIZARD 120 para converter o Diagrama da Estrutura de Código 8172 em. um Mapa de Hierarquia de Propósito 8182. A Redução Lógica C323 do Módulo de Sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula através de todas as funções interconectadas para produzir uma. definição de propósito interpretada consultando Associações de Propósito C326. A saída de definição de propósito existe no Formato de Propósito Complexo C325, que é enviado como saída, modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e, para o LIZARD 120. A. saída é rotulada como um Mapa de Hierarquia de Propósito 8182, que é apresentada como a versão do Formato de Propósito Complexo C325 do Diagrama de Estrutura do Código 8172. A mesma definição e aplicação do Núcleo Interno (IC) C333 aplica-se às funções e módulos mencionados acima.
[1210) ] A Fig. 1196 expande os detalhes operacional
do Está g i o 817 0 da Correção de Erros Inatos (IEC) 8050. 0 Estági
8170 separa o Fluxo de E x e c u ç ã o 55 6 d o Appchain AM vo 60 60
Petição 870200056145, de 06/05/2020, pág. 710/1737
708/754
Portanto, uma vez que a Coleta de Fluxo de Execução (ESC) enviou o Fluxo de Execução 556 como entrada modular para o Estágio 8170 da IEC 8050, o Fluxo 556 é enviado como entrada modular para o Estágio 8190. O Estágio 8190 invoca a Renderização de Fluxo de Execução 6400 para interpretar e construir todas as dependências relevantes do suplemento Appchains 836, produzindo o Fluxo de Execução Cumprido 8192. O fluxo 8192 é enviado como entrada modular para o Estágio 8194, que circula através de cada Segmento de Execução Cumprida 551 do Fluxo de Execução Cumprida 8192/556.
[1211] A Fig. 1197 continua o fluxo lógico do Estágio 8170 da Correção de Erro Inato (IEC) 8050. O Fluxo de Execução Cumprido 8192 é enviado como entrada modular ao Estágio 8194, que inicia o Loop da Fig. 1196. No Estágio 8196, o Segmento de Execução Cumprido selecionado 551 é isolado e armazenado no Conjunto de Buffers da Unidade de Código (CUBP) 8198 enquanto mantém (com metadados) o seu contexto relacionai a partir do Fluxo de Execução Cumprido 556. O Prompt 8202 interpreta se há algum Segmento de Execução Cumprida não processado 551 deixado no Loop que foi iniciado no Estágio 8194. Se a resposta ao Prompt 8202 for Sim 8204, o Estágio 8206 será ativado que avançou o Loop do Estágio 8194 para o próximo Segmento de Execução Cumprida 551 disponível. Se a resposta ao Prompt 8202 for No 8208, o Estágio 8200 será ativado que invocou o LIZARD 120 para cobrir todo o conteúdo do CUBP 8198 em um Mapa de hierarquia de Propósito 8210.
[1212] A Fig. 1198 mostra detalhes sobre a operação do LIZARD 120 para converter o Conjunto de Buffers da Unidade de Código (CUBP) 8198 em. um Mapa de Hierarquia de Propósito 8210. O CUBP 8198 é submetido ao Módulo de Sintaxe (SM) C35, que pertence
Petição 870200056145, de 06/05/2020, pág. 711/1737
709/754 à jurisdição de o Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura e escrita de código de computador. Para escrever código; ele recebe o Formato de Propósito Complexo C325 do Módulo de Propósito (PM) C36. O Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também, conhecida como 'pseudocódigo'’ . O pseudocódigo contém, implementações básicas das operações de computação mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Posteriormente, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação de alvo desejada (linguagem do computador). Para leitura de código; O SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar um propósito para a funcionalidade desse código. O CUBP 8198 é recebido no formato de Segmentos de Execução 5628 pela Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e compreendido pela SM C35 em qualquer linguagem, de computação conhecido e selecionado. A Conversão de Código C321 também executa, a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe
arbi. trá: r i os. A saída da execução concluí da da Conversão de Código
C321 é transfe rida como entrada para e i Redução Lógica C323. A
Redução Lógica C32 3 reduz a lógica do código para formas mais
simples p d l 3. p 1? oduzi: r um mapa de funções interconectadas, segundo
as definições de Regras e Sintaxe C322. Portanto, depois da. execução completa da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de
Petição 870200056145, de 06/05/2020, pág. 712/1737
710/754
Propósito (PM) C36. 0 PM C36 usa o SM C 3 5 para d .erivar um
Propósito no Formato de Propósito corn iplexo C 3 2 5 a partir do
código do computador Essa defini ção de p ropósito de ser eve
adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada por SM C35. O PM C36 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. O Núcleo Interno (IC) C333 é a área do LIZARD 120 que não é submetida a programação automática/auto manutenção e é direta e exclusivamente programada por especialistas na área relevante. O elemento Código Principal C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia, e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 habilita a operação e a funcionalidade gerais para
o SM C35 e o PI Ί C3 6, fornecendo bibliotecas e scripts padronizas dos
que permitem a funcionalidade básica. 0 elemento Objetivos dO
Sistema. C33 6 do IC C33 3 defi ne a. Poli ti ca de Segurança e OS
Objetivos da Empresa. Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1213] A Fig. 1199 continua o fluxo lógico da Fig. 1197 para ilustrar a operação do LIZARD 120 para converter o Conjunto de Buffers da Unidade de Código (CUBP) 8198 em. um. Mapa de Hierarquia de Propósito 8210. A Redução Lógica C323 do Módulo
Petição 870200056145, de 06/05/2020, pág. 713/1737
711/754 de Sintaxe (SM) C35 envia sua saída para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula em todas as funções interconectadas para produzir uma definição de propósito interpretado, pela consulta das Associações de Propósito C326. A saída de definição de Propósito existe no Formato de Propósito Complexo C325, é enviado
como saída modul ar para PM C 3 6 e, portanto, para o Núcle o Exterior
(OC) C 3 2 9 e, o LIZARD 120 . A saída é rotulada como l im Mapa de
Hierarquia de Pr Oposito 8210, que é apresentado como a versão do
Formato de Propósito Complexo C325 do CUBP 8198. A mesma
definição Θ aplic ação do Núcleo Interno (IC) C333 aç >lica-se às
funções e mc )dulos mencionados ac rima.
L 214] A Fig. 120 0 continua o fluxo lógico da
Correção de Erros Inatos (IEC) 8050. 0 Conjunto de Buffers da
Unidade d. p C ódigo (CUBP) 8198 é processado em um loc )p (de cada
Unidade de Código potencial) no Estágio 8212. 0 Mapa de Hierarquia de Propósito 8210 de todo o Conjunto de Buffers da Unidade de Código (CUBP) 8198 e o Mapa de Hierarquia de Propósito 8214 da Unidade de Código Selecionado 8188 é submetida ao Propósito do Processamento de Simetria de Propósito (P2SP) 7000, produzindo, portanto, o Resultado de Processamento de Simetria 8216. O Estágio 8218 executa uma verificação de consistência interna para avaliar se o Mapa de Hierarquia de Propósito 8188 da Unidade de Código Selecionado 8214 está alinhado com. um. propósito maior (Mapa, de Hierarquia de Propósito 8210) de toda a Estrutura de Código contida no CUBP 8189. Portanto, no Estágio 8220, qualquer Unidade de Código Desalinhada 8188 que não têm. uma Propósito alinhada com toda, a estrutura de código (do CUBP
Petição 870200056145, de 06/05/2020, pág. 714/1737
712/754
8198) são sinalizadas. Portanto, o Estágio 8220 envia sua saída modular à Retenção de Propósito de Unidade de Código Desalinhado (MCUPR) 8222. No Estágio 8224, cada objetivo de Unidade de Código Desalinhado é iterado em um novo loop para derivar um objetivo adequado para cada unidade que esteja em conformidade com o Mapa de Hierarquia de Objetivo 8182 do Modelo de Estrutura de Código 8172. O processo de derivação de uma Propósito adequada no Estágio 8224 é processado pela Substituição do Propósito Adequado (SPR.) 82 52.
[1215] A Fig. 1201 elabora detalhes operacionais relativos aos Estágios 8218 e 8220 da IEC 8050. A saída modular da instância correspondente do Propósito do Processamento de Simetria de Propósito (P2SP) 7000 é o Resultado de Processamento de Simetria 8216. O resultado é enviado como entrada modular ao
Estágio 8288 do Módulo de Validação de Resultado de Processamento de Simetria (SPRV) 822 6. O Estágio 8228 separa, cada resultado da instância 7040 da Detecção de Integração de A_linnamento (AID) (gerado na lógica interna do P2SP 7000) armazenado no resultado do processamento de simetria 8216. Posteriormente, o Estágio 8230 invoca um loop para cada resultado da instância do AID 7040. No Prompt de loop 8232, é interpretado se o resultado selecionado do AID 7040 é considerado desalinhado de acordo com o Resultado de Processamento de Simetria 8232. Se a resposta ao Prompt 8232 for que não está, desalinhada, o Estágio 8234 será ativado, o que levará o Loop ao próximo resultado do AID 7040. Se a resposta ao Prompt 8232 for Sim, Está Desalinhado 8236, o Estágio 8238 será ativado, emitindo o resultado selecionado do AID 7040 como uma Unidade de Código como saída modular para o SPRV 822 6. Essa saída.
Petição 870200056145, de 06/05/2020, pág. 715/1737
713/754 é enviada ao Estágio 8222 que sinaliza a Unidade de Código Desalinhada armazenando-a na retenção de objetivo de unidade de código desalinhado (MCUPR) 8224. Portanto, a execução do módulo PSRV 8226 sinaliza quaisquer unidades de código desalinhadas validando o resultado de processamento de simetria 8216.
[1216] A Fig. 1202 continua o fluxo lógico da IEC 8050 do Estágio 8224. O Estágio 8224 circula através de cada Propósito da Unidade de Código Desalinhado e deriva um objetivo adequado através da invocação da Substituição de Propósito Adequado (SPR) 82 52 que está em conformidade com o Mapa de Hierarquia de Propósitos 8182 do Modelo de Estrutura de Código 8172. No Estágio 8240, o LIZARD 120 é invocado para converter as substituições de Propósito produzidas pela instância SPR 8252 correspondente nos segmentos de execução 551. Isso leva à ativação do Estágio 8242, que associa cada unidade de substituição de sintaxe ao seu lugar relevante no Diagrama da Estrutura de Código 8172. Posteriormente, no Estágio 8244, um Patch de Implantação 6270 é criado por meio da invocação do módulo do Conjunto de Patch de Implantação (DPA) 6260. Esse patch 6270 contém as Unidades de Substituição de Sintaxe e instruções sobre qual parte do Appchain 836 original, eles devem substituir.
[1217] A Fig. 1203 continua o fluxo lógico da IEC 8050 do Estágio 8240, que invoca o LIZARD 120 para converter Substituições de Propósito em Segmentos de Execução 551, produzindo e enviando resultados para a Retenção da Unidade de Substituição de Sintaxe (SRUR) 8246. O Estágio 8242 associa cada Unidade de Substituição de Sintaxe com seu local correspondente no Diagrama 8172 da Estrutura de Código. O Estágio 8242 faz isso
Petição 870200056145, de 06/05/2020, pág. 716/1737
714/754 ao invocar o módulo da Pesquisa de Modelo de Unidade (UBL) 8248. 0 módulo UBL 8248 produz sua saída para o módulo de Estrutura de Código para Simplificar Processamento (CSS50) 8250, que organiza os dados de entrada em uma saída do Appchain Atualizado 6262. Portanto, o CSSP 8250 invoca o Estágio 8244, que cria um Patch de Implantação que contém as Unidades de Substituição de Sintaxe e instruções para qual parte do Appchain 836 elas substituirão.
[1218] A Fig. 1204 mostra a operação e a funcionalidade do módulo 8252 de Substituição de Propósito Adequado (SPR) com relação à invocação do Estágio 8224 como parte da lógica interna do módulo 8050 de Correção de Erros Inatos (IEC) . O módulo de Retenção de Propósito de Unidade de Código Desalinhado (MCUPR) 8224 é enviado como entrada modular para o Estágio 8254 do SPR 8252. O Estágio 8254 inicia um Loop através de cada Propósito de Unidade de Código Desalinhado de MCUPR 8224. No Estágio 8256, o LOM 132 é chamado para produzir uma Substituição de Propósito 8258, para a Unidade de Código Desalinhado selecionada, que é congruente e compatível com o Diagrama de Estrutura de Código 8260. Portanto, o Diagrama da Estrutura de Código 8172 é event.ualm.ente modificado para conter as Substituições de Propósito 8258, formando, assim, o Diagrama 8260 mais preciso. No Estágio 8240, o LIZARD 120 é invocado para converter as Substituições de Propósito em Segmentos de Execução 556 .
[1219] A Fig. 1205 mostra o procedimento de operação interna do LOM 132 e CTMP 124 em. relação ao Estágio 8256 da Substituição de Propósito Adequado (SPR) 8252. O Diagrama da
Petição 870200056145, de 06/05/2020, pág. 717/1737
715/754
Estrutura de Código 8260, a Unidade de Código Desalinhada 8264 e os Princípios de Design de Conformidade 8262 são fornecidos como entrada inicial para o Prompt de Solicitação de Substituição (RIP) 8266. O RIP 8266 produz um Prompt 8268 que interage diretamente com o LOM 132 para invocar a produção do Objetivo de Substituição 8258, levando em consideração os critérios de entrada do Modelo de Estrutura de Código 8260, Unidade de Código Desalinhada 8264 e Princípios de Design de Conformidade 8262. O
Prompt 8268 produzido Pel .o RIP 82 6 6 é enviado ao módt 11 o C8027 1 do
IQR (Díscur; so Inicial da Consulta) da LOM 132 . Quanc lo o LOM 132
é invocado diretamen te dentro da Plataforma UBEC 100 por um
Usuário UBEC 106, o IQR C802A recebe a pergunta/asserção inicial fornecida pelo Usuário UBEC 106. No entanto, essa instância do LOM 132 é automaticamente invocada pelo RIP 8266. O Prompt 8268 fornecido é analisado por meio da invocação da Retenção Central de Conhecimento (CKR) 648 para decifrar os Detalhes ausentes do Prompt 8268 que são cruciais para concluir o 'entendimento virtual’ correto do LOM 132 pelo LOM 132 para que o LOM 132 atenda/responda totalmente ao Prompt 8268. Os Detalhes ausentes produzidos pelo IQR C802A são enviados como entrada modular para o Esclarecimento da Pesquisa (SC) C803A. O SC C803.A se engaja com a origem do Prompt 8268 para recuperar informações suplementares, para que o Prompt 8268 possa ser analisado objetivamente e com. todo o contexto necessário. Quando o LOM 132 é invocado diretamente dentro da Plataforma UBEC 100 por um Usuário UBEC 106, o SC C803A se envolve com esse Usuário 106 como a origem, da pergunta/resposta. No entanto, essa instância do LOM 132 é invocada automaticamente pelo RIP 8266; portanto, o SC
Petição 870200056145, de 06/05/2020, pág. 718/1737
716/754
C803A se envolve com o RIP 8266 para recuperar informações suplementares sobre o Prompt 8268. A versão totalmente formada e refinada do Prompt 8268 é produzida a partir do SC C803A e enviada
como entrada r ilar ao Construção da Afi rmação (AC ) C808A. 0 AC
C8 0 8A tenta to: rmar uma resposta coe: rente ao Prompt 8268
r e f e r e n. c i a n d o o CKR 648 diretamente e ) por meio c lo Mapeamento
Hierárquico ( HM) C8Í )7A. 0 Apelação Rac i o n a 1 (RA) C811A é um
módulo de contêiner que hospeda um fluxo lógico em interface com
o CTMP 124 . 0 RA C811A usa o CTMP 124 para criticar afirmações.
Essas c irí ti cas podem ter a forma de a' utocríticas (criticando a
saída do AC C8 08A) ou críticas externas à origem da
pergunta/afirmação processada pelo IQR C802A (Usuário UBEC 106 ou RIP 8266) . Se uma afirmação produzida a partir do AC C808A falhar, uma medida significativa do teste de autocrítica processada pelo RA C811.A; então, uma nova instância do AC C808A é invocada para contabilizar as criticas válidas. Se uma AC C808A produzir uma afirmação de alta confiança que passa consistentemente nos testes de autocrítica processados pela RA C811A; a afirmação é produzida como a saida modular 132 da LOM, referenciada como Composição de Decisão de Investimento Ideal 12404 no contexto do Prompt 8268 inicial fornecido pelo RIP 8266.
[1220] A Fig. 1206 mostra mais detalhes do procedimento de operação interna do Apelação Racional (RA) C811A do LOM 132 em relação ao Estágio 12402 do CSE 12400. Construção de Afirmação (A.C) C808A fornece uma Apresentação de Resposta C843 à Apelação Racional (RA) C811A de acordo com a afirmação produzida pela AC C808A em. relação à. entrada correspondente do Prompt 8268. Nesse Estágio do fluxo lógico, a afirmação produzida.
Petição 870200056145, de 06/05/2020, pág. 719/1737
717/754 é classificada como uma Decisão Antes da Crítica C847. Isso indica que isso ainda não foi processado pelas críticas do CTMP 12 4 .
[1221] Pc jrtanto, a afirmação produzida é enviada
diretamente à instânc ia do CTMP 124 como uma entrada 'Opinião
Sub j etiva' C8 4 8 e à Coí nstrução de Contexto (CC) C817A que fornece
a entrada do Fato Objetivo C850 à instância do CTMP 124. 0 CC C817A faz referência aos metadados do AC C808A e a evidência potencial fornecida via. RIP 82 66 para enviar fatos brutos ao CTMP 124 para um pensamento crítico. Esses metadados de entrada são representados pelo arquivo Agregado de Registro LOM 5502. O Agregado de Registro LOM 5502 contém, uma coleção de arquivos de registro relevantes produzidos a partir das principais funções operacionais do LOM 132. Depois da instância do CTMP 124 concluir sua operação, uma Decisão Depois da Crítica C851 é produzida como saída modular. A Decisão Antes da Crítica C847 inicial e a Decisão Depois da Crítica C851 são submetidas ao módulo Comparação de Decisão (DC) C818A, que determina o escopo da potencial, sobreposição entre as duas entradas C847 e C851. A saída, unificada fornecida pelo DC 818A pode indicar a Concessão C852 (do erro) do CTMP 1.24 em. nome da afirmação produzida pelo AC C808A ou uma melhoria percebida C853 em metade da afirmação produzida pelo AC C808A. As Respostas de Argumento C852 e C853 podem ser classificadas como Resultados de Baixa Confiança C845 ou Resultados de Alta Confiança C84 6. Um resultado de Baixa. Confiança C845 indica que a afirmação original produzida pelo A.C C808A é defeituosa e deve ser reconstruída; portanto, o fluxo lógico continua para uma nova instância do AC C808A. Um resultado
Petição 870200056145, de 06/05/2020, pág. 720/1737
718/754 de Alta Confiança C846 indica que a afirmação original produzida pela AC C808A tem mérito; portanto, as conclusões tiradas (juntamente com. qualquer evidência correspondente, premissas etc.) são submetidas à Validação de Conhecimento (KV) C805A.
P o i? l d. n l. o , o fluxo lóg ico continua para uma 11OV ã instância do KV
C805A, e >ara que o Cl·^ '.R 8 4 6 e, portanto, o LOM 132, possam, se
benefici ar da ass erçã· o procs sssada recenteme nte .
[1222] A Fig. 1207 continua o f luxo lógico do
Estágio 12402 do CSE 12400 para ilustrar a prod ução do arquivo
Agregado de Registro LOM 5502. As saídas modulares produzidas a
partir do Discurso Inicial de Consulta (IQR) C8 02A,
Esclarecimento de Pesqu..i sa (SC) C803A, Construção • de Afi. rmações
(AC) C808A, Mapeamento Hierárquico (H M) C807A e 5 Valid/ 3. Ç cL Ο Ο. Θ
Conhecimento (KV) C805A são enviadas para o módulo da Coleção de Registro Modular LOM (LMLC) 5500. Portanto, o LMLC 5500 combina os dados do registro de entrada em um único arquivo legível referido como Agregado de Registro LOM 5502. O arquivo 5502 abrange o estado operacional geral da instância correspondente do LOM 132, fornecendo informações sobre como a instância do LOM 132 chegou a várias conclusões. O Agregado de Registro LOM 5502 é enviado ao CC C817A da Apelação Racional (RA) C811A.
[1223] A Fig. 1208 expande os detalhes operacionais relativos à Fig. 1206 para ilustrar a operação interna do CTMP 1.24 em. relação aos canais de entrada e saída definidos no Apelação Racional (RA) C811A. A Decisão Antes da Crítica. C847 é
Apresentada C843 como saída modular da Construção de Afirmação (AC)
C808A. A Decisão C847 é então marcada, como uma. Opinião
Sub j etiva C8 4 8, cumprindo, portanto, uma das duas principais
Petição 870200056145, de 06/05/2020, pág. 721/1737
719/754
entradas do CTMP 124 . A Opinião S ubjetiva C848 é submetida aos
Metadados do Sis t ema de Entrada C48 4, que atua como entrada
mo d u 1 a r p r .i m á r i a p d jS 3. CTMP 124 e uma representação interna do
Algoritmo de Correspondência de Padrões Selecionados (SPMA). Para esta configuração de instância; o SPMA é LOM 132. Os Metadados do Sistema de Entrada C4 84 são enviados para processamento no Processamento de Razões C456 e no Produção de Percepção Bruta (RP2) C465. 0 Processamento de Razões C456 entenderá logicamente as afirmações feitas comparando atributos de propriedade. 0 RP2 C465 analisa os Metadados do Sistema de Entrada C484 do LOM 132
par a produzir uma percepção no PC :F (Formato Complexo de
Per cepção) que representa a percepção ' algorítmica do LOM 1 32 .
Ess a Percepção produzida é submetida ao Emulador de Observa dor
de Percepção ( POE) C475, que emula a percepção algorítmica do
LOM 132. 0 Processamento de Razões C456 invoca o Processamento de Regras que eventualmente produz conjuntos de regras que refletem no algoritmo SPMA que, neste caso, é o LOM 132. Portanto, dois modos de 'pensamento' são executados, percepção 'analógica' e processamento de conjunto de regras 'digitais'. Essas duas filiais C461 e C475 representam similitudes com intuição e lógica. Os resultados produzidos pelas Filiais Pensantes C461 e C475 são transferidos para a Saida de Decisão Crítica (CDO) C462, que avalia quaisquer elementos fundamentais de conflito ou corroboração entre os resultados. Ao encontrar uma alta magnitude de corroboração interna e uma baixa, magnitude de conflito interno, o CTMP 124 fornece uma decisão binária de Aprovar ou Bloquear, em. relação à entrada inicial da Opinião Subjetiva C848, que é referenciada como um Resultado de Alta Confiança C846. Se
Petição 870200056145, de 06/05/2020, pág. 722/1737
720/754 houver uma baixa magnitude de corroboração interna e uma alta magnitude de conflito interno, o CTMP 124 envia um 'voto de não confiança' que é referido como um Resultado de Baixa Confiança C845. Portanto, a saída resultante do CTMP 124 é considerada a Decisão Depois da Crítica C851.
[1224] A Fig. 1209 mostra mais detalhes sobre a invocação da Produção de Percepção Bruta (RP2) C465 no CTMP 124. O LOM 132 produz a Substituição de Propósito 8258 por meio da provocação da Construção de Afirmação (AC) C808A. O Objetivo de Substituição 8258 é então submetido ao Estágio 5506 do RP2 C465, que descompacta os dados para produzir instâncias de um Rastreio C485 com Correção de Erros e Rastreio de Algoritmo C486 nos Metadados do Sistema de Entrada C484 que se originam da instância AC C808A correspondente. O Rastreio de Depuração C485 é um rastreio no nível de codificação que fornece variáveis, funções, métodos e classes que são usadas junto com a entrada e saída, correspondentes do tipo e conteúdo da variável. A cadeia de invocações de função completa (rastream.en.to de função: funções invocando outras funções) é fornecida. 0 Rastreamento de Algoritmo C486 é um rastreamento em nível de software que fornece dados de segurança juntamente com. a análise de algoritmos. A decisão de segurança resultante (aprovar/bloquear) é fornecida junto com uma trilha logística de como chegou à Decisão C847. 0 peso apropriado referente a cada fator que contribuiu para produzir a Decisão C847 está incluído. Depois disso, o RP2 C465 transfere os dados referentes ao resultado da percepção produzida para o Emulador de Observador da Percepção (POE) 0475 para c
Petição 870200056145, de 06/05/2020, pág. 723/1737
721/754
[1225] A Fig. 1210 elabora a operação da produção de percepção bruta (R.P2) C465 a partir do CTMP 124. Inicialmente, o Estágio 5506 ocorre, como ocorre na Fig. 1209, para descompactar os dados para produzir instâncias do Rastreio de Depuração C485 e do Rastreamento de Algoritmo C486 dentro os metadados C484 do sistema de entrada, originados na instância correspondente do AC C808A. No Estágio 5508, o Processamento Métrico C489 faz a engenharia reversa das variáveis do LOM 132 para extrair percepções da inteligência artificial exibida pelo LOM 132. Posteriormente, os Metadados do Sistema de Entrada C484 são processados pelo Estágio 5510, que separa os Metadados C484 em relacionamentos significativos de causa-efeito de segurança por meio da Separação de Metadados do Sistema (SMS) C487. Como também indicado na Fig. 1209, o RP2 C465 transfere os dados referentes ao resultado da percepção produzida para o Emulador
de Observador da Percepção ( POE) C475 para proces sarnento.
[1226] A Fig. 1 9 1 Ί descreve a operaç :ão do Emulador
de Observador da Percepção ( POE) C475, incl ..uindo a relação C465
da Produção de Percepção Bri ita (RP2) e a Percepção de
A_rmazenamento (PS) C478. A operação do Processamento Métrico C489 e a Separação de Metadados do Sistema (SMS) C487 leva à produção das percepções 5512/5514/5516 que são armazenadas posteriormente no PS C478. As percepções 5512/5514/5516 resultantes representam a resposta modular 132 da LOM de produzir a Substituição de Propósito 8258 via Construção de Afirmação (AC) C808A. O RP2 C465 produz um ponto de dados de formato variável comparável que é alimentado no Pesquisa de Armazenamento (SS) C480 como critério de pesquisa. Posteriormente, o SS C480 executa, uma pesquisa no
Petição 870200056145, de 06/05/2020, pág. 724/1737
722/754
PS C478 para encontrar correspondências com as percepções já existentes armazenadas no PS C478. Os Resultados 0716 da Execução SS 0480 são produzidos, o que leva a um. Cálculo de Peso C718. Esse cálculo C718 tenta encontrar a distribuição correta das percepções correspondentes do PS C478 para replicar e corresponder ao formato de variável comparável que representa a execução do algoritmo LOM 132 que produziu a Substituição de Propósito 8258.
[1227] A Fig. 1212 continua a lógica C475 do Emulador de Observador de Percepção (POE) da Fig. 1211. Depois da produção dos Resultados C716 da Pesquisa de Armazenamento (SS) C480, o Cálculo de Peso C718 é concluído para levar ao Aplicativo C729 das Percepções 5512/5514/5516 para tomar uma decisão ativa de Aprovação C731 ou Bloqueio 0730. A Substituição de Propósito 8258 produzida pela LOM 132 e o Agregado de Registro LOM 5502 correspondente passa pela Análise de Dados C724, que faz com que os B.egistros Aprimorados de Dados C723 para serem derivados, que sejam aplicados no Aplicativo C729 para obter uma Dicotomia de Interpretação 5518 de um Sentimento Positivo (Aprovar) C731 ou um sentimento negativo (Bloquear) C730 em relação à Substituição de Propósito 8258 da entrada. Depois da conclusão bem-sucedida da execução do Aplicativo C729, ocorre a Ação Corretiva de Substituição C476, que é processada pela Saída Crítica (CDO) C462 em paralelo à saída modular da Execução de Regras (RE) C461. 0 módulo Densidade do Conhecimento Autocrítico (SCKD) C4 7 4 estima, o escopo e o tipo de conhecimento desconhecido potencial que está além do alcance do Agregado Registro LOM 5502 relatável. Dessa forma, a instância dos recursos de pensamento crítico
Petição 870200056145, de 06/05/2020, pág. 725/1737
723/754 subsequentes do processamento do CTMP 124 pode alavancar o escopo potencial de todo o conhecimento envolvido, conhecido e desconhecido diretamente pela instância.
[1228] A Fig. 1213 mostra o processo de Memória na Web C4 60 que opera em paralelo com a execução do Emulador de Observador de Percepção (POE) C475 na Fig. 1211. A Substituição de Propósito 8258 produzida pela LOM 132 é enviada como entrada modular ao Processamento de Razão C456.
[1229] 0 Processamento de Razão C456 processado como o LOM 132 alcançou a decisão de produzir a Substituição de Propósito 8258 em resposta ao Prompt 8268 fornecido pelo RIP 8266. A. conclusão do processamento do Processamento de Razão 0456 é a execução do Processamento de Razão 0457, que define as regras que são consistentes de terceiro com o comportamento de execução da LOM 132. Se alguma inconsistência for encontrada no comportamento da regra em relação ao comportamento de execução do LOM, as regras existentes no momento serão modificadas ou novas regras serão adicionadas. Essas regras são posteriormente usadas na instância do CTMP 124 para criticar os comportamentos de tomada de decisão encontrados na instância correspondente do LOM 132. 0 Extensor de Escopo da Regra Crítica (CRSE) C458 aproveita as percepções conhecidas para expandir o escopo de 'pensamento crítico' dos conjuntos de regras, com efeito aprimorando os conjuntos de regras para produzir as Regras Corretas C459. As Regras Corretas C459 são então enviadas como entrada modular para a Separação do Formato da Sintaxe da Regra (RSFS) C499 de dentro da jurisdição operacional da Memória Web C460. 0 RSFS C499 separa, e organiza as Regras Corretas C459 por
Petição 870200056145, de 06/05/2020, pág. 726/1737
724/754 tipo. Portanto, todas as ações, propriedades, condições e objetos são listados separadamente após o processamento do RSFS C499. Isso permite a instância do CTMP 124 discernir quais partes foram, encontradas no campo caótico e quais não foram. A Análise de campo caótico (CFP) C535 combina e formata o Agregado de Registro LOM 5502 em uma única unidade digitalizável referida como Campo Caótico. O Campo Caótico é enviado como entrada modular para o Reconhecimento de Memória (MR) C501. O MP. C501 também recebe as Regras Originais C555, que são o resultado da execução do RSFS C499. O MR C501 varre o Campo Caótico fornecido pelo CFP C535 para reconhecer conceitos conhecíveis definidos nas Regras Originais C555. Essa execução da instância MR C501 produz os Segmentos de Regra Reconhecidos C556. Posteriormente, o Analisador de Cumprimento de Regras (RFP) C498 recebe partes individuais das Regras Originais C555 que foram etiquetadas de acordo com seu reconhecimento ou falta, no Campo Caótico por MR. C501. O P.FP C498 pode deduzir logicamente que conjunto de regras inteiro (a combinação de todas as suas partes) fo.i suficientemente reconhecido no Campo Caótico para, merecer processamento da Execução de Regras (RE) C461. Depois da conclusão bem-sucedida da execução do RE C461, a Ação Corretiva de Substituição C476 é processada pela Saída de Decisão Crítica (CDO) C462 em paralelo à saída modular do Emulador de Observador de Percepção (POE) C475.
[1230] A Fig. 1214 descreve a interação do fluxo lógico entre o Armazenamento de Percepção (PS) C478 e o Mecanismo de Descoberta Automática de Percepção (APDM) C467. O PS C478 contém quatro subconjuntos de percepções: Ângulos de Percepção
Petição 870200056145, de 06/05/2020, pág. 727/1737
725/754
Desconhecidos Deduzidos C473, Todos os Ângulos de Percepção C472, Ângulos de Percepção Implícitos C471, e Ângulos de Percepção Aplicados C470. Os Ângulos de Percepção Aplicados C470 são percepções importadas diretamente pelo estudo do comportamento algorítmico do Algoritmo de Correspondência de Padrões Selecionados (SPMA), que nesta instância é o LOM 132. Os Ângulos de Percepção Implícitos C471 são percepções derivadas de Ângulos de Percepção Aplicados C470 via execução modular de Derivação de Implementação (ID) C477 e APDM C467. Todos os Ângulos de Percepção C472 representa todo o escopo de Percepções conhecidas para a instância CTMP 124 que não foram incluídos pelos Angulos de Percepção Aplicados C470 e Ângulos de Percepção Implícitos C471. Angulos de Percepção Desconhecidos Deduzidos C473 representa o escopo de percepções que se espera existir, mas a instância do CTMP 124 ainda não foi descoberta de acordo com o módulo de Densidade do Conhecimento Autocrítico (SCKD) C474. 0
ID C477 analisa as métricas individuais de Angulos de Percepção Aplicados C470 para derivar determ.inisticam.ente Ângulos de Percepção Implícitos C470, enquanto o APDM C467 varia, criativamente composições de Angulos de Percepção C650 por meio do Módulo de Criatividade 112 para produzir uma Nova Iteração
C653 que combina os dois Pesos de Entrada C652 iniciais.
Portanto, todos os Angulos de Percepção C650 envolvidos no processamento do APDM C467 correspondem e representam a Substituição de Propósito 8258 que é produzida pelo módulo da Construção da Afirmação (AC) C808A da LOM 132.
[1231] A Fig. 1215 elabora os detalhes operacionais referentes ao Exame de Licitação Crítica (CRSE) C458 do CTMP 124.
Petição 870200056145, de 06/05/2020, pág. 728/1737
726/754
Uma instância do Apelação Racional C811A opera no LOM 132 e invoca a Construção de Contexto (CC) C817A para processar o Agregado de Registro LOM 5502 para Análise de Campo Caótico (CFP) C535. O CFP produz um Campo Caótico a partir da saida modular do CC C817A, que é referenciada pelo Reconhecimento de Memória (MR) C501.
[1232] As Regras Atuais C534 exibe conjuntos de regras que são indicativos do estado de funcionamento atual do Algoritmo de Correspondência, de Padrão Selecionado (SPMA) , que neste caso é o LOM 132. As Regras Atuais C534 são enviadas como entrada modular para o módulo de Derivação de Sintaxe de Regra (RSD) C504, que é onde as regras lógicas 'preto e branco' são convertidas em métricas baseadas em percepções. Portanto, o arranjo complexo de várias regras é convertido em uma única percepção uniforme que é expressa por meio de várias métricas de gradientes variados. A saida modular do RSD C504 é fornecida como entrada modular para a Correspondência de Percepção (PM) C503. Na PM C503; uma unidade de Formato Variável Comparável. (CVF) é formada a partir da Percepção recebida do RSD C504. O CVF recémformado é usado para pesquisar percepções relevantes no Armazenamento de Percepção (PS) C478 com índices semelhantes. As correspondências em potencial são enviadas como entrada modular para a Geração de Sintaxe de Regras (RSG) C505. 0 RSG C505 recebe
ρθ JÚ cepções previamente confirm.ad.as, quí 3 são armazenadas no
-F (”y h” mato de Percepção e acessam a composi ção métrica interna da
Per cepção. As Percepçõeí s são recebidas do PS C478, que contém as
Per cepções Previamente Confirmadas C4 6 8. Essas medidas de
métricas baseadas em gradiente são convertidas em conjuntos de
Petição 870200056145, de 06/05/2020, pág. 729/1737
727/754 regras binários e lógicos que emulam o fluxo de informações de entrada/saida da percepção original. Portanto, o RSG C505 produz as Regras Perceptivas C537, que são Percepções consideradas relevantes, populares e que foram convertidas em regras lógicas. Se uma Percepção (no Formato de Percepção Original) tivesse muitos relacionamentos métricos complexos que definissem muitas 'áreas cinzas', as regras locais 'preto e branco' abrangeríam essas áreas 'cinza', expandindo a complexidade do conjunto de regras. Portanto, as Regras Perceptivas C537 são armazenadas por uma Coleção de Definições de Formato de Sintaxe de regras (RSF). As Regras Perceptivas C537 são enviadas como entrada modular para o Reconhecimento de Memória (MR) C501, onde são digitalizadas no Campo Caótico produzido pelo CFP C535. Portanto, o MR C501 produz as Regras Extra C536 que completam as Regras Corretas C533 na sua validade.
[1233] A Fig. 1216 elabora, os detalhes operacionais relativos à Derivação de Implicação (ID) C477 do CTMP 124. Os Ângulos de Percepção Aplicados C470 do Armazenamento de Percepção (PS) C478 são submetidos como entrada modular apara o ID C477 para produzir mais Percepções que pertencem a Ângulos Implícitos de Percepção C471. Os Ângulos de Percepção Aplicados C470 são enviados especificamente para a Combinação Métrica C493 da ID
C477. A Combinação de Métricas C493 separa os Ângulos de
Percepção Recebidos C650 em categorias de métric :as : Escopo C 739,
Tipo C7 40, . Consistência C741, Intensidade C742 . ΐ i dis ponibilú da de
e referência de métrica no sistema não são necessariamente limitadas a esses quatro tipos. A. entrada Ângulos de Percepção C650 é relacionada à Substituição de proposito 8258 que foi
Petição 870200056145, de 06/05/2020, pág. 730/1737
728/754 produzida pelo módulo Construção de Afirmação (AC) C808A. da LOM 132. 0 Conjunto de Complexidade Métrica A C736 é enviado como entrada modular para a Expansão Métrica (ME) C495. Com o ME C495, as métricas de múltiplos e variados Ângulos de Percepção C650 são armazenadas categoricamente nos bancos de dados individuais C739/C740/C741/C742 . A ME C495 aprimora o lote atual de métricas recebidas com detalhes/complexidade extraídos de métricas conhecidas/encontradas anteriormente. Depois da conclusão do aprimoramento e enriquecimento da complexidade, as métricas são retornadas como saida modular ME C495 como Conjunto de Complexidade Métrica B C737 e, posteriormente, convertidas novamente em Ângulos de Percepção C650 para serem, armazenadas em. Angulos de Percepção Implícitos C471, conforme ilustrado na Fig. 1217 .
[1234] A Fig. 1217 continua o fluxo lógico da Derivação de Implicação (ID) C477 da Fig. 1216, ilustrando o Conjunto de Complexidade Métrica B C737 sendo processado pela Conversão Métrica C494 que reverte as métricas individuais de volta em Ângulos de Percepção C650 inteiros. Apesar do processo de enriquecimento e conversão realizado pelo ID C477, os Ângulos de Percepção C650 resultantes ainda fornecem, uma. representação razoavelmente precisa do Substituição de Propósito 8258 produzido pelo módulo de Construção de Afirmação (AC) C808A da LOM 132. Portanto, o processo de Conversão Métrica C494 envia os Ângulos de Percepção C650 recém-derivados/implicitos para Ângulos de Percepção Implícitos C471 no Armazenamento de Percepção (PS) C47 8 .
[1235] A Fig. 1218 detalha, os detalhes operacionais
Petição 870200056145, de 06/05/2020, pág. 731/1737
729/754 relativos à Saída de Decisão Crítica (CDO) C462 do CTMP 124. 0 CDO C462 recebe saída modular das duas principais ramificações do CTMP 124: Emulador de Observador de Percepção (POE) C475 (como a filial da intuição) e Execução da Regra (RE) C461 (como filial lógica). Cada Filial C475/461 envia sua respectiva Decisão Crítica C521 (a principal, saída modular), além de corresponder os 'Meta-metadados’ C521, que fornecem variáveis contextuais que justificam por que a decisão crítica inicial foi alcançada. Os Conjuntos de Decisões C521, que representam as Percepções C516 da POE C475, e as Regras Cumpridas C517 da RE C461, são submetidas ao Módulo de Categorização de Metadados (MCM) C488. 0 MCM C488 separa os Rastreios de Depuração e Algoritmo em categorias distintas usando a categorização de informações tradicional baseada em sintaxe. Essas categorias podem então ser usadas para organizar e produzir respostas de segurança distintas com uma correlação com riscos e assuntos de segurança.
[1236] A. Decisão Intuitiva C514, que representa as Percepções C526 da POE C475, e a Decisão Pensante C515, que
representa as Regras Cumpri _ d ci S C517 da RE C461, são s ubmetic ,*dS
pelo MCM C4 8 8 á Lógica de Processamento Ir i terno 5520 da
Comparação de Decisão de Γ) i Ύ ?eção (DDC) C512 . A I. Ágica de
processamento interno 5520 do DDC C512 verifica se há confirmação ou conflito entre a Decisão intuitiva C514 e a Decisão Pensante C515. O DDC C512 faz referência a urna variável de corte da Política de Código de Conduta Estática (SHP) 488. Se a variável de corte não for alcançada por similaridade entre a Decisão Intuitiva C514 e a Decisão Pensante C515 (ou seja, mais de 90%), a então ocorre a diretiva Comparação Direta Cancelada 5524, que
Petição 870200056145, de 06/05/2020, pág. 732/1737
730/754 pode levar o Controle de Saida do Terminal (TOC) C513 a enviar um Voto de Ausência de Confiança 5544, como mostrado na Fig. 1219. O Estágio Cancelar Comparação Direta 5524 implica que o CTMP 124 não foi capaz de agir internamente consistente em relação ao Prompt 8268 de entrada do RIP 8266. Se a variável de 'corte' foi suficientemente atendida de acordo com a Lógica do Processamento Interno 5520, então o Estágio Decisão Final de Saida 5522 é invocado para combinar as Decisões C514/C515 em uma única saida modular que é recebida e processada pelo TOC C513.
[1237] A Fig. 1219 continua o fluxo lógico da Saída de Decisão Crítica (CDO) C462 da Fig. 1218 e elabora os detalhes operacionais do Controle de Saída do Terminal (TOC) C513. O TOC C513 inicia com o Prompt 5526, que verifica se a Comparação Direta de Decisão (DDC) C512 foi capaz de fornecer um Resultado Final de Decisão 5522 (em. vez da diretiva Cancelar Comparação Direta 5524) . Se a resposta ao Prompt 5526 for Sim 5528, a decisão final combinada fornecida pelo DDC C512 na Saída de Decisão Final 552 será, enviada como saída modular do TOC C513 e, portanto, como saída modular de toda a instância do CTMP 124 como saída Final da Decisão Crítica 5542. Se a resposta ao Prompt 5526 for Não 5530, o Estágio 5532 será invocado, chamando que por sua vez à execução da Correspondência de Percepção (PM) 5532 e buscando os resultados correspondentes. As Regras Cumpridas C517 são extraídas da Decisão Crítica + os Meta-metadados C521 da Execução de Regras (RE) C461. As Regras C517 são convertidas em Percepções pela Derivação de Sintaxe de Regra (RSD) C504. O PM 5532 então faz referência a Meta-metadados para determinar, no Prompt. 5534, se houve uma forte sobreposição interna e corroboração das
Petição 870200056145, de 06/05/2020, pág. 733/1737
731/754 percepções usadas. Se a resposta ao Prompt 5534 for Sim 5538, isso indica um Voto de Ausência de Confiança 5544 em nome do CTMP
124 como saida modular. Se a resposta ao Prompt 5534 for Não 5536, o Estágio 5540 será ativado, que seleciona a decisão menos arriscada percebida entre a Decisão Intuitiva C514 e a Decisão Pensante C515. Portanto, a Decisão Critica Final 5542 é subsequentemente enviada como saída modular para CDO C462, TOC C513 e CTMP 124. A lógica no Estágio 5534 ocorre para determinar se a falta de unidade entre a Decisão Intuitiva 0514 e a Decisão Pensante C515 ocorre devido a uma falta geral de confiança algorítmica ou devido a pontos de vista altamente opostos entre os dois. Portanto, se este último ocorrer, uma Potencial Decisão Crítica Final 5542 ainda é discernível como saída modular. Um
Voto de Ausência de Confiança 5544 sempre leva à Trilha Lógica
C845 de Resultado de Baixa Confiança na Apelação Racional (RA)
C811 A. A Decisão Crítica 5542 pode levar a uma Trilha. Lógica do
Resultado de Alta Confiança C846 ou do Resultado de Baixa
Confiança C845 na RA C811 A, dependendo da. confiança algorítmica por trás da Decisão Crítica Final 5542.
[1238] A Fig. 1220 mostra detalhes sobre a operação do LIZARD 120 para converter a Substituição de Propósito 8258 em.
Segmentos de Execução 8270. A Substituição de Propósito 8258 existe no Formato de Propósito Complexo C325 e é submetida à Expansão Iterativa C327 do Módulo de Propósito C36 dentro do Núcleo Exterior (OC) C329 do LIZARD 120. A Expansão Iterativa. C327 adiciona detalhes e complexidade para evoluir um objetivo simples (indi.retam.ente definido na Substituição de Objetivo 8258) em uma definição específica de propósito complexo. Portanto, o
Petição 870200056145, de 06/05/2020, pág. 734/1737
732/754 potencial máximo da Associação de Propósito C326 da entrada é realizado e mantido como um Formato de Propósito Complexo C325, antes de ser submetido à Derivação Lógica C32 0 do Módulo de Sintaxe (SM) C35. 0 elemento Código Principal C335 do Núcleo Interior (IC) C333 contém Estruturas e Bibliotecas fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória Portanto, o Código Principal C335 permite operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. 0 elemento Objetivos do Sistema C336 do IC C333 define a Política de Segurança e Objetivos da Empresa. Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1239] A Fig. 1221 continua o fluxo lógico da Fig. 1220 para ilustrar a operação do LIZARD 120 para converter a Substituição de Propósito 8258 nos segmentos de execução 8270. Os dados de entrada são recebidos no Formato de Propósito complexo C325 do Módulo de Propósito (PM) C36 e são transferidos para a Derivação Lógica C320 do Módulo de Sintaxe (SM) C35. A Derivação Lógica C320 deriva funções logicamente necessárias de funções inicialmente mais simples. Isso significa que se uma função puder ser formada como uma função derivada devido à implicação de uma função pai mais simples; então é formado pela
Derivação Lógica C320. O resultado produzido é uma árvore de dependências de funções construídas de acordo com os dados definidos Pelo Formato de Propósito Complexo C325. A Derivação Lógica C320 opera de acordo com as definições de Regras e Sintaxe
Petição 870200056145, de 06/05/2020, pág. 735/1737
733/754
C322, que são herdados do elemento Código Principal C335 do Núcleo Interior (IC) C333.
[1240] A Derivação Lógica C320 envia sua saida para a Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e compreendido pela SM C35 em qualquer linguagem de computação conhecido e selecionado. A Conversão de Código C321 também executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. Portanto, o PM C36 invoca o SM C35 para produzir a versão dos Segmentos de Execução resultante 8270 da Substituição de Propósito 8258 de entrada através da Conversão de Código C321. Os segmentos de execução 8270 resultantes, produzidos de forma terminal pela Conversão de Código C321, são a salda modular de SM C35, Núcleo Exterior (OC) C329 e LIZARD 120. Os Segmentos de Execução 8270 são armazenados na retenção de Unidade de Substituição de Sintaxe (SRUR) 8246.
[1241] A. Fig. 1222 detalha a operação e a funcionalidade do módulo 8248 da Pesquisa do Diagrama de Unidade (UBL) em relação ao Estágio 8242 da Correção de Erros Inatos (IEC) 8050. O Estágio 8286 recebe uma entrada modular da SRUR 8246, portanto iniciou um loop que percorre todas as Unidades de Substituição de Sintaxe 8288 do formulário SRUR 8246. O Estágio 8284 recupera a Unidade de Substituição de Sintaxe 8288 selecionada do SRUR. A Unidade de Código Associado ID 8292 é descompactada da Unidade de Substituição de Sintaxe 8288 no Estágio 8290. Em um encadeamento paralelo separado na mesma instância do UBL 8248, o Diagrama de Estrutura de Código 8260 é enviado como entrada modular para o Estágio 8280. O Estágio 8280
Petição 870200056145, de 06/05/2020, pág. 736/1737
734/754 instala o Diagrama da Estrutura de Código 8260 na Nova Retenção do Diagrama da Estrutura de Código (NCSBR) 8282.
[1242] A Fig. 1223 continua o fluxo lógico da Fig. 1222 referente à invocação da Pesquisa de Modelo de Unidade (UBL) 8248 de dentro da lógica interna do Estágio 8242. O fluxo lógico
cont.inua na Fig. 1222 no Estágio 8294, que ins tala a Unidade de
Substituição de Sintaxe 8288 se lecionat ia na Nova Retenção do
Diagrama de Estr utura de Código (NCSBR) 8282 . 0 Es tágio 8296 é
invocado assim que o Loop de processamento iterative invocado no Estágio 8286 for concluído. O Estágio 8296 reverte o status Cumprido dos Segmentos de Execução 551 através do Processamento Coordenado da Estrutura de Código (CSSP) 8250. Portanto, o CSSP 8250 produz o Appchain Atualizado 6262 como saída modular.
[1243] A. Fig. 1224 continua o fluxo lógico da Correção de Erros Inatos (IEC) 8050 a partir da invocação do CSSP 8250 na Fig. 1223. O CSSP 8250 produz o Appchain Atualizado 6262,
que representa a estrutura sintática original, mas com as
Unidades de Código Desalinhadas trocadas pelas Sut )S ti tuições de
Propósito l· kdequada s. 0 Appchain 6262 at uali zado é enviado ao
Conjunto de : patche s de implantação (DPA) 62 60 pa: ra produzir o
Patch de correção do Appchain 627 0. O Appchain Alvo 60 60 é processado pela Coleta de Fluxo de Execução (ESC) 6700, enviando, portanto, o Fluxo de Execução 556 original para uma instância do DPA 6260. Isso permite que o DPA 6260 tenha acesso ao Appchain Alvo 6060 em sua forma original. Como o DPA. 6260 tem acesso ao diferencial entre o Original 6060 e o Appchain atualizado 6262, ele é capaz de produzir o Paten de correção do Appchain 6270, que contém as instruções para converter o Appchain Original 6060
Petição 870200056145, de 06/05/2020, pág. 737/1737
735/754 no Appchain atualizado 6262. No Estágio 8298, o Patch 6270 de correção do Appchain é implementado no Construtor de Ecossistemas Customchain (CEB) 584, que manipula o Appchain Alvo 6060 para que ele converta em conteúdo no Appchain Atualizado 6262.
[1244] [00] A_s Figs. 1225 - 1242 mostram a operação e a funcionalidade da Camada de Emulação Appchain (AEL) 8058 dentro do contexto de uso e aplicabilidade referente ao módulo Conteúdo Metafísico Euro Econômico (NMC). O AEL 8058 permite que o Appchains 836 seja executado em Ambientes Herdados que não participam da Rede BCHAIN 110.
[1245] A Fig. 1225 mostra o módulo Conteúdo Metafísico Neuro Econômico (NMC) 13300 sendo instalado em uma instância PAS (94) da Pilha Já Compilada de Aplicativos (PAS) através do Processamento Estático do Appchain (SA.P) 9480. O SAP 9480 interpreta o conteúdo Appchain 836 do NMC 13300, produzindo assim Retenção estática do Appchain 9402 e enviando-a como entrada modular para o PAS 9400. A Camada de Emulação de Aplicativo (AEL) 8058 é compilada e incorporada ao PAS 9400, fornecendo, portanto, autonomia à instância do PAS 9400 nos Sistemas Herdados. Um submódulo do AEL 8058 é a Interpretação e Detecção do Sistema Alvo (TSID) 9404.
[1246] Portanto, se esse PAS 9400 fosse invocado em um sistema arbitrário, o AEL 8058 seria executado em um conjunto de instruções preliminarmente básico e procuraria detectar o Sistema Operacional 9408, Drivers de Dispositivo 9410 e Hardware 9412 do Sistema Alvo 9406. Portanto, o AEL 8058 invocaria o mecanismo de conversão adequado para executar código complexo no Sistema Alvo 9406, permitindo, assim, que a Retenção estática do
Petição 870200056145, de 06/05/2020, pág. 738/1737
736/754
Appchain 9402 fosse totalmente executado. A retenção 9402 contém os Segmentos de Execução Appchain 836 551 e Segmentos de Dados 553 para NMC 13300, juntamente com. outros Appchains 836 NMC 13300, dependendo da operação, como LOM 132 e LIZARD 120.
[1247] A. Fig. 1226 mostra a operação e a funcionalidade da Camada de Emulação Appchain (AEL) 8058. O Processamento Estático do Appchain (SAP) 9480 produz uma instância de Processamento Estático do Appchain 9402 que contém o NMC 13300 Appchain 836. A Retenção estática, do Appchain 9402 é
enviada como entrada modular para o módulo 943C ) de Execução e
Extração de Segmento de Dados (EDSE) da AEL 8058 . 0 EDSE 9430 é
um módul o de contêin er para 3. invoca .ção da Cole /tá de Fluxo de
Execução (ESC I) 67 0 0 li O liste igio 943 2 e pi ara a invocação do
Classificação do Fluxo de Dados (DSS) 6800 no Estágio 9434. O Sistema. Alvo 9406 é interpretado pelo módulo Interpretação e Detecção de Sistema Alvo (TSID) 9404 por meio da consideração da coleção estática da biblioteca do Sistema Alvo 9442. A Coleção 9442 define os conjuntos de instruções 9444 apropriados aplicáveis a vários tipos de Sistema. 9406. Portanto, o TSID 9404 produz o conjunto de instruções do Sistema Alvo 9444, que permite que a operação interna do AEL 8058 envie as instruções computacionais corretas para o Sistema Alvo 9406. A tradução do Segmento de Execução (EST) 9436 é invocada a partir do Estágio 9432 para, interpretar o Conjunto de Instruções do Sistema Alvo 9444 que, portanto, converte a Sintaxe do Appchain 836 nas instruções herdadas apropriadas. A Conversão de Segmento de Dados (DST) 9438 é invocada a. partir do Estágio 9434 para interpretar o Conjunto de Instruções do Sistema Alvo 9444, que, portanto.
Petição 870200056145, de 06/05/2020, pág. 739/1737
737/754 nverte a Sintaxe ao Appertain 836 nos segmentos herdados de dados apropriados. As saídas modulares do EST 9436 e do DST 9438 são submetidas à Unificação de Instruções Herdadas (LIU) 9440, que invoca uma instância ao vivo do Renderização do Fluxo de Execução (ESR) 6400 para renderizar a Retenção Estática do Appchain 9402 de acordo com. o Conjunto de Instruções do Sistema Alvo 9444. Quaisquer tentativas de manipular elementos fora da jurisdição 8058 da AEL e dentro do Sistema Alvo 9408 (como gravar um arquivo no sistema de arquivos herdado do Sistema. Alvo 9406 são tratadas Delo Middleware de Instrução Externa ÍEIM) 9450.
Portanto, a saída modular do L Implantável 9446 que é entendí 9406 e implica a manifestação Estática do Appchain 9402, imp NMC 13300 Appchain 836 em um. s.i [1248] A Fig. 1 funcionalidade do Middleware de operação do Retenção Estátic instância Renderização de Fli instância do módulo Unificação faz com que o LIU 9440 seja p Externa 9452 e o índice de pront de Instruções 9454 como saída são enviadas como entrada modu. saída 9452 é recebida no Estág LIZARD 120 para converter a Pro em um Mapa de Hierarquia de P Estágio 9466 é executado ve
IU 9440 é um Fluxo de Instruções do e executado pelo Sistema Alvo prática da execução do Retenção licando, portanto, a execução do .sterna herdado.
.227 mostra a operação e a 5 Instrução Externa (EIM) 9450. A a do Appchain 9402 dentro da axo de Execução (ESR) 6400 da de instruções herdadas (LIU) 9440 roduza a Proposição de Instrução :idão para Prontidão de Isolamento modular. Tais saídas 9452 e 9454 lar para o EIM 9450, portanto, a io 9456. O Estágio 9458 invoca o posição de Instrução Externa 9452 ropósito 9462. Posteriormente, o jga o módulo Processamento de
Petição 870200056145, de 06/05/2020, pág. 740/1737
738/754
Realinhamento de Propósito (PRP) 7050 para entradas modulares da Coleção de Propósito em Construção 9460 e Mapa de Hierarquia de Propósito 9462. A Afinidade de Mestre/Escravo 1480 define a Coleção de Propósito de Instrução 9460 como escravo. Portanto, o PRP 7 050 produz a nova iteração da Coleção de Propósito de Instrução 9464 como saida modular. No Estágio 9468, a LIU é invocada para produzir a Prontidão de Isolamento de Instruções 9454 por meio do submódulo C114 do Correspondência do Mapa de Necessidade (NMM) do LIZARD 120. A aplicabilidade da Prontidão de Isolamento de Instruções 9454 é ilustrada na Fig. 1230.
[1249] A Fig. 1228 mostra detalhes sobre a operação do LIZARD 120 para converter a Proposição de Instrução Externa 9452 em um Mapa de Hierarquia de Propósito 9462. A Proposição de Instrução Externa 9452 é submetida ao Módulo Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura e escrita do código do computador. Para escrever código; ele recebe o Formato de Propósito Complexo C325 do Módulo de Propósito (PM) C36. O Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecida como 'pseudocódigo'. O pseudocódigo contém, implementações básicas das operações de computação mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Posteriormente, uma função auxiliar converte o pseudocódigo em código executável, real, dependendo da sintaxe de computação alvo desejada (linguagem de computador) . Para leitura de código; O SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar um propósito para a funcionalidade desse código. A
Petição 870200056145, de 06/05/2020, pág. 741/1737
739/754
Proposição de Instrução Externa 9452 é recebida no formato de
Sintaxe de Comando/Instr ução ESR 5630 pela Cor iversão de Código
C321. A Conversão de C( idigo C321. converte c :ódigo arbitrário
(genéric o) que é recont tecido e compreendido pela SM C3 5 em
qualquer linguagem de computação conhecida e esc :olhida. A
Conversã o de Código C32 1. também executa a f' umçao : Inversa de
converte r linguagens de computação conhecidas em tipos de sintaxe
arbitrários. A saida da execução concluida da Conversão de Código C321 é transferida como entrada para, a Redução Lógica C323. A Redução lógica C323 reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas, de acordo com as definições das Regras e Sintaxe C322. Portanto, após a execução completa da Redução Lógica C323, a execução da instância correspondente do SM C35 é concluida e a saida modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C3 6. 0 PM C3 6 usa o SM C35 para derivar uma Propósito no Formato de Propósito Complexo C325 do código do computador. Essa definição de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada por SM C35. 0 PM C36 também é capaz de detectar fragmentos de código que são secretamente submersos em dados (binários/ASCII etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não passa por manutenção automática/autoprogramação e é direta e exclusivamente programada por especialistas na área relevante. O elemento Código
Petição 870200056145, de 06/05/2020, pág. 742/1737
740/754
Principal C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem, a funcionalidade básica. O elemento Objetivos do Sistema C336 do IC C333 define a Política de Segurança e os Objetivos da Empresa. Essas definições operam como variáveis de política, estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1250] A Fig. 1229 continua o fluxo lógico da Fig.
1228 para ilustrar 3. Operação do LIZARD 12 0 para converter a
Propo sição de Instr' ução Externa 9452 em um Mapa de Hierarquia de
Propó sito 9462.
[1251] A Redução L ógica C323 do Módulo de Sintaxe
(SM) C35 envia sua saída, para a Interpreta ção Iterativa C328 do
Módulo de Propósito (PM) C36. A Interpretação Iterativa C328 circula em todas as funções interconectadas para produzir uma definição de propósito interpretado, pela consulta das Associações de Propósito C326. A saída de definição de Propósito existe no Formato de Propósito Complexo C325, é enviado como saída modular para PM C36 e, portanto, para o Núcleo Exterior (OC) C329 e, o LIZARD 120. A saída é rotulada como um Mapa de Hierarquia de Propósito 9462, que é apresentada como a versão do Formato de Propósito Complexo C325 da Proposição de Instrução Externa 9452. A mesma definição e aplicação do Núcleo Interno (IC) C333 aplica-se às funções e módulos mencionados acima.
[1252] A Fig. 1230 continua o fluxo lógico do
Petição 870200056145, de 06/05/2020, pág. 743/1737
741/754
Middleware de Instrução Externa (EIM) 9450 da Fig.
[1253] 1227 no Estágio 9468, que invoca a Unificação de Instruções Legadas (LIU) 9440 para produzir a variável da Prontidão de Isolamento da Instrução 9454. A variável de Prontidão 9454 define se a Coleção de Propósito de Instrução 9460 é isolada o suficiente no Sistema Alvo 9406 para ser executada sem interferência de sintaxes de execução alternativas. Portanto, o Prompt 9470 é ativado para avaliar se a variável de Prontidão de Isolamento da Instrução 9454 indica, que a Coleta de Propósitos da Instrução 9470 ainda pode ser implantada no Sistema Alvo 9406. Se a resposta ao Prompt 9470 for Implantação Não Pronta 9474, o Estágio 9478 será ativado, o que suspenderá a execução do EIM 9450 até que a próxima Proposição de Instrução Externa 9464 seja produzida pela Renderização de Fluxo Executada (ESR) 6400 por meio da Unificação de Instruções Legadas (LIU) 9440. Se a resposta, ao Prompt 9470 é Pronto para Implantação 9472, o Estágio 9476 invocará o LIZARD 120 para converter a Coleção de Propósito de Instrução 9464 na sintaxe correspondente definida pelo TSID (9404) de Interpretação e Detecção do Sistema Alvo. Portanto, o Estágio 9476 produz um fluxo de instruções implantável 9446 que é uma saida modular para EIM 9450 e é executada nativam.en.te no Sistema Alvo 9406.
[1254] A Fig. 1231 mostra a operação e a funcionalidade da Correspondência do Mapa da Necessidade (NMM) C114, operando como um submódulo do LIZARD'S 120 Shell Dinâmica. C198. A instância do NMM C114 é gerada para atender à operação do Estágio 9468 do módulo 9440 da Unificação de Instruções Herdadas (LIU). A Interpretação e Detecção do Sistema Alvo (TSID)
Petição 870200056145, de 06/05/2020, pág. 744/1737
742/754
9404 é enviada a Necessidade de Acesso, Desenvolvimento e Armazenamento 5550. Portanto, o TSID 9404 é dividido em subcategorias e retido no Armazenamento 5550 como uma série de filiais e camadas hierárquicas. Com a invocação modular do NMM C114, a Análise Inicial C148 baixa cada filial de jurisdição do Armazenamento 5550 para reter temporariamente para referência na instância contínua do NMM C114. Com Calcular as Necessidades da Filial C149: de acordo com as definições associadas a cada filial, as necessidades são associadas ao departamento
cor res jpondente. I /esta rorma, c 1 s verificações de permissão podem
ser formadas na instância do NMM C114. Por exemplo: NMM Cl 14
apr ove )u. a soli c.i t s ç s o para, o departamento d. e Recursos Humanos
faz er o download de todos os currículos dos empregados, porque
foi solicitada dentro da zona da revisão anual do desempenho dos funcionários, de acordo com suas capacidades. Portanto, foi provado ser uma. necessidade válida da jurisdição do departamento. Portanto, o índice de Necessidade C145 é o principal armazenamento das Filiais Jurisdicionais e suas respectivas necessidades. Como essa referência interna é um gargalo de recursos para a operação do NMM C114 e, portanto, todos os módulos que ele serve, é antes otimizada para consultas rápidas ao banco de dados, a fim de aumentar a eficiência geral do sistema. O Estágio 9468 fornece um Propósito de Entrada C139 como entrada modular para o Algoritmo de Pesquisa C144 do NMM C114. O Algoritmo de Pesquisa C144 faz referência e pesquisa o índice de Necessidades C145 compilado, determinando, portanto, se o Propósito de Entrada C139 define uma necessidade válida, de acordo com as filiais de jurisdição definidos inicialmente nas
Petição 870200056145, de 06/05/2020, pág. 745/1737
743/754
Necessidade de Acesso, Desenvolvimento e Armazenamento 5550. Portanto, a execução concluída do Algoritmo de Pesquisa C144 por meio do índice de Necessidade C145 produz uma resposta de Aprovação/Bloqueio C146 que é enviada como saída modular do NMM C114 e referenciada como Resultado da Necessidade C141. Portanto, o Resultado da Necessidade C141 é retornado à lógica interna do Middleware de Instrução Externa (EIM) 9450 como a variável da Prontidão de Isolamento da Instrução 9454.
[1255] A Fig. 1232 mostra, detalhes sobre a operação do LIZA-RD 120 para converter a Coleção de Propósito de Instrução 9462 em um Fluxo de Instruções Implantável 9446. A Coleção de Propósito de Instrução 9462 existe no Formato de Propósito Complexa C325 e é submetida à Expansão Iterativa C327 do Módulo de Propósito C36 dentro do Núcleo Exterior (OC) C329 do LIZARD 120. A Expansão Iterativa C327 adiciona detalhes e complexidade para evoluir uma meta simples (definida indiretamente dentro da Substituição de Propósito 8258) em uma definição específica de Propósito Complexo. Portanto, o potencial máximo de Associação de Propósito C326 da entrada é realizado e retido como um Formato de Propósito Complexa C325, antes de ser submetido à Derivação Lógica C320 do Módulo de Sintaxe (SM) C35. O elemento Código Principal C335 do Núcleo Interior (IC) C333 contém Estruturas e Bibliotecas fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código Principal C335 permite operação e funcionalidade gerais ao SM C35 e PM C36, fornecendo bibliotecas e scripts padronizados que permitem a funcionalidade básica. O elemento Objetivos do Sistema
Petição 870200056145, de 06/05/2020, pág. 746/1737
744/754
C336 do IC C333 define a Politica de Segurança e Objetivos da Empresa. Essas definições funcionam como variáveis de politica estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1256] A Fig. 1233 continua o fluxo lógico da Fig.
1232 para ilustrar a operação do LIZARD 120 para converter a Coleção de Propósito de Instrução 9462 em um Fluxo de Instruções Implantável 9446. Os dados de entrada são recebidos no Formato de Propósito Complexa C325 do Módulo de Propósito (PM) C36 e é transferido para a Derivação Lógica C320 do Módulo de sintaxe (SM) C35. A Derivação Lógica C320 deriva funções logicamente necessárias de funções inicialmente mais simples. Isso significa que, se uma função pode ser formada como uma função derivada devido à implementação de uma função-pai mais simples; então é formada pela Derivação Lógica C320. O resultado produzido é uma árvore de dependências de funções construídas de acordo com os dados definidos Pelo Formato de Propósito Complexo C325. A Derivação Lógica C320 opera de acordo com. as definições de Regras e Sintaxe C322 que são herdadas do elemento Código Principal C335 do Núcleo Interior (IC) C333 e da Coleção da Biblioteca do Sistema Alvo 9442 por meio da Detecção da Interpretação do Sistema Alvo (TSID). A Derivação Lógica C320 envia sua saída para a Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e entendido pelo SM C35 em qualquer linguagem de computação conhecido e escolhido. A Conversão de Código C321 também executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. Portanto, o PM C36 invoca o SM C35 para produzir a
Petição 870200056145, de 06/05/2020, pág. 747/1737
745/754 versão 8270 dos Segmentos de Execução resultante da Substituição de Propósito 8258 de entrada via Conversão de Código C321. Os Segmentos de Execução 8270 resultantes, produzidos de forma terminal pela Conversão de Código C321, são a saida modular do SM C35, Núcleo Exterior (OC) C329 e o LIZARD 120. Os Segmentos de Execução 8270 são armazenados na retenção da Unidade de Substituição de Sintaxe (SRUR) 8246.
[1257] A. Fig. 1234 mostra a operação e a funcionalidade do Processamento Estático do Appchain (SAP) 9480, que converte os Appchains vivos e ativos 8 36 em uma Retenção Estática do Appchain 9402 implementável. A execução do SAP 9480 é normalmente invocada manualmente, por um. Usuário UBEC 106 ou Usuário Genérico 5068 e por meio de uma Interface Administrativa 9482. No Estágio 9482, uma Proposta de coleção do Appchain 9488 é produzida a partir da Interface Administrativa 9482, definindo o escopo do(s) Appchain(s) 836 que o Usuário UBEC 106/Usuário Genérico 5068 deseja incluir na saida modular final da Retenção Estática do Appchain 9402. No Estágio 9484, as Coleções de Execução e Segmento de Dados 6902/6904 são produzidas a partir das referências da coleção Proposta do Appchain 9484. No Estágio 9486, a Coleção Proposta do Appchain 9488 é processada por uma instância gerada de Renderização do Fluxo de Execução (ESR) 6400 de dentro do Ambiente de Captura Modificado (MCE) 6174. O MCE 6174 é um. ambiente de execução personalizado que instala pontos de acionamento para vários eventos, para que informações sobre dependência e remoção de erros possam ser derivadas da sessão de execução. Posteriormente, o módulo DRF (6176) de Solicitação de Dependência, é invocado na instância SAP 9480 em conjunto com a
Petição 870200056145, de 06/05/2020, pág. 748/1737
746/754 instância MCE 6174. No Estágio 9490, uma solicitação de execução ou de dados é feita pela instância do ESR 6400. O Prompt 9492 avalia as Coleções de Segmentos Execução 6902 e Dados 6904 para determinar se a Solicitação de Execução ou Dados feita pelo ESR 6400 existe nessas Coleções 6902/6904. Se a resposta ao Prompt 9492 for Não Existe 9494, será solicitado o Prompt 9498, que avaliará se a Execução correspondente ou o Segmento de Data (do ESR 6400) é justificado de acordo com o submódulo C114 da Correspondência do Mapa da Necessidade (NMM) da LIZARD 120. A resposta de Não Existe 9496 para o Prompt 9492 é avaliada na Fig. 1238 .
[1258] A Fig. 1235 elabora os detalhes operacionais referentes ao Estágio 9498 do módulo Processamento Estático do Appchain (SAP) 9480. A Coleção Appchain 9488 proposta é submetido como entrada modular ao Estágio 9500, que separa o Coleção 9500 em referências independentes do Appchain 836 que são armazenadas posteriormente no Retenção de Cache de Referência do Appchain (ARCR) 9502. O Estágio 9504 gera um loop que circula por todas as instâncias do Appchain 836 no ARCR 9502. O Estágio 9508 recupera a instância do Appchain selecionada 9506 de um Nó de Cache Relevante 786 da Rede BCHAIN 110 e pelo Protocolo BCHAIN 1104. Portanto, o Estágio 9508 (que é detalhado na Fig. 1236) produz a Instância Appchain Cumprida 9510, que é processada no Estágio 9512 por meio de invocações do Coleta de Fluxo de Execução (ESC) 6/00 e Classificaçao cio Fluxo de Dados (DSS) 6800. O ESC 6700 produz um Fluxo de Execução 9514 que é enviado como entrada modular para o Estágio 9518 e o DSS 6800 produz um Fluxo de Dados 9516 que também é enviado como entrada modular para o Estágio
Petição 870200056145, de 06/05/2020, pág. 749/1737
747/754
9518. Portanto, o Estágio 9518 coleta os vários fluxos de execução 9514 e de Dados 9516 na Coleta de Segmentos de Execução 6902 e Coleta de Segmentos de Dados 6904. O Estágio 9519 é subsequentemente processado, avançando o loop iniciado pelo Estágio 9504 para a próxima Instância do Appchain 9506 disponível.
[1259] A Fig. 1236 detalha os detalhes operacionais referentes ao Estágio 9508 do módulo Processamento Estático do Appchain (SAP) 9480. O Estágio 9508 invoca, o gerador de declaração de conteúdo (CCG) 3050 da função BCHAIN Protocolo 794. Portanto, é produzido um Pedido de Reivindicação de Conteúdo (CCR) 2308 com um Trilha de Linha de Base Proposto (PBHP) 2322. O CCR 2308 é enviado na Rede BCHAIN 110 para que, eventualmente, alcance um Nó de Cache Correspondente 3260 que contém partes da Instância Appchain Solicitada 9506 (nesse caso, é o NMC 13300 Appchain 836). O Nó de Cache 6526 cumpre a CCR 2322, sendo assim compensado economicamente por meio do Protocolo BCHAIN 794 e aproveitando a Economia de Watt, do Metachain 834. O Nó de Cache 6526 produz uma Unidade Correspondente CCF 2323 em resposta à CCR correspondente 2308. O recém-produzido CCF 2318 viaja ao longo da Rede BCHAIN 110 para alcançar o módulo Renderização de Reivindicação de Conteúdo (CCR) 3300 do Nó 786 que está processando a instância do SAP 9480. As Instruções de Decodificação de Conteúdo 3316 são referenciadas para renderizar a resposta CCF 2318, que, portanto, produz a Instância Appchain Cumprida 9510. Portanto, a Execução 551 e os Segmentos de Dados 553 do NMC 13300 Appchain 836 foram recuperados.
[1260] A Fig. 1237 elabora o fluxo lógico do
Petição 870200056145, de 06/05/2020, pág. 750/1737
748/754 submódulo 6176 da Atendimento de Solicitação de Dependência (DRF) dentro da instância Processamento Estático do Appchain (SAP) 9480, retomando, portanto, a partir da Fig. 1234. A resposta Existe 9494 ao Prompt 9492 invoca o Estágio 9498, que verifica se a Execução ou o Segmento de Dados Correspondente é Justificado 9520 de acordo com. o NMM C114. Se a resposta Justificada 9520 ao Prompt 9498 ocorrer, o Estágio 9524 será chamado, marcando o Execução de Segmento ou Data para inclusão na Retenção de Cache do Segmento Marcado (MSCR) 8652. O fluxo lógico da resposta Não Justificado 9522 ao Prompt 9498 é mostrado em Fig. 1238. A conclusão do Estágio 9524 implica a conclusão do processamento da instância do DARF 6176. Portanto, depois do Estágio 9524, é invocado o Estágio 9526, que associa a Instância do Appchain Cumprida 9510 aos seus Segmentos Marcados Correspondentes Encontrados no MSCR 8652. O Estágio 9508 recupera a Instância do Appchain Selecionada 9506 de um Nó de Cache Relevante 786 através do Protocolo BCHAIN 794, produzindo, portanto, a Instância Appchain Cumprida 951.0, conforme ilustrado na Fig. 1236.
[1261] A Fig. 1238 elabora o fluxo lógico do submódulo 6176 da Atendimento de Solicitação de Dependência (DRF) dentro da instância do Processamento Estático do Appchain (SAP) 9480 com relação ao Estágio 9486 do Ambiente de Captura Modificado (MCE) 6174. A resposta Não Existe 9496 ao Prompt 9492 e a. resposta Não Justificada 9522 ao Prompt 9498 levam, à ativação do Estágio 5 600, que gera e envia, uma Unidade de Registro de Diagnóstico (DLU) 1182 que contém um Token Oficial do Sistema 1184. Este Token 11.84 está incluído para indicar que a função ou programa, correspondente atingiu um estado não ideal se uma função
Petição 870200056145, de 06/05/2020, pág. 751/1737
749/754 oficial dentro da Plataforma UBEC 100. O DLU 1182 é enviado ao módulo Envio de Registro de Diagnóstico (DLS) 1160, invocado pelo Mecanismo de Pesquisa Automatizado (ARM) 134 do LOM 132 para fornecer o DLU 1182 ao SPSI 130. Portanto, o SPSI 130 é capaz de processar as informações de diagnóstico encontradas na DLU 1160 com. o módulo de Análise de Unidade de Registro de Diagnóstico (DLUA_)8048. Isso leva ao Estágio 13005, que representa o DLUA 8048 sendo chamado para executar as modificações correspondentes ao I2GE 122 e/ou MCE 6174 para evitar o motivo inicial pelas quais as respostas especificadas foram invocações para os Prompts 9492 e 9498.
[1262] A resposta Justificado 9520 ao Prompt 9498 invoca o TBM (62) para a instância Renderização de Fluxo de Execução (ESR) 6400 que está sendo emulada no I2GE 122. Portanto, o TBM 6240 permite que o processo de variação evolutiva do I2GE 122 continue enquanto o original do encadeamento do DR.F 617 6 está sendo processado. Isso é feito para obter eficiência operacional.
[1263] A Fig. 1239 mostra a operação e a funcionalidade da Correspondência do Mapa da Necessidade (NMM) C114 operando como um submódulo do LIZARD'S 120 Shell Dinâmico C198. A instância do NMM C114 é gerada para atender à operação do Estágio 9528 do módulo 6176 do Realização de Solicitação de Dados (DRF) do Processamento Estático do Appchain (SAP) 9480. A Coleção do Segmento de Execução 6902 e a Coleção do Segmento de Dados 6904 são enviadas para armazenamento nas Necessidade de A.cesso, Desenvolvimento e Armazenamento 5550. Portanto, as coleções 6902/6904 são divididas em subcategorias e mantidas no Armazenamento 5550 como uma série de ramificações e camadas
Petição 870200056145, de 06/05/2020, pág. 752/1737
750/754 hierárquicas. Após a invocação modular do NMM C114, a Análise Inicial C148 baixa cada filial de jurisdição do Armazenamento 5550 para reter temporariamente para referência na instância em. andamento do NMM C114. Com Calcular Necessidades de Filial C149:
de acordo com as definições associadas a cada filial, as necessidades são associadas ao departamento correspondente. Dessa forma, as verificações de permissão podem ser formadas na instância do NMM C114. Por exemplo: O NMM C114 aprovou a solicitação para o departamento de Recursos Humanos fazer o download de todos os currículos dos Empregados, porque foi solicitada dentro da zona da revisão anual do desempenho dos funcionários, de acordo com suas capacidades. Portanto, foi provado ser uma necessidade válida da jurisdição do departamento. Portanto, o índice de Necessidade C145 é o principal armazenamento das Filiais Jurisdicionais e suas respectivas necessidades. Como essa referência interna é um gargalo de recursos para a operação do NMM C114 e, portanto, todos os módulos que atende, ela é antes otimizada para consultas rápidas ao banco de dados para aumentar a eficiência geral do sistema. O Estágio 9530 fornece um Propósito de Entrada C139 como entrada modular para o Algoritmo de Pesquisa C144 do NMM C114. O Algoritmo de Pesquisa C144 faz referência e pesquisa o índice de Necessidade C14.5 compilado, determinando, portanto, se o Objetivo de Entrada C139 define uma necessidade de ID de valor de acordo com os ramos de jurisdição inicialmente definidos em Desenvolvimento e Armazenamento de Acesso a Necessidades 5550. Portanto, a execução concluída do algoritmo de pesquisa C144 por meio do índice de Necessidade C145 produz uma resposta Aprovar / Bloco C146 que é
Petição 870200056145, de 06/05/2020, pág. 753/1737
751/754
enviada como saida modular do N MM C114 e referenciada como
Resultado da Necessidade C141. Poruanuo, o Resultado da
Necessidade Cl 41. é retornado ao Eí stágio 9498 do DRF 6176 e SAP
9480 .
[1264] A Fig. 1240 mostra detalhes sobre a operação do LIZARD 120 para converter as solicitações de execução 9532 e de dados 9534, da instância de execução de renderização em fluxo (ESR) 6400 do ambiente de captura modificada (MCE) 6174, em um Mapa de Hierarquia de Propósito 9536. Proposição de Instrução Externa 9452 é enviada para o Módulo de Sintaxe (SM) C35, que pertence à jurisdição do Núcleo Exterior (OC) C329. O SM C35 fornece uma estrutura para leitura e escrita de código de computador. Para escrever código; ele recebe o Formato de Propósito Complexo C325 do Módulo de Propósito (PM) C36. O Formato de Propósito Complexo C325 é então escrito na sintaxe de código arbitrária, também conhecida como 'pseudocódigo' . O pseudocódigo contém implementações básicas das operações de computação mais comuns entre todas as linguagens de programação, como instruções if/else, loops etc. Posteriormente, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe de computação de destino desejada (linguagem de computador) . Para leitura de código; O SM C35 fornece uma interpretação sintática do código do computador para o PM C36 para derivar um. propósito para a funcionalidade desse código. A Proposição de Instrução Externa 9452 é recebida no formato de Sintaxe de Comando/Instrução ESR 5630 pela Conversão de Código C321. A Conversão de Código C321 converte código arbitrário (genérico) que é reconhecido e compreendido pela SM
Petição 870200056145, de 06/05/2020, pág. 754/1737
752/754
C35 em qualquer linguagem de computação conhecido e selecionado. A Conversão de Código C321 também executa a função inversa de converter linguagens de computação conhecidas em tipos de sintaxe arbitrários. A saída da execução concluída da Conversão de Código C321 é transferida como entrada para a Redução Lógica C323. A Redução Lógica C323 reduz a lógica do código para formas miais simples para produzir um mapa de funções interconectadas, segundo as definições de Regras e Sintaxe C322. Portanto, depois da execução completa da Redução Lógica C323, a execução da instância SM C35 correspondente é concluída e a saída modular do SM C35 é enviada para a Interpretação Iterativa C328 do Módulo de Propósito (PM) C36. 0 PM C36 usa o SM C35 para derivar uma Propósito no Formato de Propósito Complexo C325 a partir do código do computador. Essa definição de propósito descreve adequadamente a funcionalidade pretendida da seção de código relevante, conforme é interpretada por SM C35. 0 PM C36 também é capaz de detectar fragmentos de código que estão secretamente imersos nos dados (binários/ASCII etc.). A Interpretação Iterativa C328 percorre todas as funções interconectadas para, produzir uma definição de propósito interpretada (no Formato de Propósito Complexo C325), consultando as Associações de Propósito C326. 0 Núcleo Interno (IC) C333 é a área do LIZARD 120 que não é submetida a manutenção automática/auto programação e é direta e exclusivamente programada por especialistas na área relevante. O elemento Código Principal C335 do IC C333 contém Estruturas e Bibliotecas Fundamentais, Scripts de Gestão de Tópicos e Balanceamento de Cargas, Protocolos de Comunicação e Criptografia e Sistemas de Gerenciamento de Memória. Portanto, o Código
Petição 870200056145, de 06/05/2020, pág. 755/1737
753/754
Principal C335 habilita a operação e a funcionalidade gerais para o SM C35 e o PM C36, fornecendo bibliotecas e scripts padronizados que permitem, a funcionalidade básica. 0 elemento Objetivos do Sistema C336 do IC 0333 define a Política de Segurança e os Objetivos da Empresa. Essas definições operam como variáveis de política estática para orientar várias funções dinâmicas e estáticas no LIZARD 120.
[1265] A Fig. 1241 continua o fluxo lógico da Fig. 1240 para, ilustrar a operação do LIZARD 120 para converter as solicitações de execução 9532 e de dados 9534 em um Mapa de Hierarquia de Propósito 9536.
[1266] A Redução Lógica 0323 do Módulo de Sintaxe (SM) 035 envia sua saída para a Interpretação Iterativa 0328 do Módulo de Propósito (PM) 036. A Interpretação Iterativa 0328 circula em todas as funções interconectadas para produzir uma definição de propósito interpretado, pela consulta das Associações de Propósito 0326. A saída de definição de Propósito existe no Formato de Propósito Complexo 0325, é enviado como saída modular para PM 036 e, portanto, para o Núcleo Exterior (00) 0329 e, o LIZARD 120. A saída é rotulada como um Mapa de Hierarquia de Propósito 9536, que é apresentada como a versão Formato de Propósito Complexo 0325 da Execução 9532 e Solicitações de Data 9534. A mesma definição e aplicação do Núcleo Interno (10) 0333 aplica-se às funções e módulos mencionados acima.
[1267] A. Fig. 1242 mostra uma visão geral final dos aspectos rn.ac.ro do processamento 9480 do Processamento estático do Appchain (SAP) . 0 SA.P 94 8 0 é chamado manualmente por um Usuário
Petição 870200056145, de 06/05/2020, pág. 756/1737
754/754
UBEC 106 ou Usuário Genérico 5068 por meio de uma Interface administrativa 9482. O Estágio 9482 recebe uma Proposta de Coleção do Appchain 9488 como entrada modular, que neste exemplo contém referências ao NMC 13300 Appchain 836. Um Loop é iniciado no Estágio 9504, que percorre todas as Instâncias do Appchain 9506 do Retenção de Cache de Referência do Appchain (ARCR) 9502. No Estágio 9538, a Instância do Appchain Cumprida 9510 é recuperada do Retenção de Cache do Segmento Marcado (MSCR) 8652, levando, portanto, ao Estágio 9540. A*s Instâncias Appchain Cumpridas 9510 contêm o conjunto completo de segmentos de execução 551 e dados 553 necessários para executar o Appchain 836 escolhido (como NMC 13300 neste caso), incluindo quaisquer dependências modulares, como o Appchain 836 completo para LOM 132, CTMP 124 e LIZARD 120. O Estágio 9540 instala de forma incrementai todas as instâncias do Appchain cumpridas na Retenção Estática, do Appchain 9402, na qual cada Execução 551 de saida ou Segmento de Dados 553 está sendo verificada por ter o status Marcado pelo MSCR 8652. Portanto, a Retenção Estática do Appchain 9402 é produzida, como a saida modular final do SAP 9480 e, posteriormente, é submetida como entrada modular ao módulo 9430 de Execução e Extração de Segmento de Dados (EDSE) da Camada de Emulação do Appchain, (AEL) 8058.

Claims (110)

1. SISTEMA DE CONEXÕES UNIVERSAIS DE BCHAIN TODOS/TUDO/TODA PARTE, caracterizado por compreender:
a) aplicações UBEC que operam em conformidade com o protocolo BCHAIN;
b) rede BCHAIN que compreende uma pluralidade de nós de BCHAIN, que operam o software em conformidade com o protocolo BCHAIN;
c) Appchains, que compreendem armazenamento de dados, prestação e programas computacionais que operam diretamente na Rede BCHAIN;
d) Inteligência Governante Independente Legislada por UBEC (LUIGI) que compreende um mecanismo de controle artificialmente inteligente em uma Plataforma UBEC;
em que no paradigma de interação de nó que existe na Rede BCHAIN, a Metachain é uma cadeia de cliente que contém metadados em que todos os nós na Rede BCHAIN se conectam para referência essencial e primária, onde a Metachain rastreia as informações fundamentais que contêm localizações de nó/setor, tendências de demanda de conteúdo e roteamento de salto para agilizar a configuração de infraestrutura, em que é necessário que todos os Nós de BCHAIN participem da leitura da Metachain, em que as Appchains são cadeias de cliente que atuam como contratos inteligentes avançados para fornecer informações por meio da infraestrutura que foi organizada pela Metachain, em que as Appchains podem se referir a entrada/saída no Ecossistema de cadeia de cliente paralelo e agrupado, em que as Microchains são Appchains que são automaticamente convertidas em uma cadeia de cliente que não depende nem se conecta à Metachain.
Petição 870190069340, de 22/07/2019, pág. 7/126
2/110
2 . SISTEMA, de acordo com a reivindicação 1, caracterizado pelo protocolo BCHAIN, Transmissão de Informações Enfileiradas (QIB) gerencia as Solicitações de Alegação de Conteúdo (CCRs) ou Comprimento da Alegação de
Conteúdo (CCFs) que são devidos para a transmissão a outros nós, em que os pacotes de informações CCR e CCF são encaminhados à Porta de Comunicações (CG), que é a camada exclusiva de interface entre o Protocolo BCHAIN (BP) e a Interface de Hardware do Nó, em que a CG encaminha informações referentes aos Nós adjacentes à Pesquisa Estatística de Nó (NSS), em que a NSS rastreia o comportamento do Nó adjacente que causa a formação de quatro índices a serem calculados: índice de Fuga de Nó, índice de Saturação de Nó, índice de Consistência de Nó, índice de Sobreposição de Nó, em que o índice de Fuga de Nó rastreia a probabilidade de um Nó vizinho fugir para a vizinhança do Nó de Percepção, em que o índice de Saturação de Nó rastreia a quantidade de Nós em uma faixa de detecção de Nó de Percepção, em que o índice de Consistência de Nó rastreia a qualidade dos serviços dos Nós conforme interpretado por um Nó de Percepção, em que o índice de Sobreposição de Nó rastreia a quantidade de Nós sobrepostos entre si conforme interpretado por um Nó de Percepção, em que o Nó de Percepção é aquele que executa o caso de NSS.
3. SISTEMA, de acordo com a reivindicação 2, caracterizado pelas quatro variáveis resultantes serem enviadas ao Sistema de Corroboração Estratégica (SCS), o qual força o consenso de Protocolo entre os Nós, em que Adaptação Estratégica Dinâmica (DSA) recebe as variáveis NSS para alterar dinamicamente a Implantação Estratégica que são baseadas na Composição de Critérios Estratégicos calculada, em que a
Petição 870190069340, de 22/07/2019, pág. 8/126
3/110
Composição de Critérios Estratégicos contém uma ampla gama de variáveis que informam os elementos principais, importantes e complementares do Protocolo BCHAIN sobre como operar, em que as Appchains Registradas contêm chaves de acesso criptográfico de diversas Appchains, em que uma atualização a uma Appchain é anunciada nas Atualizações da Appchain da Metachain, seu dispositivo fará o download das atualizações mais recentes à Appchain, que se manifestarão como uma Prova Criptográfica de Direito que se origina das chaves criptográficas armazenadas nas Appchains Registradas.
4. SISTEMA, de acordo com a reivindicação 1, caracterizado por LUIGI receber um nivel permanente e irrevogável codificado de privilégio administrativo e executivo dentro da plataforma UBEC; LUIGI ser programado e mantido exclusivamente por SPSI; LUIGI ser hospedado exclusivamente na Rede distribuída de BCHAIN; em que a Autoinovação de Autoprogramação (SPSI) é uma Appchain que se programa automaticamente e a outras Appchains dentro da plataforma UBEC que recebem designação oficial.
5. SISTEMA, de acordo com a reivindicação 1, caracterizado pela Extração de Objetividade Lexical (LOM) tentar chegar o mais próximo possível da resposta objetiva a uma ampla gama de perguntas e/ou afirmações, LOM se envolve com o usuário de UBEC para permitir a ele conceder ou melhorar seu argumento contra a posição de LOM, em que o Mecanismo de Pesquisa Automatizado (ARM) tenta fornecer constantemente à CKR novo conhecimento para aprimorar as capacidades de avaliação geral e de tomada de decisão de LOM.
6. SISTEMA, de acordo com a reivindicação 5, caracterizado pela Appchain do conteúdo do LOM alojar os
Petição 870190069340, de 22/07/2019, pág. 9/126
4/110 principais módulos no formato de uma Appchain, em que a Appchain possui seus Segmentos de Execução extraídos por meio de ESC para produzir o Fluxo de Execução, que se manifesta como os principais módulos que operam LOM, em que o Raciocínio de Consulta Inicial (IQR) recebe a questão/afirmação inicial provida pelo Usuário UBEC e subsequentemente impulsiona a Retenção de Conhecimento Central (CKR) a decifrar detalhes ausentes que são cruciais no entendimento e atendimento/resposta à questão/afirmação, em que a Construção de Afirmação (AC) recebe uma proposta na forma de uma afirmação ou questão e provê produção dos conceitos relacionados a tal proposta, em que o Mapeamento Hierárquico (HM) mapeia os conceitos associados para encontrar corroboração ou conflito na consistência da questão/afirmação e calcula os benefícios e riscos de ter uma determinada posição sobre o tópico, em que o Recurso Racional (RA) critica afirmações sobre se é autocrítica ou crítica de respostas humanas pelo uso de tecnologia CTMP, em que a Validação de Conhecimento (KV) recebe conhecimento altamente confidencial e pré-criticado que precisa ser separado de forma lógica quanto à capacidade de consulta e assimilação no CKR, em que com a Análise de Referência Cruzada (CRA), as informações recebidas são comparadas e concebidas considerando o conhecimento préexistente do CKR, em que o Fluxo de Execução se manifesta na realidade uma vez, executado pelo ESE, em que os Segmentos de Dados chegam da Lógica ampla de sistema do UBEC para a Appchain de Conteúdo do LOM, em que os Segmentos de Dados são processados por ESE junto à lógica principal de LOM definida pelo Fluxo de Execução e enumerada como a Manifestação Modular do Fluxo de Execução, em que a entrada Segmentos de Dados se
Petição 870190069340, de 22/07/2019, pág. 10/126
5/110 manifesta como Entrada de Questão/afirmação de LOM, em que a execução de ESE produz Segmentos de Dados que são retornados à Lógica ampla de sistema UBEC como resposta formal do LOM à Entrada de Questão/afirmação de LOM.
7. SISTEMA, de acordo com a reivindicação 1, caracterizado pelo Perfil de Inteligência Pessoal (PIP) armazenar as informações pessoais do usuário UBEC por meio de diversos possíveis endpoints e front-ends.
8. SISTEMA, de acordo com a reivindicação 4, caracterizado pelo mecanismos de implantação automatizado ser adaptado para implantar a Plataforma UBEC como um Aplicativo nos dispositivos de hardware, em que SPSI envia ao software, firmware e hardware atualizações para Lógica Principal Hibridizada do UBEC/BCHAIN, no qual a Plataforma UBEC possui sua própria Base de código distinta, que colabora com a Base de código do Protocolo BCHAIN, em que ambas as Bases de código se conectam diretamente ao Plugin da Interface Modular, que garante a execução compatível das Bases de código em diferente hardware e que opera as composições do sistema operacional dos Nós da BCHAIN, em que a Lógica Principal Hibridizada é em seguida implantada por meio de uma das Rotinas de Implantação diferentes, a qual é selecionada em conformidade com o hardware correlato e composição do sistema operacional do Nó selecionado da BCHAIN.
9. SISTEMA, de acordo com a reivindicação 1, caracterizado pelo Repasse UBEC recebe o tráfego de informações que estão ocorrendo do UBEC como uma Appchain, em que na análise das informações de passagem, as informações são devolvidas ao UBEC como uma Appchain por meio do Retorno Abrangente do UBEC para continuar sua jornada subsequente e
Petição 870190069340, de 22/07/2019, pág. 11/126
6/110 atingir seu destino pretendido na Plataforma UBEC, em que as informações recebidas do Repasse UBEC são encaminhadas para a Delegação de Tarefa LUIGI (LTD), que determina se os dados devem ser processados pelo LOM, LIZARD ou ambos, em que a Ação Corretiva de LUIGI (LCA) é invocada para gerenciar apropriadamente os eventos e transações de acessos às informações que estão ocorrendo na Plataforma UBEC.
10. SISTEMA, de acordo com a reivindicação 4, caracterizado por, quando um novo aplicativo, ou uma atualização a um aplicativo já existente, é enviado ao LUIGI utilizar a tecnologia LIZARD para identificar os padrões de jurisdição corretos de modo que possa ser compreendido se um aplicativo é necessário no UBEC ou não, em que LUIGI Bloqueia ou Aprova o envio do aplicativo, o qual é uma execução que se manifesta na Ação Corretiva do LUIGI (LCA).
11. SISTEMA, de acordo com a reivindicação 1, caracterizado pela Interação de Nó do Usuário (UNI) usar dados biométricos diretos para autenticação e não fazer referência a quaisquer nomes de usuário nem conteúdos de conta, em que os Nós, dados e serviços estão diretamente ligados aos dados biométricos do usuário, em que os dados biométricos são então transferidos à Categorização de Banda Biométrica (BBC), que cria uma versão arredondada dos dados que elimina as variações da medição de dados biométricos devido às margens de erro no equipamento de medição de dados biométricos, em que para cada entrada de dados biométricos na BBC um Código de Autorização de Banda (BAT) correspondente é produzido como saída, em que a comparação é feita entre os BATs gerados mais recentes e os Códigos de Autenticação armazenados na Appchain de Associação de Banda, em que a quantidade de dados biométricos provida é
Petição 870190069340, de 22/07/2019, pág. 12/126
7/110 medida e verificada caso suficiente para o processo de autenticação.
12. SISTEMA, de acordo com a reivindicação 11, caracterizado por, dentro do BBC, ser criada a Separação Granular da Entrada Biométrica Genérica recebida, em que a Separação Granular representa a Entrada Biométrica Genérica em um formato que quantifica os escopos de magnitude encontrados na entrada, em que as composições variáveis dos Dados Biométricos são reunidos no mesmo formato que destaca os pontos de dados de alta e baixa magnitude, em que o escopo dos pontos de dados são ampliados para criar um Formato que é pretendido por ser maior que o erro de margem esperado, em que as Categorias de Banda produzidas no Formato são armazenadas como um Código de Autorização de Banda (BAT).
13. SISTEMA, de acordo com a reivindicação 1, caracterizado pelo Ecossistema da cadeia personalizada ser uma interação complexa das Appchains, Microchains, junto à única Metachain para produzir um sistema dinamicamente adaptável de retenção de dados e serviço junto à execução de programa/rotina que compõem a Rede BCHAIN, em que a Loja de App UBEC existe dentro do Ecossistema de cadeia personalizada para hospedar, listar e servir os Aplicativos UBEC, em que o Dispositivo Habilitado para UBEC seleciona e baixa o Aplicativo UBEC A da Loja de App UBEC, em que os Segmentos de Execução são coletados da Appchain AO que se correlaciona com o Aplicativo UBEC A, em que os Segmentos de Execução coletados são enviados à Coleção de Fluxo de Execução (ESC), o qual os reúne no Fluxo de Execução AO, em que a montagem realizada pelo ESC considera a ordem correta que os Segmentos de Execução precisam ser alinhados, em que a execução dos Segmentos de Execução de Fluxo de
Petição 870190069340, de 22/07/2019, pág. 13/126
8/110
Execução AO ocorre no módulo de Execução de Fluxo de Execução (ESE), em que, em paralelo ao processamento e montagem do Fluxo de Execução AO, está o processamento e montagem de Fluxos de Dados AO e Z3, que são realizados por meio do Estágio que coleta os Segmentos de Dados da Appchain AO e os envia para classificação na Classificação de Fluxo de Dados (DSS), em que os Fluxos de Dados AO e Z3 são mencionados pelo ESE para executar corretamente os comandos listados no Fluxo de Execução AO .
14. SISTEMA, de acordo com a reivindicação 13, caracterizado pelos diversos Ecossistemas de cadeia personalizada comporem a Rede BCHAIN, em que o Aplicativo UBEC A e Aplicativo UBEC B compõem, cada, seus próprios Ecossistema de cadeia personalizada, em que em cada Ecossistema de cadeia personalizada que se correlaciona com um aplicativo há uma Appchain de Conteúdo, em que a Appchain de Conteúdo faz referência aos Fluxos de Execução e Fluxos de Dados que são armazenados nas Appchains de Suplemento.
15. SISTEMA, de acordo com a reivindicação 13, caracterizado pelos Ecossistemas de cadeia personalizada conter Appchains Independentes que não pertencem nem representam um Aplicativo UBEC específico, em que os Fluxos de Execução ou Fluxos de Dados separados podem ser extraídos das Appchains Independentes.
16. SISTEMA, de acordo com a reivindicação 13, caracterizado pelo Usuário UBEC inserir Criatividade e decisão à Interface do Gestor de Logística (LMI), em que a LMI produz a Camada Logística, que é um formato genérico de informação que define a logística do Aplicativo projetada pelo Usuário UBEC por meio da LMI, em que a Camada Logística é enviada como
Petição 870190069340, de 22/07/2019, pág. 14/126
9/110 entrada ao Criador de Ecossistema de cadeia personalizada (CEB), em que o CEB cria automaticamente o Aplicativo Logístico, conforme considerado pelo Usuário UBEC, ao usar os blocos de criação fundamental que consistem em um Ecossistema de cadeia personalizada, em que no Fluxo Lógico do Criador de Ecossistema de cadeia personalizada, inicialmente o Estado Atual da Appchain é interpretado para interpretar as posições relevantes de que os Segmentos de Execução e Segmentos de Dados existem, em que os Segmentos de Execução são reunidos em um Fluxo de Execução na ordem correta para garantir a execução correta do programa pelo ESE, em que os Segmentos de Dados são coletados e reunidos em um Fluxo de Dados por meio do processamento de DSS, em que o Processamento Lógico CEB Interno produz Suplementos de Execução + Dados, que são armazenados no bloco mais recente da Appchain, em que os novos Suplementos de Execução e Dados para a Appchain inicia o processamento na Rede BCHAIN por meio de um Novo Anúncio de Conteúdo (NCA), em que o conteúdo é submetido ao Armazenamento de Dados do Mempool (MDS) dos exploradores, onde é eventualmente explorado no bloco seguinte da Appchain 602 por meio do Módulo de Interface da cadeia personalizada (CIM), em que o conteúdo do bloco recémexplorado é cortado em partes de cache e é transferido para memorização de nós por meio de Semeadura de Cachê que fornece Nós de Exploração, em que as partes de cache migram gradual e automaticamente para áreas de serviço otimizado que garantem o melhor tempo de operação e velocidade de download possível aos nós que solicitam os dados, em que os nós reivindicam o conteúdo dos nós de memorização por meio do Gerador de Reivindicação de Conteúdo, em que uma vez baixados, os nós
Petição 870190069340, de 22/07/2019, pág. 15/126
10/110 executam o Fluxo de Execução por meio do ESSE, que leva à manifestação do aplicativo pretendido.
17. SISTEMA, de acordo com a reivindicação 1, caracterizado por uma Unidade de Watt ser uma moeda criptográfica que é indexada de forma algoritmo ao valor de eletricidade, em que as Unidades de Watt são criadas diretamente e destruídas pelo LUIGI à medida que a liquidez entra e sai da Economia de UBEC, em que a Pesquisa de Preço de Energia Distribuída (DEPS) pesquisa Nós de BCHAIN que possam relatar autenticamente o preço atual da moeda fiável de eletricidade, em que o Câmbio de Terceiros (TPCE) atua como a camada logística para gerenciar a compra e venda de moeda fiável que permite a liquidez fluir para dentro e fora da Economia de Watt da Metachain, em que no TPCE, os Usuários UBEC que estão procurando vender ou comprar Unidades de Watt são essencialmente pareados juntos em uma troca, em que o valor da moeda fiável de uma Unidade de Watt Unit é indexado ao valor relatado pela DEPS, em que quando um Usuário UBEC compra uma quantidade de Unidades de Watt, um Relatório de Transação Verificada que detalha a quantidade adquirida é enviado ao LUIGI, em que mediante aprovação do LUIGI sobre a transação, um Usuário que compra as Unidades de Watt leva à Criação de Unidade de Watt na Interface de Economia LUIGI (LEI), em que quando um Usuário UBEC que vende uma quantidade de Unidades de Watt, um Relatório de Transação Verificada que detalha a quantidade adquirida é enviado ao LUIGI, em que mediante aprovação da transação pelo LUGI, um Usuário que compra Unidades de Watt leva à Destruição da Unidade de Watt na Interface de Economia LUIGI, em que as funções de LEI exigem conhecimento e acesso à Alocação de Fundos Provados do Usuário
Petição 870190069340, de 22/07/2019, pág. 16/126
11/110 (UPFA) , em que a Alocação de fundo na UPFA é distribuída de forma inteligente entre os nós de acordo com seu tipo pelo qual mitiga o risco de um nó ser danificado/roubado.
18. SISTEMA, de acordo com a reivindicação 1, caracterizado pelo Usuário UBEC poder selecionar Personalidades Econômicas, em que a Personalidade Econômica (Equalizador) ocorre quando as fontes do nó são consumidas para corresponder apenas ao que o Usuário UBEC consome, em que a Personalidade B (Lucro) ocorre quando o nó consume o máximo possível de fontes locais, contanto que a margem de lucro seja superior a X, em que a Personalidade C (Consumidor) ocorre quando o Usuário UBEC paga pelas unidades de trabalho por meio de uma moeda negociada de modo que conteúdo possa ser consumido enquanto gasta menos fontes de nó, em que a Personalidade D (Altruísta) ocorre quando as fontes do nó são gastas o máximo possível e sem qualquer restrição de esperar nada em troca, em que a Imposição de Trabalho Considerado Economicamente (ECWI) faz referência à Economia de Watt da Metachain para determinar o Superávit/Déficit atual deste nó em relação ao trabalho tornado crédito, em que o Superávit/Déficit de Trabalho Atual é encaminhado à ECWI, que considera a Personalidade Econômica selecionada e o Superávit/Déficit para avaliar se deve ser realizado mais trabalho atualmente.
19. SISTEMA, de acordo com a reivindicação 1, caracterizado por, se os critérios definidos na Implantação de Estratégia conhecidos como Critérios de Disseminação de Salto Paralelo tiverem sido atendidos, então o Nó invoca a Lógica de Salto Paralelo (PHL), em que isto leva aos Nós específicos que iniciam mais Vias de Salto Paralelo do que receberam, o que leva a uma redundância nas Vias de Salto em relação ao CCR ou
Petição 870190069340, de 22/07/2019, pág. 17/126
12/110
CCF que percorre, em que as Vias de Salto Paralelo Redundantes mitigam o risco apresentado pela desordem ao aumentar as chances de que, pelo menos em quantidade mínima de vias exigidas, atinja o Alvo Final sem uma interrupção significativa decorrente da desordem, em que o Alvo Final pode receber uma confirmação que se origina de um consenso descentralizado devido às Vias de Salto Paralelo redundantes que são iniciadas pela PHL, em que para um pacote de CCR ou CCF ser aceito no seu Nó de destino, ele deve chegar de pelo menos um número predeterminado de Vias de Salto separadas, em que a Redução de Via de Salto Superparalelizada (OPHPR) detecta as Vias de Salto Paralelo que se tornaram uma carga ineficiente no sistema e devem ser interrompidas de continuar sua jornada subsequente, em que a quantidade de Vias de Salto Paralelo redundantes que são geradas depende do tamanho da taxa da Unidade de Watt que foi pré-autorizada para o Código de Autorização Econômica (EAT) do CCR ou CCF, em que a funcionalidade de potencializar o movimento físico dos Nós é processada pela Camada de Migração de Dados Físicos (PDML) dos módulos e Uso de Migração de Dados Físicos (PDMU), em que a funcionalidade de Migração Física permite um aumento geral completo no sistema, já que os movimentos físicos dos Nós são feitos para trabalhar em favor da eficiência da Rede em vez de contra ela.
20. SISTEMA, de acordo com a reivindicação 1, caracterizado pelos Setores serem agrupamentos de Nós de BCHAIN que facilitam logisticamente a orientação e roteamento de percurso dentro da Rede BCHAIN, em que em qualquer determinado momento qualquer Nó da BCHAIN esteja sob a jurisdição de exatamente dois Setores, em que as definições de Setores são derivadas do Hash de Escopo Duplo gerado pelo Consenso de
Petição 870190069340, de 22/07/2019, pág. 18/126
13/110
Escopo de Tráfego (TSC), em que a Descoberta da Via do Setor Otimizado (OSRD) interpreta o estado geográfico da Rede BCHAIN conforme definido na Metachain e produz Vias de Setor Otimizado que são efetivamente Vias Rápidas de informações, em que as informações são submetidas à Via do Setor Otimizado da Metachain, as informações estatísticas incluindo Força de Percurso (eficácia) e Saturação de Percurso (demanda/uso) são incluídas na Via do Setor Otimizado da Metachain.
21. SISTEMA, de acordo com a reivindicação 2, caracterizado por um Nó de BCHAIN usar CCG para gerar CCR, que é por fim enviado para o Nó do Alvo Final, em que o CCR é equipado com a Via de Salto Basal Proposto (PBHP) e Pacote Variável de Trilho (TVS), em que a PBHP contém informações sobre a sequência proposta de nós para salto, para eventualmente atingir o Alvo Final, em que o TVS contém informações dinâmicas sobre o gerenciamento logístico de fornecimento de CCR, em que os elementos de gerenciamento logístico incluem o Código de Autorização Econômica (EAT) e um caso de Implantação Estratégica que é referenciada durante o percurso dentro de um Setor específico, em que o CCR percorre por meio dos Nós que existem nos Nós Intermediários, em que na chegada bem sucedida do CCR ao Nó do Alvo Final, o Nó executa o Fornecimento de Reivindicação de Conteúdo (CCD) para tentar atender à solicitação de conteúdo realizada pelo Nó solicitante, em que um pacote de Cumprimento de Reivindicação de Conteúdo (CCF) é enviado em troca, que percorre pelo Nó Intermediário para o Nó solicitante, em que o CCF é processado pela Renderização de Reivindicação de Conteúdo (CCR), em que o CCR faz uso de Cache de Conteúdo de Liberação de
Petição 870190069340, de 22/07/2019, pág. 19/126
14/110
Escalonamento (SRCC) para manter as partes do conteúdo até que toda a unidade de conteúdo possa ser completamente renderizada.
22. SISTEMA, de acordo com a reivindicação 2, caracterizado pelo mecanismo de Conteúdo de Transmissão Direta não faça uso de (CCRs), em que o Conteúdo precisa ser preenchido por meio de CCFs para os Nós que solicitam tal Conteúdo de acordo com a implicação de sua descrição e jurisdição, em que o módulo Envio de CCF Jurisdicionalmente Implicado (JICS) opera em um Nó de BCHAIN que percebe a necessidade jurisdicional do fornecimento de conteúdo de outro Nó, em que um CCF é enviado por meio dos Nós Intermediários sem um CCR de acompanhamento, em que o CCF é recebido e validado no Nó de Alvo Final pela Recepção de CCF Jurisdicionalmente Aceito (JACR) e, daí por diante, renderizado pelo CCR.
23. SISTEMA, de acordo com a reivindicação 2, caracterizado pelo Sistema de Corroboração de Estratégia (SCS) usar o modulo de Consenso de Escopo de Tráfego (TSC) para fornecer uma coleção de Hash de Escopo Duplo, em que a composição do Hash de Escopo Duplo é por fim derivada das quatro variáveis pela Pesquisa Estatística de Nó (NSS); índice de Fuga de Nó, índice de Saturação de Nó, índice de Consistência de Nó e o índice de Sobreposição de Nó, em que as variáveis são derivadas por NSS do Comportamento de Tráfego Externo, em que os Anúncios Hash são trocados entre diferentes áreas de tráfego conhecidas como Setores, em que cada Nó detecta dois hashes devido ao algoritmo que é executado no Consenso de Escopo de Tráfego (TSC) , em que a Lógica de Reconhecimento de Hash Duplo exige que pelo menos um dos dois hashes corresponda a dois nós para poder se comunicar entre si, em que devido ao arredondamento para baixo/arredondamento
Petição 870190069340, de 22/07/2019, pág. 20/126
15/110 para cima lógico empregado no TSC, um nó é capaz de atravessar para diferentes ambientes de rede enquanto mantém o consenso com os demais nós devido a apenas um hash poder mudar por vez, portanto, o nó é obrigado a ter uma sobreposição com pelo menos um hash com Nós circundantes sob o Protocolo BCHAIN.
24. SISTEMA, de acordo com a reivindicação 23, caracterizado pela Pesquisa Estatística de Nó (NSS) reunir informações sobre o comportamento dos Nós circundantes para calcular quatro índices importantes, que, por sua vez, informa os módulos que operam as principais funções do Protocolo BCHAIN sobre o estado da Rede BCHAIN em relação à atividade e comportamento do Nó, em que o modulo Lógico de Interação de Nó (NIL) opera como um subgrupo de Porta de Comunicações (CG) e interage com a Interface do Hardware por meio do Sistema Operacional e Endpoints da API, em que todos os zunidos relacionados aos Nós nas proximidades imediatas do Nó que está executando o caso de NSS são encaminhados para Processamento de Zunido de Nó (NPP), em que a Atividade de Nó DB (NAD) é um banco de dados local que retém dados brutos em relação à atividade de zunido do Nó, em que a NAD é uma fonte primária de informações para o NPP realizar Questões Operacionais que levam ao Cálculo de índice da coleção de Variáveis de índice de Nó, em que os Registros de Zunido de Nó são inicialmente recebidos no Tráfego Recebido, em que cada Registro de Zunido de Nó contém a identidade referente ao Nó relevante, bem como a Marcação de hora de Validade, em que a Marcação de hora faz com que o NSS relate até as informações de data que refletem o estado atual das proximidades locais da Rede BCHAIN, em que as Questões Operacionais processam os Registros de Zunido de Nó em lotes, enquanto considera a Marcação de hora de Validade,
Petição 870190069340, de 22/07/2019, pág. 21/126
16/110 em que os Registros são finalmente calculados de acordo com os critérios das quatro Variáveis de índice de Nó no Cálculo de índice.
25. SISTEMA, de acordo com a reivindicação 24, caracterizado por, em relação ao Sistema de Corroboração Estratégica (SCS), o Consenso de Escopo de Tráfego (TSC) produzir um grupo de Hash de Escopo Duplo ao mencionar
variáveis de NSS e definições estáticas da Política Codificada Estática (SHP), em que o SCS invoca a Derivação de Identidade de Setor (SID) a usar os Hashes de Escopo Duplo para atuar como uma base para definir as Identificações Atuais de Setor, em que cada Nó em qualquer dado momento existe na jurisdição de exatamente dois Setores, cada um definido pelo Hash 1 e Hash 2, em que a Corroboração de Hash dos Hashes que são anunciados das Proximidades circundantes são verificados em oposição aos Hashes localmente produzidos, em que, caso nenhum dos hashes corresponda, então o Nó Vizinho é adicionado à Lista de Bloco de Nó, em que com os Nós de Percepção de Tráfego de Nó Específico que são reconhecidos como legítimos devido ao seu Anúncio de Hash correspondente podem informar os demais Nós sobre os Nós que suspeitam ser Falsos e que operam além dos limites do Protocolo BCHAIN definidos na Política Codificada Estática (SHP).
26. SISTEMA, de acordo com a reivindicação 25, caracterizado pelo TSC invocar NVP a receber as variáveis da Pesquisa Estática de Nó (NSS) e produzir uma Média de Composite de Variáveis de NSS (NVCI), em que com os Nós NVP de dentro dos mesmos Setores anunciam uma percepção das Variáveis de NSS entre si para criar o consenso sobre as características do Setor por meio do qual as variáveis de NSS locais e remotas
Petição 870190069340, de 22/07/2019, pág. 22/126
17/110 são agrupadas para criar uma média de composite conhecida como NVCI, em que NVCI é usado para manter o consenso sobre o escopo e definição deste Setor, e portanto onde recai seus limites físicos, em que a versão agrupada do índice de Fuga de Nó é arredondada para baixo ao múltiplo X mais próximo, em que a versão agrupada de índice de Saturação de Nó é arredondada para baixo ao múltiplo X mais próximo, em que a versão agrupada do índice de Consistência de Nó é arredondada para baixo ao múltiplo X mais próximo, em que a versão agrupada do índice de Sobreposição de Nó é arredondada para baixa ao múltiplo X mais próximo no Estágio, em que todas as avariáveis então produzidas no Estágio são mescladas em uma única variável.
27. SISTEMA, de acordo com a reivindicação 26, caracterizado pelos Fatores de Desempenho serem produzidos pelo Agrupamento de Variável de NSS (NVP) e também serem arredondados para baixo ao múltiplo X mais próximo, em que os Fatores de Desempenho são medições de desempenho em relação ao tráfego de Rede no Setor relevante, em que o valor X usado no Estágio de arredondamento se origina do Múltiplo de Arredondamento de Consenso de Tráfego da Implantação Estratégica, em que a Implantação Estratégica é extraída de um Pacote de Variável de Trilho (TVS) que é processado pelo Processamento de Evento Cruzado de Setor (SCEP), em que esperase que o Múltiplo seja diferente dentro de cada Setor, contudo permaneça igual para todos os Nós dentro do mesmo Setor por meio do qual os resultados da mescla se tornem a base para o Hash 1 do Hash de Escopo Duplo, em que para a base para o Hash 2, o mesmo NVCI seja mencionado a partir do processo de arredondamento para baixo, exceto o processo que arredonda para cima a partir do mesmo múltiplo X que é obtido do Múltiplo
Petição 870190069340, de 22/07/2019, pág. 23/126
18/110 de Arredondamento de Consenso de Tráfego, em que os mesmos Fatores de Desempenho do NVP são processados apesar de arredondado para cima.
28. SISTEMA, de acordo com a reivindicação 1, caracterizado pela Adaptação Estratégica Dinâmica (DSA) atuar como a estrutura para criar variáveis dinâmicas que controlam os fatores de processamento dentro da Rede BCHAIN, em que as variáveis são acondicionadas e transferidas por meio da Implantação Estratégica que é realizada em um Pacote de Variável de Trilho (TVS), em que o DSA mantém constantemente e ajusta as variáveis que controlam as operações de Rede de acordo com o estado da rede física, conforme relatado pelas variáveis de NSS por meio da Interpretação de Desordem de Campo (FCI), em que a FCI interpreta o nível geral de desordem da disponibilidade do Nó em toda a Rede BCHAIN, em que a Implantação Estratégica é um conjunto acondicionado de critérios que estabelece valores operacionais nos módulos do Protocolo BCHAIN, em que o Algoritmo de Seleção de Estratégia Otimizado (OSSA) seleciona a Estratégia Ideal mais adequada que opera melhor em condições ambientais que foram declaradas pelo NSS, em que a Estratégia Preferida Atual (SCM) é usada como entrada para o Módulo de Criação de Estratégia (SCM) para ajustar a estratégia com experimentação, em que SCM usa o Módulo de Criatividade para hibridizar a forma da Estratégia Preferida Atual com a interpretação atual de Desordem de Campo do FCI.
29. SISTEMA, de acordo com a reivindicação 28, caracterizado pela Designação e Comprovação de Prioridade (PAP) modificar os Critérios de Implantação de Estratégia para realizar com prioridade estendida de acordo com a quantidade
Petição 870190069340, de 22/07/2019, pág. 24/126
19/110 extra paga pelo Usuário UBEC, em que a Implantação Estratégica que é subsequentemente produzida contém um valor relativamente elevado para os Critérios de Disseminação de Salto Paralelo e um valor relativamente baixo para os Critérios de Redução de Salto Paralelo por meio dos quais as Vias de Salto Paralelo são iniciadas, que levam à latência inferior, perda de pacote menor, confiabilidade mais elevada, em que as Implantações Estratégicas são acondicionadas em Pacotes de Variáveis de Trilho (TVS) de um CCR ou CCF, em que o Rastreamento de Desempenho de Estratégia (SPT) é uma base de dados do Appchain que rastreia o desempenho percebido de Estratégias Implantadas na Rede, o que possibilita à OSSA selecionar uma que seja considerada a Estratégia Preferida Atual considerando as condições de Rede de proximidade local.
30. SISTEMA, de acordo com a reivindicação 28, caracterizado pelo Rastreamento de Desempenho de Estratégia (SPT) operar como um Appchain pesado de Segmento de Dados, SPT armazenar unidades de Estratégias, em que cada Estratégia possui uma Composição de Critérios Estratégicos base, que atua como a identidade principal da Estratégia, em que todas as demais variações dentro da unidade de Estratégia atuam como medições logísticas do desempenho e tempo para possibilitar à OSSA escolher o que considera ser a Estratégia Preferida Atual, em que cada unidade de Estratégia possui uma Marcação de tempo de Validade, que se estende toda vez que uma atualização à Estratégia é provida pela Interpretação de Desempenho de Estratégia (SPI), onde associada a cada Estratégia são Unidades de Rastreamento de Desempenho múltiplas, que são relatadas pelo SPI, em que uma Unidade de Rastreamento contém um Composição de NSS e um índice de Desempenho, em que a
Petição 870190069340, de 22/07/2019, pág. 25/126
20/110
Composição de NSS captura as Variáveis de NSS que existiam no momento em que esta Unidade de Rastreamento foi capturada, em que o índice de Desempenho registra medições de desempenho que incluem saltos por segundo, megabytes.
31. SISTEMA, de acordo com a reivindicação 28, caracterizado pelo Rastreamento de Desempenho de Estratégia (SPT) se conectar indiretamente ao Algoritmo de Seleção de Variável Múltiplo (MVSA), em que o MVSA seleciona a Estratégia mais apropriada a partir dos dados no SPT, em que os Dados do SPT são usados para derivar um índice de Desempenho de Estratégia que é uma média de composite de todos os índices de desempenho individuais listados em uma única Estratégia, em que a Classificação de Confiança de Estratégia indica quanto de precedência/evidência está disponível para justificar a percepção no índice de Desempenho de Estratégia, em que o MVSA faz referência à Política Codificada Estática (SHP) para discernir os critérios pelos quais seleciona a Estratégia apropriada, em que todas as Estratégias que não expiraram do SPT são recuperadas, em que todas as composições de NSS de Todas as Estratégias Ativas que estão dentro da faixa da Composição NSS Local são recuperadas, pela qual produz Composições de NSS Dentro da Faixa, que contém Unidades de Rastreamento de Desempenho selecionadas de diversas Estratégias, em que as Unidades de Rastreamento de Desempenho são organizadas de acordo com a Composição de Critérios Estratégicos, em que os Conteúdos de Estratégia contêm Estratégias selecionadas que contêm as Unidades de Rastreamento de Desempenho que foram inicialmente selecionadas, em que os Conteúdos de Estratégia são mencionados para calcular o índice de Desempenho médio por Estratégia, que
Petição 870190069340, de 22/07/2019, pág. 26/126
21/110 produz como índice de Desempenho de Estratégia pelo qual a Classificação de Confiança de Estratégia é calculada por Estratégia, em que a estratégia preferida é selecionada de acordo com a Confiança de Desempenho e Avaliação via MVSA.
32. SISTEMA, de acordo com a reivindicação 28, caracterizado pelo Módulo de Criação de Estratégia (SCM) ser invocado pela Adaptação Estratégica Dinâmica (DSA), em que o SCM varia de forma inteligente as composições de Estratégias por meio do Módulo de Criatividade para criar Estratégias de baixo risco experimental que se criam das forças de iterações anteriores, em que a Interpretação de Desordem de Campo (FCI) envia sua saída de Interpretação de Desordem para a Criatividade como uma Forma de Entrada, em que os Critérios Estáticos da Criatividade são baseados nos Limites de Escopo de Estratégia Acordados e na quantidade de Unidade de Watt que foi pré-autorizada no Código de Autorização Econômica (EAT), em que a Estratégia Preferida Atual é recebida pelo OSSA e é desfeita para recuperar a Composição de Critérios Estratégicos.
33. SISTEMA, de acordo com a reivindicação 32, sendo os Critérios que compõem a Composição de Critérios Estratégicos caracterizados por compreender:
a) Validade de Testemunho de Salto, que indicam quanto tempo deve ter transcorrido para uma Entrada de Testemunho de Salto no Histórico de Salto Recente (RHH) ser ignorada, por meio da qual removendo Vias de Salto Paralelo potencialmente úteis de ser geradas;
b) Critérios de Disseminação de Salto Paralelo, que indicam quão amplo os Saltos Paralelos devem ser disseminados e a quais valores variáveis de desencadeamento;
Petição 870190069340, de 22/07/2019, pág. 27/126
22/110
c) Critérios de Redução de Salto Paralelo, que indicam quando as Vias de Salto Paralelo devem ser removidas devido à redundância;
d) Saturação de Conteúdo Exigida para Cache, que é a quantidade mínima de ocorrências na qual uma Appchain foi recentemente testemunhada por este nó no Histórico de Salto Recente (RHH);
e) Percurso de Salto Mínimo Exigido para Cache, que é a quantidade mínima de progresso que precisa ser concluída para o nó memorizar o conteúdo por meio do qual apenas os Nós que participam da jornada após o ponto de passagem serão elegíveis para memorizar o conteúdo;
f) Ponto de Salto de Declaração de Demanda, que é o ponto de salto ao longo da jornada de CCR ou CCF na qual o Nó declara à Metachain a Demanda da Appchain e a Demanda do Setor, em que a Demanda da Appchain é rastreada para decidir a memorização e localizações da Appchain, enquanto a Demanda de Setor é rastreada para calcular os diferentes preços de diferentes Setores;
g) Segurança Mínima do Nó para a Implementação de Via, que é o nível de segurança mínima de um Nó conforme ajustado pelas variáveis de NSS para um nó ser incluído em uma Via de Salto;
h) Critérios de Extração Autoimpostos, que é a quantidade mínima de recursos informáticos relativos exigidos para explorar uma Appchain, em que a quantidade é proporcional à carga de recurso de extração daquela Appchain;
i) Critérios de Prevenção de Ambiente Desordenado, que define as características de nós que indicam que eles são
Petição 870190069340, de 22/07/2019, pág. 28/126
23/110 esporádicos e inseguros, conforme compreendido pelas variáveis providas por NSS;
j) CCFs para Reter no Cache de Conflito, que define a quantidade percentual do armazenamento local do Nó que deve ser alocada para reter CCFs que não existem no Cache de Conteúdo de Nó Primário (PNCC);
k) Segurança de Via/Equilíbrio de Distância, que definem a zona percebida de eficiência em relação ao equilíbrio de seleção entre a segurança dos Nós selecionados e a distância esperada percorrida;
l) Gatilho de Microchain de ITII, que define o valor do índice de Isolamento de Transferência de Informações (ITII) exigido para merecer uma votação do nó para mudar uma Appchain para um formato de Microchain;
m) Múltiplo de Arredondamento de Consenso de Tráfego, que é o múltiplo do qual as variáveis de NVCI e de desempenho são arredondadas para cima ou para baixo, em que se este valor aumenta, o tamanho relativo dos Setores que são influenciados por esta variável aumentará gradualmente de tamanho e caso este valor diminua, os Setores encolherão de tamanho e conta do Nó;
n) Intervalo de Agrupamento de Variável de NSS, que define a frequência que os Nós devem se declarar dentro dos Setores que compartilham uma sobreposição com as variáveis de NSS que percebem;
o) Multiplicador de Pagamento por Trabalho, que define a intensidade de discrepância no pagamento entre o pagamento mais baixo e mais elevado dos Setores;
Petição 870190069340, de 22/07/2019, pág. 29/126
24/110
p) Tempo Mínimo de Retenção de Cache, que define o periodo de tempo mínimo que se exige que um Nó de Memorização retenha um cache que escolheu adotar;
q) Exploração para Proporção de Pagamento de Memorização, que aloca uma divisão de pagamento entre o Trabalho Passivo realizado por meio do Algoritmo de Seleção de Exploração (MSA) e o Trabalho Passivo realizado por meio do Algoritmo de Seleção de Cache (CSA);
r) Limiar de Exclusão de Parte do Cache, que define quando é seguro para os Exploradores em um Setor que está recuperando dados por meio do Processamento de Refúgio de Dados (DRP) excluir tais Dados em Perigo;
s) Magnitude da Taxa do Setor, que atua como um multiplicador para o tamanho do valor da Unidade de Consequência de Taxa que deve ser imposta sobre o Nó do Setor relevante.
34. SISTEMA, de acordo com a reivindicação 32, caracterizado pelo processamento de SCM de sua entrada e saída modular começar com a Estratégia Preferida Atual como a entrada inicial, em que a Estratégia é extraída em um formato intermediário para disponibilizá-la para manipulação e processamento pelo SCM de módulo original, por meio do qual a Composição de Critérios Estratégicos é gerada a partir da entrada de Estratégia Preferida Atual, em que a lógica atualiza a Composição de Critérios Estratégicos a uma nova versão de experimentação de baixo risco da Estratégia que termina iniciando a saída de Implantação de Estratégia, em que na conclusão do processo de atualização, o módulo de Montagem de Sintaxe Estratégica (SSA) reacondiciona as informações no
Petição 870190069340, de 22/07/2019, pág. 30/126
25/110 formato que seja incompreensível para os demais módulos que operam o Protocolo BCHAIN.
35. SISTEMA, de acordo com a reivindicação 32, caracterizado pelo Módulo de Criatividade ser usado para atualizar a Composição de Critérios Estratégicos considerando as variáveis de NSS que refletem o estado do ambiente da Rede BCHAIN local, em que a Criatividade é dada ao Modo dos critérios atualmente selecionados a partir da Criação de Estratégia, que é o Modelo Pré-definido para gerenciar a criação e variação de estratégia dinâmica, em que a Criatividade processa duas entradas; Forma A e Forma B, em que cada único Critério da Composição de Critérios Estratégicos é selecionado para processos individuais como Forma A com Criatividade, em que a Forma B é a interpretação geral da Desordem de Campo a partir da Interpretação de Desordem de Campo (FCI), em que, na conclusão da Criatividade que processa a Saida, a Forma AB é produzida como as novas variações propostas dos Critérios.
36. SISTEMA, de acordo com a reivindicação 12, caracterizado pelo Usuário UBEC acessar a Plataforma UBEC por meio de reconhecimento biométrico realizado na Interação de Nó do Usuário (UNI), por meio da qual uma Sessão de Usuário Autenticado é produzida da qual a Lista de Nós Associado é extraída, em que a Sessão de Usuário Autenticado também é usada para acessar a Interface de Usuário Front-End que leva a uma Seleção de Personalidade Econômica, em que o Usuário UBEC seleciona uma Personalidade Econômica que é mencionada pela Computação e Disponibilidade de Recurso de Rede do Protocolo BCHAIN, em que CNRA menciona a Seleção de Personalidade Econômica da Plataforma UBEC como uma metodologia de medição
Petição 870190069340, de 22/07/2019, pág. 31/126
26/110 que quaisquer recurso disponível de superávit de um Nó que está associado ao Usuário UBEC por meio da Lista de Nós Associados, em que CNRA faz referência ao módulo de Seleção de Incentivo Econômico (EIS) , em que o EIS recomenda ao Nó realizar Outro Trabalho de Nó ou uma sessão de trabalho de Envio de Registro Diagnóstico (DLS), em que a execução local do EIS em um Nó estimula aquele Nó a se tornar um Nó Diagnóstico autoimposto por meio da execução de DLS, em que o Nó se declara um Nó Diagnóstico para Localização de Nó Diagnóstico da Metachain, em que, devido à condição inicialmente declarada do Nó a partir da execução do Estágio, o Nó é marcado como não confirmado até outros Nós poderem corroborar que ele está realizado a função declarada, em que as atualizações feitas à Localização de Nó Diagnóstico da Metachain são enviadas ao Módulo de Interface de cadeia personalizada (CIM) para serem exploradas e empenhadas na Metachain atual.
37. SISTEMA, de acordo com a reivindicação 36, caracterizado por, devido à declaração do Nó na Metachain quanto a ser um Nó Diagnóstico, outros Nós de dentro do mesmo Setor enviam seus Registros Diagnósticos via Envio de CCF Jurisdicionalmente Implicado (JICS) e Recepção de CCF Jurisdicionalmente Aceita (JACR), em que os Registros Diagnósticos são validados quanto à autenticidade pelo Nó diagnóstico autodeclarado, em que as Unidades de Registro que são marcadas com um Código de Sistema Oficial são enviadas para o Desenvolvimento Indireto de SPSI (SID), em que o Código de Sistema Oficial é prova criptográfica de que a Unidade de Registro se origina de uma Appchain Oficial, em que as Appchains são marcadas como Oficiais caso contribuam com a funcionalidade principal para a Plataforma UBEC.
Petição 870190069340, de 22/07/2019, pág. 32/126
27/110
38. SISTEMA, de acordo com a reivindicação 36, caracterizado por outros Nós da BCHAIN no mesmo Setor processarem o modulo de Coleção de Registro Diagnóstico (DLC) para registrar os Registros relevantes de registro que são pretendidos para ser enviados aos locais relevantes via Envio de Registro Diagnóstico (DLS), em que os Registros do DLC são encaminhados para o JICS, que envia um CCF sem CCR de acompanhamento a um caso de JACR que invocou DLS no Nó Diagnóstico autodeclarado, em que devido à declaração do Nó de ser um Nó Diagnóstico no Local de Nó Diagnóstico da Metachain, deve aceitar os pacotes de CCF enviados pelo JICS devido à jurisdição elegida, em que LIZARD monitora e justifica os pacotes de CCF sem um CCR de acompanhamento por meio do qual a tecnologia de rastreamento de jurisdição do LIZARD é implementada nas camadas mais inferiores do tráfego de Rede BCHAIN.
39. SISTEMA, de acordo com a reivindicação 38, caracterizado por na Seleção de Incentivo Econômico (EIS) e Processamento de Reivindicação de Pagamento por Trabalho (WPCP), EIS agir como um mecanismo de mediação de fornecimento/demanda para a Rede BCHAIN, em que os Nós que procuram o Trabalho de Nó Ativo invoca EIS para selecionar o melhor tipo de trabalho disponível que seja mais provável de render àquele Nó o melhor retorno de investimento, em que as variáveis locais e remotas em relação à Metachain são analisadas para compreender as tendências de demanda de fornecimento atuais, em que o módulo de Mediação de Demanda Fornecimento (SDA) é invocado, em que as referências SDA à Metachain para criar uma representação lógica de vetores de fornecimento/demanda na Rede BCHAIN, em que SDA envia a
Petição 870190069340, de 22/07/2019, pág. 33/126
28/110
Composição de Demanda de Fornecimento para representar os achados de seus cálculos, em que a disponibilidade de recurso é verificada ao invocar a Disponibilidade de Recurso de Computação e Rede (CNRA), em que a designação de Personalidade Econômica é projetada de dentro da Interface da Plataforma UBEC (UPI), em que caso os recursos não estejam disponíveis, a operação de EIS seja terminada, em que caso os recursos estejam disponíveis, EIS invoca a Seleção de Trabalho do Nó (NJS) que faz referência à Composição de Demanda de Fornecimento e a disponibilidade de recursos do Nó ao selecionar o trabalho apropriadamente rentável.
40. SISTEMA, de acordo com a reivindicação 39, caracterizado por na transação entre a Seleção de Incentivo Econômico (EIS) e Processamento de Reivindicação de Pagamento por Trabalho (WPCP), assim que o trabalho Ativo ou Passivo é concluído, uma reivindicação para receita é feita ao WPCP, que verifica e processa o pagamento para a Economia de Watt da Metachain, em que o Trabalho do Nó Passivo é trabalho implicado pelo Protocolo BCHAIN devido às necessidades da Rede, em que o Trabalho de Nó Ativo é realizado fora de motivos egoístas do Nó em nome de seu proprietário, o Usuário UBEC, enquanto, em conformidade com a Personalidade Econômica selecionada, em que EIS apenas invoca o Trabalho do Nó Ativo por meio da Seleção de Trabalho do Nó, enquanto o Trabalho do Nó Passivo é implicado devido à aderência ao Protocolo, em que se WPCP for invocado pela conclusão de um Nó de Trabalho Passivo ou Ativo; então, o Pagamento de Trabalho Validado é enviado para Pagamentos de Trabalho Validado Ainda Pendente da Metachain, em que se WPCP for invocado por um Anúncio de Novo Bloco Solucionado, os Pagamentos Pendentes são enviados à Economia
Petição 870190069340, de 22/07/2019, pág. 34/126
29/110 de Watt, em que na invocação modular de WPCP via Anúncio de Novo Bloco de Trabalho Solucionado, os Pagamentos de Trabalho Validado Ainda Pendente são recuperados da Appchain associada ao bloco recém-solucionado por meio do qual os Pagamentos Pendentes são produzidos como saída.
41. SISTEMA, de acordo com a reivindicação 1, caracterizado por, em um processador UBMA, dois reguladores de tensão controlarem a entrada de tensão que leva a duas subseções separadas do Processador UBMA, em que duas tensões separadas podem ser ajustadas em paralelo, o que leva à priorização dinâmica de recursos de acordo com os sinais recebidos do Protocolo BCHAIN, em que para os Nós de BCHAIN poderem se comunicar via Rádio, há diversas frequências de encontro em que cada Nó ocasionalmente transmite sua Identidade, Anúncio de Hash e Frequência Pessoal, em que, em seguida, para dois Nós estabelecerem um canal de comunicação de ponto a ponto, eles podem encontrar em cada Frequência Pessoal do outro e trocar informações, em que o Wireless opera em diferentes frequências para evitar colisão e interferência e são diversificados por comunicação de faixa curta, média e longa, em que o Protocolo BCHAIN prioriza as informações que devem ser transferidas em situações de escassez, em que o Gerenciamento de Entrada/Saída reconhece os Segmentos de Execução e Instruções de Processamento Geral e, portanto, os designa ao Microchip correto e retorna os dados para o restante do Nó.
42. SISTEMA, de acordo com a reivindicação 41, caracterizado por, na estrutura da Subseção A, o Microchip de Logística de Appchain ser capaz de processar retenção e execução de Appchains e Microchains na Rede BCHAIN, em que
Petição 870190069340, de 22/07/2019, pág. 35/126
30/110
LIZARD como um microchip não confia em uma base de dados para operação e, ao contrário, avalia e estima as medidas de risco e aderência no momento devido à sua complexa inteligência pressuposta (sem referência anterior), em que o Processador UBMA é capaz de alterar sua própria montagem de microprocessador dinamicamente por meio de estruturas condutoras dinâmicas, em que o Microchip Lógico de Roteamento aumenta a eficiência de energia e reduz a latência para Lógica de Roteamento (RL) , em que o mais repetidamente usado dos submódulos de LOM, inclusive Construção de Afirmação (AC) e Mapeamento Hierárquico (HM), são otimizados na Lógica de Núcleo LOM como um Microchip, por meio do qual toda Manifestação Modular de Fluxo de Execução de LOM é tornada eficiente para executarem que o Módulo de Criatividade como um Microchip otimiza a execução do Módulo de Criatividade dentro da Plataforma UBEC, que aumenta a eficiência computacional entre a Plataforma UBEC e a Rede BCHAIN devido a muitas Appchains que dependem da Criatividade, inclusive I2GE, CTMP, MPG, SPSI.
43. SISTEMA, de acordo com a reivindicação 42, caracterizado por, na Subseção B do Processador UBMA, a Unidade de Processamento Criptográfico (CGPU) exercer as funções que operam dentro do Núcleo Criptográfico (CC), que são invocadas durante todo o Protocolo BCHAIN, em que a Unidade de Certificado de Hardware Seguro (SHCG) retém de forma segura a Chave Privada Exclusiva Sensível de Segurança que é usada para manipular os fundos do Nó na Economia de Watt da Metachain, por meio da qual um Endereço Público Gerado de Nó pode ser eficaz e rapidamente gerado por SHCG sem responsabilidade e risco da Chave Privada Exclusiva Sensível de Segurança ficar exposta, em que pela acoplagem forçosamente das Unidades de
Petição 870190069340, de 22/07/2019, pág. 36/126
31/110
Watt na Economia de Watt com o Hardware físico de um Nó por meio do Processador UBMA, o gerenciamento e manipulação das Unidades de Watt se tornam mais previsíveis e seguros na Plataforma UBEC e Rede BCHAIN, em que o Microchip de SHCGU contém uma série de Identificação Exclusiva de Nó codificada que foi aleatoriamente gerada no momento da fabricação do Processador UBMA.
44. SISTEMA, de acordo com a reivindicação 43, caracterizado por, no SHCGU, a Associação de Identidade Permanente com o Hardware (PIAH) produzir a Identificação Exclusiva de Nó que foi definida no momento da fabricação, em que com a Chave Privada Bloqueada de Hardware (HLPK), a Chave Privada Exclusiva Sensível de Segurança é permanentemente observada atrás de uma Camada de Bloqueio de Hardware, em que a única exceção de uma cópia da Chave Privada deixar intencionalmente a Camada de Bloqueio de Hardware é por meio do Canal Indireto Exclusivo para envio para LUIGI, em que a Geração de Endereço Público (PAG) é a Subseção que gera um Endereço Público que é derivado da Chave Privada sem transferência de qualquer caso da Chave Privada fora da Camada de Bloqueio de Hardware.
45. SISTEMA, de acordo com a reivindicação 1, caracterizado por, no Mecanismo de Recuperação de Fundo (FRM), o Usuário UBEC se autenticar por meio da Interação de Nó de Usuário (UNI), que produz uma Sessão de Usuário Autenticado, em que o início do processo para recuperar fundos perdidos é invocado pelo Usuário UBEC por meio do Front-End de UBEC, em que a Lista de Nós Associados é aberta a partir da Sessão de Usuário Autenticado, em que uma Sessão de Verificação de Recuperação de Fundos é iniciada com o Usuário UBEC por meio
Petição 870190069340, de 22/07/2019, pág. 37/126
32/110 do Front-End UBEC, em que o módulo de Verificação de Recuperação de Fundos (FRV) gerencia a Sessão de Verificação de Recuperação de Fundos.
46. SISTEMA, de acordo com a reivindicação 45, caracterizado por, na interação entre o Mecanismo de Recuperação de Fundos (FRM) e LUIGI, em que FRM é um submódulo que pertence à jurisdição de LUIGI, em que a Chave de Decodificação de Retenção é acessada a partir do Enclave de Segurança de LUIGI (LSE) , em que a Chave de Decodificação de Retenção é usada para decodificar e acessar a Chave Privada Exclusiva Sensível de Segurança que é usada para manipular os fundos a partir da Economia de Watt da Metachain por meio do Mecanismo de Manipulação de Fundos (FMM) , por meio do qual LUIGI acessa toda a Economia UBEC/BCHAIN armazenada na Economia Watt devido às suas cópias duplicadas das Chaves Privadas na Retenção Criptografada de Chaves Privadas.
47. SISTEMA, de acordo com a reivindicação 8, caracterizado por LUIGI ser programado uma vez e a primeira vez diretamente por humanos e, assim que a Plataforma UBEC e a Rede BCHAIN estão ao vivo e operacionais pela primeira vez, todo o acesso criptográfico para modificar a base de código do LUIGI é retido exclusivamente pela Autoinovação de Autoprogramação (SPSI), em que SPSI é uma Appchain que usa tecnologia LIZARD para programar outras Appchains dentro da Plataforma UBEC, em que a programação por SPSI inclui aprimoramento, conserto de bug/erro, manutenção agendada, análise de Unidade de Registro Diagnóstico, nova inovação de recurso, em que SPSI é capaz de se programar, ainda recebe elementos de Orientação para Programação do Desenvolvimento Indireto de SPSI (SID).
Petição 870190069340, de 22/07/2019, pág. 38/126
33/110
48. SISTEMA, de acordo com a reivindicação 47, caracterizado por SPSI conceder, de acordo com o Protocolo BCHAIN permanente, acesso exclusivo para manipular a base de código de todas as principais funções da Plataforma UBEC, inclusive Aplicativo UBEC, LUIGI, Criatividade, I2GE, SPSI, LOM, LIZARD, CTMP, MPG, MC e I2CM, em que LOM recebe as Unidades de Registro Diagnóstico do Mecanismo de Pesquisa Automatizada (ARM), em que LOM caracteriza e compreende defeitos de rotina com os Recursos Atualmente Existentes e propõe Soluções para as Unidades de Registro recebidas, em que os Recursos Atualmente Existentes são recursos da Appchain selecionada que foi direcionada para programação/aprimoramento/inovação, em que as Soluções Propostas são saída para Defeitos de Recurso Existente, em que LOM inspeciona a Appchain selecionada e estima os novos recursos propostos que espera-se que potencializarão a capacidade e eficiência da Appchain no desempenho de sua função primária, em que os Recursos Propostos e Soluções Propostas são definidos em propósito, e são transferidos para LIZARD para serem programados nos códigos funcionais por meio dos Módulos de Propósito e Sintaxe.
49. SISTEMA, de acordo com a reivindicação 48, caracterizado por LIZARD produzir Conjuntos de Código Executáveis que representam as idéias originalmente concebidas por LOM, em que os Conjuntos de Código Executáveis são transferidos para I2GE junto aos Cenários de Execução bem sucedida e Falha de Execução do LIZARD, I2GE evolui e se ajusta por meio da Criatividade do software sobre múltiplas vias evolucionárias ao usar o CPU e armazenar recursos disponibilizados pela Rede BCHAIN, em que ao fazer referência aos Cenários de Execução bem sucedida e Falha de Execução I2GE
Petição 870190069340, de 22/07/2019, pág. 39/126
34/110 é capaz de distinguir variações dos Conjuntos de Código que são por fim estáveis e funcionais com aqueles que não são, em que LOM verifica que o software resultante está em conformidade
com sua percepção de estabilidade e meio de atingir funcionalidade 50 . SISTEMA, de acordo com a reivindicação 8, caracterizado pelo Avanço Recursive de Inteligência de
Progresso (SRIA) ser algoritmo de Inteligência Artificial que é principalmente manifestado na operação de Autoinovação de Autoprogramação (SPSI), SRIA estar relacionado a LIZARD, I2GE e SPSI, em que LIZARD melhora o Código Fonte de um algoritmo pelo entendimento do Propósito do Código, em que I2GE simula gerações de iterações de programa virtual, selecionando, portanto, a versão mais forte do programa, em que BCHAIN é uma Rede vasta de Nós conectados de forma desordenada que podem executar as Appchains de forma descentralizada, em que SPSI mantém as mesmas Appchains que concedem sua funcionalidade e capacidades, em que o layout do sistema baseado no ciclo de resposta garante que o progresso incrementai gradual na Inteligência Artificial cognitiva e capacidades de solução de problema aumente, em que a Imitação Virtual ocorre quando I2GE executa o código da Appchain Alvo em um ambiente virtual que é hospedado pela Rede BCHAIN, em que a BCHAIN atua como um Provedor de Recurso para Hospedagem para I2GE, LIZARD, LOM, CTMP, NC e I2CM.
51. SISTEMA, de acordo com a reivindicação 50, caracterizado pelo Status Quo representar genericamente a funcionalidade, eficiência e desenho gerais de um sistema alvo, em que LOM é invocado pela Rápida Invocação de Principio de Desenho (DPIP) para produzir Princípios de Desenho do Sistema,
Petição 870190069340, de 22/07/2019, pág. 40/126
35/110 em que o refinamento dos Princípios de Desenho é habilitado por LIZARD, que converte os dados relevantes no formato de propósito que atua como o estágio intermediário crucial para realização de forma precisa das modificações do sistema, em que LIZARD usa suas capacidades de programação para realizar modificações experimentais ao Status Quo Refinado, em que o novo Status Quo é virtualizado e desenvolvido por I2GE, por meio do qual o ciclo de inteligência redefine o potencial de o novo ciclo se tornar disponível aumenta conforme os Algoritmos de Appchain relevantes descobrem novas informações, funcionalidades e técnicas.
52. SISTEMA, de acordo com a reivindicação 50, caracterizado por, em relação ao Agrupamento de Inteligência, CTMP atuar como a localização central de retenção de inteligência, uma vez que usurpa gradualmente a inteligência de algoritmos, em que CTMP interpreta todas as decisões baseadas de forma artificial feitas pelos Algoritmos da Appchain, inclusive LIZARD, LOM e I2GE, e recebe seus registros de processamento bruto que atua como os Fatos Objetivos em relação à decisão tomada, por meio da qual a inteligência agregada de diversos Algoritmos da Appchain é reciclada por CTMP e qualquer inteligência coletada/agrupada eventualmente se beneficia de todos os Algoritmos da Appchain que interagem com CTMP.
53. SISTEMA, de acordo com a reivindicação 50, caracterizado por, em relação à resposta e influência de Hardware, Estrutura e Funcionalidade, um desenho de sistema ideal ser produzido no Gerador de Sistema Alvo Abstrato (ATSG), em que a Funcionalidade de Usuário Exigida está relacionada a e informa a definição de Nova Funcionalidade de Usuário, em
Petição 870190069340, de 22/07/2019, pág. 41/126
36/110 que a Sintaxe de Funcionalidade é herdada pela Funcionalidade do Aplicativo, que, por sua vez, torna-se uma camada de Capacitação de Operação para a Funcionalidade de Novo Usuário, em que a potencialização de Funcionalidade de Aplicativo é manifestada no submódulo Novo Desenvolvimento de Appchain (NAD) do SPSI, em que a prática principal de tensão de camada logística é a potencialização da Eficiência, Qualidade, Segurança e Estabilidade do Código e o Processo é assumido por SPSI por meio de seus submódulos de Enrijecimento de Segurança da Appchain (ASH), Correção de Erro Inato (IEC), Refinamento de Appchain Automatizado (A2R), Manutenção de Appchain Automatizada (A2M), Conformidade Regulatória da Appchain (ARC) e Análise da Unidade de Registro Diagnóstico (DLUA), em que a Qualidade de Código Potencializada possibilita a Operação de Funcionalidade de Aplicativo, que, por sua vez, possibilita Funcionalidade de Novo Usuário, em que os ditos aspectos do software são habilitados pela Adaptação de estrutura, em que a Adaptação representa as alterações realizadas à Estrutura de base, que permite aos Aplicativos do Espaço do Usuário operar, em que a Adaptação da estrutura é praticamente realizada pelo Desenvolvimento de estrutura potencializada (EFD) do SPSI, por meio da qual as Alterações de Hardware são realizadas de acordo com a sintaxe de Estrutura que é herdada, que, por sua vez, possibilita a Estrutura e seu Espaço de Usuário operar.
54. SISTEMA, de acordo com a reivindicação 50, caracterizado por, em relação ao escape de inteligência da interação do Usuário UBEC entre ciclos multi-hierárquicos, o Ciclo de Longo Prazo representa Princípios de Orientação de larga escala de Direção de SPSI por meio do qual as capacidades, metodologias e tendências de SPSI são
Petição 870190069340, de 22/07/2019, pág. 42/126
37/110 gradualmente informadas lenta e básica em longo termo por meio da interação humana de LOM e Desenvolvimento Indireto de SPSI (SID) , em que LOM atua como um diretor racional da funcionalidade de SPSI e composição de operação devido à sua justificativa objetiva que é habilitada pela invocação modular embutida de CTMP, em que as alterações que ocorrem por meio de LOM e SID no Ciclo de Longo Prazo eventualmente afetam e informam o Ciclo de Médio Prazo, que representa a operação prática sustentada de SPSI, em que os submódulos de SPSI são afetados gradualmente pelos Princípios de Orientação da Direção de SPSI, em que a operação de SPSI dentro do Ciclo de Médio Prazo leva à potencialização geral das Appchains que existem na Plataforma UBEC/Rede BCHAIN, bem como Appchains/Programas de Legado que operam nos Sistemas de Legado por meio da Camada de Imitação de Appchain (AEL) , em que os ciclos de adaptação de curto prazo de inteligência são potencializados por SPSI, o que permite que estratégias de adaptação sofisticadas sejam implantadas em curto prazo.
55. SISTEMA, de acordo com a reivindicação 8, caracterizado por, na Autoinovação de Autoprogramação (SPSI), o Refinamento de Appchain Automatizado (A2R) inspecionar as Appchains ou Programas de Legado, em que a Manutenção de Appchain Automatizada (A2M) mantém a Appchain ou Programa de Legado selecionado ao excluir os Caches Expirados, modernizando as Funções Depreciadas para Funções Usáveis, modernizando os Módulos Depreciados e Dependências com os Módulos usáveis, excluindo Pontos de Referência Expirados e realizando a Calibração de Estabilidade Econômica, em que o Enrijecimento de Segurança da Appchain (ASH) inspeciona automaticamente os pontos de intrusão e exploração em uma
Petição 870190069340, de 22/07/2019, pág. 43/126
38/110
Appchain ou Programa de Legado, em que a Conformidade Regulatória da Appchain (ARC) garante que a Appchain ou Programa de Legado selecionado esteja em conformidade com regulamentos diversos e específicos, em que a Análise de Unidade de Registro Diagnóstico (DLUA) receba as Unidades de Registro Diagnóstico (DLU) a partir de rotinas de defeito e decretem as medidas apropriadas para tentar reparar tais defeitos percebidos, em que a Correção de Erro Inato (IEC) tente reparar as falhas de procedimento fundamental que possam levar a uma rotina interrompida, em que o Desenvolvimento de Nova Appchain (NAD) encontre uso para Aplicativos em um ecossistema de Aplicativo específico que possua possível recurso de Aplicativo ausente, que beneficiaria perceptivelmente tal ecossistema, em que o Desenvolvimento de Estrutura Aprimorada (EFD) inspeciona e potencialmente melhora estruturas existentes de software tanto para a Plataforma UBEC/Rede BCHAIN quanto Sistemas de Legado, em que o Desenvolvimento de Hardware Aprimorado (EHD) modifica os sistemas físicos que contêm os Comitês Condutores Líquidos Dinâmicos (DLCB) e, portanto, pode ter sua principal estrutura de hardware otimizada e modernizada, em que o Mecanismo de Direcionamento de Appchain (ATM) processa um algoritmo de seleção inteligente que informa os demais módulos para os quais a Appchain deve selecionar seu processamento.
56. SISTEMA, de acordo com a reivindicação 55, caracterizado por LIZARD operar para converter o Fluxo de Execução da Appchain Alvo, que foi selecionado por ATM, em um Mapa de Hierarquia de Propósito, em que o Fluxo de Execução da Appchain Alvo é produzido pela Coleção do Fluxo de Execução (ESC) submetido ao Módulo de Sintaxe (SM), em que para redigir
Petição 870190069340, de 22/07/2019, pág. 44/126
39/110 o Código, ο SM recebe o Formato de Propósito Complexo do Módulo de Propósito (PM), em que para leitura do código, SM provê uma interpretação sintática do Código do computador para o PM derivar um propósito para a funcionalidade de tal código, em que a Appchain Alvo é recebida no formato de Fluxo de Execução Preenchido pela Tradução de Código, em que a Tradução de Código converte o código arbitrário (genérico) reconhecido e compreendido pelo SM para escolher a linguagem computacional, em que a Tradução de Código realiza a função inversa de tradução das linguagens computacionais conhecidas em tipos de sintaxe arbitrária, em que a saída da execução concluída da Tradução de Código é transferida como entrada para a Redução Lógica, em que a Redução Lógica reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas em conformidade com as definições de Regras e Sintaxe, em que na conclusão da execução de Redução Lógica, a execução do caso de SM correspondente é completo e a saída modular de SM é enviada para Interpretação Iterativa de PM, em que PM usa SM para derivar um propósito no Formato de Propósito Complexo a partir do código de computador, em que a Interpretação Iterativa segue através de todas as funções interconectadas para produzir uma definição de propósito interpretada ao se referir a Associações de Propósito.
57. SISTEMA, de acordo com a reivindicação 56, caracterizado pela Redução Lógica do Módulo de Sintaxe SM enviar sua saída para a Interpretação Iterativa do PM, em que a Interpretação Iterativa segue através de todas as funções interconectadas para produzir uma definição de propósito interpretado ao se referir às Associações de Propósito, em que a saída de definição de propósito existe no Formato de
Petição 870190069340, de 22/07/2019, pág. 45/126
40/110
Propósito Complexo, que é enviado como saída modular para PM, em que a saída é rotulada como Mapa de Hierarquia de Propósito que é apresentado como a versão de Formato de Propósito Complexo da Appchain Alvo.
58. SISTEMA, de acordo com a reivindicação 57, caracterizado pelos Princípios de Desenho de Código serem submetidos ao SM, que pertence à jurisdição do Núcleo Externo (OC), em que SM provê uma estrutura para leitura e escrita de código de computador, em que para escrita do código, SM recebe o Formato de Propósito Complexo do PM, em que o Formato de Propósito Complexo é então escrito no pseudocódigo, em que, posteriormente, uma função auxiliar converte o pseudocódigo em código executável real, dependendo da sintaxe computacional alvo desejada, em que para a leitura do código, SM provê uma interpretação sintática do código de computador para PM derivar um propósito para a funcionalidade de tal código, em que a Appchain Alvo é recebida no formato de Sintaxe de Princípio pela Tradução de Código, em que a Tradução do Código converte o código arbitrário reconhecido e compreendido pelo SM em qualquer linguagem computacional escolhida, em que a Tradução de Código realiza a função inversa da tradução de linguagens computacionais conhecidas em tipos de sintaxe arbitrária, em que a saída da execução concluída da Tradução do Código é transferida como entrada para a Redução Lógica, em que a Redução Lógica reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas em conformidade com as definições de Regras e Sintaxe.
59. SISTEMA, de acordo com a reivindicação 58, caracterizado pela Redução Lógica do SM enviar sua saída para a Interpretação Iterativa do PM, em que a Interpretação
Petição 870190069340, de 22/07/2019, pág. 46/126
41/110
Iterativa segue através de todas as funções interconectadas para produzir uma definição de propósito interpretado ao se referir a Associações de Propósito, em que a saída de definição de propósito existe no Formato de Propósito Complexo, que é enviado como saída modular para PM, em que a saída é rotulada como um Mapa Hierárquico de Propósito que é apresentado como a versão do Formato de Propósito Complexo dos Princípios de Desenho de Código.
60. SISTEMA, de acordo com a reivindicação 9, caracterizado pela Coleção de Propósito de Instrução existir no Formato de Propósito Complexo e ser enviado para Expansão Iterativa de PM, dentro do Núcleo Externo (OC) de LIZARD, em que a Expansão Iterativa adiciona detalhe e complexidade para desenvolver um objetivo simples em uma definição de propósito complexo específico, em que, portanto, a Associação de Propósito máxima potencial da entrada é realizada e mantida como um Formato de Propósito Complexo antes de ser submetida para Derivação Lógica do SM, em que os dados de entrada são recebidos no Formato de Propósito Complexo do PM e são transferidos para Derivação Lógica do SM, em que a Derivação Lógica deriva funções logicamente necessárias a partir de funções inicialmente mais simples, em que o resultado produzido é uma árvore de dependências de função que é criada de acordo com os dados definidos do Formato de Propósito Complexo, em que a Derivação Lógica opera de acordo com as definições de Regras e Sintaxe que são herdadas do elemento de Código Núcleo do Núcleo Interno, em que a Derivação Lógica envia sua saída para Tradução de Código, em que, portanto, o PM invoca SM para produzir a versão resultante de Sintaxe da Appchain do Mapa de
Petição 870190069340, de 22/07/2019, pág. 47/126
42/110
Propósito Modernizado de entrada por meio da Tradução de Código. 61. SISTEMA, de acordo com a reivindicação 55, caracterizado pela Correção de Erro Inato (IEC) ser um submódulo de SPSI, em que o Mecanismo de Direcionamento de
Appchain (ATM) seleciona uma Appchain Alvo específica que é então enviada como entrada modular a um caso invocado de Coleção de Fluxo de Execução (ESC), em que o Fluxo de Execução que é produzido como saída modular a partir do caso de ESC é enviado como entrada modular para um estágio de IEC, que separa o Fluxo de Execução da Appchain para produzir o Plano de Estrutura de Código, em que cada Unidade de Código Selecionado que existe no Plano de Estrutura de Código é submetido a ciclos através de um Ciclo de programação, em que LIZARD é invocado para produzir um Mapa Hierárquico de Propósito de todo o Plano de Estrutura de Código, em que ambos os Mapas Hierárquicos de Propósito são enviados como entrada modular ao módulo de Processamento de Simetria de Propósito a Propósito (P2SP), em que na conclusão do processamento de P2SP, o Resultado do Processamento de Simetria é produzido como a saída modular.
62. SISTEMA, de acordo com a reivindicação 61, caracterizado pela Unidade de Código Selecionada ser enviada para SM, em que a Unidade de Código Selecionada ser recebida no formato de Fluxo de Execução Preenchido pela Tradução de Código, em que a saída da execução concluída da Tradução de Código é transferida como entrada para a Redução Lógica, em que a Redução Lógica reduz a lógica do código para formas mais simples para produzir um mapa de funções interconectadas em conformidade com as definições de Regras e Sintaxe, em que a
Petição 870190069340, de 22/07/2019, pág. 48/126
43/110
Redução Lógica envia sua saida para a Interpretação Iterativa, em que o Plano de Estrutura de Código é enviado ao SM.
63. SISTEMA, de acordo com a reivindicação 61, caracterizado por, uma vez que a Coleção de Fluxo de Execução (ESC) tiver enviado o Fluxo de Execução como entrada modular de IEC, a Renderização do Fluxo de Execução é invocada para interpretar e criar todas as dependências relevantes das Appchains de complemento, produzindo o Fluxo de Execução Preenchido, em que o Segmento de Execução Preenchido selecionado é isolado e armazenado no Grupo de Memória da Unidade de Código (CUBP), em que CUBP é enviado ao SM.
64. SISTEMA, de acordo com a reivindicação 63, caracterizado por CUBP ser processado em um Ciclo (de cada possível Unidade de Código) , em que o Mapa Hierárquico de Propósito de todo o CUBP e Mapa Hierárquico de Propósito da Unidade de Código Selecionada serem enviados ao Processamento de Simetria de Propósito para Propósito (P2SP) por meio do qual produz o Resultado de Processamento de Simetria, em que a saída modular do caso correspondente de P2SP é o Resultado de Processamento de Simetria, cujo resultado é enviado como entrada modular para Validação de Resultado de Processamento de Simetria (SPRV), em que cada caso de Detecção de Integração de Alinhamento (AID) é separado, em que um Ciclo para cada resultado de caso de AID é invocado, em que o ciclo é realizado através de cada Propósito de Unidade de Código Desalinhado e deriva um propósito adequado por meio da invocação de Substituição de Propósito Adequado (SPR) que se adapta ao Mapa Hierárquico de Propósito do Plano de Estrutura de Código, em que LIZARD é invocado para converter as Substituições de Propósito produzidas pelo caso de SPR correspondente em
Petição 870190069340, de 22/07/2019, pág. 49/126
44/110
Segmentos de Execução, em que cada Unidade de Substituição de Sintaxe é associada ao seu lugar relevante no Plano de Estrutura de Código, em que LIZARD é invocado para converter as Substituições de Propósito em Segmentos de Execução produzindo e enviando os resultados para a Retenção de Unidade de Substituição de Sintaxe (SRUR) , em que cada Unidade de Substituição de Sintaxe é associada ao seu lugar correspondente no Plano de Estrutura de Código, em que a Busca de Plano de Unidade (UBL) é invocada, em que a UBL produz sua saída para o Processamento para Agilizar a Estrutura de Código (CSSP), que dispõe os dados de entrada em uma saída de Appchain Modernizada, em que é criada uma Via de Implantação, que contém as Unidades de Substituição de Sintaxe e instruções para qual parte da Appchain substituirão.
65. SISTEMA, de acordo com a reivindicação 61, caracterizado pela Retenção de Propósito de Unidade de Código Desalinhado (MCUPR) ser submetida como entrada modular para SPR, em que o Ciclo através de cada Propósito de Unidade de Código Desalinhado da MCUPR é iniciado, em que LOM é invocado para produzir uma Substituição de Propósito para a Unidade de Código Desalinhado Selecionada, que é coerente e compatível com o Plano de Estrutura de Código, em que a Substituição de Propósito individual no Ciclo é processada pelo LIZARD.
66. SISTEMA, de acordo com a reivindicação 61, caracterizado pelo Plano de Estrutura de Código, Unidade de Código Desalinhado e Princípios de Desenho de Conformidade serem fornecidos como entrada inicial ao Lembrete de Invocação de Substituição (RIP), em que RIP produz um Lembrete que interage com LOM para invocar a produção da Substituição de Propósito com consideração dos critérios de entrada de Plano
Petição 870190069340, de 22/07/2019, pág. 50/126
45/110 de Estrutura de Código, Unidade de Código Desalinhado e Princípios de Desenho de Conformidade, em que o Lembrete é enviado ao módulo de Justificação de Pergunta Inicial (IQR) do LOM, em que este caso de LOM é invocado automaticamente por RIP, em que o Lembrete provido é analisado via invocação de Retenção de Conhecimento Central (CKR) para decifrar os Detalhes Ausentes do Lembrete que são cruciais para concluir o entendimento virtual correto por LOM, em que os Detalhes Ausentes resultantes produzidos por IQR são enviados como entrada modular para Esclarecimento de Pesquisa (SC), em que SC colabora com a origem do Lembrete para recuperar informações complementares, em que a versão totalmente formada e refinada do Lembrete é produzida a partir de SC e enviada como entrada modular para Construção Asserção (AC) , em que AC tentar formar uma resposta coerente ao Lembrete ao mencionar CKR diretamente e também por meio do Mapeamento Hierárquico (HM)
67. SISTEMA, de acordo com a reivindicação 66, caracterizado por AC prover uma Apresentação de Resposta ao Recurso Racional (RA), em que a asserção produzida é enviada diretamente para o CTMP como uma entrada de Opinião Subjetiva e também para a Construção de Contexto (CC) que provê a entrada de Fato Objetivo para CTMP, em que CC menciona os metadados de AC e possível evidência provida por RIP para enviar fatos brutos para CTMP, em que os metadados de entrada são representados pelo arquivo de Agregação de Registro de LOM, que contém uma coleção de arquivos de registro relevantes que são produzidos a partir de funções operacionais primárias de LOM, em que após CTMP concluir sua operação, uma Decisão PósCriticada é produzida como saída modular, em que a Decisão Pré-Critiçada e a Decisão Pós-Criticada iniciais são enviadas
Petição 870190069340, de 22/07/2019, pág. 51/126
46/110 à Comparação de Decisão (DC) que determina o escopo da possível sobreposição entre as duas entradas, em que a saída unificada provida por DC pode indicar Concessão de CTMP ou uma Melhora percebida em benefício, em que as Respostas de Argumento podem ser classificadas como Resultados de Baixa Confiança ou Resultados de Alta Confiança, em que as saídas Modulares que produziram IQR, SC, AC, Mapeamento Hierárquico (HM) e Validação de Conhecimento (KV) são enviadas para a Coleção de Registro Modular de LOM (LMLC), em que LMLC combina os dados de registro de entrada em um único arquivo de leitura mencionado como Agregado de Registro de LOM.
68. SISTEMA, de acordo com a reivindicação 61, caracterizado pela Decisão Pré-Criticada ser apresentada como saída modular a partir de AC, em que a Decisão é então marcada como Opinião Subjetiva, em que a Opinião Subjetiva é enviada para os Metadados do Sistema de Entrada, que atua como a entrada modular primária para CTMP e uma representação interna do Algoritmo de Correspondência de Padrão Selecionado (SPMA), em que para este caso de configuração; o SPMA é LOM, em que os Metadados do Sistema de Entrada são enviados para processamento para Processamento de Motivo e para Produção de Percepção Bruta (RP2), em que o Processamento de Motivo compreenderá logicamente as afirmações feitas pela comparação de atributos de propriedade, em que RP2 analisar os Metadados do Sistema de Entrada do LOM para produzir uma percepção no Formato de Complexo de Percepção (PCF) que representa a percepção algorítmica de LOM, em que a Percepção produzida é enviada para o Emulador do Observador de Percepção (POE) , em que o Processamento de Motivo invoca o Processamento de Regra, em que os resultados produzidos por ambos os Ramos de pensamento
Petição 870190069340, de 22/07/2019, pág. 52/126
47/110 são transferidos para a Saída de Decisão Crítica (CDO), que avalia quaisquer elementos fundamentais de conflito ou corroboração entre os resultados.
69. SISTEMA, de acordo com a reivindicação 68, caracterizado por LOM produzir a Substituição de Propósito ao invocar AC, em que a Substituição de Propósito é enviada para RP2 que abre os dados para produzir casos de Traço de Depuração e Traço de Algoritmo nos Metadados do Sistema de Entrada que se originam do caso AC correspondente, em que o Traço de Depuração é um traço de nível de codificação que provê variáveis, funções, métodos e classes que são usados com sua entrada correspondente e saída de tipo e conteúdo variável, em que o Traço de Algoritmo é um traço de nível de software que provê dados de segurança acoplados à análise de algoritmo, em que a decisão de segurança resultante é provida com um percurso logístico de como é atingida a Decisão, em que RP2 transfere os dados em relação ao resultado de percepção produzido para o Emulador do Observador de Percepção (POE) para processamento.
70. SISTEMA, de acordo com a reivindicação 69, caracterizado pela operação de Processamento Métrico e Separação de Metadados do Sistema (SMS) leva à produção de Percepções, que representam a resposta modular de LOM da produção de Substituição de Propósito via AC, em que RP2 produz um ponto de dados em Formato Variável Comparável que é alimentado na Pesquisa de Armazenamento (SS) como critérios de pesquisa, em que SS realiza uma pesquisa de Armazenamento de Percepção (PS) para encontrar correspondências com as Percepções já existentes armazenadas em PS, em que os Resultados da execução de SS são produzidas, que levam a um Cálculo de Peso, que tenta encontrar a distribuição correta de
Petição 870190069340, de 22/07/2019, pág. 53/126
48/110
Percepções correspondentes do PS para replicar e corresponder ao Formato Variável Comparável que representa a execução do algoritmo de LOM que produziu a Substituição de Propósito.
71. SISTEMA, de acordo com a reivindicação 61, caracterizado pelo processo de Rede de Memória opera rem paralelo à execução de POE, em que a Substituição de Propósito produzida por LOM é enviada como entrada modular ao Processamento de Motivo que processa como LOM atingiu a decisão de produzir a Substituição de Propósito em resposta ao Lembrete provido por RIP, em que a conclusão do processamento de Processamento de Motivo define as regras que são compatíveis com o comportamento de execução de LOM, em que, caso quaisquer inconsistências sejam encontradas no comportamento de regra em relação ao comportamento de execução de LOM, então as regras atualmente existentes são modificadas ou novas regras são adicionadas, em que o Extensor de Escopo de Regra Crítica (CRSE) impulsiona as Percepções conhecidas a se expandirem ao escopo de 'pensamento crítico' dos conjuntos de regras, de fato potencializando os conjuntos de regras para produzir Regras Corretas que sejam enviadas como entrada modular à Separação de Formato de Sintaxe de Regra (RSFS) de dentro da jurisdição operacional da Rede de Memória, em que RSFS separa e organiza as Regras Corretas por tipo, em que a Análise de Campo Desordenado (CFP) combina e formata o Agregado de Registro de LOM em uma única unidade passível de digitalização denominada Campo Desordenado, em que o Campo Desordenado é enviado como entrada modular para Reconhecimento de Memória (MR), em que o MR também recebe as Regras Originais que são a execução resultante de RSFS, em que MR digitaliza o Campo
Petição 870190069340, de 22/07/2019, pág. 54/126
49/110
Desordenado provido por CFP para reconhecer conceitos conhecidos definidos nas Regras Originais.
72. SISTEMA, de acordo com a reivindicação 61, caracterizado por PS conter quatro subconjuntos de Percepções: Ângulos Desconhecidos Deduzidos de Percepção, Todos os Ângulos de Percepção, Ângulos Implicados de Percepção e Ângulos Aplicados de Percepção, em que os Ângulos Aplicados de Percepção são diretamente importados ao estudar o comportamento algorítmico do Algoritmo de Correspondência de Padrão Selecionado (SPMA), em que os Ângulos Implicados de Percepção são derivados dos Ângulos Aplicados de Percepção por meio da execução modular de Implicação Derivação (ID) e APDM, em que Todos os Ângulos de Percepção representam o escopo completo de Percepções conhecidas para CTMP que não foram incluídos pelos Ângulos Aplicados de Percepção e Ângulos Implicados de Percepção, em que os Ângulos Desconhecidos Deduzidos de Percepção representam o escopo de Percepções espera-se existir ainda no CTMP que ainda não descobriram, de acordo com a Densidade de Conhecimento Autocrítico (SCKD), em que ID analisa as métricas individuais de ângulos Aplicados de Percepção para derivar de forma determinística os Ângulos Implicados de Percepção, enquanto APDM varia de forma criativa as composições de Ângulos de Percepção por meio do Módulo de Criatividade para produzir uma Nova Iteração que combine os dois Pesos de entrada iniciais, em que todos os Ângulos de Percepção envolvidos com o processamento de APDM correspondem e representam à Substituição de Propósito que é produzida por AC.
73. SISTEMA, de acordo com a reivindicação 61, caracterizado pelo Recurso Racional (RA) operar dentro de LOM
Petição 870190069340, de 22/07/2019, pág. 55/126
50/110 e invocar a Construção de Contexto (CC) para processar ο Agregado de Registro de LOM para Análise de Campo Desordenado (CFP) que produz um Campo Desordenado a partir da saída modular de CC, que é mencionado pelo Reconhecimento de Memória (MR) , em que as Regras Atuais apresentam conjuntos de regras que são indicativos do estado de funcionamento atual do Algoritmo de Correspondência de Padrão Selecionado (SPMA), em que as Regras Atuais são enviadas como entrada modular para a Derivação de
Sintaxe de Regra (RSD) onde as regras 'em preto e branco' lógicas são convertidas para percepções baseadas em métricas, em que a saída de RSD é provida como entrada para a
Correspondência de Percepção (PM) , em que em PM, uma unidade de Formato Variável Comparável (CVF) é formada a partir da Percepção recebida de RSD, em que o CVF recém-formado é usado para procurar Percepções relevantes em PS, em que as correspondências potenciais são enviadas como entrada modular para a Geração de Sintaxe de Regra (RSG), em que RSG recebe as percepções anteriormente confirmadas que são armazenadas em formato de Percepção e acessam a composição métrica interna da Percepção, em que as Percepções são recebidas de OS, que contém as Percepções Anteriormente Confirmadas, em que tais medidas de métricas baseadas em gradiente são convertidas a conjuntos de regras binárias e lógicas que simulam o fluxo de informação de entrada/saída da percepção original, em que, portanto, RSG produz Regras Perceptivas que são consideradas relevantes, populares e foram convertidas em regras lógicas, em que, caso uma Percepção possua muitas relações métricas complexas que definiram muitas 'áreas cinza', as regras em 'preto e branco' locais abrangem tais áreas 'cinza' ao se expandir na complexidade de conjunto de regras, em que as Regras
Petição 870190069340, de 22/07/2019, pág. 56/126
51/110
Perceptivas são armazenadas por uma coleção de definições de Formato de Sintaxe de Regra (RSF), em que as Regras Perceptivas são enviadas como entrada para MR, onde são digitalizadas contra o Campo Desordenado, que foi produzido por CFP, em que MR produz Regras Extras que completam as Regras Corretas em sua validade.
74. SISTEMA, de acordo com a reivindicação 61, caracterizado pelos Ângulos Aplicados de Percepção de PS serem enviados como entrada para ID para produzir mais Percepções que pertencem aos Ângulos Implicados de Percepção, em que os Ângulos Aplicados de Percepção são enviados especificamente à Combinação Métrica de ID, em que a Combinação Métrica separa os Ângulos de Percepção recebidos em categorias de métricas: Escopo, Tipo, Consistência, Intensidade, em que os Ângulos de Percepção de entrada estão relacionados à Substituição de Propósito produzida por AC, em que o Conjunto de Complexidade Métrica A é enviado como entrada para a Expansão Métrica (ME), em que com a ME as métricas de Ângulos de Percepção múltiplos e variáveis são categoricamente armazenados, em que ME potencializa o lote atual de métricas recebidas com detalhes/complexidade extraídos das métricas anteriormente conhecidas/encontradas, em que na potencialização e conclusão de enriquecimento de complexidade, as métricas são devolvidas como saída de ME como Conjunto de Complexidade Métrica B e, subsequentemente, convertidas de volta a Ângulos de Percepção para serem armazenados nos Ângulos Implicados de Percepção.
75. SISTEMA, de acordo com a reivindicação 61, caracterizado pela Saída de Decisão Crítica (CDO) de CTMP recebe a saída de POE e RE, em cada Ramo envia sua respectiva Decisão Crítica, bem como os Meta-metadados correspondentes,
Petição 870190069340, de 22/07/2019, pág. 57/126
52/110 que provê variáveis contextuais que justifiquem a razão de a Decisão Crítica inicial ter sido atingida, em que tanto os Conjuntos de Decisão que representam as Percepções de POE quanto as Regras de Atendimento de RE são enviados ao Módulo de Categorização Metadados (MCM), que separa os Traços de Depuração e de Algoritmo em categorias distintas usando a categorização de informações baseada em sintaxe tradicional, em que a Lógica de Processamento Interno de Comparação de Decisão de Direção (DDC) verifica a corroboração ou conflito entre a Decisão Intuitiva e a Decisão de Pensamento, em que o Controle de Saída Terminal (TOC) se inicia com Lembrete, que verifica se DDC pode prover uma Saída de Decisão Final, em que, caso a resposta ao Lembrete seja Sim, então a decisão final combinada provida por DDC na Saída de Decisão Final é enviada como saída de TOC, em que, caso a resposta ao Lembrete seja Não, PM é executado para buscar os resultados correspondentes, em que as Regras Atendidas são extraídas da Decisão Crítica + Meta-metadados de RE, em que as Regras são convertidas em Percepções por Derivação de Sintaxe de Regra (RSD), em que PM então mencionada os Meta-metadados para determinar se há uma sobreposição interna forte e corroboração de Percepções usada.
76. SISTEMA, de acordo com a reivindicação 61, caracterizado pela Substituição de Propósito existir no Formato de Propósito Complexo e ser enviada para Expansão Iterativa de PM, em que a Expansão Iterativa adiciona detalhe e complexidade para desenvolver um objetivo simples (definido indiretamente na Substituição de Propósito) em uma definição de propósito complexo específico por meio do qual o potencial máximo de Associação de Propósito da entrada é realizado e
Petição 870190069340, de 22/07/2019, pág. 58/126
53/110 retido como um Formato de Propósito Complexo antes de ser submetido para Derivação Lógica de SM, em que o elemento do Código do Núcleo de IC contém Estruturas e Bibliotecas Fundamentais, Gerenciamento de Ameaça e roteiros de Equilíbrio de Carga, protocolos de Comunicação e Criptografia e sistema de Gerenciamento de Memória, por meio dos quais possibilita a operação geral e funcionalidade para SM e PM, em que os Objetivos do Sistema de IC definem a Política de Segurança e Objetivos da Empresa.
77. SISTEMA, de acordo com a reivindicação 61, caracterizado pela operação e funcionalidade da Pesquisa de Plano de Unidade (UBL) de IEC, entrada a partir da Retenção de Unidade de Substituição de Sintaxe (SRUR), serem recebidas, portanto, iniciadas como Ciclo que produz ciclos através de todas as Unidades de Substituição de Sintaxe, em que o ID da Unidade de Código Associado é aberto a partir da Unidade de Substituição de Sintaxe, em que em uma ameaça paralela separada no mesmo caso de UBL, o Plano de Estrutura de Código é enviado como entrada e o Plano de Estrutura de Código é instalado na Nova Retenção de Plano de Estrutura de Código (NCSBR), em que o estado de Atendido dos Segmentos de Execução é revertido por meio do Processamento para Racionalizar a Estrutura de Código (CSSP), produzindo a Appchain Modernizada como saída, que representa a estrutura sintática original, mas com as Unidades de Código Desalinhado substituídas por Substituições de Propósito Adequados, em que a Appchain Modernizada é enviada para Montagem de Remendo de Implementação (DPA) para produzir o Remendo de Correção de Appchain, em que a Appchain Alvo é processada pela Coleção de Fluxo de Execução (ESC), enviando, portanto, o Fluxo de Execução original para DPA habilitar DPA
Petição 870190069340, de 22/07/2019, pág. 59/126
54/110 para ter acesso à Appchain Alvo em sua forma original, em que o Remendo de Correção de Appchain é implantado no Criador de Ecossistema de cadeia personalizada (CEB), que manipula a Appchain Alvo de modo que a converta no conteúdo para a Appchain Modernizada.
78. SISTEMA, de acordo com a reivindicação 55, caracterizado por, em relação à operação interna de LOM e CTMP quanto ao Enrijecimento de Segurança da Appchain (ASH), a Teoria de Segurança, Informação de Segurança não Confirmada e Conhecimento de Segurança Confirmada são fornecidos como entrada inicial ao Lembrete de Invocação de Dedução (DIP) que produz um Lembrete que interage diretamente com LOM para invocar a produção da Afirmação de Segurança Confiável com consideração dos critérios de entrada Teoria de Segurança, Informação de Segurança não Confirmada e Conhecimento de Segurança Confirmada, em que o Lembrete é enviado para Justificativa de Pergunta Inicial (IQR), em que o Lembrete provido é analisado por meio da invocação de Retenção de Conhecimento Central (CKR), em que os Detalhes Ausentes resultantes produzidos por IQR são enviados como entrada para Clarificação de Pesquisa (SC) que colabora com a origem do Lembrete para recuperar informações complementares, SC colabora com DIP para recuperar informações complementares em relação ao Lembrete, em que a versão refinada do Lembrete é produzida a partir de SC e enviada como entrada para AC, que tenta formar uma resposta coerente ao Lembrete ao mencionar CKR diretamente e também por meio do Mapeamento Hierárquico (HM), em que RA usa CTMP para criticar afirmações na forma de autocrítica e crítica externa à origem da questão/afirmação processada por IQR, em que, se uma asserção produzida a partir
Petição 870190069340, de 22/07/2019, pág. 60/126
55/110 de AC falha, uma medida significativa do teste de autocrítica processada por RA, então, um novo caso de AC é invocado para representar quaisquer críticas válidas, em que, caso seja produzida uma afirmação de alta confiança por AC que passe de forma consistente nos testes de autocrítica processados por RA, então, a afirmação é produzida como saída de LOM, mencionada como a Afirmação de Segurança de Confiança no contexto do Lembrete inicial provido por DIP.
79. SISTEMA, de acordo com a reivindicação 78, caracterizado por, em relação ao procedimento de operação interna de RA quanto a ASH, AC prover uma Apresentação de Resposta a RA quanto à afirmação produzida por AC em relação ao Lembrete de entrada correspondente, a afirmação produzida ser enviada diretamente a CTMP como uma entrada de Opinião Subjetiva, e também para Construção de Contexto (CC) que provê a entrada de Fato Objetivo para CTMP, em que CC menciona os metadados de AC e possível evidência provida por meio de RIP para enviar fatos brutos a CTMP para pensamento crítico, em que estes metadados de entrada são representados pelo arquivo Agregado de Registro de LOM, em que as saídas produzidas a partir da Justificativa de Pergunta Inicial (IQR), SC, AC, HM e KV são enviadas à Coleção de Registro Modular de LOM (LMLC) que combina os dados de registro de entrada em um único arquivo de leitura mencionado como Agregado de Registro de LOM, que é enviado para CC de Recurso Racional (RA).
80. SISTEMA, de acordo com a reivindicação 79, caracterizado por, quanto à invocação de RP2 em CTMP, LOM produzir a Afirmação de Segurança Confiante ao invocar AC, em que a Afirmação de Segurança Confiante é então enviada para RP2 que abre os dados para produzir casos de Traço de Depuração
Petição 870190069340, de 22/07/2019, pág. 61/126
56/110 e Traço de Algoritmo nos Metadados do Sistema de Entrada que se originam do caso de AC correspondente, em que o Processamento Métrico reverte os mecanismos das variáveis de LOM para extrair percepções da Inteligência Artificial exibida por LOM, em que, consequentemente, os Metadados do Sistema de Entrada são separados em relações de causa e efeito de segurança significativas por meio da Separação de Metadados do Sistema (SMS).
81. SISTEMA, de acordo com a reivindicação 80, caracterizado pela Substituição de Propósito produzida por LOM e Agregado de Registro de LOM serem submetidos à Análise de dados que faz com que os Registros Potencializados de Dados sejam derivados, que são aplicados no Aplicativo pra atingir uma Dicotomia de Interpretação de um Sentimento Positivo (Aprovação) ou Sentimento Negativo (Bloqueio) em relação à Substituição de Propósito de entrada, em que a conclusão bem sucedida da execução de Aplicativo leva a uma Ação Corretiva de Comando que é processada pela Saída de Decisão Crítica (CDO) em paralelo à saída modular de Execução de Regra (RE), em que a Densidade de Conhecimento autocrítico (SCKD) estima o escopo e tipo de possível conhecimento desconhecido que está além do alcance do Agregado de Registro de LOM relatável.
82. SISTEMA, de acordo com a reivindicação 72, caracterizado por, em relação à interação de fluxo lógico entre PS e o Mecanismo de Descoberta de Percepção Automatizada (APDM), PS conter quatro subconjuntos de Percepções: Ângulos de Percepção Desconhecidos Deduzidos, Todos os Ângulos de Percepção, Ângulos Implicados de Percepção e Ângulos Aplicados de Percepção, em que os Ângulos Aplicados de Percepção são diretamente importados ao estudar o comportamento algorítmico
Petição 870190069340, de 22/07/2019, pág. 62/126
57/110 de SPMA, os Ângulos Implicados de Percepção são derivados dos Ângulos Aplicados de Percepção por meio da execução de Implicação Derivação (ID) e APDM, em que Todos os Ângulos de Percepção representam todo o escopo de Percepções conhecidas para o CTMP que não foram incluídas pelos Ângulos Aplicados de Percepção e Ângulos Implicados de Percepção, em que os Ângulos de Percepção Desconhecidos Deduzidos representam o escopo de Percepções que espera-se ainda existir no CTMP ainda a descobrir de acordo com SCKD, em que ID analisa as métricas individuais de Ângulos Aplicados de Percepção para derivar de forma determinística os Ângulos Implicados de Percepção, enquanto APDM varia criativamente as composições de Ângulos de Percepção por meio do Módulo de Criatividade para produzir uma Nova Iteração que combine os dois Pesos de entrada iniciais por meio dos quais todos os Ângulos de Percepção envolvidos com o processamento de APDM correspondem e representam a Afirmação de Segurança Confidente que é produzida por AC de LOM.
83. SISTEMA, de acordo com a reivindicação 71, caracterizado por, em relação ao Extensor de Escopo de Regra Crítica (CRSE) de CTMP, um caso de RA operar dentro de LOM e invocar a Construção de Contexto (CC) para processar o Agregado de Registro de LOM para a Análise de Campo Desordenado (CFP), que produz um Campo Desordenado a partir da saída modular de CC, que é mencionado pelo Reconhecimento de Memória (MR), em que as Regras Atuais exibem conjuntos de regras que são indicativos do estado de funcionamento atual do Algoritmo de Correspondência de Padrão Selecionado (SPMA), que neste caso é LOM, em que as Regras Atuais são enviadas como entrada modular para a Derivação de Sintaxe de Regra (RSD), que é onde
Petição 870190069340, de 22/07/2019, pág. 63/126
58/110 as regras lógicas em 'preto e branco' são convertidas para percepções baseadas em métricas, em que a saida de RSD é provida como entrada para Correspondência de Percepção (PM), em que em PM, uma unidade de Formato Variável Comparável (CVF) é formada a partir da Percepção recebida de RSD, em que o CVF recém-formado é usado para procurar Percepções relevantes no Armazenamento de Percepção (PS) com índices similares, em que as correspondências potenciais são enviadas como entrada para a Geração de Sintaxe de Regra (RSG), em que RSG recebe as percepções anteriormente confirmadas, que são armazenadas no formato de Percepção e acessam a composição métrica interna da Percepção, em que as Percepções são recebidas de OS, que contém as Percepções Anteriormente Confirmadas, por meio das quais estas medidas de métricas baseadas em gradiente são convertidas para conjuntos de regras binários e lógicos que simulam o fluxo de informações de entrada/saída da percepção original e, portanto, RSG produz Regras Perceptivas que são Percepções consideradas relevantes, populares e foram convertidas em regras lógicas, em que as Regras Perceptivas são armazenadas por uma coleção de definições de Formato de Sintaxe de Regra (RSF), em que as Regras Perceptivas são enviadas como entrada para o Reconhecimento de Memória (MR) onde são digitalizadas contra o Campo Desordenado que foi produzido por CFP, por meio do qual o MR que produz as Regras Extras que completam as Regras Corretas em sua validade.
84. SISTEMA, de acordo com a reivindicação 72, caracterizado por, em relação ao ID de CTMP, os Ângulos Aplicados de Percepção de PS serem enviados como entrada para ID para produzir mais Percepções pertencentes aos Ângulos Implicados de Percepção, em que os Ângulos Aplicados de
Petição 870190069340, de 22/07/2019, pág. 64/126
59/110
Percepção são especificamente enviados para Combinação Métrica de ID, em que a Combinação Métrica separa os Ângulos de Percepção recebidos em categorias de métricas: Escopo, Tipo, Consistência, Intensidade, em que os Ângulos de Percepção de entrada estão relacionados à Substituição de Propósito que foi produzida por AC.
85. SISTEMA, de acordo com a reivindicação 81, caracterizado por CDO receber a saída modular de ambos os ramos principais de CTMP: POE e RE, em que cada Ramo envia sua respectiva Decisão Crítica, bem como os Meta-metadados correspondentes, em que ambos os Conjuntos de Decisão são enviados para o Módulo de Categorização de Metadados (MCM), que separa os Traços de Depuração e Algoritmo em categorias distintas usando categorização de informação baseada em sintaxe tradicional.
86. SISTEMA, de acordo com a reivindicação 60, caracterizado por, em relação à operação de LIZARD para converter as Regulações e Diretrizes de Sistema em um Mapa Hierárquico de Propósito, as Regulações e Diretrizes de Sistema são enviadas do LUIGI para SM, em que as Regulações e Diretrizes de Sistema são recebidas no formato de Fluxo de Dados AO pela Tradução de Código, que converte o código arbitrário para escolher a linguagem de computação e assim realiza a função inversa de tradução das linguagens computacionais conhecidas em tipos de sintaxe arbitrária.
87. SISTEMA, de acordo com a reivindicação 86, caracterizado pelo Mapa de Propósito Modernizado existir no Formato de Propósito Complexo e ser enviado para Expansão Iterativa que adiciona detalhe e complexidade para desenvolver um simples objetivo em uma definição de propósito complexo
Petição 870190069340, de 22/07/2019, pág. 65/126
60/110 específico, em que os dados de entrada são recebidos no Formato de Propósito Complexo a partir de PM e são transferidos para a Derivação Lógica de SM, em que PM invoca SM para produzir a versão resultante de Sintaxe de Appchain do Mapa de Propósito Modernizado de entrada por meio da Tradução de Código, em que a Appchain Modernizada resultante é produzida de forma terminal pela Tradução de Código da saida modular de SM, Núcleo Externo e LIZARD.
88. SISTEMA, de acordo com a reivindicação 86, caracterizado por, em relação à operação de LIZARD converter o conteúdo total de Retenção de Registro Relacionado a Erro (ERLR) em um Mapa Hierárquico de Propósito, o conteúdo de ERLR ser enviado para SM, em que a Redução Lógica de SM envia sua saida para Interpretação Iterativa de PM, em que a Interpretação Iterativa segue todas as funções interconectadas para produzir uma definição de propósito interpretado ao se referir a Associações de Propósito, em que a saida é rotulada como um Mapa Hierárquico de Propósito que é apresentado como a versão de Formato de Propósito Complexo de ERLR.
89. SISTEMA, de acordo com a reivindicação 86, caracterizado por, em relação à operação de LIZARD converter o Registro de Erro Contextualizado em um Mapa Hierárquico de Propósito, o Registro de Erro Contextualizado ser enviado para SM, em que a Redução Lógica de SM envia sua saida para Interpretação Iterativa de PM, em que a Interpretação Iterativa segue todas as funções interconectadas para produzir uma definição de propósito interpretado ao se referir a Associações de Propósito, em que a saida é rotulada como um Mapa Hierárquico de Propósito que é apresentado como a versão de
Petição 870190069340, de 22/07/2019, pág. 66/126
61/110
Formato de Propósito Complexo do Registro de Erro Contextualizado.
90. SISTEMA, de acordo com a reivindicação 86, caracterizado por, em relação à operação de LIZARD converter o Segmento de Execução Refinada em um Mapa Hierárquico de Propósito, o Segmento de Execução Refinada ser enviada para SM, em que a Redução Lógica de SM envia sua saída para a Interpretação Iterativa de PM, em que a Interpretação Iterativa segue todas as funções interconectadas para produzir uma definição de propósito interpretado ao se referir a Associações de Propósito, em que a saída é rotulada como um Mapa Hierárquico de Propósito que é apresentado como a versão de Formato de Propósito Complexo do Segmento de Execução Refinada.
91. SISTEMA, de acordo com a reivindicação 86, caracterizado por, em relação à operação de LIZARD converter todo o Ecossistema de cadeia personalizada da Plataforma UBEC em um Mapa Hierárquico de Propósito, a Plataforma UBEC ser enviada para SM, em que a Redução Lógica de SM envia sua saída para Interpretação Iterativa de PM, em que a Interpretação Iterativa segue todas as funções interconectadas para produzir uma definição de propósito interpretado ao se referir a Associações de Propósito, em que a saída é rotulada como um Mapa Hierárquico de Propósito que é apresentado como a versão de Formato de Propósito Complexo da Plataforma UBEC.
92. SISTEMA, de acordo com a reivindicação 86, caracterizado por, em relação à operação de LIZARD converter o Mapa Hierárquico de Propósito em uma série de Bandas de Propósito, o Mapa Hierárquico de Propósito existir em Formato de Propósito Complexo e ser enviado para Expansão Iterativa de PM, em que a Expansão Iterativa adiciona detalhe e complexidade
Petição 870190069340, de 22/07/2019, pág. 67/126
62/110 para desenvolver um objetivo simples em uma definição de propósito complexo específico por meio da qual o potencial máximo de Associação de Propósito da entrada é realizado e retido como um Formato de Propósito Complexo antes de ser enviado para Derivação Lógica de SM, em que os dados de entrada são recuperados no Formato de Propósito Complexo a partir de PM e serem transferidos para Derivação Lógica de SM, em que a Derivação Lógica deriva funções logicamente necessárias a partir de funções inicialmente mais simples, em que o resultado produzido é uma árvore de dependências de função que é criada de acordo com os dados definidos do Formato de Propósito Complexo.
93. SISTEMA, de acordo com a reivindicação 86, caracterizado por, em relação à operação de LIZARD converter as Novas Alterações Propostas em um Mapa Hierárquico de Propósito, a Plataforma UBEC ser enviada para SM, em que a Redução Lógica de SM envia sua saída para a Interpretação Iterativa de PM, em que a Interpretação Iterativa segue todas as funções interconectadas para produzir uma definição de propósito interpretado ao se referir às Associações de Propósito, em que a saída é rotulada como um Mapa Hierárquico de Propósito que é apresentado como a versão de Formato de Propósito Complexo das Novas Alterações Propostas.
94. SISTEMA, de acordo com a reivindicação 86, caracterizado por, em relação à operação de LIZARD converter os Princípios de Desenho do Sistema em um Mapa Hierárquico de Propósito, os Princípios de Desenho do Sistema ser enviado para SM, em que a Redução Lógica de SM envia sua saída para Interpretação Iterativa de PM, em que a Interpretação Iterativa segue todas as funções interconectadas para produzir uma
Petição 870190069340, de 22/07/2019, pág. 68/126
63/110 definição de propósito interpretado ao se referir às Associações de Propósito, em que a saída é rotulada como um Mapa Hierárquico de Propósito que é apresentado como a versão de Formato de Propósito Complexo dos Princípios de Desenho do Sistema.
95. SISTEMA, de acordo com a reivindicação 86, caracterizado por, em relação à operação de LIZARD converter as Jurisdições da Appchain em um Mapa Hierárquico de Propósito, as Jurisdições da Appchain serem enviadas para SM, em que a Redução Lógica de SM envia sua saída para Interpretação Iterativa de PM, em que a Interpretação Iterativa segue todas as funções interconectadas para produzir uma definição de propósito interpretado ao se referir às Associações de Propósito, em que a saída é rotulada como um Mapa Hierárquico de Propósito que é apresentado como a versão do Formato de Propósito Complexo das Jurisdições da Appchain.
96. SISTEMA, de acordo com a reivindicação 86, caracterizado por, em relação à operação de LIZARD converter o Mapa de Propósito Modernizado em Novas Alterações Propostas, o Mapa de Propósito Modernizado existir no Formato de Propósito Complexo e ser enviado para Expansão Iterativa de PM, em que os dados de entrada são recebidos de PM, e ser transferido para a Derivação Lógica de SM, em que a Derivação Lógica deriva de funções logicamente necessárias a partir de funções inicialmente mais simples e o resultado produzido ser uma árvore de dependências de função que é criada de acordo com os dados definidos de Formato de Propósito Complexo, em que PM invoca SM para produzir a versão resultante de Sintaxe de Appchain do Mapa de Propósito Modernizado de entrada por meio de Tradução de Código.
Petição 870190069340, de 22/07/2019, pág. 69/126
64/110
97. SISTEMA, de acordo com a reivindicação 86, caracterizado por, em relação à operação de LIZARD converter Appchains para Criar em uma Camada Logística, em que as Appchains para Criar são enviadas para SM, em que a Redução Lógica de SM envia sua saída para a Interpretação Iterativa de PM, em que a Interpretação Iterativa segue todas as funções interconectadas para produzir uma definição de propósito interpretado ao se referir às Associações de Propósito, em que a saída é rotulada como uma Camada Logística que é apresentada como a versão do Formato de Propósito Complexo de Appchains pra Criar e codificada ainda em um formato de Camada Logística, em que a Camada Logística é uma macro disposição da sintaxe enquanto o Formato de Propósito Complexo define a micro disposição da sintaxe.
98. SISTEMA, de acordo com a reivindicação 86, caracterizado por, em relação à operação de LIZARD converter o Mapa OC3 em um Mapa de Sintaxe de Appchain, o Mapa OC3 existir no Formato de Propósito Complexo e ser enviado para Expansão Iterativa de PM, em que a Expansão Iterativa adiciona detalhe e complexidade para desenvolver um simples objetivo em uma definição propósito de complexo específico, em que os dados de entrada são recebidos no Formato de Propósito Complexo a partir de PM e são transferidos para a Derivação Lógica de SM, em que a Derivação Lógica deriva as funções logicamente necessárias a partir de funções inicialmente mais simples e o resultado produzido é uma árvore de dependências de função que é criada de acordo com os dados definidos do Formato de Propósito Complexo, em que a unidade do Mapa de Sintaxe de Appchain resultante terminalmente produzida pela Tradução de Código e a saída modular de SM, OC e LIZARD.
Petição 870190069340, de 22/07/2019, pág. 70/126
65/110
99. SISTEMA, de acordo com a reivindicação 86, caracterizado por, em relação à operação de LIZARD 120 converter a Appchain Atendida no Mapa Hierárquico de Propósito, Appchain Atendida ser enviada para SM, em que a Redução Lógica de SM envia sua saída para Interpretação Iterativa de PM, em que uma saída é rotulada como uma Camada Logística que é apresentada como a versão do Formato de Propósito Complexo de Appchain Atendida.
100. SISTEMA, de acordo com a reivindicação 24, caracterizado por, em relação à operação LOM e CTMP quanto ao Desenvolvimento de Nova Appchain (NAD), os Princípios de Desenho Criativo, Segmento de Mapa Selecionado e Mapa OC3 serem fornecidos como entrada inicial para o Lembrete de Invocação de Variação Criativa (CVIP), que produz um Lembrete que interage diretamente com LOM para invocar a produção da Afirmação de Segurança Confidente com consideração dos critérios de entrada Teoria de Segurança, Informação de Segurança não Confirmada e Conhecimento de Segurança Confirmada, em que o Lembrete é enviado para o módulo de Justificativa de Pergunta Inicial (IQR) de LOM, em que o Lembrete é analisado por meio da invocação de Retenção de Conhecimento Central (CKR), em que os Detalhes Ausentes resultantes produzidos por IQR são enviados como entrada modular para Clarificação de Pesquisa (SC) que colabora com a origem do Lembrete para recuperar informação complementar, em que SC colabora com DIP para recuperar informação complementar sobre o Lembrete, em que a versão do Lembrete a partir de SC é enviada para AC, que tenta formar uma resposta coerente para o Lembrete ao se referir a CKR diretamente e também por meio do Mapeamento Hierárquico (HM), em que AC provê uma
Petição 870190069340, de 22/07/2019, pág. 71/126
66/110
Apresentação de Resposta para RA em relação à afirmação produzida por AC, em que a afirmação produzida é classificada como uma Decisão Pré-Criticada, em que CTMP produz uma Decisão Pós-Critiçada, em que a Decisão Pré-Criticada e a Decisão PósCriticada iniciais são enviadas para a Comparação de Decisão (DC) que determina o escopo da sobreposição potencial entre duas entradas.
101. SISTEMA, de acordo com a reivindicação 100, caracterizado pelas saídas modulares produzidas a partir de IQR, SC, AC, HM e KV serem enviadas para a Coleção de Registro Modular de LOM (LMLC) que combina os dados de registro de entrada em um único arquivo de leitura mencionado como Agregado de Registro de LOM, que é enviado para CC de Recurso Racional (RA), em que a Decisão Pré-Criticada é apresentada como saída modular de AC e marcada como uma Opinião Subjetiva, em que os Metadados do Sistema de Entrada são enviados para processamento ao Processamento de Motivo e RP2, em que o Processamento de Motivo compreenderá logicamente as afirmações feitas por comparação de atributos de propriedade e análises de RP2 dos Metadados do Sistema de Entrada a partir de LOM para produzir uma percepção no Formato de Complexo de Percepção (PCF), que é enviado para POE, em que o Processamento de Motivo invoca o Processamento de Regra que eventualmente produz conjuntos de regras que refletem o algoritmo de SPMA.
102. SISTEMA, de acordo com a reivindicação 101, caracterizado por, em relação à operação de POE, a operação de Processamento Métrico e Separação de Metadados do Sistema (SMS) levarem à produção de Percepções, em que as Percepções resultantes representam resposta de LOM de produção da Substituição de Propósito via AC, em que RP2 produz um ponto
Petição 870190069340, de 22/07/2019, pág. 72/126
67/110 de dado de Formato Variável Comparável que é alimentado em SS como critérios de pesquisa, em que os Resultados da execução SS são produzidos, os quais levam a um Cálculo de Peso que tenta encontrar a distribuição correta de Percepções correspondentes de PS para replicar e corresponder ao Formato Variável Comparável que representa a execução do LOM que produziu a Unidade Potencial Criativa, em que o Cálculo de Peso completa-se para levar à Aplicação das Percepções para tornar uma decisão Aprovada ou de Bloqueio ativa, em que a Unidade Potencial Criativa produzida por LOM e Agregado de Registro de LOM correspondente se submete à Análise de Dados que faz com que os Registros Potencializados de Dados sejam derivados, os quais são aplicados no Aplicativo para atingir uma Dicotomia de Interpretação de um Sentimento Positivo (Aprovado) ou Sentimento Negativo (Bloqueio) em relação à entrada Unidade Potencial Criativa, em que na conclusão bem sucedida da execução de Aplicativo leva a uma Ação Corretiva de Comando que é processada por CDO em paralelo para a saída de RE, em que SCKD estima o escopo e tipo de conhecimento desconhecido potencial que está além do alcance do Agregado de Registro de LOM relatável.
103. SISTEMA, de acordo com a reivindicação 102, caracterizado por, em relação ao processo de Rede de Memória que opera em paralelo à execução de POE, a Unidade Potencial Criativa produzida por LOM ser enviada como entrada modular para o Processamento de Motivo que processa como o LOM atingiu a decisão de produzir a Unidade Potencial Criativa em resposta ao Lembrete provido por CVIP, em que CRSE impulsiona Percepções conhecidas a expandir o escopo de 'pensamento crítico' dos conjuntos de regras, em que as Regras Corretas são enviadas
Petição 870190069340, de 22/07/2019, pág. 73/126
68/110 para Separação de Formato de Sintaxe de Regra (RSFS) de dentro da jurisdição de operação da Rede de Memória, em que RSFS separa e organiza as Regras Corretas por tipo, em que a Análise de Campo Desordenado (CFP) combina e formata o Agregado de Registro de LOM em uma única unidade digitalizável mencionada como Campo Desordenado que é enviada para MR, em que MR recebe as Regras Originais que são o resultado de execução de RSFS e digitaliza o Campo Desordenado provido por CFP para reconhecer os conceitos conheciveis definidos nas Regras Originais que produzem os Segmentos de Regra Reconhecida, em que RFP recebe partes individuais das Regras Originais que foram marcadas de acordo com seu reconhecimento ou falta deste no Campo Desordenado por MR e RFP deduz logicamente que todo o conjunto de regra (a combinação de todas as suas partes) foi suficientemente reconhecido no Campo Desordenado para merecer o processamento por RE, em que a conclusão da execução de RE leva a uma Ação Corretiva de Comando processada por CDO em paralelo à saída de POE.
104. SISTEMA, de acordo com a reivindicação 9, caracterizado por, em relação à operação de LIZARD converter Soluções Criativas Sintáticas em um Mapa Hierárquico de Propósito, em que as Soluções Criativas Sintáticas são enviadas para SM, em que a Redução Lógica do Módulo de Sintaxe (SM) envia sua saída para a Interpretação Iterativa de PM, em que a Interpretação Iterativa segue todas as funções interconectadas para produzir uma definição de propósito interpretado ao se referir às Associações de Propósito, em que a saída é rotulada como a Camada Logística que é apresentada como a versão do Formato de Propósito Complexo das Soluções Criativas Sintáticas.
Petição 870190069340, de 22/07/2019, pág. 74/126
69/110
105. SISTEMA, de acordo com a reivindicação 55, caracterizado por, em relação ao Desenvolvimento de Estrutura Aprimorada (EFD), os Princípios de Desenho de Eficiência, Princípios de Desenho de Estabilidade e Mapa de Propósito de Hardware serem fornecidos como entrada inicial ao Lembrete de Invocação de Dedução (DIP) que produz um Lembrete, o qual é enviado para IQR, em que o Lembrete provido é analisado por CKR para decifrar os Detalhes Ausentes do Lembrete, em que os Detalhes Ausentes resultantes são enviados para SC que colabora com a origem do Lembrete para recuperar informação complementar, em que a versão do Lembrete produzido de SC é enviada para AC que tenta formar uma resposta coerente para o Lembrete ao se referir a CKR diretamente e também por meio de HM.
106. SISTEMA, de acordo com a reivindicação 9, caracterizado por, em relação à invocação de RP2 em CTMP, LOM produzir a Estrutura de Moldura Ideal ao invocar AC, em que a Estrutura de Moldura Ideal é então submetida a RP2, que abre os dados para produzir casos de um Traço de Depuração e Traço de Algoritmo, em que RP2 transfere os dados relacionados ao resultado de percepção produzido para POE.
107. SISTEMA, de acordo com a reivindicação 72, caracterizado por, em relação ID de CTMP, os Ângulos Aplicados de Percepção de PS serem enviados para ID para produzir mais Percepções pertencentes aos Ângulos Implicados de Percepção, em que a Combinação Métrica separa os Ângulos de Percepção recebidos em categorias de métricas, em que os Ângulos de Percepção de entrada estão relacionados à Estrutura de Moldura Ideal, em que o Conjunto de Complexidade Métrica A é enviado para ME, em que na potencialização e conclusão de
Petição 870190069340, de 22/07/2019, pág. 75/126
70/110 enriquecimento de complexidade, as métricas são devolvidas como saída de ME como Conjunto de Complexidade Métrica B e, consequentemente, convertido de volta a Ângulos de Percepção para serem armazenados nos Ângulos Implicados de Percepção, em que o Conjunto de Complexidade Métrica B C737 é processado pela Conversão Métrica que reverte as métricas individuais de volta para todos os Ângulos de Percepção.
108. SISTEMA, de acordo com a reivindicação 9, caracterizado por, em relação à operação de LIZARD converter a Interpretação de Estrutura de Moldura Refinada em um Mapa de Propósito de Estrutura Ideal, a Interpretação de Estrutura de Moldura Refinada ser enviada para SM, Redução Lógica de SM enviar sua saída para a Interpretação Iterativa de PM, em que a Interpretação Iterativa segue todas as funções interconectadas para produzir uma definição de propósito interpretado ao se referir às Associações de Propósito, em que uma saída é rotulada como um Mapa de Propósito de Estrutura Refinada.
109. SISTEMA, de acordo com a reivindicação 9, caracterizado por, em relação à Correspondência de Mapa de Necessidade (NMM) , o caso de NMM é gerado para servir à operação de Desenvolvimento de Estrutura Aprimorada (EFD), em que na invocação de NMM, a Análise Inicial baixa cada ramo de jurisdição do Armazenamento para reter temporariamente referindo-se ao caso NMM em andamento, em que com as Necessidades de Ramos para Cálculo: de acordo com as definições associadas a cada ramo, as necessidades são associadas a seu departamento correspondente, em que o Resultado de Processamento de Simetria é provido como um Propósito de Entrada como entrada para o Algoritmo de Pesquisa de NMM, em
Petição 870190069340, de 22/07/2019, pág. 76/126
71/110 que o Algoritmo de Pesquisa menciona e pesquisa através do índice de Necessidade compilada por meio do qual determina se o Propósito de Entrada define uma necessidade válida de acordo com os ramos de jurisdição inicialmente definidos no Desenvolvimento de Acesso de Necessidade e Armazenamento, em que a execução concluída do Algoritmo de Pesquisa por meio do índice de Necessidade produz uma resposta de Aprovação/Bloqueio que é enviada como saída modular de NMM e mencionada como Resultado de Necessidade.
110. SISTEMA, de acordo com a reivindicação 9, caracterizado por, em relação à invocação de Produção de Percepção Bruta (RP2) no CTMP, LOM produzir a Estrutura de Moldura Ideal ao invocar AC, em que a Estrutura de Moldura Ideal é então enviada para RP2 que abre os dados para produzir casos de um Traço de Depuração, em que RP2 transfere os dados em relação ao resultado de percepção produzida para POE.
111. SISTEMA, de acordo com a reivindicação 9, caracterizado por, em relação à operação de LIZARD converter a Configuração de Hardware Ideal em um Mapa Hierárquico de Propósito, a Configuração de Hardware Ideal ser enviada para SM, em que a Redução Lógica de SM envia sua saída para a Interpretação Iterativa de PM, em que a Interpretação Iterativa segue todas as funções interconectadas para produzir uma definição de propósito interpretado ao se referir às Associações de Propósito, em que a saída é rotulada como Mapa Hierárquico de Propósito que é apresentado como a versão do Formato de Propósito Complexo da Configuração de Hardware Ideal.
112. SISTEMA, de acordo com a reivindicação 9, caracterizado por, em relação à operação de Correspondência de
Petição 870190069340, de 22/07/2019, pág. 77/126
72/110
Mapa de Necessidade (NMM) , NMM ser gerado para servir a operação de Middleware de Instrução Externa (EIM), em que a Análise Inicial baixa cada ramo de jurisdição do Armazenamento para reter temporariamente para referência no caso de NMM em andamento, em que as Necessidades de Ramo para Cálculo: de acordo com as definições associadas a cada ramo, as necessidades estão associadas ao seu departamento correspondente, em que o Propósito de entrada é provido como entrada para o Algoritmo de Pesquisa de NMM, em que o Algoritmo de Pesquisa menciona e pesquisa através do índice de Necessidade compilado, por meio do qual determina se o Propósito de entrada define uma necessidade válida de acordo com os ramos de jurisdição inicialmente definidos no
Desenvolvimento de Acesso de Necessidade e Armazenamento, em que o Algoritmo de Pesquisa produz uma resposta de Aprovação/Bloqueio, em que o Resultado de Necessidade é devolvido no EIM que processa como Disponibilidade de Isolamento de Instrução. 113. SISTEMA, de acordo com a reivindicação 54,
caracterizado por, em relação à operação e funcionalidade da Camada de Imitação de Appchain (AEL) e produção de uma Pilha de Aplicativo Pré-compilada (PAS) por meio do Processamento de Appchain Estático (SAP), SAP interpretar o conteúdo de Appchain correspondente, produzir a Retenção de Appchain Estática e enviá-la para PAS, em que AEL é compilado e incorporado em PAS, fornecendo, portanto, a autonomia de caso de PAS nos Sistemas de Legado, em que a Interpretação e Detecção de Sistema Alvo (TSID) de AEL executa em um conjunto de instrução básica preliminar e busca detectar o Sistema Operacional, Drivers do Dispositivo e Hardware do Sistema Alvo, em que AEL
Petição 870190069340, de 22/07/2019, pág. 78/126
73/110 invocaria o mecanismo de tradução adequado para executar o código complexo no Sistema Alvo, possibilitando a Retenção de Appchain Estática a ser completamente executada, em que a Retenção contém os Segmentos de Execução de Appchain e Segmentos de Dados para a Appchain direcionada, junto a outras Appchains que a Appchain direcionada depende para operação.
114. SISTEMA, de acordo com a reivindicação 113, caracterizado por SAP produzir um caso de Retenção de Appchain Estática que contém a Appchain direcionada, em que a Retenção de Appchain Estática é enviada para a Execução e Extração de Segmento de Dados (EDSE) de AEL, em que EDSE é um módulo de Conteúdo para a invocação de Coleção de Fluxo de Execução (ESC) e para a invocação de Classificação de Fluxo de Dados (DSS), em que o Sistema Alvo é interpretado pelo módulo de Interpretação de Sistema Alvo e Detecção (TSID) por meio de consideração da Coleção de Biblioteca de Sistema Alvo Estático que define os Conjuntos de Instrução apropriados que são aplicáveis a diversos tipos de Sistema, em que TSID produz o Conjunto de Instrução de Sistema Alvo que possibilita a operação interna de AEL para enviar as instruções computacionais corretas ao Sistema Alvo, em que a Tradução de Segmento de Execução (EST) é invocada para interpretar o Conjunto de Instrução do Sistema Alvo que, portanto, traduz a Sintaxe da Appchain nas instruções de legado apropriadas, em que a Tradução de Segmento de Dados (DST) é invocada para interpretar o Conjunto de Instrução do Sistema Alvo que traduz a Sintaxe da Appchain nos segmentos de legado apropriados de dados, em que as saídas modulares de EST e DST são enviadas para a Unificação de Instrução de Legado (LIU), que invoca um caso ao vivo de Renderização de Fluxo de Execução (ESR) para
Petição 870190069340, de 22/07/2019, pág. 79/126
74/110 render a Retenção de Appchain Estática de acordo com o Conjunto de Instrução do Sistema Alvo definido.
115. SISTEMA, de acordo com a reivindicação 114, caracterizado por, em relação à operação de Middleware de Instrução Externa (EIM), a operação da Retenção da Appchain Estática no caso de ESR da Unificação de Instrução de Legado (LIU) fazer a LIU produzir a Proposição de Instrução Externa e do índice de Disponibilidade de Isolamento de Instrução como saída modular, em que as Saídas são enviadas para EIM, em que LIZARD é invocado para converter a Proposição de Instrução Externa em um Mapa Hierárquico de Propósito, em que o Processamento de Realinhamento de Propósito (PRP) é invocado para a Coleção de Propósito de Instrução de entradas modulares e Mapa Hierárquico de Propósito, em que a Afinidade Mestre/Escrava define a Coleção de Propósito de Instrução como a escrava, em que PRP produz a nova iteração da Coleção de Propósito de Instrução, em que LIU é invocado para produzir Disponibilidade de Isolamento de Instrução por meio da Correspondência de Mapa de Necessidade (NMM), em que a variável de Disponibilidade define se a Coleção de Propósito de Instrução está isolada o bastante dentro do Sistema Alvo a ser executado sem interferência de sintaxes de execução alternativas, em que o Lembrete é ativado, que avalia se a Disponibilidade de Isolamento de Instrução indica que a Coleção de Propósito de Instrução pode ser implantada no Sistema Alvo, em que, se a resposta ao Lembrete é Implantação não Pronta, então o Estágio é ativado, o qual suspende a execução de EIM até a próxima Proposição de Instrução Externa ser produzida por ESR por meio do LIU, em que, caso a resposta ao Lembrete seja Implantação Pronta, então LIZARD é invocado para converter
Petição 870190069340, de 22/07/2019, pág. 80/126
75/110 a Coleção de Propósito de Instrução na Sintaxe correspondente definida por TSID.
116. SISTEMA, de acordo com a reivindicação 113, caracterizado por, em relação à operação de SAP, uma Coleção de Appchain Proposta ser produzida a partir da Interface Administrativa, em que a Execução e Coleções de Segmento de Dados são produzidas a partir de referências da Coleção de Appchain Proposta, em que a Coleção de Appchain Proposta é processada por ESR de dentro do Ambiente de Captura Modificada (MCE) que é um ambiente de execução personalizado que aciona pontos para diversos eventos de modo que a dependência de caminho e informação de depuração possam ser derivadas da sessão de execução, em que o Atendimento de Solicitação de Dependência (DRF) é invocado no SAP em conexão com MCE, em que uma Solicitação de Execução ou Dados é feita por ESR, em que as Coleções de Execução e Segmento de Dados são avaliadas para determinar se a Solicitação de Execução ou Dados feita por ESR exista em tais Coleções, em que caso a resposta ao Lembrete seja Existe, então o Lembrete é invocado, o qual avalia se o Segmento de Execução ou Dados correspondente é justificado de acordo com NMM.
117. SISTEMA, de acordo com a reivindicação 116, caracterizado pela Coleção de Appchain Proposta ser enviada separada nas Referências da Appchain independente que são subsequentemente armazenadas na Retenção de Cache de Referência da Appchain (ARCR), em que um Ciclo que submete a ciclo todos os Casos de Appchain em ARCR é gerado, em que o Caso de Appchain selecionado é recuperado do Nó de Cache relevante a partir da Rede BCHAIN e por meio do Protocolo
Petição 870190069340, de 22/07/2019, pág. 81/126
76/110
BCHAIN, em que o Caso da Appchain Atendida é produzido e processado por meio de invocações de ESC e DSS.
118. SISTEMA, de acordo com a reivindicação 113, caracterizado por uma Solicitação de Reivindicação de Conteúdo (CCR) com uma Via de Hop Basal Proposta (PBHP) ser produzida, em que CCR é enviada na Rede BCHAIN de modo que eventualmente atinja um Nó de Cache correspondente que contém partes do Caso de Appchain solicitado, em que o Nó de Cache atende a CCR, obtendo assim a compensação eventualmente econômica por meio do Protocolo BCHAIN e ao impulsionar a Economia de Watt da Metachain, em que o Nó de Cache produz uma unidade de Atendimento de Reivindicação de Conteúdo correspondente (CCF) em resposta à CCR correspondente, em que a CCF recém-produzida percorre ao longo da Rede BCHAIN para atingir o módulo de Renderização de Reivindicação de Conteúdo (CCR) do Nó que está processando o caso SAP, em que as Instruções de Decodificação de Conteúdo são mencionadas para render a resposta de CCF, que produz o Caso de Appchain Atendida.
119. SISTEMA, de acordo com a reivindicação 113, caracterizado por, em relação DRF dentro de SAP, a resposta Existe ao Lembrete invocar se o Segmento de Execução ou Dados correspondente ser justificada de acordo com NMM, em que caso ocorra a resposta justificada ao Lembrete, então o Segmento de Execução ou Dados é marcado para inclusão na Retenção de Cache de Segmento Marcado (MSCR), em que a resposta Não Existe e a resposta justificada gerem e enviem uma Unidade de Registro Diagnóstico (DLU) que contém um Código de Sistema Oficial, em que o Código é incluído para indicar que a função ou programa correspondente atingiu um estado não ideal caso uma função oficial na Plataforma UBEC, em que DLU é enviado para DLS, que
Petição 870190069340, de 22/07/2019, pág. 82/126
77/110 é invocado por ARM para fornecer DLU a SPSI por meio do qual SPSI é capaz de processar a informação diagnostica encontrada em DLU com DLUA.
120. SISTEMA, de acordo com a reivindicação 113, caracterizado por SAP ser invocado por um Usuário UBEC ou Usuário Genérico por meio de uma Interface Administrativa, em que uma Coleção de Appchain Proposta é recebida, em que um Ciclo submeter a ciclos todos os Casos de Appchain da Retenção de Cache de Referência de Appchain (ARCR) , em que o Caso de Appchain Atendida é recuperado a partir da Retenção de Cache de Segmento Marcado (MSCR), os Casos de Appchain atendida contém o conjunto completo de Segmentos de Execução e de Dados exigidos para executar a Appchain escolhida, em que todos os Casos de Appchain Atendida são adicionalmente instalados na Retenção de Appchain Estática, que sai do Segmento de Execução ou de Dados sendo verificado por ter status Marcado por MSCR, em que a Retenção de Appchain Estática é produzida como a saída modular final de SAP, e é, consequentemente, enviada como entrada modular a EDSE de AEL.
121. SISTEMA, de acordo com a reivindicação 1, caracterizado por, em relação à Troca Econômica Digital Criptográfica (CDEE) e seu módulo de dependência LUIGI, o módulo do núcleo de Satisfação Metafísica Neuroeconômica (NMC)
se Avaliação de Estado Abrangente (CSE) que monitora e regulação, conduzido por meio da Supervisão de Movimento de Fundos (FMO) dos fundos que se movem para uma Alocação de Fundos Públicos de App (APFA) , que pertence ao App UBEC
designado que foi selecionado para investimento pela Estrutura de Dotação relevante (ES), em que o acesso criptográfico aos fundos detido em APFA é mantido por meio dos Nós de BCHAIN, em
Petição 870190069340, de 22/07/2019, pág. 83/126
78/110 que BD e ID de ES têm acesso ao Mecanismo de Recuperação de Fundo (FRM) do LUIGI.
122. SISTEMA, de acordo com a reivindicação 121, caracterizado por, em relação LUIGI que opera como uma Appchain na Plataforma UBEC, as invocações de LUIGI regular o movimento da Unidade de Watt e prover garantia de segurança de Alocação da Unidade de Watt em CDEE, em que a Conexão UBEC recebe informações de transferência de dados das Appchains por meio das quais o tráfego e atividade em CDEE é inerentemente ligada ao gancho de Conexão UBEC, em que a Deleção de Tarefa de LUIGI (LTD) determina se os dados recebidos da Conexão UBEC devem ser processados por LIZARD, LOM ou ambos, em que a invocação da Appchain de LIZARD indica que o modo de processamento do 'Leitor de Execução Jurisdicional e de Intenção Reader' foi selecionado, em que a invocação da Appchain de LOM indica que o modo de processamento de 'Investigação de conhecimento e Arbitração Judicial' foi selecionado, em que o fluxo lógico continua para Customização de API Dinâmica (DAC), em que a função de DAC é interpretar o Tipo de Tarefa e, portanto, personalizar a interface da API selecionada para o Tipo de Tarefa selecionada, em que os algoritmos LOM e LIZARD correspondentes são executados conforme são invocados, produzindo, portanto, resultados analíticos que são enviados para Unificação de Conclusão Inteligente (ICU), em que ICU reconcilia quaisquer conclusões interpretativas/subjetivas entre LOM e LIZARD.
123. SISTEMA, de acordo com a reivindicação 122, caracterizado pela Composição de Decisão de Investimento Ideal da saída de CSE ser recebida por meio da Conexão UBEC, em que LUIGI percebe que a Composição atua como um Conteúdo de
Petição 870190069340, de 22/07/2019, pág. 84/126
79/110 diversas Alocações de Investimento de subelemento, Retiradas de Investimento, Alocações de Lucro e Notificação Diretora, em que a Delegação de Tarefa de LUIGI (LTD) delega a Composição de saída de dados correspondente para ser analisada pelos ramos LUIGI apropriados de análise: Investigações de Conhecimento e Arbitração Judicial (LOM), e Execução Jurisdicional e Leitor de Intenção (LIZARD).
124. SISTEMA, de acordo com a reivindicação 122, caracterizado por, em relação às Appchains que interagem com LUIGI, a Plataforma UBEC ser manifestada como uma Appchain com a Appchain UBEC, que se liga à Conexão UBEC para prover entrada de dados modulares para LUIGI, em que na conclusão de processamento de LUIGI, o Retorno Abrangente de UBEC envia os dados de volta à Appchain UBEC, em que LOM atua como a Appchain principal para possibilitar o processamento no ramo de Investigações de Conhecimento e Arbitração Judicial, em que LOM e LIZARD alimentam as informações de customização de API para a Customização de API Dinâmica (DAC), que possui acesso às informações de API apropriadas para realizar as customizações relevantes do processo lógico conforme necessário, dependendo de qual Appchain é invocada, em que SPSI monitora, mantém e moderniza a composição e operação de LUIGI.
125. SISTEMA, de acordo com a reivindicação 124, caracterizado por, em relação a DAC, a API de Uso de LIZARD ser provida na operação de DAC, em que LTD determina o Tipo de Tarefa que é definido na Recepção de Tarefa e o Tipo de Tarefa provido indicar o escopo de customização para DAC que provê Conjunto de Instrução Modular, o qual é provido para o Ramo selecionado, em que o Conjunto de Instrução Modular é
Petição 870190069340, de 22/07/2019, pág. 85/126
80/110 programado em conformidade com a API de Uso de LIZARD, em que LIZARD é executado para atender a duas entradas, em que a Unificação de Conclusão Inteligente (ICU) reconcilia diversas saídas de diferentes Execuções de Módulo para garantir uma saída unificada singular dos Ramos por meio dos quais permite a recepção de entrada simplificada da Ação Corretiva de LUIGI (LCA).
126. SISTEMA, de acordo com a reivindicação 124, caracterizado por, em relação a DAC, a API de Uso de LOM ser provida na operação de DAC, em que LTD determina o Tipo de Tarefa que é definido na Recepção de Tarefa, em que o Tipo de Tarefa é interpretado no DAC que produz o Conjunto de Interpretação Modular, o qual é provido para ser o Ramo selecionado, em que o Conjunto de Interpretação Modular é programado em conformidade com a API de Uso de LOM, em que LOM é executado para atender a duas entradas, em que ICU reconcilia diversas saídas de diferentes Execuções de Módulo para garantir uma saída unificada singular dos Ramos que permite a recepção de entrada simplificada de LCA.
127. SISTEMA, de acordo com a reivindicação 122, caracterizado por, em relação às funções de manipulação de liquidez de moeda que pertencem exclusivamente a LUIGI na Manipulação de Liquidez Financeira, em que dentro de LSE estar uma Chave de Decodificação de Retenção que permite ao LUIGI decodificar a Retenção Codificada de Chaves Privadas que permite ao Mecanismo de Manipulação de Fundo (FMM) manipular fundos na Economia de Watt da Metachain em uma sessão de recuperação de fundos, em que a Prova de Autoridade é uma chave criptográfica exclusiva que é criptograficamente garantida por ser a única produzível por LUIGI devido às logísticas de LSE,
Petição 870190069340, de 22/07/2019, pág. 86/126
81/110 em que a Prova de Autoridade é usada para invocar um Chip UBMA para fornecer sua Chave Privada Exclusiva Sensível de Segurança.
128. SISTEMA, de acordo com a reivindicação 122, caracterizado por BD e ID interagirem com DVM por meio da Interface de Votação de Proposta (PVI), em que uma Proposta Autorizada é enviada por um Diretor, em que com o ID, as Propostas são efetivamente tratadas como comandos em ES devido ao fator de serem apenas um único Diretor e não dilema de consenso, em que a Admissão do Novo Diretor implica aceitação potencial do Comitê de um novo Diretor, em que a Proposta só é aplicável a BD e não a ID, em que a aplicabilidade da Admissão do Novo Diretor depende da política definida em EPR, em que os votos realizados pelos Diretores por meio de DVM para modificar uma Política pré-existente são votos eficazes para um par acoplado de Propostas, Adição de Regra de Política e Exclusão de Regra de Política que são tratadas como uma única unidade, em que a Adição de Medida de Comando Manual introduz uma nova regra de personalização para Retenção de Medida de Comando (OMR), que influencia a Composição de Decisão de Investimento Ideal produzida por CSE, em que se dois ES foram gerados no exato mesmo tempo, ambos com um OMR idêntico, então teoricamente receberão as exatas mesmas Composições de Decisão de Investimento Ideal de CSE.
129. SISTEMA, de acordo com a reivindicação 122, caracterizado por, em relação à Iniciação de Ameaça Preliminar (PTI), o Intervalo de Invocação de CSE ser recuperado da Retenção de Política Estabelecida (EPR), em que o Intervalo define quão frequente o ES relevante pretende que um caso de CSE seja gerado, em que um Intervalo menor implica que o EPR
Petição 870190069340, de 22/07/2019, pág. 87/126
82/110 indica que mais Unidades de Watt devam ser gastas nas Taxas de BCHAIN para hospedar mais iterações de casos de CSE, em que o tempo de Última Invocação de CSE é recuperado de uma loja de valor definido em EPR, em que o valor da Última Invocação de CSE é uma variável específica que está relacionada ao BD ou ID específico, em que no financiamento bem sucedido dos Nós de BCHAIN relevantes do Capital de Investimento de Capital (IC) correspondente, se a Manipulação de Medida de Comando Automatizado (AOM2) tiver sido assinalada para invocação no EPR correspondente do ES relevante ser avaliada, em que ES pode optar por ter A0M2 habilitado caso uma Mente Alvo especificada seja pretendida para guiar as decisões de investimento por CSE.
130. SISTEMA, de acordo com a reivindicação 129, caracterizado por AOM2 simular os critérios reacionários de uma Mente Alvo, que foi identificada por meio da Identidade de Mente Alvo de AOM2, para promulgar, modificar ou remover Medidas de Comando promulgadas a partir da Retenção de Medida de Comando (OMR) de um ES relevante, em que o efeito prótico da operação de AOM2 é que o ES relevante contém uma OMR condutora das reações e tendências esperadas da Mente Alvo, em que a composição resultante de OMR influencia as Circunstâncias de Investimento Alvo produzidas pela Interpretação de Circunstâncias de Investimento Alvo (TICI) e, portanto, a Composição de Decisão de Investimento Ideal produzida por CSE, em que o Cache de Resultados de TICI é descomprimido e extraído para produzir as Circunstâncias de Investimento Alvo como originalmente processadas por TICI, em que a Posição de Participação Atual é recuperada da Retenção de Participação de Portfolio (PSR), em que todas as Medidas de Comando atualmente
Petição 870190069340, de 22/07/2019, pág. 88/126
83/110 ativas de OMR são recuperadas e produzidas como Medidas de Comando Ativo, em que todas as Medidas de Comando Ativo variáveis anteriormente processadas, Posição de Participação Atual, Circunstâncias de Investimento Alvo e Identidade de Mente Alvo AOM2 são acumuladas, em que na acumulação, as variáveis mencionadas acima são fornecidas ao Módulo de Solicitação de Emulação de Mente (MERM) para invocar casos de Rastreamento de Mente Digital (DMT).
131. SISTEMA, de acordo com a reivindicação 130, caracterizado por MERM ser invocado para produzir uma Solicitação de Emulação de Mente a DMT de que DMT usa CTMP para similar a Mente Alvo representada pela Identidade de Mente Alvo AOM2, produzindo, portanto, o Resultado de Percepção de Mente, que é enviado de volta a MERM, em que MERM invoca diversos casos de DMT conforme necessário para produzir de forma precisa o resultado final das Medidas de Comando Preferidas, que representa as Medidas de Comando que esperase serem selecionadas e, assim, preferidas pela Mente Alvo especificada.
132. SISTEMA, de acordo com a reivindicação 122, caracterizado pelas decisões baseadas em consenso investir em serviços de previsão de investimento inteligente serem tomadas em ES, em que ES financia o serviço de previsão, Avaliação de Estado Abrangente (CSE), por meio de IC, em que CSE é invocado de acordo com o Intervalo de Invocação de CSE que é definido na Retenção de Política Estabelecida (EPR), em que o trabalho computacional é realizado entre os Nós de BCHAIN que operam o Protocolo de BCHAIN, formando assim a Rede BCHAIN, em que a manipulação de fundos que está estrategicamente alocada no IC relevante acresce a Economia de Watt da Metachain, em que os
Petição 870190069340, de 22/07/2019, pág. 89/126
84/110 fundos nunca existem criptograficamente de modo direto no próprio caso de IC, mas são empenhados por meio de WUP2 pelos Nós de BCHAIN que detêm os fundos por meio dos quais todas as Unidades de Watt são gerenciadas pela Economia de Watt enquanto reside criptograficamente nos Nós físicos de BCHAIN.
133. SISTEMA, de acordo com a reivindicação 122, caracterizado por CSR gerir os relatórios de informação realizados pelas entidades corporativas registradas que enviam informação operacional à sua Appchain de Entidade de Rastreamento Corporativo correspondente, que possibilita a Avaliação de Estado Abrangente (CSE) para considerar a atividade operacional de todas as entidades corporativas registradas no processamento de ES, em que uma entidade corporativa é 'registrada' no sentido de que optou por anunciar os elementos chave de dados registrados relativos às suas atividades operacionais para a Appchain de Rastreamento de Entidade Corporativa, em que o Gerado de Reivindicação de Conteúdo (CCG) é uma função do Protocolo BCHAIN que possibilita ao conteúdo ser recuperado de diversos Nós BCHAIN, em que o Módulo de Reconhecimento de cadeia personalizada (CRM) é uma função do Protocolo BCHAIN, que mantém automaticamente as Appchains que são definidas nas Appchains Registradas, em que o Relatório de Erro na forma de um DLU é encaminhado por ARM para SPSI, que processa o Relatório de Erro por meio da Análise de Unidade de Registro Diagnóstico (DLUA), em que o ciclo de resposta do Relatório de Erro com SPSI leva à programação de CSR para alterar eventualmente, para acomodar solução comprovada do Relatório de Erro inicial demonstrado por DLU após o conceito de SRIA, em que MRP é iniciado pela operação de CSE via RIP que invoca um caso de LOM que pesquisa a
Petição 870190069340, de 22/07/2019, pág. 90/126
85/110
Atividade e Eventos de Mercado via ARM, em que ARM inicialmente recupera informação não confirmada de fontes pública e privada e, consequentemente, LOM e CTMP verificarem a informação não confirmada e expandi-la para produzir conceitos confiáveis.
134. SISTEMA, de acordo com a reivindicação 122, caracterizado pelo Procedimento Regulatório/de Pesquisa de Taxa (RTRP) ser iniciado pela operação de CSE via RIP que invoca um caso de LOM que pesquise os Códigos de Taxa e Regulatórios via ARM, em que ARM inicialmente recupera informação não confirmada de fontes pública e privada e, consequentemente, LOM e CTMP verificam a informação não confirmada e a expande para produzir conceitos confiáveis.
135. SISTEMA, de acordo com a reivindicação 122, caracterizado por TICI extrair a Composição de Participação de Portfolio da Retenção de Participação de Portfolio (PSR) relevante do ES correspondente, em que as Medidas de Comando são extraídas da Retenção de Medida de Comando relevante (OMR) do ES correspondente, em que as Medidas de Comando induzem um efeito de personalização pretendido à Composição de Decisão de Investimento Ideal resultante via DVM, em que as informações contidas na Composição de Participação de Portfolio e Medidas de Comando são mescladas em um Conteúdo de Abstração que se torna Circunstâncias de Investimento Alvo, a qual é enviada para CSE, em que na invocação completa de LOM e CTMP, a Composição de Decisão de Investimento Ideal é produzida por CSE, em que LOM produz Conhecimento de Atividade de Mercado a partir de CKR, em que LOM é invocado para produzir tal Conhecimento por meio do Lembrete de Invocação de Conhecimento de NMC (NKIP).
Petição 870190069340, de 22/07/2019, pág. 91/126
86/110
136. SISTEMA, de acordo com a reivindicação 122, caracterizado pelas Circunstâncias de Investimento Alvo serem fornecidas ao Lembrete de Invocação de Configuração Idealista (ICIP), em que o Lembrete produzido por ICIP 12403 é enviado para IQR de LOM, em que o Lembrete provido é analisado por CKR, em que NMM é gerado para servir CSE, em que o Estado de Situação em sua Totalidade é enviado para armazenar no Acesso de Necessidade e Desenvolvimento e Armazenamento, em que o Estado de Situação em sua Totalidade é decomposto em subcategorias e mantido no Armazenamento como uma série de ramos e camadas hierárquicas, em que o Risco à Segurança Artificial (AST) provê um Propósito de Entrada para o Algoritmo de Pesquisa de NMM, que menciona e pesquisa através do índice de Necessidade compilado, determinado, portanto, se o Propósito de Entrada define uma necessidade válida de acordo com os ramos de jurisdição inicialmente definidos no Desenvolvimento e Armazenamento de Acesso de Necessidade.
137. SISTEMA, de acordo com a reivindicação 122, caracterizado pela Iniciação de Risco Preliminar (PTI) iniciar um caso da Interpretação de Circunstâncias de Investimento Alvo (TICI) que produz as Circunstâncias de Investimento Alvo para o mecanismo de Processamento Interno de CSE, em que a Composição de Decisão de Investimento Refinado é aberta para seus elementos individuais, em que a Composição de Participação é assimilada nas Circunstâncias de Investimento Alvo, a Atuação de Decisão de Investimento (IDA) executa os Elementos Individuais providos para realizar as consequências pretendidas para o ES relevante.
138. SISTEMA, de acordo com a reivindicação 122, caracterizado por, em relação à operação de Rastreamento de
Petição 870190069340, de 22/07/2019, pág. 92/126
87/110
Mente Digital (DMT), o Registro de Comportamento Alvo (TBR) receber as informações do Conjunto de Dados Comportamentais (BDS) diretamente da Mente Alvo especificada, e também associações de mapeamento neurológico feitas pela Potencialização de Mapeamento Neurológico (NME), em que BDS contém informações sobre Ações, Declarações e Metadados em relação à Mente Alvo, em que o caso de BDS é fornecido por DMT, e normalizado por meio de LIZARD, que o converte a partir de seu formato de propósito, por meio do qual um Mapa de Propósito Comportamental é construído do caso BDS por LIZARD, em que o Mapa de Propósito Comportamental é armazenado e retido em um caso de Perfil de Inteligência Pessoal (PIP) que é logicamente associado à Mente Alvo, em que LOM é invocado para produzir Tipos de Modelo de Personalidade, em que uma Composição de Modelo de Personalidade é produzida a partir do Atendimento ao Modelo de Personalidade (PTF), em que uma Composição de Modelo de Personalidade captura os elementos de personalidade que existem a partir dos Tipos de Modelo de Personalidade de acordo com os Critérios de Modelo de Personalidade da Mente Alvo, em que LOM é invocado para produzir a Definição de Nuance de Personalidade que corresponde à Mente Alvo a partir do caso de PIP correspondente.
139. SISTEMA, de acordo com a reivindicação 138, caracterizado por PTF iniciar um Ciclo para submeter a ciclo através dos Critérios de Modelo de Personalidade, em que os Critérios de Modelo de Personalidade Selecionados a partir da Iteração de Ciclo recupera os Tipos de Modelo de Personalidade correspondente de acordo com os Tipos de Modelo de Personalidade que são mencionados nos Critérios de Modelo de Personalidade selecionada que produzem o Tipo de Modelo de
Petição 870190069340, de 22/07/2019, pág. 93/126
88/110
Personalidade selecionado designado de acordo com a Magnitude de presença definida nos Critérios de Modelo de Personalidade Selecionados que produzem a Composição de Modelo de Personalidade, em que LIZARD converte a Definição de Nuance de Personalidade em um Mapa Hierárquico de Propósito, em que LIZARD converte a Composição de Modelo de Personalidade em um Mapa Hierárquico de Propósito, em que ambos os Mapas Hierárquico de Propósito são processados pelo Processamento de Simetria de Propósito para Propósito (P2SP) que determina a congruência/compatibilidade entre as entradas, produzindo, portanto, o Resultado de Processamento de Simetria.
140. SISTEMA, de acordo com a reivindicação 139, caracterizado pela Identidade da Mente Alvo da Mente Alvo ser recuperada e o caso de Retenção de Cache de Cópia de Personalidade (PSCR) que está associado à Identidade de Mente Alvo ser recuperado, em que, caso haja iteração anterior do Sistema de Reação de Personalidade que está armazenada no caso PSCR correspondente Época Definida é verificada, em que a Época Definida é mencionada a partir da Identidade de Mente Alvo, em que a Época Definida pode fazer distinções entre versões antigas e mais novas de pessoas de como elas eram, caso positivo, a iteração anterior do Sistema de Reação de Personalidade é excluído do caso PSCR, em que a próxima etapa converte, armazena e retém o Sistema de Reação de Personalidade no caso PSCR que está associado à Mente Alvo da Época Definida de acordo com a Identidade da Mente Alvo.
141. SISTEMA, de acordo com a reivindicação 140, caracterizado por um Conjunto de Comando Personalizado ser enviado para ESR, que o instrui a extrair o conteúdo da Appchain de CTMP sem quaisquer dados pré-existentes produzindo
Petição 870190069340, de 22/07/2019, pág. 94/126
89/110 uma Base de Execução de CTMP Vazia, que é uma captura de cópia do caso ESR, em que a Base de Execução de CTMP Vazia é fornecida em um novo caso de ESR, em que a Appchain de CTPM Personalizada fornecida interage com o Sistema de Reação de Personalidade que captura a Personalidade da Mente Alvo no caso de CTMP personalizado, em que um Conjunto de Comando Personalizado é enviado como uma instrução para o caso ESR para praticar todas as alterações para armazenamento persistente e o Caso CTMP Personalizado é eficazmente capturado em um arquivo de Retenção de Appchain de Cópia de CTMP, em que um conjunto de Cenários de Emulação Relevante é produzido por meio da Produção de Cenário de Emulação (ESP), em que ESP produz Cenários de Emulação Relevantes que são relevantes para o escopo, jurisdição e capacidades do Sistema de Reação de Personalidade, em que um Ciclo é iniciado, o qual se repete através dos Cenários de Emulação Relevante que produz um Cenário de Emulação Selecionado de unidade única por repetição do Ciclo, em que o Cenário de Emulação Selecionado é aberto para produzir duas variáveis principais que contêm: a Proposição de Emulação e o Ambiente de Emulação, em que a Proposição de Emulação é enviada para o caso de CTMP personalizado como Metadados do Sistema de Entrada e o Ambiente de Emulação é enviado como Registros para o caso de CTMP Personalizado com a classificação e Fato Objetivo.
142. SISTEMA, de acordo com a reivindicação 122, caracterizado por, em relação à Potencialização de Mapeamento Neuroeconômico (NME) que associada Padrões Neurais da Mente Alvo com estados físicos de existência que são capturados no Estado Circunstancial Alvo, o Dispositivo de Digitalização Neural Discreto (UNSD) receber um Padrão Neural Bruto da Mente
Petição 870190069340, de 22/07/2019, pág. 95/126
90/110
Alvo que está atuando em sua capacidade como um Usuário UBEC, em que a Mente Alvo que é um Usuário UBEC possibilita as comunicações de API padronizadas internas sejam realizadas por meio da Rede BCHAIN para UNSD, em que o Padrão Neural Bruto do Usuário UBEC é recebido por meio de UNSD, em que LOM relata no Estado Circunstancial Alvo e Confiança do Usuário UBEC por meio de PIP correspondente e Automação de Administração de Vida (LAA), em que LOM produz o Estado Circunstancial Alvo com base nos dados providos por PIP, que retém informações pessoais referentes ao Usuário UBEC Alvo e LAA, que conecta o estilo de vida digital do Usuário UBEC, em que LOM produz o Conhecimento de Associação de Estado Neural, que representa correlações aprendidas entre o Estado Neural potencial e o Estado Circunstancial potencial, em que a Confiança de Conhecimento de Associação de Estado Neural se correlaciona com a Confiança algorítmica que LOM possui em relação à precisão e confiança do Conhecimento de Associação de Estado Neural, em que LIZARD converte o Conhecimento de Associação de Estado Neural em um Mapa Hierárquico de Propósito.
143. SISTEMA, de acordo com a reivindicação 122, caracterizado pela, em relação a SPSI em adição a AEL, programação e reconfiguração da Metodologia de Fornecimento Perpétuo (MPG) em NMC, SPSI roda no Sistema de Legado por meio de AEL, que possibilita ao SPSI acessar e manipular elementos que existem e operam na API e Estrutura de Legado, em que SPSI realiza modernizações de eficiência e funcionalidade, manutenção e modificações gerais para MPG produzir NMC, em que SPSI é uma Appchain na Rede BCHAIN, em que SPSI converte NMC como um Programa de Legado para NMC como uma Appchain por meio
Petição 870190069340, de 22/07/2019, pág. 96/126
91/110 de invocação do Criador de Ecossistema de cadeia personalizada (CEB) .
144. SISTEMA, de acordo com a reivindicação 1, caracterizado pelo Gerenciamento de Integridade de Dados operar com Sincronização e Reconciliação de cadeia personalizada (CSR), Nós de Exploração que Fornecem Semeadura de Cache (MNSCS) e Reconstrução de Dados de Falha de Exploração (MFDR), em que DIM mantém a integridade dos dados de Appchains de modo descentralizado, e sincronização para os nós que realizaram operações enquanto offline, em que a finalidade da legitimidade de dados é considerada na Critica Profunda de Decisão de Cliente (DC2) que simula qual comportamento esperado do protocolo deve ocorrer.
145. SISTEMA, de acordo com a reivindicação 144, caracterizado pelo modulo de Criação de Taxa do Setor criar uma Unidade de Consequência de Taxa (TCU) que enumera consequências de taxa positiva ou negativa que devem ser promovidas no tempo variável quando ocorre Atendimento de Cache, em que o Cumprimento de Taxa do Setor (STE) avalia o desempenho de Atendimento de Cache dos nós no setor, e impõe o código de taxa conforme estipulado na Unidade de Consequência de Taxa (TCU), em que TCU contém um Plano de Taxa de Cronograma que é promulgado no Momento de Atendimento de Cache e enumera a potencial quebra de Taxa ou multa de Taxa, em que o Anúncio de Taxa de Setor (STA) transmite TCU a todos os nós aplicáveis na jurisdição de setor relevante, em que DIM consiste e interage com o Algoritmo de Seleção de Exploração (MSA), Economia de Watt, Localização de Cache de Appchain, Novo Trabalho Solucionado, Processamento de Reivindicação de Pagamento por Trabalho (WPCP), Digitalização de Integridade de
Petição 870190069340, de 22/07/2019, pág. 97/126
92/110
Dados (DIS), Processamento de Refúgio de Dados (DRP), Conteúdo no Relatório de Perigo, Sincronização e Reconciliação de cadeia personalizada (CSR)/Processamento de Mescla de Appchain (AMP), Seleção de Incentivo Econômico (EIS), Nó de Exploração que Fornece Semeadura de Cache (MNSCS) , Reconstrução de Dados de Falha de Exploração (MFDR), Tempo de Retenção de Cache de Exploração, Exploração para Proporção de Pagamento por Memorização, Algoritmo de Seleção de Cache (CSA), Algoritmo de Seleção de Exploração (MSA), Lógica de Pagamento de Appchain e Unidades de Trabalho de BCHAIN.
146. SISTEMA, de acordo com a reivindicação 144, caracterizado pela Distribuição de Informações do Nó demonstrar Consenso de Verificação de Reforços de Sobreposição de Blocos entre os Nós de BCHAIN, em que quando um bloco de Metachain é baixado de outro nó, é verificado por ser o bloco correto e preciso ao mencionar o hash conhecido do bloco, que cada nó retém para todos os blocos de Metachain, em que a Distribuição de Informações do Nó é demonstrada ainda por um Escopo de Metachain Total Disponível e Disponibilidade de Distribuição de Metachain que destaca tanto a Preservação Total da Zona de Retenção Obrigatória devido ao Protocolo BCHAIN que obriga a retenção dos primeiros 3 blocos, em que o módulo da Lógica de Retenção de Metachain Retenção (MRL) é codificado para selecionar a retenção dos blocos de Metachain em uma curva de distribuição exponencialmente decrescente.
147. SISTEMA, de acordo com a reivindicação 144, caracterizado pela Mescla da Appchain demonstrar a Versão de Appchain A e a Versão de Appchain B, em que o modulo de Sincronização de Tempo de Versão da Appchain (AVTS) compara as marcações tempo criptográficas de ambas as versões da Appchain
Petição 870190069340, de 22/07/2019, pág. 98/126
93/110 para deduzir qual bloco da Versão da Appchain A está cronologicamente associada a qual bloco da Versão da Appchain B, em que o Hash de Árvore de Merkle Alterado é calculado com consideração de todos os blocos anteriores na Appchain, em que a Mescla da Appchain entre a Versão da Appchain A e a Versão da Appchain B resulta em Appchain Mesclada AB e Sincronização de Tempo da Versão da Appchain (AVTS).
148. SISTEMA, de acordo com a reivindicação 144, caracterizado pela Versão de Ecossistema de cadeia personalizada A e Versão de Ecossistema de cadeia personalizada B serem reconciliadas para o Nó de BCHAIN A, Nó de BCHAIN B, Nó de BCHAIN C e Processamento de Mescla da Appchain (AMP) na Nova Interpretação de Status Quo de Ecossistema de cadeia personalizada, em que o Protocolo Idêntico/Critérios de Algoritmo levam ao Consenso sobre o Novo Paradigma Pós-Mescla, em que devido a cada Nó de BCHAIN estar executando a versão legítima do Cliente de Protocolo BCHAIN, eles podem atingir um consenso sobre o processo de mescla por ter critérios idênticos, em que este processo também elimina os Nós de BCHAIN que estão executando versões ilegítimas do Cliente de Protocolo, uma vez que seus critérios alternativos levarão a resultados falsos que são, consequentemente, ignorados pela maioria dos nós legítimos.
149. SISTEMA, de acordo com a reivindicação 144, caracterizado pela Interpretação de Dilema Completo ser uma interpretação do estado complexo real do Ecossistema de cadeia personalizada personalizável, em que a Interpretação de Dilema Completo está disponível a partir do campo, distribuída em uma Distribuição Desordenada de Partes, em que esta Interpretação de Dilema é uma representação abstrata do dilema separação
Petição 870190069340, de 22/07/2019, pág. 99/126
94/110 geográfica existente que fez com que duas versões da mesma Appchain fossem exploradas, em que cada Nó de BCHAIN individual é exposto a diferentes aspectos ou 'partes' da interpretação de dilema e em diferentes ordens, em que a Interpretação Progressiva de Realidade Existente de Dilema de Ecossistema eventualmente leva a Consenso devido a Critérios Sincronizados, em que o Ponto de Divisão da Appchain é o ponto no tempo no qual os nós envolvidos com a Appchain foram separados fisicamente de modo que não foram capazes de sincronizar mediante outras adições à Appchain e antes do Ponto de Divisão todos os blocos eram idênticos, mais posteriormente ao Ponto de Divisão todos os blocos são diferentes, em que para ocorrer uma mescla de Appchain, é necessário que fossem sincronizados uma vez.
150. SISTEMA, de acordo com a reivindicação 144, caracterizado pelo modulo de Crítica Profunda de Decisão de Cliente (DC2) receber blocos relevantes e atendidos da Metachain para similar qual a resposta correta do Protocolo BCHAIN a situações ambientais anteriores de um nó direcionado, em que as ações anteriores de um nó podem ser verificados caso estejam em conformidade com a definição legítima do Protocolo BCHAIN, ou caso o firmware/software do nó esteja intencional ou não intencionalmente comprometido, em que os elementos de confiança do nó podem ser estabelecidos, os quais possibilitam procedimentos subsequentes na Mescla da Appchain, em que o módulo de Download de Retenção de Metachain (MRD) interage com outros nós na Rede BCHAIN para recuperar o conteúdo de blocos de Metachain direcionados, em que a Carga de Pagamento de Verificação (VPB) julga, de acordo com a Política definida de
Petição 870190069340, de 22/07/2019, pág. 100/126
95/110
Appchain, que os nós devem portar a carga de pagamento para o Mesclador de Appchain.
151. SISTEMA, de acordo com a reivindicação 144, caracterizado por, em relação ao Código de Autorização Econômica de Baixo Preço (EAT), Código de Autorização Econômica de Alto Preço (EAT), Pesquisa Finita Eventualmente se Encerra Apesar do Nível de Taxa e Mecanismo de Crescimento Exponencial, para evitar que uma recompensa de bloco sobrecarregue permanentemente um sistema devido ao crescimento perpétuo e exponencial, o recurso de uma Recompensa de Bloco diminui a cada hop devido à remuneração da Recompensa de Bloco ser compartilhada com cada nó que o transmite, em que a Recompensa de Bloco eventualmente para se ser transmitida devido ao fato de ser um prospecto econômico não atraente com os nós que são propostos para interagir com a Recompensa de Bloco, em que a taxa proposta que é fixada à Recompensa de Bloco por meio de um Código de Autorização Econômica (EAT) faz toda a diferença quanto à magnitude de alcance que a Recompensa de Bloco tem entre a Rede BCHAIN e, portanto, os prospectos do Bloco de Metachain desejado sendo encontrados, em que a Lógica de Retenção de Metachain (MRL) executa o processo de tomada de decisão para quais blocos de Metachain o nó deve reter e tentar reter a gama mais apropriada de blocos de Metachain para aumentar a probabilidade de o nó ser capaz de atender de forma bem sucedida uma solicitação de Download de Retenção de Metachain (MRD).
152. SISTEMA, de acordo com a reivindicação 144, caracterizado por, em relação ao Fluxo de Mempool Mesclado, o Vetor de Quantidade de Dados ilustrar a quantidade de conteúdo que um bloco específico contribui e delineia entre o Fluxo de
Petição 870190069340, de 22/07/2019, pág. 101/126
96/110
Mempool Mesclado, em que o Vetor de Intervalo dos Dados ilustra a magnitude do escopo que os dados em um bloco específico atinge, em que a Medição Linear de Tempo mede o tempo de forma consistente e linear, à qual o conteúdo de diversos blocos são delineados contra, em que o módulo de Rastreamento do Evento de Mescla (MET) que inclui as Marcas de Evento de Mescla para um Registro de Evento de Mescla que acompanha cada único bloco que já passou por uma Mescla de Appchain, permitindo assim futuras implementações de operações analíticas avançadas e de segurança em relação a ataques de injeção de informação à cadeia personalizada.
153. SISTEMA, de acordo com a reivindicação 144, caracterizado por, em relação à Exploração de Nós que fornecem Semeadura de Cache (MNCS) , o módulo Criação de Taxa de Setor (STC) criar uma Unidade de Consequência de Taxa (TCU) que enumera as consequências de taxa positiva ou negativa que devem ser decretadas no tempo variável quando ocorre Atendimento de Cache, em que os fatores que definem a composição de uma TCU inclui a quantidade de nós no setor, magnitude de Demanda do Setor, magnitude de Fundos de Emergência de Setor, em que o Cumprimento de Taxa de Setor (STE) avalia o desempenho de Atendimento de Cache dos nós no setor, em que na obtenção eventual do status de Atendimento de Cache no setor, este módulo aplica o código de taxa conforme estipulado na Unidade de Consequência de Taxa (TCU) , em que o Anúncio de Taxa de Setor (STA) transmite a Unidade de Consequência de Taxa (TCU) a todos os nós aplicáveis na jurisdição de setor relevante, em que referências de Nó são realizadas principalmente por meio da Associação de Localização na Metachain.
Petição 870190069340, de 22/07/2019, pág. 102/126
97/110
154. SISTEMA, de acordo com a reivindicação 144, caracterizado por, em relação à Digitação de Integridade de Dados (DIS), o Relatório de Conteúdo em Perigo ser um relatório abrangente que enumera a identidade dos dados que é reivindicada por estar em perigo de perda de integridade permanente, com referências externas para evidenciar quais indicam tal perigo é uma realidade relativa ao sistema em geral, em que tais referências externas são feitas por meio da Metachain de modo que as partes alternativas podem verificar estas reivindicações de perigos de integridade dos dados.
155. SISTEMA, de acordo com a reivindicação 144, caracterizado pelos Padrões de Migração de Dados com Estados Desejados entre a Integridade de Dados e Prestação de Conteúdo e a Rede BCHAIN, via Protocolo BCHAIN, tentar maximizar constantemente o nível de Integridade dos Dados e configuração Ideal para fornecimento rápido e compatível de conteúdo realizado considerando os recursos finitos disponíveis entre os nós da Rede BCHAIN, em que a Área de Semeadura de Conteúdo Inicial, Área de Integridade de Conteúdo representa Locações Ideais de Integridade, em que com a Área de Semeadura de Conteúdo Inicial, confirmaram as políticas de taxa de execução de nós de exploração que motivam os nós em um setor para memorizar conteúdo a partir de um bloco recém-explorado, em que a Área de Demanda de Alto Conteúdo é uma demanda de conteúdo por Localização Ideal de Serviço que é esperada por culminar em pacotes específicos da rede por meio dos quais o Algoritmo de Seleção de Cache (CSA) possibilitará a hospedagem de cache de conteúdo em áreas mais próximas à demanda para tal conteúdo que leva um alívio geral à rede uma vez que os pacotes de roteamento (CCR/CCF) precisam percorrer muito menos para
Petição 870190069340, de 22/07/2019, pág. 103/126
98/110 realizar a mesma transferência de dados e que leva a menor latência e velocidades de transferência maiores para consumidores de informações.
156. SISTEMA, de acordo com a reivindicação 1, caracterizado por, em relação à Lógica de Roteamento, os Nós assumirem diferentes papéis em uma distribuição desordenada de recursos, alguns acabam servindo Solicitação de Reivindicação de Conteúdos (CCRs) , alguns receber Atendimentos de Reivindicação de Conteúdo (CCFs), em que a Principal lógica de roteamento ocorrem em torno da criação referência e atualização de Via de Hop Basal Proposta (PBHP), em que a Descoberta de Via de Seção Otimizada (OSRD) é um sistema de memorização inteligente que detecta automaticamente vias eficientes durante toda a topologia de nó sem despender recursos significativos, em que dois aspectos principais do módulo são a Detecção de Nó de Ponta (END) e o Algoritmo Bumerangue, em que a sequência bumerangue é um método eficaz de determinação do ângulo e área da travessia de pacote ao aproveitar a distribuição desordenada de nós, por meio da qual as vias eficientes de pacote se tornam 'autoconscientes' , o que leva às vias rápidas otimizadas de informações ao longo da topologia do nó.
157. SISTEMA, de acordo com a reivindicação 156, caracterizado pela Lógica de Roteamento receber entrada do Armazenamento de cadeia personalizada (CS), que consiste em Metachain, Appchain e Microchain através do Módulo de Reconhecimento de cadeia personalizada (CRM), que se conecta com as cadeias personalizadas que foram anteriormente registradas pelo nó, por meio das quais o nó possui acesso criptográfico para ler, escrever e/ou capacidades
Petição 870190069340, de 22/07/2019, pág. 104/126
99/110 administrativas para tal função, em que este módulo informa o restante do Protocolo BCHAIN quando uma atualização foi detectada em uma seção da Appchain na Metachain ou um Simulador de Metachain da Microchain, em que ao receber uma Solicitação válida de Reivindicação de Conteúdo (CCR), o Fornecimento de Reivindicação de Conteúdo (CCD) produz e envia o Atendimento relevante de Reivindicação de Conteúdo (CCF) para atender à solicitação, em que ao receber um CCF validado, a Renderização de Reivindicação de Conteúdo (CCR) entrega o conteúdo de solicitação ao usuário por meio de um frontend como a Interface UBEC da Plataforma.
158. SISTEMA, de acordo com a reivindicação 157, sendo o CCR caracterizado por compreender Origem de Reivindicação, Plausibilidade de Localização de Conteúdo Percebido, Prova Criptográfica de Direito, Pacote Variável de trilho (TVS), Via de Hop Basal Proposto (PBHP), Identificação Exclusiva de Nó e Tipo Alvo, em que o Tipo Alvo consiste em Alvo Imediato que é o nó imediatamente procurado na próxima sequência de hop da via de jornada, Alvos Subsequentes que são uma lista de crescimento e encolhimento dinâmico de nós que são percebidos como a melhor via em curto prazo para facilitar uma jornada eficiente para o Alvo Final que é o nó de destino pretendido, que está esperando o conteúdo de entrega ou está entregando o próprio conteúdo, em que a Origem da Reivindicação inclui um bloco criptograficamente assinado que indica os detalhes de identificação do nó de origem que proveram a Reivindicação de Conteúdo, em que a Plausibilidade de Localização de conteúdo percebido é um conjunto dinamicamente variável que indica os aspectos primários de roteamento de hop de nó, em que a Prova Criptográfica de Direito contém um bloco
Petição 870190069340, de 22/07/2019, pág. 105/126
100/110 criptograficamente assinado de informações que indica que o nó de origem possui acesso a uma chave válida que pode acessar a Appchain/Microchain especificada.
159. SISTEMA, de acordo com a reivindicação 157, sendo o CCF caracterizado por compreender Origem de Conteúdo, Plausibilidade de Fornecimento de Conteúdo Percebido, Parte Codificada de Conteúdo, Pacote Variável de Trilho (TVS), Via de Hop Basal Proposta (PBHP), Identificação Exclusiva de Nó e Tipo Alvo, em que a Origem de Conteúdo inclui um bloco criptograficamente assinado de informações que indica os detalhes de identificação do nó de origem que prove o atendimento ao conteúdo, em que a Plausibilidade de Fornecimento de Conteúdo Percebido é um conjunto dinamicamente variável de variáveis que indica os aspectos primários de roteamento de hop de nó, em que a Parte Codificada de Conteúdo possui a informação solicitação que é atendida por um nó de cache que retorna uma Parte relevante de informação ao requerente de tal informação.
160. SISTEMA, de acordo com a reivindicação 156, caracterizado por, em relação ao Gerador de Hop Basal Proposto (PBHG), o Suplemento de Conscientização de Nó Local (LNR) substituir nós que estão no escopo do hop de LNT por nós que são comprovados por prover uma via de hop inicial confiável, em que o Alvo Final é o nó de destino pretendido que espera conteúdo de fornecimento ou está ele próprio fornecendo conteúdo, em que o Alvo Imediato é o nó que é imediatamente procurado na próxima sequência de hop da via de jornada, em que os Alvos Subsequentes é uma lista de nós de crescimento e encolhimento dinâmico que são percebidos por ser a melhor via de curto prazo para facilitar uma jornada eficiente para o
Petição 870190069340, de 22/07/2019, pág. 106/126
101/110
Alvo Final, em que os Alvo Finais Alternativos são nós propostos que oferecem funcionalidade similar como o Alvo Final, por meio do qual um nó portador pode trocar facilmente para um Alvo Final alternativo no caso de Alvo Final original ser inatingível, em que a Troca de Estabilidade de Nó (NSE) substitui os nós que são considerados inseguros com os nós que estão em ambientes estáveis/confiáveis.
161. SISTEMA, de acordo com a reivindicação 156, caracterizado por, em relação à Transmissão de Informações Enfileiradas, o Processamento de Evento Cruzado de Setor (SCEP) desativar um Pacote Variável de Trilho complete (TVS) em um CCR ou CCF que transfere para um novo setor e então delega um novo TVS para a jornada subsequente do pacote, em que a Percepção de Melhor Hop (BHP) provê a lógica primária para avanço de um CCR ou CCF para seus alvos imediatos e subsequentes para sua jornada subsequente para seu Alvo Final, em que o Rastreamento de Nó Local (LNT) armazena informações em relação a nós atualmente alocados nas proximidades locais, conforme definido pelo escopo de Pesquisa Estatística de Nó (NSS).
162. SISTEMA, de acordo com a reivindicação 156, caracterizado pelo Processador de Transmissão (BP) ser um estágio intermediário entre a lógica de roteamento de hop e a Porta de Comunicações (CG) e sinaliza criptograficamente as transações enviadas, bem como as ordena por ordem de chegada até os níveis congestionamento de hardware permitirem que mais transações sejam transmitidas, em que o Histórico de Hop Recente (RHH) é um cache temporário que armazena informações de cabeçalho de CCR e CCF, por meio das quais diversos algoritmos podem incorporar as implicações de tais entidades
Petição 870190069340, de 22/07/2019, pág. 107/126
102/110 em sua lógica, em que o Módulo de Gerenciamento de Histórico de Hop Recente (RHHMM) está onde os CCRs e CCFs recebidos são registrado no RHH para facilitar que diversos outros algoritmos se refiram a este cache de informações, em que assim que o sistema não considera mais que um evento de testemunho é 'recente', a totalidade é excluída do RHH.
163. SISTEMA, de acordo com a reivindicação 156, caracterizado por, em relação ao Avanço de Alvo Subsequente (STA), conforme o CCR ou CCF é processado através da Lógica de Roteamento, este módulo interpretar o campo de Alvos Subsequentes para produzir o próximo Alvo Imediato, em que este módulo verifica se quaisquer dos Alvos Subsequentes estão atualmente disponíveis para transmissão imediata e direta de informações, mesmo de que isso não fosse esperado pela Via de Hop Basal Proposta (PBHP), por meio da qual, se os movimentos desordenados de nós permitem uma potencial micro-otimização na sequência (um atalho), então este módulo a detectará e o levará para alterar o Alvo Imediato declarado, em que os Alvos Subsequentes são uma lista de nós de crescimento e encolhimento dinâmico que são percebidos como a melhor via de curto prazo para facilitar uma jornada eficiente para o Alvo Final, em que LNT armazena informações sobre os nós atualmente alocados nas proximidades locais, conforme definido pelo escopo da Pesquisa Estatística de Nó (NSS).
164. SISTEMA, de acordo com a reivindicação 156, caracterizado por, em relação ao Módulo de Reconhecimento de Cadeia personalizada (CRM), as Atualizações em tempo real conterem atualizações em tempo real da Metachain conforme o armazenamento de cadeia local é atualizado pelo CIM e quaisquer atualizações de Appchain são promovidas para CRM em tempo real
Petição 870190069340, de 22/07/2019, pág. 108/126
103/110 de modo que as CCRs apropriadas podem ser geradas, em que a Detecção de Recuperação de Appchain Devida (DARD) detecta diferenças pendentes entre as Atualizações de Appchains da Metachain atualizadas em tempo real e as versões localmente conhecidas das Appchains, por meio das quais, caso uma Appchain seja atualizada, as marcações de tempo diferentes instruirão este módulo a destacar que um CCR deve ser enviado para atingir tal informação.
165. SISTEMA, de acordo com a reivindicação 156, caracterizado pela Verificação de Desvio de Microchain (MBC) se iniciar com a Solicitação para Informações de Metachain e/ou e se encerrar com o Retorno dos pontos de acesso das informações de Metachain com a versão imitada pelo Microchip, em que a Política Codificada Estatística (SHP) provê critérios que são codificados no Protocolo BCHAIN, em que estes critérios são estáticos em oposição aos critérios baseados em estratégia dinâmica habituais devido a estes critérios serem usados para definir a própria estratégia.
166. SISTEMA, de acordo com a reivindicação 156, caracterizado pelo Processamento de Evento Cruzado de Setor (SCEP) incluir Pacote Variável de Trilho (TVS), Processo de Criação de TVS (TCP), Processo de Desativação de TVS (TDP), em que TCP cria e invoca uma gama totalmente nova de variáveis para popular um novo Pacote Variável de Trilho (TVS), em que isto inclui uma nova Interpretação de Implantação de Estratégia a partir da Adaptação Estratégica Dinâmica (DSA) e um registro de Hop em branco, em que a única variável reutilizada a partir de TVS antigo é o Código de Autorização Econômica (EAT), em que TDP é um Pacote Variável de Trilho (TVS) que deve ser substituído por um novo é processado pra propósitos de reunião
Petição 870190069340, de 22/07/2019, pág. 109/126
104/110 de inteligência derivada de dados, permitindo assim que o pagamento de uma Unidade de Trabalho de BCHAIN (BWU) seja processado para todos os nós que participaram da transferência do CCR ou CCF, conforme indicado do Registro de Hop.
167. SISTEMA, de acordo com a reivindicação 156, caracterizado por, em relação ao Processo de Criação de TVS (TCP) e Processo de Desativação de TVS (TDP) , TVS ser uma coleção de variáveis que são dinamicamente alteradas e mencionadas como CCR ou CCF, conforme atravessa um setor, em que o Mecanismo de Ajuste de Trabalho (WSM) provê pagamento para o trabalho realizado pelos nós autorizado e enviado para a seção de Economia de Infraestrutura da Metachain, em que o registro de Hop é uma lista criptograficamente segura de nós que participaram da transferência de um CCR ou CCF em um setor específico, em que o Registro de Hop é reinicializado durante o processo de desativação no TVS relevante que é recebido por um nó que não pertence a nenhum dos dois setores definidos na Identificação do Setor de Trilho, em que o Mecanismo de Preço de Setor (SPM) determina o preço da Unidade de Trabalho de BCHAIN (BWU) de transferência de informações por meio de hop de nó para um setor específico por informação mencionada que se acumulou na Demanda de Setor da Metachain.
168. SISTEMA, de acordo com a reivindicação 156, caracterizado por, em relação à Descoberta de Via de Setor Otimizado (OSRD), o Produtor de Ponte de via entre Setores (Inter-SRBP) ligar uma série de setores por meio de vias entre Setores eficientes, em que o Produtor de Ponte de via entre Setores (Intra-SRSP) produz um segmento de via proposta que visa prover uma via eficaz de fornecimento de conteúdo de uma ponta de um setor para outra, em que a Eleição de Via de
Petição 870190069340, de 22/07/2019, pág. 110/126
105/110
Roteamento em sua totalidade (WRPE) propõe vias eficientes entre Setores ao unir diversos Segmentos de Via, em que a Retenção de Segmento de Setor (SRSR) é uma base de dados que retém vias realizadas pelos Registros de Hop desativados e são adicionados diretamente quando um caso de nó desta base de dados apresenta um evento de desativação do TDP, ou quando os nós de outros setores anunciam a este nó sobre os Registros de Hop de desativação que receberam, em que uma Composição de Setor destaca o Segmento de Via IntraSetores (Intra-SRS) e Segmento de Via entre Setores (entre-SRS) e Setor, em que Intra-SRS é capaz de descobrir Vias Eficientes de Hop que abrangem uma jornada de ponta a ponta em um único setor, em que estas descobertas são realizadas pelo módulo Intra-SRSP, em que o módulo entre-SRS encontra pontos eficientes de sobreposição que permitem que diversos Segmentos de Via sejam ligados em ponte para formar eventualmente Vias de Setor Otimizado, que são armazenadas em mencionadas na Metachain.
169. SISTEMA, de acordo com a reivindicação 156, caracterizado por, em relação à Visão Geral de Entrelaçamento de Setor, Estágios de Entrada/Saída de Segmento de Via serem níveis preliminares de indicativo de complexidade de interação de nó de que todos os segmentos de via percorridos são reversíveis, em que esta camada primária de gerenciamento de nó é suficiente devido à suposição de eficiência de hop bidireccionalmente coigual, em que uma segunda camada de gerenciamento de nó é implantável para otimizar as percepções de algoritmo para considerar as nuances na interação de nó que levam a uma via que não perf eitamente reversível quanto à eficiência, por meio da qual a camada primária de dos estágios de entrada e saída de gerenciamento de nó são sinônimos entre
Petição 870190069340, de 22/07/2019, pág. 111/126
106/110 si, em que ter determinado a direção geral de um segmento de via por meio da Interseção de Largura do Setor, os módulos como entre-SRSP podem selecionar os Segmentos de Via mais beneficiárias considerando sua Via de Hop de Nível de Setor, em que a Interseção de Largura do Setor é onde o módulo RDOD mede a largura na qual dois setores se intersectam.
170. SISTEMA, de acordo com a reivindicação 156, caracterizado por, no Estágio de Detecção de Nó na Borda 1, Bolhas do Detector Popular, o modulo de Formação de Bolha de Detector (DBF) seleciona nós aleatórios na Área de Intersecção de Setor para se tornarem sementes para expansão das bolhas, que se disseminam uniformemente aos nós circundantes, em que o Estágio de Detecção de Nó na Borda 2, Saturação de Bolha do Detector, eventualmente as Bolhas não terão mais espaço para se expandir, ou mais tecnicamente não serão mais nós disponíveis para reivindicar uma jurisdição da bolha em quanto a bolha mantém um expansão de área superficial uniforme entre sua circunferência, em que no Estágio de Detecção de Nó da Borda 3, Eliminação da Maioria da Vizinhança, as bolhas superiores X são excluídas de acordo com a área de superfície por meio do módulo de Eliminação de Vizinhança de Bolha (BNE), em que X é definido de acordo com a Política Codificada Estatística (SHP), em que no Estágio de Detecção de Nó na Borda
4, Calibração de Direção, a orientação da direção de via ideal Intra-Setor é calculada por referência à Sequência Bumerangue algorítmica mencionada no módulo de Calibração de Direção de Percurso (TDC), em que no Estágio de Detecção de Nó na Borda
5, Dissecção de Largura de Secção, as coordenadas de Largura de Setor são calculadas pelo módulo de Dissecção de Largura de Setor (SWD) , em que a Largura de Setor é definida como a
Petição 870190069340, de 22/07/2019, pág. 112/126
107/110 distância mais longa possível entre quaisquer bolhas restantes, em que no Estágio de Detecção de Nó na Borda 6, Descoberta de Nó da Borda, a Dissecção de Largura do Setor (SWD) foi realizada após Calibração de Direção de Percurso (TDC) remover todas as bolhas de tamanho pequeno que poderíam ter agido como Nós da Borda falso positivos.
171. SISTEMA, de acordo com a reivindicação 156, caracterizado por, em relação à sequência de Camada de Migração de Dados Físicos (PDML), o Gerador de Ligação de Atrito (FLG) mencionar a categorização de nós em diferentes Suportes de Velocidade para gerar ligações entre os nós que representam um diferencial na velocidade de fuga de nó, em que a Estimativa de Zona de Atrito (FZE) menciona as Ligações de Atrito prérealizadas para definir um limite geográfico que é virtualmente conhecido ao nó como uma ferramenta logística para realizar a migração de dados físicos, em que o Uso de Migração de Dados Físicos (PDMU) concede aos dados em movimento a capacidade de fazer uso funcional das vias de migração física que foram construídas pela Construção de Via de Migração (MPC), em que a Construção de Via de Migração (MPC) menciona dados de travessia de via incrementai da Metachain para construir novas vias de migração física que estão em demanda.
172. SISTEMA, de acordo com a reivindicação 156, caracterizado por, de acordo com Estrangulamento de Tráfego de Nó nos dois BN no Ambiente Desordenado, Ambiente Desordenado ser definido por um estrangulamento em toda a largura de banda devido à baixa densidade dos nós na área, em que os mesmos dois BN no Ambiente Desordenado possuem um seta bidirecional que indica a Priorização de Sincronicidade de Metachain, em que dada a largura de banda limitada entre os dois nós de
Petição 870190069340, de 22/07/2019, pág. 113/126
108/110 estrangulamento, as informações são priorizadas, de acordo com o tipo de cadeia personalizada, em que os pacotes de Metachain são dados a prioridade mais elevada para manter a integridade e eficiência da Rede BCHAIN no geral, em que os pacotes de Appchain/Microchain secundários são priorizados de acordo com a taxa de pagamento provida pelo Código de Autorização Econômica (EAT) de transferência daqueles dados, em que o CCR ou CCF inaceitável leva à invocação do módulo de Ratificação de Erro de Via e isto possibilita aos Ambientes Desordenados serem rastreados e marcados na Metachain por meio da Potencialização de Potência e Congruência de Rede (NSCE), em que o Ambiente Desordenado Indica Fraqueza com Comunicações entre os nós - Rastreamento de Ambiente Desordenado a partir da Metachain destaca uma área geográfica em relação à Localização de nó, que possui uma baixa densidade de disponibilidade de nó ativo, por meio do qual o protocolo BCHAIN é capaz de evitar antecipadamente a ineficiência de roteamento de travessia de dados de um Ambiente Desordenado.
173. SISTEMA, de acordo com a reivindicação 156, caracterizado por, em relação ao Mecanismo de Preço de Setor (SPM) e Mecanismo de Acordo de Trabalho (WSM) , o modulo de Pagamento de Trabalho por Nó (NWP) interagir com a Metachain para enviar pagamento do trabalho aos nós que contribuíram para a transferência de CCR ou CCF, em que a Verificação de Saída Econômica Assinada (SEOV) verifica que o nó que está pagando pela transferência de informações autorizou o escopo do trabalho, em que os Nós se digitalizam para nós diagnósticos autodeclarados e comprovados em um setor.
174. SISTEMA, de acordo com a reivindicação 156, caracterizado por, em relação ao Pagamento de Trabalho por Nó
Petição 870190069340, de 22/07/2019, pág. 114/126
109/110 (NWP), módulo interagir com a Metachain para enviar o pagamento de trabalho aos nós que contribuíram na transferência de CCR ou CCF, em que a sequência se inicia com o rendimento percentual total de rede dos setores atuais provendo entrada para calcular o pagamento por hop/nó (cada nó realizado em um hop) com fórmula que envia as informações para Pagamento por e termina na Interface de Economia Direta.
175. SISTEMA, de acordo com a reivindicação 156, caracterizado pela Verificação de Saída Econômica Assinada (SEOV) verificar que o nó que está pagando pela transferência de informações autorizou o escopo do trabalho, em que o cálculo de divergência de via de Hop (HPDC) calcula a porcentagem na diferença entre o PBHP original conforme percebido pelo remetente e o PBHP atual que está sendo realizado por CCR ou CCF.
176. SISTEMA, de acordo com a reivindicação 156, caracterizado por, no Agrupamento de Variável de NSS (NVP), os nós de dentro dos mesmos setores anunciarem sua percepção da Pesquisa Estatística de Nó (NSS) Variáveis entre si para criar o consenso sobre as características do setor e as variáveis de NSS locais e remotas serem agrupadas para criar uma média composta, NVCI, em que a Implementação de Estratégia determina o Intervalo de Agrupamento de Variável de NSS sobre qual a frequência que os nós devem se anunciar.
177. SISTEMA, de acordo com a reivindicação 156, caracterizado por, em relação à sequência de Envio de CCF Implicado Jurisdicionalmente (JICS) e Recepção de CCF Jurisdicionalmente Aceita (JACR), o Acionamento de Evento de Sistema Genérico (GSET) ser uma rotina automatizada que invoca obrigações de outros nós de acordo com sua categoria de
Petição 870190069340, de 22/07/2019, pág. 115/126
110/110 jurisdição na Invocação de Categoria, que provê entrada para Criar prova criptográfica de origem ao usar Identificação Exclusiva de Nó no Envio de CCF Implicado Jurisdicionalmente (JICS), no qual os CCFs são enviados a um nó sem um CCR anexo devido àquela responsabilidade jurisdicionalmente implicada do nó de receber tal CCF, em que o Upload de Conteúdo ocorre através da Interface de Upload de Conteúdo Genérico (GCUI), que é um endpoint de entrada para o conteúdo a ser carregado por meio do Envio de CCF Implicado.
178. SISTEMA, de acordo com a reivindicação 156, caracterizado pela Participação de Chamada ao Vivo A iniciar uma proposta de chamada telefônica, que inclui um EAT, ao emitir CCR para o Participante B, em que EAT provê Opções de Pagamento Flexíveis, em que o Participante de Chamada ao Vivo B aceita a chamada e o Participante A verifica a aceitação do Participante B da chamada telefônica, em que a Appchain Aninhada que está executando exclusivamente para os Participantes A e B na Appchain de Chamada ao Vivo de UBEC utiliza o módulo de Procedimento de Interação de Transmissão ao Vivo de Appchain (ALIP), que serve um endpoint para conectar a programação de contrato inteligente de uma Appchain com a sessão de transmissão ao vivo por meio da qual uma Appchain pode iniciar, pausar ou destruir uma sessão de transmissão ao vivo com base em procedimentos automatizados e/ou entrada manual do usuário, em que a Appchain de Chamada ao Vivo de UBEC é uma estrutura de Appchain aninhada que provê as capacidades de transferência de informações para gerenciar e executar a chamada telefônica ao vivo, inclusive autenticação dos usuários, logísticas pagamento, políticas de iniciação.
BR112019015066-8A 2017-01-23 2018-01-23 Sistema de conexões universais de bchain todos/tudo/toda parte BR112019015066A2 (pt)

Applications Claiming Priority (15)

Application Number Priority Date Filing Date Title
US201762449313P 2017-01-23 2017-01-23
US62/449,313 2017-01-23
US201762464156P 2017-02-27 2017-02-27
US62/464,156 2017-02-27
US201762468202P 2017-03-07 2017-03-07
US62/468,202 2017-03-07
US201762489309P 2017-04-24 2017-04-24
US62/489,309 2017-04-24
US201762504057P 2017-05-10 2017-05-10
US62/504,057 2017-05-10
US201762530197P 2017-07-08 2017-07-08
US62/530,197 2017-07-08
US201762549714P 2017-08-24 2017-08-24
US62/549,714 2017-08-24
PCT/US2018/014874 WO2018136944A1 (en) 2017-01-23 2018-01-23 Universal bchain e3a connections (ubec)

Publications (1)

Publication Number Publication Date
BR112019015066A2 true BR112019015066A2 (pt) 2020-06-02

Family

ID=62908762

Family Applications (1)

Application Number Title Priority Date Filing Date
BR112019015066-8A BR112019015066A2 (pt) 2017-01-23 2018-01-23 Sistema de conexões universais de bchain todos/tudo/toda parte

Country Status (7)

Country Link
US (1) US20180285840A1 (pt)
KR (2) KR20240072271A (pt)
AU (2) AU2018210013A1 (pt)
BR (1) BR112019015066A2 (pt)
IL (2) IL268145B2 (pt)
SG (1) SG11201906695VA (pt)
WO (1) WO2018136944A1 (pt)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11368286B1 (en) * 2019-05-24 2022-06-21 Jiaping Wang Txilm: lossy block compression with salted short hashing

Families Citing this family (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
CN103793284B (zh) * 2012-10-29 2017-06-20 伊姆西公司 基于共同序列模式的、用于智能客户服务的分析系统和方法
US9794331B1 (en) * 2014-09-29 2017-10-17 Amazon Technologies, Inc. Block allocation based on server utilization
EP3257002B1 (en) * 2016-02-23 2020-03-11 Nchain Holdings Limited Agent-based turing complete transactions integrating feedback within a blockchain system
US10785022B2 (en) * 2016-09-13 2020-09-22 Hiroshi Watanabe Network without abuse of a private key
US10560268B2 (en) 2017-02-13 2020-02-11 International Business Machines Corporation Node characterization in a blockchain
US10135607B1 (en) 2017-08-11 2018-11-20 Dragonchain, Inc. Distributed ledger interaction systems and methods
US10268829B2 (en) * 2017-08-11 2019-04-23 Dragonchain, Inc. Security systems and methods based on cryptographic utility token inventory tenure
US10452466B1 (en) 2017-11-29 2019-10-22 Architecture Technology Corporation Automated system maintenance capabilities for a computing system
CN109064036B (zh) * 2018-08-08 2021-07-06 武汉大学 面向管理领域的生态系统服务供需指数变化检测方法
US10915521B2 (en) * 2018-08-21 2021-02-09 Syniverse Technologies, Llc Blockchain gateway device and associated method of use
US10783928B2 (en) * 2018-09-20 2020-09-22 Autochartis Limited Automated video generation from financial market analysis
CN109409878B (zh) * 2018-10-11 2021-09-14 上海保险交易所股份有限公司 经由双层联盟链进行交易的方法
US11308194B2 (en) * 2018-10-31 2022-04-19 Seagate Technology Llc Monitoring device components using distributed ledger
US11443317B2 (en) * 2018-12-19 2022-09-13 Salt Blockchain Inc. Tracing flow of tagged funds on a blockchain
US11875400B2 (en) * 2019-01-31 2024-01-16 Salesforce, Inc. Systems, methods, and apparatuses for dynamically assigning nodes to a group within blockchains based on transaction type and node intelligence using distributed ledger technology (DLT)
US11424643B2 (en) * 2019-02-22 2022-08-23 Johnson Controls Tyco IP Holdings LLP Building management system with energy optimization using blockchain
US11645620B2 (en) * 2019-03-15 2023-05-09 Tecnotree Technologies, Inc. Framework for explainability with recourse of black-box trained classifiers and assessment of fairness and robustness of black-box trained classifiers
US11032355B2 (en) * 2019-04-05 2021-06-08 International Business Machines Corporation Trustless notification service
US11093495B2 (en) * 2019-06-25 2021-08-17 International Business Machines Corporation SQL processing engine for blockchain ledger
US10547317B1 (en) * 2019-07-01 2020-01-28 Xilinx, Inc. Low latency receiver
US20210019838A1 (en) * 2019-07-18 2021-01-21 Che Sheng Kung Public object rechecking system and user interfaces thereof
CN110490079B (zh) * 2019-07-19 2022-06-03 万翼科技有限公司 巡检数据处理方法、装置、计算机设备和存储介质
CN110390524B (zh) * 2019-07-31 2021-10-26 中国工商银行股份有限公司 区块链中作业数据处理方法、装置、电子设备及存储介质
US11394627B1 (en) 2019-07-31 2022-07-19 Express Scripts Strategie Development, Inc. Systems and methods for monitoring inter-application communications in complex computing ecosystems
WO2021038568A2 (en) * 2019-08-28 2021-03-04 Rnkd Security & Systems Ltd Method for fraud prevention and tracking a communication path with smart contracts
US11218301B1 (en) 2019-09-10 2022-01-04 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography communications channels
US11552793B1 (en) 2019-09-10 2023-01-10 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography communications channels
US11218300B1 (en) 2019-09-10 2022-01-04 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography communications channels
US11403283B2 (en) 2019-10-15 2022-08-02 Sony Corporation Distributed ledger based generation of electronic documents
SG10201910109RA (en) 2019-10-30 2020-07-29 Accenture Global Solutions Ltd Leading-party-initiated cryptologic coordinated symmetric conditional key release
US11232441B2 (en) * 2019-10-30 2022-01-25 Accenture Global Solutions Limited Cryptologic coordinated symmetric conditional key release
US10873578B1 (en) * 2019-12-09 2020-12-22 Evan Chase Rose Biometric authentication, decentralized learning framework, and adaptive security protocols in distributed terminal network
US11356260B2 (en) 2020-01-26 2022-06-07 International Business Machines Corporation Decentralized secure data sharing
US11271742B2 (en) 2020-01-26 2022-03-08 International Business Machines Corporation Decentralized secure data sharing
US11088833B1 (en) * 2020-01-26 2021-08-10 International Business Machines Corporation Decentralized secure data sharing
CN111314336B (zh) * 2020-02-11 2021-03-23 中国科学院信息工程研究所 一种面向抗追踪网络的动态传输路径构建方法及系统
CN113810238A (zh) * 2020-06-12 2021-12-17 中兴通讯股份有限公司 网络监测方法、电子设备及存储介质
US11632237B2 (en) * 2020-08-28 2023-04-18 International Business Machines Corporation Configuration override in a blockchain network
CN113037918B (zh) * 2021-03-02 2022-06-17 四川速宝网络科技有限公司 Android客户端非入侵式变声方法
CN113360206A (zh) * 2021-05-31 2021-09-07 珠海大横琴科技发展有限公司 一种数据处理的方法和装置
US11556403B1 (en) 2021-10-19 2023-01-17 Bank Of America Corporation System and method for an application programming interface (API) service modification
CN114819481A (zh) * 2022-03-11 2022-07-29 国网浙江省电力有限公司绍兴供电公司 基于基础配电业务系统的一站式管理方法
US11748561B1 (en) * 2022-03-15 2023-09-05 My Job Matcher, Inc. Apparatus and methods for employment application assessment
CN114785526B (zh) * 2022-06-16 2022-09-02 德德市界(深圳)科技有限公司 基于区块链的多用户多批次权重分配计算及存储处理系统
CN115499135B (zh) * 2022-09-14 2024-04-12 山东大学 一种基于对称密码的环签名方法及系统
CN115357308B (zh) * 2022-10-21 2023-01-06 国网信息通信产业集团有限公司 基于Docker的边缘物联代理装置、系统及应用方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150379510A1 (en) * 2012-07-10 2015-12-31 Stanley Benjamin Smith Method and system to use a block chain infrastructure and Smart Contracts to monetize data transactions involving changes to data included into a data supply chain.
WO2015082016A1 (en) * 2013-12-06 2015-06-11 Huawei Technologies Co., Ltd. Method and controller for chaining applications in a software defined network
US9608829B2 (en) * 2014-07-25 2017-03-28 Blockchain Technologies Corporation System and method for creating a multi-branched blockchain with configurable protocol rules
WO2016063092A1 (en) * 2014-10-23 2016-04-28 Dele Atanda Intelligent personal information management system
GB2525701B (en) * 2015-01-08 2016-11-30 Openwave Mobility Inc A software defined network and a communication network comprising the same
US9967334B2 (en) * 2015-03-02 2018-05-08 Dell Products Lp Computing device configuration and management using a secure decentralized transaction ledger
US20170214701A1 (en) 2016-01-24 2017-07-27 Syed Kamran Hasan Computer security based on artificial intelligence

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11368286B1 (en) * 2019-05-24 2022-06-21 Jiaping Wang Txilm: lossy block compression with salted short hashing

Also Published As

Publication number Publication date
IL302367A (en) 2023-06-01
AU2018210013A1 (en) 2019-09-12
IL268145B2 (en) 2023-09-01
KR20190119054A (ko) 2019-10-21
IL268145A (en) 2019-09-26
IL268145B1 (en) 2023-05-01
KR20240072271A (ko) 2024-05-23
SG11201906695VA (en) 2019-08-27
US20180285840A1 (en) 2018-10-04
AU2022287674A1 (en) 2023-02-02
WO2018136944A1 (en) 2018-07-26

Similar Documents

Publication Publication Date Title
BR112019015066A2 (pt) Sistema de conexões universais de bchain todos/tudo/toda parte
Gupta et al. Smart contract privacy protection using AI in cyber-physical systems: tools, techniques and challenges
CN109313687B (zh) 基于人工智能的计算机安全
Xu et al. Sok: Decentralized exchanges (dex) with automated market maker (amm) protocols
JP7078705B2 (ja) セキュアで信頼性があるアイデンティティベースコンピューティングの方法及びシステム
US11727120B2 (en) Blockchain cybersecurity solutions
CA3071976C (en) Distributed ledger interaction systems and methods
Pasdar et al. Connect API with blockchain: A survey on blockchain oracle implementation
Cysneiros et al. Non-functional requirements orienting the development of socially responsible software
WO2024025863A1 (en) Systems and methods for providing process automation and artificial intelligence, market aggregation, and embedded marketplaces for a transactions platform
Harper The impact of consumer security awareness on adopting the internet of things: A correlational study
Islam et al. Distributed ledger technology based integrated healthcare solution for Bangladesh
US20210241149A1 (en) System to ensure safe artificial general intelligence via distributed ledger technology
Alaba et al. Smart Contracts Security Application and Challenges: A Review
Paul Official (ISC) 2 guide to the CSSLP CBK
Karpf Dead reckoning: where we stand on privacy and security controls for the Internet of Things
Moon et al. Conformance evaluation of the top‐100 Ethereum token smart contracts with Ethereum Request for Comment‐20 functional specifications
Leema et al. Fundamentals of Blockchain and Distributed Ledger Technology (DLT)
Leema Roselin et al. Fundamentals of Blockchain and Distributed Ledger Technology (DLT)
John Scheid An intent-based blockchain-agnostic interaction environment
Desai Using Public and Private Blockchains for Secure Data Sharing and Analytics
Tuzarová Potenciál technologie Blockchain pro zmírnění dopadů COVID-19 a budoucích pandemií
Florin Governing Cybersecurity Risks and Benefits of the Internet of Things: Connected Medical and Health Devices and Connected Vehicles
Anoop et al. Blockchain for Industry 4.0: Blockchain for Industry 4.0: Emergence, Challenges, and Opportunities
Kohen et al. Securing the Internet of Things with Object-Process Methodology Stereotypes

Legal Events

Date Code Title Description
B350 Update of information on the portal [chapter 15.35 patent gazette]