Patent ID: 12229146

The Figures depict preferred embodiments for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the systems and methods illustrated herein may be employed without departing from the principles of the invention described herein.

DETAILED DESCRIPTION OF THE INVENTION

The present embodiments may relate to, inter alia, systems and methods for providing enhanced rules conflict checks with data validation for downstream systems. In an exemplary embodiment, the process is performed by a data integrity and validation (“DIV”) computer device, also known as a data integrity and validation (“DIV”) server.

The DIV computer device interacts with a database or data structure that provides data to a data flow pipeline. The DIV computer device is programmed to provide data to one or more destination systems. The DIV computer device is also programmed to identify data anomalies to allow the user to take corrective measures before the data anomalies are introduced to the destination systems or to notify the user that non-critical data anomalies. Data anomalies include where the data in a data message conflicts with the rules for that data message. Data anomalies can include, but are not limited to, missing data, incorrect data, improperly formatted data, data in the wrong place, and other errors that could impact other systems.

The DIV computer device is configured to evaluate the valuation requirements from the data producers and the data consumers (i.e., the destination systems) to determine if the data is in the proper format and location in data messages to be transmitted to the destination systems. By consolidating the data validation and data consumption rules for a plurality of destination computer systems, the DIV computer device is able to concurrently execute data validation for multiple systems, provide point-in-time evaluation for data quality, content, and condition, provide analysis of data structures across time periods, provide data validation externalized from the calling application or system, and provide dashboard and error logging analysis for an overall view of the quality of the data being provided.

The DIV system is also programmed to assist with determining the format of a data message based on the rules and requirements of the destination systems that the data message is to be routed to. The DIV system receives the rules and requirements from each of the destination systems that a data message is to be routed to. The DIV system compares the rules and requirements to each other to determine the final rules and requirements for the data message. The DIV system also determines the layout of the payload of the data message so that all of the required fields and the required formats at included in the data message. The DIV system instructs the destination systems in which fields each destination system's data fields are stored. When the destination system receives the data message, the destination system knows which fields to extract the data from.

FIG.1illustrates an exemplary system100for data validation and integrity checks in accordance with at least one embodiment. In system100, a source system105is in communication with an information source database110. The source system105is also in communication with a data integrity and validation (DIV) system115, which is associated with a rules database120. The source system105is further in communication with one or more destination systems125-135.

The destination systems A-C125-135represent multiple systems that request information from the information source database110. In system100, the three destination systems A-C125-135are in communication in a serial order, where a data message is transmitted from the source system105to destination system A125. In some embodiments, destination systems A-C125-135are independent of each other. In other embodiments, destination systems A-C125-135are related. For the discussion here, destination system C135is considered to be ‘downstream’ of destination system B130, which is ‘downstream’ of destination system A125. While only three destination systems125-135are shown in the Figures presented herein, the systems and methods described herein may be used for any number of destination systems125-135.

The data message is then transmitted from destination system A125to destination system B130and then from destination system B130to destination system C. When the data message reaches each destination system125-135, the corresponding destination system125-135retrieves the data that it requires from the data message and ignores the data in the rest of the fields. The data message needs to include the required information for each of the destination systems125-135that the data message will be routed to. For example, if the data message is being routed to destination system A125, then destination system B130, and finally destination system C135, the data message will include all of the data required by each destination system125-135. This also requires the data message to conform to the rules and requirements for each of the destination systems125-135.

Some of the data fields may have contradictory requirements for different destination systems125-135. For example, destination system A125may require the date to be in the American format of month, day, and year, but destination system B130may require the data to be in the European format of day, month, and year. Or destination system B130may require the year to be two digits long, while destination system C125may require the year to be four digits long. Or the state could be required to be spelled out instead of using the two letter code. Or the zip code may require five digits or nine digits. The same data in a data field could be required to be 8 bits long for destination system A125and 12 bits long for destination system B130. In some embodiments, this is resolved by having two different data fields in the data message, one field including the information for destination system A125and the other field including the information for destination system B130.

In the exemplary embodiment, the source system105is a data source computer device that receives requests for data and generates data messages to respond with. The source system105transmits the requested data to one or more of the destination systems125-135in the appropriate data message. The source system100can transmit a data message in response to a received data request from one or more destination systems125-135. The source system100can also transmit a data message at a predetermined time or after a predetermined period of time. The source system can further receive a request to transmit the data to the destination systems125-135from an outside system, such as when specific data is received in the information source database110.

The data message can include, but is not limited to, a header field, a message type field, one or more destination fields, a length field, and a payload. The payload includes a plurality of data fields populated from the information source database110. As described further below, the length field and the data fields in the payload of each data message depend on the message type and the destination systems125-135that the data message is being transmitted to.

