BR112022001950B1

BR112022001950B1 - Método e sistema para adaptação de programas para interoperabilidade e adaptadores para os mesmos

Info

Publication number: BR112022001950B1
Application number: BR112022001950-5A
Authority: BR
Inventors: Chris A. Haudenschild
Original assignee: Clinicomp International, Inc
Priority date: 2019-08-15
Filing date: 2020-08-13
Publication date: 2023-01-24
Also published as: MX2022001762A; AU2020331323B2; CN114270335A; JP7277669B2; CN117827941A; KR20220041932A; KR102496630B1; EP4014127A1; MX2022011070A; AU2022204388A1; CA3146272A1; AU2022204388B2; BR112022001950A2; EP4235430A3; US11256709B2; US20210049181A1; IL290515B; US11714822B2; US20230325398A1; JP2022537588A

Abstract

MÉTODO E SISTEMA PARA ADAPTAÇÃO DE PROGRAMAS PARA INTEROPERABILIDADE E ADAPTADORES PARA OS MESMOS. Um método e sistema, de acordo com modalidades, permitem programa generalizado para programar a interoperabilidade. O método e o sistema empregam um adaptador de transformada automático ou substancialmente automático para usar um determinado padrão de intercâmbio para comunicação bidirecional com um programa. Para que o adaptador empregue o padrão de intercâmbio, um gerenciador de revelação pode aprender a estrutura e/ou formato de comunicação de dados de programa e pode aprender informações de significado de dados a partir do programa. Um criador de adaptador pode derivar uma transformada que converte a estrutura de comunicação de dados de programa e o significado dos dados no padrão de intercâmbio. A transformada pode ser usada pelo adaptador para permitir a comunicação bidirecional com qualquer adaptador e/ou programa que emprega de maneira semelhante o determinado padrão de intercâmbio para obter interoperabilidade.

Description

CAMPO DA INVENÇÃO

[0001] A presente invenção refere-se em geral a um método e um sistema para adaptação de programas de software para interoperabilidade. Refere-se adicionalmente a adaptadores para permitir que diferentes programas alcancem a interoperabilidade.

FUNDAMENTOS DA INVENÇÃO

[0002] Não se admite que os fundamentos da técnica descritos nesta seção constituam legalmente técnica anterior.

[0003] Atualmente, programas como programas de banco de dados empregam uma variedade de diferentes modelos de dados, linguagens de interface, convenções de nomenclatura, semântica de dados, esquemas e representações de dados. Assim, um problema fundamental é o compartilhamento de informações heterogêneas entre uma variedade de recursos. A diversidade entre os dados de diferentes programas pode criar sérias barreiras em que a interoperabilidade dentre programas tão diversos pode ser altamente desejável, mas até então inatingível.

[0004] Embora tenha havido muitas tentativas direcionadas a bancos de dados heterogêneos, continua a existir uma necessidade significativa para que aplicativos de projeto, engenharia e fabricação possam acessar e importar dados facilmente de maneira eficiente e eficaz. Os esforços para desenvolver linguagens de consulta globais não atendem satisfatoriamente ao grande grupo de usuários que podem querer ver o mundo dos dados externos como se fosse uma extensão de seu sistema existente e sua representação especializada. Esses usuários podem não querer aprender uma representação global diferente - e mais importante, suas ferramentas de projeto dispendiosas podem funcionar apenas com sua representação especializada.

[0005] Portas de conexão de banco de dados, Agente de Solicitação de Objeto Comum (Common Object Request Broker (COBRA)) e interfaces de Conectividade de Banco de Dados Aberta (Open Database Connectivity (ODBC)) tentam abordar a heterogeneidade, mas apenas o fazem em um nível relativamente superficial. Assim, existem sérias desvantagens até mesmo para começar a alcançar a interoperabilidade universal de programa.

[0006] Em todos esses casos, os programadores ainda devem registrar o código do aplicativo para invocar as diversas funções projetadas em uma interface entre programas para, de alguma forma, permitir que eles interoperem, criando assim, despesas e atrasos indesejados e indesejáveis. Transformações de dados e reformatação podem ser necessárias no lado de fonte da interface de programa de aplicativos (API), no lado almejado da API ou, muitas vezes, em ambos os lados. Tudo isso é deixado para os programadores, que devem implementar essa funcionalidade de interoperabilidade caso a caso e, portanto, com grandes despesas para a implementação desejada. Infelizmente, há pouco ou nenhum software pré-existente a partir do qual esses tradutores podem ser construídos, e cada esforço geralmente começa do zero. Embora alguns fornecedores ofereçam tradutores a partir de importação de alguns formatos comuns, em geral, eles não oferecem interoperabilidade suficiente.

[0007] Além disso, se o uso almejado dos dados, espera dados não relacionais (por exemplo, ligados, aninhados ou outro formato), pode ser necessária uma transformação de dados adicional. Normalmente, isso também pode envolver um esforço de programação proibitivamente dispendioso com requisitos indesejados de consumo de tempo. Mesmo dentro do modo de dados relacionais, geralmente há várias maneiras diferentes de projetar as tabelas relacionais - ou seja, geralmente há mais de uma maneira de normalizar os dados. Se o aplicativo exigir os dados de maneira diferente dos providos pela API, as transformações de dados geralmente serão necessárias então. Assim, muitas vezes é necessário que uma organização registre tradutores especializados dispendiosos e demorados para seus requisitos específicos.

[0008] Outras desvantagens de interoperabilidade ocorrem frequentemente em uma grande empresa moderna. É inevitável que diferentes partes da organização usem sistemas diferentes para produzir, armazenar e pesquisar seus dados críticos. Essa diversidade de fontes de dados pode ser causada por muitos fatores, que inclui falta de coordenação dentre unidades da companhia, diferentes taxas de adoção de novas tecnologias, fusões e aquisições e separação geográfica de grupos colaboradores. No entanto, é apenas combinando as informações desses vários sistemas que a empresa pode perceber o valor total dos dados que eles contêm. Assim, a interoperabilidade do programa é cada vez mais desconcertante nas grandes empresas modernas.

[0009] Nas indústrias de finanças ou de saúde, por exemplo, as fusões são uma ocorrência quase comum. A companhia resultante a partir de uma fusão, herda os armazenamentos de dados da instituição ou instituições originais. Muitos desses armazenamentos de dados podem ser de fabricantes diferentes. Tanto o adquirente quanto o almejado podem ter um ou mais sistemas de gerenciamento de documentos para armazenar documentos de texto. Cada um pode ter tido aplicativos que computam informações importantes como, por exemplo, o risco de conceder um empréstimo a um determinado cliente ou minerar informações sobre os padrões de compra de cliente.

