Dynamically merging database tables

The present disclosure relates to dynamically merging database tables according to user specified parameters. A user may specify a threshold confidence level that relates to a likelihood that two database records represent the same real-world entity. In addition, a user may specify a merge rule such as desired fields or a manner for consolidating the variations of the information in desired fields from the related records. The original database tables are preserved so that users can iteratively create new dynamically merged database tables by varying the parameters.

BACKGROUND

In the course of business, large amounts of data records are collected and stored in one or more databases. These data records may reflect customer information, business records, events, products, or other records pertinent to a relevant business. These records can accumulate from a number of data sources. For example, a retail company may sell products over different channels such as online e-commerce platforms as well as physical store locations. The retail company may maintain separate customer records for each of its different retail channels.

Records may be maintained in separate database tables. Merging two database tables may be time consuming and costly. The present disclosure describes systems and methods of managing a database that overcomes a number of the drawbacks of prior art solutions. The advantages and benefits of the present disclosure will be discussed in further detail.

DETAILED DESCRIPTION

Various embodiments of the present disclosure relate to dynamically merging two or more database tables based on one or more user parameters. Merging database tables can be a time consuming and burdensome process. Techniques such as extract transform load (ETL) are time intensive processes that may require significant user input and human intervention to create a merged database table. This may be the case where there is a likelihood that redundant records exist within the two or more database tables that are being merged.

The present disclosure provides an effective way of dynamically merging two or more database tables. A user may specify parameters such as the desired database fields and/or a confidence level relating to the likelihood that two records represent the same real-world entity. In response to these parameters, a merged database table is dynamically generated. The original database tables are persistently stored so that they can be used to generate a variety of dynamically merged database tables as a user varies between different database parameters. Moreover, any links to relational tables continue to exist. This way, the dynamically created database table uses the preexisting links to any relational tables.

FIG. 1shows a computing system100according to various embodiments. The computing system100is made up of a combination of hardware and software. The computing system100includes a database103, software application106, and a classifier109. The computing system100may be connected to networks such as the Internet, intranets, extranets, wide area networks (WANs), local area networks (LANs), wired networks, wireless networks, or other suitable networks, etc., or any combination of two or more such networks.

The computing system100may comprise, for example, a server computer or any other system providing computing capability. Alternatively, the computing system100may employ a plurality of computing devices that may be arranged, for example, in one or more server banks or computer banks or other arrangements. Such computing devices may be located in a single installation or may be distributed among many different geographical locations. For example, the computing system100may include a plurality of computing devices that together may comprise a hosted computing resource, a grid computing resource and/or any other distributed computing arrangement. In some cases, the computing system100may correspond to an elastic computing resource where the allotted capacity of processing, network, storage, or other computing-related resources may vary over time. The computing system100may implement one or more virtual machines that use the resources of the computing system100.

Various applications and/or other functionality may be executed in the computing system100according to various embodiments. Also, various data is stored in the database103or other memory that is accessible to the computing system100. The database103may represent one or more databases103.

The data stored in the database103includes one or more database tables112. A database table112includes several records, where each record has one or more corresponding fields. A database table112may be linked or otherwise associated with one or more relational tables115. The components executed on the computing system100include a software application106and a classifier109, which may access the contents of the database103. When stored in a relational database103, a database table112may be linked to one or more relational tables115. For example, if an airline company maintained a database table112that stored customer records, there may be a relational table115storing the flight history for each customer. The contents of the relational table115links to a corresponding record.

Next, a general description of the operation of the various components of the computing system100is provided. Various businesses or other entities utilize the computing system to store information in a database103. For example, businesses may want to store records reflecting customers, products, transactions, events, items, or any other piece of information relevant to the business. Records are collected over time and stored in one or more database tables112. For example, when a business gets a new customer, a software program may create a record reflecting the new customer. This record may include the customer's name, address, contact information, or any other information that identifies the customer. Such information is stored as fields within a database table. The values in a field may be used to calculate one or more features between records.

In practice, a single record is sufficient to represent a customer. However, it is possible that duplicate or redundant records are inadvertently or unintentionally created and/or exist within one or more databases103. For example, a customer may register with a business via an online portal which creates a customer record for that customer. Later, the same customer may inadvertently register again with the online portal, thereby creating a redundant customer record in the database table. Also, a company may have a first database table for its brick and mortar customers and a second database table for its e-commerce customers. It is possible that the same customer has a corresponding record in these two different database tables. As another example, two businesses maintaining their own customer records may merge such that the same customer may exist in two different database tables112. The resulting merged database table could have redundant records reflecting the same customer.