The information source database110is configured to store information, such as, but not limited to, client records, property records, driving records, financial records, insurance policy information, cybersecurity information, and/or any other type of data required. The source system105is programmed to provide the information in the information source database110to the destination systems125-135. In some embodiments, the records in the information source database110are formatted based on how the information is to be presented to the destination systems125-135. For example, the records in the information source database110are formatted so that the information can be directly added to the message providing the information to the destination systems125-135. In one example, a date is formatted in the European style, where the number for the date is before the month. In other embodiments, the source system105converts or formats the information prior to adding the information to the data message to the one or more of destination systems125-135based on the requirements of the receiving destination systems125-135. The data in the information source database110can be provided from a plurality of different computer systems. In some embodiments, the data is provided to the source system105, which stores the data in the information source database110. In other embodiments, other computer systems store the data in the information source database110. While the other computer systems may validate the information as it is being provided, the DIV system115, described below, also validates the data in the information source database110to ensure that the data is placed into the data message correctly.

The DIV system115is programmed to receive the data message for validation before the data message is transmitted to the destination systems125-135. The DIV system115is in communication with rules database120. The rules database120includes the rules associated with the destination systems125-135about how those destination systems125-135expect to receive the data stored in the information source database110. The DIV system115compares the data message to the rules in the rules database120to validate the data message. If the data message is validated, then the DIV system115notifies the source system105of the validation. The source system105can then transmit the data message to the destination systems125-135. If the data message is not validated, then the DIV system115determines why the data message was not validated. If the DIV system115determines that the validation issue is minor, the DIV system115can log the validation issue and instruct the source system105to transmit the data message to the destination systems125-135. If the DIV system determines that the validation issue is significant, then the DIV system115can log the validation issue and then notify the user of the validation issue. In some embodiments, the user can then correct the validation issue to allow the data message to be transmitted. In some further embodiments, the DIV system115corrects the validation issue in the data message and transmits the corrected data message to the source system105to be transmitted to the destination systems125-135.

In some embodiments, a minor (or low) validation error may include data that is not vital to the operation of system100. A minor validation error may also be considered a low risk error, where the validation failure presents an acceptable risk, but the error should be further investigated and repaired at a later time. For example, data for trend analysis may be missing. As the trend analysis only occurs on a periodic basis, the validation error can be considered minor as the rest of the system100will continue to operate effectively. Furthermore, since the error is logged, those performing trend analysis could be aware of the issue before they begin performance of the analysis and thus have time to correct the issue. An example of a significant (or high level) validation error may include missing data that is vital to the operation of the system100, such as, but not limited to, financial data. A significant validation error may also be considered a high risk error, where the validation failure presents an unacceptable risk and could critically impact the destination systems125-135, where data correction is required before the data message is released. If this data is missing or incorrect, then one or more of the downstream systems125-135may operate inefficiently or may introduce errors into the system100. Accordingly, significant or high level validation errors are logged and the associated data message is not transmitted. In some embodiments, the low risk issues could be considered at a warning level, while the high risk issues are at an error level.

In validating the data message, the DIV system115can evaluate a plurality of rules to ensure that each of the plurality of rules is being followed for the data message, so that the data message will not cause any problems with the destination systems125-135. Example rules can include, but are not limited to, i) quality rules (i.e. is the data present? does the data element meet the expected requirements for format and length?); ii) content rules (i.e. allowed values); iii) conditional rules (i.e. evaluation of secondary elements for quality and/or content based on the presence or content of primary elements); and/or any other types of rules.

Examples of quality rules include, but are not limited to, ensuring that the birthday field is filled, ensuring that the date is formatted correctly (i.e. two digits in each of the month, day, and year fields), and ensuring that the proper field type is used (i.e. Boolean, text, integer, etc.). Examples of content rules include, but are not limited to, ensuring that the provided date is proper (i.e. no greater than 28 days in February 1990). Examples of conditional rules include, but are not limited to (i.e. if field A is filled, then field B needs to be filled; if field A is set to 8, then field B needs to be filled; or if a policy states that it is for two people, but there in only information for one person). Other rules may be used based on the requirements of different destination systems125-135.

In some embodiments, DIV system115has access to the information source database110to check if the correct information was placed into the fields of the data message. For example, the DIV system115can compare the fields of the data message to the raw data in the information source database110and determine that the source system105improperly converted the data prior to placing the data in the data message. In some further embodiments, the DIV system115logs the improper conversion issue to be repaired. In some embodiments, the destination system125-135provides preferences on how to handle issues and errors. For example, the destination system125-135may instruct the source system105to transmit the data message even if there are specific types of errors or errors in specific fields of the data message. In still further embodiments, the DIV system115repairs the improperly converted field so that the data message can still be transmitted to the destination systems125-135.

The rules database120stores a plurality of rules based on the rules of each of destination systems125-135. The rules in the rules database120describe many or all of the fields in the data message including, but not limited to, what information should be included in each field, when, and in what format.

