BRPI0520475B1 - método e sistema para gerar sinais de instrução arranjados em fluxos de trabalho, e, meio de armazenamento legível por computador - Google Patents

Abstract

método e sistema para gerar sinais de instrução arranjados em fluxos de trabalho, e, produto de programa de computador. um sistema para gerar sinais de instrução arranjados em fluxo de trabalho para executar intervenções em equipamentos de rede incluídos em uma rede de comunicação (n), em que os equipamentos estão associados a agentes de proxy de recurso (rp1, ..., rpn), cada um responsável por administrar um único equipamento na rede (n). o sistema inclui uma arquitetura distribuída de agentes de proxy de administração de intervenção (pp 1, ..., ppn) para gerar os sinais de instrução. os agentes de proxy de administração de intervenção (pp 1, ..., ppn) estão acoplados interativamente (ptp) com os agentes de proxy de recurso (rp1, ..., rpn), por meio de que os sinais de instrução são uma função do estado do equipamento em dita rede (n) na qual as intervenções são executadas.

Description

“MÉTODO E SISTEMA PARA GERAR SINAIS DE INSTRUÇÃO ARRANJADOS EM FLUXOS DE TRABALHO, E, MEIO DE ARMAZENAMENTO LEGÍVEL POR COMPUTADOR”

Campo da Invenção [001] A presente invenção relaciona-se a técnicas que habilitam geração de sinais de instrução organizados como fluxos de trabalho para executar intervenções em uma rede de comunicação.

[002] A invenção foi desenvolvida com atenção particular prestada a seu possível uso no contexto de plataformas distribuídas para administração e suporte à operação da mão-de-obra e dos clientes.

Descrição da Técnica Relacionada [003] Os custos dos processos operacionais, tais como os para prover novos serviços a clientes ou para remover falhas e defeito, representam uma porcentagem importante dos custos que as operadoras de telecomunicações devem enfrentar anualmente. Consequentemente, a importância de métodos/sistemas visados a reduzir ditos custos por ferramentas suportando atividades de ambos mão-de-obra de operadora e clientes, que por esse meio podem ser envolvidas diretamente em remover dificuldades relacionadas a equipamentos nas instalações de cliente.

[004] Suporte para a mão-de-obra e para o cliente, que está diretamente envolvido em ações de consertar falhas/defeitos, pode ser provido usando duas ferramentas principais: Sistemas de Administração de Conhecimento (KMs), ou em lugar disso Sistemas de Administração de Conhecimento Operacional (OKMs), e plataformas de administração avançadas, não vistas como entidades separadas, mas como componentes de uma solução integrada e completa.

[005] Por Administração de Conhecimento (KM) é significado a atividade que habilita criação, disseminação e uso do conhecimento de uma organização. Entre as várias abordagens para KM, companhias preferem geralmente a local, que focaliza na administração de uma parte do

Petição 870180145819, de 29/10/2018, pág. 12/82 / 49 conhecimento e em objetivos específicos (por exemplo, tomada de decisão, solução de problema, etc.). Administração de Conhecimento Operacional (OKM) é uma abordagem local à administração de conhecimento, focalizada na administração do conhecimento operacional. Este tipo de conhecimento inclui métodos e técnicas (práticas operacionais) necessárias para efetuar um trabalho particular ou uma atividade específica. Usuários típicos de uma OKM são engenheiros de campo de uma companhia e consultores de Centro de Chamada.

[006] Sistemas de KM/OKM representando o nível atual de desenvolvimento destas técnicas são descritos, por exemplo no documento US-A-2004/0044542 e no artigo por G. Valente e A. Rigallo: Remoter: an Operational Knowledge Management System for Telecommunication Operators, 'Workshop on Knowledge Management and Organizational Memories', 16^a Conferência Européia sobre Inteligência Artificial (ECAI), 2004.

[007] As soluções descritas nos documentos anteriores são propostas como ferramentas para suportar atividades de solução de problema como as que podem ser efetuadas pela mão-de-obra de uma operadora de telecomunicações (para lidar com reclamações de cliente ou cumprir pedidos de cliente de novos serviços) ou até mesmo pelo próprio cliente, envolvido diretamente em atividades de auto-atendimento em equipamentos nas suas instalações.

[008] Em particular, o documento US-A-2004/0044542 descreve um método e um sistema para capturar e compartilhar o conhecimento entre o pessoal técnico de uma dada companhia, entre dito pessoal e os usuários e entre os usuários e o pessoal técnico de outras companhias. Dito método e sistema podem ser aplicados a vários domínios, entre os quais também o domínio de serviços de telecomunicações, e provêm um suporte a atividades de solução de problema, usando abordagens de Raciocínio Baseado em Caso

Petição 870180145819, de 29/10/2018, pág. 13/82 / 49 e Raciocínio Baseado em Modelo.

[009] No artigo por Valente e Rigallo, ao invés, um sistema de Administração de Conhecimento Operacional (OKM,) chamado 'Remoter', é definido, dito sistema sendo usado em um contexto de telecomunicações para apoiar os técnicos de uma operadora de telecomunicações durante suas atividades diárias. Em particular, 'Remoter' foi usado e testado no contexto dos processos de Provisão e Garantia de serviços de ADSL, nos quais os técnicos devem reagir em um curto tempo e escolher a melhor solução. O propósito do sistema é habilitar os técnicos compartilharem, capturarem e aplicarem seu Conhecimento Operacional para tomar decisões ótimas em tempo real. Dito sistema usa a abordagem de Raciocínio Baseado em Caso Coloquial para suportar solução de problema.

[0010] O documento WO-A-2005/018249 descreve uma arquitetura de sistema baseada em um paradigma de agente e com um alto grau de flexibilidade e capacidade de expansão, para administração distribuída de uma rede de telecomunicações e dos serviços suportados. Os pontos chaves de dita arquitetura são:

- uma plataforma para administração de rede e serviço baseada em agentes distribuídos, associados a máquinas de fluxo de trabalho e máquinas de regras, e organizada em três níveis hierárquicos;

- Máquinas de Processo (máquinas de fluxo de trabalho e máquinas de regras) usadas não só para coordenação dos componentes (dos aplicativos), mas também para implementação flexível de todos os aspectos funcionais e de comportamento da plataforma;

- um inventário de modelo centralizado (Banco de Dados de Modelo - MDB) para a definição, armazenamento mestre (banco de dados mestre) e administração de todas as descrições de processo e modelos de informação de recursos de rede para ser distribuída ao longo da plataforma para uso dentro das Máquinas de Processo;

Petição 870180145819, de 29/10/2018, pág. 14/82 / 49

- uma camada de inventário de rede distribuída que desacopla a rede das funções de administração do OSS e provê um banco de dados alinhado em tempo real com a rede;

- uso de técnicas de mobilidade de código que habilitam uma distribuição conveniente de aplicativos, incluindo os aspectos de equilíbrio de carga e tolerância a falhas.

Objetivo e Sumário da Invenção [0011] O Requerente observou que os métodos usados nos sistemas descritos nos primeiros dois documentos previamente referenciados apresentam limites em termos de funções oferecidas, que derivam de três desvantagens.

[0012] Em primeiro lugar, eles não provêm uma interação direta com os sistemas/plataformas responsáveis por administração de rede e serviço, que habilitaria uma redução significante nos tempos de execução de atividades de solução de problema explorando as vantagens relacionadas por exemplo à verificação em tempo real da execução correta dos trabalhos pelo pessoal técnico, provisão proativa dos dados de rede precisados, e execução automática de comandos padrão na rede.

[0013] Em segundo lugar, eles não representam o conhecimento a ser compartilhado usando ferramentas formais (tais como os fluxos de trabalho) que habilitariam uma redução nos tempos de trabalho dos técnicos por uma descrição não ambígua e prontamente compreensível das atividades a serem efetuadas. Tal representação formal também evitaria qualquer possível dificuldade de interpretação ou qualquer má interpretação, pelos técnicos, das indicações providas, que pode conduzir à execução de atividades que são inúteis ou até mesmo prejudiciais para a rede na qual eles estão operando.

[0014] Finalmente, os sistemas em questão não guiam o pessoal técnico de um modo completo, integrado e exaustivo, por todas as etapas a serem seguidas para executar atividades de solução de problema: eles provêm

Petição 870180145819, de 29/10/2018, pág. 15/82 / 49 sugestões pontuais de atividades individuais a serem executadas ou de documentos específicos a serem consultados, derivado usando métodos tais como Raciocínio Baseado em Caso Coloquial. Um guia completo habilitaria ambas uma redução nos tempos de trabalho para os técnicos e uma inserção mais rápida de técnicos que são novos ao trabalho.

[0015] Igualmente, na estrutura de sistemas/plataformas para a administração de rede/serviço, soluções avançadas estão disponíveis, que idealizam arquiteturas distribuídas baseadas em agente.

[0016] Nesse respeito, a arquitetura descrita no terceiro documento referido acima é extremamente efetiva e eficiente em gerenciamento de rede, mas não idealiza qualquer função de KM/OKM para suportar atividades da mão-de-obra de uma operadora de telecomunicações.

[0017] Consequentemente, claramente emerge a necessidade para ter soluções inovadoras disponíveis que, superando as desvantagens inerentes esboçadas no antecedente, apresentam algumas características funcionais importantes.

[0018] Uma primeira destas características é a possibilidade de interação automática e ajudada com os sistemas/plataformas responsáveis pela administração de rede/serviço, o propósito disto sendo habilitar:

- verificação em tempo real, na rede/serviços administrados, da execução correta das sugestões providas, retornando uma realimentação imediata ao usuário do sistema;

- provisão automática, sincronizada com as atividades executadas, dos dados (dados de configuração, dados de medição, etc.) requeridos para proceder com ditas atividades;

- execução automática das etapas, consideradas padrão, da atividade de um engenheiro/operador de campo: por exemplo, configuração de uma placa de rede de acordo com parâmetros predefinidos, para eliminar qualquer possibilidade de erro e reduzir os tempos envolvidos.

Petição 870180145819, de 29/10/2018, pág. 16/82 / 49 [0019] Uma segunda característica desejável é que as sugestões providas à mão-de-obra deveriam ser representadas por ferramentas formais (tais como fluxos de trabalho) que têm as vantagens seguintes:

- descrição das atividades a serem executadas a fim de efetuar com êxito uma dada intervenção ou lidar efetivamente com um pedido de cliente, de um modo não ambíguo e prontamente compreensível;

- realce imediato (por exemplo, por meio de contagens apropriadas) das Melhores Práticas; e

- habilitação de uma administração mais simples do conhecimento com respeito às atividades de avanço e atualização possivelmente também por mecanismos automáticos.

[0020] Ainda uma característica importante certamente desejável adicional é que o sistema deveria ser capaz de indicar autonomamente e completamente todas as etapas específicas requeridas para efetuar uma dada intervenção (engenheiros de campo) ou para responder a um dado pedido de cliente (consultores de Centro de Chamada): eles provêm sugestões pontuais de atividades individuais a serem executadas ou de documentos específicos a serem consultados, derivados usando métodos tal como Raciocínio Baseado em Caso Coloquial.

[0021] Pode ser notado especificamente que as presentes plataformas de administração, embora na vanguarda com respeito a aspectos de administração, não oferecem ferramentas adequadas para apoiar a mão-deobra, que ainda é confiada com efetuar etapas importantes dos processos Empresariais de uma companhia, e não estão integradas com sistemas de OKM.

[0022] É consequentemente sentida a necessidade de ter soluções disponíveis capazes de superar estas limitações. Especificamente, é sentida a necessidade de ter disponível uma solução completa para apoiar a mão-deobra que, a partir de avançadas arquiteturas de administração flexíveis e

Petição 870180145819, de 29/10/2018, pág. 17/82 / 49 expansíveis avançadas, introduzirá funções de OKM inovadoras, baseado em uma representação formal das práticas operacionais, e assegurará uma integração entre operação e administração de rede/serviço.

[0023] O objetivo da invenção é assim prover uma resposta completamente satisfatória às necessidades anteriores.

[0024] O Requerente achou que o objetivo anterior é alcançado provendo uma arquitetura distribuída de agentes de proxy de administração de intervenção associada aos dispositivos terminais de operador respectivo ou usuário respectivos, ditos agentes de proxy de administração de intervenção sendo configurados para interagir com agentes de Proxy de Recurso associados com equipamentos de rede para gerar sinais de instrução (na forma de fluxos de trabalho) para executar intervenções nos equipamentos de rede, por meio de que os sinais de instrução são uma função do estado dos equipamentos de rede requerendo a intervenção.

[0025] A invenção também se relaciona a um produto de programa de computador correspondente, carregável na memória de pelo menos um computador e incluindo porções de código de software para executar aa etapas do método da invenção quando o produto é corrido em um computador. Como usado aqui, referência a um tal produto de programa de computador é compreendida como sendo equivalente à referência a um meio legível por computador contendo instruções para controlar um sistema de computador para o propósito de coordenar a execução do método de acordo com a invenção. Referência a pelo menos um computador é pretendido realçar a possibilidade para a presente invenção ser implementada de um modo distribuído e/ou modular. As reivindicações formam uma parte integral da exposição da invenção provida aqui.

[0026] Uma concretização preferida da solução descrita aqui é assim um método para gerar sinais de instrução arranjados em fluxos de trabalho para executar intervenções em equipamentos de rede incluídos em uma rede de

Petição 870180145819, de 29/10/2018, pág. 18/82 / 49 comunicação em que ditos equipamentos estão associados a agentes de Proxy de Recurso, cada um responsável por administrar um único equipamento em dita rede, o método incluindo aa etapas de:

prover uma arquitetura distribuída de agentes de proxy de administração de intervenção; e gerar ditos sinais de instrução por ditos agentes de proxy de administração de intervenção de uma maneira interativa com ditos agentes de Proxy de Recurso, por meio de que ditos sinais de instrução são uma função do estado do equipamento em dita rede na qual ditas intervenções são executadas.

Breve Descrição dos Desenhos Anexos [0027] A invenção será descrita agora, puramente por meio de exemplo, com referência aos desenhos, em que:

Figura 1 é um diagrama de bloco funcional ilustrando uma possível concretização de uma plataforma como descrita aqui;

Figura 2 é outro diagrama de bloco funcional representando administração de operação dentro da plataforma da Figura 1;

Figura 3 é um fluxograma de um primeiro procedimento executado dentro da solução descrita aqui;

Figura 4 é um exemplo de um fluxo de trabalho como gerado pela solução descrita aqui; e

Figuras 5 a 7 são fluxogramas de procedimentos adicionais executados dentro da solução descrita aqui.

Descrição Detalhada de Concretizações Preferidas da Invenção [0028] A fim de facilitar entendimento correto dos princípios subjacentes à invenção, um glossário é apresentado aqui com explicação de alguns termos/acrônimos usados nesta exposição e nas reivindicações anexas. [0029] WFM (Administração de Mão-de-obra): no contexto de uma operadora de telecomunicações, este é o aplicativo de software/conjuntos de

Petição 870180145819, de 29/10/2018, pág. 19/82 / 49 aplicativos de software responsáveis por administrar a mão-de-obra de dita operadora. No contexto específico de interesse, é compreendido como sendo o aplicativo/conjuntos de aplicativos usados para administrar ambas a mão-deobra móvel (engenheiros de campo) e a mão-de-obra de Centro de Chamada. [0030] Operador: este é um membro do pessoal de companhia fazendo parte da mão-de-obra, compreendido como mão-de-obra móvel (engenheiros de campo), como mão-de-obra especializada (pessoal de retaguarda) e como consultores de Centro de Chamada.

[0031] Módulo de Administrador - MM: este é um aplicativo de software correndo em um hospedeiro que se comunica com os agentes distribuídos para várias atividades de coordenação, tais como distribuição de descrições de fluxo de trabalho, chamada dos agentes distribuídos para invocar uma operação, controles administrativos, etc.; pode incluir uma Interface Gráfica de Usuário (GUI) apropriada e especializada.

[0032] Agente: este é um processo autônomo com possível estado persistente e requerendo comunicação (por exemplo, em um modo colaborador e/ou competitivo) com outros agentes a fim de cumprir suas tarefas. Esta comunicação pode ser implementada por troca de mensagem assíncrona e usando linguagens bem conhecidas (por exemplo, a Linguagem de Comunicação de Agente - ACL) com uma semântica bem definida e comumente concordada.

[0033] Proxy: este é um componente (agente) por qual é possível controlar ou intervir em outro objeto administrado, por exemplo um equipamento de rede ou uma GUI no contexto de suporte para operação.

[0034] Máquina de Regras: este é um sistema para separar regras de processo (logicamente e/ou fisicamente) da lógica de controle e compartilhálas por armazenamentos de dados, interfaces de usuário e aplicativos. Uma máquina de regras é basicamente um intérprete de declaração de se/então muito sofisticado. Uma máquina de regras é usada para decidir, durante

Petição 870180145819, de 29/10/2018, pág. 20/82 / 49 processamento, quais regras aplicar e como estas são para serem executadas. [0035] Fluxo de trabalho: isto pode ser definido como a automatização parcial ou completa de um processo, onde documentos, informação ou tarefas são passadas de um participante para outro, de acordo com um jogo de regras processuais. Um fluxo de trabalho pode ser representado por um fluxograma com uma sequência de tarefas e dependências temporais e lógicas, entre tarefas incluindo ramais paralelos ou alternativos. Há linguagens ad hoc, tal como XPDL (Linguagem de Descrição de Processo de XML), que habilitam descrição formal dos fluxos de trabalho.

[0036] Máquina de Fluxo de trabalho: este é o componente que possui toda a informação relacionada aos procedimentos (fluxos de trabalho), etapas em um procedimento e as regras para cada etapa. A máquina de fluxo de trabalho determina se o processo está pronto para se mover à próxima etapa. Em outras palavras, uma máquina de fluxo de trabalho é um componente para executar fluxos de trabalho.

[0037] O diagrama de bloco da Figura 1 representa uma concretização preferida de uma plataforma que é uma evolução da plataforma para administração distribuída de uma rede de telecomunicações e serviços relacionados, descrita em WO-A-2005/018249.

[0038] A arquitetura ilustrada (que define, em suas camadas mais altas, um Sistema de Suporte de Operações (OSS)) interage com três entidades básicas incluindo outros Sistemas de Suporte de Operações (OSSs), Sistemas de Suporte Empresarial (BSSs), e um sistema de Administração de Mão-deobra (WFM) (ou possivelmente mais de um WFM). Até onde os aspectos de administração estão envolvidos, os OSSs e os BSSs interagem por um barramento (BARRAMENTO - por exemplo, o barramento TIBCO) com o Aplicativo Mestre, designado por MA1. Este aplicativo administra a distribuição de processos e modelos de dados relacionados, armazenados no Banco de Dados de Modelo (MDB), para os vários Aplicativos de Agente, um

Petição 870180145819, de 29/10/2018, pág. 21/82 / 49 dos quais é mostrado e designado por AA1, e Agentes de Proxy de Recurso RP1, ..., RPn. Cada Aplicativo de Agente se confia em um ou mais Agentes de Proxy de Recurso RP1, ..., RPn que conectam com uma rede de comunicação N por Adaptadores de Protocolo PAs. O Inventário de Rede NI corresponde ao conceito habitual de um componente de inventário de rede e são as coleções de todas as visualizações (imagens) do recurso na rede N; é atualizado periodicamente recuperando informação dos RPs. Detalhes adicionais relativos a esta solução ou arquitetura conhecida podem ser derivados de WO-A-2005/018249.

[0039] Quando comparada à plataforma básica anterior conhecida, os novos elementos introduzidos na Figura 1 e apresentados em maior detalhe na Figura 2 são um Administrador Operacional OM, que conecta com o barramento e coopera com um Banco de Dados de Operação ODB, um Banco de Dados de Desempenho PDB, um Inventário de Perícia EI e um Arquivo de Registro de Operação OL. O Administrador Operacional OM supervisiona a operação de Agentes Operacionais OA1, ..., OAK. Cada Agente Operacional se confia em uma ou mais Proxies Pessoais PP1, ..., PPn que se conectam com uma pluralidade de Equipes Virtuais VT1, ..., VTn por Interfaces Pessoais PIs. Cada VT é composto de, por exemplo, engenheiros de campo, pessoal de retaguarda, consultores de Centro de Chamada, ou clientes.

[0040] As Proxies Pessoais - PP1, PP2, ..., PPn cada uma das quais está equipada com uma Interface Pessoal PI, estão conectadas à camada hierárquica superior da arquitetura que inclui tanto um conjunto de Agentes Operacionais OA1, OA2, ..., OAK ou diretamente um Administrador Operacional OM. No caso que os OAs estão presentes, estes são, por sua vez, conectados à camada hierárquica superior que inclui o OM. Esta arquitetura em camadas assegura flexibilidade e capacidade de expansão das funções, como descrito no que segue.

[0041] Os PPs também estão conectados um ao outro, e às Proxies de

Petição 870180145819, de 29/10/2018, pág. 22/82 / 49

Recurso RPs, como indicado esquematicamente pela seta de duas cabeças PTP na Figura 1. Isto representa tipicamente uma relação de ponto a ponto entre as Proxies Pessoais e as Proxies de Recurso. Esta relação habilita a possibilidade para a arquitetura aqui descrita de gerar sinais de instrução pelas proxies de administração de intervenção (isto é, as Proxies Pessoais) de uma maneira interativa com as Proxies de Recurso, de forma que estes sinais de instrução dependam do estado do equipamento no qual uma intervenção é executada. Pessoas qualificadas no setor apreciarão prontamente que referência à possível presença de n Proxies de Recurso RP1 a RPn, n Proxies Pessoais PP1 a PPn, e n Equipes Virtuais é completamente puramente indicativa, visto que cada uma destas entidades pode estar concebivelmente presente em qualquer número.

[0042] Cada RP é responsável pela criação, manutenção e administração da denominada imagem de um equipamento individual (localizado na rede ou nas instalações do cliente). A imagem é uma representação da configuração do equipamento de acordo com um modelo de dados definido.

[0043] Cada Agente Operacional OA1, ..., OAk coordena um conjunto de Proxies Pessoais; os Agentes Operacionais OA1, ..., OAk podem interagir entre si, como também com as Proxies Pessoais e o Administrador Operacional OM.

[0044] Cada agente correndo em hospedeiro (isto é, cada agente para a administração de rede/serviço e cada novo agente tais como Proxies Pessoais, Agentes Operacionais e Administrador Operacional) preferivelmente inclui um ou mais Agentes de Controle CÃS, que são os módulos de software responsáveis por controlar e administrar a plataforma.

[0045] Como foi visto, a plataforma também inclui um conjunto de DBs em suporte das atividades executadas pelos vários componentes. O Banco de dados Operacional ODB é o único ponto (lógico) de definição e armazenamento de todos os aspectos funcionais e os aspectos de

Petição 870180145819, de 29/10/2018, pág. 23/82 / 49 administração/suporte de mão-de-obra e clientes, relacionado à plataforma. O ODB é o repositório das descrições de processo (em que uma descrição de processo é tanto um fluxo de trabalho ou uma regra) e das definições de modelo de dados que são usadas pelos componentes da plataforma para administrar a operação (PP, OA e OM).

[0046] Um Módulo de Administrador MM, pelos Agentes de Controle CA, distribui as definições de processo e as definições de modelo de dados aos componentes de administração de operação. Em primeiro lugar, isto habilita as práticas operacionais mais eficientes e efetivas (Melhor Prática) serem feitas disponíveis à mão-de-obra inteira e aos clientes. Além disso, por um espalhamento das definições de modelo de dados, coordenação entre os membros da mão-de-obra é habilitada, assim permitindo identificação simples e rápida de peritos a serem referidos para obter suporte sobre um assunto específico. Associada ao Banco de Dados ODB está uma GUI provida propositalmente que habilitará seu povoamento.

[0047] O Banco de Dados de Modelo MDB armazena todas as descrições de processo (fluxos de trabalho e regras) e os modelos dos dados processados (incluindo os modelos do equipamento de rede), que são usados pelos componentes da plataforma para administração de rede/serviço (RPs, AAs e MA como mostrado na Figura 1).

[0048] Este elemento provê os usuários com um único ponto no qual definir e administrar as funções da plataforma com relação aos aspectos de administração de rede/serviço.

[0049] Em uma concretização preferida, a fim de definir os modelos de dados armazenados nos bancos de dados ODB e MDB, o modelo de SID (modelo de Dados de Informação Compartilhada, conjunto de documentos do TeleManagementForum GB922 versão 4.0, agosto de 2004 e versão 4.5 em Avaliação de Membro - dezembro de 2004) é usado.

[0050] O Banco de dados de Desempenho PDB é um único ponto

Petição 870180145819, de 29/10/2018, pág. 24/82 / 49 (lógico) de armazenamento de todos os dados de desempenho relacionados aos componentes de plataforma e é usado ambos para otimizar o uso de recursos e identificar a Melhor Prática.

[0051] Finalmente, também presente na plataforma estão: o Registro Operacional, que é um único ponto (lógico) de armazenamento de todos os registros das atividades executadas pelos operadores e pelos clientes; e o Inventário de Perícia EI, que contém os dados dos perfis de operador e dos perfis de cliente administrados pelos vários PPs.

[0052] Os processos operacionais da plataforma são segmentados em três camadas com funções específicas. Esta escolha é pretendida para cumprir duas necessidades: manter o número de camadas tão baixo quanto possível (assim evitando a complexidade de arquiteturas convencionais), e permitir alocação livre de processos entre uma modalidade distribuída e uma centralizada. Isto implica na presença de uma camada centralizada 1 (que corresponde ao Administrador Operacional OM) e uma camada 2 completamente distribuída (que corresponde aos Agentes Operacionais OA1, ..., OAk) mais uma camada de proxy independente 3 (que corresponde às Proxies Pessoais PPs) que desacopla a operação das funções de administração e controle. Esta segmentação também provê visões de serviço diferentes, por exemplo uma visão de produto para o cliente final na camada 1, uma visão de serviço na camada 2 e uma visão operacional na camada 3. Como será explicado mais tarde, os componentes PP, OA, OM são adaptados para executar funções respectivas baseado em informação de instrução respectiva provida a eles, qual informação inclui definições de processo, tais como fluxos de trabalho ou regras, ou definições de modelos de dados.

[0053] Cada Proxy Pessoal PP (no que segue, por razão de brevidade, nós evitaremos repetir cada vez que a sequência de sufixos 1 a N por exemplo em PP1, ..., PPn, e uma abordagem semelhante também será adotada com referência às outras entidades presentes em uma múltipla forma nos

Petição 870180145819, de 29/10/2018, pág. 25/82 / 49 diagramas das Figuras 1 e 2) é responsável por suportar as atividades de um operador específico ou de um cliente específico, em termos ambos de guia nas várias atividades operacionais e de suporte para a cooperação (entre operadores diferentes ou entre operadores e cliente). Em particular, suporte para cooperação é baseado nos perfis de operador e nos perfis de cliente, estes perfis sendo representados no modelo de dados. Processamento dos perfis com os dados reais e atualizados é efetuado pelo Administrador Operacional OM com a informação vindo de sistemas de WFM externos, no caso de perfis de operador, ou de Sistemas de Suporte Empresarial, no caso de perfis de cliente, e é comunicado à Proxy Pessoal.