[0010] Após a fusão, a nova empresa poderá exigir acesso às informações dos clientes a partir de ambos os conjuntos de armazenamentos de dados, para analisar seu novo portfólio com o uso de aplicativos existentes e novos e, em geral, usar os recursos combinados de ambas as instituições através de uma interface comum. A companhia também pode exigir a capacidade de identificar clientes comuns e consolidar suas contas, mesmo que os dados dos clientes possam estar armazenados em diferentes bancos de dados e em diferentes formatos. Esses são todos os aspectos da interoperabilidade do programa e todos podem representar desafios pesados e excessivamente dispendiosos no processo de implementação. Além disso, a implementação normalmente requer atrasos longos indesejados para alcançar a interoperabilidade desejada.

[0011] Outra tentativa de interoperabilidade é o estabelecimento de um depósito de dados (data warehouse), que geralmente é construído carregando-se dados a partir de uma ou mais fontes de dados em um esquema recém-definido em um banco de dados de depósito. Os dados geralmente são limpos e transformados no processo de carregamento. Alterações nas fontes subjacentes podem causar alterações no processo de carregamento e a parte do aplicativo que lida com a análise de dados deve ser protegida. Novas fontes de dados podem introduzir alterações no esquema, exigindo que um novo processo de carregamento para os novos dados seja definido. No entanto, quaisquer funções da nova fonte de dados que não sejam uma parte padrão do sistema de gerenciamento de banco de dados de depósito geralmente devem ser reimplementadas no sistema de banco de dados de depósito ou como parte do aplicativo, frequentemente com despesas indesejadas e perda de tempo para instalação.

[0012] Uma solução com base apenas no depósito pode ser impraticável ou não ser econômica por vários outros motivos. Por exemplo, nem sempre é viável mover dados a partir de sua localização original para um depósito de dados e, conforme descrito acima, o depósito vem com seus próprios custos de manutenção e implementação.

[0013] O uso de um sistema de federação de banco de dados é mais uma tentativa de alcançar a interoperabilidade universal. O termo “federação de banco de dados” refere-se a uma arquitetura na qual um sistema de gerenciamento de banco de dados provê acesso uniforme a várias fontes de dados heterogêneas. No entanto, o tempo e os custos de projetar e implementar tal sistema geralmente são desagradáveis e indesejados. Mesmo assim, normalmente é limitado apenas a bancos de dados relacionais e não a outros formatos, como hierárquico ou outras formas. Assim, uma arquitetura tão limitada não é adequada para a interoperabilidade universal. Escalonar adicionando-se fontes de dados preenchidas, não conhecidas anteriormente, pode ser um desafio externo na melhor das hipóteses, se não totalmente impraticável para alguns aplicativos.

[0014] Em geral, há despesas e tempo indesejados necessários para criar interfaces para alcançar alguma medida de interoperabilidade de programa, como, por exemplo, em que um grande grupo de fontes de dados heterogêneas é empregado. Esse trabalho manual pelos programadores geralmente é totalmente indesejável e desagradável, se não assustador.

[0015] Seria extremamente desejável ter um sistema e método para permitir a interoperabilidade para qualquer número de programas diferentes de forma automática ou substancialmente automática e altamente eficiente e eficaz. Tal sistema e método devem ser protegidos contra erros humanos. Além disso, seria altamente desejável ter um adaptador de programa para auxiliar a facilitar a interoperabilidade universal entre diferentes programas. Os adaptadores operariam de maneira automática ou substancialmente automática para eliminar ou reduzir bastante a necessidade de programadores desenvolverem interfaces para programas anteriormente desconhecidos. Os adaptadores devem ser capazes de permitir a interoperabilidade mesmo dentre programas que tem arranjos e significados de dados anteriormente desconhecidos e a implementação pode ser concluída substancialmente sem intervenção humana. Assim, programas anteriormente desconhecidos podem ser facilmente acessados por outros programas para fins de interoperabilidade para estender globalmente um sistema de maneira essencialmente ilimitada e de forma rápida e eficiente.

[0016] Adaptadores têm sido usados para ajudar o acesso a bancos de dados a obter acesso com outros programas. Por exemplo, pode ser feita referência à seguinte patentes U.S.: n° U.S. 9.201.874 B2; n° U.S. 9.135.297 B2; n° U.S. 6.880.151 B2; n° U.S. 6.792.431 B2; n° U.S. 5.970.490; e o pedido de patente publicado n° U.S. 2014/0032608 A1.

[0017] Além disso, os seguintes são artigos publicados sem patente:

[0018] Por exemplo, no pedido de patente publicado n° U.S. 2014/0032608 A1, é descrito um adaptador de banco de dados que reivindica reduzir “o tempo e as despesas associadas à adaptação de um programa aplicativo para operar com um segundo banco de dados, diferente de um primeiro banco de dados, que o pedido foi projetado para acessar". Primeiro, no entanto, esse adaptador deve ser customizado manualmente para cada um dos dois programas de banco de dados diferentes. Tal customização é, obviamente, excessivamente dispendiosa e indesejavelmente demorada para implementar, especialmente quando pode haver um grande número de diferentes programas heterogêneos possíveis para interoperar, de maneira eficiente e eficaz. Em segundo lugar, o adaptador descrito é projetado para instanciar ambos os bancos de dados, o que pode não ser desejável para a maioria dos aplicativos.

[0019] A patente n° U.S. 6.792.431 para Tamboli e a patente n° U.S. 9.201.874 para Szyperski descrevem adaptadores e técnicas para informações de mapeamento de dados para auxiliar a interoperabilidade. Na patente Tamboli, são descritos adaptadores usados para integração de dados. Os atributos de identificação são exibidos por uma estação de trabalho de usuário. Os atributos são “na verdade armazenados em um catálogo”.

[0020] (Coluna 12, linhas 43 a 49). O usuário pode então habilitar a “execução de uma transferência, para transferir dados específicos identificados a partir de um repositório nativo de fonte para um repositório nativo de destino. As interfaces de usuário em tais modalidades são capazes, quando solicitadas, de registrar em um carrinho de transferência, chaves de catálogo dos atributos de identificação para todos os registros nativos solicitados transferidos pelo usuário A interface de usuário, em seguida, em modalidades típicas, registra uma chave de catálogo em um carrinho de transferência (242), uma chave para cada gravação de transferência.” (Coluna 13, linhas 1 a 26). Para habilitar esta operação, os programadores “registram código para funções de adaptador ou métodos membros que são registrados na linguagem de um sistema de gerenciamento de banco de dados para um repositório nativo ou que chamam interfaces de programação de aplicativos (“APIs”) suportadas por um repositório nativo ou seu sistema de gerenciamento de banco de dados." (Coluna 23, linhas 8 a 12). Quando foram cometidos erros no mapeamento, “na medida em que o mapeamento precisa ser alterado, não é necessária programação, apenas edição de texto. Na medida em que um adaptador precisa ser alterado, apenas uma pequena quantidade de programação está envolvida, apenas o suficiente no exemplo atual para adicionar um elemento de dados excluído O fato... de que o erro humano ou a escolha humana podem, por uma questão prática, excluir elementos de dados de uma maneira que falha na definição de uníssono total, 'são necessárias alterações'.” (Coluna 25, linhas 29 a 40).