In some embodiments, the DIV system115transmits a validation success or failure notification to the source system105after analyzing the data message. In other embodiments, the DIV system115transmits the data message to the destination system(s)125-135, after analyzing the data message. The validation notification can include information about all of the low risk and high risk issues that were detected by the DIV system115.

FIG.2illustrates another exemplary system200for data validation and integrity checks in accordance with at least one embodiment. In system200, destination systems A125and B130are in parallel with each other, while destination system C135is downstream of destination system B130. When a data message is transmitted to destination system B130, the data message must comply with the rules of destination system B130and destination system C135. In some embodiments, the same data message is transmitted to destination system A125and destination system B130simultaneously and must comply with the rules for both. In other embodiments, different data messages are sent to destination system A125and destination system B130. Thus the different data messages only have to comply with the rules of any destination systems125-135that the data message is routed to.

In other embodiments, other configurations of destination systems125-135may be used with the systems and methods described herein. Furthermore, in at least one embodiment, destination system A125may provide information for destination system C135. For example, a data field in the payload may be empty when the data message is transmitted from source system105to destination system A125. Destination system A125can then fill in the appropriate data into the data field of the data message, so that destination system C135can receive that data. In this example, destination system A125may be a pricing system and determines and provides a price for destination system C135to use.

FIG.3illustrates an exemplary system300for compiling rules for making data validation and integrity checks using the system100(shown inFIG.1).

In system300, the DIV system115is in communication with a plurality of destination systems125-135. The DIV system115receives a plurality of rules from each of the destination systems125-135. The DIV system115analyzes the plurality of rules to determine if there are any rules conflicts. Conflicts can include, but are not limited to, rules requiring data to be in different formats for different destination systems125-135, missing data, different versions of the effectively the same data (birthdate vs. current age), and contradictory data.

The DIV system115is also in communication with the information source database110. In some embodiments, the DIV system115compares the plurality of rules to the data stored in the information source database110. The DIV system115also determines if there are any rules conflicts between the plurality of rules and the information stored in the information source database110. For example, a date may be stored in European format vs. American format; the birthdate may be stored, but not the current age; or the number of digits required for the year may vary. For both of these examples, the DIV system115can instruct the source system105to properly format the required data as the source system105generates the data message.

The DIV system115compares the plurality of rules from each of the destination systems125-135and the available data in the information source database110and generates a blueprint for the data message. The DIV system115determines which fields and field types will be put in the payload section, where those fields will be located in the data message, and how those fields will be formatted. The DIV system115also informs the destination systems125-135where the data that each of the destination systems125-135needs will be located in the data message.

For example, the three fields for destination system A125are fields1,2, and3. The three fields for destination system B130are fields1,2, and4. And the four fields for destination system C135are fields1,2,3, and5. The DIV system115ensures that the data message includes all of the required fields in the required formats. In this example, field3could be the date of activation of a policy in the American date format. Destination systems A125and C135require the date field in the American date format. However, destination system B130requires the date field in the European date format. Since destination system B130receives the same data message as destination systems A125and C135, the DIV system115generates the data message to store the date in the American format in field3and in the European format in field4. While this adds an additional field to the data message, it reduces the number of messages required to be generated and sent over the network, thus reducing overall network traffic.

In some other embodiments, the fields of the data message are predetermined, where the DIV system115does not have access to the information source database110. In these embodiments, the data message is designed to fit the requirements of each of the destination systems125-135. Then when another destination system is added at a subsequent point in time, such as destination system D (not shown), the DIV system115receives the requirements of destination system D and compares those requirements to the data message. If the requirements are compatible, then no other actions are required and destination system D is integrated into the system100. If there are issues or conflicts, then the DIV system115can notify one or more administrator users to fix the conflicts. In further embodiments, the DIV system115can edit the data message and inform destination system D where the fields that it needs to access are located in the data message.

FIG.4illustrates a further system400for data validation and integrity checks in accordance with at least one embodiment. In system400, source system105has access to two information source databases110, information source database A405and information source database B410. In some embodiments, each database405-410provides different information and is associated with different data messages.

In system400, the source system105routes the appropriate information from the appropriate information source database405-410to the appropriate destination system(s)125-135. For example, source system105is responsible four separate data messages. The first data message includes data from information source database A405and is transmitted to destination systems A125and B130. The DIV system115receives the rules requirements from destination systems A125and B130for the first data message. The DIV system115generates the first data message in response to the received rules sets and the information available in information source database A405. When source system105receives a request for the first data message, the source system105populates the first data message with the appropriate data from information source A405. Then source system105requests that the DIV system115validate the populated first data message. The DIV system115uses the rules sets from destination system A125and destination system B130to validate the first data message. If the first data message is validated, the source system105transmits the first data message to destination system A125.