[0054] Em outras palavras, cada Proxy Pessoal desempenha o papel de um agente de proxy de administração de intervenção. Cada Proxy Pessoal (PP) executa processos típicos do nível de PP correspondente usando uma Máquina de Processo PE: estes processos são referidos como sendo processos de camada 3 e podem ser estruturados em subcamadas (por exemplo, para a definição de macro-operações). Os processos na camada de topo de camada 3 constituem os serviços que o PP oferece à camada superior (Agente Operacional e possíveis outros aplicativos externos) por invocação de ditos processos. Eles representam as operações que correspondem a uma única atividade executada pelo operador/cliente ao qual o PP está associado. Consequentemente, o termo, já previamente introduzido, de agente de proxy de 'administração de intervenção'.

[0055] Exemplos de serviços (e consequentemente de intervenções) providos por uma Proxy Pessoal são: executar uma conexão cruzada, instalar e configurar um modem, consertar uma falha de um equipamento (roteador, DSLAM, etc.), etc.; cada um destes pode incluir sequências de atividades a serem executadas em um ou mais equipamentos. Os processos na camada de fundo de camada 3 usam os serviços oferecidos pelas Interfaces Pessoais PIs.

[0056] Os perfis de operador e perfis de cliente administrados por uma

Petição 870180145819, de 29/10/2018, pág. 26/82 / 49

Proxy Pessoal PP são representados no modelo de dados. Este modelo, definido por meio de uma GUI provida propositalmente, é armazenado no banco de dados ODB e é distribuído pelo Módulo de Administrador MM, pelos Agentes de Controle CA, às Proxies Pessoais PPs, que o carregam e o processam com os valores enviados pelo Administrador Operacional OM e adquiridos por sistemas externos (WFM e BSS). Novamente, o processamento é executado de um modo flexível usando uma Máquina de Proxy PE. Desta maneira, mudanças e adições de modelos de dados (tal como atualização do perfil de operador/cliente, introdução de novos tipos de operador, etc.) não requerem qualquer mudança de software apreciável nos componentes da plataforma, alcançando um alto grau de flexibilidade.

[0057] Os dados dos perfis de operador e dos perfis de cliente são armazenados no Inventário de Perícia EI, que é atualizado periodicamente pelo OM usando informação adquirida de sistemas externos (sistemas de WFM para perfil de operador e sistemas de suporte empresariais para perfil de cliente). Como dito antes, as mudanças nos dados de perfil também são comunicadas às Proxies Pessoais PPs interessadas.

[0058] Os operadores podem consequentemente ser agrupados logicamente em Equipes Virtuais VT1, ..., VTn: uma Equipe Virtual inclui um conjunto de operadores que compartilham um dado conhecimento e/ou que trabalha em problemas comuns., As Equipes Virtuais podem, em geral, serem organizadas baseado em uma subdivisão geográfica da mão-de-obra a fim de melhorar a eficiência da solução de problema e otimizar as intervenções de campo.

[0059] As Proxies Pessoais PPs podem interagir diretamente entre si para prover suporte para cooperação entre operadores ou entre operadores e cliente, por exemplo, para consertar uma falha complicada. As Proxies Pessoais PPs também estão em comunicação com as Proxies de Recurso RPs associadas aos recursos de rede diferentes; consequentemente, os PPs podem

Petição 870180145819, de 29/10/2018, pág. 27/82 / 49 interagir com RPs para emitir comandos, juntar dados de configuração, resultados de medições ou resultados de verificações de execução bem sucedida, no equipamento, de algumas dadas ações pelo operador/cliente, e fazer disponível um acesso remoto para possíveis interfaces de linha de comando. As Interfaces Pessoais PI são ao invés responsáveis por administração da GUI para todos os operadores (membros da mão-de-obra) ou clientes, qualquer que seja o tipo de dispositivo terminal que eles usem para suportar suas atividades de trabalho (PDAs, laptops, computadores de mesa, etc.). Cada PI oferece, como serviços para as Proxies Pessoais, administração da GUI para o operador/cliente, incluindo a configuração automática da GUI baseado no tipo de dispositivo disponível.

[0060] Cada Agente Operacional OA é responsável por coordenação de um conjunto de PPs e para execução de processos típico de camada 2 usando uma Máquina de Proxy. Estes processos estão relacionados à execução distribuída de intervenções operacionais e podem ser estruturados em subcamadas. Os processos na camada de topo de camada 2 podem ser invocados externamente; assim, estes são os serviços oferecidos pelo Agente Operacional OA ao Administrador Operacional OM ou outros sistemas externos. Os processos na camada de fundo da camada 2 usam os serviços (quer dizer, eles invocam processos) oferecidos pela Proxy Pessoal PP.

[0061] Um Agente Operacional OA não requer atualização de software para suportar novas práticas operacionais. Isto é devido à flexibilidade dos processos que são recebidos do Módulo de Administração MM, pelo CA, carregados e executados pela camada de OA. Os Agentes Operacionais OAs podem interagir por um Protocolo de Comunidade (um mecanismo intertrabalho baseado na troca de mensagens) para suportar a execução distribuída de atividades operacionais correlatadas entre si, tal como, por exemplo, a criação de um circuito que envolve equipamento localizado em locais geograficamente distribuídos.

Petição 870180145819, de 29/10/2018, pág. 28/82 / 49 [0062] O Administrador Operacional OM é responsável por coordenação de primeiro nível da execução dos processos típicos de um nível de administração. Os processos de camada 1 podem ser estruturados em subcamadas e são caracterizados para prover funções que requerem interação com entidades externas à plataforma (por exemplo, sistemas de WFM ou Sistemas de Suporte Empresarial) e/ou coordenação entre Agentes Operacionais OAs, que não podem ser alcançados de um modo fácil ou efetivo apenas pelos Agentes Operacionais OAs. A grande flexibilidade da arquitetura também habilita evolução suave; por exemplo, um avanço do protocolo de comunidade pode habilitar migração de um processo de camada 1 para camada 2.

[0063] As Máquinas de Processo PE para qualquer camada são pretendidas serem uma máquina de fluxo de trabalho (isto é, um fluxograma), uma máquina de regras ou uma combinação das duas. Por exemplo, funções de suporte relacionadas a uma intervenção de campo de um operador são representadas melhor como um fluxograma enquanto funções para suportar diagnose em uma base de reclamação, no contexto de um Centro de Chamada, são representadas melhor por um conjunto de regras. Sempre que possível e aconselhável, o uso de fluxos de trabalho é preferido como evita a complexidade de lidar com conflitos de regras e administração de regras.

[0064] As Máquinas de Processo são preferivelmente usadas por todo componente da plataforma e, se possível, elas são para serem alocadas no mesmo hospedeiro no qual o próprio componente reside a fim de melhorar os níveis de desempenho: o Administrador Operacional OM, os Agentes Operacionais OAs e as Proxies Pessoais PPs apresentam um comportamento que é ambos reativo e proativo, reagindo a eventos, mas também iniciando espontaneamente processos.

[0065] Os Agentes de Controle CAs são responsáveis pela distribuição do fluxos de trabalho e dos modelos de dados nos vários agentes da

Petição 870180145819, de 29/10/2018, pág. 29/82 / 49 plataforma, para a medição do uso dos recursos e desempenho dos agentes locais (isto é, os que são executados no hospedeiro), e, finalmente, para a otimização local da administração de recurso. As medições são enviadas ao Módulo de Administrador MM e para outros Agentes de Controle CAs.

[0066] A mobilidade entre hospedeiros, administrada pelo Módulo de Administrador MM ou por um Controle Agente CA dos Agentes Operacionais OAs e das Proxies Pessoais PPs faz os procedimentos de desenvolvimento, balanceamento de carga e tolerância a falhas mais eficiente e automático. Se agente por qualquer razão desativar, a solução pode ser clonar ou mover o agente para outro hospedeiro corrente. O Módulo de Administrador MM, pelo Controle Agente CA, controla periodicamente o estado operacional dos Agentes Operacionais OAs e das Proxies Pessoais PPs para ditos propósitos. A fim de monitorar desempenho, os componentes da plataforma devem ser capazes de monitorar também execução dos vários processos. No caso da Proxy Pessoal PP, monitoração da execução dos vários processos também é útil em uma perspectiva de identificação de Melhor Prática.

[0067] Como já foi dito, a solução descrita aqui é visada para administrar e suportar a operação da mão-de-obra e do cliente. Isto é obtido por um conjunto de serviços feitos disponíveis aos operadores/clientes.

[0068] Com referência à estrutura de eTOM (documentos: TeleManagementForum GB921 e GB921D, versão 4.0, de março de 2004 e versão 5.0 em Avaliação de Membro, de abril de 2005), uma primeira concretização da solução descrita na presente invenção provê suporte para operadores e clientes que efetuam atividades se referindo aos agrupamentos de processo de ponta a ponta verticais de Nível 1 seguintes:

- Administração de Vida de Infra-estrutura (área de processo: Estratégia, Infra-estrutura e Produto);

- Suporte e Prontidão de Operações (área de processo:

Petição 870180145819, de 29/10/2018, pág. 30/82 / 49

Operações);

- Cumprimento (área de processo: Operações);

- Garantia (área de processo: Operações).

Considerando agora a dimensão horizontal da estrutura de eTOM, os agrupamentos de processo funcionais horizontais de Nível 1 nos quais as atividades de operadores e clientes caem são:

- Desenvolvimento e Administração de Recurso (área de processo: Estratégia, Infra-estrutura e Produto);

- Administração de Relação de Cliente (área de processo: Operações);

- Conserte Administração e Operações (área de processo: Operações); e

- Administração e Operações de Recurso (área de processo: Operações).

[0069] Administração e compartilhamento do conhecimento operacional para operadores e clientes podem, em troca, cair na área de processo Administração de Empreendimento e, em particular, ao agrupamento de processo Nível 1 conhecido como Administração de Conhecimento e Pesquisa.

[0070] O fluxograma da Figura 3 mostra, por meio de exemplo, um procedimento para suportar engenheiros de campo.

[0071] Em primeiro lugar, a plataforma descrita acima guia o operador, confiado com efetuar uma dada atividade, mostrando a ele as atividades pontuais a serem executadas; os modos operacionais com os quais a plataforma oferece dito serviço com referência a engenheiros de campo são apresentados na Figura 3 e descritos em seguida.

[0072] A jusante da seleção pelo engenheiro de campo da intervenção a ser efetuada (etapa 100), a Proxy Pessoal associada a ele exibe (etapa 110) no dispositivo terminal do engenheiro de campo, usando a Interface PI

Petição 870180145819, de 29/10/2018, pág. 31/82 / 49 correspondente, sinais de instrução organizados como fluxos de trabalho visados a consertar uma falha ou executar uma Ordem de Trabalho, relacionada, por exemplo, a atividades de Provisão ou Operação (tais como atualizações de banco de dados, etc.). Exibida no dispositivo do engenheiro de campo é uma seleção específica de fluxos de trabalho, que o guia na execução da intervenção de acordo com práticas que são alternativas entre si. Os fluxos de trabalho individuais contêm toda a informação necessária para o engenheiro de campo executar a intervenção específica, incluindo dados específicos possíveis relativos à própria intervenção, tais como os requeridos para identificar o componente de um equipamento no qual operar: por exemplo, se uma etapa de um fluxo de trabalho guiar o engenheiro de campo na atividade de mudar uma placa de um equipamento, dita etapa contém também a indicação que habilita o engenheiro de campo identificar de um modo fácil e único a placa a ser mudada. Cada fluxo de trabalho é apresentado, também indicando a contagem que foi nomeada a ele e que reflete uma avaliação averiguada da efetividade e eficiência do próprio fluxo de trabalho a fim de melhor alcançar o objetivo da intervenção. Dita contagem também determina a ordem de apresentação dos fluxos de trabalho (listados a partir do com a contagem mais alta).

[0073] Antes de decidir se selecionar um dos fluxos de trabalho indicados, o engenheiro de campo pode pedir a Proxy Pessoal PP para juntar dados de medição ou prover informação sobre a configuração de equipamento. O pedido requer uma troca de informação entre a Proxy Pessoal PP e a Proxy de Recurso RP, com o pedido do engenheiro de campo remetido da Proxy Pessoal PP para a Proxy de Recurso RP e a resposta correspondente, enviada pela Proxy de Recurso RP para a Proxy Pessoal PP, apresentada ao engenheiro de campo pela Interface PI (a atividade inteira corresponde à etapa 120).

[0074] Além disso, o engenheiro de campo também pode pedir que um

Petição 870180145819, de 29/10/2018, pág. 32/82 / 49 ou mais dos fluxos de trabalho propostos deveria ser exibido (etapa 130) assim para ter informação adicional antes de decidir como proceder. O engenheiro de campo pode então decidir (etapa 140) selecionar um ou nenhum dos fluxos de trabalho apresentados; no caso de seleção, há a ativação no PP do fluxo de trabalho escolhido (etapa 150).

[0075] A jusante da ativação de um fluxo de trabalho, um processo de registrar todas as atividades executadas pelo engenheiro de campo é começado (etapa 160). Informação juntada é armazenada no registro operacional OL e então pode ser processada para refinar os fluxos de trabalho existentes ou para o propósito de gerar e validar novos fluxos de trabalho.

[0076] Em paralelo à ativação do fluxo de trabalho na Proxy Pessoal PP, há a ativação na Proxy de Recurso RP que administra o equipamento no qual o engenheiro de campo deve operar de um fluxo de trabalho cooperativo que coopera com o na Proxy Pessoal (etapa 170). É o fluxo de trabalho na própria Proxy Pessoal PP que, como uma primeira etapa, ativa um fluxo de trabalho 'cooperativo' específico na Proxy de Recurso RP. Os dois fluxos de trabalho são executados de um modo independente, exceto para coordenação em alguns pontos nos quais eles podem usar mecanismos de espera mútua para trocar resultados de processamento. Alguns exemplos de permutas de informação são dados no seguinte.

