Method and system for adapting programs for interoperability and adapter therefor - Patents.com

Abstract

To provide a method and a system for enabling a generalized program for programming interoperability.SOLUTION: A method employs an automatic or substantially automatic transform adapter for using a given exchange standard for two-way communication with a program. In order for the adapter to employ the exchange standard, a discovery manager learns the program's data communications structure and / or format, and learns data meaning information from the program. An adapter creator derives a transform which converts the program's data communications structure and data meaning into the exchange standard. The transform is used by the adapter to enable two-way communication with any adapter and / or program similarly employing the given exchange standard to achieve interoperability.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates generally to methods and systems for adapting software programs for interoperability. The present invention further relates to adapters for enabling different programs to achieve interoperability. [Background technology]

[0002] The background art disclosed in this section is not admitted as a matter of law to constitute prior art.

[0003] Currently, programs, e.g. database programs, use a variety of different data models, interface languages, naming conventions, data semantics, schemas, and data representations. A fundamental problem is therefore the sharing of heterogeneous information between various resources. The diversity of data from different programs can create serious barriers, where interoperability between such diverse programs may be highly desirable, but has been unattainable up until now.

[0004] While many attempts have been made toward heterogeneous databases, there continues to be a significant need to design, engineer, and produce applications that can easily access and import data in an efficient and effective manner. Efforts to develop global query languages ​​have not satisfactorily addressed the large number of users who would like to view the world of external data as if it were an extension of their own existing system and its specialized representations. These users may not want to learn different global representations, and more importantly, their expensive design tools may work only with their one specialized representation.

[0005] Database gateways, Common Object Request Broker (COBRA), and Open Database Connectivity (ODBC) interfaces attempt to address heterogeneity but do so at a relatively superficial level, and thus have serious shortcomings from the outset to achieve universal program interoperability.

[0006] In all these cases, programmers still need to write application code to invoke some of the functions designed in the interface between the programs so that they can interoperate in some way, resulting in extra and undesirable costs and time delays. Data conversion and reformatting may be required on either the source side of the application programming interface (API), the target side of the API, or often on both sides. This is all left to the programmer, who must implement this interoperability functionality on a case-by-case basis, resulting in a significant cost for the desired implementation. Unfortunately, there is little or no existing software available to build these conversion tools, and each effort usually starts from scratch. Several vendors offer import conversion tools from some common formats, but by and large these do not provide sufficient interoperability.

[0007] Furthermore, when the target use of the data expects non-relational data (e.g., linked, nested, or other formats), additional data transformations may be required. This also usually entails significant and very expensive programming effort and extra time-consuming requirements. Even in a relational data mode, there are usually several different ways to design relational tables; that is, there are usually more than one way to normalize the data. If the application requires different data than what the API provides, data transformations are usually required. Thus, it is often necessary for an organization to write specialized transformations for its own specific requirements, which can be expensive and time-consuming.

[0008] Other interoperability shortcomings often arise in modern large enterprises. It is inevitable that different parts of an organization may use different systems to generate, store, and retrieve their important data. This diversity of data sources can be caused by many factors, including lack of coordination within company units, differences in the rate of adoption of new technologies, mergers and acquisitions, and geographic separation of collaborating groups. However, without combining the information from these various systems, an enterprise may not realize the value of the entire data contained therein. Thus, program interoperability has become more complex in modern large enterprises.

[0009] Mergers are a fairly common occurrence, for example in the financial or healthcare industries. The resulting company inherits the data stores of the original institution or institutions. Many of those data stores may often be from different manufacturers. Both the acquirer and the target may have had one or more document management systems for storing text documents. Each of them may have applications that calculate important information, for example, the risk of providing a loan to a given customer, or sources of information about the customer's buying patterns.

[0010] The new, combined company will need to access customer information from both sets of data stores to analyze its new portfolio with existing and new applications, and to use the combined resources of both institutions, typically through a common interface. In addition, the company will need the ability to identify common customers and consolidate their accounts, even if the customer data is stored in different databases and in different formats. These are all aspects of program interoperability, and all can pose significant and excessively costly challenges in the implementation process. In addition, the implementation typically requires extra and lengthy delays to achieve the desired interoperability.

[0011] Another approach to interoperability is to establish a data warehouse, which is typically built by loading data from one or more data sources into a newly defined schema in a warehouse database. During this loading process, the data is often cleaned and transformed. Changes in the underlying sources may result in changes to the loading process, and the parts of the application that deal with data analysis need to be protected. New data sources may introduce changes to the schema, making it necessary to define a new loading process for the new data. However, any functionality of the new data source that is not a standard part of the warehouse database management system usually needs to be reimplemented within the warehouse database system or as part of the application, often resulting in extra costs and wasted time for installation.

