Resolving similar entities from a database.

Field of the Invention

Embodiments of the present invention generally relate to data analysis and, more specifically, to resolving similar entities from a database.

Description of the Related Art

Obtaining relevant information from large databases can be relatively straightforward in some situations. Particularly, when the data records in a database are wellstructured and it is desired to obtain information in records having a particular value or character string in a particular field, those records can be isolated using filtering functions of database interfacing software. Using combinations of filtering functions, more sophistication can be provided to the way in which records are identified for isolation. The isolated records may then be aggregated so as to provide a report including all the records that together constitute the desired information.

However, in order to denote database records having commonality, such filtering functions rely on identical attributes across those database records. In the real world, database records may not have identical attributes across those records despite those records being related, or may have identical attributes in a relatively small number of fields (or parts of fields) such that filtering functions are unable to provide isolation of the desired database records from other database records. For example, such problems can occur when a database has database records originating from a number of different sources. The isolation of related database records from other database records is a technical problem that becomes worse as the database becomes larger (e.g., a database having billions of database records), in terms of the number of records present. With the sizes of databases in the real world increasing as time progresses, this problem is expected to worsen over time.

Embodiments of the invention address the problem of identifying related database records that may have not have useful identical attributes whilst excluding unrelated database records, and in particular solve the problem of identifying database records that relate to a common entity but which may have no identical attributes.

A first aspect of the invention provides a method for identifying related records from a database storing records for multiple entities as claimed in claim 1.

A second aspect of the invention provides a computer system as claimed in claim 12.

Optional features are listed in the dependent claims or are recited in the detailed description embodiments.

One advantage of the disclosed technique is that two record sets in a database of records that have no identical attributes, but belong to the same common entity, may be linked to the common entity. Therefore, resolutions that would be missed with string comparisons alone are made and incorrect resolutions based only on similar strings are avoided, which improves the resolution precision. Another advantage of the disclosed technique is that it reduces the number of mistaken aggregates resulting from records having similar identifiers despite being associated with different entities. By reducing the number of mistaken aggregates, an aggregated report of record sets thus provided occupies less memory than a corresponding aggregated report produced by filtering functions.

Brief Description of the Drawings

So that the manner in which the above recited features of the present invention can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.

Figure 1 is a block diagram illustrating a computer system configured to implement one or more aspects of the present invention.

Figure 2 is a block diagram of the flow of data in through the application server.

Figure 3 illustrates a method for training the classifier, according to one embodiment.

Figure 4 illustrates a method of resolving merchant ID to a merchant, according to one embodiment.

Figure 5 illustrates an example of a computing environment, according to one embodiment.

Detailed Description

Embodiments of the invention may be used to aggregate certain records that are resolved to a common entity, but might not otherwise be grouped with one another. Assuming a database identifies records from each distinct account of an entity by a distinct ID attribute, then the distinct ID attributes may not be matched correctly to link the records of the accounts with the entity.. In one embodiment, a system combines records into ID sets based upon identical IDs, so each ID set contains all of the records with a particular ID.

As this example illustrates, a single entity may be represented by multiple IDs. To evaluate the full set of records for a single entity each collection of records (the ID sets) associated with the single entity need to be merged together .

For example, embodiments of the invention may be used to aggregate certain financial transaction records that are resolved to a common entity, but might not otherwise be grouped with one another. Assuming a transaction database of a financial institution identifies transaction records from each distinct merchant account of a company by a distinct merchant ID attribute, then the distinct merchant IDs attributes may not be matched correctly to link the transaction records of the accounts with the company. As another example, different franchisees of common franchisor will have spate merchant accounts, making it difficult to aggregate the transaction records associated with all franchisees of the franchisor from the transaction records alone. In one embodiment, a financial analysis system combines transaction records into merchant ID sets based upon identical merchant IDs, so each merchant ID set contains all of the transaction records with a particular merchant ID. As this example illustrates, a single company may be represented by multiple merchant IDs. To evaluate the full set of transaction records for a single entity (company) each collection of financial transaction records (the merchant ID sets) associated with the single entity need to be merged together .

Background art for handling transaction records will now be described.

