Patent Grant
11694276
This is a priority application.
The present disclosure relates generally to computer algorithms for matching records in a data set, specifically using data enrichment and triaging to optimize performance.
There are many situations where a record needs to be found in a different dataset. An address read from an envelope needs to be matched to a postal database to determine the proper routing channels. Or in a network, a MAC address from a network packet needs to be found in a database to determine the physical location of the device that sent the message. In still another situation, a death record needs to be located in the roles of registered voters. In each case, the record may be formatted differently than in the dataset. The data in the record may be slightly different than the data in the dataset. Does the imperfect data match?
These questions also arise in the reconciliation of checks with banking records, or with payments received to open invoices or purchase orders to approved payments. There are numerous situations where the matching of imperfect data is required.
Current approaches to matching imperfect data are slow and inefficient, particularly with large datasets. The performance issue is particularly acute in scenarios where thousands of matches are needed in a day or hour. An improvement is needed. The apparatuses and methods described below articulate an optimized solution to the matching of imperfect data.
This document describes a non-transitory computer readable media programmed to enrich an entered record submitted to be matched with a dataset record stored on a data storage device. The enrichment is done by supplementing data in the entered record with customer data from a dataset. The media is further programmed to search through a plurality of dataset records in the dataset for the entered record. The search is programmed to first determine if the entered record unambiguously matches one of the dataset records or if the entered record unambiguously does not match one of the dataset records. If the entered record does not unambiguously match one of the dataset records, score match characteristics using a Fellegi-Sunter algorithm, save the score as a highest score if the score is above the highest score less a threshold, and save a location of one of the dataset records as a matching record if the score is above a previous highest score. Next, tune a Fellegi-Sunter algorithm parameter with the data from the entered record and data from one of the dataset records; and when the dataset records have been checked, return the matching record.
The dataset record could be a payment record and the media could be further programmed to enrich at least one payment record by supplementing data in at least one payment record with the customer data from the dataset. The dataset record could be an invoice record and the media could be further programmed to enrich at least one invoice record by supplementing data in at least one invoice record with the customer data from the dataset. The entered record could be related to a payment or an invoice. The threshold could be zero. The Fellegi-Sunter algorithm parameter could be a probability m that an amount field in the entered record matches an amount field in the dataset record. The Fellegi-Sunter algorithm parameter could be a probability n that a customer address field in the entered record does not match a customer address field in the dataset record.
A method is also described here. The method is made up of the steps of (1) enriching, with a computer, an entered record submitted to be matched with a dataset record on a data storage device by supplementing data in the entered record with customer data from a dataset, (2) searching through a plurality of dataset records in the dataset for the entered record, wherein the searching first determines if the entered record unambiguously matches one of the dataset records or if the entered record unambiguously does not match one of the dataset records, (3) if the entered record does not unambiguously match one of the dataset records, (3a) scoring match characteristics using a Fellegi-Sunter algorithm, (3b) saving the score as the highest score if the score is above the highest score, less a threshold, and (3c) saving a location of the one of the dataset records as a matching record if the score is above a previous highest score. The method continues by (4) tuning a Fellegi-Sunter algorithm parameter with the data from the entered record and data from one of the dataset records, and (5) when the dataset records have been checked, returning the matching record.
The dataset record could be a payment record and the method could also include (2a) enriching at least one payment record by supplementing data in at least one payment record with the customer data from the dataset. The dataset record could be an invoice record and the method could also include (2a) enriching at least one invoice record by supplementing data in at least one invoice record with the customer data from the dataset. The entered record could be related to a payment or an invoice. The threshold could be zero. The Fellegi-Sunter algorithm parameter could be a probability m that an amount field in the entered record matches an amount field in the dataset record. The Fellegi-Sunter algorithm parameter could be a probability n that a customer address field in the entered record does not match a customer address field in the dataset record.
The annexed drawings, which are not necessarily to scale, show various aspects of the inventions in which similar reference numerals are used to indicate the same or similar parts in the various views.
The present disclosure is now described in detail with reference to the drawings. In the drawings, each element with a reference number is similar to other elements with the same reference number independent of any letter designation following the reference number. In the text, a reference number with a specific letter designation following the reference number refers to the specific element with the number and letter designation and a reference number without a specific letter designation refers to all elements with the same reference number independent of any letter designation following the reference number in the drawings.
The present disclosure provides several embodiments for matching records in a dataset where both the record and the dataset are made up of imperfect data. Many data applications rely on multiple data sources, merging data sets is an essential part of researchers' workflow. Unfortunately, a unique identifier that unambiguously links records is often unavailable, and data may contain missing and inaccurate information. These problems are severe especially when merging large-scale administrative records.
Starting with
In some embodiments, the dataset 101 contains a set of outstanding invoices I, 131a-c representing all of the receivables for a company. The payments P, 132a-c received by the company are also stored in the dataset 101. The customer records C, 133a-b for the company are also stored in the dataset 101, as are the advice records A, 134a-b. Some of these records are linked, perhaps using pointers in memory for example. When an invoice I, 131a-c is entered, it may be linked to a customer account C, 133a-b. Payments P, 132a-c may contain advice information A, 134a-b. With the match described herein, the payment P, 132a-c is linked with an invoice I, 131a-c.
The dataset 101 interfaces with a computing device 102. This interface could be a direct bus connection, a local area network connection, an optical link, a wireless communications interface, or similar. The computing device 102 includes circuitry 112 such as a microprocessor and various interface and power circuitry. The computing device 102 also includes a communications interface 113 for interfacing the computing device 102 to networks such as the internet, local area networks, wireless networks, optical networks. The communications interface 113 could be a component of the interface with the dataset 101. In some embodiments, the computing device 102 also includes a display 114 (such as an LED screen, a CRT monitor, a LED monitor, an LCD or laser projector, etc.) and/or an input device 115 (such as a keyboard, mouse, touchscreen, touchpad, check reader, license plate reader, credit card scanner, driver's license scanner, passport scanner, etc). The computing device 102 also includes or interfaces to computer readable media 116. The computing device includes memory 111 that connects to the circuitry 112, the communications interface 113, and perhaps to the display 114, the computer readable media 116, and the input device 115. The memory 111 could include the computer readable media 116.
The memory 111 contains the entered record 121 (a payment P or an invoice I) that is being searched for to match. It also includes the matched, scored records 122a-c that hold the match score, potential matched records 124a-c, and record (payment P or invoice I) in the dataset 101 for the records that appear to be a match. Further, the memory 111 includes the field weights 123 that are tuned parameters for calculating the score, such as m and u discussed below).
Once the data is enriched, the data is triaged to see if a quick, unambiguous match between payment and invoice can be found 203. This process is outlined in detail in
If the triage result 204 is unambiguous then proceed to processing the feedback 206.
If the triage result 204 is ambiguous, then additional processing is needed to identify the best match 205. The best match 205 algorithm is shown in
The feedback 206 adjusts the parameters used in the best match 205 algorithm. For instance, parameters u and m may be adjusted to tune the Fellegi-Sunter algorithm. Other parameters may be adjusted as well.
Once the feedback 206 algorithm has adjusted the parameters, the matching record could be returned 207 to the calling routine, if a matching record is found. If a match is not found, a null pointer may be returned in some embodiments. In other embodiments, a second parameter is returned indicating whether a match was found. In still other embodiments, a score indicating the confidence of the match is returned.
The enrichment process 202 matches information from advice A and customers C with payments P or with invoices I to form enriched payments P,A,C or enriched invoices I,C,A. This combination is then sent through the find, or triage match 203 to see if a quick match can be made between the enriched payments P,A,C and an enriched invoice I,C,A (or any invoice I). The triage match 203 may also be run to match an enriched invoice I,C,A to a stored payment P (or an enriched payment P,A,C).
There are three possible results of the triage match 202: the match could be unambiguous, with the invoice I (or enhanced invoice I,C,A) clearly matching the enriched payment P,A,C) 301, or there could be an unambiguous mismatch 302, or the match could be ambiguous 303, with a plurality of match candidates.
When there is an unambiguous match 301, then the enriched invoice I,C,A (or the invoice itself I) is linked to the enriched payment P,A,C (or the payment P). The process is complete, the match is made. Once matched, the feedback engine 206 is run to update the parameters used in the scoring and fuzzy matching.
When there is an unambiguous mismatch 302, then no link is made. The process is complete, the match is not made. No invoices I are found that match the payment P (or no payment P is found to match the invoice I). The feedback engine 206 is run to update the parameters used in the scoring and fuzzy matching.
When the match is ambiguous 303, then each of the potential match candidate invoices I,A; I,C,A; I,C are scored 316 against the match with the payment P,A,C. Then the automatic match process 318 determines which match scored the highest, and the match between the invoice I and the payment P, and the link between the invoice I and the payment P is established. The feedback engine 206 is run to update the parameters used in the scoring and fuzzy matching.
If there is additional missing information in the entered record 121, then the advice information A is looked up in the customer records 133a-b in the dataset 101. Any missing information from the advice record 134a-b is copied into (enriched) 403 the entered record 121. Any other missing information is filled in if it is easily accessible. The advice record 134a-b could be found with a search or a lookup.
The enrichment process 202 then continues looking at every invoice in the dataset 404. Each invoice 131a-c is analyzed to see if it is missing customer information C. If so, then the invoice 131a-c in the dataset 101 is enriched 405 by filling in missing data from customer data 133a-b. In some embodiments, this enrichment is done by linking the invoice 131a-c with the customer record 133a-b. Each invoice 131a-c is also analyzed to see if it is missing other information. If so, then the invoice 131a-c in the dataset 101 is enriched 406 by filling in missing data from advice data 134a-b. In some embodiments, this enrichment is done by linking the invoice 131a-c with the advice record 134a-b.
See Table 1 for an example of the parameters for an enrichment. The Property is the field of the invoice record 131a-c, the identifier is the type of field, the disqualify is used by the triage match 203 to determine if the match of the field needs to be absolute or if it is optional. The unique check says whether the field is unique. And the ambiguous field determines if the match is unambiguous if the field matches.
In some embodiments, the payment records 132a-c are also enriched similarly.
Once all of the invoices 132a-c have been enriched, the process ends and returns to the calling routine 411.
In some embodiments, the enrichment 202 process continuously watches (as a background process) for new advice A and customers C and tries to link new information with payments P or invoices I in the system. Once a link is established between the new advice A or the new customer C, the properties in the invoices I or payments P are associated with the new advice A or new customer C populated automatically.
For each invoice 131a-c in the dataset 101, the incoming record 121 is checked against the next invoice 131a-c. This triage match 504 is a simple comparison of the data in the two records. If it matches completely (in some embodiments, the match is not complete, but requires a match of certain fields, or alternatively, a match of a certain number of fields), then there is a complete match 511. If none of the information matches (in some embodiments, the mismatch is not complete, but requires a mismatch of certain fields, or alternatively, a mismatch of a certain number of fields), then there is no match 521. If some of the information matches, then there is a possible match 505. In some embodiments, the possible match 505 is determined if there is neither a match 511 nor a not a match 521, then a possible match 505 is determined for all other cases.
If there is no match 521, the loop checks the next 503 invoice in the dataset 101.
If there is a possible match 505, then the invoice 13 la-c from the dataset 101 is added 506 to the list of possible matches 124a-c. The MatchFlag is set to ambiguous. And then the invoice 131a-c in the list is checked 503.
If there is a match 511, then the MatchFlag is set to unambiguous 512, as we found the matching invoice I, and the invoice 132a-c is copied to the head of the linked list of potentially matched records 124a. This copying is done to clear the list of matches and replace it with the one matched record 124a. The loop checking all records in the list is terminated, and the routine returns 513 the Match Flag and the list of potential matching records 124a.
Once the entire list of invoices 131a-c is checked 503, the MatchFlag and the list of potential matching records 124a-c are returned 513.
Looking to
The best match process 205 may start by clearing the matching record list 602, initializing this list, and setting the BestScore value to 0. Next, the list of potential matches 124a-c are processed one record by one 603, first scoring the match between the potential match record with the entered record 121. In some embodiments, the entered record 121 is a payment P, and the potential match list 124a-c is a list of invoices I. In another embodiment, the entered record 121 is an invoice I, and the potential match list 124a-c is a list of payments P.
In one embodiment, the match is scored with the Fellegi-Sunter algorithm 604. The score is compared with the BestScore 605, and if the score is better than the BestScore, then the BestScore is assigned the value of the score 606. And the matching record from 124a-c is saved in the matched scored record list 122a-c. The score is within a threshold of the BestScore, then the matching record from 124a-c is saved in the matched scored record list 122a-c but the BestScore is not changed. Then the next record in the potential match list 124a-c is checked. Once all of the records in the potential match list 124a-c have been checked, the matched scored record list 122a-c is returned to the calling routine 611. In some embodiments, only the best scoring record is returned, and no threshold analysis is performed.
The best match process is called when there is a possible match 303, 505. Some of the fields may match but others may be missing or misspelled. The match is scored 216 to see how close the record 131a, 131b, 131c in the dataset 101 matches incoming record 121.
The Fellegi-Sunter algorithm compares the similarity of two records. This comparison is done on a field by field basis (aka level by level), calculating the probability that the field matches and a probability that the field does not match. The probabilities are then summed to determine a match score.
Fellegi and Sunter algorithm considers the binary comparison vector
For an observed comparison vector γ, the space of all comparison vectors, m(γ) is defined to be the conditional probability of observing γ□ given that the record pair is a true match: in formula m(γ)=P((a, b) ∈M). Similarly, u(γ)=P((a, b) ∈U) denotes the conditional probability of observing γ□given that the record pair is a true non-match.
There are two kinds of possible misclassification errors: false matches and false non-matches. The probability of false matches is:
μ=P(M*|M)=Σu(γ)P(M*|γ)
and the probability of a false non-match is:
λ=P(U*|M)=Σm(γ)P(U*|γ)
The Fellegi-Sunter scoring uses the Bayes theorem to calculate a probability that the records match. For instance, the probability that we have found a true match, given that we observed this particular level (e.g. probability of true match given that emails matched exactly), is calculated. Observed patterns can be used to generate a probability of if a new record comparison is a true match or not.
For the purpose of initializing the scoring algorithm, we define the types of matches for a level (Entity name in this example):
These different fields are referred to as levels. A user can use as many levels as they want and can define. The algorithm discovers which rules (levels) are most important for distinguishing between possible matches and non-matches. Rule (level) importance is quantified by the m/u ratio, where a higher m/u ratio means that rule is more important for determining if a comparison is a true match.
The Bayes theorem is:
Where γ indicates the value of the comparison, the index k designates the comparison column, and l designates the observed comparison level. P(TrueMatch Level) is the estimated prior probability that any comparison between a pair of records is a match. For instance, it is the probability that the cell at the column and level is a true match.
At the core of this estimation are the m and u probabilities (m and u are part of the field weights 123). Here, m is the fraction of true matches for a given level and u is the fraction of non-matches for a given level. For instance, the m probability for level 2 (where emails exactly match) is the fraction of true matches having identical emails in both the invoice and payment tables.
If the level is a high similarity comparison (e.g. Emails match exactly), we expect a high m probability, because we would expect true matches to almost always have the same email (except for typos or missing entries). The u probability represents the chance that a non-match has a high similarity level in that column. (e.g. two different people share the same email by pure chance). We would expect First Name to have a higher u probability than Social Security Number, since there is more chance of two people sharing the same first name than social security number.
In reality, we don't have any knowledge of which records are true matches when we start the matching process. This means we don't know m or u and can't make any predictions. So, we begin with an educated guess (e.g. m=0.9, u=0.2 for a level) and use the expectation maximization algorithm (based on the feedback 206) to converge on values of m and u which best fit the patterns in the data. It is also possible to use domain knowledge to set initial values of m and u.
The expectation maximization algorithm begins by estimating m, u (or manually choose these) for each column and level. Next, it computes the probability that each record comparison is a match/non-match (using Bayes Theorem). Then, the expectation maximization algorithm uses these probabilities to assign all the comparisons to predicted match/non-match. Next, the algorithm uses these predicted matches to calculate a new m, u. Finally, the algorithm iterates until m and u converge. As a result, we have a model which knows how each level of comparison influences the probability of a record being a match or a non-match.
It should be appreciated that many of the elements discussed in this specification may be implemented in a hardware circuit(s), a circuitry executing software code or instructions which are encoded within computer readable media accessible to the circuitry, or a combination of a hardware circuit(s) and a circuitry or control block of an integrated circuit executing machine readable code encoded within a computer readable media. As such, the term circuit, module, server, application, or other equivalent description of an element as used throughout this specification is, unless otherwise indicated, intended to encompass a hardware circuit (whether discrete elements or an integrated circuit block), a circuitry or control block executing code encoded in a computer readable media, or a combination of a hardware circuit(s) and a circuitry and/or control block executing such code.
All ranges and ratio limits disclosed in the specification and claims may be combined in any manner. Unless specifically stated otherwise, references to “a,” “an,” and/or “the” may include one or more than one, and that reference to an item in the singular may also include the item in the plural.
Although the inventions have been shown and described with respect to a certain embodiment or embodiments, equivalent alterations and modifications will occur to others skilled in the art upon the reading and understanding of this specification and the annexed drawings. In particular regard to the various functions performed by the above described elements (components, assemblies, devices, compositions, etc.), the terms (including a reference to a “means”) used to describe such elements are intended to correspond, unless otherwise indicated, to any element which performs the specified function of the described element (i.e., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary embodiment or embodiments of the inventions. In addition, while a particular feature of the inventions may have been described above with respect to only one or more of several illustrated embodiments, such feature may be combined with one or more other features of the other embodiments, as may be desired and advantageous for any given or particular application.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4575793 | Morel et al. | Mar 1986 | A |
| 5228122 | Cahn et al. | Jul 1993 | A |
| 5559961 | Blonder | Sep 1996 | A |
| 5600735 | Seybold | Feb 1997 | A |
| 5600835 | Garland et al. | Feb 1997 | A |
| 5634008 | Gaffaney et al. | May 1997 | A |
| 5644717 | Clark | Jul 1997 | A |
| 5790798 | Beckett et al. | Aug 1998 | A |
| 5845369 | Dunchock | Dec 1998 | A |
| 5912669 | Hsia | Jun 1999 | A |
| 5961592 | Hsia | Oct 1999 | A |
| 5970482 | Pham et al. | Oct 1999 | A |
| 6044401 | Harvey | Mar 2000 | A |
| 6192411 | Chan et al. | Feb 2001 | B1 |
| 6195452 | Royer | Feb 2001 | B1 |
| 6205416 | Butts et al. | Mar 2001 | B1 |
| 6256737 | Bianco et al. | Jul 2001 | B1 |
| 6523016 | Michalski | Feb 2003 | B1 |
| 6651099 | Dietz et al. | Nov 2003 | B1 |
| 6675164 | Kamath et al. | Jan 2004 | B2 |
| 6687693 | Cereghini et al. | Feb 2004 | B2 |
| 6708163 | Kargupta et al. | Mar 2004 | B1 |
| 6801190 | Robinson et al. | Oct 2004 | B1 |
| 6845369 | Rodenburg | Jan 2005 | B1 |
| 6968335 | Bayliss | Nov 2005 | B2 |
| 7044365 | Witherspoon | May 2006 | B2 |
| 7092941 | Campos | Aug 2006 | B1 |
| 7174462 | Pering et al. | Feb 2007 | B2 |
| 7308436 | Bala et al. | Dec 2007 | B2 |
| 7415509 | Kaltenmark et al. | Aug 2008 | B1 |
| 7584128 | Mason et al. | Sep 2009 | B2 |
| 7702631 | Basu | Apr 2010 | B1 |
| 7716129 | Tan et al. | May 2010 | B1 |
| 7726561 | Katyal et al. | Jun 2010 | B2 |
| 7729959 | Wells et al. | Jun 2010 | B1 |
| 7730521 | Thesayi et al. | Jun 2010 | B1 |
| 7822598 | Carus et al. | Oct 2010 | B2 |
| 7831703 | Krelbaum et al. | Nov 2010 | B2 |
| 7860783 | Yang et al. | Dec 2010 | B2 |
| 7970669 | Santos | Jun 2011 | B1 |
| 7992202 | Won et al. | Aug 2011 | B2 |
| 8229875 | Roychowdhury | Jul 2012 | B2 |
| 8229876 | Roychowdhury | Jul 2012 | B2 |
| 8392975 | Raghunath | Mar 2013 | B1 |
| 8401867 | Lagadec et al. | Mar 2013 | B2 |
| 8429745 | Casaburi et al. | Apr 2013 | B1 |
| 8433791 | Krelbaum et al. | Apr 2013 | B2 |
| 8484168 | Bayliss | Jul 2013 | B2 |
| 8515862 | Zhang et al. | Aug 2013 | B2 |
| 8538124 | Harpel et al. | Sep 2013 | B1 |
| 8638939 | Casey et al. | Jan 2014 | B1 |
| 8650624 | Griffin et al. | Feb 2014 | B2 |
| 8776213 | McLaughlin et al. | Jul 2014 | B2 |
| 8844059 | Manmohan | Sep 2014 | B1 |
| 8881005 | Al et al. | Nov 2014 | B2 |
| 9015036 | Karov et al. | Apr 2015 | B2 |
| 9189505 | Bayliss | Nov 2015 | B2 |
| 9449346 | Hockey et al. | Sep 2016 | B1 |
| 9489627 | Bala | Nov 2016 | B2 |
| 9529678 | Krelbaum et al. | Dec 2016 | B2 |
| 9537848 | McLaughlin et al. | Jan 2017 | B2 |
| 9595023 | Hockey et al. | Mar 2017 | B1 |
| 9607103 | Anderson | Mar 2017 | B2 |
| 9667609 | McLaughlin et al. | May 2017 | B2 |
| 9691085 | Scheidelman | Jun 2017 | B2 |
| 9798984 | Paleja et al. | Oct 2017 | B2 |
| 9811650 | Todeschini | Nov 2017 | B2 |
| 10037533 | Caldera | Jul 2018 | B2 |
| 10152680 | Myrick et al. | Dec 2018 | B1 |
| 10235356 | Amend et al. | Mar 2019 | B2 |
| 10242258 | Guo et al. | Mar 2019 | B2 |
| 10319029 | Hockey et al. | Jun 2019 | B1 |
| 10320800 | Guo et al. | Jun 2019 | B2 |
| 10402817 | Benkreira et al. | Sep 2019 | B1 |
| 10414197 | Jesurum | Sep 2019 | B2 |
| 10440015 | Pham et al. | Oct 2019 | B1 |
| 10467631 | Dhurandhar et al. | Nov 2019 | B2 |
| 10510083 | Vukich et al. | Dec 2019 | B1 |
| 10511605 | Ramberg et al. | Dec 2019 | B2 |
| 10523681 | Bulgakov et al. | Dec 2019 | B1 |
| 10540491 | Martinez et al. | Jan 2020 | B1 |
| 10552837 | Jia et al. | Feb 2020 | B2 |
| 10552841 | Dixit | Feb 2020 | B1 |
| 10586220 | Adams et al. | Mar 2020 | B2 |
| 10607008 | Byrne et al. | Mar 2020 | B2 |
| 10607228 | Gai et al. | Mar 2020 | B1 |
| 10607230 | Adams et al. | Mar 2020 | B2 |
| 10621587 | Binns et al. | Apr 2020 | B2 |
| 10699075 | Amend et al. | Jun 2020 | B2 |
| 10824809 | Kutsch et al. | Nov 2020 | B2 |
| 10909511 | Chanyontpatanakul | Feb 2021 | B2 |
| 10929851 | Kang et al. | Feb 2021 | B2 |
| 11042555 | Kane et al. | Jun 2021 | B1 |
| 20020019945 | Houston et al. | Feb 2002 | A1 |
| 20020056043 | Glass | May 2002 | A1 |
| 20020065938 | Jungck et al. | May 2002 | A1 |
| 20020080123 | Kennedy et al. | Jun 2002 | A1 |
| 20020099649 | Lee et al. | Jul 2002 | A1 |
| 20020163934 | Moore et al. | Nov 2002 | A1 |
| 20030041042 | Cohen et al. | Feb 2003 | A1 |
| 20030083764 | Hong | May 2003 | A1 |
| 20030110394 | Sharp et al. | Jun 2003 | A1 |
| 20030135612 | Huntington et al. | Jul 2003 | A1 |
| 20030233305 | Solomon | Dec 2003 | A1 |
| 20040034666 | Chen | Feb 2004 | A1 |
| 20040186882 | Ting | Sep 2004 | A1 |
| 20040193512 | Gobin et al. | Sep 2004 | A1 |
| 20050021650 | Gusler et al. | Jan 2005 | A1 |
| 20050081158 | Hwang | Apr 2005 | A1 |
| 20050154692 | Jacobsen et al. | Jul 2005 | A1 |
| 20050177483 | Napier | Aug 2005 | A1 |
| 20060101048 | Mazzagatti et al. | May 2006 | A1 |
| 20060155751 | Geshwind et al. | Jul 2006 | A1 |
| 20060190310 | Gudla et al. | Aug 2006 | A1 |
| 20060212270 | Shiu et al. | Sep 2006 | A1 |
| 20070100749 | Bachu et al. | May 2007 | A1 |
| 20070277224 | Osborn et al. | Nov 2007 | A1 |
| 20080104007 | Bala | May 2008 | A1 |
| 20090059793 | Greenberg | Mar 2009 | A1 |
| 20090094677 | Pietraszek et al. | Apr 2009 | A1 |
| 20090140838 | Newman et al. | Jun 2009 | A1 |
| 20090174667 | Kocienda et al. | Jul 2009 | A1 |
| 20090201257 | Saitoh et al. | Aug 2009 | A1 |
| 20090202153 | Cortopassi et al. | Aug 2009 | A1 |
| 20090282039 | Diamond | Nov 2009 | A1 |
| 20090307176 | Jeong et al. | Dec 2009 | A1 |
| 20090313693 | Rogers | Dec 2009 | A1 |
| 20100066540 | Theobald et al. | Mar 2010 | A1 |
| 20100130181 | Won | May 2010 | A1 |
| 20100169958 | Werner et al. | Jul 2010 | A1 |
| 20100185615 | Monga | Jul 2010 | A1 |
| 20100225443 | Bayram et al. | Sep 2010 | A1 |
| 20110055907 | Narasimhan et al. | Mar 2011 | A1 |
| 20110070864 | Karam et al. | Mar 2011 | A1 |
| 20110082911 | Agnoni et al. | Apr 2011 | A1 |
| 20110145587 | Park | Jun 2011 | A1 |
| 20110251951 | Kolkowitz et al. | Oct 2011 | A1 |
| 20110298753 | Chuang et al. | Dec 2011 | A1 |
| 20120041683 | Vaske et al. | Feb 2012 | A1 |
| 20120124662 | Baca et al. | May 2012 | A1 |
| 20120127102 | Uenohara et al. | May 2012 | A1 |
| 20120151553 | Burgess et al. | Jun 2012 | A1 |
| 20130071816 | Singh et al. | Mar 2013 | A1 |
| 20130117246 | Cabaniols et al. | May 2013 | A1 |
| 20130231974 | Harris et al. | Sep 2013 | A1 |
| 20130254115 | Pasa et al. | Sep 2013 | A1 |
| 20130339141 | Stibel et al. | Dec 2013 | A1 |
| 20140006347 | Qureshi et al. | Jan 2014 | A1 |
| 20140067656 | Cohen et al. | Mar 2014 | A1 |
| 20140149130 | Getchius | May 2014 | A1 |
| 20140366159 | Cohen | Dec 2014 | A1 |
| 20150039473 | Hu et al. | Feb 2015 | A1 |
| 20150220509 | Karov Zangvil et al. | Aug 2015 | A1 |
| 20150254308 | Scott | Sep 2015 | A1 |
| 20150264573 | Giordano et al. | Sep 2015 | A1 |
| 20150348041 | Campbell et al. | Dec 2015 | A1 |
| 20160041984 | Kaneda et al. | Feb 2016 | A1 |
| 20160352759 | Zhai | Dec 2016 | A1 |
| 20170039219 | Acharya et al. | Feb 2017 | A1 |
| 20170068954 | Hockey et al. | Mar 2017 | A1 |
| 20170070500 | Hockey et al. | Mar 2017 | A1 |
| 20170154382 | McLaughlin et al. | Jun 2017 | A1 |
| 20170163664 | Nagalla et al. | Jun 2017 | A1 |
| 20170177743 | Bhattacharjee et al. | Jun 2017 | A1 |
| 20170300911 | Alnajem | Oct 2017 | A1 |
| 20180107944 | Lin et al. | Apr 2018 | A1 |
| 20180349924 | Shah et al. | Dec 2018 | A1 |
| 20180357434 | Roy | Dec 2018 | A1 |
| 20190014101 | Hockey et al. | Jan 2019 | A1 |
| 20190182233 | Hockey et al. | Jun 2019 | A1 |
| 20190197189 | Studnicka | Jun 2019 | A1 |
| 20190228411 | Hernandez-Ellsworth et al. | Jul 2019 | A1 |
| 20190318122 | Hockey et al. | Oct 2019 | A1 |
| 20190347281 | Natterer | Nov 2019 | A1 |
| 20190349371 | Smith et al. | Nov 2019 | A1 |
| 20190373001 | Deeb et al. | Dec 2019 | A1 |
| 20200019964 | Miller et al. | Jan 2020 | A1 |
| 20200117800 | Ramberg et al. | Apr 2020 | A1 |
| 20200279275 | Kelly et al. | Sep 2020 | A1 |
| 20210049326 | Amend et al. | Feb 2021 | A1 |
| 20210110447 | Ransom et al. | Apr 2021 | A1 |
| Number | Date | Country |
|---|---|---|
| 1211865 | Jun 2002 | EP |
| 1706960 | Oct 2006 | EP |
| 2653982 | Oct 2013 | EP |
| 2636149 | Oct 2016 | EP |
| 176551 | Sep 2012 | IL |
| 219405 | Mar 2007 | IN |
| 10-0723738 | May 2007 | KR |
| 201723907 | Jul 2017 | TW |
| 0125914 | Apr 2001 | WO |
| 0287124 | Oct 2002 | WO |
| 2002100039 | Dec 2002 | WO |
| 0373724 | Sep 2003 | WO |
| 2005067209 | Jul 2005 | WO |
| 2012061701 | May 2012 | WO |
| 2014145395 | Sep 2014 | WO |
| 2015175824 | Nov 2015 | WO |
| 2017096206 | Jun 2017 | WO |
| 2017209799 | Dec 2017 | WO |
| 2018022157 | Feb 2018 | WO |
| Entry |
|---|
| Appaloosa Store, “String Similarity Algorithms Compared”, Apr. 5, 2018, webpage downloaded on Oct. 20, 2020 from https://medium.com/@appaloosastore/string-similarity-algorithms-compared-3f7b4d12f0ff. |
| Banon, Shay, “Geo Location and Search”, elastic blog post, Aug. 16, 2010, webpage found at https://www.elastic.co/blog/geo-location-and-search on Oct. 15, 2019. |
| Bansal, Nikhil, Avrim Blum, and Shuchi Chawla. “Correlation clustering.” Machine Learning 56.1-3 (2004): 89-113. |
| Bottomline Technologies (de), Inc, “′4 Steps to Bringing a Positive ROI to Accounts Payable”, 2019, a white paper downloaded from https://go.bottomline.com/rs/498-XVR-738/images/4-Steps-Bringing-Positive-ROI-AP-IOFM-FDX-US-WTP-1802-088.pdf on Sep. 30, 2019. |
| Bottomline Technologies, Bottomline Cyber Fraud & Risk Management:Secure Payments, marketing brochure. |
| Brasetvik, Alex, “Elasticsearch from the Bottom up, Part 1”, Elastic, Sep. 16, 2013. Webpage found at https://www.elastic.co/blog/found-elasticsearch-from-the-bottom-up on Jun. 17, 2019. |
| Co-pending U.S. Appl. No. 13/135,507, filed Jul. 7, 2011. |
| Dalit Amitai, Shahar Cohen, Yulia Mayer, and Avital Seraty, “Fraud Detection Rule Optimization”, U.S. Appl. No. 16/985,773, filed Aug. 5, 2020. |
| EMV Payment Tokenisation Specification, Technical Framework, EMVCo, LLC, Version 2.1, Jun. 2019. |
| EMV Payment Tokenisation, a Guide to Use Cases, EMVCo, LLC, Version 1.0, Jun. 2019. |
| Ephesoft, “KV Extraction Normalization”, webpage downloaded from https://ephesoft.com/docs/2019-1/moduleplugin-configuration/extraction-module/key-value-extraction-4040/key-value-extraction-plugin/kv-extraction-normalization/on Oct. 1, 2019. |
| Experian, “Fuzzy address searching”, webpage downloaded from https://www.edq.com/glossary/fuzzy-address-searching/ on Oct. 8, 2019. |
| Fenz, Dustin, et al, “Efficient Similarity Search in Very Large String Sets”, conference paper, Jun. 2012. |
| Finley, Thomas, and Thorsten Joachims. “Supervised clustering with support vector machines.” Proceedings of the 22nd international conference on Machine learning, ACM, 2005. |
| G. Kou, Y. Peng, Y. Shi, M. Wise, W. Xu, Discovering credit cardholders behavior by multiple criteria linear programming, Annals of Operations Research 135, (2005) 261-274. |
| Haydn Shaughnessy, Solving the $190 billion Annual Fraud Problem: More on Jumio, Forbes, Mar. 24, 2011. |
| Holl, Xavier and Andrew Chisholm, “Extracting structured data from invoices”, Proceedings of Australasian Language Technology Association Workshop, 2018, pp. 53-59. |
| IdentityMing, Accelerated Fintech Compliance and Powerful Online Fraud Prevention Tools, website found at https://identitymindglobal.com/momentum/ on Dec. 12, 2018. |
| International Search Report and Written Opinion received for PCT Patent Application No. PCT/IL05/000027, dated Jun. 2, 2005, 8 pages. |
| International Search Report and Written Opinion received for PCT Patent Application No. PCT/US17/13148, dated May 19, 2017, 11 pages. |
| Jeremy Olshan, How my bank tracked me to catch a thief, MarketWatch, Apr. 18, 2015. |
| Krawetz, N., “Looks Like It”, 2011. Downloaded from from:http://www.hackerfactor.com/blog/index.php?/archives/432-Looks-Like-It.html on May 27, 2020. |
| Lada, Dr. Maria, “Combined Search and Examination Report”, UK Intellectual Property Office, May 18, 2020. |
| Meia et al., Comparing clusterings—an information based distance, Journal of Multivariate Analysis 98 (2007) 873-895. |
| Mitchell, Stuart, et al, “pulp Documentation”, Release 1.4.6, Jan. 27, 2010. |
| Oracle(Registered) Warehouse Builder Data Modeling, ETL, and Data Quality Guide, Chapter 23, 11g Release 2 (11.2), Part No. E10935-04, Aug. 2011, web page downloaded from https://docs.oracle.com/cd/E24693_01/owb.11203/e10935/match_merge.htm on Apr. 16, 2020. |
| Postel et al.; “Telnet Protocol Specification” RFC 854; entered into the case on Apr. 18, 2013. |
| RodOn, “location extraction with fuzzy matching capabilities”, Blog post on StackOverflow.com, Jul. 8, 2014, webpage downloaded from https://stackoverflow.com/questions/24622693/location-extraction-with-fuzzy-matching-capabilities on Oct. 8, 2019. |
| Rosette Text Analytics, “An Overview of Fuzzy Name Matching Techniques”, Blog, Dec. 12, 2017, webpage downloaded from https://www.rosette.com/blog/overview-fuzzy-name-matching-techniques/ on Oct. 15, 2019. |
| Samaneh Sorournejad, Zahra Zojaji, Reza Ebrahimi Atani, Amir Hassan Monadjemi, “A Survey of Credit Card Fraud Detection Techniques: Data and Technique Oriented Perspective”, 2016. |
| Schulz, Klaus and Stoyan Mihov, “Fast String Correction with Levenshtein-Automata”, IJDAR (2002) 5: 67. https://doi.org/10.1007/s10032-002-0082-8. |
| Segers, Jens, “Perceptual image hashes”, Dec. 13, 2014, webpage downloaded from https://jenssegers.com/perceptual-image-hashes on Sep. 27, 2019. |
| Sypht, “Unlock the value of your information”, webpage downloaded from https://www.sypht.com/index.html on Sep. 27, 2019. |
| The Telnet Protocol Microsoft Knowledgebase; entered into the case on Apr. 18, 2013. |
| Vogler, Raffael, “Comparison of String Distance Algorithms”, Aug. 21, 2013, webpage downloaded on Oct. 20, 2020 from https://www.joyofdala.de/blog/comparison-of-string-distance-algorithms. |
| Wikil Kwak, Yong Shi, John J. Cheh, and Heeseok Lee, “Multiple Criteria Linear Programming Data Mining Approach: An Application for Bankruptcy Prediction”, : Data Mining and Knowledge Management, Chinese Academy of Sciences Symposium, 2004, LNAI 3327, pp. 164-173, 2004. |
| Wikipedia, “Autoencoder”, web page downloaded from http://en.wikipedia.org/wiki/Autoencoder on Dec. 18, 2020. |
| Wikipedia, “Damerau-Levenshtein distance”, webpage downloaded on Oct. 20, 2020 from https://en.wikipedia.org/wiki/Damerau-Levenshtein_distance. |
| Wikipedia, “Reverse image search”, Sep. 12, 2019. Downloaded from: https://en.wikipedia.org/w/index.php?title=Reverse_image_search&oldid=915372427 on May 27, 2020. |
| Written Opinion of the International Searching authority for corresponding International Application No. PCT/US2016/064689 dated Feb. 22, 2017. |
| “Splink: Probabilistic record linkage and deduplication at scale”, Python Software Foundation, webpage downloaded from https://pypi.org/project/splink/ on Jun. 1, 2021. |
| “Save time on monthly reconciliations with QuickBooks.”, Intuit Quickbooks, webpage downloaded from https://quickbooks.intuit.com/accounting/bank-reconciliation/ on Jun. 1, 2021. |
| Sadinle, Mauricio, et al, “Approaches to Multiple Record Linkage”, ISI 2011 invited paper, 2011. |
| Winkler, William, et al, “An Application of the Fellegi-Sunter Model of Record Linkage to the 1990 U.S. Decennial Census”, US Census working paper No. RR91-09, 1991. |
| “Record Linkage”, Wikipedia, webpage downloaded on Jun. 3, 2021 from https://en.wikipedia.org/wiki/Record_linkage. |
| Fellegi, Ivan and Alan Sunter, “A Theory for Record Linkage”, Journal of the American Statistical Association, Dec. 1969, vol. 64, No. 328, pp. 1183-1210. |
| Enamorado, Ted, et al, “Using a Probabilistic Model to Assist Merging of Large-Scale Administrative Records”, American Political Science Review, 2019, vol. 113, No. 2, pp. 353-371. |
| Tiziana Tuoto, “Method: Fellegi-Sunter and Jaro Approach to Record Linkage”, a section in Memobust Handbook on Methodology of Modern Business Statistics, Mar. 26, 2014. |