Because multiple records may represent the same real-world entity, it is desirable to group related records together. A classifier109may be used to determine whether two records should be classified as a match based on the degree of related or common values between the two records. The classifier109may be a binary classifier that determines whether a pair of records represent the same real-world entity or whether they do not represent the same real-world entity. A record pair (i.e., two records being compared) is considered to be a related record pair if it represents the same real-world entity or an unrelated pair if it does not. A classifier109may make decisions based on a threshold level of similarity. The classifier109may calculate a confidence level (e.g., a score) that quantifies the degree of similarity between two records. Then, the classifier109may output a binary result (e.g., yes or no) that the two records are similar enough to be deemed a related record pair if the confidence level exceeds a threshold confidence level. The classifier109may make its determination based on the extent that two records contain similar information.

When comparing records, different combinations of field values among the two records are compared. For example, in one embodiment, the value of F1 of the first record is compared to the value of F1 of a second record, then the value of F2 of the first record is compared to the value of F2 of the second record, and so on. The comparison of two values yields a feature with respect to the record pair. A feature is a programmed calculation taking as inputs M records and/or other data, such as external metadata, and returning a numeric value as output. The variable M=2 in the case of handling a record pair. That numeric output may be, for example, a real value bounded between 0 and 1, or a binary value with two distinct outputs, 0 being considered “false” and 1 being considered “true.” A feature score is the specific output value generated by a feature for a given set of records or record pair. A feature score refers to the degree that two field values are the same.

For example, comparing the first name field value of “Joseph” to the first name field value of “Joe” may yield a “first name feature” having a feature score of 0.88 on a scale of 0 to 1, where 0 means no-match and 1 means a perfect match. In other embodiments, the first name feature may be a binary value of “true/T,” meaning match, or “false/F”, meaning no-match. In addition, features may be determined based on a combination of field values. Here, a feature may be “full_name_match,” which is a feature based on concatenating a first name field value with a last name field value.

The software application106dynamically merges two or more database tables112based on specified user parameters. The software application106uses the classifier109to determine whether two records appearing in two different database tables112should be represented as a single record in the dynamically merged database table. The software application106also creates the dynamically merged database table based on a user's specification of desired fields. The software application106may generate numerous dynamically merged database tables based on different parameters because the underlying database tables112are preserved along with any links to relational tables115.

FIG. 2shows an example of a first database table112aand a second database table112bthat represent examples of database tables112stored in the database103ofFIG. 1according to various embodiments of the present disclosure. A database table112includes a set of records201and one or more fields213. A record201may or may not have all its fields213populated with values. Each record is intended to represent an entity such as, for example, a person, thing, event, or place. Such entities reflect something that is part of the real-world. Moreover, records may contain different or possibly conflicting information even though they intend to represent the same real-world entity.

For example, in the first database table112a, a first record “A1” is intended to be the record representing an individual named “Jane Doe.” Record “A2” is intended to be the record representing “John Smith” and so on. A second database table112bhas different records201, but some of those records may represent the same entity that is reflected by a record201in the first database table112a. For example, both records “A3” and “B3” may represent the same individual named “Stephen Meyles,” even though they are separate records201.

FIG. 2also shows how each database table112has its own set of fields213. A field213provides a specification of a particular attribute of a record201. If a record is a customer record, then a field213may be “first name” or “last name.” The first database table112ahas three fields being F1, F2, and F3 which refer to “first name,” last name,” and “area code,” respectively. The second database table112bhas three fields being F1, F2, and F4 which refer to “first name,” last name,” and “zip code,” respectively. Fields F1 and F2 are common to both the first database table112aand the second database table112b. Fields F3 and F4 are not.

In various embodiments, the fields213are semantic fields such that they are normalized across several database tables112. For example, a first database table112amay have its F2 field originally called “last_name” while a second database table112bmay have its F2 field originally called “surname.” By using semantic fields, the first and second database tables112aand112bconform to a universal format of identifying its fields. This way, the software application106(FIG. 1) understands that the “last_name” field of the first database table112amaps to the “surname” field of second database table112b. The database103may store a lookup table that maps original fields to semantic fields in order to normalize the fields across multiple database tables112.

FIG. 3is an example of merging two database tables in manner that is not dynamic. Without employing the software application106of the present disclosure, a first and a second database table112aand112bare joined together to create a merged database table308. This process requires significant manual input. The merged database may be scrubbed to identify duplicate records.