Financial institutions store transactional data for analysis. A financial institution generates transactional data from credit and debit card purchases at companies that have a merchant account with the financial institution. The merchant account may be used to processes individual credit or debit card purchases. In turn, each such purchase is stored as a transaction record in a transaction database. A transaction record associated with a particular merchant account oftentimes includes a merchant ID attribute that links the transaction record to the merchant account. A merchant ID may be any data type, including a number, a string, or some combination thereof. The financial institution may then analyze the transaction records from one or more merchant accounts. For example, an analysis may involve aggregating the transaction records of a merchant account or particular merchant accounts. The analysis may then compare the performance of the merchant account to that of competing merchant accounts in the same geographic area.

Although the financial institution stores the transaction records in a database of transactions, certain analysis may require the data to be organized in ways that are not part of the transaction records in the database. These databases contain sets of transaction records that an analysis should group together, even though there is no single attribute value that relates the transaction records. For example, if a financial institution configures a database of transactions with a merchant ID attribute that links each transaction record to a merchant account, then an analysis would easily aggregate transaction records with the same merchant ID together. However, a single company may have multiple merchant accounts with a financial institution. If the financial institution provides distinct merchant IDs for every merchant account, even when multiple merchant accounts belong to a single company, then it is difficult to aggregate transaction records together from the multiple merchant accounts of that company. For instance, a franchise company may have distinct merchant accounts with distinct merchant IDs for each franchisee location. In such a case, an analysis could not aggregate the transaction records of the franchise company together based on identical merchant IDs alone.

Instead, an analysis can use similarities between the merchant

ID attribute values to aggregate the transaction records of the franchise company together.

Existing techniques rely upon simple tests, such as string comparisons between an attribute in a database of transaction records to detect similarities between groups of transaction records. Transaction records including attribute strings that meet a measure of similarity are then aggregated together for analysis. These techniques may work as long as the attribute contains strings that are identical or similar for groups of transaction records that should be aggregated together and strings that are distinct for groups of transaction records that should not be aggregated together.

However, such identifiers are not always (or even usually) available. For example, different merchant IDs for the merchant accounts of a single company may prevent an analysis system from aggregating the transaction records of the company together. Furthermore, transaction records may contain similar identifiers that an analysis system may base aggregations upon, even if the transaction records should not be aggregated together. For example, two different companies may have merchant accounts with similar merchant IDs, which an analysis system could mistakenly match to one company. The analysis system may then mistakenly aggregate the transaction records of the two companies together.

As the foregoing illustrates, there remains a need for more effective techniques evaluating financial transaction records .

In one embodiment, the analysis system aggregates transaction records from a large collection of merchant ID sets. This aggregation may include calculating the average transaction size, the transaction size standard deviation, or the average amount that an individual has spent. The analysis system uses the aggregates to train a classifier. Once trained, the analysis system produces a confidence score of whether two merchant ID sets belong to a company, based upon the aggregates from the pair of merchant ID sets. To associate the merchant ID sets to the company, the analysis system receives a selection of an exemplar merchant ID set that should be associated with the company and best represents the characteristics of the company. The analysis system compares the exemplar merchant ID set with other merchant ID sets to determine a confidence score. The confidence score represents the likelihood that the exemplary merchant ID set and the other merchant ID set is associated with the company. The analysis system associates every merchant ID set having a confidence scores above a threshold, when compared with the exemplar, to the company. Doing so results in a collection of financial transaction records that presumably all belong to one company, despite the fact that many of such records may include different merchant IDs.

In the following description, numerous specific details are set forth to provide a more thorough understanding of the present invention. However, it will be apparent that the present invention may be practiced without one or more of these specific details.

Figure 1 is a block diagram illustrating an example data analysis system 100, according to one embodiment of the present invention. As shown, the data analysis system 100 includes an application server 140 running on a server computing system 130, a client 120 running on a client computer system 110, and at least one transaction database 160. Further, the client 120, application server 140, and transaction database 160 may communicate over a network 180.

The client 120 represents one or more software applications configured to present data and translate user inputs into requests for data analyses by the application server 140. In this embodiment, the client 120 connects to the application server 140. However, several clients 120 may execute on the client computer 110 or several clients 120 on several client computers 110 may interact with the application server 140. In one embodiment, the client 120 may be a browser accessing a web service.