The second data message includes data from information source database A405and is transmitted to destination systems A125, B130, and C135. The DIV system115receives the rules requirements from destination systems A125, B130, and C135for the first data message. The DIV system115generates the second data message in response to the received rules sets and the information available in information source database A405. The second data message can include more fields than the first data message, which may include additional data requested by destination system C135and/or additional fields needed to resolve conflicts between the rules for destination systems A125or B130and destination system C135.

When source system105receives a request for the second data message, the source system105populates the second data message with the appropriate data from information source A405. Then source system105requests that the DIV system115validate the populated second data message. The DIV system115uses the rules sets from destination system A125, B130, and C135to validate the second data message. If the second data message is validated, the source system105transmits the second data message to destination system A125.

The third data message includes data from information source database B410and is transmitted to destination systems A125and C135. The DIV system115receives the rules requirements from destination systems A125and C135for the third data message. The DIV system115generates the third data message in response to the received rules sets and the information available in information source database B410. When source system105receives a request for the third data message, the source system105populates the third data message with the appropriate data from information source B410. Then source system105requests that the DIV system115validate the populated third data message. The DIV system115uses the rules sets from destination system A125and destination system C135to validate the third data message. If the third data message is validated, the source system105transmits the third data message to destination system A125.

The fourth data message includes data from information source database B410and is transmitted to destination systems B130and C135. The DIV system115receives the rules requirements from destination systems B130and C135for the third data message. The DIV system115generates the third data message in response to the received rules sets and the information available in information source database B410. When source system105receives a request for the fourth data message, the source system105populates the fourth data message with the appropriate data from information source B410. Then source system105requests that the DIV system115validate the populated fourth data message. The DIV system115uses the rules sets from destination system B130and destination system C135to validate the fourth data message. If the fourth data message is validated, the source system105transmits the fourth data message to destination system B130.

FIG.5illustrates a process500for performing data validation and integrity checks using at least one of the system100(shown inFIG.1), the system200(shown inFIG.2), and the system400(shown inFIG.4). In the exemplary embodiment, process500is performed by the source system105and the DIV system115(both shown inFIG.1).

The source system105receives505a data request to be transmitted to one or more destination system125-135(shown inFIG.1). In some embodiments, the data request could originate from one or more of the destination systems125-135. In other embodiments, the data request could be automated, where the data request or the data message is transmitted on a regular basis. In other embodiments, the data request could originate from a user computer device, such as a user computer device being used by a user to input information.

The source system105determines which data message to respond with. The data message selected may be based on one or more of the destination systems125-135receiving the data message, the information source database110(shown inFIG.1) containing the data, and/or the data request message.

The source system105determines510one or more destination systems125-135to transmit the data message from the data request. As described above, the source system105can store a plurality of data messages that can be routed to different destination systems125-135. In at least one embodiment, each data message is routed to a specific set of destination systems125-135due to the required fields from the requirements of the associated destination systems125-135. By determining510the destination systems, the source system105also can determine the appropriate data message to transmit to those destination systems125-135.

The source system105builds515the data message based on the data request. In the exemplary embodiment, the format and fields of the data message have been previously determined, such as in process600(shown inFIG.6). The source system105populates the fields of the data message with the data from the information source database110. In some embodiments, the source system105converts some of the data from the information source database110to a required format prior to populating that data in the appropriate data field. For example, if the field requires that the year be listed in two digits and the information source database110stores the year using four digits, the source system105converts the year field from four to two digits for the data message. Or if the data field requires the age of the client, but only the birthdate is stored in the information source database110, the source system105determines the age of the client from the birthdate and the current date.

The DIV system115compares520the data message to a plurality of rules associated with the determined one or more destination systems125-135. In some embodiments, the source system105calls the DIV system115to validate the data message. In other embodiments, the source system105transmits the data message to the DIV system115.

The DIV system115validates525the data message based on the plurality of rules stored in the rules database120(shown inFIG.1). In some embodiments, the rules database120stores the rules for each destination system125-135. In other embodiments, the rules database120stores the rules for each data message, where the rules for each destination system125-135that the data message is scheduled to go to has been integrated together and stored in the rules database120, such as in process600.

If the data message is validated, the data message is transmitted530to the one or more destination systems125-135. In some embodiments, the source system105transmits530the data message. In other embodiments, the DIV system115transmits530the data message.

If the data message is not validated, the DIV system115determines535the level of error associated with the validation failure. If the level of error is low (or minor), the DIV system115logs540and the data message is transmitted530to the one or more destination systems125-135. If the error level is high (or significant), the DIV system115logs545the error and requests550user input. While the error system described herein as high level and low level errors, in some embodiments, other error valuation systems, such as colors or a scale may be used with the systems described herein.