[0021] Assim, o mapeamento aparentemente requer alteração devido a erro humano na inserção manual de informações em uma estação de trabalho. Esses erros humanos e correções manuais podem ser dispendiosos e altamente indesejáveis. A técnica Tamboli de exigir a “interface de usuário, em seguida, em modalidades típicas, registra uma chave de catálogo em um carrinho de transferência (242), uma chave para cada registro de transferência”, está sujeita a erro humano para cada registro no sistema. Portanto, problemas graves de precisão podem resultar de maneira fácil e previsível.

[0022] Na patente de Szyperski, é feita uma tentativa de “correlacionar diferentes tipos nominais com base em um conjunto mínimo de formatos ou estruturas comuns. Em uma implementação, um desenvolvedor identifica um número de tipos nominais diferentes de interesse (tipos de fonte) e identifica o conjunto mínimo de formatos de tipos comuns a serem acessadas por um programa de aplicativo. O conjunto mínimo de formatos de tipo comum pode ser usado para criar um tipo intermediário (tipo almejado) para o qual cada um dos outros tipos de fonte diferentes pode ser mapeado. Por exemplo, um ou mais proxies podem ser criados para mapear formas de um ou mais tipos de fonte para formatos correspondentes do tipo almejado criado. O programa de aplicativo criado pelo desenvolvedor, por sua vez, pode acessar, operar ou usar os dados mapeados de cada tipo de fonte diferente através de um único tipo almejado.” (Resumo, linhas 2 a 15).

[0023] No entanto, para fins de mapeamento de dados, o desenvolvedor deve identificar diferentes tipos nominais de interesse (tipos de fonte) e identificar o conjunto mínimo de formatos de tipos comuns a serem acessadas por um programa de aplicativo. Essa programação pode ser excessivamente dispendiosa e demorada. Além disso, é evidente que o desenvolvedor já deve conhecer os tipos antes que ele ou ela possa identificar um número de tipos nominais diferentes e, além disso, pode identificar o conjunto mínimo de formatos de tipos comuns. Assim, Szyperski requer conhecimento prévio de certos programas antes que o mapeamento possa ocorrer. BREVE DESCRIÇÃO DOS DESENHOS

[0024] A fim de entender melhor certas modalidades e ver como as mesmas podem ser realizadas na prática, as modalidades preferenciais não limitantes da invenção serão agora descritas com referência aos desenhos anexos, nos quais:

[0025] A Figura 1 é um diagrama de blocos simbólico que mostra a criação de adaptadores para uso com diferentes programas para permitir a interoperabilidade dentre eles de acordo com várias modalidades;

[0026] A Figura 2 é um diagrama de blocos simbólico de um par de adaptadores conectados a um par de programas diferentes para permitir que eles interoperem de acordo com várias modalidades;

[0027] A Figura 3 é um diagrama de fluxo de métodos de criação de adaptadores para facilitar a interoperabilidade de diferentes programas de acordo com várias modalidades;

[0028] A Figura 4 é um diagrama de blocos simbólico mais detalhado do adaptador de acordo com uma modalidade atualmente preferencial;

[0029] A Figura 5 é um diagrama de um perfil de dados a partir de um determinado dados padrão de intercâmbio de acordo com uma modalidade; e

[0030] A Figura 6 é uma implementação de software de uma etapa de determinação de consistência de perfil do fluxograma da Figura 3 de acordo com uma modalidade preferencial.

Descrição Detalhada de Certas Modalidades da Invenção

[0031] Certas modalidades da presente invenção serão agora descritas mais detalhadamente a seguir com referência aos desenhos anexos, nos quais algumas, mas não todas as modalidades da invenção, são mostradas. De fato, essas modalidades da invenção podem estar em muitas formas diferentes e, portanto, a invenção não deve ser interpretada como limitada às modalidades estabelecidas no presente documento; em vez disso, essas modalidades são providas como exemplos ilustrativos apenas para que esta descrição satisfaça os requisitos legais aplicáveis. Números semelhantes referem-se a elementos similares ao longo de toda a descrição.

[0032] Será prontamente entendido que os componentes das modalidades como geralmente descritos e ilustrados nos desenhos no presente documento, podem ser arranjados e projetados em uma ampla variedade de configurações diferentes. Assim, a seguinte descrição mais detalhada de algumas das modalidades do sistema de aparelhos, componentes e métodos da presente invenção, conforme representados nos desenhos, não se destina a limitar o escopo da invenção, conforme reivindicado, mas é meramente exemplos representativos de uma ou mais das modalidades da invenção.

[0033] De acordo com uma modalidade, um sistema facilita a interoperabilidade entre o primeiro e o segundo programas diferentes. Os programas podem ter significados e arranjos de dados previamente desconhecidos. O sistema inclui o primeiro e o segundo adaptadores padrão de intercâmbio bidirecional, que inclui, cada um, a primeira e a segunda transformadas funcionais de dados. As transformadas podem ser uma função de conversão de estruturas de dados e formatos de dados entre o primeiro e o segundo programas e um padrão de intercâmbio comum. O primeiro e o segundo adaptadores também incluem dados de leitura e gravação de transferência de comunicação para os respectivos primeiro e segundo programas. Um enlace de comunicação pode conectar o primeiro e o segundo adaptadores para transmitir informações padrão de intercâmbio de modo bidirecional.

[0034] As transformadas funcionais de dados, de acordo com várias modalidades, podem ser criadas sem intervenção humana e permitem que os programas interoperem. As estruturas de dados e formatos de dados, bem como os dados de leitura/gravação para cada programa, são aprendidas pelos gerenciadores de revelação. Assim, as transformadas de dados e os dados de leitura/gravação para cada adaptador permitem que os criadores de adaptador criem os adaptadores, o que pode ser feito sem intervenção humana.

[0035] Deve ser entendido que o termo "transformada funcional de dados", conforme usado no presente documento, também pode ser citado no presente documento de forma variada como "transformada de dados ES", "transformada" ou "transformada de dados de programa ES".

[0036] Outra modalidade refere-se a um método de criação dos adaptadores padrão de intercâmbio bidirecional. O método inclui receber significados de dados de programa e localizações de dados correspondentes a partir de um determinado programa. É então determinado a possibilidade de os significados do programa recebido serem equivalentes aos significados desejados de um padrão de intercâmbio. Uma determinação adicional pode ser feita como a possibilidade de os dados das localizações de dados recebidos do determinado programa serem consistentes com os dados correspondentes do padrão de intercâmbio.

[0037] Assim, se os significados dos dados estiverem disponíveis, os dados para esses significados podem ser verificados analisando-se os dados associados. Se não houver significados disponíveis, os próprios dados podem ser analisados para determinar se algum dos dados contidos no programa desconhecido pode ser de interesse, todos podem ser preenchidos sem intervenção humana de maneira rápida e eficiente.