Alternatively, the client 120 may run on the same server computing system 130 as the application server 140. In any event, a user would interact with the data analysis system 100 through the client 120.

The application server 140 is configured to include a merchant resolution tool 150 and an analysis engine 155. The merchant resolution tool 150 links matching merchant IDs to a company. The merchant resolution tool 150 reads data from the transaction database 160. The merchant resolution tool 150 may store resolution data on the server computer 130 or on the transaction database 160.

The analysis engine 155 uses the resolution data from the merchant resolution tool 150 to analyze data retrieved from the transaction database 160. The analysis engine 155 aggregates and compares the transaction records from the transaction database 160 to provide insights about a particular company. For instance, a financial institution may design a data analysis to evaluate the seasonal spending trends for a franchise company. However, each franchisee of the franchise company may have a distinct merchant account with the financial institution. The financial institution stores the transaction records from the merchant accounts with distinct merchant IDs that associate a transaction record with a merchant account. To evaluate the full set of transaction records for the franchise company the analysis engine 155 needs to merge each collection of financial transaction records from each franchisee together. Therefore, the analysis engine 155 uses the resolution data from the merchant resolution tool 150 to merge the financial transaction records from each franchisee together into a full set of transaction records for the franchise company in order to evaluate the seasonal spending trends for the franchise company.

In this embodiment, the transaction database 160 stores data records of financial transactions associated with a financial institution. For example, the transaction database may include data records for a large number of merchant accounts processing credit and debit card transaction. In such a case, each record would include data attributes for the amount spent, the transaction date and time, the address of the merchant, and a merchant ID to associate the record with a particular merchant account.

The transaction database 160 may be a Relational Database Management System (RDBMS) that stores the transaction data as rows in relational tables. Alternatively, the transaction database 160 may be stored on the same server computing system 130 as the application server 140. The data records of a financial institution.

Figure 2 illustrates a flow of data from the transaction database 160 through the merchant resolution tool 150, according to one embodiment of the present invention. As shown, the transaction database 160 includes merchant ID sets 210. Each merchant ID set 210 includes transaction records 215 with the same merchant ID, such as credit and debit card transactions processed for a single merchant account at a financial institution. The merchant resolution tool 150 includes an aggregator 240, candidate aggregates 242, exemplar aggregates 244, training data set 260, and an identity resolver 250. The identify resolver 250 itself includes a classifier 255 and a resolve list 270.

In one embodiment, the classifier 255 is a random forest classifier. A random forest classifier is a machine learning algorithm that is generally known to be highly accurate on large databases that include discrete, continuous, and missing data, as may be the case for financial transaction records 215 in the transaction database 160. Random forest classifiers include multiple decision trees. The decision trees evaluate features of input data. In the present context, of financial transaction records that are associated with merchant accounts by a merchant id, the evaluated features may include:

• Word overlap count and frequency of merchant ID attributes • Word-based cosine similarity weighted by perterm inverse document frequency scores of merchant ID attributes • Character-based cosine similarity of merchant ID attributes • Placement of word overlap of merchant ID attributes • Identification of the string .com • If the merchant ID attributes includes a store code • Overlap of prefix or suffix digits in the merchant ID attributes • Whether the provided city is numeric • Matching unique merchant category codes • Fractional difference in average ticket amounts • Standard deviations from the average ticket amounts • Fractional difference in magnitude of the ticket amount variances

Note, the classifier 255 may evaluate a variety of other features, depending on the needs of a particular case and data available from the underlying transaction records. Further one of ordinary skill in the art will recognize that a random forest classifier is used as a reference example of a classifier and that a variety of other machine learning classifiers could be used.

To evaluate the variety of features the classifier 255 grows decision trees based upon the probability that a selected feature should lead to a certain classification. In the present context, the classifier 255 grows several decision trees based upon different combinations of the features, so that each decision tree classifies a pair of merchant ID sets 210 as matching the same company or not. The output of the classifier 255 is the percentage of decision trees that classify a pair of merchant ID sets 210 as matching the same company.