[0077] Pode haver então trocas de informação (etapa 180) entre Proxies Pessoais PPs e Proxies de Recurso RPs para enviar, de Proxies de Recurso RPs para Proxies Pessoais PPs:

- possíveis dados sobre a configuração do equipamento, ou resultados de medições no equipamento, no qual o engenheiro de campo está intervindo, que são requeridos para executar as etapas subsequentes do fluxo de trabalho. Estes dados são enviados automaticamente, sem qualquer pedido pelo engenheiro de campo, como a Proxy de Recurso RP está sincronizada com as atividades que estão sendo executadas e conhece ambos os tempos

Petição 870180145819, de 29/10/2018, pág. 33/82 / 49 envolvidos e o tipo de informação requerida;

- a indicação que as atividades de configuração executadas autonomamente pela Proxy de Recurso RP em pontos apropriados do fluxo de trabalho foram efetuadas realmente;

- os resultados da verificação, executados autonomamente pela Proxy de Recurso RP, da execução bem sucedida da intervenção pelo engenheiro de campo (no caso de falha, verificação de seu conserto, no caso de Prover Ordem de Trabalho, verificação da execução correta das atividades de configuração pedidas).

[0078] Seguindo na recepção pelo engenheiro de campo pela Proxy Pessoal PP da indicação, vindo da RP, da conclusão bem sucedida da intervenção (etapa 190), a intervenção é considerada encerrada (etapa 200), e o engenheiro de campo pode selecionar uma intervenção subsequente.

[0079] No caso de onde um engenheiro de campo decide não selecionar qualquer dos fluxos de trabalho propostos a ele, ou senão, se não existir qualquer fluxo de trabalho associado à intervenção a ser executada, o engenheiro de campo pode em qualquer caso pedir, pela Proxy Pessoal PP, que, por sua vez, se conecta com a Proxy de Recurso RP apropriada, informação, medições ou execução de comandos no equipamento no qual ele deve operar, também provendo um acesso remoto à Interface de Linha de Comunicação (CLI) do equipamento. Isto é feito como suporte para a execução da intervenção (etapa 220) e/ou como verificação da execução correta disso (etapa 230), antes de encerrar a intervenção (etapa 200). Além disso, todas as atividades executadas pelo engenheiro de campo são registradas (etapa 210), e informação juntada é armazenada no Registro Operacional e pode ser processada subsequentemente para o propósito de gerar e validar novos fluxos de trabalho ou para refinar fluxos de trabalho existentes.

[0080] O técnico que escolheu seguir as etapas indicadas por um fluxo

Petição 870180145819, de 29/10/2018, pág. 34/82 / 49 de trabalho específico pode interromper a qualquer momento a execução do próprio fluxo de trabalho e proceder sem qualquer demora sendo guiado, interagindo com o equipamento (pela cadeia entre Proxies Pessoais PPs e Proxies de Recurso RPs) para obter informação e/ou efetuar ações no próprio equipamento.

[0081] Por exemplo, Figura 4 apresenta um exemplo de fluxo de trabalho cooperativo para substituição de uma placa de equipamento. Em particular, Figura 4 em questão apresenta um exemplo de fluxo de trabalho cooperativo visado a guiar os engenheiros de campo em uma atividade de substituição de uma placa em um equipamento.

[0082] O engenheiro de campo, a jusante da escolha do fluxo de trabalho a ser ativado de acordo com os critérios previamente descritos, requer a iniciação, pela Interface PI, do fluxo de trabalho selecionado na Proxy Pessoal PP (etapa 1100).

[0083] O fluxo de trabalho na ponta de Proxy Pessoal PP começa (etapa 300) e, como primeira ação, começa o fluxo de trabalho cooperativo relacionado na Proxy de Recurso RP (etapa 310). Ao engenheiro de campo é enviada uma mensagem na Interface PI para esperar iniciação do fluxo de trabalho RP (etapa 1110).

[0084] O fluxo de trabalho de Proxy Pessoal PP procede com as atividades preliminares à substituição da placa, indicando ao engenheiro de campo as instruções para abrir o equipamento (etapa 320) por descrição na Interface PI das operações manuais a serem executadas (etapa 1120) e as indicações para identificar a placa dentro do equipamento (etapa 330), uma vez mais por exibição na Interface PI (etapa 1130), também pela ajuda de esquemas que facilitam a identificação da placa.

[0085] Ao mesmo tempo, o fluxo de trabalho de Proxy de Recurso RP procede com as atividades de administração introdutórias à substituição da placa (etapa 510), tal como, por exemplo, a desativação ou deslocamento de

Petição 870180145819, de 29/10/2018, pág. 35/82 / 49 serviços ainda ativos nela ou colocando a placa em um estado não operacional. Quando ditas atividades ocorreram, o fluxo de trabalho de Proxy de Recurso RP notifica o fluxo de trabalho de Proxy Pessoal PP que pode proceder (etapa 520).

[0086] O fluxo de trabalho de Proxy Pessoal PP notifica o engenheiro de campo para desconectar a fiação para a placa que está sendo substituída (etapa 340), apresentando informação útil para atividade manual na Interface PI (etapa 1140), enquanto notifica o fluxo de trabalho de Proxy de Recurso RP para proceder com a próxima etapa de supervisão da atividade (etapa 530), tal como, por exemplo, verificação de se as portas físicas envolvidas sinalizam o estado de fiação desconectada. Quando toda a fiação da placa a ser substituída foi desconectada, o fluxo de trabalho de Proxy de Recurso RP notifica o fluxo de trabalho PP (etapa 530).

[0087] O fluxo de trabalho de Proxy Pessoal PP procede com a verificação sobre se a placa está pronta para remoção do equipamento (etapa 350), avançando o fluxo de trabalho de Proxy de Recurso RP sobre a atividade de liberação de placa (etapa 540) e indicando ao engenheiro de campo para verificar o sinal de placa liberada (etapa 1150).

[0088] Quando o fluxo de trabalho de Proxy de Recurso RP completa as atividades de liberação de placa, como, por exemplo, colocando a placa no estado desligado, notifica o fluxo de trabalho de Proxy Pessoal PP (etapa 540), que procede com a ação de remoção física atual da placa (etapa 360), indicando ao engenheiro de campo as atividades manuais a serem executadas (etapa 1160), tais como alavancas de liberação a serem ativadas e indicações das práticas para remover a placa.

[0089] O fluxo de trabalho de Proxy de Recurso RP supervisiona a atividade manual, verificando o estado e sinais vindo do equipamento (etapa 550), tal como, por exemplo, o estado de abertura livre, e notifica o fluxo de trabalho de Proxy Pessoal PP quando a placa não está mais presente.

Petição 870180145819, de 29/10/2018, pág. 36/82 / 49 [0090] O fluxo de trabalho de Proxy Pessoal PP, tendo recebido as mensagens de conclusão das atividades ambos do fluxo de trabalho de Proxy Pessoal PP e do engenheiro de campo pela Interface PI, procede com a ação de inserção da placa nova (etapa 370), enviando a informação necessária para a Interface PI (etapa 1170) e notificando o fluxo de trabalho de Proxy de Recurso RP. O anterior supervisiona a inserção da placa nova (etapa 560), por exemplo, verificando se a abertura passou do estado livre para o estado ocupado, até notificação ao fluxo de trabalho de Proxy Pessoal PP da inserção correta da placa nova (etapa 570).

[0091] O fluxo de trabalho de Proxy de Recurso RP procede com as verificações e configuração da placa nova (etapa 580), enquanto o fluxo de trabalho de Proxy Pessoal PP espera a conclusão da atividade anterior (etapa 380) e notifica o engenheiro de campo pela Interface PI da verificação em desenvolvimento (etapa 1180).

[0092] Ao término da configuração da placa nova, o fluxo de trabalho de Proxy de Recurso RP notifica o fluxo de trabalho de Proxy Pessoal PP (etapa 580) para proceder com a conexão da fiação (etapa 390), por apresentação ao engenheiro de campo na Interface PI das atividades manuais a serem executadas (etapa 1190) com a ajuda de esquemas relativos ao tipo de placa e fiação.

[0093] Durante a conexão da fiação, o fluxo de trabalho de Proxy de Recurso RP supervisiona as portas da placa (etapa 590), por exemplo controlando o estado das portas que indica fiação conectada. Só quando toda a fiação envolvida foi reconectada, o fluxo de trabalho de Proxy de Recurso RP notifica o fluxo de trabalho de Proxy Pessoal PP (etapa 590) e procede com a verificação e configuração das portas (etapa 600), tal como, por exemplo, reativação dos serviços ou sua transição da configuração temporária previamente executada (etapa 510).

[0094] O fluxo de trabalho de Proxy Pessoal PP espera a conclusão das

Petição 870180145819, de 29/10/2018, pág. 37/82 / 49 configurações das portas da placa nova (etapa 400) e notifica o engenheiro de campo pela Interface PI (etapa 1200) que dita atividade está em desenvolvimento. Uma vez que a configuração das portas esteja completada (etapa 600), o fluxo de trabalho de Proxy de Recurso RP notifica o fluxo de trabalho de Proxy Pessoal PP e termina (etapa 610), enquanto o fluxo de trabalho de Proxy Pessoal PP guia o engenheiro de campo para efetuar o fechamento do gabinete do equipamento (etapa 410) provendo informação apropriada na Interface PI (etapa 1210).

[0095] Finalmente, o fluxo de trabalho de Proxy Pessoal PP completa sua execução (etapa 420), notificando o engenheiro de campo que fim dos fluxos de trabalho está sendo esperado (etapa 1220) e esperando por conclusão do fluxo de trabalho de Proxy de Recurso RP. Os fluxos de trabalho terminam, sincronizando na última ação do fluxo de trabalho PP (etapa 430), com informação ao engenheiro de campo de intervenção concluída com sucesso (etapa 1230).

[0096] Figura 5 ilustra, ao invés, um exemplo de procedimento para suportar consultores de Centro de Chamada: a solução descrita aqui na realidade habilita aplicação do serviço de guia também para consultores de Centro de Chamada.

[0097] Seguindo no recebimento, pelo consultor de Centro de Chamada, de uma reclamação de cliente (em seguida chamada Relatório de Dificuldade: TR) ou de um pedido para um novo serviço (em seguida chamado Pedido de Cliente: CO) (etapa 1300), a Proxy Pessoal PP associada ao consultor de Centro de Chamada abre uma sessão com a Proxy/Proxies de Recurso RP associadas aos equipamentos de rede de interesse para o pedido de cliente e coleta informação requerida para sua interação com o cliente (no caso de um Relatório de Dificuldade, é verificado se há falhas nos equipamentos envolvidos na oferta de serviço de cliente) (etapa 1310).

[0098] Seguindo na coleta dos dados da rede, se a Proxy Pessoal PP não

Petição 870180145819, de 29/10/2018, pág. 38/82 / 49 requerer qualquer informação adicional (verificação feita na etapa 1320) e estiver lidando com uma reclamação de cliente (verificação feita na etapa 1330), os dados juntados são processados a fim de efetuar uma primeira diagnose (etapa 1380). Se, ao invés, a Proxy Pessoal PP não requerer informação adicional (verificação feita na etapa 1320) e estiver lidando com um pedido para um novo serviço (verificação feita na etapa 1330), a próxima etapa é a criação de um Pedido de Trabalho (WO) (etapa 1420).

[0099] Seguindo na coleta dos dados da rede, se a Proxy Pessoal PP requerer informação adicional (verificação feita na etapa 1320), ela exibe no dispositivo do consultor de Centro de Chamada (etapa 1340), usando a Interface PI correspondente, uma sequência de perguntas visadas a adquirir detalhes adicionais sobre o TR/CO do cliente. No caso de Relatório de Dificuldade, ditas perguntas também podem ser pedidos ao cliente para executar verificações/ações pontuais, que podem conduzir a resolver o problema que é a causa do Relatório de Dificuldade, por exemplo, pedidos para verificar se toda a fiação de um Equipamento de Instalação de Cliente (CPE) está conectada corretamente e procedendo para corrigir conexão da fiação na qual falhas de conexão são detectadas.

[00100] O consultor de Centro de Chamada, interagindo com o cliente, provê a Proxy Pessoal PP com as respostas apropriadas para as perguntas postas a ele (etapa 1350). No caso onde o cliente não é capaz de prover os dados pedidos ou a fim de integrar os dados providos por ele, o consultor de Centro de Chamada pode pedir a Proxy Pessoal PP para juntar dados de medição ou prove-lo com informação de configuração relacionada à porção de rede de interesse para o cliente específico. Isto requer uma troca de informação entre as Proxies Pessoais PPs e as Proxies de Recurso RPs que controlam dita porção de rede, com o pedido do consultor de Centro de Chamada remetido pela Proxy Pessoal PP para a Proxy de Recurso RP e as respostas correspondentes enviadas pela Proxy de Recurso RP para a Proxy

Petição 870180145819, de 29/10/2018, pág. 39/82 / 49

Pessoal PP e mostrado pelo anterior ao operador pela Interface PI (a atividade inteira corresponde à etapa 1360).

[00101] Ao término da sequência de perguntas ou, no caso de um Relatório de Dificuldade, a jusante da solução do próprio Relatório de Dificuldade baseado em uma verificação/ação do cliente (verificação feita na etapa 1370), a próxima etapa é etapa 1420.