[0038] Se a equivalência e/ou consistência forem determinadas, uma transformada funcional de duas vias pode ser criada. A transformada funcional pode ser uma função da estrutura de dados e formato de dados para uma conversão de dados entre o determinado programa e o padrão de intercâmbio correspondente. A transformada funcional é provida para um determinado adaptador padrão de intercâmbio bidirecional para facilitar a interoperabilidade entre o determinado programa e um programa diferente que tem outro adaptador padrão de intercâmbio bidirecional.

[0039] O método de criação pode incluir um gerenciador de revelação, que facilita a busca de significados de dados para dados armazenados em determinado programa. A pesquisa pode incluir o recebimento por meio do gerenciador de revelação de uma interface de programação de aplicativo (API).

[0040] O método de criação pode incluir um gerenciador de revelação, que facilita a busca de significados de dados para dados armazenados em determinado programa na forma de metadados.

[0041] O método de criação que usa o gerenciador de revelação pode incluir determinar o significado do padrão de intercâmbio desejado com os significados dos dados de programa recebido, para determinar a possibilidade de os significados do padrão de intercâmbio serem ou não equivalentes aos significados dos dados de programa correspondentes.

[0042] O método de criação com o uso do gerenciador de revelação pode incluir determinar se existe um perfil de dados de programa e se existe um perfil de dados de intercâmbio. Se eles existirem, uma determinação pode ser feita através do gerenciador de revelação se existe consistência entre o perfil de dados de programa e o perfil de dados padrão de intercâmbio.

[0043] O método de criação pode incluir uma determinação se o gerenciador de revelação determinar que existe a equivalência do significado de dados e/ou a consistência do perfil de dados, o adaptador pode então ser criado por um criador de adaptador, a menos que (1) o significado de dados de programa não é equivalente ao significado de dados padrão de intercâmbio, ou (2) o perfil de dados de programa não é consistente com o perfil de dados padrão de intercâmbio.

[0044] O método de criação pode incluir a criação de regras que definem comandos de leitura e gravação e transformadas de dados funcionais.

[0045] Ainda outra modalidade refere-se a um adaptador padrão de intercâmbio bidirecional que permite que um determinado programa interopere com um programa diferente que tem outro adaptador padrão de intercâmbio bidirecional. O adaptador pode incluir um ou mais hiperobjetos que inclui uma ou mais regras que definem uma transformada de dados funcional de duas vias. A transformada funcional pode ser uma função de conversão de dados de estruturas de dados e formatos de dados para um determinado programa e para um determinado padrão de intercâmbio. Os um ou mais hiperobjetos também podem definir regras para leitura de dados e gravação de dados para um determinado programa. Como resultado, a intercomunicação com outro adaptador padrão de intercâmbio bidirecional é facilitada para prover interoperabilidade entre o determinado programa e o programa diferente.

[0046] O adaptador padrão de intercâmbio bidirecional pode incluir adicionalmente um enlace de comunicação para comunicação entre o adaptador e outro adaptador padrão de intercâmbio bidirecional para transmitir informações padrão de intercâmbio bidirecional.

[0047] Em uma modalidade, as regras de hiperobjeto do adaptador permitem implementação rápida e eficiente em um quadro de hiperobjeto bem conhecido e aceito. As regras também podem ser revisadas ou alteradas dinamicamente.

[0048] Com referência agora aos desenhos e mais particularmente à Figura 1 dos mesmos, é mostrado um adaptador padrão de intercâmbio bidirecional 10 para permitir que um determinado programa, como um programa 12 de um grupo de programas 13, interopere com um programa desconhecido diferente, como um programa 14. O grupo de programas 13 pode ser uma variedade de programas diferentes, por exemplo, bancos de dados, aplicativos e outros tipos e tipos de programas. Além disso, os significados dos dados podem não ser conhecidos anteriormente dentre os vários programas 13. De acordo com várias modalidades, equipando-se cada um dos programas 13 com um adaptador padrão de intercâmbio semelhante ao adaptador 10, os programas 13 podem, ainda, ser capazes de interoperar entre si e compartilhar dados entre si, mesmo que a estrutura e disposição dos dados de cada um dos programas 13 podem ser diferentes e previamente desconhecidos.

[0049] A fim de criar o adaptador 10 para o programa 12, um gerenciador de revelação 15 pode ser empregado para revelar o significado de certos dados desejados utilizados ou armazenados no programa 12. Para este propósito, certas informações de programa recebidas indicadas em 16, informam ao gerenciador de revelação 15 como encontrar significados de dados e localizações de dados correspondentes, que podem ser providas a um servidor 17 do gerenciador de revelação 15.

[0050] De acordo com várias modalidades, se tais significados de dados e localizações de dados não estiverem disponíveis, os dados de programa (P-DATA), por exemplo, podem ser analisados automaticamente ou semiautomaticamente para aprender significados e localização de dados a partir dos próprios dados.

[0051] De acordo com as modalidades, um determinado padrão de intercâmbio (ES), como geralmente indicado em 18, é recebido pelo gerenciador de revelação 15. Os dados padrão de intercâmbio ES-DATA podem incluir dados que representam informações providas desejadas, incluindo, mas não se limitando a, significados de dados desejados, estrutura e formato de dados, perfis de dados e outros.

[0052] Caso o gerenciador de revelação 15 saiba que os determinados significados de dados desejados e suas localizações correspondentes ao determinado padrão de intercâmbio ES, foram revelados e/ou os dados de programa P-DATA são consistentes com os dados padrão de intercâmbio ES-DATA, um criador de adaptador 19 que tem um servidor 21, pode, em seguida, criar transformadas funcionais de dados para estrutura de dados e formatos de dados, bem como comandos de programa de leitura/gravação.

[0053] Uma vez criada, a transformada, tal como a transformada de dados de programa ES, pode ser montada no adaptador 10 conforme indicado em 20. Adicionalmente, os dados de leitura/gravação de transferência de comunicação também podem ser determinados pelo gerenciador de revelação 15 e usados para acessar o programa 12 pelo criador de adaptador 19 para prover comandos de leitura e gravação para o determinado programa 12 e montados no adaptador 10 conforme indicado em 22.

[0054] Agora, em referência à Figura 2, após a conclusão do adaptador 10, o determinado programa 12 pode ser conectado através de seu adaptador 10 através de um enlace de comunicação de dados ES 26 a um adaptador padrão de intercâmbio bidirecional diferente, como um adaptador 27, por sua vez acoplado através de um enlace 25 a um programa diferente, como o programa 14 para facilitar a interoperação entre os programas 12 e 14. Supondo-se que o adaptador 27 possa ter sido criado pelo gerenciador de revelação 15 e pelo criador de adaptador 19, ou por seu próprio gerenciador de revelação dedicado semelhante (não mostrado) e criador de adaptador (não mostrado). O adaptador 27 inclui uma transformada de dados de programa ES 29 que converte de modo bidirecional entre as informações do programa, no programa 14 e o padrão de intercâmbio ES de maneira semelhante à transformada 20 do adaptador 10 para uso com o programa 12. Da mesma forma, o adaptador 27 pode incluir dados de leitura/gravação de transferência de comunicação 28, que são semelhantes em função aos dados de transferência de comunicação 22 do adaptador 10 e que proveem comandos de leitura e gravação para o programa 14.