The first database table112ais linked to a first relational table115aand a second relational table115bwhile the second database table112bis linked to a third relational table115c. When a merged database table308is created, new links are created in order to associate the merged database table308with the new relational tables315a-cthat are derived from the original relational tables115a-c. Once the merged database table308is created along with replicating the links to relational tables115, the first database table112aand second database table112b(along with any corresponding relational tables115a-c) are no longer needed. The merged database table308is intended to be a comprehensive representation of all information contained within the first and second database tables112aand112b.

FIG. 4is an example of dynamically merging database tables within the computing system100ofFIG. 1according to various embodiments of the present disclosure.FIG. 4depicts the software application106that operates by dynamically merging a first database table112awith a second database table112bto create a dynamically merged database table416. The software application106receives an input from a user that specifies certain parameters, which is discussed in more detail with respect toFIG. 6. The parameters specify how to construct a dynamically merged database table416. For example, the parameters may include a threshold confidence level relating to the probability that two records represent to the same entity. As discussed in further detail below, the software application106may generate various dynamically merged database tables416, each of which are customized based on user-specified parameters.

In response to receiving parameters, the software application106generates a dynamically merged database table416on the fly. In addition, the first and second database tables112aand112bare preserved so that more dynamically merged database tables416may be created by varying the parameters.

In addition, the dynamically merged database table416is linked to preexisting relational tables115. In other words, the software application106does not need to create new relational tables115that are linked to the dynamically merged database table416. This is demonstrated in further detail with respect toFIGS. 6A and 6B.

FIG. 5is an example of operations performed by the software application106in the computing system100ofFIG. 1according to various embodiments of the present disclosure. The operations shown inFIG. 5demonstrate a manner of comparing two records to create a dynamically merged database table416(FIG. 4).

The software application106is configured to access records in a first database table112aand records in a second database table112b. The software application106selects a record pair made up of a first record503and a second record506taken from a first and second database table112aand112b, respectively. Once a record pair is selected, the software application106performs a pairwise comparison509. This may involve comparing the field values between the two records503and506. As shown inFIG. 5, a first record503may be “A1” and a second record506may be “B1.”

The pairwise comparison509generates a feature signature512, which is created using a set of features between a pair of records. The feature signature512reflects how two records are similar or dissimilar based on the records' contents. As an example, the feature signature may be generated using a number of features such as “fuzzy_first_name_match”, “fuzzy_last_name_match”, “email_match”, “zip_code_match”, “last_4_SNN_digits_match”, etc. Two different record pairs may have the same feature signature512even though they represent different entities. In this case, it is inferred that the records in the first pair are similar to each other in the same way that the records in the second pair are similar to each other. For example, given the trivial set of binary features “Fuzzy Last Name match” and “Fuzzy First Name match”, the record pair {“Stephen Meyles”, “Steve Myles” } will generate a feature signature of [1 1], where “1” refers to a binary value indicating a match. In addition, a record pair of {“Derek Slager”, “Derke Slagr”} will also generate a feature signature of [1 1]. This does not necessarily mean that the first pair of records are related to the same real-world identity as the second pair of records. Instead it suggests that the records have the same data variations (fuzzy matches of first and last name). Records with the same data variations may have the same feature signature512.

By way of example using binary features, assume that a first record having fields F1-F5 is compared to a second record having fields F1-F5 to determine the following five features: “F1_match”, “F2_match”, F3_match”, F4_match”, and F5_match”. In addition, assume that the values in fields F1 and F2 are the same while the values in fields F3-F5 are different between the two records. Then, a feature signature512may be “11000.” The “1s” in the feature signature512refer to fields that have common values while the “0s” refer to fields that have different values. Here, F1=1, F2=1, F3=0, F4=0, and F5=0, yielding “11000.” In other embodiments, non-binary features may be used to construct a feature signature512. For example, a “fuzzy_match” feature may yield a score ranging from 0 to 1 that correlates the strength of similarity between field values.

After generating the feature signature512, the software application106uses a classifier109(FIG. 1) to perform a classification process515on the feature signature512to generate a result518. The classification process generates a confidence score524which represents a level of confidence that a particular record pair521represents the same entity. The example inFIG. 5shows a confidence score524that ranges from 0 to 1, where 0 represents 0 percent confidence that two records are similar and where 1 represents a 100% confidence. A first record pair521made up of record “A1” and record “B4” (SeeFIG. 2) yields a confidence score524of “0.42.” In other words, there is a 42% confidence that record “A1—Jane Doe” refers to the same person that is referenced in record “B4—Janet Doe.” Stated differently, the confidence score524corresponds to a confidence level that a record pair521represents duplicative or redundant information.