[00102] No caso de um Relatório de Dificuldade (verificação feita na etapa 1370) pelo cliente, ao término da etapa de coleta guiada dos dados (do cliente e/ou da rede), a Proxy Pessoal PP, usando um sistema baseado em regras, formula uma primeira hipótese sobre a causa raiz do Relatório de Dificuldade (etapa 1380).

[00103] Se a falha puder ser consertada pelo cliente (verificação feita na etapa 1390), a Proxy Pessoal PP do consultor de Centro de Chamada abre uma sessão com a Proxy Pessoal PP do cliente, pedindo a ele para executar um fluxo de trabalho específico para resolver o Relatório de Dificuldade (etapa 1400). O consultor de Centro de Chamada pode então passar para a execução de outras atividades, ao mesmo tempo sendo informado do resultado da execução do fluxo de trabalho pelo cliente.

[00104] No recebimento do resultado do fluxo de trabalho (etapa 1410), um Tíquete de Dificuldade (TT) apropriado é criado, que levará em conta o resultado do fluxo de trabalho (se o fluxo de trabalho foi executado com êxito, o TT registrará a solução do Relatório de Dificuldade; caso contrário, conterá informação útil para criar um ou mais Pedidos de Trabalho WR para os engenheiros de campo).

[00105] Se a falha não puder ser resolvida pelo cliente (verificação feita na etapa 1390), a próxima etapa é a criação de um Tíquete de Dificuldade (etapa 1420). Seguindo na coleta dos dados no Relatório de Dificuldade/Pedido de Cliente e, no caso de Relatório de Dificuldade, a jusante da diagnose de primeiro-nível e/ou da solução do Relatório de

Petição 870180145819, de 29/10/2018, pág. 40/82 / 49

Dificuldade, a Proxy Pessoal PP provê o consultor de Centro de Chamada com todos os dados requeridos para criar um Tíquete de Dificuldade ou um Pedido de Trabalho, que, no caso de um pedido de cliente ainda não satisfeito, produzirá em um ou mais Pedidos de Trabalho WR para os engenheiros de campo (etapa 1420). A jusante da criação do TT/WO, a atividade do consultor de Centro de Chamada termina (etapa 1430).

[00106] O fluxograma da Figura 6 se refere, ao invés, a um procedimento para suportar clientes; o suporte para a execução de atividades operacionais descritas aqui também se aplica ao cliente.

[00107] Seguindo na detecção, por um cliente, de qualquer mau funcionamento (etapa 700), o próprio cliente ativa em seu dispositivo (tipicamente um PC ou PDA) a Proxy Pessoal PP associada a ele (etapa 710).

[00108] A Proxy Pessoal PP abre uma sessão com a Proxy/proxies de Recurso RP associadas com os equipamentos localizados nas instalações de cliente, a fim de identificar qualquer possível falha em ditos equipamentos (etapa 720). No caso onde nenhuma falha está presente nos equipamentos nas instalações de cliente (verificação feita na etapa 730), a Proxy Pessoal PP exibe no dispositivo do cliente (etapa 740), usando a interface PI correspondente, uma sequência de perguntas visadas a adquirir detalhes adicionais sobre o mau funcionamento detectado. O cliente provê a Proxy Pessoal PP com as respostas apropriadas para as perguntas postas a ele (etapa 750).

[00109] Ao término da sequência de perguntas, a Proxy Pessoal PP verifica se a causa do mau funcionamento foi identificada e se dita causa pode ser removida pelo cliente (verificação feita na etapa 760) e, nesse caso, ativa um fluxo de trabalho apropriado (etapa 770), que guia o cliente em resolver o problema. A Proxy Pessoal PP também ativa um processo de registro das atividades de cliente (etapa 780): a informação juntada é armazenada no Registro Operacional e pode ser processada subsequentemente para refinar os

Petição 870180145819, de 29/10/2018, pág. 41/82 / 49 fluxos de trabalho existentes ou a fim de gerar e validar novos fluxos de trabalho.

[00110] Ao término do fluxo de trabalho, uma verificação é feita, pelo cliente, sobre a remoção do mau funcionamento (etapa 790); se dita verificação tiver um resultado positivo, a atividade do cliente termina (etapa 810). Se, ao invés, a verificação tiver um resultado negativo, a Proxy Pessoal PP notifica o cliente para contatar o Centro de Chamada (etapa 800); a jusante da notificação pela Proxy Pessoal PP, a atividade do cliente termina (etapa 810). Se a causa do mau funcionamento não foi identificada ou senão, se não puder ser removida pelo cliente (verificação feita na etapa 760), a Proxy Pessoal PP notifica o cliente para contatar o Centro de Chamada (etapa 800).

[00111] Seguindo em dita notificação pela Proxy Pessoal PP, a atividade do cliente termina (etapa 810).

[00112] No caso onde há falhas em equipamentos nas instalações de cliente (verificação feita na etapa 730), a Proxy Pessoal PP efetua uma verificação adicional para verificar se ditas falhas podem ser consertadas pelo cliente (verificação feita na etapa 820) e, no caso de um resultado positivo, ativa um fluxo de trabalho apropriado (etapa 770), que guia o cliente em resolver o problema.

[00113] A Proxy Pessoal PP também ativa um processo de registro das atividades de cliente (etapa 780): a informação juntada é armazenada no Registro Operacional e, como já mencionado, pode ser processada a fim de refinar fluxos de trabalho existentes ou gerar e validar novos fluxos de trabalho. Ao término do fluxo de trabalho, uma verificação é feita, pelo cliente, sobre a remoção do mau funcionamento (etapa 790); se dita verificação tiver um resultado positivo, a atividade do cliente termina (etapa 810). Se, ao invés, a verificação tiver um resultado negativo, a Proxy Pessoal PP notifica o cliente para contatar o Centro de Chamada (etapa 800); a jusante da notificação pela Proxy Pessoal PP, a atividade do cliente termina (etapa

Petição 870180145819, de 29/10/2018, pág. 42/82 / 49

810).

[00114] Os fluxos de trabalho executados na Proxy Pessoal PP do cliente idealizam normalmente que o cliente será informado também de possíveis ações efetuadas automaticamente pelas Proxies de Recurso RPs e que ele pode conceder um consentimento explícito para sua execução.

[00115] O fluxograma da Figura 7 ilustra um procedimento para cooperação entre operadores. A plataforma descrita aqui na realidade provê um serviço adicional para suportar o operador, confiado com efetuar uma dada atividade (por exemplo, uma intervenção em campo ou operação de um pedido de cliente), administrando as interações com possíveis outros operadores ou entre um operador e um cliente.

[00116] As práticas operacionais adotadas para interação entre operadores são descritas no seguinte.

[00117] A Proxy Pessoal PP autonomamente (por exemplo, a jusante de detecção de uma intervenção que foi malsucedida no caso de engenheiros de campo) ou na notificação pelo operador, decide ativar uma sessão para as Proxies Pessoais PPs de outros operadores (etapa 1500).

[00118] No caso de ativação automática (verificação feita na etapa 1510), a Proxy Pessoal PP, baseado no conhecimento do tipo de atividade que o operador está executando (deduzida dos dados disponíveis ou derivando de uma indicação explícita do operador) e das macro-habilidades requeridas para efetuá-la, tenta ativar uma sessão usando uma lista ordenada de nomes de operadores a serem contatados, arranjados de acordo com macro-habilidades (etapa 1600).

[00119] Se a ativação não for bem-sucedida (verificação feita na etapa 1610), a Proxy Pessoal PP verifica com o operador (etapa 1640) se proceder em sua tentativa para ativar uma sessão, ou parar. Se o operador decidir continuar, a Proxy Pessoal PP faz outra tentativa para ativar uma sessão com o próximo nome na lista (etapa 1600) e procede iterativamente até que

Petição 870180145819, de 29/10/2018, pág. 43/82 / 49 administre para ativar uma sessão ou até que o operador decida interromper o procedimento. No caso anterior, a Proxy Pessoal PP termina o procedimento de ativação de sessão (etapa 1590).

[00120] Se a ativação for bem-sucedida (verificação feita na etapa 1610), uma sessão é começada entre operadores, em que a Proxy Pessoal PP faz disponível um conjunto de ferramentas para trabalho cooperativo, tal como fazendo visível para ambos operadores todos os dados sobre a atividade a ser efetuada e sobre as etapas já efetuadas ou para compartilhar possíveis dados de rede que o operador, que pediu o suporte, já tinha adquirido (etapa 1620).

[00121] Na notificação do operador, a Proxy Pessoal PP então procede para encerrar a sessão (etapa 1570).

[00122] No caso de ativação no pedido pelo operador (verificação feita na etapa 1510), a Proxy Pessoal PP, baseado no conhecimento do tipo de atividade que o operador está efetuando (deduzida dos dados disponíveis ou derivando de uma indicação explícita do operador) e das macro-habilidades requeridas para efetuá-lo, apresenta (etapa 1520) uma lista ordenada de nomes (a ordem é o que a Proxy Pessoal PP seguiria se tivesse que ativar a sessão autonomamente), entre os quais o operador seleciona o desejado (etapa 1530). [00123] A jusante de seleção do nome pelo operador, a Proxy Pessoal PP tenta estabelecer uma sessão para a Proxy Pessoal PP associada a dito nome (etapa 1540). Se a ativação for malsucedida (verificação feita na etapa 1550), a Proxy Pessoal PP verifica com o operador (etapa 1580) se proceder com a tentativa para ativar uma sessão, ou parar. Se o operador decidir continuar, a Proxy Pessoal PP uma vez mais exibe a lista de nomes, apropriadamente atualizada a fim de levar em conta a tentativa/tentativas malsucedidas (etapa 1520) e procede iterativamente até que administre para ativar uma sessão ou até que o operador decida interromper o procedimento. No caso anterior, a Proxy Pessoal PP termina o procedimento de ativação de sessão (etapa 590).

[00124] Se a ativação for bem-sucedida (verificação feita na etapa 1550),

Petição 870180145819, de 29/10/2018, pág. 44/82 / 49 uma sessão entre operadores é começada, na qual a Proxy Pessoal PP faz disponível um conjunto de ferramentas para trabalho cooperativo, do tipo já previamente considerado (etapa 1560). Na notificação do operador, a Proxy Pessoal PP procede então para encerrar a sessão (etapa 1570).

[00125] A interação entre cliente e o operador usa mecanismos semelhantes para os referidos acima para interação entre operadores; neste caso, é possível imaginar que a cooperação envolverá normalmente o cliente e um consultor de Centro de Chamada e que será a Proxy Pessoal PP do cliente, no pedido do próprio cliente ou autonomamente, que estabelecerá uma sessão. Também neste caso, o cliente pode decidir interromper a tentativa para estabelecer uma sessão com um operador a qualquer momento. No caso de um pedido de cliente, a Proxy Pessoal PP apresenta o próprio cliente com a lista ordenada de nomes de consultores de Centro de Chamada e permite ao cliente selecionar o consultor a ser contatado.

[00126] A fim de oferecer os serviços exemplificados acima, a plataforma descrita mantém um conjunto de dados sobre os operadores, sobre os clientes, e sobre os fluxos de trabalho, e executa uma administração dinâmica dos processos, para adaptar ambos a mudanças operacionais (introdução de novos fluxos de trabalho seguindo na introdução de novos equipamentos, apagamento de fluxos de trabalho se referindo a atividades em equipamentos que não estão mais na rede, etc.), e a mudanças das características e do número de membros da mão-de-obra (introdução de novos operadores, atualização dos dados dos perfis de operador, etc.) e dos clientes (introdução de novos clientes, atualização dos dados dos perfis de cliente, etc.).

[00127] Os perfis de operador são definidos baseado em um pequeno número de perfis básicos padrão; ditos perfis especificam as macrohabilidades (por exemplo domínios de rede/serviço nos quais o operador pode efetuar atividades: comutação, transmissão, acesso de ADSL, etc.) dos operadores e, para cada macro-habilidade, o grau correspondente (indica

Petição 870180145819, de 29/10/2018, pág. 45/82 / 49 quanto o operador está qualificado em um dado campo). O perfil também realça se o operador é um engenheiro de campo ou um operador de retaguarda, ou um consultor de Centro de Chamada mostra a qual equipe virtual ele pertence, e provê suas credenciais de autenticação. Os dados de ditos perfis são atualizados dinamicamente para levar em conta, por exemplo, novas macro -habilidades ou mudanças em grau; o modelo dos perfis é armazenado no banco de dados ODB. A atualização dinâmica das macrohabilidades é efetuada de um modo oportuno, para habilitar todos os serviços de plataforma (por exemplo, aquele de interação entre operadores) a usar dados atualizados. Com respeito a carregamento dos dados dos perfis de operador, cada Proxy Pessoal PP mantém só o perfil do operador ao qual está associada (cada Proxy Pessoal PP está associada a um operador específico): os dados de dito perfil são adquiridos pelo OM interagindo com sistemas externos apropriados (sistemas de WFM); a plataforma então idealiza um inventário centralizado (Inventário de Perícia EI), em que os dados dos perfis de todos os operadores (carregado do WFM) estão armazenados. Na iniciação de cada Proxy Pessoal PP, os dados de perfil de operador associados a dita Proxy Pessoal PP são carregados automaticamente do Inventário de Perícia EI, pelo Administrador Operacional OM, sobre a própria Proxy Pessoal PP. O inventário EI é atualizado periodicamente e, a cada atualização dos dados no próprio inventário, dados são enviados à Proxy Pessoal PP correspondente.

[00128] Os perfis de cliente são definidos na base de um pequeno número de perfis básicos padrão; ditos perfis especificam o serviço/serviços, para o qual o cliente pode efetuar atividades de auto-conserto (por exemplo, serviço de ADSL, serviço de ISDNS, etc.), e as credenciais de autenticação do cliente. Os dados dos perfis são atualizados dinamicamente a fim de levar em conta, por exemplo, novos serviços que foram assinados; o modelo dos perfis é armazenado no banco de dados ODB. A atualização dinâmica dos dados dos perfis de cliente é feita de um modo oportuno a fim de habilitar todos os