To prepare for linking merchant IDs to a company, the classifier 255 grows the decision trees by training on the training data set 260. The training data set 260 includes pairs of merchant ID sets 210 that match the same company and pairs of merchant ID sets 210 that do not match the same company. The pairs of merchant ID sets 210 that match the same company are classified as positive examples in the training data set 260. The pairs of merchant ID sets 210 that do not match the same company are classified as negative examples in the training data set 260. As the classifier 255 processes the features of each pair of merchant ID sets 210 as a positive or negative example, the classifier 255 becomes more accurate by refining the probabilities used in the decision trees.

The training data set 260 may also include difficult edge cases, such as pairs of merchant ID sets 210 that do not match, but have similar merchant ID strings. A pair of merchant ID sets 210 with similar merchant ID strings that should not be linked to the same company is an edge case, because oftentimes similar merchant ID strings come from merchant ID sets 210 that should be linked to the same company. Adding such edge cases to the training data set 260 causes the classifier 255 to adjust the probabilities in the decision trees of the classifier 255 to better classify pairs of merchant ID sets 210 with similar merchant ID attributes.

To create a large training data set 260, the merchant resolution tool 150 may generate pairs of randomly selected merchant ID sets 210, which typically provide negative training examples.

The training data set 260 may include transaction records 215 retrieved from the transaction database 160, may include synthetic transaction records 215, or may include some combination thereof. While a training data set 260 of 4,000 pairs of merchant ID sets 210 has proven to be effective, the actual size of the training data set 260 may be set as a matter of preference.

Once the classifier 255 is trained, the merchant resolution tool 150 may be used to associate merchant IDs from distinct merchant account to a company, so that the analysis engine 155 may run data analyses on full sets of transaction records 215 from all merchant accounts of the company.

The transaction database 160 is configured to include a mechanism for providing transaction records 215 with a common merchant ID attribute as merchant ID sets 210. For example, the transaction database 160 may store transaction records 215 with equal merchant ID attributes together in merchant ID sets 210 or the transaction database 160 may store transaction records 215 sequentially by the value of a transaction date attribute. Regardless of the arrangement of the transaction records 215, the merchant resolution tool 150 may retrieve merchant ID sets 210 from the transaction database 160.

After a user selects a merchant ID set 210 as an exemplar merchant ID set 210(0), other merchant ID sets 210 may be considered as candidate merchant ID sets 210(1) through 210(M-l). The user selects the exemplar merchant ID set 210(0) as being representative of the characteristics of the company to be resolved. The exemplar merchant ID set may include a large number of transaction records 215. A large number of transaction records 215 may provide aggregates, such as the average transaction size, that are more accurate than merchant ID sets 210 with fewer transaction records 215.

Other factors, such as geographic locations, the merchant ID string, or other business heuristics may also guide the selection of the exemplar merchant ID set 210(0) from the available merchant ID sets 210.

When linking merchant IDs to a company, the merchant resolution tool 150 retrieves the transaction records 215 of the exemplar merchant ID set 210(0) and the transaction records 215 of a candidate merchant ID set 210(1). The aggregator 240 aggregates the attributes of the transaction records 215 of the exemplar merchant ID set 210(0) to produce exemplar aggregates 244. For example, the aggregator 240 calculates the average transaction size, the transaction size standard deviation, or the average amount that an individual has spent. The merchant ID attribute of the exemplar merchant ID set 210(0) is also included with the exemplar aggregates 244. The aggregator 240 also calculates the candidate aggregates 242 from the candidate merchant ID set 210 and includes the merchant ID attribute of the candidate merchant

ID set 210(1) with the candidate aggregates 242. Note that the aggregator 240 may calculate additional aggregate values, according to numerous different designs that the tool developer can choose.

After the aggregator 240 determines the aggregate values, the merchant resolution tool 150 passes the exemplar aggregate 244 and the candidate aggregate 242 to an identity resolver 250. The classifier 255 determines the values used as features in the decision trees from the data included in the exemplar aggregates 244 and the candidate aggregates 242. The classifier 255 processes the exemplar aggregate 244 and the candidate aggregate 242 to produce a confidence score between zero and one equal to how likely the exemplar merchant ID set 210(0) matches the candidate merchant ID set 210(1) and should therefore be linked to the same company. If the exemplar merchant ID set 210(0) and the candidate merchant ID set 201(1) receive a score over some threshold, such as 0.70, then the identity resolver 250 stores the merchant ID of the candidate merchant ID set 201(1) in a resolve list 270.