[0012] A solution based solely on warehousing may not be practical or cost-effective for a variety of other reasons: for example, it is not always feasible to move data from its original location to a data warehouse, and, as mentioned above, warehousing has its own maintenance and implementation costs.

[0013] The use of database federation systems is yet another attempt to achieve universal interoperability. The term "database federation" refers to an architecture in which a database management system provides uniform access to several heterogeneous data sources. However, the time and expense of designing and implementing such a system is usually an undesirable extra. If realized, the system is usually limited to relational databases only, and not to other formats, e.g., hierarchical or otherwise. Thus, such a limited architecture is simply not suitable for universal interoperability. Scaling up by adding previously unknown input data sources can be at best an external challenge, if not entirely impractical for some applications.

[0014] Typically, extra cost and time is required to create interfaces to achieve some measure of program interoperability, for example when a large group of heterogeneous data sources are used. This manual effort by the programmer is extra, if not difficult, and usually quite undesirable.

[0015] It would be highly desirable to have a system and method that allows interoperability of any number of different programs in an automatic or substantially automatic, highly efficient and effective manner. Such a system and method would provide protection against human error. In addition, it would be highly desirable to have a program adapter to help promote universal interoperability between different programs. The adapter would operate in an automatic or substantially automatic manner, eliminating or greatly reducing the need for programmers to develop interfaces for previously unknown programs. The adapter should be capable of enabling interoperability even between programs with previously unknown data arrangements and semantics, and the implementation may be completed with substantially no human intervention. Thus, previously unknown programs can be easily accessed by other programs for interoperability purposes, globally expanding the system in an essentially unlimited manner and in a fast and efficient approach.

[0016] Adapters have been used to help an accessing database achieve access with other programs. For example, reference may be made to the following U.S. patents: U.S. Pat. No. 6,233,633; ... and U.S. Pat. No. 6,233,633.

[0017] In addition, Non-Patent Document 1 and Non-Patent Document 2 are non-patent publications.

[0018] For example, Patent Document 6 discloses a database adapter that is claimed to reduce "the time and expense associated with adapting an application program to work with a second database that is different from the first database that the application is designed to access." First, however, such an adapter must be manually customized for each of the two different database programs. Of course, implementing such customization would be excessively expensive and undesirably time-consuming, especially when there may be many different possible heterogeneous programs that must interoperate in an efficient and effective manner. Second, the disclosed adapter is designed to instantiate both databases, which may be undesirable for most applications.

[0019] U.S. Patent No. 5,399,433 to Tamboli and U.S. Patent No. 5,399,433 to Szyperski disclose adapters and techniques for data mapping of information to aid in interoperability. The Tamboli patent discloses an adapter used for data integration. Identifying attributes are displayed by a user workstation. These attributes are "actually stored in a catalog." (Col. 12, lines 43-49.) The user can then enable "execution of a transfer to transfer the specific identified data from a source native repository to a destination native repository." "The user interface in such an embodiment, when so instructed, may write to a transfer cart catalog keys from the identifying attributes for all designated native records transferred by the user. ... In a typical embodiment, the user interface then writes the catalog keys to the transfer cart (242), one key for each transferred record." (Col. 13, lines 1-26.) To enable this action, the programmer "writes code for adapter functions or member methods that are written in the language of the database management system for the native repository or that calls application programming interfaces ("APIs") supported by the native repository or its database management system." (Col. 23, lines 8-12.) When a mapping is incorrect, "to the extent that the mapping needs to be corrected, no programming is required, only text editing. To the extent that the adapter needs to be corrected, only a small amount of programming is involved, and in the present example adding one excluded data element is sufficient. ... The fact that human error or human choice has, as a practical matter, led to data elements being excluded without defining a perfect join, 'needs correction.'" (Col. 25, lines 29-40.)

[0020] Thus, it is clear that the mapping would require correction due to human error when manually entering information at a workstation. Such human error and manual correction would be costly and highly undesirable. Tamboli's technique, which requires that "in a typical embodiment, the user interface then writes the catalog keys to the transfer cart (242), one key for each transfer register," is subject to human error for every record in the system. Thus, serious accuracy problems can easily and predictably result.