[0055] Como exemplo, supondo-se que o determinado programa 12 contém informações no idioma Italiano e o programa diferente 14 contém informações no idioma Chinês. Além disso, supondo-se que o padrão de intercâmbio ES esteja no idioma Inglês. O programa 12 pode solicitar informações do programa diferente 14 enviando-se uma mensagem como uma consulta em Italiano por meio do enlace 11, do adaptador 10, do enlace de comunicação de dados ES 26, do adaptador 27 e do enlace 25 para o programa 14. Ao fazê-lo, a solicitação de programa, do programa 12 no idioma Italiano, é enviada usando os comandos de leitura/gravação 22 e é transformada no idioma Inglês por meio da transformada de dados ES em 20 e transmitida pelo enlace 26 e o adaptador 27 para prover a solicitação em Inglês. O adaptador 27, por sua vez, converte a solicitação do idioma Inglês para o idioma Chinês por meio da transformada de dados 29 para apresentação ao programa 14. A solicitação de idioma Chinês é transmitida ao programa 14 através do enlace 25 usando-se os dados de leitura/gravação 28 para o programa 14.

[0056] O programa 14 pode então responder em Chinês por meio do enlace 25 ao adaptador 27, com o uso dos comandos de leitura/gravação em conformidade dos dados 28. O adaptador 27 converte as informações do idioma Chinês em Inglês por meio da transformada de dados 29 para prover a resposta em Inglês por meio do enlace de comunicação de dados ES 26 para o adaptador 10. O adaptador 10 converte, em seguida, a resposta de dados em Inglês através da transformada de dados 20 para o idioma Italiano para fornecer as informações em Italiano com o uso dos dados de leitura/gravação 22, através do enlace 11, para o programa 12. Como resultado, a comunicação em duas vias pode ocorrer entre os programas 12 e 14 para prover interoperabilidade, mesmo que os dois programas possam ser diferentes e se comunicarem em idiomas diferentes ou outras diferenças.

[0057] Referindo-se agora às Figuras 1 e 3, de acordo com várias modalidades, o método ou processo de criação do adaptador de intercâmbio bidirecional 10 será agora descrito em mais detalhes. Supondo-se que o programa 12 seja um programa de banco de dados e empregue significados de dados anteriormente desconhecidos. No entanto, outros programas como o grupo 13 de programas da Figura 1, podem ser programas diferentes, como aplicativos e podem ter diferentes arranjos de dados desconhecidos. O grupo 13 de programas pode ter outros adaptadores diferentes, como o adaptador 27 feito de forma semelhante ao adaptador 10.

[0058] Na caixa 31, as informações do programa e o padrão de intercâmbio ES são recebidos pelo gerenciador de revelação 15. As informações de saúde desejadas, como certas informações do paciente, podem, por exemplo, ser desejadas. Supondo- se que as informações do programa possam informar ao gerenciador de revelação 15 como encontrar significados de dados (P-DMs) e localizações para os mesmos, contidos no programa 12. As informações do programa recebidas pelo gerenciador de revelação 15 podem, por exemplo, estar na forma de uma interface de programação de aplicativos (API), metadados ou significados e localização de dados ou receber manualmente informações para o programa 12.

[0059] Na caixa de decisão 32, o gerenciador de revelação 15 determina se quaisquer significados de dados de programa (P-DMs) podem ou não estar disponíveis a partir do programa 12. Se disponível na caixa de decisão 34, é determinado a possibilidade de os significados de dados de programa disponíveis (P- DMs) para o programa 12, equivalerem aos significados de dados padrão de intercâmbio correspondentes (ES-DMs). Por exemplo, o significado dos dados de programa (P-DM), para o programa 12, pode incluir "temperatura" ou "temp" para as temperaturas registradas para um determinado paciente. Supondo que pelo menos um dos significados de dados padrão de intercâmbio é "temperatura", a igualdade é, em seguida, determinada pelo gerenciador de revelação 15. Determinação de igualdade significa que o programa 12 contém significado de dados de programa P- DM que equivale a significado de dados padrão de intercâmbio ES-DM, como neste presente exemplo como "temperatura". Esta operação pode ser realizada processando-se uma função de comparação ou de correspondência.

[0060] Visto que no presente exemplo é suposto que significado de dados padrão de intercâmbio ES-DM equivale a significado de dados de programa correspondente P-DM ou que nenhum significado de dados de programa está disponível, na caixa de decisão 38, o gerenciador de revelação 15 determina se os dados de programa P - DATA e os dados padrão de intercâmbio ES-DATA estão disponíveis.

[0061] Conforme indicado na caixa 41, visto que P-DATA e ES-DATA estão disponíveis, o gerenciador de revelação 15 pode determinar a possibilidade de o programa de dados P-DATA ser consistente com os dados padrão de intercâmbio ES- DATA. Os dados podem ser semelhantes aos ES-DATA correspondentes, mas não necessariamente os mesmos. A consistência pode ser definida de várias maneiras, que inclui, porém sem limitação, semelhante, compatível, possível ou outro. Os dados de programa podem não ser consistentes se o P-DATA estiver fora da faixa de dados descrita no padrão de intercâmbio. Por exemplo, os dados de programa "1000" podem ser determinados como não sendo uma "temperatura" de um paciente humano, comparando-se os dados de programa com dados padrão de intercâmbio de uma faixa de temperaturas fisiológicas possíveis. Outras técnicas de verificação de consistência são descritas doravante no presente documento.

[0062] Supondo-se que o P-DATA e o ES-DATA estejam disponíveis. Então, na caixa de decisão 41, os dados de programa P-DATA podem ser determinados pelo gerenciador de revelação 15 para serem consistentes com dados padrão de intercâmbio de ES-DATA correspondentes. Se consistente, o criador de adaptador 19 pode criar transformadas para o adaptador 10.

[0063] Conforme indicado nas caixas 34 e 36, se os significados de dados de programa P-DMs não equivalem aos significados de dados padrão de intercâmbio ES- DMs, na caixa STOP 36, o gerenciador de revelação 15 pode, em seguida, determinar que nenhuma revelação adicional deste significado de dados será assumida pelo gerenciador de revelação 15 e outros significados de dados podem ser processados ou o processo pode ser totalmente encerrado.

[0064] Se o gerenciador de revelação 15 na caixa 41 determinar que não há consistência entre os dados de programa P-DATA e os dados padrão de intercâmbio ES-DATA, o gerenciador de revelação 15, conforme indicado na caixa 45, PARAR, pode, em seguida, determinar que nenhuma revelação adicional desse significado de dados será assumida pelo gerenciador de revelação 15 e outros significados de dados podem ser processados ou o processo pode ser totalmente encerrado.