The merchant resolution tool 150 compares candidate merchant ID sets 210(2) through 210(M-l) with the exemplar merchant ID set 210(0). The identity resolver 250 adds the merchant ID of each candidate merchant ID set 210(1) through 210(M-l) that produces a high confidence score to the resolve list 270. Therefore, the merchant IDs on the resolve list 270 represent the merchant ID sets 210 that belong to the same company as the exemplar merchant ID set 210(0).

The merchant resolution tool 150 stores the resolve list 270 for use by the analysis engine 155. In turn, the analysis engine 155 may analyze the full collection of transaction records 215 of the company independent of the various merchant IDs included in the transaction records 215 of the company. For example, if the various merchant IDs in a resolve list 270 associate transaction records 215 with multiple merchant accounts from multiple franchisees of a franchise company. Then the analysis engine 155 should merge the transaction records 215 with the merchant IDs in the resolve list 270 to analyze the full collection of transaction records 215 of the franchise company.

Figure 3 is a flow diagram of method steps for training the classifier 255, according to one embodiment of the present invention. Although the method steps are described in conjunction with the systems of Figures 1-2 and 5, persons of ordinary skill in the art will understand that any system configuration to perform the method steps, in any order, is within the scope of the invention.

As shown, method 300 beings at step 305, where a merchant resolution tool 150 creates a training data set 260 of positive examples of pairs of merchant ID sets 210 that link to the same company. The merchant resolution tool 150 adds edge cases to the training data set 210. The edge cases include pairs of merchant ID sets 210 that do not match, but have similar merchant ID strings. The edge cases may also include pairs of merchant ID sets 210 that have similar aggregate values, but are from different companies, so are actually negative training examples.

In step 310, the merchant resolution tool 150 adds randomly selected pairs of merchant ID sets 210 to the training data set 260. The randomly selected pairs of merchant ID sets 210 should include a majority of negative training examples.

In step 315, the merchant resolution tool 150 submits each merchant ID sets 210 in the training data set 260 to the aggregator 240 to generate candidate aggregates 242. When training the classifier 255, there is no exemplar merchant ID set 210(0), so all merchant ID sets 210 in the training data set 260 are considered candidates merchant ID sets 210(1) through 210(M-l). A user may review these candidate aggregates 242.

In step 320, the user selects pairs of merchant ID sets 210 that should be linked to the same company as positive training examples.

In step 325, the user selects pairs of merchant ID sets 210 that link to different companies as negative training examples. These negative training examples include several difficult edge cases. Additionally, the training data set 210 includes a majority of random selections, so the majority of the pairs of merchant ID sets 210 in the training data set 260 are negative training examples.

In step 330, the merchant resolution tool 150 trains the classifier 255 with the training data set 260. As described, the classifier 255 is a random forest learning algorithm.

After training the classifier 255 with the training data set 260, the classifier 255 may evaluate a pair of merchant ID sets 210 to produce a confidence score, e.g., a value between zero and one. The confidence score equals the percent of decision trees in the random forest algorithm used by the classifier 255 that determine that both merchant ID sets 210 in the pair should be linked to the same company. Therefore, the classifier 255 is able to produce a confidence score that represents whether a pair of merchant ID sets 210 including an exemplar merchant ID set 210(0) and a candidate merchant ID set 210(1) should be linked to the same company.

Figure 4 is a flow diagram of method steps for linking merchant IDs to a company according to one embodiment of the present invention. Although the method steps are described in conjunction with the systems of Figures 1-2 and 5, persons of ordinary skill in the art will understand that any system configuration to perform the method steps, in any order, is within the scope of the invention.

As shown, method 400 beings at step 410, where the merchant resolution tool 150 receives an exemplar merchant ID as the merchant ID attribute for an exemplar merchant ID set 210(0). As described, a user selects the exemplar merchant ID set 210(0) as being representative of the characteristics of the financial transaction records 215 associated with a company, e.g., the franchisee that best represents a given franchise company. Alternatively, the system may automatically choose an exemplar merchant ID set 210(0) based on user-specified criteria.