[0021] The Sipersky patent attempts to "correlate different nominal types together based on a minimal set of common shapes or structures." "In one implementation, a developer identifies several different nominal types of interest (source types) and identifies a minimal set of shapes of the common types that will be accessed by an application program. An intermediate type (target type) can then be created using that minimal set of shapes of the common types, and each of the other different source types can be mapped to that intermediate type. For example, one or more proxies can be created that map shapes of one or more source types to corresponding shapes of the created target type. An application program written by the developer can then access, operate on, or otherwise use the mapped data of each of the different source types through the single target type." (Abstract, lines 2-15.)

[0022] However, for the purposes of data mapping, a developer must identify the different nominal types (source types) of interest and identify a minimal set of shapes of the common types that are accessed by the application programs. Such programming can be excessively expensive and time consuming. In addition, it is clear that the developer must already know several different nominal types before he or she can identify those types and further identify the minimal set of shapes of the common types. Thus, Siperski requires prior knowledge of a particular program before the mapping can be performed.

[0023] In order to better understand the particular embodiments and to see how they may be carried out in practice, non-limiting preferred embodiments of the invention will now be described with reference to the accompanying drawings, in which: [Prior art documents] [Patent documents]

[0024] [Patent Document 1] U.S. Patent No. 9,201,874(B2) [Patent Document 2] U.S. Patent No. 9,135,297(B2) [Patent Document 3] U.S. Patent No. 6,880,151(B2) [Patent Document 4] U.S. Patent No. 6,792,431(B2) [Patent Document 5] U.S. Patent No. 5,970,490 [Patent Document 6] US Patent Application Publication No. 2014 / 0032608(A1) [Non-patent literature]

[0025] [Non-Patent Document 1] Freir, Andreas, Hofestadt, Ralf, Lange, Matthias, Scholz, Uwe, Stephanik, Andreas, "BioDataServer; A SQL-based Service for the Online Integration of Life Science Data", In Silico Biology 2, 0005 Bioinformation Systems (2002). [Non-Patent Document 2] Devi, C. Punitha, Venkatesan, V. Prasanna, Diwahar, S., Shanmugasundaram, G., "A Model for Information Integration Using Service Oriented Architecture", IJ Information Engineering and Electronic Business (MECS www.mecs-press.org / Published online June 2014) [Brief description of the drawings]

[0026] [Figure 1] FIG. 1 is a symbolic block diagram illustrating the creation of an adapter for use with different programs to enable interoperability between the different programs, according to various embodiments. [Diagram 2] FIG. 2 is a symbolic block diagram illustrating an adapter connected to a pair of disparate programs to enable the pair of disparate programs to interoperate, according to various embodiments. [Diagram 3] 1 is a flow diagram illustrating a method for creating an adapter to facilitate interoperability between different programs, according to various embodiments. [Figure 4] FIG. 2 is a more detailed symbolic block diagram showing an adapter according to a currently preferred embodiment. [Diagram 5] FIG. 2 illustrates a data profile from a given exchange standard data, according to one embodiment. [Figure 6] FIG. 4 illustrates a software implementation of the profile consistency determination step of the flowchart of FIG. 3, according to a preferred embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] Specific embodiments of the invention will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all, embodiments of the invention are shown. Indeed, these embodiments of the invention may take many different forms, and thus the invention should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided merely as illustrative examples so that this disclosure will satisfy applicable legal requirements. Like numbers refer to like elements throughout.

[0028] It will be readily understood that the components of the embodiments as generally described and illustrated in the Figures herein could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of specific embodiments of the apparatus systems, components and methods of the present invention as represented in the Figures are not intended to limit the scope of the invention as claimed, but are merely representative of one or more embodiments of the invention.

[0029] According to an embodiment, a system facilitates interoperability between first and second disparate programs. The programs may have previously unknown data meanings and data arrangements. The system includes first and second bidirectional exchange standard adapters, each of which includes first and second data function transformations. The transformations may be data structure and data format transformation functions between the first and second programs and the common exchange standard. Additionally, each of the first and second adapters includes a communication transport for reading and writing data to the respective first and second programs. A communication link may connect the first and second adapters for communicating exchange standard information bidirectionally.

[0030] Data function transformations according to various embodiments may be created without human intervention and allow programs to interoperate. The data structures and data formats, as well as the read / write data for each program, are learned by the discovery manager. Thus, the data transformations and read / write data for each adapter allow an adapter creator to create an adapter, all of which may be done without human intervention.

[0031] It should be understood that the term "data function transformation" as used herein may be variously referred to herein as "ES data transformation," "transformation," or "ES program data transformation."