In some embodiments, the user is in the process of inputting data, such as through the source system105. The user may be entering data to request a policy or policy update. The DIV system115determines that one or more fields in the data message are missing or are incorrectly formatted. In these embodiments, the DIV system115may inform the source system105of the error and the source system105may request corrected information from the user. The user input may correct the error, so that the data message may then be transmitted530.

In some other embodiments, the user is an administrator that makes one or more changes to at least one of the data message and the information source database110for future data messages to correct the error.

In the exemplary embodiment, the DIV system115compares520the entire data message to the rules associated with that data message. Then the DIV system115compiles all of the issues and errors for the data message.

In some embodiments, the destination system125-135provides preferences on how to handle issues and errors. For example, the destination system125-135may instruct the source system105to transmit530the data message even if there are specific types of errors or errors in specific fields of the data message. In other embodiments, the source system105transmits information about the issues and errors to the destination system(s)125-135associated with the error or issue and request instructions on how to proceed. The corresponding destination system(s)125-135instructs the DIV system115and/or the source system105whether to transmit530the data message, fix the issue or error, or prevent transmission of the data message.

If there are multiple errors, then each error is logged540-545. If all of the errors are low, then the data message is transmitted530.

In some embodiments, the DIV system115corrects the error.

FIG.6illustrates a process600for compiling rules for making data validation and integrity checks using the system300(shown inFIG.3). In the exemplary embodiment, process600is performed by the DIV system115(shown inFIG.1). Process600can be used when a new data message is being designed. For the new data message the destination systems125-135that the message will be transmitted to are analyzed for their rules to determine if there any conflicts in the fields of the data message. The rules describe the data requirements of the destination systems125-135that the data message will be transmitted to, including i) quality rules (i.e. is the data present? does the data element meet the expected requirements for format and length?); ii) content rules (i.e. allowed values); iii) conditional rules (i.e. evaluation of secondary elements for quality and/or content based on the presence or content of primary elements); and/or any other types of rules necessary. The data message is designed so that each destination system125-135will know where in the data message its fields are stored.

The DIV system115receives605a first set of rules from a first destination system, such as destination system A125(shown inFIG.1). The DIV system115receives610a second set of rules from a second destination system, such as destination system B130. While only two sets of rules are described in process600, multiple sets of rules may be used to create the data message, these can include, but are not limited to, rules from the destination systems125-135, rules from the information source database110(shown inFIG.1), and rules for the data message itself.

The DIV system115compares615the first set of rules and the second set of rules. In some embodiments, the DIV system115compares615the rules to each other. In other embodiments, the DIV system115also compares615the rules to the available data in the information source database110. The DIV system115compares the rules to detect620rules conflicts. The rules conflicts can include, but are not limited to, quality rules conflicts (where the required data is missing or misformatted); content rules conflicts (where the data available is outside of the required bounds); mismatching rules conflicts (where different sets of rules require data to be in different formats); and differing data requirements (where different data is required by different destination systems125-135). When the DIV system115detects620a rules conflict, the DIV system115determines625a potential fix. For example, the DIV system115may determine625to create two different fields with the same information but in different formats. The DIV system115may also determine625that a specific piece of data is not provide, but can be derived from the available information. The DIV system115stores630the potential fix for the rules conflict and returns to Step615to compare615the sets of rules. The DIV system115continues to cycle through Steps615-630until all of the rules conflicts are resolved. In some embodiments, the DIV system115is unable to determine625a potential fix for a rules conflict. In these embodiments, the DIV system115logs the rules conflict and requests user input to correct the rules conflict. For example, a required field or piece of information might not be available in the information source database110. In this example, the user can remove the requirement, ensure that the required data is added to the information source database110, or instruct that the data is retrieved from a different source than information source database110.

Once the DIV system115detects620no more unresolved rules conflicts, the DIV system115generates635the format for the data message based on the comparison and any potential fixes. In some embodiments, the DIV system115generates635the format of the data message and the instructions on how to populate the fields of the data message from the information source database110. The source system105would then follow those instructions in populating the data message as shown in Step515(shown inFIG.5). Instructions can include, but are not limited to, which fields to place where in the data message, how to format those fields, and how to generate the data for the fields using available data from the information source database110.

In some embodiments, the DIV system115instructs the information source database110to store some information differently, such as in a different format, to allow the source system105to quickly and efficiently build515the data message.

In some embodiments, the DIV system115transmits the data locations of the data fields in the data message to each of the downstream systems125-135, so that each one knows which fields to extract data from. In some embodiments, the destination systems125-135receive a complete mapping of the data message. In other embodiments, the destination systems125-135receive the mappings of the data fields that are to be retrieved by the corresponding destination system125-135.