FIGS. 6A and 6Bare examples of dynamically merged database tables created within the computing system100ofFIG. 1, according to various embodiments of the present disclosure.FIGS. 6A and 6Bshow different examples of dynamically merged database tables416generated in response to different parameters608. The dynamically merged database tables416includes one or more related record pairs618and one or more unique records622. Related record pairs618refer to a pair of records taken from the first database table112aand the second database table112bthat have a relatively high confidence that the record pair commonly represents the same entity, such as a person or other real-world entity. Unique records622are records that have a relatively high confidence that they uniquely refer to different entities, such as different people.

FIG. 6Ashows a software application106that generates a dynamically merged database table416abased on parameters608a. The parameters608amay be specified by a user who wishes to merge a first database table112a(FIG. 2) with a second database table112b(FIG. 2). The parameters608may include a threshold confidence level and/or a database merge rule. The threshold confidence level may be a value that correlates to a degree that two records are similar or likely to be similar. InFIG. 6Athe user has specified a threshold confidence level of 0.5. A lower confidence level may lead to more related record pairs618. This can reduce the number of entries in the dynamically merged database table416a. In other words, a lower threshold confidence level means there is more tolerance when grouping together two records from different database tables112aand112b.

The parameters608aalso comprises a database merge rule which includes, for example, a specification of desired fields. As shown inFIG. 6A, a user wishes to customize a dynamically merged database table416ato include only fields F1 and F2 (as opposed to all available fields). Thus, the database merge rule indicates one or more desired field selected from fields213(FIG. 2) within the first database table112aor the second database table112b. The merge rule may also indicate a manner for consolidating variations in the information in desired fields from the related records. For example, if A4 and B2 form a related record pair618, a merge rule can specify how to determine field values of the dynamically merged database table based416aon the field values of records A4 and B2. One example is to select the field values of the most recent record among the record pair. Here, the name of the record associated with the most recent timestamp will be selected.

The use of database merge rules as a parameter608aallows users to generate dynamically merged database tables416afor specific purposes. If the user wishes to change the fields213in the dynamically merged database tables416a, the user can create a new dynamically merged database table416with different merge rules.

The dynamically merged database table416aofFIG. 6Ashows how a first database table112a(FIG. 2) has been dynamically merged with a second database table112b(FIG. 2) in response to parameters608a. Rather than having a separate entry for records A1-A5 and B1-B4, the dynamically merged database table416acombines record “A3” with “B3” and further combines record “A4” with “B2.” The manner of combining two records is determined according to a merge rule. Both record pairs618have a confidence level that exceeds a specified threshold confidence level of “0.5.” Records A3 and B3 form a related record pair618because they have relatively high confidence that they refer to the same entity, a person named “Stephen Meyles.” Specifically, the A3-B3 record pair521has a confidence score524of “0.98” which is relatively higher than the threshold confidence level of “0.5” of the user-specified parameters608a. Similarly, the A4-B2 record pair521is also considered a related record pair618in the example ofFIG. 6A.

Records A1, A2, A5, B1, and B4 form a set of unique records with respect to the first and second database tables112aand112b. In other words, based on the threshold confidence level of “0.5,” records A1, A2, A5, B1, and B4 are not sufficiently similar to be part of a related record pair618. For example, record “A1,” which is in the first database table112a, is not similar enough with respect to the records in the second database table112bby comparing the confidence scores524with the threshold confidence level.

The dynamically merged database table416aprovides each unique record622its own database entry. It also combines the related record pair618to conform to a single database entry. Thus, each related record pair618is treated as a single entry within the dynamically merged database table416a.

In various embodiments, the merge rule can specify that the field values of a related record pair618should be equal to either one of the original field values. For example, record “A4” refers to a person named “Carlos Sakoda” and record “B2” refers to a person named “Chuck Sakoda.” The software application106determined that the record pair521of “A4-B2” has a confidence score of “0.78.” Qualitatively, that means that there is a reasonably high confidence that “A4” and “B2” refer to the same entity, which represents a particular person in the real-world. If the parameter specifies a confidence level of greater than “0.5,” the dynamically merged database table416awill treat this record pair521as a related record pair618having a single database entry. Moreover, the F1 field, “first name,” is equal to “Chuck” OR “Carlos.” A merge rule may specify the manner in selecting to use either “Chuck” OR “Carlos” in the dynamically merged database416a. Thus, the field value may be an array of values derived from the original field values in the related record pair618. As another example, the merge rule may choose the longer of two text strings of competing field values. In this case, “Carlos” would be selected over “Chuck” because it is longer in terms of the number of characters. In any case, the resulting database entry for a related record pair618is derived from the field values of the records in the related record pair618.