[0032] Another embodiment relates to a method of creating a bidirectional exchange standard adapter, the method including receiving program data semantics and corresponding data locations from a given program. A determination is then made as to whether the received program semantics are equivalent to a desired semantics of the exchange standard. A further determination may be made as to whether data from the received data locations of the given program matches the corresponding data of the exchange standard.

[0033] Thus, when data meanings may be available, the data against those meanings may be verified by analyzing related data, if no meanings are available, the data itself may be analyzed to determine if any of the data contained in the unknown program may be of interest, all of which may be completed in a fast and efficient manner without human intervention.

[0034] When equivalence and / or consistency is determined, a two-way functional transformation may then be created. The functional transformation may be a function of data structures and data formats for data conversion between a given program and a corresponding exchange standard. The functional transformation is provided for a given bidirectional exchange standard adapter to facilitate interoperability between the given program and a different program having another bidirectional exchange standard adapter.

[0035] The method of creating may include a discovery manager that facilitates retrieval of data meanings for data stored in a given program. The retrieval may include receiving an application programming interface (API) via the discovery manager.

[0036] The method of creating may include a discovery manager that facilitates retrieval of data meanings for data stored in a given program in the form of metadata.

[0037] A method of creating with a discovery manager may include determining a desired exchange standard meaning according to a received program data meaning and determining whether the exchange standard meaning is equivalent to the corresponding program data meaning.

[0038] A method of creating using a discovery manager may include determining whether a program data profile exists and whether an exchange data profile exists. If they exist, then via the discovery manager, it may be determined whether a match exists between the program data profile and the exchange standard data profile.

[0039] The creation method may include determining whether the discovery manager determines that either data semantics equivalence and / or data profile consistency exists, and then the adapter may be created by the adapter creator unless (1) the program data semantics are not equivalent to the exchange standard data semantics or (2) the program data profile is not consistent with the exchange standard data profile.

[0040] The method of creation may include creating rules that define read and write commands and functional data transformations.

[0041] Yet another embodiment relates to a bidirectional exchange standard adapter that allows a given program to interoperate with a different program having another bidirectional exchange standard adapter. The adapter may include one or more hyperobjects that include one or more rules that define a two-way functional data transformation. The functional transformation may be a data transformation function of a data structure and data format for a given program and a given exchange standard. The one or more hyperobjects may include one or more rules that define a two-way functional data transformation function for a given program and a given exchange standard. Against Rules for reading and writing data may also be defined. As a result, intercommunication with other bidirectional exchange standard adapters is facilitated, providing interoperability of a given program with different programs.

[0042] The two-way exchange standard adapter may further include a communications link for communication between the adapter and another two-way exchange standard adapter for communicating the two-way exchange standard information.

[0043] In one embodiment, the adapter's hyperobject rules allow for fast and efficient implementation in well-known and accepted hyperobject frameworks, and the rules may be dynamically modified or otherwise changed.

[0044] Referring now to the drawings, and more particularly to FIG. 1, there is shown a bidirectional exchange standard adapter 10 for enabling a given program, such as, for example, program 12 of a group of programs 13, to interoperate with a different, unknown program, such as, for example, program 14. Group of programs 13 may be a variety of different programs, such as, for example, databases, applications, and other types and kinds of programs. In addition, data meanings may not be previously known between the various programs 13. According to various embodiments, by each of the programs 13 being equipped with an exchange standard adapter similar to adapter 10, the programs 13 may still be able to interoperate with each other and share data with each other, even when the structure and arrangement of data in each of the programs 13 may be different and previously unknown.

[0045] To create an adapter 10 for a program 12, a discovery manager 15 may be used to discover the meaning of particular desired data used or stored in the program 12. To this end, specific received program information, shown at 16, informs the discovery manager 15 how to find the data meaning and the corresponding data location, which may be provided to a server 17 of the discovery manager 15.

[0046] According to various embodiments, when such data meanings and data locations may not be available, for example, program data (P-DATA) may be automatically or semi-automatically analyzed to learn data meanings and data locations from the data itself.

[0047] According to an embodiment, a given exchange standard (ES), generally indicated at 18, is received by discovery manager 15. The exchange standard data ES-DATA may include data representing the desired given information, including but not limited to desired data semantics, data structures and formats, data profiles, and others.

[0048] When the discovery manager 15 learns that given desired data meanings and their locations corresponding to a given exchange standard ES have been discovered and / or that the program data P-DATA is consistent with the exchange standard data ES-DATA, the adapter creator 19 with the server 21 may then create data function transformations and read-write program commands for data structures and data formats.