FIGS.7A and7Billustrate views700and720of a user interface for viewing the results of a data validation and integrity check in accordance with at least one embodiment. Views700and720display a dashboard for quickly and efficiently viewing the results of a data validation and integrity check. The dashboard shown inFIGS.7A and7Bdisplays a holistic view of the quality of the data in the data message. The dashboard can display the results of data message validation525(shown inFIG.5) and/or the results of detected rules conflicts620(shown inFIG.6). In view700, the dashboard includes a plurality of selectable filters705, which allow the user to choose which information to view. View700also includes a numerical display710to show the number of validation issues (errors and warnings) that were discovered. View700further includes a graphical display715to show the validation issues in a pie chart separated by type or other visual presentation. In view720, one or more of the filters705have been selected and the numerical display710and the graphical display715have been updated based on the selected filters. Furthermore, in view720, a validation issues display area725displaying individual validation issues. In some embodiments, a user can drill down to learn more about the validation issues that have arisen. In some embodiment, the user can select a pie piece from the graphical display715and have the validation issues associated with that pie piece displayed in the validation issue display area725. The user can also select an individual validation issue in the validation issue display area725to learn more information about the individual validation issue.

FIG.8illustrates a process800for performing data validation and integrity checks using at least one of the system100(shown inFIG.1), the system200(shown inFIG.2), and the system400(shown inFIG.4). In the exemplary embodiment, process800is performed by the DIV system115(shown inFIG.1).

In the exemplary embodiment, the DIV system115stores805a plurality of rules for transmitting to a plurality of destination systems125-135. The plurality of destination systems includes a first destination system, such as destination system A125, and a second destination system, such as destination system B130. The data message includes a first plurality of fields for the first destination system125and a second plurality of fields for the second destination system130.

In the exemplary embodiment, the DIV system115receives810, from a requesting system, such as source system105(shown inFIG.1), a data message for transmission to the plurality of destination systems125-135. The data message is configured to be routed to each of the plurality of destination systems125-135. The plurality of destination systems includes a first destination system125and a second destination system130. The data message is configured to be routed to the first destination system125and then from the first destination system to the second destination system130.

In the exemplary embodiment, the DIV system115compares815the data message to the plurality of rules to validate the data message. If the data message is validated, the DIV system115instructs820the requesting system to transmit the data message to the plurality of destination systems125-135. The DIV system115determines one or more validation errors based on the comparison. The one or more validation errors can include at least one of missing data, incorrect data, improperly formatted data, and failed conditional logic. The DIV system115determines whether or not to validate the data message based on the one or more validation errors. The DIV system115determines an error level for each validation error of the one or more validation errors. The error level includes at least one of a low level and a high level.

The DIV system115validates the data message if none of the one or more validation errors includes a high level. The DIV system115indicates that the validation failed if at least one validation error of the one or more validation errors includes a high level. The DIV system115requests a user input in response to a validation error including a high level. The DIV system115adjusts the data message to correct at least one validation error of the one or more validation errors. The DIV system115stores the one or more validation errors for further review.

The data message is assembled by a source system105from a source database, such as information source database110, based on a predetermined data format including a plurality of fields to be populated from the source database110. The source system105retrieves a data value from the source database110. The source system105converts the data value from a first format to a second format. The source system105populates a data field of the data message with the converted data value. The source system105retrieves a data value from the source database110. The source system105populates a first data field of the data message with the data value. The first data field is associated with a first destination system, such as destination system A125of the plurality of destination systems125-135. The source system105converts the data value from a first format to a second format. The source system105populates a second data field of the data message with the converted data value. The second data field is associated with a second destination system, such as destination system B130, of the plurality of destination systems125-135.

The plurality of destination systems125-135includes a first destination system125and a second destination system130. The DIV system115receives a first plurality of rules from the first destination system125. The DIV system115receives a second plurality of rules from the second destination system130. The DIV system115compares the first plurality of rules to the second plurality of rules. The DIV system115generates the plurality of rules based on the comparison. The DIV system115detects a first conflict between the first plurality of rules and the second plurality of rules associated with a first data field. The DIV system115generates a format for the data message to include a first version of a first data field for the first destination system125and a second version of the first data field for the second destination system130.

FIG.9illustrates an example configuration of user computer device902used in the system100(shown inFIG.4), in accordance with one example of the present disclosure. User computer device902is operated by a user901. The user computer device902can include, but is not limited to, the source system105and the destination systems125-135(shown inFIG.1). The user computer device902includes a processor905for executing instructions. In some examples, executable instructions are stored in a memory area910. The processor905can include one or more processing units (e.g., in a multi-core configuration). The memory area910is any device allowing information such as executable instructions and/or transaction data to be stored and retrieved. The memory area910can include one or more computer-readable media.