[0065] O gerenciador de revelação 15 pode determinar que (1) na caixa 34 o significado de dados de programa P-DM equivale ao significado de dados padrão de intercâmbio ES-DM, e que (2) na caixa 38, dados de programa P-DATA e dados padrão de intercâmbio ES-DATA não estão disponíveis. Em seguida, por meio de uma função E 43, como uma porta E ou outras técnicas, como uma função de software, o criador de adaptador 19 pode então prover transformadas funcionais para o adaptador 10 conforme indicado na caixa 47. Além disso, se o gerenciador de revelação 15 determinar que os dados P-DATA e os dados ES-DATA são consistentes conforme indicado na caixa 41, a transformada de dados ES pode então ser criada pelo criador de adaptador 19, a menos que os dados do programa não sejam consistentes com o perfil de dados padrão de intercâmbio na caixa 45, PARAR.

[0066] De acordo com várias modalidades, analisando os dados do programa, pode ser determinado se os dados do programa, no programa 12, podem ser de interesse, mesmo sem a disponibilidade de quaisquer significados de dados. Assim, um programa desconhecido, tal como o programa 12, de acordo com as modalidades, pode ser analisado apenas por seus dados para determinar se é de interesse conforme exigido pelo padrão de intercâmbio ES.

[0067] Conforme indicado na caixa 47, o criador de adaptador 19 desenvolve uma transformada de dados funcional T que é uma função tanto da estrutura/formato de dados padrão de intercâmbio (ES-DSF) quanto da estrutura/formato de dados de programa (P-DSF). A estrutura de dados pode, para alguns aplicativos, estar relacionada às unidades de dados. Por exemplo, no caso de significado de dados padrão de intercâmbio ES-DM ser "temperatura", o ES-DSF pode empregar graus centígrados como unidades de medida para os dados padrão de intercâmbio e o P- DSF pode ser expresso em graus Fahrenheit. O criador de adaptador 19 pode, sem seguida, empregar uma fórmula de conversão convencional como pelo menos uma porção da transformada T para conversão entre graus centígrados e graus Fahrenheit. A transformada de dados em geral pode ser qualquer função matemática e/ou operação lógica.

[0068] O formato de dados para o padrão de intercâmbio (ES-DSF) pode ser em formato binário, enquanto o formato de dados de programa (P-DSF) pode ser expresso na forma de ASCII. O criador de adaptador 19 pode, por exemplo, empregar uma fórmula de conversão como uma porção da transformada T para conversão entre os formatos binário e ASCII.

[0069] Conforme indicado na caixa 49, o criador de adaptador 19 também provê os comandos de leitura e gravação de dados para comunicação a partir de e para o programa 12.

[0070] Depois disso, conforme indicado na caixa 52, o adaptador 10 recebe a transformada T de dados ES em 20 e os dados de leitura e gravação em 22 a partir do criador de adaptador 19.

[0071] Agora, em referência à Figura 4, é descrito com mais detalhes o adaptador 10. O adaptador 10, de acordo com uma modalidade preferencial, pode incluir um grupo de leitura 53 de hiperobjetos, como hiperobjetos 54 e 56. O grupo de leitura 53 de hiperobjetos recebe informações a partir do enlace bidirecional 11 acoplado ao programa 12 e faz parte dos dados de leitura/gravação 22. O grupo de leitura 53 transmite informações para um grupo de dados de programa 58 de hiperobjetos, como um hiperobjeto 61 e um hiperobjeto 63. O grupo de dados de programa 58 faz parte da transformada de dados ES 20 e, por sua vez, transmite os dados transformados para o enlace bidirecional 26 e para outro adaptador, como o adaptador 27. Assim, as informações podem ser transmitidas a partir do programa 12 por meio do enlace bidirecional 11 e dos grupos de hiperobjetos 53 e 58 para o enlace bidirecional 26 acoplado ao adaptador 27.

[0072] Na direção inversa, um grupo de dados de programa 66 de hiperobjetos, como um hiperobjeto 68 e um hiperobjeto 71, faz parte da transformada de dados ES 20 e transmite informações do enlace bidirecional 26 a partir do adaptador 27. As informações a partir do grupo de dados de programa 66 podem ser transmitidas para um grupo de gravação 55 de hiperobjetos, como um hiperobjeto 57 e um hiperobjeto 59, e que faz parte dos dados de leitura/gravação 22. Os dados de leitura/gravação 22 transmitem as informações para o enlace bidirecional 11 acoplado ao programa 12. Assim, as informações podem ser transmitidas a partir do adaptador 27 por meio do enlace 26 e dos grupos de hiperobjetos 55 e 66 para o enlace bidirecional 11 acoplado ao programa 12.

[0073] Os grupos de hiperobjetos podem ser executados sob o controle de um servidor 65 e podem ser programados com as regras de comando de leitura/gravação geradas de acordo com, por exemplo, uma API ou informações semelhantes de um programa tal como o programa 12 para gerenciar comunicação entre o adaptador 10 e o programa 12. As regras ou algoritmos podem conter fórmulas ou equações funcionais complexas de uma maneira simples e expressiva para implementar a regra, conforme descrito em conexão com a transformada T. A implementação é relativamente direta para gravar informações como Linguagem de Consulta Estruturada (Structured Query Language (SQL)), bem como outras mais complexas, como regras. O quadro de hiperobjetos é bem conhecida e, portanto, as regras podem ser alteradas dinamicamente de forma relativamente rápida e fácil para atualização dinâmica conforme necessário em determinados aplicativos. Os hiperobjetos não contêm dados. Consultar, por exemplo, a patente n° U.S. 8.386.442, que é incorporada a título de referência em sua totalidade.

[0074] Portanto, a interoperabilidade de programas pode ser alcançada pelo uso de adaptadores de acordo com várias modalidades, mesmo que os programas possam ser diferentes e os arranjos de dados nos mesmos sejam desconhecidos anteriormente. Além disso, através do uso do padrão de intercâmbio, a atualização dinâmica pode ser obtida simplesmente atualizando-se o padrão de intercâmbio. Através do uso dos gerenciadores de revelação e criadores de adaptadores, de acordo com as várias modalidades, os adaptadores podem ser criados e atualizados mesmo dinamicamente, sem a necessidade de programação dispendiosa e demorada. Tais técnicas empregadas pelas várias modalidades permitem atender aos padrões e requisitos de grandes dados na indústria moderna e facilitam os requisitos de flexibilidade e de escalonamento.

[0075] Considerando agora a técnica, de acordo com várias modalidades, de determinar a partir dos dados de programa P-DATA apenas, a possibilidade de incluir ou não os dados desejados especificados nos dados padrão de intercâmbio ES- DATA. De acordo com certas modalidades, certos perfis de dados podem ser reconhecidos pelo gerenciador de revelação 15. O perfil de dados, de acordo com várias modalidades, pode descrever as características intrínsecas dos dados de programa P-DATA, como, por exemplo, uma faixa de valores de dados, uma estrutura hierárquica de dados, uma distribuição estatística de dados e outros, para os próprios dados. Um perfil de dados do padrão de intercâmbio ES é preferencialmente uma amostra de alta qualidade.