[0049] Once created, a transform, such as an ES program data transform, may be assembled into an adapter 10 as shown at 20. In addition, communication transport read / write data may also be defined by the discovery manager 15, which may be used by the adapter creator 19 to access the program 12 to provide read and write commands for a given program 12, and may be assembled into the adapter 10 as shown at 22.

[0050] 2, once adapter 10 is complete, a given program 12 may be connected through its adapter 10 to a different bidirectional exchange standard adapter, such as adapter 27, via ES data communication link 26, which may be coupled to a different program, such as program 14, via link 25 to facilitate interoperability between programs 12 and 14. It is assumed that adapter 27 may have been created by discovery manager 15 and adapter creator 19, or may have been created by its own similar dedicated discovery manager (not shown) and adapter creator (not shown). Adapter 27 includes ES program data transformation 29, which bidirectionally translates between program information in program 14 and the exchange standard ES, in a manner similar to transformation 20 of adapter 10 for use with program 12. Similarly, adapter 27 may include communication transport read / write data 28, which has a similar function as communication transport data 22 of adapter 10, to provide read and write commands for program 14.

[0051] As an example, assume that a given program 12 contains information in Italian and a different program 14 contains information in Chinese. Further assume that the exchange standard ES is English. Program 12 may request information from different program 14 by sending a message, such as a query in Italian, to program 14 via link 11, adapter 10, ES data communication link 26, adapter 27, and link 25. In doing so, the Italian program request from program 12 is sent using read / write commands 22, converted to English via ES data conversion at 20, and conveyed by link 26 and adapter 27 to provide the English request. Adapter 27 then converts the English request to Chinese by data conversion 29 for presentation to program 14. The Chinese request is conveyed to program 14 via link 25 by using read / write data 28 for program 14.

[0052] Program 14 may then respond in Chinese to adapter 27 via link 25 with read / write commands consistent with its data 28. Adapter 27 converts the Chinese information to English via data conversion 29 and provides the English response to adapter 10 via ES data communications link 26. Adapter 10 then converts the English data response to Italian via data conversion 20 and provides the Italian information to program 12 via link 11 with read / write data 22. As a result, two-way communication occurs between programs 12 and 14 and interoperability may be provided even though the two programs are different and communicate in different languages ​​or may have other differences.

[0053] 1 and 3, a method or process for creating a bidirectional exchange adapter 10 according to various embodiments will now be described in more detail. Program 12 is assumed to be a database program and to use previously unknown data semantics. However, other programs, such as, for example, group 13 of programs in FIG. 1, may be different programs, such as, for example, applications, and may have different, unknown data arrangements. Group 13 of programs may have other, different adapters, such as, for example, adapter 27, created in a manner similar to adapter 10.

[0054] In box 31, program information and exchange standard ES are received by discovery manager 15. Desired healthcare information may be desired, such as, for example, specific patient information. It is assumed that the program information may inform discovery manager 15 how to find the data meanings (P-DMs) contained in program 12 and their locations. The program information received by discovery manager 15 may be in the form of, for example, an application programming interface (API), metadata, or data meanings and data locations, or may be manually received information for program 12.

[0055] In decision box 32, discovery manager 15 determines whether any program data meanings (P-DM) may be available from program 12. If so, in decision box 34, it is determined whether the available program data meanings (P-DM) of program 12 are equivalent to the corresponding exchange standard data meanings (ES-DM). For example, program data meanings (P-DM) of program 12 may include "temperature" or "temp" for a body temperature recorded for a given patient. Assuming that at least one of the exchange standard data meanings is "temperature", then equivalence is determined by discovery manager 15. Determining equivalence means that program 12 includes a program data meaning P-DM that is equivalent to an exchange standard data meaning ES-DM, such as "temperature" in this example. This operation may be accomplished by processing a comparison or matching function.

[0056] In this example, it is assumed that the exchange standard data meaning ES-DM is equivalent to the corresponding program data meaning P-DM or that the program data meaning is not available, so in decision box 38 the discovery manager 15 determines whether the program data P-DATA and the exchange standard data ES-DATA are available.

[0057] As shown in box 41, since P-DATA and ES-DATA are available, discovery manager 15 may determine whether the data program P-DATA is consistent with the exchange standard data ES-DATA. The data may be similar to the corresponding ES-DATA, but not necessarily the same. Consistency may be defined in various ways, including but not limited to similarity, compatibility, likelihood, or other. When the P-DATA is outside of the data range described in the exchange standard, the program data may not be consistent. For example, by comparing the program data with the exchange standard data for the range of physiologically possible body temperatures, it may be determined that the program data "1000" is not the "body temperature" of a human patient. Other consistency checking techniques are described below.