In other embodiments, the merge rule may specify a format for the field values that is not necessarily used in the original records. For example, the merge rule may specify using a postal service address format for address field values. Here, an address field value in the merged database table416would be derived from the address field values contained within both records in the related record pair618.

The dynamically merged database table416ais linked to any relational tables115(FIG. 4) that are originally linked to the first or second database tables112aor112b(FIG. 4). This is explained in the following example. Record “B2” is part of the second database table112b. As shown inFIG. 4, the second database table is linked to relational table115c. The relational table115cmay be used, for example, to store transaction history for each customer record in the second database table112b. In this case, a customer record in the second database table112b, such as “B2,” is linked to transaction history stored in the relational table115c. Because the dynamically merged database table416ahas joined B2 with A4, A4 is transitively linked to the relational table115cbecause it is part of a related record pair with respect to record “B2.” Thus, the transaction history for “Chuck Sakoda” now applies to “Carlos Sakoda.” By leveraging the preexisting relational table115c, no new relational table needs to be created.

FIG. 6Bshows a different parameter608bused to generate a second dynamically merged database table416b. Multiple dynamically merged database tables416may be generated in response to different parameters608. This is because the underlying database tables112are persistently stored in a database103(FIG. 1). InFIG. 6Bthe user specifies a threshold confidence level of “0.85.” This is higher than the confidence level specified in the example ofFIG. 6A. A user may wish to have a higher confidence level to reduce the occurrence of inaccurately identifying related record pairs618at the cost of increasing the size of the dynamically merged database table416b. In this example, the software application106will likely find fewer related record pairs618with a higher threshold confidence level.

When comparingFIG. 6AtoFIG. 6B, the second dynamically merged database table416bseparates out records “A4” and “B2” as two unique records622while the first dynamically merged database table416atreated these two records as a related record pair618. This is because the record pair A4-B2 has a threshold confidence level of “0.78” which meets the parameters608ainFIG. 6Abut not the parameters608bofFIG. 6B. As a result, the second dynamically merged database table416bhas a larger size, in terms of number of record entries.

FIG. 7is a flowchart that provides an example of the operation of the software application106according to various embodiments. It is understood that the flowchart ofFIG. 7provides merely an example of the many different types of functional arrangements that may be employed to implement the operation of the portion of the software application as described herein. As an alternative, the flowchart ofFIG. 7may be viewed as depicting an example of elements of a method implemented in the computing system100(FIG. 1) according to one or more embodiments.

Beginning at702software application106accesses a database103(FIG. 1). Here, the software application106selects two database tables112(FIG. 1) to dynamically merge. The database tables may use semantic fields to assist in the comparison of fields between a first database table112aand a second database table112b(FIG. 2). The software application106may have continuous access to the database103in order to generate dynamically merged database tables416(FIG. 4).

At705the software application106waits to obtain parameters from a user. Parameters608are used to determine how to dynamically merge the first and second database tables112aand112b. A user may specify a parameter608(FIGS. 6A and 6B) by providing user input to the software application106. The user may submit user input via an online portal, client-side application, online form, or any other mechanism to transmit data within the computing system100(FIG. 1). The software application106obtains the parameters608from a user's client device that interfaces with the software application106.

At708the software application106compares the records in the first database table112aand records in the second database table112bto determine a confidence score524between different record pairs521. The confidence score524is used to identify related record pairs618, which are duplicative or redundant records existing within the first and second database tables112aand112b. For example, the software application106may perform a number of pairwise comparisons509(FIG. 5) on various record pairs521(FIG. 5) taken from the first and second database tables112aand112b. The pairwise comparison509may yield a feature signature512that quantifies the similarity between two records. The feature signature512may indicate which fields have related values between two records. Thereafter, the software application106may use a classifier109(FIG. 1) to evaluate the feature signature512.