In one embodiment, the merchant resolution tool 150 presents an exemplar selection tool to the user. The exemplar selection tool provides assistance in selecting an exemplar merchant ID that is representative of a company to be resolved. The exemplar selection tool may accept a search string from the user to identify merchant IDs that should potentially be linked to the company. The exemplar selection tool may also use some subset of the company name as the search string. Furthermore, the exemplar selection tool may submit the merchant ID sets 210 associated with the identified merchant IDs to the aggregator 240. The aggregator 240 then computes aggregates 242 that assist the user in selecting the exemplar merchant ID.

In step 420, the merchant resolution tool 150 generates exemplar aggregates 244 for the selected exemplar merchant ID set 210(0) . After the merchant resolution tool 150 retrieves the exemplar merchant ID set 210(0) from the transaction database 160, the aggregator 240 calculates the average transaction size, the transaction size standard deviation, and the average amount that an individual has spent.

In step 430, the merchant resolution tool 150 generates candidate aggregates 242 for a candidate merchant ID set 210(1). The merchant resolution tool 150 identifies a merchant ID set 210(1) through 210(M-l) that has not been compared to the exemplar merchant ID set 210(0), as the candidate merchant ID set 210(1). Once identified, the merchant resolution tool 150 retrieves the candidate merchant ID set 210(1) from the transaction database 160, and submits the candidate merchant ID set 210(1) to the aggregator 240.

The aggregator 240 generates the candidate aggregates 242.

The aggregation and comparison of every possible merchant ID record set 210(1) through 210(M-l) may be very time consuming, so reducing the number of comparisons is desirable. In one embodiment, the merchant resolution tool 242 does not compare every merchant ID record set 210. The merchant resolution tool 242 skips merchant ID record sets 210 that do not meet a certain qualification. Assuming a franchise company only has franchisee locations in the state of California and the transaction records 215 include an attribute for the address at which the transaction occurred, then the merchant resolution tool 242 would skip those merchant ID record sets 210 that do not include transaction records 215 from California. In this case, the merchant resolution tool 242 reduces the number of comparisons by skipping those merchant ID sets 210 that are not from California .

In step 440, the merchant resolution tool 150 determines if the exemplar merchant ID set 210(0) and the candidate merchant ID set 210(1) match one another and therefore should be linked to the same company. The identity resolver 250 submits the exemplar aggregates 244 and the candidate aggregates 242 to the classifier 255. As described, the classifier 255 produces a confidence score between zero and one equal to the percent of decision trees in the random forest algorithm used by the classifier 255 that determine that both merchant ID sets 210 in the pair should be linked to the same company. If the classifier 255 produces a confidence score under a threshold, then the method 400 proceeds to step 460. If, however, the confidence score is over the threshold, then method 400 proceeds to step 450. While a threshold confidence score of 0.70 has proven to be effective, the actual threshold may be set as a matter of preference.

In step 450, the identity resolver 250 stores the merchant ID attribute of the candidate merchant ID set 201(1) in a resolve list 270.

In one embodiment, the merchant resolution tool 242 merges the exemplar merchant ID set 240(0) and the candidate merchant ID set 240(1) into a combined merchant ID set, which becomes a new larger exemplar merchant ID set 240(0). Then the merchant resolution tool 242 re-generates the exemplar aggregates 244 for the remaining comparisons. In doing so, the new exemplar merchant ID set 240(0) may better represent the company and improve the resolution of the remaining candidate merchant ID sets 240(2) through 240(M-l).

In step 460, the merchant resolution tool 150 determines if there are more merchant ID sets 210 in the transaction database 160 that have not been compared. If the merchant resolution tool 150 determines there is another candidate merchant ID set 210(2) to compare, then the method 400 returns to step 430. Once no more candidate merchant ID sets 210 remain to compare, the merchant resolution tool 150 links merchant ID sets 210 listed in the resolve list 270 for the company.