[0058] Assume that P-DATA and ES-DATA are available. Then, in decision box 41, the program data P-DATA may be determined by discovery manager 15 to match the corresponding exchange standard data ES-DATA. When there is a match, adapter creator 19 may then create a transformation for adapter 10.

[0059] As shown in boxes 34 and 36, when the program data semantics P-DM is not equivalent to the exchange standard data semantics ES-DM, then in stop box 36 the discovery manager 15 may determine that no further discovery of this data semantics by the discovery manager 15 will be performed, other data semantics may be processed, or the entire process may terminate.

[0060] When in box 41 the discovery manager 15 determines that there is no consistency between the program data P-DATA and the exchange standard data ES-DATA, then as shown in stop box 45 the discovery manager 15 may determine that no further discovery of this data meaning will be performed by the discovery manager 15, other data meanings may be processed, or the entire process may terminate.

[0061] The discovery manager 15 may (1) determine in box 34 that the program data semantics P-DM are equivalent to the exchange standard data semantics ES-DM, and (2) determine in box 38 that the program data P-DATA and the exchange standard data ES-DATA are not available. Then, by an AND function 43, e.g., an AND gate, or other technique, e.g., a software function, the adapter creator 19 may then provide a function transformation for the adapter 10, as shown in box 47. In addition, as shown in box 41, when the discovery manager 15 determines that the data P-DATA and the data ES-DATA match, an ES data transformation may then be created by the adapter creator 19, except when the program data in stop box 45 does not match the exchange standard data profile.

[0062] According to various embodiments, by analyzing the program data, it can be determined whether the program data of program 12 may be of interest even if any data semantics are not available. Thus, an unknown program, such as program 12 according to embodiments, may be analyzed by its data alone to determine whether its data is of interest as required by exchange standard ES.

[0063] As shown in box 47, the adapter creator 19 develops a functional data transformation T that is a function of both the exchange standard data structure / format (ES-DSF) and the program data structure / format (P-DSF). This data structure may relate to a data unit for some applications. For example, if the exchange standard data meaning ES-DM is "body temperature", then the ES-DSF may use degrees Celsius as the unit of measure for the exchange standard data, and the P-DSF may be expressed in degrees Fahrenheit. The adapter creator 19 may then use a conventional conversion formula as at least a part of the transformation T to convert between degrees Celsius and degrees Fahrenheit. A general data transformation may be any mathematical function and / or logical operation.

[0064] The data format for the exchange standard (ES-DSF) may be a binary format, while the program data format (P-DSF) may be represented in ASCII form. For example, the adapter creator 19 may use a transformation formula as part of the transformation T to convert between binary and ASCII formats.

[0065] As indicated in box 49 , adapter creator 19 also provides read data and write data commands for communication with program 12 .

[0066] Thereafter, as shown in box 52 , adapter 10 receives an ES data transform T at 20 and read and write data at 22 from adapter creator 19 .

[0067] 4, adapter 10 is described in more detail. Adapter 10 according to a preferred embodiment may include a read group 53 of hyperobjects, such as hyperobjects 54 and 56. The read group 53 of hyperobjects receives information from bidirectional link 11 coupled to program 12 and forms part of read / write data 22. The read group 53 communicates information to a program data group 58 of hyperobjects, such as hyperobjects 61 and 63. The program data group 58 forms part of ES data transformation 20 and subsequently communicates the transformed data to bidirectional link 26 and another adapter, such as adapter 27. Thus, information may be communicated from program 12 via bidirectional link 11 and hyperobject groups 53 and 58 to bidirectional link 26 coupled to adapter 27.

[0068] In the opposite direction, program data group 66 of hyperobjects, such as hyperobject 68 and hyperobject 71, forms part of ES data transformation 20 and conveys information from bidirectional link 26 from adapter 27. Information from program data group 66 may be conveyed to write group 55 of hyperobjects, such as hyperobject 57 and hyperobject 59, which form part of read / write data 22. Read / write data 22 conveys information to bidirectional link 11 coupled to program 12. Information may thus be conveyed from adapter 27 via link 26 and hyperobject groups 55 and 66 to bidirectional link 11 coupled to program 12.

[0069] The group of hyperobjects may be executed under the control of the server 65 and may be programmed by read / write command rules generated according to, for example, an API or similar information of a program, such as, for example, the program 12, for managing the communication between the adapter 10 and the program 12. The rules or algorithms may include complex functional formulas or equations for implementing the rules, such as those described in relation to the transformation T, in a simple representation manner. It is relatively easy to implement to write information as rules, such as, for example, Structured Query Language (SQL) and other more complex ones. Since the hyperobject framework is well known, the rules may be dynamically changed relatively quickly and easily for dynamic updates required in a particular application. Hyperobjects do not contain data. See, for example, U.S. Pat. No. 8,386,442, which is incorporated by reference in its entirety.