[0076] Uma curva de dados de amostra de alta qualidade de um padrão de intercâmbio ES pode ser comparada à uma curva de dados de entrada a partir do programa 12. Uma variedade de métodos pode ser usada para determinar a consistência entre as duas curvas de dados. Por exemplo, um método de correlação cruzada com base no algoritmo do “Teste de Kolmogorov-Smirnov de duas amostras” (Two-Sample Kolmogorov-Smirnov Test) pode ser usado para calcular a consistência de duas curvas de dados.

[0077] Na Figura 5, é mostrado um exemplo apenas para fins de explicação não limitativa de um perfil de dados padrão de intercâmbio que pode ser derivado a partir de seus dados subjacentes. Um diagrama de dados 40 mostrado na Figura 5 é um histograma unidimensional que forma um perfil de dados. Com referência particular à caixa 41 da Figura 3, supondo-se que o programa 12 seja um programa de banco de dados orientado para a saúde e o padrão de intercâmbio ES seja projetado para acessar os dados desejados concernentes a pacientes que tenham sido submetidos a testes de hemoglobina. O perfil de dados do diagrama 40 da Figura 5 ilustra o número de amostras testadas versus os valores de hemoglobina para vários registros de pacientes para determinar uma impressão digital de um perfil de dados.

[0078] No eixo geométrico X do diagrama 40, são mostrados os valores de teste dos resultados do teste de hemoglobina para vários pacientes. No eixo geométrico Y está listado o número de amostras de hemoglobina correspondente a cada valor especificado no eixo geométrico X. O número total de valores para as amostras de teste foi de 715.511. O resultado é a curva distinta 40 para ilustrar um padrão de distribuição dos dados. Este padrão é então o perfil de dados para resultados de testes laboratoriais de hemoglobina e pode ser usado como um perfil de dados padrão de intercâmbio. Deve ser entendido que pode haver muitos tipos e tipos diferentes de perfis de dados que podem ser usados de acordo com várias modalidades. Exemplos de perfis de dados podem incluir, sem limitação, eletrocardiogramas (ECGs), imagens, histogramas e muitos outros. Agora, em referência à Figura 6, uma Rede Neural Convolucional (CNN) 42 convencional pode ser usada de acordo com uma modalidade preferencial para a etapa 41 do método da Figura 3. A CNN pode ser treinada para capturar a representação invariante (formato intrínseco) de uma curva de dados. A CNN treinada também pode ser usada para computar um escore de consistência entre duas curvas de dados. No presente exemplo de uma curva de histograma 40 conforme mostrado na Figura 6, a CNN é treinada primeiro para capturar o formato intrínseco da curva de dados 40 e também para computar um escore de consistência desejada entre duas curvas com base na curva 40 como o padrão de intercâmbio. Em seguida, tanto o P-DATA a partir do programa 12 quanto o padrão de intercâmbio ES-DATA são transmitidos de forma contínua para a CNN para fins de processamento. Os resultados da determinação de consistência podem então ser "sim" ou "não", conforme indicado.

[0079] Em vista dos desenhos anteriores e descrições detalhadas de certas modalidades, pode tornar-se evidente para as pessoas versadas na técnica, que as modalidades descritas e outras, se referem a técnicas aperfeiçoadas para alcançar a interoperabilidade do programa dentre e entre diferentes programas, apesar do fato de poderem ter anteriormente dados desconhecidos. Adaptadores podem ser criados para ajudar a alcançar a interoperabilidade desejada, pelo menos em parte, aprendendo se o programa contém ou não os dados desejados.

[0080] Um método e sistema, de acordo com modalidades, permitem programa generalizado para programar a interoperabilidade. O método e o sistema empregam um adaptador de transformada automático ou substancialmente automático para usar um determinado padrão de intercâmbio para comunicação bidirecional com um programa. Para que o adaptador empregue o padrão de intercâmbio, um gerenciador de revelação pode aprender a estrutura e/ou formato de comunicação de dados de programa e pode aprender informações de significado de dados a partir do programa. Um criador de adaptador pode derivar uma transformada que converte a estrutura de comunicação de dados de programa e o significado dos dados no padrão de intercâmbio. A transformada pode ser usada pelo adaptador para permitir a comunicação bidirecional com qualquer adaptador e/ou programa que emprega de maneira semelhante o determinado padrão de intercâmbio para obter interoperabilidade.

[0081] Embora a invenção tenha sido descrita com referência aos exemplos acima, será entendido que muitas modificações e variações são contempladas dentro do verdadeiro espírito e escopo das modalidades descritas no presente documento. Muitas modificações e outras modalidades virão à mente de uma pessoa versada na técnica à qual a invenção pertence, tendo o benefício dos ensinamentos apresentados nas descrições anteriores e nos desenhos associados. Portanto, deve ser entendido que a invenção não deve ser limitada de forma alguma às modalidades específicas descritas no presente documento ou modificações das mesmas e que as modificações e outras modalidades são destinadas e contempladas para serem incluídas no escopo das reivindicações anexas. Embora termos específicos sejam empregados no presente documento, eles são usados em um sentido genérico e descritivo apenas e não para fins de limitação.

Claims

1. Método de criação de adaptadores para permitir a interoperabilidade de diferentes programas, caracterizado pelo fato de que compreende: receber significados de dados de programa e localizações de dados correspondentes para um determinado programa (31); determinar se os significados do programa recebido são equivalentes aos significados de dados desejados de um padrão de intercâmbio (34); determinar se os dados das localizações de dados recebidos do determinado programa, são consistentes com os dados correspondentes do padrão de intercâmbio (41); criar, se a equivalência e/ou consistência for determinada, uma transformada de dados funcional de duas vias, sendo que a transformada de dados funcional é uma função da estrutura de dados e formato de dados para conversão de dados entre o determinado programa e o padrão de intercâmbio correspondente (47); e prover a transformada funcional para um determinado adaptador padrão de intercâmbio bidirecional para facilitar a interoperabilidade entre o determinado programa e um programa diferente que tem outro adaptador padrão de intercâmbio bidirecional (52).

2. Método de acordo com a reivindicação 1, caracterizado pelo fato de que inclui adicionalmente a provisão de um gerenciador de revelação (15).

3. Método de acordo com a reivindicação 2, caracterizado pelo fato de que a etapa de determinação se os significados de programa recebidos são equivalentes aos significados de dados desejados de um padrão de troca inclui pesquisar, por meio do gerenciador de revelação, para significados de dados para dados armazenados no determinado programa (32).

4. Método de acordo com a reivindicação 3, caracterizado pelo fato de que o recebimento inclui o recebimento por meio do gerenciador de revelação de uma interface de programação de aplicativo (API) (31).

5. Método de acordo com a reivindicação 3, caracterizado pelo fato de que a pesquisa inclui receber metadados a partir do determinado programa por meio do gerenciador de revelação (31).