The user computer device902also includes at least one media output component915for presenting information to the user901. The media output component915is any component capable of conveying information to the user901. In some examples, the media output component915includes an output adapter (not shown) such as a video adapter and/or an audio adapter. An output adapter is operatively coupled to the processor905and operatively coupleable to an output device such as a display device (e.g., a cathode ray tube (CRT), liquid crystal display (LCD), light emitting diode (LED) display, or “electronic ink” display) or an audio output device (e.g., a speaker or headphones). In some examples, the media output component915is configured to present a graphical user interface (e.g., a web browser and/or a client application) to the user901. A graphical user interface can include, for example, an interface for viewing validation errors. In some examples, the user computer device902includes an input device920for receiving input from the user901. The user901can use the input device920to, without limitation; select a validation error to view. The input device920can include, for example, a keyboard, a pointing device, a mouse, a stylus, a touch sensitive panel (e.g., a touch pad or a touch screen), a gyroscope, an accelerometer, a position detector, a biometric input device, and/or an audio input device. A single component such as a touch screen can function as both an output device of the media output component915and the input device920.

The user computer device902can also include a communication interface925, communicatively coupled to a remote device such as the DIV system115(shown inFIG.1), one or more destination systems125-135, and the source system105. The communication interface925can include, for example, a wired or wireless network adapter and/or a wireless data transceiver for use with a mobile telecommunications network.

Stored in the memory area910are, for example, computer-readable instructions for providing a user interface to the user901via the media output component915and, optionally, receiving and processing input from the input device920. A user interface can include, among other possibilities, a web browser and/or a client application. Web browsers enable users, such as the user901, to display and interact with media and other information typically embedded on a web page or a website from the source system105or the DIV system115. A client application allows the user901to interact with, for example, the DIV system115. For example, instructions can be stored by a cloud service, and the output of the execution of the instructions sent to the media output component915.

The processor905executes computer-executable instructions for implementing aspects of the disclosure.

FIG.10illustrates an example configuration of a server computer device1001used in the system100(shown inFIG.1), in accordance with one example of the present disclosure. Server computer device1001can include, but is not limited to, the source system105, the DIV system115, and the destination systems125-135(shown inFIG.1). The server computer device1001also includes a processor1005for executing instructions. Instructions can be stored in a memory area1010. The processor1005can include one or more processing units (e.g., in a multi-core configuration).

The processor1005is operatively coupled to a communication interface1015such that the server computer device1001is capable of communicating with a remote device such as another server computer device1001, the source system105, the DIV system115, and the destination systems125-135. For example, the communication interface1015can transmit data messages to the destination systems125-135via the Internet, as illustrated inFIG.1.

The processor1005can also be operatively coupled to a storage device1034. The storage device1034is any computer-operated hardware suitable for storing and/or retrieving data, such as, but not limited to, data associated with the information source database110and the rules database (both shown inFIG.1). In some examples, the storage device1034is integrated in the server computer device1001. For example, the server computer device1001can include one or more hard disk drives as the storage device1034. In other examples, the storage device1034is external to the server computer device1001and can be accessed by a plurality of server computer devices1001. For example, the storage device1034can include a storage area network (SAN), a network attached storage (NAS) system, and/or multiple storage units such as hard disks and/or solid state disks in a redundant array of inexpensive disks (RAID) configuration.

In some examples, the processor1005is operatively coupled to the storage device1034via a storage interface1020. The storage interface1020is any component capable of providing the processor1005with access to the storage device1034. The storage interface1020can include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor1005with access to the storage device1034.

The processor1005executes computer-executable instructions for implementing aspects of the disclosure. In some examples, the processor1005is transformed into a special purpose microprocessor by executing computer-executable instructions or by otherwise being programmed. For example, the processor1005is programmed with instructions such as those shown inFIGS.5,6, and8.

Described herein are computer systems such as the data integrity and validation computer devices and related computer systems. As described herein, all such computer systems include a processor and a memory. However, any processor in a computer device referred to herein can also refer to one or more processors wherein the processor can be in one computing device or a plurality of computing devices acting in parallel. Additionally, any memory in a computer device referred to herein can also refer to one or more memories wherein the memories can be in one computing device or a plurality of computing devices acting in parallel.

As used herein, a processor can include any programmable system including systems using micro-controllers, reduced instruction set circuits (RISC), application-specific integrated circuits (ASICs), logic circuits, and any other circuit or processor capable of executing the functions described herein. The above examples are example only, and are thus not intended to limit in any way the definition and/or meaning of the term “processor.”

As used herein, the term “database” can refer to either a body of data, a relational database management system (RDBMS), or to both. As used herein, a database can include any collection of data including hierarchical databases, relational databases, flat file databases, object-relational databases, object oriented databases, and any other structured collection of records or data that is stored in a computer system. The above examples are example only, and thus are not intended to limit in any way the definition and/or meaning of the term database. Examples of RDBMS' include, but are not limited to including, Oracle® Database, MySQL, IBM® DB2, Microsoft® SQL Server, Sybase®, and PostgreSQL. However, any database can be used that enables the systems and methods described herein. (Oracle is a registered trademark of Oracle Corporation, Redwood Shores, California; IBM is a registered trademark of International Business Machines Corporation, Armonk, New York; Microsoft is a registered trademark of Microsoft Corporation, Redmond, Washington; and Sybase is a registered trademark of Sybase, Dublin, California.)