[0070] Thus, interoperability of programs may be achieved through the use of adapters according to various embodiments, even though the programs may be different and the data arrangement therein may be previously unknown. Furthermore, through the use of exchange standards, dynamic updates may be achieved simply by updating the exchange standards. Through the use of discovery managers and adapter creators according to various embodiments, adapters may be created and dynamically updated without the need for expensive and time-consuming programming. These techniques used by various embodiments enable addressing the large data standards and requirements of modern industry, facilitating flexibility and scaling requirements.

[0071] Consider now the technique according to various embodiments for determining from the program data P-DATA alone whether it may contain the desired data specified in the exchange standard data ES-DATA. According to certain embodiments, a particular data profile may be recognized by the discover manager 15. The data profile according to various embodiments may describe the unique characteristics of the program data P-DATA, such as, for example, the data value range for the data itself, the data hierarchical structure, the statistical distribution of the data, and others. The data profile of the exchange standard ES is preferably a high quality sample.

[0072] The high quality sample data curve from the exchange standard ES may be compared to the input data curve from the program 12. Various methods may be used to determine the consistency of the two data curves. For example, a cross-correlation method based on the "Two-Sample Kolmogorov-Smirnov Test" algorithm may be used to calculate the consistency of the two data curves.

[0073] A non-limiting illustrative example of an exchange standard data profile that may be derived from the underlying data is shown in Figure 5. The data diagram 40 shown in Figure 5 is a one-dimensional histogram forming the data profile. With particular reference to box 41 in Figure 3, assume that program 12 is a database program for healthcare and that the exchange standard ES is designed to access desired data regarding patients who have undergone hemoglobin testing. The data profile in Figure 40 of Figure 5 shows the number of samples tested verses hemoglobin values ​​for various patient records to define a fingerprint of the data profile.

[0074] The X-axis of FIG. 40 lists the test values ​​of hemoglobin test results for various patients. The Y-axis lists the number of hemoglobin samples corresponding to each value identified on the X-axis. The total number of values ​​for the test samples was 715,511. The result is a characteristic curve 40 that shows the distribution pattern of the data. This pattern is thus a data profile for the hemoglobin clinical test results and may be used as an exchange standard data profile. It should be understood that there may be many different types and kinds of data profiles that may be used according to various embodiments. Examples of data profiles may include, without limitation, electro cardiograms (ECGs), images, histograms, and many others. Now referring to FIG. 6, according to a preferred embodiment for step 41 of the method of FIG. 3, a conventional Convolutional Neural Network (CNN) 42 may be used. The CNN may be trained to capture an invariant representation (eigenshape) of the data curve. The trained CNN may also be used to calculate a consistency score between two data curves. In this example of a histogram curve 40 shown in Figure 6, the CNN is first trained to capture the inherent shape of the data curve 40, and additionally trained to calculate a desired match score between the two curves based on the curve 40 as an exchange standard. Both the P-DATA from program 12 and the exchange standard ES-DATA are then streamed to the CNN for processing purposes. The result of the match determination may be either "yes" or "no" as shown.

[0075] In view of the foregoing drawings and detailed description of specific embodiments, it will be apparent to those skilled in the art that the disclosed and other embodiments relate to novel techniques for achieving program interoperability within and between different programs, despite the fact that the programs may have previously unknown data. Adapters may be created to help achieve the desired interoperability, at least in part, by learning whether the programs contain desired data.

[0076] The method and system according to the embodiment enables generalized program to program interoperability. The method and system uses an automatic or substantially automatic conversion adapter to use a given exchange standard for two-way communication with a program. For the adapter to use the exchange standard, the discovery manager may learn the data communication structure and / or format of the program and may learn data semantic information from the program. The adapter creator may derive a transformation that converts the data communication structure and data semantics of the program into the exchange standard. The adapter may use this transformation to achieve interoperability by enabling two-way communication with any adapter and / or program that also uses the given exchange standard.