Petição 870180145819, de 29/10/2018, pág. 46/82 / 49 serviços de plataforma usarem dados atualizados. Com respeito a carregamento dos dados dos perfis de cliente, cada Proxy Pessoal PP mantém apenas o perfil do cliente ao qual está associado (cada Proxy Pessoal PP está associada a um cliente específico): os dados de dito perfil são adquiridos pelo Administrador OM Operacional interagindo com sistemas externos apropriados (Sistemas de Suporte Empresarial); a plataforma então idealiza um inventário centralizado (Inventário de Perícia EI) em que os dados dos perfis de todos os clientes (carregados dos Sistemas de Suporte Empresarial) são armazenados. Na iniciação de cada Proxy Pessoal PP, os dados do perfil de cliente associados à dita Proxy Pessoal PP são carregados automaticamente do inventário EI, pelo Administrador Operacional OM, sobre a própria Proxy Pessoal PP. O inventário EI é atualizado periodicamente, e a cada atualização dos dados no próprio inventário, dados são enviados à Proxy Pessoal PP correspondente.

[00129] Com respeito a fluxos de trabalho em suporte de operação dos engenheiros de campo, o banco de dados ODB mantém, para cada fluxo de trabalho, um conjunto de características como o identificador de fluxo de trabalho (este pode ser um identificador numérico progressivo gerado automaticamente pela plataforma), a versão do fluxo de trabalho, a contagem do fluxo de trabalho, o tipo de intervenção ao qual o fluxo de trabalho se aplica (por exemplo, falha, atividades de Provisão, atividades de operação, etc.), o identificador da intervenção específica a ser executada (por exemplo, no caso de falha, é possível indicar falha de ligação, falha de placa de usuário, etc.), o grau de macro-habilidades requeridas para efetuar a intervenção, se aplicável (por exemplo, engenheiro de campo perito e engenheiro de campo iniciante), etc. Ditas características são providas quando o fluxo de trabalho é criado/modificado; a contagem é atualizada dinamicamente, de acordo com o que é mencionado abaixo. A criação/modificação dos fluxos de trabalho suportando operação, armazenados no banco de dados OBD, e dos fluxos de

Petição 870180145819, de 29/10/2018, pág. 47/82 / 49 trabalho cooperativos correspondentes, armazenados no banco de dados MDB, é feita por uma interface gráfica apropriada que habilita edição paralela dos dois fluxos de trabalho correlatado a fim de facilitar verificações de congruência sobre o foi processado.

[00130] Considerações semelhantes se aplicam com respeito a fluxos de trabalho suportando operação de cliente: o banco de dados ODB mantém, para cada fluxo de trabalho em suporte do cliente, um conjunto de características semelhantes às dos fluxos de trabalho para o engenheiro de campo e também aplicáveis ao caso de cliente.

[00131] Para os fluxos de trabalho em suporte dos engenheiros de campo, duas funções de administração são idealizadas.

[00132] Com respeito a carregamento de fluxos de trabalho, carregamento do fluxo de trabalho na Proxy Pessoal PP será efetuado pelo Agente de Controle CA associado a isso. Na iniciação da Proxy Pessoal PP, nenhum fluxo de trabalho é carregado; os fluxos de trabalho são carregados sobre a Proxy Pessoal PP só no pedido explícito pela própria Proxy Pessoal PP: a jusante da suposição de uma dada atividade por um engenheiro de campo e da seleção por ele de um fluxo de trabalho a ser efetuado ou ser exibido no seu dispositivo, a Proxy Pessoal PP verifica se dito fluxo de trabalho é acessível diretamente na medida em que já está presente na área de memória local e se está atualizado (pelo indicador de versão associado ao fluxos de trabalho). Se o fluxo de trabalho não estiver presente ou não atualizado, pelo Agente de Controle CA, é carregado do banco de dados ODB; o fluxo de trabalho permanecerá armazenado na Proxy Pessoal PP para qualquer possível uso futuro.

[00133] De um modo semelhante, na iniciação da Proxy de Recurso RP nenhum fluxo de trabalho é carregado; os fluxos de trabalho são carregados sobre a Proxy de Recurso RP só no pedido explícito pela própria Proxy de Recurso RP: no momento em que a Proxy de Recurso RP recebe da Proxy

Petição 870180145819, de 29/10/2018, pág. 48/82 / 49

Pessoal PP o pedido para ativar um dado fluxo de trabalho em suporte de operação, a Proxy Pessoal PP verifica se isto está diretamente acessível na medida em que já está presente na área de memória local e se está atualizado (pelo indicador de versão associado aos fluxos de trabalho). Se o fluxo de trabalho não estiver presente ou não estiver atualizado, a Proxy de Recurso RP o carrega do banco de dados MDB; o fluxo de trabalho permanecerá armazenado na Proxy de Recurso RP para possíveis usos futuros.

[00134] Um procedimento para administrar dinamicamente a contagem dos fluxos de trabalho é então idealizado. A contagem do fluxo de trabalho é baseada ambos nos dados de tempo/custo (ligados às atividades executadas pelo engenheiro de campo e ao custo de materiais usados para executar estas atividades) e as preferências do engenheiro de campo para um dado fluxo de trabalho. A fim de adquirir estes dados, a cada execução de um fluxo de trabalho, um conjunto de parâmetros, ligados à dita execução, é juntado (a coleção dos parâmetros de fluxo de trabalho é executada pelas Proxies Pessoais PPs) e atualizado. Exemplos de tais parâmetros são tempo total de execução do fluxo de trabalho na Proxy Pessoal PP, uso de CPU, número de operadores que escolheram o fluxo de trabalho, etc. Os dados juntados/atualizados são armazenados no Banco de Dados de Desempenho PDB. Periodicamente (por exemplo, a intervalos de tempo fixos), é necessário analisar e processar ditos parâmetros para obter um novo valor da contagem para cada fluxo de trabalho. A nova contagem dos fluxos de trabalho é então comunicada às várias Proxies Pessoais PPs.

[00135] Funções de administração semelhantes são providas para fluxos de trabalho suportando os clientes: os fluxos de trabalho são carregados sobre a Proxy Pessoal PP no pedido pela própria Proxy Pessoal PP, a jusante da identificação da falha/problema a ser operado com ditos fluxos de trabalho ou na recepção do pedido para ativar um fluxo de trabalho específico vindo da Proxy Pessoal PP de um consultor de Centro de Chamada. Em particular, no

Petição 870180145819, de 29/10/2018, pág. 49/82 / 49 caso de vários fluxos de trabalho que podem ser usados para guiar o cliente, só o fluxo de trabalho que naquele momento tem a contagem mais alta é carregado na Proxy Pessoal PP. Também para fluxos de trabalho para o cliente, um mecanismo de administração dinâmica da contagem é provido, calibrado apropriadamente nos parâmetros que podem ser identificados na ponta de cliente.

[00136] Como foi visto, a interação entre a Proxy Pessoal PP e o operador ou o cliente é realizada usando uma Interface Pessoal PI apropriada. A Interface PI é criada usando tecnologias que dependem do tipo e potência computacional do dispositivo usado pelo operador/cliente (PC, telefone móvel, palmtop, etc.), tal como por exemplo tecnologias de cliente-servidor baseadas na web (páginas de HTML, Applet Java, aplicativos de Java independentes) ou tecnologias de agente autônomo. A interface PI é projetada consistentemente com os princípios de utilidade a fim de habilitar o operador/cliente alcançar o objetivo fixado com a melhor efetividade, eficiência e satisfação em todos os contextos específicos de uso. No desenvolvimento da interface PI, muito atenção foi prestada ambos a otimização de código para fazer as interações e atividades, que as Proxies Pessoais PPs têm que executar em cooperação com as Proxies de Recurso RPs, mais efetivas, e aos aspectos de utilidade e de favorecimento de usuário da GUI a fim de melhorar altamente a capacidade do operador/cliente para efetuar a tarefa nomeada a ele.

[00137] No caso de um operador, em um pedido de atividade (intervenção em campo ou Relatório de Dificuldade/Pedido de Cliente), o WFM envia ao Administrador Operacional OM o nome do operador escolhido e os detalhes da atividade a ser executada. O Administrador Operacional OM remete ditos dados à Proxy Pessoal PP associada ao operador escolhido, pelo Agente Operacional AO, que coordena dita Proxy Pessoal PP; a Proxy Pessoal PP, por sua vez, notifica na interface PI

Petição 870180145819, de 29/10/2018, pág. 50/82 / 49 correspondente que há uma atividade a ser efetuada.

[00138] Uma vez que o operador recebeu na sua Interface PI a informação que há uma atividade a ser efetuada, ele procede como segue:

- ele começa, da 'Home Page' da Interface PI, o procedimento de registro e autenticação; baseado no perfil de operador, seções dedicadas a funções privilegiadas podem ou não ser exibidas; os dados de autenticação são verificados contra os armazenados no Inventário de Perícia EI para o operador associado à dita Proxy Pessoal PP;

- ele exibe os dados na atividade nomeada a ele e executa o procedimento de suposição de dita atividade (por exemplo, intervenção em campo ou Relatório de Problema/Pedido de Cliente); neste momento, o operador pode acessar, pela interface PI, a ambientes gráficos e de navegação como ajuda para operação; as funções providas por estes ambientes estão disponíveis em parte e usadas por todos os tipos de operadores (por exemplo, engenheiros de campo e consultores de Centro de Chamada) e em parte específicas para um certo tipo de operador.

[00139] Estas funções habilitam:

- exibição de local do equipamento (por exemplo, dentro de uma estação telefônica) na qual efetuar a intervenção (engenheiros de campo);

- exibição da interface do equipamento e identificação gráfica do componente de hardware (prateleira, placa, porta, dispositivo, etc.) em que é necessário intervir (engenheiros de campo);

- apresentação do fluxo de trabalho (com possível opção anterior de seleção entre fluxos de trabalho diferentes) em um modo interativo, a fim de guiar, passo a passo, a operação do engenheiro (engenheiros de campo);

- apresentação de uma sequência de perguntas de um modo interativo a fim de adquirir, passo a passo, a informação requerida para detalhar o pedido de um cliente (consultores de Centro de Chamada);

Petição 870180145819, de 29/10/2018, pág. 51/82 / 49

- sugestão de ações que o cliente deveria efetuar a fim de resolver um Relatório de Dificuldade apresentado pelo próprio cliente (consultores de Centro de Chamada);

- apresentação das hipóteses feitas sobre a causa do Relatório de Dificuldade de um cliente (consultores de Centro de Chamada);

- exibição da instalação das conexões entre a Proxy Pessoal PP e Proxy de Recurso RP, e apresentação das respostas da Proxy de Recurso RP para as ações de configuração, colocação, medição, prova, etc., efetuadas pelo RP tanto autonomamente ou no pedido da Proxy Pessoal PP (todos os operadores);

- acesso remoto, pelo RP, a uma CLI (Interface de Linha de Comando) no equipamento no qual a intervenção está sendo efetuada (engenheiros de campo);

- exibição da documentação on-line como possível suporte para a atividade (todos os operadores); e

- acesso às funções tradicionais de comunicação com outros operadores (os operadores de Equipe Virtual, pessoal de administração, operadores de retaguarda, consultores de Centro de Chamada): chamada de voz, e-mail, conversação, placa branca compartilhada, etc., (todos os operadores).

[00140] No caso de um cliente, o próprio cliente, seguindo na iniciação de sua Proxy Pessoal PP, executa o procedimento de registro e autenticação e recebe em eu dispositivo todos os dados (perguntas, fluxos de trabalho de guia, etc.) requeridos para resolver um mau funcionamento detectado por ele. [00141] As funções oferecidas habilitam:

- apresentação do fluxo de trabalho de um modo interativo, a fim de orientar, passo a passo, operacionalidade do cliente;

- apresentação de uma sequência de perguntas de um modo interativo, a fim de adquirir, passo a passo, a informação requerida para

Petição 870180145819, de 29/10/2018, pág. 52/82 / 49 identificar a causa do mau funcionamento detectado pelo cliente;

- apresentação da hipótese sobre a causa raiz de um mau funcionamento;

- exibição da instalação de conexões entre a Proxy Pessoal PP e a Proxy de Recurso RP, e apresentação das respostas da Proxy de Recurso RP;

- notificação da necessidade para contatar um operador para resolver o mau funcionamento;

- acesso às funções de comunicação com um operador.

[00142] Os componentes suportando operação acima descritos também acham aplicação em contextos de administração baseados em abordagens tecnológicas mais tradicionais (paradigma de cliente-servidor).

[00143] Se nós examinamos por exemplo, soluções de administração que adotam uma abordagem hierárquica baseada em tecnologia de cliente-servidor (como, por exemplo, exemplificada por US-A-2004/0196794), as funções para suportar operação (de operadores e clientes) previamente descritas ainda são efetivas e podem ser oferecidas usando uma plataforma que, para a parte operacional, não muda com respeito ao que é apresentado aqui na Figura 2, enquanto, para a parte de administração de rede e serviço, se confia na arquitetura descrita na Figura 2 de US-A-2004/0196794. Em particular, neste caso, se a meta for adotar uma abordagem conservadora que não idealiza modificação do componente de administração (estação de administração de rede de camada inferior) que administra diretamente os dispositivos na rede, a Proxy Pessoal PP se conectaria diretamente com a estação de administração de rede de camada inferior correspondente para efetuar todas as interações da/para a rede (que, na concretização acima descrita, eram executadas pela Proxy de Recurso RP), usando modalidades de comunicação semelhantes às adotadas entre estações de administração de rede de camada superior e camada inferior. Alternativamente, a Proxy Pessoal PP poderia interagir com