In step 470, the merchant resolution tool 150 links the exemplar merchant ID set 210(0) with the candidate merchant ID sets 210(1) through 210(M-l) listed in the resolve list 270. As described, the resolution of the merchant ID sets may involve storing a list of merchant ID attributes that the analysis engine 155 can use to identify the transaction records 215 of the company. Alternatively, the merchant resolution tool 150 may link the transaction records 215 of the merchant ID sets 210 on the resolve list 270 to the company by populating an attribute of the transaction records 215 with the company name, so that the analysis engine 155 can query the transaction database 160 for the transaction records 215 belonging to the company.

Figure 5 illustrates an example server computing system 130 running a merchant resolution tool 150, according to one embodiment. As shown, the server computing system 130 includes, a central processing unit (CPU) 550, a network interface 570, a memory 520, and a storage 530, each connected to an interconnect (bus) 540. The server computing system 130 may also include an I/O device interface 560 connecting I/O devices 580 (e.g., keyboard, display and mouse devices) to the computing system 130. Further, in context of this disclosure, the computing elements shown in server computing system 130 may correspond to a physical computing system (e.g., a system in a data centre) or may be a virtual computing instance executing within a computing cloud.

The CPU 550 retrieves and executes programming instructions stored in memory 520 as well as stores and retrieves application data residing in memory 520. The bus 540 is used to transmit programming instructions and application data between the CPU 550, I/O device interface 560, storage 530, network interface 570, and memory 520. Note that the CPU 550 is included to be representative of a single CPU, multiple CPUs, a single CPU having multiple processing cores, a CPU with an associate memory management unit, and the like. The memory 520 is generally included to be representative of a random access memory. The storage530 may be a disk drive storage device. Although shown as a single unit, the storage 530 may be a combination of fixed and/or removable storage devices, such as fixed disc drives, removable memory cards, or optical storage, network attached storage (NAS), or a storage area-network (SAN).

The communications between the client 120 and the merchant resolution tool 150 are transmitted over the network

180 via the network interface 570.

Illustratively, the memory 520 includes a merchant resolution tool 150, exemplar aggregates 244, candidate aggregates 242, and a resolve list 270. The merchant resolution tool 150 itself includes an aggregator 240 and a classifier 225. The storage 530 includes a training data set 533, which the merchant resolution tool 150 uses to train the classifier 225.

The aggregator 240 generates the exemplar aggregates 244 and the candidate aggregates 242 from transaction records 215 retrieved from the transaction database 160. The merchant resolution tool 150 issues database queries over the network 180 to the transaction database 160 via the network interface 570. Once the aggregator 240 generates the exemplar aggregates 244 and candidate aggregates 242, the merchant resolution tool 150 uses the classifier 225 to determine if the merchant IDs sets 240 should be linked to a company.

Although shown in memory 520, the merchant resolution tool 150, exemplar aggregates 244, candidate aggregates 242, and resolve list 270, may be stored in memory 520, storage 530, or split between memory 520 and storage 530. Likewise, the training data set 533 may be stored in memory 520, storage 530, or split between memory 520 and storage 530.

In some embodiments, the database repository 160 may be located in the storage 530. In such a case, the database queries and subsequent responses are transmitted over the bus 540. As described, the client 120 may also be located on the server computing system 130, in which case the client 120 would also be stored in memory 520 and the user would utilize the I/O devices 580 to interact with the client 120 through the I/O device interface 560.

While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. For example, aspects of the present invention may be implemented in hardware or software or in a combination of hardware and software. One embodiment of the invention may be implemented as a program product for use with a computer system. The program(s) of the program product define functions of the embodiments (including the methods described herein) and can be contained on a variety of computer-readable storage media. Examples of computer-readable storage media include (i) non-writable storage media (e.g., read-only memory devices within a computer, CD-ROM disks readable by a CD-ROM drive, flash memory, ROM chips or any type of solid-state nonvolatile semiconductor memory); and (ii) writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive or any type of solid-state random-access semiconductor memory) on which alterable information is stored.

The invention has been described above with reference to specific embodiments. It will be understood however, that various modifications and changes may be made thereto without departing from the scope of the invention as set forth in the appended claims. The foregoing description and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Therefore, the scope of the present invention is determined by the claims that follow.