In another example, a computer program is provided, and the program is embodied on a computer-readable medium. In an example, the system is executed on a single computer system, without requiring a connection to a server computer. In a further example, the system is being run in a Windows® environment (Windows is a registered trademark of Microsoft Corporation, Redmond, Washington). In yet another example, the system is run on a mainframe environment and a UNIX® server environment (UNIX is a registered trademark of X/Open Company Limited located in Reading, Berkshire, United Kingdom). In a further example, the system is run on an iOS® environment (iOS is a registered trademark of Cisco Systems, Inc. located in San Jose, CA). In yet a further example, the system is run on a Mac OS® environment (Mac OS is a registered trademark of Apple Inc. located in Cupertino, CA). In still yet a further embodiment, the system is run on Android® OS (Android is a registered trademark of Google, Inc. of Mountain View, CA). In another embodiment, the system is run on Linux® OS (Linux is a registered trademark of Linus Torvalds of Boston, MA). The application is flexible and designed to run in various different environments without compromising any major functionality.

In some examples, the system includes multiple components distributed among a plurality of computer devices. One or more components can be in the form of computer-executable instructions embodied in a computer-readable medium. The systems and processes are not limited to the specific embodiments described herein. In addition, components of each system and each process can be practiced independent and separate from other components and processes described herein. Each component and process can also be used in combination with other assembly packages and processes. The present examples can enhance the functionality and functioning of computers and/or computer systems.

As used herein, an element or step recited in the singular and proceeded with the word “a” or “an” should be understood as not excluding plural elements or steps, unless such exclusion is explicitly recited. Furthermore, references to “example” or “one example” of the present disclosure are not intended to be interpreted as excluding the existence of additional embodiments that also incorporate the recited features.

As used herein, the terms “software” and “firmware” are interchangeable, and include any computer program stored in memory for execution by a processor, including RAM memory, ROM memory, EPROM memory, EEPROM memory, and non-volatile RAM (NVRAM) memory. The above memory types are example only, and are thus not limiting as to the types of memory usable for storage of a computer program.

Furthermore, as used herein, the term “real-time” refers to at least one of the time of occurrence of the associated events, the time of measurement and collection of predetermined data, the time to process the data, and the time of a system response to the events and the environment. In the examples described herein, these activities and events occur substantially instantaneously.

The systems and processes are not limited to the specific examples described herein. In addition, components of each system and each process can be practiced independent and separate from other components and processes described herein. Each component and process also can be used in combination with other assembly packages and processes.

The patent claims at the end of this document are not intended to be construed under 35 U.S.C. § 112(f) unless traditional means-plus-function language is expressly recited, such as “means for” or “step for” language being expressly recited in the claim(s).

The computer-implemented methods discussed herein can include additional, less, or alternate actions, including those discussed elsewhere herein. The methods can be implemented via one or more local or remote processors, transceivers, servers, and/or sensors (such as processors, transceivers, servers, and/or sensors mounted on vehicles or mobile devices, or associated with smart infrastructure or remote servers), and/or via computer-executable instructions stored on non-transitory computer-readable media or medium. Additionally, the computer systems discussed herein can include additional, less, or alternate functionality, including that discussed elsewhere herein. The computer systems discussed herein may include or be implemented via computer-executable instructions stored on non-transitory computer-readable media or medium.

As used herein, the term “non-transitory computer-readable media” is intended to be representative of any tangible computer-based device implemented in any method or technology for short-term and long-term storage of information, such as, computer-readable instructions, data structures, program modules and sub-modules, or other data in any device. Therefore, the methods described herein can be encoded as executable instructions embodied in a tangible, non-transitory, computer readable medium, including, without limitation, a storage device and/or a memory device. Such instructions, when executed by a processor, cause the processor to perform at least a portion of the methods described herein. Moreover, as used herein, the term “non-transitory computer-readable media” includes all tangible, computer-readable media, including, without limitation, non-transitory computer storage devices, including, without limitation, volatile and nonvolatile media, and removable and non-removable media such as a firmware, physical and virtual storage, CD-ROMs, DVDs, and any other digital source such as a network or the Internet, as well as yet to be developed digital means, with the sole exception being a transitory, propagating signal.

This written description uses examples to disclose various implementations, including the best mode, and also to enable any person skilled in the art to practice the various implementations, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the disclosure is defined by the claims, and can include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal language of the claims.