Petição 870180145819, de 29/10/2018, pág. 53/82 / 49 a estação de administração de rede de camada superior, que possui a informação topológica sobre a estações de administração rede de camada inferior, assim evitando ter que operar dita informação diretamente. Em qualquer caso, exceto para modificações para o componente de administração, não haveria um fluxo de trabalho cooperativo na estação de administração de rede interessada: isto, porém, de nenhuma maneira arrisca a validade e efetividade da função para suportar operação, na medida em que isto representa só uma possível alternativa à concretização preferida da presente invenção.

[00144] Será apreciado que, enquanto o procedimento guiando os engenheiros de campo em efetuar uma dada intervenção, como descrito com relação à Figura 3, se refere à seleção da intervenção a ser efetuada por um engenheiro de campo, as modalidades com as quais dita seleção é feita são várias, e dependem do paradigma operacional adotado e das funções executadas pelo sistema de WFM. Em uma concretização da presente invenção, o engenheiro de campo só se encarrega da intervenção que é apresentada a ele pela Proxy Pessoal PP na sua Interface PI, e que foi carregada à própria Proxy Pessoal PP pela cadeia de WFM-OM.

[00145] Em uma concretização alternativa, o engenheiro de campo seleciona uma atividade das serem efetuadas em um equipamento em um dado local; neste caso, a única indicação recebida pelo engenheiro de campo, pela Proxy Pessoal PP que, por sua vez, a recebeu da cadeia de WFM-OM, é a relacionada ao local ao qual ele tem que ir (o WFM só administra as rodadas periódicas dos engenheiros de campo entre os vários locais, sem indicar a eles o que eles têm que fazer).

[00146] O procedimento previamente descrito com relação à Figura 3 indica que fluxos de trabalho apropriados são propostos ao engenheiro de campo. Isto é feito por interação entre a Proxy Pessoal PP e o Administrador Operacional OM. Quando uma intervenção é selecionada por um engenheiro

Petição 870180145819, de 29/10/2018, pág. 54/82 / 49 de campo, a Proxy Pessoal PP pede para o Administrador Operacional OM a lista de todos os fluxos de trabalho para suportar dita intervenção. O Administrador Operacional OM cria dinamicamente esta lista, baseado em informação de fluxo de trabalho disponível no banco de dados ODB, e a envia à Proxy Pessoal PP que a apresenta ao engenheiro de campo.

[00147] Em uma primeira possível concretização da presente invenção, dada uma intervenção específica, todos os engenheiros de campo são então apresentados com os mesmos fluxos de trabalho, independente do seu grau de habilidade particular.

[00148] Em uma concretização alternativa, dada uma intervenção específica, os fluxos de trabalho apresentados a um engenheiro de campo dependem do seu próprio grau de habilidade. Se o engenheiro de campo for um perito, ele é apresentado com fluxos de trabalho de nível mais alto; caso contrário, os fluxos de trabalho propostos são mais detalhados ou em qualquer caso permitem acessar documentos e normas técnicas úteis para o engenheiro de campo. No primeiro caso, a seleção pelo Administrador Operacional OM dos fluxos de trabalho a serem postos na lista é, portanto, feita considerando só o tipo de intervenção a ser efetuada, enquanto, no segundo caso, também o perfil do engenheiro de campo é levado em conta e em particular o seu grau de habilidade com referência à habilidade requerida para efetuar a intervenção em questão.

[00149] Novamente, em uma concretização alternativa da presente invenção, a ativação do fluxo de trabalho na Proxy Pessoal PP não envolve ativação de um fluxo de trabalho cooperativo na Proxy de Recurso RP: o fluxo de trabalho na Proxy Pessoal PP só ativa de um modo interativo fluxos de trabalho específicos na Proxy de Recurso RP a fim de juntar alguns determinados dados/medições, para pedir execução de dadas atividades no equipamento, ou fazer disponível um acesso remoto a possíveis interfaces de linha de comando. Os fluxos de trabalho executam o que é pedido e retornam

Petição 870180145819, de 29/10/2018, pág. 55/82 / 49 o resultado à Proxy Pessoal PP. Neste caso, a Proxy de Recurso RP não sabe o que o operador, guiado pela Proxy Pessoal PP, está fazendo. Isto requer que, como última etapa, o fluxo de trabalho na Proxy Pessoal PP deveria pedir para a Proxy de Recurso RP verificar o resultado da intervenção efetuada pelo engenheiro de campo, antes de considerar dita intervenção efetuada com êxito.

[00150] Como foi visto, o procedimento para suportar um consultor de Centro de Chamada permite ativar, sempre que necessário, um fluxo de trabalho na Proxy Pessoal PP do cliente. Isto requer a Proxy Pessoal PP estar ativa. Ativação da Proxy Pessoal PP pode ocorrer automaticamente, com um pedido para ativação da Proxy Pessoal PP do operador ou senão em modo manual, com ativação da Proxy Pessoal PP pelo cliente. Neste caso anterior, a própria Proxy Pessoal PP já pode estar no dispositivo de cliente e deve apenas ser ativada, ou senão o cliente pode carregá-la de um local provido propositalmente. Em uma concretização alternativa, dito procedimento não idealiza ativação de um fluxo de trabalho na Proxy Pessoal PP do cliente: o consultor de Centro de Chamada só interage com o cliente por meio de um paradigma de pergunta-resposta, no máximo lhe pedindo para efetuar algumas ações particulares.

[00151] Também o procedimento para suportar o cliente idealiza uma concretização alternativa na qual, uma vez a Proxy Pessoal PP detectou a necessidade para contatar um consultor de Centro de Chamada para resolver o mau funcionamento informado pelo cliente, em vez de sugerir ao cliente para contatar o Centro de Chamada, ativa diretamente uma sessão com a Proxy Pessoal PP de um consultor de Centro de Chamada.

[00152] Com respeito à cooperação entre operadores, pode ser notado novamente o que é descrito na sequência. O procedimento descrito com referência à Figura 7 idealiza preparar uma lista ordenada de nomes de operadores a serem contatados, usada pelo PP para abrir uma sessão entre

Petição 870180145819, de 29/10/2018, pág. 56/82 / 49 operadores ou então apresentada ao operador: dita lista é criada de um modo dinâmico. No momento em que a Proxy Pessoal PP deveria abrir um sessão cooperativa, pede para o Administrador Operacional OM criar a lista dos operadores a serem contatados, provendo-o com as indicações requeridas (por exemplo, indicação da atividade executada pelo operador e da habilidade requerida para dita atividade); o Administrador Operacional OM examina o Inventário de Perícia EI e, baseado na informação obtida, prepara a lista requerida (entrando com operadores da mesma Equipe Virtual ou até mesmo de outras Equipes). A lista é ordenada de acordo com as habilidades dos operadores e, no caso de equipes diferentes, de acordo com as Equipes (primeiro os operadores da mesma Equipe Virtual são entrados, de acordo com o grau decrescente de habilidade, então os operadores de outras Equipes, uma vez mais em grau decrescente de habilidade). Finalmente, o Administrador Operacional OM envia a lista criada à Proxy Pessoal PP.

[00153] Em uma concretização alternativa à previamente apresentada, a Proxy Pessoal PP pode abrir sessões entre operador e dois ou mais outros operadores, que podem interagir entre si por várias ferramentas, incluindo ferramentas para suportar trabalho cooperativo.

[00154] Também no caso de cooperação entre cliente e operador, as mesmas modalidades são aplicadas de criação dinâmica, pelo Administrador Operacional OM, da lista de operadores a serem contatados, usada pela Proxy Pessoal PP para abrir uma sessão entre cliente e operador, ou senão apresentada ao cliente.

[00155] Levando em conta agora a administração dos perfis de operador na Proxy Pessoal PP em uma concretização alternativa à apresentada acima, cada PP mantém, além do perfil do operador ao qual está associado, também os dados de outros perfis de operador (isto é feito por razão de desempenho: deste modo, tempo para acessar dados de outros operadores a serem contatados diminui). Em particular, uma primeira alternativa idealiza que dito

Petição 870180145819, de 29/10/2018, pág. 57/82 / 49 dados deveriam se referir a todos os operadores na mesma Equipe Virtual como aquela do operador ao qual a Proxy Pessoal PP está associada. Uma segunda alternativa também é possível, de acordo com a qual os dados sobre os perfis de operador armazenados na Proxy Pessoal PP se referem a um subconjunto dos operadores na Equipe Virtual de interesse e em particular consideram os operadores equipados, a um grau alto, com as macrohabilidades requeridas à Equipe: para cada macro-habilidade, um ou mais perfis são selecionados; estes perfis são os perfis de operadores que são peritos com respeito a uma macro-habilidade específica (isto é, cuja habilidade é a mais alta entre as de uma dada Equipe Virtual). Os modos que ditos dados são carregados pela primeira vez e são atualizados subsequentemente não mudam com respeito ao que foi descrito para o perfil do operador associado à Proxy Pessoal PP; neste caso, porém, nos dados remetidos à Proxy Pessoal PP, também há a indicação de quais se referem ao perfil do operador associado à própria Proxy Pessoal PP.

[00156] Administração dos perfis de operador em uma concretização adicional é completamente dinâmica, no senso que a Proxy Pessoal PP não está associada a priori a qualquer operador específico: a associação com um dado operador é feita quando o operador se autentica. Neste caso, seguindo na autenticação pelo operador, a Proxy PP remete ao Administrador Operacional OM os dados de autenticação providos pelo operador e lhe pede para carregar os dados de perfil relativos a dito operador. O Administrador Operacional OM, depois de verificação anterior da perfeição das credenciais providas, carrega sobre o PP os dados do perfil em questão. Também neste caso, é possível idealizar uma concretização alternativa na qual o Administrador Operacional OM envia à Proxy Pessoal PP não só os dados do perfil do operador ao qual está associado, mas também os dados de outros perfis de operador, com as mesmas opções vistas acima (dados se referindo a todos os operadores da Equipe Virtual do operador, ou a um subconjunto dos

Petição 870180145819, de 29/10/2018, pág. 58/82 / 49 operadores da Equipe Virtual).

[00157] Com respeito ao procedimento de administração dos fluxos de trabalho para suportar operadores, com respeito ao que foi mencionado previamente, é possível idealizar concretizações alternativas das modalidades a serem adotadas para carregar os fluxos de trabalho.

[00158] Uma primeira concretização idealiza que na iniciação da Proxy Pessoal PP todos os fluxos de trabalho para guiar o operador são carregados nela.

[00159] De acordo com uma segunda concretização, ao invés, na iniciação da Proxy Pessoal PP ou depois de autenticação do operador (de acordo com se a Proxy Pessoal PP está associada a um operador de um modo estático ou dinâmico), todos os fluxos de trabalho para guiar o operador são carregados nela com a exclusão de possível fluxos de trabalho aplicáveis só a Equipes Virtuais específicas. É possível definir fluxos de trabalho que só se aplicam a Equipes Virtuais específicas, baseado nas características dos equipamentos administrados por estas equipes e/ou baseado nas habilidades particulares dos membros da equipe.

[00160] Finalmente, de acordo com uma terceira concretização, na iniciação da Proxy Pessoal PP ou a jusante da autenticação de operador, só os fluxos de trabalho que são consistentes com as habilidades do operador ao qual a PP está associada são carregados nela.

[00161] Na base de possíveis concretizações alternativas adotadas, também as funções da Interface PI podem mudar: em particular, se a única indicação recebida pelo engenheiro de campo na Interface PI for a relativa ao local para o qual ele deve ir, a Interface PI apresentará ao engenheiro de campo o conjunto das intervenções a serem feitas em um dado local (consistentemente com o perfil do engenheiro de campo), e será o próprio engenheiro de campo que selecionará a intervenção a ser efetuada e se encarregar disto.

Petição 870180145819, de 29/10/2018, pág. 59/82 / 49 [00162] Consequentemente, sem prejuízo para os princípios subjacentes à invenção, os detalhes e as concretizações pode variar, até mesmo apreciavelmente, com respeito ao que foi descrito aqui puramente por meio de exemplo, sem partir da extensão da invenção como definida pelas reivindicações anexas.

Claims (45)

1. REIVINDICAÇÕES

   1. Método para gerar sinais de instrução arranjados em fluxos de trabalho para executar intervenções em equipamentos de rede incluídos em uma rede de comunicação (N), em que ditos equipamentos de rede tem agentes de Proxy de Recurso (RP1, ..., RPn) associados, caracterizado pelo fato de que inclui as etapas de:

   prover uma arquitetura distribuída de agentes de proxy de administração de intervenção (PP1, ..., PPn) para administrar intervenções nos equipamentos de rede, ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) estando associados a dispositivos terminais; e gerar sinais de instrução para executar uma intervenção em pelo menos um equipamento de rede de dita rede de comunicação (N) por um de ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) de uma maneira interativa (PTP) com pelo menos um de ditos agentes de Proxy de Recurso (RP1, ..., RPn) associados com dito equipamento de rede, por meio de que ditos sinais de instrução são uma função do estado de dito equipamento de rede.
2. 2. Método de acordo com a reivindicação 1, caracterizado pelo fato de que cada um de dito agente de Proxy de Recurso (RP1, ..., RPn) é responsável por administrar um único equipamento de rede.
3. 3. Método de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que cada um de ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) é responsável por administrar um único dispositivo terminal.
4. 4. Método de acordo com a reivindicação 1, caracterizado pelo fato de que inclui a etapa de acoplar com ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) interfaces pessoais (PI) para gerar ditos sinais de instrução arranjados em fluxos de trabalho.
5. 5. Método de acordo com a reivindicação 1, caracterizado pelo

   Petição 870180145819, de 29/10/2018, pág. 61/82

   2 / 9 fato de que inclui a etapa de arranjar dita arquitetura distribuída em camadas hierárquicas incluindo:

   - uma camada de Agentes Operacionais (OA1, ..., OAk) coordenando operação de ditos agentes de proxy de administração de intervenção (PP1, ..., PPn); e

   - uma camada incluindo um Administrador Operacional (OM) tendo funções de administração e controle e supervisionando operação de ditos Agentes Operacionais (OA1, ..., OAk).