6. Método de criação de adaptadores para habilitar a interoperabilidade de programas diferentes, caracterizado pelo fato de que compreende: receber significados de dados de programa e locais de dados correspondentes para um determinado programa (31); fornecer um gerenciador de revelação (15); comparar, por meio do gerenciador de revelação, o significado do padrão de intercâmbio desejado com os significados dos dados de programa recebido para determinar a possibilidade de os significados do padrão de intercâmbio serem ou não equivalentes aos significados dos dados de programa correspondentes (34); determinar se dados provenientes de locais de dados recebidos do determinado programa são consistentes aos dados correspondentes do padrão de troca (41); criar, se equivalência e/ou consistência for determinada, uma transformada de dados bidirecional, sendo que a transformada de dados funcional é uma função de estrutura de dados e formato de dados para conversão de dados entre o determinado programa e o padrão de troca correspondente (47); e fornecer a transformada funcional para um adaptador de padrão de troca bidirecional determinado para facilitar a interoperabilidade entre o programa determinado e um programa diferente tendo outro adaptador de padrão de troca bidirecional (47).

7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a etapa de determinação se dados provenientes de locais de dados recebidos do determinado programa são consistentes aos dados correspondentes do padrão de troca inclui determinar, por meio do gerenciador de revelação que inclui uma rede neural convolucional, se existe um perfil de dados de programa e se existe um perfil de dados de intercâmbio (34).

8. Método de acordo com a reivindicação 7, caracterizado pelo fato de que inclui determinar, por meio do gerenciador de revelação, a consistência entre o perfil de dados de programa e o perfil de dados padrão de intercâmbio (42).

9. Método de criação de adaptadores para habilitar a interoperabilidade de programas diferentes, caracterizado pelo fato de que compreende: receber significados de dados de programa e locais de dados correspondentes para um determinado programa (31); determinar se significados de programa recebidos são equivalentes a dignificados de dados desejados de um padrão de troca (34); fornecer um gerenciador de revelação que inclui uma rede neural convolucional (15); determinar, por meio do gerenciador de revelação que inclui uma rede neural convolucional, se existe um perfil de dados de programa e se existe um perfil de dados de intercâmbio e determinar se dados provenientes dos locais de dados recebidos do determinado programa são consistentes aos dados correspondentes do padrão de troca (41); fornecer um criador de adaptador (19); sendo que se o gerenciador de revelação determinar que existe a equivalência do significado de dados e/ou a consistência do perfil de dados, criar pelo criador de adaptador uma transformada de dados funcional bidirecional, sendo que a transformada de dados funcional é uma função de estrutura de dados e formato de dados para conversão de dados entre o determinado programa e o padrão de troca correspondente, a menos que (1) o significado de dados de programa seja equivalente ao significado de dados padrão de intercâmbio e (2) o perfil de dados de programa não é consistente com o perfil de dados padrão de intercâmbio (43); e fornecer a transformada funcional para um adaptador de padrão de troca bidirecional determinado para facilitar a interoperabilidade entre o programa determinado e um programa diferente tendo outro adaptador de padrão de troca bidirecional (52).

10. Método de criação de adaptadores para habilitar a interoperabilidade de programas diferentes, caracterizado pelo fato de que compreende: receber significados de dados de programa e locais de dados correspondentes para um determinado programa (31); determinar se significados de programa recebidos são equivalentes a dignificados de dados desejados de um padrão de troca (34); fornecer um gerenciador de revelação que inclui uma rede neural convolucional (15); determinar, por meio do gerenciador de revelação que inclui uma rede neural convolucional, se existe um perfil de dados de programa e se existe um perfil de dados de intercâmbio e determinar se dados provenientes dos locais de dados recebidos do determinado programa são consistentes aos dados correspondentes do padrão de troca (42); fornecer um criador de adaptador (19); criar, se a equivalência e/ou consistência for determinada, uma transformada de dados funcional de duas vias, sendo que a transformada de dados funcional é uma função da estrutura de dados e formato de dados para conversão de dados entre o determinado programa e o padrão de intercâmbio correspondente; criar uma transformada de transferência de comunicação de duas vias que inclui regras para leitura de dados e/ou gravação de dados; sendo que a transformada de dados e a transformada de transferência de comunicação são montadas pelo criador de adaptador para o determinado adaptador padrão de intercâmbio; fornecer a transformada funcional para um adaptador de padrão de troca bidirecional determinado para facilitar a interoperabilidade entre o programa determinado e um programa diferente tendo outro adaptador de padrão de troca bidirecional.

11. Adaptador padrão de intercâmbio bidirecional para permitir que um determinado programa interopere com um programa diferente que tem outro adaptador padrão de intercâmbio bidirecional, caracterizado pelo fato de que compreende: um ou mais hiperobjetos que inclui uma ou mais regras que definem uma transformada funcional de duas vias; sendo que a transformada funcional é uma função de conversão de dados de estruturas de dados e formatos de dados para um determinado programa e para um padrão de intercâmbio; os um ou mais hiperobjetos que definem regras para leitura de dados e gravação de dados para o determinado programa; e pelo qual a intercomunicação com o outro adaptador padrão de intercâmbio bidirecional é facilitada para prover interoperabilidade entre o determinado programa e o programa diferente.

12. Adaptador padrão de intercâmbio bidirecional de acordo com a reivindicação 11, caracterizado pelo fato de que as regras incluem a transformada funcional, a leitura de dados e a gravação de dados.

13. Adaptador padrão de intercâmbio bidirecional de acordo com a reivindicação 11, caracterizado pelo fato de que inclui adicionalmente um enlace de comunicação para comunicação entre o adaptador e outro adaptador padrão de intercâmbio bidirecional para transmitir informações padrão de intercâmbio bidirecional (26).

14. Sistema para facilitar a interoperabilidade entre o primeiro e o segundo programas diferentes, caracterizado pelo fato de que compreende: um primeiro adaptador padrão de intercâmbio bidirecional que inclui uma primeira transformada funcional de dados, sendo que a primeira transformada funcional de dados é uma função de conversão de estruturas de dados e formatos de dados entre o primeiro programa e um padrão de intercâmbio (10); o primeiro adaptador padrão de intercâmbio bidirecional inclui ainda uma primeira transformada de transferência de comunicação para leitura e gravação de dados para o primeiro programa (22); um segundo adaptador padrão de intercâmbio bidirecional que inclui uma segunda transformada funcional de dados, sendo que a primeira transformada funcional de dados é uma função de conversão de estruturas de dados em formatos de dados entre o segundo programa e um padrão de intercâmbio (27); o segundo adaptador de intercâmbio bidirecional que inclui um segundo padrão de transformada de transferência de comunicação para leitura e gravação de dados para o segundo programa (28); e um enlace de comunicação comum conectado em comunicação entre o primeiro e o segundo adaptadores para transmitir informações padrão de intercâmbio de modo bidirecional (26).

15. Sistema de acordo com a reivindicação 14, caracterizado pelo fato de que o primeiro e o segundo adaptadores incluem um ou mais hiperobjetos, que tem, cada um, regras, em que as regras definem a primeira e a segunda transformadas funcionais de dados e a primeira e a segunda transformadas de transferência de comunicação.