[0077] Although the present invention has been described with reference to the above examples, it will be understood that many modifications and variations are anticipated within the true spirit and scope of the embodiments disclosed herein. Many modifications and other embodiments will occur to those skilled in the art to which the present invention pertains having the benefit of the teachings provided in the foregoing description and the accompanying drawings. It is therefore to be understood that the present invention is not limited in any manner to the specific embodiments or modifications thereof disclosed herein, and that such modifications and other embodiments are intended and anticipated to be included within the scope of the appended claims. Although specific terms have been employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1. 1. A processor-implemented method for creating an adapter to enable different programs to interoperate, comprising: receiving program data semantics and corresponding data locations for a program; determining whether the received program data semantics are equivalent to a predetermined data semantics of an interchange standard; determining whether data from the received data location of the program matches corresponding data in the interchange standard; if equality or consistency is determined, creating a two-way functional data transformation; providing said two-way functional data conversion for a bidirectional exchange standard adapter to enable interoperability between said program and a different program having another bidirectional exchange standard adapter in an automated manner; A method comprising:

2. The method of claim 1 , further comprising the step of providing a discovery manager.

3. 3. The method of claim 2, wherein determining whether the received program data semantics are equivalent to a desired data semantics of an exchange standard includes retrieving data semantics for data stored in the program via the discovery manager.

4. The method of claim 3 , wherein the receiving step includes receiving an application programming interface (API) via the discovery manager.

5. The method of claim 3 , wherein the step of searching includes the step of receiving metadata from the program via the discovery manager.

6. 2. The method of claim 1, wherein the step of determining whether the received program data semantics are equivalent to a desired data semantics of the exchange standard includes the step of comparing the received program data semantics with a predetermined exchange standard semantics via the discovery manager to determine whether the exchange standard semantics are equivalent to the corresponding program data semantics.

7. 2. The method of claim 1, wherein determining whether data from the received data location of the program matches corresponding data of the exchange standard includes determining whether a program data profile exists and whether an exchange standard data profile exists via a discovery manager including a convolutional neural network.

8. 8. The method of claim 7, further comprising determining, via the discovery manager, the consistency between the program data profile and the exchange standard data profile.

9. 8. The method of claim 7, wherein the two-way functional data transformation is created by an adapter creator if the discovery manager determines that the equivalence of the data semantics and / or the consistency of the data profile exists, except when (1) the program data semantics are equivalent to the data semantics of the exchange standard, and (2) the program data profile is not consistent with the exchange standard data profile.

10. The method of claim 1 , further comprising creating a communication transport transformation that includes rules for reading data and / or writing data.

11. 11. The method of claim 10, wherein the functional data transformation and the communication transport transformation are assembled by an adapter creator for the bidirectional exchange standard adapter.

12. 2. The method of claim 1, wherein determining whether data from the received data location of the program matches corresponding data of the exchange standard includes program data meaning (P-DM) equal to exchange standard data meaning (ES-DM).

13. 2. The method of claim 1, wherein determining whether data from the received data location of the program matches corresponding data in the exchange standard comprises determining whether program data (P-DATA) falls outside a data range described in the exchange standard.

14. 14. The method of claim 13, wherein the program data includes one or more of the following unique characteristics: data value ranges, data hierarchical structure, and statistical distribution of data.

15. 2. The method of claim 1, wherein creating a two-way functional data transformation if the equivalence or consistency is determined comprises developing a functional data transformation (T) that is a function of both an exchange standard data structure / format (ES-DSF) and a program data structure / format (P-DSF).

16. 1. A system for facilitating interoperability between a first program and a second, different program, comprising: a first bidirectional exchange standard adapter including a first data function transformation, the first data function transformation being a conversion function of data structures and data formats between a first program and an exchange standard, the first bidirectional exchange standard adapter further including a first communication transport transformation for reading data from and writing data to the first program; a second bidirectional exchange standard adapter including a second data function transformation, the second data function transformation being a transformation function of data structures in a data format between a second program and the exchange standard, the second bidirectional exchange standard adapter including a second communication transport transformation for reading data from and writing data to the second program; a common communications link coupled between said first bidirectional exchange standard adapter and said second bidirectional exchange standard adapter for automatically bidirectionally communicating exchange standard information therebetween; Including, the system.

17. 17. The system of claim 16, wherein the first bidirectional exchange standard adapter includes one or more hyperobjects each having rules, the rules defining the first data function transformation and the first communication transport transformation.

18. 17. The system of claim 16, wherein the second bidirectional exchange standard adapter includes one or more hyperobjects each having rules, the rules defining the second data function transformation and the second communication transport transformation.

19. 17. The system of claim 16, wherein the first program includes information in a first language and the second program includes information in a second language different from the first language.

20. 20. The system of claim 19, wherein the exchange standard information communicated over the common communications link includes information in a third language different from the first language and the second language.

Images