6. 6. Método de acordo com a reivindicação 5, caracterizado pelo fato de que inclui a etapa de dividir a ditos Agentes Operacionais (OA1, ..., OAK) a execução distribuída de intervenções através de uma pluralidade de ditos agentes de proxy de administração de intervenção (PP1, ..., PPn).
7. 7. Método de acordo com a reivindicação 1, caracterizado pelo fato de que inclui a etapa de arranjar dita arquitetura distribuída em camadas hierárquicas, em que uma camada inclui um Administrador Operacional (OM) tendo funções de administração e controle e coordenando diretamente a operação de ditos agentes de proxy de administração de intervenção (PP1, ..., PPn).
8. 8. Método de acordo com a reivindicação 5 ou 7, caracterizado pelo fato de que inclui a etapa de dividir, para cada um de ditos agentes de proxy de administração de intervenção (PP1, ..., PPn), a tarefa de suportar um único operador ou cliente, por meio de que execução de ditas intervenções é desacoplada com respeito a ditas funções de administração e controle.
9. 9. Método de acordo com a reivindicação 1, caracterizado pelo fato de que inclui a etapa de prover máquinas de processo (PE) a ditos agentes de proxy de administração de intervenção (PP1, ..., PPn).
10. 10. Método de acordo com a reivindicação 5 ou 7, caracterizado pelo fato de que inclui a etapa de prover máquinas de processo (PE) para todas as camadas em dita arquitetura distribuída.

    Petição 870180145819, de 29/10/2018, pág. 62/82

    3 / 9
11. 11. Método de acordo com a reivindicação 9 ou 10, caracterizado pelo fato de que prover máquinas de processo (PE) inclui a etapa de prover pelo menos dito um de um fluxo de trabalho, uma máquina de regras e combinação disso.
12. 12. Método de acordo com a reivindicação 5 ou 7, caracterizado pelo fato de que inclui a etapa de incluir em ditos componentes de camadas (PP, OA, OM) adaptados para executar funções respectivas baseado em informação de instrução respectiva provida a eles.
13. 13. Método de acordo com a reivindicação 12, caracterizado pelo fato de que inclui a etapa de prover em dita informação de instrução pelo menos um de:

    - uma definição de processo, que inclui pelo menos um de um fluxo de trabalho e uma regra; e

    - uma definição de modelos de dados.
14. 14. Método de acordo com a reivindicação 1, caracterizado pelo fato de que inclui a etapa de configurar ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) para interagir diretamente entre si em uma relação intertrabalho, por meio de que pelo menos um de ditos sinais de instrução é produzido por interação entre agentes de proxy de administração de intervenção (PP1, ..., PPn).
15. 15. Método de acordo com a reivindicação 1, caracterizado pelo fato de que inclui a etapa de configurar ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) para interação de ponto a ponto (PTP) com ditos agentes de Proxy de Recurso (RP1, ..., RPn).
16. 16. Método de acordo com a reivindicação 1, caracterizado pelo fato de que inclui a etapa de organizar um Banco de Dados Operacional (ODB) como um repositório de definições de processo e definições de modelo de dados de ditas intervenções.
17. 17. Método de acordo com a reivindicação 1, caracterizado

    Petição 870180145819, de 29/10/2018, pág. 63/82

    4 / 9 pelo fato de que inclui a etapa de organizar um Banco de Dados de Modelo (MDB) como um repositório de definições de processo e definições de modelo de dados para administrar ditos equipamentos de rede.
18. 18. Método de acordo com a reivindicação 5 ou 7, caracterizado pelo fato de que inclui a etapa de organizar um único Banco de Dados de Desempenho (PDB) armazenando dados de desempenho relacionados a ditas camadas de dita arquitetura distribuída.
19. 19. Método de acordo com a reivindicação 1, caracterizado pelo fato de que inclui a etapa de organizar um Registro Operacional (OL) armazenando todas as atividades executadas por usuários de ditos agentes de proxy de administração de intervenção (PP1, ..., PPn).
20. 20. Método de acordo com a reivindicação 1, caracterizado pelo fato de que inclui a etapa de organizar um Inventário de Perícia (EI) armazenando perfis de operadores ou clientes administrados por ditos agentes de proxy de administração de intervenção (PP1, ..., PPn).
21. 21. Método de acordo com a reivindicação 5 ou 7, caracterizado pelo fato de que inclui a etapa de prover os agentes de controle (CA) associados a pelo menos uma camada de dita arquitetura distribuída para executar pelo menos uma etapa selecionada do grupo consistindo em:

    - distribuir definições de processo para ditas camadas de dita arquitetura distribuída;

    - distribuir definições de modelo de dados para ditas camadas de dita arquitetura distribuída; e

    - monitorar o estado de ditas camadas de dita arquitetura distribuída.
22. 22. Método de acordo com a reivindicação 21, caracterizado pelo fato de que inclui a etapa de prover um módulo de administrador (MM) para executar pelo menos uma etapa selecionad do grupo consistindo em:

    - administrar a distribuição de definições de processo a ditas

    Petição 870180145819, de 29/10/2018, pág. 64/82

    5 / 9 camadas de dita arquitetura distribuída por ditos agentes de controle (CA);

    - administrar a distribuição de definições de modelo de dados a ditas camadas de dita arquitetura distribuída por ditos agentes de controle (CA); e

    - monitorar o estado de ditas camadas de dita arquitetura distribuída por ditos agentes de controle (CA).
23. 23. Sistema para gerar sinais de instrução arranjados em fluxos de trabalho para executar intervenções em equipamentos de rede incluídos em uma rede de comunicação (N), em que ditos equipamentos de rede tem agentes de Proxy de Recurso (RP1, ..., RPn) associados, o sistema caracterizado pelo fato de que inclui uma arquitetura distribuída de agentes de proxy de administração de intervenção (PP1, ..., PPn) para gerar ditos sinais de instrução, ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) estando associados a dispositivos terminais, em que ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) estão acoplados interativamente (PTP) com ditos agentes de Proxy de Recurso (RP1, ..., RPn) e em que ditos sinais de instrução são função do estado dos equipamentos de rede na qual ditas intervenções são executadas.
24. 24. Sistema de acordo com a reivindicação 23, caracterizado pelo fato de que cada um de dito agente de Proxy de Recurso (RP1, ..., RPn) é responsável por administrar um único equipamento de rede.
25. 25. Sistema de acordo com a reivindicação 23 ou 24, caracterizado pelo fato de que cada um de ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) é responsável por administrar um único dispositivo terminal.
26. 26. Sistema de acordo com a reivindicação 23, caracterizado pelo fato de que inclui interfaces pessoais (PI) acopladas com ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) para gerar ditos sinais de instrução arranjados em fluxos de trabalho.

    Petição 870180145819, de 29/10/2018, pág. 65/82

    6 / 9
27. 27. Sistema de acordo com a reivindicação 23, caracterizado pelo fato de que dita arquitetura distribuída inclui camadas hierárquicas incluindo:

    - uma camada de Agentes Operacionais (OA1, ..., OAk) coordenando a operação de ditos agentes de proxy de administração de intervenção (PP1, ..., PPn); e

    - uma camada incluindo um Administrador Operacional (OM) tendo funções de administração e controle e supervisionando a operação de ditos Agentes Operacionais (OA1, ..., OAk).
28. 28. Sistema de acordo com a reivindicação 27, caracterizado pelo fato de que ditos Agentes Operacionais (OA1, ..., OAk) são divididos para execução distribuída de intervenções através de uma pluralidade de ditos agentes de proxy de administração de intervenção (PP1, ..., PPn).
29. 29. Sistema de acordo com a reivindicação 23, caracterizado pelo fato de que dita arquitetura distribuída inclui camadas hierárquicas, em que uma camada inclui um Administrador Operacional (OM) tendo funções de administração e controle e supervisionando diretamente a operação de ditos agentes de proxy de administração de intervenção (PP1, ..., PPn).
30. 30. Sistema de acordo com a reivindicação 27 ou 29, caracterizado pelo fato de que cada um de ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) é dividido para a tarefa de suportar único operador ou cliente, por meio de que execução de ditas intervenções é desacoplada com respeito a ditas funções de administração e controle.
31. 31. Sistema de acordo com a reivindicação 21, caracterizado pelo fato de que ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) são configurados para interagir diretamente entre si em uma relação intertrabalho, por meio de que ditos sinais de instrução incluem sinais de instrução produzidos por interação entre agentes de proxy de administração de

    Petição 870180145819, de 29/10/2018, pág. 66/82

    7 / 9 intervenção (PP1, PPn).
32. 32. Sistema de acordo com a reivindicação 23, caracterizado pelo fato de que ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) incluem máquinas de processo respectivas (PE).
33. 33. Sistema de acordo com a reivindicação 27 ou 29, caracterizado pelo fato de que cada uma de ditas camadas inclui máquinas de processo (PE).
34. 34. Sistema de acordo com a reivindicação 32 ou 33, caracterizado pelo fato de que ditas máquinas de processo (PE) incluem pelo menos um de um fluxo de trabalho, uma máquina de regras e combinação disso.
35. 35. Sistema de acordo com a reivindicação 27 ou 29, caracterizado pelo fato de que ditas camadas em dita arquitetura incluem componentes (PP, OA, OM) adaptados para executar funções respectivas baseado em informação de instrução respectiva provida a eles.
36. 36. Sistema de acordo com a reivindicação 35, caracterizado pelo fato de que dita informação de instrução inclui pelo menos um de:

    - uma definição de processo, que inclui pelo menos um de um fluxo de trabalho e uma regra; e

    - uma definição de modelos de dados.
37. 37. Sistema de acordo com a reivindicação 23, caracterizado pelo fato de que ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) são configurados para interação de ponto a ponto (PTP) com ditos agentes de Proxy de Recurso (RP1, ..., RPn).
38. 38. Sistema de acordo com a reivindicação 23, caracterizado pelo fato de que inclui um Banco de Dados Operacional (ODB) como um repositório de definições de processo e definições de modelo de dados de ditas intervenções.
39. 39. Sistema de acordo com a reivindicação 23, caracterizado

    Petição 870180145819, de 29/10/2018, pág. 67/82

    8 / 9 pelo fato de que inclui um Banco de Dados de Modelo (MDB) como um repositório de definições de processo e definições de modelo de dados para administrar ditos equipamentos de rede.
40. 40. Sistema de acordo com a reivindicação 27 ou 29, caracterizado pelo fato de que inclui um único Banco de Dados de Desempenho (PDB) armazenando dados de desempenho relacionados a ditas camadas de dita arquitetura distribuída.
41. 41. Sistema de acordo com a reivindicação 23, caracterizado pelo fato de que inclui um Registro Operacional (OL) armazenando todas as atividades executadas por usuários de ditos agentes de proxy de administração de intervenção (PP1, ..., PPn).
42. 42. Sistema de acordo com a reivindicação 23, caracterizado pelo fato de que inclui um Inventário de Perícia (EI) armazenando perfis de operadores ou clientes administrados por ditos agentes de proxy de administração de intervenção (PP1, ..., PPn).
43. 43. Sistema de acordo com a reivindicação 27 ou 29, caracterizado pelo fato de que pelo menos uma camada de dita arquitetura distribuída inclui agentes de controle (CA) para executar pelo menos uma etapa selecionada do grupo consistindo em:

    - distribuir definições de processo para ditas camadas de dita arquitetura distribuída;

    - distribuir definições de modelo de dados para ditas camadas de dita arquitetura distribuída; e

    - monitorar o estado de ditas camadas de dita arquitetura distribuída.
44. 44. Sistema de acordo com a reivindicação 43, caracterizado pelo fato de que inclui um módulo de administrador (MM) para executar etapas selecionadas do grupo consistindo em:

    - administrar distribuição de definições de processo entre ditas

    Petição 870180145819, de 29/10/2018, pág. 68/82

    9 / 9 camadas de dita arquitetura distribuída por ditos agentes de controle (CA);

    - administrar distribuição de modelos de dados entre ditas camadas de dita arquitetura distribuída por ditos agentes de controle (CA); e

    - monitorar o estado de ditas camadas de dita arquitetura distribuída por ditos agentes de controle (CA).
45. 45. Meio de armazenamento legível por computador para gerar sinais de instrução arranjados em fluxos de trabalho para executar intervenções em equipamentos de rede incluídos em uma rede de comunicação (N), em que ditos equipamentos de rede tem agentes de Proxy de Recurso (RP1, ..., RPn) associados, caracterizado pelo fato de que compreende instruções legíveis por computador que, quando lidas por computador, fazem com que o mesmo realize as etapas de:

    prover uma arquitetura distribuída de agentes de proxy de administração de intervenção (PP1, ..., PPn) para administrar intervenções nos equipamentos de rede, ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) estando associados a dispositivos terminais; e gerar sinais de instrução para executar uma intervenção em pelo menos um equipamento de rede de dita rede de comunicação (N) por um de ditos agentes de proxy de administração de intervenção (PP1, ..., PPn) de uma maneira interativa (PTP) com pelo menos um de ditos agentes de Proxy de Recurso (RP1, ..., RPn) associados com dito equipamento de rede, por meio de que ditos sinais de instrução são uma função do estado de dito equipamento de rede.