At711the software application generates confidence scores524(FIG. 5) for different record pairs521. As mentioned above, the software application106may invoke the classifier109to quantify the probability or likelihood that two records reflect the same entity. In other words, the classifier109may generate a confidence score524that corresponds to the level of confidence that a record pair521should be deemed a related record pair618(FIG. 6) according to a threshold.

At713the software application106compares the confidence scores of various record pairs521to a threshold confidence level that is submitted as a parameter608. At716the software application identifies related record pairs618and unique records622. When a record pair521has a corresponding confidence score524(FIG. 5) that exceeds the threshold confidence level, that record pair521is considered to be a related record pair618. When a record pair521has a corresponding confidence score that does not exceed the threshold confidence level, the individual records in the record pair521are treated as unique records622(FIG. 6). Unique records622may include records within the first and second database tables112aand112bthat are not part of a related record pair618.

At719the software application106generates a dynamically merged database table416that includes a selected portion of the related record pairs618and includes the unique records. One record among the related record pairs618may be selected as a single table entry of the dynamically merged database table416. A merge rule determines a manner of selecting a record from the related record pair618. In one embodiment, the merge rule indicates that the more recent record among a related record pair618is selected. In another embodiment, the merge rule specifies that the record from the first database table112ashould be selected. In this respect, the merge rule specifies how to consolidate variations of information in record fields among related record pairs618.

Once created, the dynamically merged database table416is stored in the database103for future use. In addition, the first database table112aand the second database table112bcontinue to be persistently stored after the dynamically merged database table416is generated. Once generated, the software application106waits for new parameters705to generate additional dynamically merged database tables416. This way, the software application106may generate a plurality of dynamically merged database tables416by varying the user-specified threshold confidence level or any other parameter608.

FIG. 8shows a schematic block diagram of the computing system100according to an embodiment of the present disclosure. The computing system100includes one or more computing devices800Each computing device800includes at least one processor circuit, for example, having a processor803and a memory806, both of which are coupled to a local interface809or bus. To this end, each computing device800may comprise, for example, at least one server computer or like device. The local interface809may comprise, for example, a data bus with an accompanying address/control bus or other bus structures as can be appreciated.

Stored in the memory806are both data and several components that are executable by the processor803. In particular, stored in the memory806and executable by the processor803is the software application106. Also stored in the memory806may be a database103and other data such as, for example, dynamically merged database tables416, scores524, previously used parameters608, or any other data used to dynamically generate merged database tables. In addition, an operating system may be stored in the memory806and executable by the processor803.

Several software components are stored in the memory806and are executable by the processor803. In this respect, the term “executable” means a program file that is in a form that can ultimately be run by the processor803. Examples of executable programs may be, for example, a compiled program that can be translated into machine code in a format that can be loaded into a random access portion of the memory806and run by the processor803, source code that may be expressed in proper format such as object code that is capable of being loaded into a random access portion of the memory806and executed by the processor803, or source code that may be interpreted by another executable program to generate instructions in a random access portion of the memory806to be executed by the processor803, etc. An executable program may be stored in any portion or component of the memory806including, for example, random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, USB flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape, or other memory components.

Also, the processor803may represent multiple processors803and/or multiple processor cores and the memory806may represent multiple memories806that operate in parallel processing circuits, respectively. In such a case, the local interface809may be an appropriate network that facilitates communication between any two of the multiple processors803, between any processor803and any of the memories806, or between any two of the memories806, etc. The local interface809may comprise additional systems designed to coordinate this communication, including, for example, performing load balancing. The processor803may be of electrical or of some other available construction.

The flowchart ofFIG. 7shows the functionality and operation of an implementation of the software application106. If embodied in software, each box may represent a module, segment, or portion of code that comprises program instructions to implement the specified logical function(s). The program instructions may be embodied in the form of source code that comprises human-readable statements written in a programming language or machine code that comprises numerical instructions recognizable by a suitable execution system such as a processor803in a computer system or other system. The machine code may be converted from the source code, etc. If embodied in hardware, each block may represent a circuit or a number of interconnected circuits to implement the specified logical function(s).

Further, any logic or application described herein, including software application106, may be implemented and structured in a variety of ways. For example, one or more applications described may be implemented as modules or components of a single application. Further, one or more applications described herein may be executed in shared or separate computing devices or a combination thereof. For example, the software application described herein may execute in the same computing device800, or in multiple computing devices in the same computing system100. Additionally, it is understood that terms such as “application,” “service,” “system,” “engine,” “module,” and so on may be interchangeable and are not intended to be limiting.