BRPI0513004B1 - "system and method for processing data records, mediation system for handling event records, service supply system, and system and method of mediation for processing event records" - Google Patents

"system and method for processing data records, mediation system for handling event records, service supply system, and system and method of mediation for processing event records" Download PDF

Info

Publication number
BRPI0513004B1
BRPI0513004B1 BRPI0513004-2A BRPI0513004A BRPI0513004B1 BR PI0513004 B1 BRPI0513004 B1 BR PI0513004B1 BR PI0513004 A BRPI0513004 A BR PI0513004A BR PI0513004 B1 BRPI0513004 B1 BR PI0513004B1
Authority
BR
Brazil
Prior art keywords
data
function
network
parameter
processing
Prior art date
Application number
BRPI0513004-2A
Other languages
English (en)
Inventor
Talja Ari
Original Assignee
Comptel Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from EP20040396044 external-priority patent/EP1615127B1/en
Application filed by Comptel Corporation filed Critical Comptel Corporation
Publication of BRPI0513004A publication Critical patent/BRPI0513004A/pt
Publication of BRPI0513004B1 publication Critical patent/BRPI0513004B1/pt

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/448Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4482Procedural
    • G06F9/4484Executing subprograms

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Devices For Executing Special Programs (AREA)
  • Stored Programmes (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Debugging And Monitoring (AREA)

Abstract

processamento de dados em um sistema de aprovisionamento de mediação ou serviço. a presente invenção refere-se a um sistema e método de processamento de dados para processar os dados em uma mediação ou sistema de aprovisionamento de serviço de uma rede de comunicações. na invenção, uma estrutura de definição lógica especial está formada com base na lógica de processamento. a estrutura de definição lógica está projetada de modo que seja fácil de modificar e eficiente para executar. isto é tornado possível pela definição da lógica de processamento na forma de uma série de instruções de código de byte, em que cada instrução contém um apontador para uma peça de código de programa que executa uma função e um apontador para os parâmetros a serem utilizados na execução da função. as instruções, os códigos de programa que executam as funções, os apontadores e os dados sob processamento estão de preferência armazenados em redes assim permitindo a utilização de mecanismos de apontador eficientes juntamente com flexibilidade e facilidade de modificação.

Description

Relatório Descritivo da Patente de Invenção para "SISTEMA E MÉTODO PARA PROCESSAR REGISTROS DE DADOS, SISTEMA DE MEDIAÇÃO PARA MANIPULAR REGISTROS DE EVENTO, SISTEMA DE APROVISIONAMENTO DE SERVIÇO, E SISTEMA E MÉTODO DE MEDIAÇÃO PARA PROCESSAR REGISTROS DE EVENTOS".
Campo da Técnica A presente invenção refere-se a processamento de dados.
Especificamente, a presente invenção refere-se ao processamento de registros de dados estruturados, que contém campos de dados e dados nos campos de dados. Um exemplo de um tal registro de dados é um registro de evento que contém os dados sobre a utilização de uma rede de comunicações.
Por isto, uma modalidade da presente invenção refere-se a métodos e sistemas de mediação. A mediação é um processo em que os dados de utilização são coletados da rede de comunicações e fornecidos para o(s) Sistema(s) de Suporte de Operação e Comercial (OSS/BSS). O software de mediação coleta os dados de utilização da rede pelo interfaceamento de vários diferentes elementos de rede. A camada de mediação então agrega, correlaciona, enriquece, valida, formata e/ou classifica os dados de modo que estes sejam legíveis pelo(s) sistema(s) OSS/BSS alvo e esta contém todas as informações requeridas.
Nas redes de telecomunicações modernas, existe uma demanda para a manipulação de eventos logo que os dados estejam disponíveis na rede. Uma mediação de fluxo contínua, a qual é também denominada mediação em tempo real, foi desenvolvida para atender estas necessidades. Especialmente na mediação de fluxo contínuo, a qualidade, a confiabilidade e a eficiência do processamento de dados são muito importantes.
Nas redes de telecomunicações modernas, existe também uma necessidade de uma fácil adaptação do sistema para prover novos serviços e processar os registros de eventos de acordo com as necessidades de processamento variadas. Os objetivos acima mencionados estão freqüentemen-te em contraste uns com os outros: a fácil adaptação do sistema tende a re- duzir o rendimento enquanto que um sistema que tem um rendimento otimizado usualmente requer um trabalho intensivo para reconfigurar.
Outra modalidade da presente invenção refere-se a sistemas e métodos de aprovisionamento. O aprovisionamento de serviço e a ativação de serviço é um processo em que quaisquer tipos de serviços em todos os tipos de rede são aprovisionados e ativados para elementos de rede, Estes podem ser por exemplo ativar todos os serviços do consumidor e corporativos, tais como voz, ADSL, acesso de WLAN e VPN com o mesmo sistema de aprovisionamento ajuda o operador a remover muitos processos dispendiosos desnecessários e sobrepostos.
Antecedentes da Técnica A Publicação de Patente U.S. Número 6.449.618 descreve um sistema de processamento de eventos em tempo real. O sistema apresentado na publicação tem uma flexibilidade insatisfatória. A Publicação de Patente U.S. Número 6.366.657 descreve um sistema de suporte e gerenciamento de serviços de telecomunicações. A idéia de princípio da U.S. 6.366.657 é que o sistema compreende um Ambiente de Criação de Serviços (SCE), cujo ambiente permite criar prover e gerenciar novos serviços para os assinantes facilmente. Isto é feito por kits de ferramentas para especificaras definições do objeto em uma estrutura orientada em objeto. O sistema apresentado na publicação está destinado para operadores de telecomunicação para tomar os serviços mais fáceis.
Existem dois modos alternativos para desenvolver adicionalmente os sistemas conhecidos em uma tentativa de combinar a eficiência e a fácil modificação e gerenciamento. A primeira alternativa seria gerar alguma linguagem de script da lógica de processamento predefinida. Uma linguagem de script adequada é a Perl. A vantagem desta proposta é que o código resultante pode ser visto e é legível por pessoas. Por isto, o código é fácil de depurar. No entanto, existem diversas desvantagens na proposta de linguagem de script. Por exemplo, o desempenho é relativamente baixo já que as linguagens de script (mesmo a Perl) são mais lentas do que o código nativo. É também difícil gerar um código válido e assegurar que os nomes de variáveis etc. não causem nenhum conflito no sistema. A segunda alternativa seria gerar um código de fonte C ou Java e compilá-lo antes da execução. Esta solução produz um código mais rápido, se C for utilizado, porque nenhuma interpretação é necessária. O problema é compilar o código de fonte e assegurar que o sistema realmente funciona corretamente. A lógica criada deste modo não podería ser testada antes de entrar em uso, se mudanças realmente rápidas forem necessárias. Isto toma o sistema não confiável e arriscado. A compilação é também muito difícil se não impossível porque esta precisa ser executada no ambiente do cliente e em diferentes plataformas. Por isso, esta proposta envolve sérios riscos e é extremamente difícil. No entanto, se os problemas envolvidos nesta solução pudessem ser resolvidos, a solução oferecería um desempenho muito alto. Descrição da Invenção É um objetivo da presente invenção criar um sistema e método de processamento de dados confiável que tanto provenham um desempenho relativamente alto quanto sejam relativamente fáceis de adaptar a novas lógicas de processamento. O objetivo da invenção é conseguido pela formação de uma estrutura de definição lógica especial com base na lógica de processamento. A estrutura de definição lógica está projetada de modo que seja fácil de executar eficientemente. A estrutura de definição lógica está também projetada de modo que a execução de modificações na lógica de processamento requer alterações relativamente limitadas e diretas na estrutura de definição lógica. Isto é tornado possível pela definição da lógica de processamento na forma de uma série de instruções de código de byte, em que cada instrução contém um apontador para uma peça de código de programa que executa uma função e um apontador para os parâmetros a serem utilizados na execução da função. As instruções, os códigos de programa que executam as funções, os apontadores e os dados sob processamento estão de preferência armazenados em redes assim permitindo a utilização de mecanismos de apontador eficientes com flexibilidade e facilidade de modificação.
Em uma modalidade, a estrutura de definição lógica compreende uma rede de parâmetros que contém apontadores para os valores dos pa- râmetros necessários na lógica de processamento, um conjunto de códigos de função que contém os códigos de programa para executar as funções necessárias na lógica de processamento, e uma série de instruções de código de byte, cada uma das instruções apontando para os apontadores na rede de parâmetros e um código de função que são necessários na execução da instrução. A presente invenção toma possível construir um sistema e método de processamento de dados confiáveis que tanto provêem um desempenho relativamente alto quanto são relativamente fáceis de adaptar às novas lógicas de processamento. O conceito inventivo permite diversas modalidades úteis e vantajosas, as quais provêem vantagens adicionais.
Em uma modalidade da invenção a adaptação da lógica de a-provisionamento pode ser implementada e visualizada através da interface gráfica do usuário. Novos serviços e pacotes de serviços - independente de sua complexidade - podem ser rapidamente introduzidos sem precisar executar mudanças demoradas e dispendiosas no sistema OSS/BSS de um o-perador. A invenção oferece também modalidades de um sistema de mediação, o qual pode ser operado continuamente uma vez iniciado, porque todas as configurações podem ser feitas enquanto o sistema está em produção.
Existem também modalidades, as quais permitem tanto um processamento do tipo em batelada quanto um processamento em tempo real de registros de eventos.
Como fica aparente da descrição acima, a presente invenção pode ser aplicada em uma grande variedade de aplicações que requerem um processamento rápido e confiável de registros de eventos.
Breve Descrição dos Desenhos Para uma compreensão mais completa da presente invenção e das suas vantagens, a invenção será agora descrita com o auxílio dos e-xemplos e com referência aos desenhos seguintes, nos quais: a Figura 1 representa um diagrama de blocos de um sistema de acordo com uma modalidade da invenção. a Figura 2 apresenta um diagrama de blocos de um exemplo de funcionamento de acordo com uma modalidade da invenção. a Figura 3a apresenta um diagrama de blocos de um exemplo de execução de função de lógica de processamento de acordo com uma modalidade da invenção. a Figura 3b apresenta um diagrama de blocos de outro exemplo de execução de função de lógica de processamento de acordo com uma modalidade da invenção. a Figura 4 apresenta um diagrama de blocos de um exempio de uma execução de código de byte de acordo com uma modalidade da invenção. a Figura 5 apresenta um fluxograma de um processo de mediação de acordo com uma modalidade da invenção.
Definições Registro de Dados Um registro de dados é um registro que contém dados sobre por exemplo uma utilização de serviço ou solicitação de aprovisionamento. Um Registro de Dados tipicamente contém diversos campos de dados e pode ser estruturado (registros contém outros registros). Nos sistemas de comunicação os exemplos de registros de dados incluem tais como CDR, Registro de Detalhes de Chamada; ER, Registro de Evento; UDR, Registro de Utilização de Dados; e IPDR, Registro de Detalhes de Protocolo de Internet.
Campo O campo é uma unidade única de registro de dados. Normalmente o campo contém um valor que pode ser qualquer dado (data, inteiro, cadeia, etc.).
Evento Evento é uma transação que ocorre em uma rede de telecomunicações. Os eventos são tipicamente causados por ações tomadas por um assinante enquanto utilizando os serviços de telecomunicações. Os eventos podem também estar baseados em ações tomadas pela rede de telecomunicações ou por um aparelho conectado a esta, por exemplo, enquanto execu- tando os serviços de telecomunicações. Alguns eventos podem mesmo ser gerados automaticamente enquanto executando os programas de serviço e executando outras funções para prover os serviços para os clientes.
Registro de Evento O Registro de Evento é um registro de dados que indica que um evento ocorreu. Isto é, um registro de evento provê as informações de que um assinante utilizou um serviço de telecomunicações. O registro de evento contém também as informações detalhadas sobre o evento. Por isto, um registro de evento pode conter as informações sobre a utilização, por exemplo se o serviço de telecomunicações utilizado é uma chamada telefônica, o registro de evento pode indicar quanto tempo durou a chamada, ou se o serviço está carregando um arquivo de um servidor de FTP, o registro de evento pode conter as informações sobre o tamanho do bloco de dados transferido. Tempo Real Em contraste com o processamento em batelada, o processamento em tempo real refere-se a passar o registro de evento através do sistema de mediação em um formato de fluxo contínuo. Isto é, logo que um certo nodo no fluxo contínuo de mediação processou (por exemplo enriqueceu) o registro, este é passado para o próximo nodo. No processamento em batelada, um grande número de registros de eventos é primeiramente coletado em um armazenamento intermediário e então o batelada de registros de e-ventos é processado do armazenamento temporário. Por isto, no processamento em batelada, os retardos de processamento experimentados pelos registros de eventos são tipicamente longos e variam entre os registros de eventos. No processamento em tempo real, os retardos de processamento experimentados pelos registros de eventos são tipicamente curtos e substancialmente os mesmos em magnitude entre os registros de eventos. O tempo de atravessamento em um sistema em tempo real pode ser, por exemplo de aproximadamente 1 milissegundo a 10 segundos. Em algumas modalidades, os eventos podem atravessar o sistema ainda mais rápido. Algumas vezes, dependendo da modalidade e da aplicação, o termo tempo real pode também compreender tempos de atravessamento mais lon- gos do que acima declarado. Em geral, um serviço em tempo real é um serviço que não inclui retardos consideráveis de modo que o usuário do serviço considera que os atos sejam tomados e os serviços providos essencialmente no momento que os serviços são solicitados (isto é os eventos supridos para o sistema de mediação).
Registro de Entrada O registro de dados que é lido por um nodo de processamento. O formato e a estrutura do registro de entrada são de preferência predefini-dos e conhecidos pelo nodo.
Registro de Saída O registro de dados que é escrito por um nodo de processamento. O formato e a estrutura do registra de saída são de preferência predefini-dos e conhecidos pelo nodo.
Executor de Lóaica de Processamento O Executor de Lógica de Processamento é um aplicativo de nodo em um sistema de mediação. O Executor de Lógica de Processamento gerencia uma lógica de processamento predefinida em um fluxo contínuo de processamento. Este executa o conjunto de regras definido pelo usuário utilizando as funções para regras protótipo existentes.
Base de Nodo A Base de Nodo provê uma interface para ler os registros de entrada e escrever os registros de saída. O Executor de Lógica de Processamento consegue os valores de campo utilizando o nome do campo da Base de Nodo. A Base de Nodo implementa a funcionalidade para as operações como criar um novo registro de saída e rejeitar um registro existente.
Função (= Setas na Fiaura 2) Uma seta ou na realidade um grupo de setas que apontam para um único campo representam uma função. A Função é um protótipo de uma regra de processamento, por exemplo uma validação de campo, uma coincidência de valor ou uma conversão. Códlao de Função O código de função é um código de programa para executar uma função necessária na lógica predefinida. Em uma modalidade preferida, o código de função é um código binário diretamente executável por um sistema operacional. O código utiliza os parâmetros de função para as decisões que precisam ser tomadas durante a execução da função.
Instrução A instrução é uma unidade única de Código de Byte de Lógica de Processamento. Em uma modalidade preferida, uma instrução contém um apontador para o código de função, um apontador para os parâmetros de função e o número de parâmetros. As instruções são criadas durante o processo de compilação.
Executor de Códiao de Bvte O Executor de Código de Byte é o componente que cuida do recolhimento, decodificação e execução de instruções. Assim, o Executor de Código de Byte pega a próxima instrução da rede e chama a função da instrução utilizando os parâmetros da instrução.
Arquivos de Biblioteca Compartilhados Os arquivos de biblioteca compartilhados contém um código de função tanto para a função de núcleo quanto para a função personalizada. O código é produzido pelo compilador C e é rápido para executar. As funções são carregadas na memória dos arquivos quando o Executor de Lógica de Processamento é iniciado.
Melhor Modo para Executar a Invenção A Figura 1 mostra um exemplo de utilização de uma modalidade da invenção. O sistema da Figura 1 compreende uma interface gráfica do usuário 1 (GUI) para definir a lógica de processamento predefinida de acordo com a qual o usuário deseja que o sistema processe os registros de dados, tais como os registros de eventos ou uma rede de comunicações. A GU11 produz um arquivo de Lógica de processamento predefinida 2 que contém a Lógica de processamento predefinida, e cuida de salvar os dados em um armazenamento persistente, por exemplo um banco de dados 3. Na modalidade, o arquivo de Lógica de processamento predefinida 2 contém uma representação de XML da lógica construída com a GU11. 0 sistema compreende um Compilador 4 que utiliza o arquivo de Lógica de processamento predefinida 2 como um código de fonte e constrói um código de byte de Lógica de Processamento 5 com base na Lógica de processamento predefinida. A compilação é executada cada vez que a lógica e testada ou salva no armazenamento persistente 3. O armazenamento persistente 3 contém todas as configurações de Lógica de Processamento e os códigos de bytes compilados para as mesmas. O código de byte de Lógica de Processamento 5 é um arquivo de texto comum que descreve como a lógica de processamento predefinida deve ser executada. Este tem um conjunto de instruções sequencial e seus parâmetros. Todas as instruções são salvas utilizando os nomes de função originais. O sistema também compreende um Executor de Lógica de Processamento 6, o qual pode ser um aplicativo de nodo que pode ser executado utilizando a Base de Nodo. O próprio Executor de Lógica de Processamento 6 compreende uma biblioteca de funções 7, um analisador de código de byte 8 e um Executor de Código de Byte 9. A biblioteca de funções 7 contém todas as funções da Lógica de Processamento. Na Figura, a biblioteca de funções 7 está dividida em funções de núcleo 10 e funções personalizadas 11. O analisador de código de byte 8 analisa o código de byte de texto comum 5 e produz e produz uma forma mais eficiente do código. O código de byte completo não tem nenhum nome de função mas apontadores diretos para os mesmos. O Executor de Código de Byte 9 executa o código de byte analisado. Por isso o Executor de Código de Byte 9 atua como o meio de execução de lógica para executar a lógica de processamento predefinida. O código é executado "cegamente" sem conhecer o que as funções executam.
Por isto, na modalidade, uma interface gráfica do usuário pode ser utilizada para preparar o sistema para processar os registros de dados de acordo com uma lógica de processamento desejada. Após definira lógica de processamento, o Compilador analisa a lógica de processamento e a compila em um formato (código de byte de Lógica de Processamento) que é rápido e fácil de executar. O meio de compilação lê o arquivo de XML de lógica de processamento, cria uma estrutura de dados deste e produz um arquivo de código de byte utilizando a estrutura de dados. O compilador remove todas as informações "inúteis" que não são necessárias na execução da lógica de processamento e achata a estrutura da lógica. O compilador também reserva uma rede de campos na qual todos os campos estão colocados. Após isto os campos não são mais referenciados por seus nomes mas pelo índice da rede. O analisador de código de byte muda o índice para a localização de memória direta.
As instruções requeridas são acrescentadas no código de byte quando o compilador ou encontra uma função na definição de lógica de processamento ou necessita adicionar uma função para por exemplo saltar de um local para outro no código. Quando o compilador adiciona uma instrução, este também adiciona os parâmetros da função como uma lista de índices dos campos. O analisador de código de byte constrói a rede de parâmetros utilizando estas informações. Após a compilação ficar pronta, o compilador calcula os valores para os campos de cabeçalho de código de byte.
Em uma modalidade avançada, um usuário pode também definir e acrescentar funções personalizadas através da interface gráfica do usuário. Quando adicionando uma função personalizada, o sistema adiciona uma nova tela de plug-in para definir os parâmetros de função na interface gráfica do usuário. O sistema também adiciona um código de função correspondente na rede de códigos de função do Executor de Lógica de Processamento 6. Para a funcionalidade de função personalizada, o compilador inclui uma extensão de função personalizada para modificar a estrutura de definição de lógica para incluir a função personalizada e os parâmetros da função personalizada nas redes de campos do sistema. A Figura 2 mostra um exemplo do funcionamento do Executor de Lógica de Processamento 6. Na Figura 2, cada seta 10,11 (ou um grupo de setas que apontam para o mesmo campo) representa uma função de Lógica de Processamento. O Executor de Lógica de Processamento executa, em uma ordem especificada, o Código de Byte que o Compilador gerou. Cada seta na Figura representa uma função de Lógica de Processamento que e-xecuta a ação dependendo dos parâmetros de função (campos).
Na modalidade, os campos 22, 32 nos registros de entrada 20 e de saída 30 são os campos lidos pela base de nodo 130. A base de nodo 130 lê os campos 22 de um arquivo de entrada 20 e cria uma estrutura de dados 40 para o registro. Cada campo pode ser recolhido ou escrito utilizando o nome de campo. O Executor de Lógica de Processamento 6 não precisa ler todos os campos do registro de entrada.
Em uma modalidade, os campos internos 42 no Executor de Lógica de Processamento 6 são campos temporários que o Executor de Lógica de Processamento produziu. Os campos internos 42 podem conter os dados originais lidos da base de nodo 130 ou os dados gerados pelas funções 10, 11. Os campos internos 42 podem também ser constantes dentro do Executor de Lógica de Processamento 6.
Na modalidade, o Executor de Lógica de Processamento 6 aloca memória para todos os campos temporários 42 na fase de inicialização para tornar a execução mais eficiente. Os campos são crescidos automaticamente durante a execução se necessário. Os campos lidos da base de nodo não precisam de nenhum espaço (a base de nodo cuida disto) e estes não podem ser modificados dentro do Executor de Lógica de Processamento.
Na modalidade, os campos podem ser mapeados diretamente do registro de entrada 20 para o registro de saída 30 sem modificar o campo ou utiiizá-lo para quaisquer outros campos.
Na Figura, cada seta 10,11 (ou um grupo de setas que apontam para o mesmo campo) representa uma função no Executor de Lógica de Processamento 6. A função pode ser por exemplo uma concatenação de cadeia, a qual toma dois campos de entrada e produz um campo de saída. O código de byte de Lógica de Processamento 5 consiste em apontadores para estas funções 10,11 e seus parâmetros. A Figura 3 mostra dois exemplos de execuções de função de Lógica de Processamento em uma modalidade da invenção. Na modalidade à esquerda (Figura 3a) é um exemplo de função básica que toma quatro campos de entrada 22,42 e produz dois campos de saída 32, 42. Na modalidade à direita (Figura 3b) um exemplo tem uma função que toma três campos de entrada 22,42 e não produz nenhum campo de saída mas modifica o contador de programas 17 de acordo com os valores de campo.
Na modalidade, as instruções 62 em ambos os exemplos na Figura 3 são apontadores para os códigos de função 12. O código de função 12 existe na memória somente uma vez mesmo se existirem muitas instruções 62 utilizando-o. O Executor de Código de Byte 9 sempre executa a instrução 62 para a qual o seu contador de programas 17 aponta. O Executor de Código de Byte 9 aumenta o contador de programas 17 em um após cada chamada de função.
Na Figura 3b, o exemplo mostra como uma função pode atualizar o contador de programas. Por exemplo as funções de comparação, o salto incondicional etc. modificam o contador de programas. Isto significa que a execução "salta" para um local diferente no código.
Em uma modalidade, o Executor de Lógica de Processamento 6 consegue a sua configuração inteira em parâmetros de aplicativo de nodo e em arquivo de códigos de byte 5. Os parâmetros de aplicativo de nodo incluem todos os parâmetros específicos de lógica de processamento predefini-dos e os ajustes do Executor de Lógica de Processamento. Os pontos de ruptura no código de byte e outros parâmetros de depuração são determinados com a utilização de parâmetros de nodo se necessário. Estes parâmetros são utilizados por exemplo no modo de depuração. A Figura 4 mostra um exemplo de um Executor de Código de Byte 9 de acordo com uma modalidade da invenção. Na modalidade o Executor de Código de Byte 9 recolhe uma instrução 62 de cada vez. Uma única instrução 62 contém três partes: um apontador de função 70, um número de parâmetros 80 e apontador para parâmetros 90 da instrução 62. A Figura 4 descreve como uma única instrução 62 é manipulada pelo Executor de Código de Byte 9. Cada instrução 62 consiste nas seguintes partes: - Apontador de função 70 - O apontador de função aponta para o código de função real 12 que é utilizado na execução desta instrução 62. - Número de parâmetros 80 - A função pode utilizar um diferente número de parâmetros 52 dependendo da utilização da função. Por exemplo a função de coincidência de valor pode conseguir 3-N parâmetros dependendo do números de valores para coincidências. - Apontador para parâmetros 90 - O apontador para parâmetros aponta para a rede de parâmetros 50, a qual contém todos os parâmetros 52 necessários na lógica de processamento predefinida inteira. Todos os parâmetros 52 desta instrução 62 estão na rede 50 um após o outro. O apontador 90 refere-se ao primeiro parâmetro 54 e o número de parâmetros 80 diz quantos destes devem ser utilizados. A lista de parâmetros pode conter tantos os parâmetros de entrada quanto os de saída.
Na modalidade, a função pega tanto o número de parâmetros quanto o apontador para a lista de parâmetros como argumentos de função.
Em uma modalidade, o Executor de Código de Byte 6 manipula a execução do código de byte 5. A execução é executada cegamente, não se preocupando sobre as funções que são executadas. O código de byte 5 é dividido em três diferentes partes: partes de inicialização, processamento e desligamento. A execução de código de byte é uma tarefa direta: 1. Recolher a próxima instrução da lista de instruções (aquela à qual o contador de programas refere-se). 2. Chamar a função da instrução utilizando o contador de parâmetros e o apontador de parâmetro como parâmetros de função. 3. Verificar se a execução atingiu o final da lista de instruções. a. Se não, aumentar o contador de programas em um e pular para a parte um. b. Se a execução alcançou o final, retornar da função de processo e dar o controle de volta para a base de nodo. O Executor de Lógica de Processamento da modalidade acima descrita é um componente muito flexível. O usuário pode programar novas funções personalizadas no sistema sem modificar a implementação existen- te. Isto torna possível criar até uma lógica muito complicada utilizando a Lógica de Processamento e fazer modificações específicas do cliente no sistema se necessário sem afetar o desempenho. O Executor de Lógica de Processamento da modalidade acima descrita também provê um alto desempenho. O código extra de interpretação é mínimo nesta implementação significando que operar a lógica com o Executor de Lógica de Processamento é quase o mesmo que operar um programa de código nativo especificamente programado para a lógica do cliente. O Executor de Lógica de Processamento da modalidade acima descrita é também muito modular e assim fácil de testar. Cada função é um componente de software independente que pode ser testado com uma ferramenta automatizada. Isto economizará custos em transporte do produto e torna mais fácil implementar uma nova funcionalidade para o sistema.
Na modalidade da invenção, o código de byte de Lógica de Processamento 5 é armazenado em formato de texto comum para evitar os problemas com o transporte de uma plataforma para outra. O código de byte contém os seguintes componentes: - Cabeçalho - O cabeçalho contém as informações detalhadas sobre a lógica de processamento predefinida. - Campos - Esta seção contém as instruções para criar a rede de campos. Esta lista todos os campos, os seus comprimentos e valores iniciais. - Instruções - Esta seção lista as instruções e seus parâmetros.
Na modalidade da invenção, o analisador de código de byte 8 cuida da leitura do arquivo de código de byte 5, analisando-o quanto às estruturas internas e campos de pré-formatação. As estruturas internas incluem os seguintes componentes: - Redes de campo de dados 40 - Os campos estão armazenados em duas redes: uma contendo todos os inteiros e outra que contém todas as cadeias. Os campos são lidos e inicializados. A inicialização contém a alocação de memória e valor de ajuste, se necessário. - Rede de instruções 60 - As instruções estão armazenadas em uma longa rede. Estas estão armazenadas ali como descrito no projeto de Executor de Código de Byte de Lógica de Processamento.
Na modalidade da invenção, as funções de Lógica de Processamento 10,11 são testadas com uma ferramenta de teste automatizada. A idéia principal é que o desenvolvedor de função crie alguns dados de teste em um arquivo de texto em um formador definido e execute os casos de teste. A ferramenta de teste automatizada utiliza a biblioteca de funções de Lógica de Processamento 7 para carregar as funções 10,11 definidas no arquivo de casos de teste. Nenhuma codificação é necessária para os testes.
Uma modalidade da invenção pertence aos registros de dados de processamento nos sistemas de mediação com as redes de comunicações. As soluções de mediação sofisticadas têm diversos aspectos benéficos, dos quais os mais importantes estão abaixo apresentados.
Na Figura 5, cada nodo 120 inclui uma base de nodo 130 e um aplicativo de nodo 140. A base de nodo 130 provê uma funcionalidade padrão básica para o nodo 120. Este manipuía o mecanismo de transmissão de dados de utilização interna entre os nodos 120 e codifica os dados de utilização interna. A base de nodo 130 provê uma interface para o aplicativo de nodo 140 para acessar os dados de utilização e coletar as informações de auditoria personalizadas. Para executar as suas tarefas uma base de nodo 130 pode incluir diversos componentes, por exemplo uma entrada de nodo 131, uma saída de nodo 132, uma API de nodo 133, uma configuração de nodo 134 e uma auditoria de nodo 135. A Entrada de Nodo 131 é responsável por ler os dados, os registros de entrada 20, das fontes de dados de entrada internas, analisá-los e passar os dados para a interface de Aplicativo de Nodo. A Entrada de Nodo 131 utiliza a Interface de Transmissão de Dados que define o formato de dados internos e o mecanismo de transmissão de dados. A Saída de Nodo 132 é responsável por ler os dados, os registros de saída 30, da Interface de Aplicativo de Nodo e codificá-los e escrevê-los na Interface de Transmissão de Dados. A Saída de Nodo utiliza a Interfa- ce de Transmissão de Dados que define o formato de dados internos e o mecanismo de transmissão de dados. A API de Nodo 133 provê ao Aplicativo de Nodo o acesso aos dados de utilização. Esta "esconde" para a interface de transmissão de dados interna do Aplicativo de Nodo 140. A API de Nodo inclui uma funcionalidade para prover os dados de utilização para o e recebê-los do Aplicativo de Nodo 140. É também utilizada para recuperar as informações de auditoria personalizadas do Aplicativo de Nodo 140 e para prover os parâmetros de configuração para este. A Configuração de Nodo 134 é responsável por ver os dados de configuração da Interface de Configuração e para inicializar o Nodo de acordo com os dados parâmetros de configuração. A Configuração de Nodo também passa os parâmetros específicos de Aplicativo de Nodo para a API de Nodo. A Configuração de Nodo utiliza uma Interface de Configuração que define o formato de dados de configuração e o mecanismo de transmissão. A Auditoria de Nodo 135 é responsável por escrever vários dados de auditoria na Interface de Auditoria. A Auditoria de Nodo define o conteúdo para a interface de auditoria. A Auditoria de Nodo utiliza a Interface de Auditoria que define o formato de dados de auditoria padrão e o mecanismo de transmissão. A Auditoria de Nodo também utiliza uma Interface de Gerenciamento que define o formato de dados monitorados e o mecanismo de transmissão. Isto é utilizado por exemplo para indicar o status do Nodo. A Interface de Transmissão de Dados e/ou armazenamento temporário 145 define o formato de dados de utilização e o mecanismo de transmissão de dados entre os Nodos. A mediação consiste em diferentes processos como o coleta-mento, a validação, o enriquecimento, a agregação, a correlação, a classificação, a conversão e o fornecimento. A funcionalidade variada permite que os sistemas OSS/BSS recebam os dados de utilização como estes os desejam.
As palavras chave e a arquitetura de solução de mediação são a simplicidade e a retidão. O projeto modular da solução de acordo com uma modalidade da invenção permite processos em tempo real e distribuíveis, uma operação confiável e um alto desempenho.
Nodo (Processo de Mediação) Os Nodos 120 são componentes funcionais especializados em diferentes processos de mediação, tais como o coletamento, a agregação, a validação, a correlação e a formatação, ou uma combinação destes. Os Nodos estão ligados juntos para formarem fluxos de processamento para a manipulação de registro de evento.
Cada Nodo 120 tem uma funcionalidade padrão que provê um mecanismo de transmissão de dados automatizado entre os Nodos e um mecanismo de registro de informações de processamento entre o Nodo e o Gerenciador de Nodo (não mostrado na Figura). A lógica de processamento de dados de utilização real é implementada por diferentes aplicativos 140 que residem nos Nodos. Estes aplicativos 140 estão isolados do mecanismo de transmissão de dados interno e dos formatos de dados internos permitindo um mais fácil desenvolvimento de aplicativos. Os aplicativos 140 estão desenhados como ovais na Figura 5 apresentada. O sistema provê uma interface padrão através da qual os aplicativos comunicam-se com a estrutura de processamento.
Os Nodos 120 podem ser adicionalmente categorizados de a-cordo com a sua funcionalidade. A funcionalidade depende do Aplicativo de Nodo 140 e da posição do Nodo na Cadeia de Processamento 200. O primeiro Nodo 120 em uma Cadeia de Processamento pode ser denominado um Nodo de Coletor e o último Nodo um Nodo de Distribuição. Nestes casos a análise de dados e a funcionalidade de formatação precisam ser executadas pelo próprio aplicativo 140 e a funcionalidade padrão provida pela Base de Nodo 130 não é utilizada. O fluxo de dados de utilização e os componentes padrão que tornam-se obsoletos estão mostrados na Figura 5. Nesta i-magem é assumido que a fonte de dados 210 e o destino 220 ambos operam com algum protocolo de tempo real, isto é estas estão utilizando uma conexão de soquete para enviar e receber os dados.
Se o destino de dados de saída 220 requerer a utilização de uma interface baseada em arquivo, o aplicativo cuida da formatação e de escrever os dados nos arquivos de saída. Em um caso como este, pode ser necessário separar a geração de arquivo de saída e o fornecimento dos arquivos de saída para Nodos 120 separados.
Em uma modalidade da presente invenção o Executor de Lógica de Processamento 6 representa um exemplo de um aplicativo de nodo 140 utilizando nos sistemas de mediação. A descrição acima é somente para exemplificar a invenção e não pretende limitar o escopo de proteção oferecido pelas reivindicações. As reivindicações também pretendem cobrir os seus equivalentes e não devem ser consideradas literalmente.
REIVINDICAÇÕES

Claims (38)

1. Sistema para processar registros de dados de acordo com uma lógica de processamento predefinida, os ditos registros de dados tendo uma forma especificada com campos de dados e dados nos ditos campos de dados, o sistema compreendendo uma rede de campos de dados que contém campos para armazenar dados sob processamento no sistema, uma estrutura de definição lógica que contém a lógica de processamento predefinida, e um programa de execução e um processador para executar a lógica de processamento predefinida contida na estrutura de definição lógica, em que a estrutura de definição lógica compreende: uma rede de parâmetros que contém uma pluralidade de apontadores, cada um apontando para um campo de dados na rede de campos de dados que contém um valor de um parâmetro necessário na execução da lógica de processamento predefinida, um conjunto de códigos de função que contém códigos de programa para executar as funções necessárias na execução da lógica de processamento predefinida, e caracterizado pelo fato de que a estrutura de definição lógica compreende ainda uma série de instruções de código de byte, em que cada instrução de código de byte contém: um apontador de função que aponta para um código de função no conjunto de códigos de função para ser utilizado na execução da instrução, e um apontador para parâmetros que aponta para um conjunto de apontadores na rede de parâmetros, os valores apontados pelos quais são necessários na execução da instrução, em que a execução da estrutura de definição lógica pelo programa de execução e pelo processador faz com que o sistema processe um registro de dados de acordo com a lógica de processamento predefinida.
2. Sistema de acordo com a reivindicação 1, caracterizado pelo fato de que é configurado para receber os registros de dados de entrada que tem uma forma especificada com os campos de dados e os valores nos ditos campos de dados.
3. Sistema de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que é configurado para produzir os registros de dados de saída que tem uma forma especificada com os campos de dados e os valores nos ditos campos de dados.
4. Sistema de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de que a rede de campos de dados contém campos de dados para o armazenamento de valores dos parâmetros necessários na lógica predefinida, campos para armazenar os valores lidos de um registro de dados sob processamento, e campos para escrever as saídas das funções.
5. Sistema de acordo com a reivindicação 4, caracterizado pelo fato de que os apontadores para os campos de dados na rede de parâmetros são apontadores diretos para as localizações de memória dos campos na rede de campos de dados.
6. Sistema de acordo com qualquer uma das reivindicações 1 a 5, caracterizado pelo fato de que enquanto o sistema está na operação e processando um registro de dados, os valores armazenados na rede de campos de dados contém: os valores para os parâmetros da lógica predefinida, e os valores do registro de dados sob processamento, e quando o processamento está pronto, os valores armazenados na rede de campos de dados também contém: os valores para a saída do processo, e pelo menos alguns valores intermediários, se estes fossem necessários no processamento do registro de dados.
7. Sistema de acordo com qualquer uma das reivindicações 1 a 6, caracterizado pelo fato de que cada apontador na rede de parâmetros aponta para um único campo de dados na rede de campos de dados.
8. Sistema de acordo com qualquer uma das reivindicações 1 a 7, caracterizado pelo fato de que o sistema contém pelo menos dois apontadores diferentes que apontam para um campo de dados comum na rede de campos de dados.
9. Sistema de acordo com qualquer uma das reivindicações 1 a 8, caracterizado pelo fato de que o conjunto de códigos de função contém uma função que tem um número de parâmetros e outra função que tem um número de parâmetros diferente.
10. Sistema de acordo com qualquer uma das reivindicações 1 a 9, caracterizado pelo fato de que o conjunto de códigos de função é dinamicamente extensível.
11. Sistema de acordo com qualquer uma das reivindicações 1 a 10, caracterizado pelo fato de que os códigos de programa no conjunto de códigos de função estão na forma de um código binário diretamente executável por um sistema operacional.
12. Sistema de acordo com qualquer uma das reivindicações 1 a 11, caracterizado pelo fato de que a construção da rede de parâmetros é tal que cada conjunto de parâmetros necessário na execução das instruções de codificação de byte está formado por parâmetros consecutivos na rede de parâmetros.
13. Sistema de acordo com a reivindicação 12, caracterizado pelo fato de que o apontador para parâmetros contém um apontador para o primeiro parâmetro e um número dos parâmetros necessários na execução da instrução de código de byte.
14. Sistema de acordo com qualquer uma das reivindicações 1 a 13, caracterizado pelo fato de que o apontador de função e o apontador para parâmetros estão na forma de apontadores diretos que apontam para os locais de memória.
15. Sistema de acordo com qualquer uma das reivindicações 1 a 14, caracterizado pelo fato de que o meio de execução lógico compreende: um contador de programas que apontam para uma instrução de código de byte na série de instruções de código de byte, um meio para reinicializar o contador de programas de modo que o contador de programas aponte para a primeira instrução de código de byte quando o meio de execução de lógica começa a processar um novo registro de dados, e um meio para ajustar o contador de programas para apontar para a instrução de código de byte seguinte após cada chamada de função.
16. Sistema de acordo com a reivindicação 15, caracterizado pelo fato de que pelo menos um código de função no conjunto de códigos de função compreende um meio de código de programa para mudar o valor de contador de programas.
17. Sistema de acordo com qualquer uma das reivindicações 1 a 16, caracterizado pelo fato de que compreende: uma interface gráfica do usuário para definir a lógica predefinida, um compilador para compilar a lógica predefinida para produzir uma série de instruções de código de byte e os parâmetros para as ditas instruções, e um analisador de código de byte para analisar a série de instruções de código de byte para formar a estrutura de definição lógica que compreende as instruções na forma dos apontadores de função e dos apontadores para parâmetros.
18. Sistema de acordo com a reivindicação 17, caracterizado pelo fato de que compreende uma funcionalidade para adicionar uma função personalizada no conjunto de códigos de função, e para efetuar a dita funcionalidade: um meio para exibir uma tela na interface gráfica do usuário para definir os parâmetros da função personalizada, e uma extensão de função personalizada no compilador para modificar a estrutura de definição lógica para incluir a função personalizada e os parâmetros da função personalizada.
19. Sistema de mediação para manipular registros de evento em uma rede de comunicações entre uma camada de geração de eventos e uma camada de sistema de operação de eventos, o sistema caracterizado pelo fato de que compreende pelo menos um nodo que compreende o sistema de acordo com qualquer uma das reivindicações 1 a 18, para processar os registros de eventos.
20. Sistema de mediação de acordo com a reivindicação 19, caracterizado pelo fato de que o dito pelo menos um nodo inclui: um meio de programa de base de nodo capaz de prover uma funcionalidade de software básica para o nodo, a dita funcionalidade de software básica incluindo uma interface externa do nodo e uma interface interna do nodo, um meio de interface de programação de aplicativo para receber os programas de aplicativos para o nodo, cujos programas de aplicativos são capazes de interfacear com a interface interna do nodo, e um programa de aplicativo, e em que a estrutura de definição lógica está contida no programa de aplicativo do nodo.
21. Sistema de aprovisionamento de serviço para aprovisionar e ativar serviços em uma rede de comunicações, caracterizado pelo fato de que o sistema compreende o sistema de acordo com qualquer uma das reivindicações 1 a 18, para definir o processamento de dados em pelo menos um dos elementos de rede.
22. Método para processar registros de dados que tem uma pluralidade de campos de dados e de valores em pelo menos alguns dos ditos campos de dados, o método compreendendo: ler os valores de pelo menos alguns dos campos de dados de um registro de dados, escrever os valores lidos em campos de uma rede de campos de dados, processar os valores do registro de dados nos campos da rede de campos de dados pela execução de uma seqüência de instruções, caracterizado pelo fato de que cada instrução na seqüência executada está em uma forma de código de byte e contém: um apontador de função que aponta para um código de função em uma rede de códigos de função, e um apontador para parâmetros que aponta para um conjunto de apontadores de valor de parâmetro em uma rede de pa- râmetros, o dito processamento incluindo executar cada um dos códigos de função apontados utilizando os valores apontados pelo conjunto apontado de apontadores de valor de parâmetro, em que a execução da seqüência de instruções faz com que os valores do registro de dados sejam processados de acordo com uma lógica de processamento predefinida.
23. Método de acordo com a reivindicação 22, caracterizado pelo fato de que as instruções na seqüência de instruções executada estão armazenadas em uma rede de instruções.
24. Método de acordo com a reivindicação 23, caracterizado pelo fato de que a seqüência de instruções executada contém pelo menos uma subseqüência de instruções, e as instruções na pelo menos uma subse-qüência de instruções estão localizadas consecutivamente na rede de instruções.
25. Método de acordo com a reivindicação 23 ou 24, caracterizado pelo fato de que a etapa de processar os dados compreende para cada instrução na seqüência de instrução: ler um contador de programas que aponta para uma instrução na rede de instruções, recolher as instruções apontadas pelo contador de programas, chamar a função apontada e fornecer o apontador para parâmetros como um argumento, e incrementar o contador de programas.
26. Método de acordo com qualquer uma das reivindicações 22 a 25, caracterizado pelo fato de que compreende produzir pelo menos um registro de dados de saída após executar a seqüência de instruções, em que pelo menos um registro de dados de saída inclui uma pluralidade de campos de dados e a etapa de produzir pelo menos um registro de dados de saída compreende: ler os valores em pelo menos alguns dos campos na rede de campos de dados, e escrever os valores lidos da rede de campos de dados nos cam- pos de dados de pelo menos um registro de dados de saída.
27. Método de acordo com qualquer uma das reivindicações 22 a 26, caracterizado pelo fato de que o apontador de função e o apontador para parâmetros estão na forma de apontadores diretos que apontam para as localizações de memória.
28. Método de acordo com qualquer uma das reivindicações 22 a 27, caracterizado pelo fato de que cada um dos apontadores de valor de parâmetro aponta para um único campo na rede de campos de dados e está na forma de um apontador direto que aponta para uma localização de memória.
29. Método de acordo com qualquer uma das reivindicações 22 a 28, caracterizado pelo fato de que os valores sob processamento estão armazenados na rede de campos de dados, os ditos valores incluindo os valores dos parâmetros necessários na lógica predefinida, os valores lidos do registro de dados sob processamento, e a saída das funções.
30. Método de acordo com qualquer uma das reivindicações 22 a 29, caracterizado pelo fato de que o mesmo valor de parâmetro é utilizado em mais do que uma função.
31. Método de acordo com qualquer uma das reivindicações 22 a 30, caracterizado pelo fato de que os códigos de função no conjunto de códigos de função estão na forma de um código binário diretamente executável por um sistema operacional.
32. Método de acordo com qualquer uma das reivindicações 22 a 31, caracterizado pelo fato de que os ditos registros de dados são registros de eventos em um sistema de mediação de uma rede de comunicações.
33. Método de acordo com qualquer uma das reivindicações 22 a 32, caracterizado pelo fato de que compreende as etapas de receber uma lógica de processamento de uma interface gráfica do usuário e formar a se-qüência de instruções com base na lógica de processamento recebida.
34. Método de acordo com a reivindicação 33, caracterizado pelo fato de que a etapa de formar a seqüência de instruções com base na lógica de processamento recebida compreende: compilar a lógica de processamento recebida para produzir uma série de instruções de código de byte e os parâmetros para as ditas instruções; e analisar a série de instruções de código de byte para formar a seqüência de instruções, em que as instruções estão na forma dos apontadores de função e os apontadores para os parâmetros.
35. Método de acordo com qualquer uma das reivindicações 22 a 34, caracterizado pelo fato de que após o processamento de um registro de dados o método compreende repetir o método com outro registro de dados.
36. Método de acordo com a reivindicação 35, caracterizado pelo fato de que os valores de um registro de dados subseqüente é escrito na mesma rede de campos de dados para substituir pelos valores de um registro de dados precedente.
37. Sistema de mediação para processar registros de eventos de acordo com uma lógica de processamento predefinida, os ditos registros de eventos tendo uma forma especificada com campos de dados e dados nos eventos nos ditos campos de dados, o sistema compreendendo uma rede de campos de dados que contém os campos para armazenar dados sob processamento no sistema, uma estrutura de definição lógica que contém a lógica de processamento predefinida e um programa de execução e um processador para executar o processamento predefinido contido na estrutura de definição lógica, em que a estrutura de definição lógica compreende: uma rede de parâmetros que contém uma pluralidade de apontadores cada um apontando para um campo de dados na rede de campos de dados que contém um valor de um parâmetro necessário na execução da lógica de processamento predefinida, um conjunto de códigos de função que contém códigos para executar as funções necessárias na execução da lógica de processamento predefinida, e caracterizado pelo fato de que a estrutura de definição lógica compreende ainda uma série de instruções de código de byte em que cada instrução de código de byte contém: um apontador de função que aponta para um código de função no conjunto de códigos de função para ser utilizado na execução da instrução, e um apontador para parâmetros que aponta para um conjunto de apontadores na rede de parâmetros os valores apontados pelos quais são necessários na execução da instrução, em que a execução da estrutura de definição lógica pelo programa de execução e pelo processador faz com que o sistema de mediação processe um registro de evento de acordo com a lógica de processamento predefinida.
38. Método de mediação para processar registros de eventos de acordo com uma lógica de processamento predefinida recebida de uma interface do usuário, os ditos registros de eventos tendo uma forma especificada com campos de dados e dados nos eventos nos ditos campos de dados, o método compreendendo: formar uma estrutura de definição lógica que contém a lógica de processamento predefinida, em que a estrutura de definição lógica compreende: uma rede de parâmetros que contém uma pluralidade de apontadores cada um apontando para um campo de dados na rede de campos de dados que contém um valor de um parâmetro necessário na execução da lógica de processamento predefinida, um conjunto de códigos de função que contém códigos de programa para executar as funções necessárias na execução da lógica de processamento predefinida, e caracterizado pelo fato de que a estrutura de definição lógica compreende ainda uma série de instruções de código de byte, em que cada instrução de código de byte contém: um apontador de função que aponta para um código de programa no conjunto de códigos de função para ser utilizado na execução da instrução, e um apontador para parâmetros que aponta para um conjunto de apontadores na rede de parâmetros os valores apontados pelos quais são necessários na execução da instrução, receber os registros de eventos, processar dados nos registros de eventos pela execução da estrutura de definição lógica, em que a execução da estrutura de definição lógica faz com que os dados nos registros de eventos sejam processados de acordo com a lógica de processamento predefinida.e formar os registros de saída com base nos ditos dados processados.
BRPI0513004-2A 2004-07-06 2005-06-16 "system and method for processing data records, mediation system for handling event records, service supply system, and system and method of mediation for processing event records" BRPI0513004B1 (pt)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US58552704P 2004-07-06 2004-07-06
US60/585,527 2004-07-06
EP20040396044 EP1615127B1 (en) 2004-07-06 2004-07-06 Data processing in a mediation or service provisioning system
EP04396044.2 2004-07-06
PCT/FI2005/000287 WO2006003239A1 (en) 2004-07-06 2005-06-16 Data processing in a mediation or service provisioning system

Publications (2)

Publication Number Publication Date
BRPI0513004A BRPI0513004A (pt) 2008-04-22
BRPI0513004B1 true BRPI0513004B1 (pt) 2017-12-05

Family

ID=34971665

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0513004-2A BRPI0513004B1 (pt) 2004-07-06 2005-06-16 "system and method for processing data records, mediation system for handling event records, service supply system, and system and method of mediation for processing event records"

Country Status (5)

Country Link
AU (1) AU2005259108B2 (pt)
BR (1) BRPI0513004B1 (pt)
CA (1) CA2572668C (pt)
NO (1) NO338023B1 (pt)
WO (1) WO2006003239A1 (pt)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101394451B (zh) * 2008-11-06 2012-09-05 北京中创信测科技股份有限公司 呼叫详细记录数据的存储方法、显示方法及系统

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6513156B2 (en) * 1997-06-30 2003-01-28 Sun Microsystems, Inc. Interpreting functions utilizing a hybrid of virtual and native machine instructions

Also Published As

Publication number Publication date
NO338023B1 (no) 2016-07-18
BRPI0513004A (pt) 2008-04-22
AU2005259108A1 (en) 2006-01-12
AU2005259108B2 (en) 2011-08-04
CA2572668C (en) 2014-10-14
WO2006003239A1 (en) 2006-01-12
CA2572668A1 (en) 2006-01-12
NO20070481L (no) 2007-01-25

Similar Documents

Publication Publication Date Title
Bouajjani et al. Regular symbolic analysis of dynamic networks of pushdown systems
US8494832B2 (en) Method and apparatus for software simulation
Mens et al. Formalising behaviour preserving program transformations
Koziolek et al. A model transformation from the palladio component model to layered queueing networks
US8042106B2 (en) Data processing in a mediation or service provisioning system
Zhang SymPas: symbolic program slicing
Koziolek et al. Predicting the performance of component-based software architectures with different usage profiles
Tuong et al. Deeply integrating C11 code support into Isabelle/PIDE
US6304877B1 (en) Device description and management language for computer network devices
BRPI0513004B1 (pt) "system and method for processing data records, mediation system for handling event records, service supply system, and system and method of mediation for processing event records"
Van den Brink et al. Deriving modernity signatures for PHP systems with static analysis
de Boer et al. Combining monitoring with run-time assertion checking
Azzopardi et al. Model-based static and runtime verification for ethereum smart contracts
Kallwies et al. Aggregate update problem for multi-clocked dataflow languages
Beurer-Kellner et al. A transformational approach to managing data model evolution of web services
Husák et al. PeachPie: Mature PHP to CLI compiler
Lui et al. A generalized approach to real-time, non-intrusive instrumentation and monitoring of standards-based distributed middleware
Casey et al. Eliminating network protocol vulnerabilities through abstraction and systems language design
Sander Design and Implementation of the Language Server Protocol for the Nickel Language
Van Rossum et al. Python frequently asked questions
CA2566025C (en) Type validation for applications incorporating a weakly-typed language
CN114329492A (zh) 一种针对Go语言链码的漏洞检测方法
Al-Moayed et al. An approach to model, configure and apply QoS attributes to web services
Ketkar et al. A Lightweight Polyglot Code Transformation Language
Gasser Program Verification in Continuous Integration Workflows

Legal Events

Date Code Title Description
B06A Notification to applicant to reply to the report for non-patentability or inadequacy of the application according art. 36 industrial patent law
B09A Decision: intention to grant
B16A Patent or certificate of addition of invention granted
B15K Others concerning applications: alteration of classification

Ipc: G06F 9/455 (2006.01)

B21F Lapse acc. art. 78, item iv - on non-payment of the annual fees in time

Free format text: REFERENTE A 15A ANUIDADE.

B24J Lapse because of non-payment of annual fees (definitively: art 78 iv lpi, resolution 113/2013 art. 12)

Free format text: EM VIRTUDE DA EXTINCAO PUBLICADA NA RPI 2594 DE 24-09-2020 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDA A EXTINCAO DA PATENTE E SEUS CERTIFICADOS, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013.