DETAILED ACTION
This Office Action is in response to the request for continued examination and associated fee payment filed on March 16th, 2026 and amendments filed on February 5th, 2026 for Application No. 17/455, 629, in which claims 1-5, 7-13, 15-20, and 23-25 are presented for examination.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/05/2026 has been entered.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, 7, 9-13, 15, 17-20, 23, and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Faruquie et al. (hereinafter Faruquie) (Patent Pub. No. US 2021/0224258 A1) in view of Gundersen et al. (hereinafter Gundersen) (Patent No. US 10,007,739 B1) and Elmagarmid et al. (hereinafter Elmagarmid) (“Duplicate Record Detection: A Survey”).
Regarding Claim 1, Faruquie teaches a computer-implemented method for entity resolution (Abstr., “In order to facilitate entity resolution, systems and methods include”),
the method comprising: using a number of processors to perform the steps of (Para. [0006], “computer-based method that includes at least the following steps of receiving, by at least one processor”):
receiving, into a dual layer resolution system . . . data batches for [entities] . . . at different locations comprising a number of different entity identifiers (Abstr., “In order to facilitate entity resolution, systems and methods include”; Para. [0006], “receiving . . . a plurality of first records associated with one or more entities . . . include[ing] respective first entity data representing identifying information . . . [and] a plurality of second records associated with the one or more entities . . . include[ing] respective second entity data representing identifying information”, where the “plurality of records” are data batches; Fig. 3-4, where the records “318” and “319” are grouped and feed through a dual layer resolution system, see Fig. 3, where a first layer is depicted, comprising the “Rules Engine 336” and “Minhash[es] . . . 334”; Fig. 4, where a second layer is depicted, comprising the “Feature Generator 440” and the “Entity Engine 450”; and where different businesses will inherently be at different locations, sometimes as similar as different offices within the same building, and the records also include businesses with multiple different locations, see Para. [0136], “since businesses may have multiple addresses, the maximum of all addresses pairs is taken as an address similarity feature”)
comprising . . . of: entity names and entity addresses (Para. [0044], “entity records identifying entities, such as, e.g., commercial entities . . . the data items may include, e.g., information related to an entity name or secondary name, address”);
distributing the . . . data batches . . . between different types of processors in the number of processors (Para. [0019], “Examples of hardware elements may include processors, microprocessors . . . digital signal processors (DSP) . . . In some embodiments, the one or more processors may be implemented as a Complex Instruction Set Computer (CISC) or Reduced Instruction Set Computer (RISC) processors; x86 instruction set compatible processors, multi-core, or any other microprocessor or central processing unit (CPU). In various implementations, the one or more processors may be dual-core processor(s), dual-core mobile processor(s), and so forth”, where these different types of processors receive the data batches distributed to them, see Para. [0005], “receiving, by at least one processor, a first entity record set . . . Receiving, by the at least one processor, a second entity record set”):
grouping . . . data batch entity identifiers into a number of entity pairs . . . with the number of different entity identifiers . . . grouping between the number of different entity identifiers . . . and expanding the number of entity pairs (Fig. 3; Para. [0080], “the blocking engine 330 may include a pairing engine 333 that . . . creates a pair for every combination of a first source record paired with a second source record”, where “creat[ing] a pair for every combination” requires pairing different entity identifiers in a manner that expands the number of entity pairs);
feeding the number of entity pairs directly into a first layer comprising a match generator filter (Para. [0080], “the pair engine 333 operates as a buffer that . . . provides each pair to a rules engine 336 in time with the rules engine 336 processing a given pair”; Fig. 3, where, as discussed above, the “Rules Engine 336” and “Minhash[es] . . . 334” are within the broadest reasonable interpretation of a layer, which is the first layer entity pairs are passed to; and where the “Rules Engine 336” and “Minhash[es] . . . 334” are also within the broadest reasonable interpretation of a match generator filter, which receives the pairs directly from the “Pairing Engine 333”, as indicated by the arrow);
determining, respectively for each entity pair of the number of entity pairs, a similarity score by applying each of: . . . [multiple iterations of] a MinHash algorithm, to each entity pair of the number of entity pairs (Para. [0073] – [0074], “Minhash may be employed to determine likely matches . . . Minhash of each entity, e.g., a name of each entity, in each of the first record table 218 and the second record table 219 is determined . . . the blocking engine 230 may determine a Minhash for each entity multiple times, e.g., three times, five times, ten times, or other suitable number of times, to reduce the risk of false negatives. In some embodiments, each entity in the first record table 218 and the second record table 219 may be Minhashed using a common random key for each Minhash iteration. Once the entire set of entities is Minhashed for a given Minhash iteration, the hash values are compared to identify matches . . . Minhash matches may be filtered using, e.g., a Jaccard similarity between each pair of entities having a matching Minhash . . . Minhash matches may be filtered using, e.g., a Jaccard similarity between each pair of entities having a matching Minhash”, where a similarity score is determined, the value used to assess whether “each pair of entities hav[e] a matching Minhash” to be sufficiently similar to warrant evaluation of “a Jaccard similarity” based on the “compar[ison]” of “hash values . . . to identify matches”, respectively for each entity pair of the number of entity pairs, “of each entity, in each of the first record table 218 and the second record table . . . the hash values are compared to identify matches between each pair of entities”, by applying multiple iterations of a MinHash algorithm, “Minhash for each entity multiple times, e.g., three times, five times, ten times, or other suitable number of times . . . ”, to each entity pair of the number of entity pairs, “for a given Minhash iteration the hash values are compared to identify matches between each pair of entities”),
deriving from the similarity scores a number of potentially matching entity pairs (Para. [0073] - [0074], “Once the entire set of entities is Minhashed for a given Minhash iteration, the hash values are compared to identify matches . . . Minhash matches may be filtered using, e.g., a Jaccard similarity . . . where the Jaccard similarity for a pair of entities is below a similarity threshold, the pair may be removed from the blocked set of entity pairs”, where the similarity scores are used for “identifying matches” and the filtered to remove “false positives”, which derives the potentially matching entity pairs as the remaining pairs, see Para. [0074], “Thus, false positives can be removed from the blocked set of entity pairs having matching Minhashes in a Minhash iteration by removing the pairs from the set that have a low similarity according to the Jaccard similarity”);
feeding potentially matching entity pairs into a second layer (Fig. 3-4, where the “Blocking Engine 330” produces “Candidate Pair[s] 332[/432]” that are fed through the “Feature Generator 440” and, in the form of “Candidate Pair Features 434”, the “Entity Engine 450”, which, as discussed above comprise the second layer; Para. [0079], “the blocking engine 330 may form candidate pairs of similar records where each pair includes a first source record and a second source record”, where the “candidate pairs” are “similar” enough to be potential matches);
comprising a machine learning model (Para. [0057]-[0058], “a feature generator 140 receives blocked candidate pairs . . . the feature generator 140 generate or extract features representative of characteristics of each record”; Para. [0101], “an entity engine 450, such as the entity engine 150 described above, may receive the candidate pair features 434 . . . the entity engine 450 employs an entity matching machine learning model”)
determining (Fig. 1; Para. [0062], “the entity engine 150 utilizes a machine learning model to compare the first data entity feature vectors with each candidate matching second data entity feature to generate a probability of a match”)
a confidence score for each potentially matching entity pair (Fig. 1; Para. [0061], “the entity engine 150 may determine a score indicative of a probability of matches from the set of candidate matches”); and
generating, by the machine learning model, matched entities (Fig. 1; Para. [0062], “the entity engine 150 utilizes, e.g., a classifier . . . the classifier may include, e.g., random forest . . . [and] the classifier may be configured to classify a match where the probability of a match exceeds a probability”, where “match[ing]” is generating)
comprising a subset of the potentially matching entity pairs comprising confidence scores above a specified threshold (Fig. 1; Para. [0064], “the entity merge engine 160 may select candidate matches from the set of candidate matches based on a threshold probability score”).
Faruquie does not explicitly disclose . . . at varying times, new . . . for supply chains . . . varying formats . . . new . . . for supply chains . . . target entities comprising previous . . . only . . . of the new data batches for supply chains . . . of the new data batches for supply chains . . . (where the first and second source records are not specifically described as new or previous records or as comprising supply chain data)
a Token Diff algorithm, a Needleman-Wunsch algorithm, a Smith-Waterman algorithm . . . (where the use of a Token Diff, Needleman-Wunsch, or Smith-Waterman algorithms are not specifically described; but see Para. [0073] – [0074], “the blocking engine 230 may determine a Minhash for each entity multiple times, e.g., three times, five times, ten times, or other suitable number of times, to reduce the risk of false negatives . . . Minhash matches may be filtered using, e.g., a Jaccard similarity between each pair of entities having a matching Minhash”, where the concurrent use of multiple different similarity algorithms and the benefits of repeated use of similarity algorithms to “reduce the risk of false negatives” are specifically discussed).
However, Gundersen teaches . . . [receiving] at varying times, new [data batches] (Fig. 2; Col. 2, Ln. 55-57, “Update database 110 may include, for example, new addresses, new or split ZIP Codes, or reformulated addresses in effect at a given point in time”; see also Col. 1, Ln. 5-7, “The application relates generally to database maintenance and, more particularly, to reconciling address records between related databases”; Col. 3, Ln. 50-63, “Address records in the “add” group initially includes new addresses in update database 110 to be added to production database 120 and address records previously deleted from production database 120 that need to be reinstated. Reinstated address records within the “add” group may be identified by a comparison with a historical database using methods known to those skilled in the art. Address records in the “delete” group include addresses marked “delete” in update database 110 and, accordingly, should be deleted from production database 120. The “update” group may include address records from update database 110 in which one or more address elements have changed and, accordingly, should be updated in production database 120”, where “maintenance” in combination with actions to “add”, “delete”, or “update” the database based on changing information indicates the data batches are received at varying times)
for supply chains (Abstr., “Methods for reconciling an address database include”; Col. 1, Ln. 66-67, “the terms address, address record and address data are used interchangeably to correspond to a delivery location”, where “delivery location” demonstrates the addresses are for supply chains) . . .
[comprising] varying formats [identifiers] (Fig. 2, compare “123 MAIN ST APT 5 302” with “123 Main ST #5 304”)
. . . new (Fig. 2; Col. 2, Ln. 55-57, “Update database 110 may include, for example, new addresses, new or split ZIP Codes, or reformulated addresses in effect at a given point in time”) . . .
for supply chains (Abstr., “Methods for reconciling an address database include”; Col. 1, Ln. 66-67, “the terms address, address record and address data are used interchangeably to correspond to a delivery location”, where “delivery location” demonstrates the addresses are for supply chains) . . .
[grouping] target entities comprising previous [data baches into pairs] . . . only [with entities] . . . of the new data batches for supply chains (Abstr., “Methods for reconciling an address database include comparing addresses in an update database to addresses in a production database”, where, in the first comparison, only the update database entries are paired with the production database entries; Col. 3, Ln. 6-7, “Production database 120 may be any information product that includes addresses to be updated”, where “to be updated” demonstrates previous incorporation; see also Fig. 3-5; Col. 5, Ln. 35-42, “In step 375, box addresses in update database 110 are compared to production database 120 with a match scheme 480 shown in FIG. 5. As shown in FIG. 5, match scheme 480 compares a plurality of address elements 420 for a given address in update database 110 to the corresponding address elements in production database 120. Any box addresses that do not find a match in step 375 may be further processed in step 240 described below, where entities from the “production database” are not paired together) . . .
[grouping between different entity identifiers] of the new data batches for supply chains . . . (Col. 5, Ln. 50-55, “As illustrated, step 310 includes an intradupe check 430 that generally identifies addresses in update database 110 that match each other . . . if two or more addresses in update database 110 match each other according to match scheme”, where, as discussed above, the “update database” comprises the new data batches and conducting “an intradupe check” to “identif[y]” “addresses in update database 110 that match each other” “according to a match scheme” is within the broadest reasonable interpretation of grouping different entity identifiers).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine receiving of data batches comprising different name and addresses identifiers for entities at different locations and grouping the identifiers into pairs of Faruquie with the receiving new data batches for supply chains, of varying formats and at varying times, and the grouping of target entities only with entities of the new data batches, while also grouping different entities of the new data batches together of Gundersen in order to perform maintenance on supply chain databases, which requires updating the production database with new entries of varying formats and at varying times (Gundersen, Col. 1, Ln. 11-13, “it may be necessary to correct or update information in a first database by reference to a related but separate database”; see also Gundersen, Fig. 2, where varying formats are used to describe the same delivery location at different times) and ensuring the update database does not, itself, have duplicate entries, which can simplify the difficult and time consuming process of database reconciliation (Gundersen, Col. 1, Ln. 16-19, “Maintaining (i.e., reconciling) a database, such as by identifying matching records between the first database and the second database, can be a difficult and time consuming process, particularly for large databases”, where the “difficult and time consuming process” can be reduced, particularly in instances where the target database is much larger than the update database, if “addresses in update database 110 that match each other” are first reconciled before “identifying matching records between the first database and the second database”, see Gunderson, Col. 5, Ln. 50-56, “As illustrated, step 310 includes an intradupe check 430 that generally identifies addresses in update database 110 that match each other. According to an embodiment of intradupe check 430, if two or more addresses in update database 110 match each other according to match scheme 410, the matching addresses in update database”; see also Gunderson, Col. 5, Ln. 54-59, “if two or more addresses in update database 110 match each other according to match scheme 410, the matching addresses . . . will be passed on to step 340 or identified for manual processing”, where grouping new database entries allows for incorporation of manual checks into the database reconciliation process, which may reduce difficulty by allowing for the utilization of human judgment in anomalous circumstances).
Additionally, Elmagarmid teaches [entity matching using] (Pg. 1, Abstract, “We cover similarity metrics that are commonly used to detect similar field entries, and we present an extensive set of duplicate detection algorithms that can detect approximately duplicate records in a database”)
. . . a Token Diff algorithm (Pg. 4, Col. 1-2, Para. 4-4, Subsec. “Token-Based Similarity”, where the category of “Token-Based Similarity” is within the broadest reasonable definition of Token Diff and “Atomic Strings”, “WHIRL”, and “Q-Grams with tf.idf” are discussed as specific algorithm examples),
a Needleman-Wunsch algorithm (Pg. 3, Col. 1-2, Para. 6-1, “The edit distance between two strings σ1 and σ2 is the minimum number of edit operations of single characters needed to transform the string σ1 into σ2 . . . Needleman and Wunsch [31] modified the original edit distance model and allowed for different costs for different edit distance operations”), [and]
a Smith-Waterman algorithm (Pg. 3. Col. 2, Para. 3, Subsec. “3.1.3 Smith-Waterman Distance”, “Smith and Waterman [34] described an extension of edit distance and affine gap distance in which mismatches at the beginning and the end of strings have lower costs than mismatches in the middle. This metric allows for better local alignment of the strings (i.e., substring matching). Therefore, the strings “Prof. John R. Smith, University of Calgary” and “John R. Smith, Prof.” can match within a short distance using the Smith-Waterman distance since the prefixes and suffixes are ignored”) . . . .
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the application of each of multiple iterations of a MinHash algorithm to each entity pair of a number of entity pairs in order to determine a similarity score for each entity pair, wherein multiple different similarity algorithms are also used concurrently, of Faruquie in view of Gundersen with the use of a Token Diff algorithm, a Needleman-Wunsch algorithm, and a Smith-Waterman algorithm for entity matching of Elmagarmid in order to utilize supplementary similarity algorithms to increase the effectiveness of the similarity scores by reducing the risk of false negatives (Faruquie, Para. [0073], “the blocking engine 230 may determine a Minhash for each entity multiple times, e.g., three times, five times, ten times, or other suitable number of times, to reduce the risk of false negatives”, where the “reduc[tion of] the risk of false negatives” is limited by the applicability of the “Minhash” to the text of the pairs, with Elmagarmid, Pg. 4, Col. 1, Para. 4, “Character-based similarity metrics work well for typographical errors. However, it is often the case that typographical conventions lead to rearrangement of words (e.g., “John Smith” versus “Smith, John”). In such cases, character-level metrics fail to capture the similarity of the entities. Token-based metrics try to compensate for this problem”, where combination of a “Token-based” similarity algorithm with “Character-based similarity”, such as Needleman-Wunsch or Smith-Waterman would help identify “typographical conventions”-related entity matches; Elmagarmid, Pg. 3. Col. 2, Para. 3, Subsec. “3.1.3 Smith-Waterman Distance”, This metric allows for better local alignment of the strings (i.e., substring matching). Therefore, the strings “Prof. John R. Smith, University of Calgary” and “John R. Smith, Prof.” can match within a short distance using the Smith-Waterman distance since the prefixes and suffixes are ignored”; Elmagarmid, Pg. 3, Col. 2, Para. 1, “Needleman and Wunsch [31] modified the original edit distance model and allowed for different costs for different edit distance operations”, where use of both “Needleman and Wunsch” and “Smith-Waterman” would allow for entity matching where “prefixes and suffixes” are common, as well as instances where unimportant characters appear in the middle of identifiers; thus use of each of Token Diff, Needleman-Wunsch, Smith-Waterman, and MinHash would reduce false negatives to a greater extent than repeated use of MinHash), where a practice of using concurrent similarity algorithms is already taught by the primary reference (Faruquie, Para. [0073] – [0074], “Minhash may be employed to determine likely matches . . . In some embodiments, Minhash matches may be filtered using, e.g., a Jaccard similarity”).
Regarding Claim 2, Faruquie in view of Gundersen and Elmagarmid teach the method of claim 1, wherein: the target entities are in a storage unit networked with the number of processors (Gundersen, Abstr., “Methods for reconciling an address database include comparing addresses in an update database to addresses in a production database”; Gundersen, Fig. 2, Ref. 301-304, where entities are identified by their addresses, Gundersen, Fig. 2; Gundersen, Col. 3, ln. 6-17, “Production database 120 may be any information product that includes addresses to be updated”, where “addresses to be updated” are the target entities, as discussed in regard to the rejection of Claim 1, and “production database 120” is a storage unit networked with a number of processors in an “exemplary environment for implement[ation]”, see Gundersen, Col. 10, Ln. 11-14, “FIG. 9 is an exemplary environment 710 for implementing an embodiment of the present invention. Environment 710 includes a computer 712 that, in turn, includes a processing unit 714”, where “production database” operates in a “networked environment”, see Gundersen, Col. 10, Ln. 63, “Computer 712 can operate in a networked environment”, where, in view of Gundersen, the “computer-based method . . . include[ing] . . . at least one processor” is within that “networked environment”, see Faruquie Para. [0006], “computer-based method that includes at least the following steps of receiving, by at least one processor”);
and the different entity identifiers further comprise at least one of: different legal entity designations for a same company, different abbreviations of the same company name (Faruquie, Table 1, Para. [0121] and Faruquie, Para. [0044], “entity records identifying entities, such as, e.g., commercial entities . . . the data items may include, e.g., information related to an entity name or secondary name, address”, where each entity identifier comprises a name and address, which comprises different legal entity designations for the same company and different abbreviations for the same company, compare “First Company INC” in row 1 of table 1 with “First Company” in row 2, where the absence of “INC” is a different legal designation for the same company because “INC” is a legal designation for an incorporated entity, and “INC” is an abbreviation for incorporated and its absence abbreviates a company name, thus the entity identifies comprise different abbreviations for the same company name).
The reasons of obviousness have been noted in the rejection of Claim 1 and remain applicable here.
Regarding Claim 3, Faruquie in view of Gundersen and Elmagarmid teach the method of claim 2, wherein the potentially matching entity pairs comprise a similarity score above a specified similarity threshold (Faruquie, Para. [0073] - [0074], “Once the entire set of entities is Minhashed for a given Minhash iteration, the hash values are compared to identify matches . . . Minhash matches may be filtered using, e.g., a Jaccard similarity . . . where the Jaccard similarity for a pair of entities is below a similarity threshold, the pair may be removed from the blocked set of entity pairs”, where, as discussed above, the similarity scores are used for “identifying matches” and then filtered to remove “false positives”, using a similarity score above a certain threshold, sufficient “hash values . . . to identify [a] match” and “Jaccard similarity for a pair of entities is [not] below a similarity threshold”, which derives the potentially matching entity pairs as the remaining pairs, see Faruquie, Para. [0074], “Thus, false positives can be removed from the blocked set of entity pairs having matching Minhashes in a Minhash iteration by removing the pairs from the set that have a low similarity according to the Jaccard similarity”).
Regarding Claim 4, Faruquie in view of Gundersen and Elmagarmid teach the method of claim 1, wherein each entity identifier comprises a name and address of a company (Faruquie, Para. [0044], “entity records identifying entities, such as, e.g., commercial entities . . . the data items may include, e.g., information related to an entity name or secondary name, address”).
Regarding Claim 5, Faruquie in view of Gundersen and Elmagarmid teach the method of claim 4, wherein the number of different entity identifiers differ from each other according to at least one of, respectively, a name or an address within each entity identifier of the number of different entity identifiers (Faruquie, Para. [0044], “entity records identifying entities, such as, e.g., commercial entities . . . the data items may include, e.g., information related to an entity name or secondary name, address”, where each entity identifier comprises a name and address, which may be the only components of the identifier, see Faruquie, Para. [0036], “As used herein, the terms “and” and “or” may be used interchangeably to refer to a set of items in both the conjunctive and disjunctive in order to encompass the full description of combinations and alternatives of the items”; and, as a result, the number of different entity identifiers differ from each other according to at least one of, respectively, a name or an address within each entity identifier of the entity identifiers because duplicate information is removed during processing, see Faruquie, Fig. 4; Para. [0070], “In some embodiments, the cleansed data may be provided to a deduplication engine 228 to remove any duplicate information”),
wherein the entity identifiers comprise: legal entity designations, different language representations of a company name, different naming conventions, or abbreviations (Faruquie, Table 1, Para. [0121] and Faruquie, Para. [0044], “entity records identifying entities, such as, e.g., commercial entities . . . the data items may include, e.g., information related to an entity name or secondary name, address”, where each entity identifier comprises a name and address, which comprises legal entity designations, different naming conventions, and abbreviations, compare “First Company INC” in row 1 of table 1 with “First Company” in row 2, where the absence of “INC” is a different naming convention, “INC” is a legal designation for an incorporated entity, and “INC” is an abbreviation for incorporated; additionally, while unnecessary given the optional “or” language, the absence of “INC” could be considered a different language representation of a company name).
Regarding Claim 7, Faruquie in view of Gundersen and Elmagarmid teach the method of claim 1, wherein the machine learning model comprises a random forest model (Faruquie, Fig. 1; Faruquie, Para. [0062], “the entity engine 150 utilizes a machine learning model . . . may include, e.g., random forest”).
Regarding Claim 9, Faruquie in view of Gundersen and Elmagarmid teach a system for entity resolution (Faruquie, Abstr., “to facilitate entity resolution, systems and methods include”),
wherein the system comprises: a storage device configured to store program instructions; and one or more processors operably connected to the storage device and configured to execute the program instructions to cause the system to: (Faruquie, Para. [0007], “computer-based system that includes at least the following components of an entity database configured to store entity records, and at least one processor configured to perform instructions stored in a non-transitory storage medium”)
receive . . . from different locations (Faruquie, Para. [0068], “a data ingestion engine 222 of the pre-processor 220 receives the first source records 208 and the second source records 209, each including, e.g., entity information. In some embodiments, the data ingestion engine 222 receives the raw data from a database, such as, e.g., a local database, a remote database, a cloud storage, or other data store”, where the system receives “records” from different data locations, such as “a local database”, “a remote database”, or “a cloud storage”, see generally Faruquie, Fig. 6, where multiple “network servers” and “client devices” are connected to the network, facilitating record transfer from multiple locations of the same type, such as “cloud storage”) . . . .
The remaining limitations are substantially the same as the limitations of Claim 1, therefore it is rejected under the same rationale.
Regarding Claim 10, Faruquie in view of Gundersen and Elmagarmid teach the system of claim 9, wherein the previous data batch entity identifiers are in a storage unit networked with the number of processors (Gundersen, Abstr., “Methods for reconciling an address database include comparing addresses in an update database to addresses in a production database”; Gundersen, Fig. 2, Ref. 301-304, where entities are identified by their addresses, Gundersen, Fig. 2; Gundersen, Col. 3, ln. 6-17, “Production database 120 may be any information product that includes addresses to be updated”, where the previous data batch entity identifiers for the target entities comprise and associated with the “addresses to be updated” , see Faruquie, Para. [0044], “entity records identifying entities, such as, e.g., commercial entities . . . the data items may include, e.g., information related to an entity name or secondary name, address”, for the target entities to be identified for “update[ing]”, as discussed in regard to the rejection of Claim 1, and “production database 120” is a storage unit networked with a number of processors in an “exemplary environment for implement[ation]”, see Gundersen, Col. 10, Ln. 11-14, “FIG. 9 is an exemplary environment 710 for implementing an embodiment of the present invention. Environment 710 includes a computer 712 that, in turn, includes a processing unit 714”, where “production database” operates in a “networked environment”, see Gundersen, Col. 10, Ln. 63, “Computer 712 can operate in a networked environment”, where, in view of Gundersen, the “computer-based method . . . include[ing] . . . at least one processor” is within that “networked environment”, see Faruquie Para. [0006], “computer-based method that includes at least the following steps of receiving, by at least one processor”).
The reasons of obviousness have been noted in the rejection of Claim 1 and remain applicable here.
Regarding Claim 11, Faruquie in view of Gundersen and Elmagarmid teach the system of claim 10, wherein each of the potential matches comprise a similarity score above a specified threshold (Faruquie, Para. [0073] - [0074], “Once the entire set of entities is Minhashed for a given Minhash iteration, the hash values are compared to identify matches . . . Minhash matches may be filtered using, e.g., a Jaccard similarity . . . where the Jaccard similarity for a pair of entities is below a similarity threshold, the pair may be removed from the blocked set of entity pairs”, where, as discussed above, the similarity scores are used for “identifying matches” and then filtered to remove “false positives”, using a similarity score above a certain threshold, sufficient “hash values . . . to identify [a] match” and “Jaccard similarity for a pair of entities is [not] below a similarity threshold”, which derives the potentially matching entity pairs as the remaining pairs, see Faruquie, Para. [0074], “Thus, false positives can be removed from the blocked set of entity pairs having matching Minhashes in a Minhash iteration by removing the pairs from the set that have a low similarity according to the Jaccard similarity”).
Regarding Claim 12, the additional elements of the dependent claim are substantially the same as the limitations of Claim 4, therefore it is rejected under the same rationale.
Regarding Claim 13, Faruquie in view of Gundersen and Elmagarmid teach the system of claim 12, wherein the entity identifiers differ from each other according to at least one of, respectively, a name or an address within each entity identifier of the number of different entity identifiers (Faruquie, Para. [0044], “entity records identifying entities, such as, e.g., commercial entities . . . the data items may include, e.g., information related to an entity name or secondary name, address”, where each entity identifier comprises a name and address, which may be the only components of the identifier, see Faruquie, Para. [0036], “As used herein, the terms “and” and “or” may be used interchangeably to refer to a set of items in both the conjunctive and disjunctive in order to encompass the full description of combinations and alternatives of the items”; and, as a result, the number of different entity identifiers differ from each other according to at least one of, respectively, a name or an address within each entity identifier of the entity identifiers because duplicate information is removed during processing, see Faruquie, Fig. 4; Para. [0070], “In some embodiments, the cleansed data may be provided to a deduplication engine 228 to remove any duplicate information”).
Regarding Claim 15, the additional elements of the dependent claim are substantially the same as the limitations of Claim 7, therefore it is rejected under the same rationale.
Regarding Claim 17, Faruquie in view of Gundersen and Elmagarmid teach a computer program product for entity resolution, wherein the computer program product comprises a computer-readable storage medium that comprises program instructions embodied thereon and configured to perform the steps of: (Faruquie, Para. [0017], “The material disclosed herein may be implemented in software or firmware or a combination of them or as instructions stored on a machine-readable medium”).
The remaining limitations are substantially the same as the limitations of Claim 1, therefore it is rejected under the same rationale.
Regarding Claim 18, Faruquie in view of Gundersen and Elmagarmid teach the computer program product of claim 17, wherein the target entities are in a storage unit networked with the number of processors (Gundersen, Abstr., “Methods for reconciling an address database include comparing addresses in an update database to addresses in a production database”; Gundersen, Fig. 2, Ref. 301-304, where entities are identified by their addresses, Gundersen, Fig. 2; Gundersen, Col. 3, ln. 6-17, “Production database 120 may be any information product that includes addresses to be updated”, where “addresses to be updated” are the target entities, as discussed in regard to the rejection of Claim 1, and “production database 120” is a storage unit networked with a number of processors in an “exemplary environment for implement[ation]”, see Gundersen, Col. 10, Ln. 11-14, “FIG. 9 is an exemplary environment 710 for implementing an embodiment of the present invention. Environment 710 includes a computer 712 that, in turn, includes a processing unit 714”, where “production database” operates in a “networked environment”, see Gundersen, Col. 10, Ln. 63, “Computer 712 can operate in a networked environment”, where, in view of Gundersen, the “computer-based method . . . include[ing] . . . at least one processor” is within that “networked environment”, see Faruquie Para. [0006], “computer-based method that includes at least the following steps of receiving, by at least one processor”).
The reasons of obviousness have been noted in the rejection of Claim 1 and remain applicable here.
Regarding Claim 19, the additional elements of the dependent claim are substantially the same as the limitations of Claim 3, therefore it is rejected under the same rationale.
Regarding Claim 20, the additional elements of the dependent claim are substantially the same as the limitations of Claim 4, therefore it is rejected under the same rationale.
Regarding Claim 23, the additional elements of the dependent claim are substantially the same as the limitations of Claim 7, therefore it is rejected under the same rationale.
Regarding Claim 25, Faruquie in view of Gundersen and Elmagarmid teach a computer-implemented method for entity resolution (Faruquie, Abstr., “In order to facilitate entity resolution, systems and methods include”),
the method comprising using a number of processors performing the steps of (Faruquie, Para. [0006], “computer-based method that includes at least the following steps of receiving, by at least one processor”):
receiving, into a dual layer resolution system (Faruquie, Abstr., “In order to facilitate entity resolution, systems and methods include”; Faruquie, Para. [0006], “receiving . . . a plurality of first records . . . [and] a plurality of second records”; Faruquie, Fig. 3-4, where the records “318” and “319” are grouped and feed through a dual layer resolution system, see Faruquie, Fig. 3, where a first layer is depicted, comprising the “Rules Engine 336” and “Minhash[es] . . . 334”; Faruquie, Fig. 4, where a second layer is depicted, comprising the “Feature Generator 440” and the “Entity Engine 450”)
at varying times (where, in view of Gundersen, the receiving occurs at varying times, Gundersen, Fig. 2; Col. 2, Ln. 55-57, “Update database 110 may include, for example, new addresses, new or split ZIP Codes, or reformulated addresses in effect at a given point in time”; see also Gundersen, Col. 1, Ln. 5-7, “The application relates generally to database maintenance and, more particularly, to reconciling address records between related databases”; Gundersen, Col. 3, Ln. 50-63, “Address records in the “add” group initially includes new addresses in update database 110 to be added to production database 120 and address records previously deleted from production database 120 that need to be reinstated. Reinstated address records within the “add” group may be identified by a comparison with a historical database using methods known to those skilled in the art. Address records in the “delete” group include addresses marked “delete” in update database 110 and, accordingly, should be deleted from production database 120. The “update” group may include address records from update database 110 in which one or more address elements have changed and, accordingly, should be updated in production database 120”, where “maintenance” in combination with actions to “add”, “delete”, or “update” the database based on changing information indicates the data batches are received at varying times)
from different locations (Faruquie, Para. [0068], “a data ingestion engine 222 of the pre-processor 220 receives the first source records 208 and the second source records 209, each including, e.g., entity information. In some embodiments, the data ingestion engine 222 receives the raw data from a database, such as, e.g., a local database, a remote database, a cloud storage, or other data store”, where the system receives “records” from different data locations, such as “a local database”, “a remote database”, or “a cloud storage”, see generally Faruquie, Fig. 6, where multiple “network servers” and “client devices” are connected to the network, facilitating record transfer from multiple locations of the same type, such as “cloud storage”),
new data batches comprising a number of different entity identifiers comprising varying formats of: names and addresses of companies in shipping records (Faruquie, Para. [0006], “receiving . . . a plurality of first records associated with one or more entities . . . include[ing] respective first entity data representing identifying information . . . [and] a plurality of second records associated with the one or more entities . . . include[ing] respective second entity data representing identifying information”, where the “plurality of records” are data batches; Faruquie, Para. [0044], “entity records identifying entities, such as, e.g., commercial entities . . . the data items may include, e.g., information related to an entity name or secondary name, address”, where “commercial entities” includes companies and, in view of Gundersen, the number of different entity identifiers are new data, Gundersen, Fig. 2; Col. 2, Ln. 55-57, “Update database 110 may include, for example, new addresses, new or split ZIP Codes, or reformulated addresses in effect at a given point in time”; of varying formats, Gundersen, Fig. 2, compare “123 MAIN ST APT 5 302” with “123 Main ST #5 304”; and are shipping records, Gundersen, Abstr., “Methods for reconciling an address database include”; Gundersen, Col. 1, Ln. 66-67, “the terms address, address record and address data are used interchangeably to correspond to a delivery location”, where “delivery location” demonstrates the addresses are for supply chains);
distributing the new data batches for supply chains between different types of processors in the number of processors (Faruquie, Para. [0019], “Examples of hardware elements may include processors, microprocessors . . . digital signal processors (DSP) . . . In some embodiments, the one or more processors may be implemented as a Complex Instruction Set Computer (CISC) or Reduced Instruction Set Computer (RISC) processors; x86 instruction set compatible processors, multi-core, or any other microprocessor or central processing unit (CPU). In various implementations, the one or more processors may be dual-core processor(s), dual-core mobile processor(s), and so forth”, where these different types of processors receive the data batches distributed to them, see Faruquie, Para. [0005], “receiving, by at least one processor, a first entity record set . . . Receiving, by the at least one processor, a second entity record set”; where, in view of Gundersen the data batches are new data batches for supply chains, see above):
grouping target entities comprising previous data batch entity identifiers into a number of entity pairs only with the number of different entity identifiers of the new data batches for supply chains (Faruquie, Para. [0080], “the blocking engine 330 may include a pairing engine 333 that . . . creates a pair for every combination of a first source record paired with a second source record”, where, in view of Gundersen, the data batches are for supply chains, see above, and, in the grouping, only the new entities are paired with the target entities, which are previous batches, see Gundersen, Abstr., “Methods for reconciling an address database include comparing addresses in an update database to addresses in a production database”, where, in the first comparison, only the update database entries are paired with the production database entries; Gundersen, Col. 3, Ln. 6-7, “Production database 120 may be any information product that includes addresses to be updated”, where “to be updated” demonstrates previous incorporation; see also Gunderson, Fig. 3-5; Gundersen, Col. 5, Ln. 35-42, “In step 375, box addresses in update database 110 are compared to production database 120 with a match scheme 480 shown in FIG. 5. As shown in FIG. 5, match scheme 480 compares a plurality of address elements 420 for a given address in update database 110 to the corresponding address elements in production database 120. Any box addresses that do not find a match in step 375 may be further processed in step 240 described below, where entities from the “production database” are not paired together);
grouping between the number of different entity identifiers of the new data batches for supply chains and expanding the number of entity pairs (Gunderson, Col. 5, Ln. 50-55, “As illustrated, step 310 includes an intradupe check 430 that generally identifies addresses in update database 110 that match each other . . . if two or more addresses in update database 110 match each other according to match scheme”, where, as discussed above, the “update database” comprises the new data batches and conducting “an intradupe check” to “identif[y]” “addresses in update database 110 that match each other” “according to a match scheme” is within the broadest reasonable interpretation of grouping different entity identifiers);
generating, by inputting the entity pairs directly into a match generator filter in a first layer (Faruquie, Para. [0080], “the pair engine 333 operates as a buffer that . . . provides each pair to a rules engine 336 in time with the rules engine 336 processing a given pair”; Faruquie, Fig. 3, where, as discussed above, the “Rules Engine 336” and “Minhash[es] . . . 334” are within the broadest reasonable interpretation of a layer, which is the first layer entity pairs are passed to; and where the “Rules Engine 336” and “Minhash[es] . . . 334” are also within the broadest reasonable interpretation of a match generator filter, which receives the pairs directly from the “Pairing Engine 333”, as indicated by the arrow, in order to perform the below discussed generating),
a similarity score for each of the entity pairs, by applying each of: a Token Diff algorithm, a Needleman-Wunsch algorithm, a Smith-Waterman algorithm, and a MinHash algorithm, to each of the entity pairs (Faruquie, Para. [0073] – [0074], “Minhash may be employed to determine likely matches . . . Minhash of each entity, e.g., a name of each entity, in each of the first record table 218 and the second record table 219 is determined . . . the blocking engine 230 may determine a Minhash for each entity multiple times, e.g., three times, five times, ten times, or other suitable number of times, to reduce the risk of false negatives. In some embodiments, each entity in the first record table 218 and the second record table 219 may be Minhashed using a common random key for each Minhash iteration. Once the entire set of entities is Minhashed for a given Minhash iteration, the hash values are compared to identify matches . . . Minhash matches may be filtered using, e.g., a Jaccard similarity between each pair of entities having a matching Minhash . . . Minhash matches may be filtered using, e.g., a Jaccard similarity between each pair of entities having a matching Minhash”, where a similarity score is determined, the value used to assess whether “each pair of entities hav[e] a matching Minhash” to be sufficiently similar to warrant evaluation of “a Jaccard similarity” based on the “compar[ison]” of “hash values . . . to identify matches”, respectively for each entity pair of the number of entity pairs, “of each entity, in each of the first record table 218 and the second record table . . . the hash values are compared to identify matches between each pair of entities”, by applying multiple iterations of a MinHash algorithm, “Minhash for each entity multiple times, e.g., three times, five times, ten times, or other suitable number of times . . . ”, to each entity pair of the number of entity pairs, “for a given Minhash iteration the hash values are compared to identify matches between each pair of entities”, where, in view of Elmagarmid, subsequent iterations of a MinHash algorithm are instances of Token Difference, Elmagarmid, Pg. 4, Col. 1-2, Para. 4-4, Subsec. “Token-Based Similarity”, where the category of “Token-Based Similarity” is within the broadest reasonable definition of Token Diff and “Atomic Strings”, “WHIRL”, and “Q-Grams with tf.idf” are discussed as specific algorithm examples; Needleman-Wunsch, Elmagarmid, Pg. 3, Col. 2, Para. 1, “Needleman and Wunsch [31] modified the original edit distance model and allowed for different costs for different edit distance operations”; and Smith-Waterman, see Elmagarmid, Pg. 3. Col. 2, Para. 3, Subsec. “3.1.3 Smith-Waterman Distance”, “Smith and Waterman [34] described an extension of edit distance and affine gap distance in which mismatches at the beginning and the end of strings have lower costs than mismatches in the middle. This metric allows for better local alignment of the strings (i.e., substring matching)”);
deriving, from the similarity scores, a number of potential matches among the entity pairs: (Faruquie, Para. [0073] - [0074], “Once the entire set of entities is Minhashed for a given Minhash iteration, the hash values are compared to identify matches . . . Minhash matches may be filtered using, e.g., a Jaccard similarity . . . where the Jaccard similarity for a pair of entities is below a similarity threshold, the pair may be removed from the blocked set of entity pairs”, where the similarity scores are used for “identifying matches” and then filtered to remove “false positives”, which derives the potentially matching entity pairs as the remaining pairs, see Faruquie, Para. [0074], “Thus, false positives can be removed from the blocked set of entity pairs having matching Minhashes in a Minhash iteration by removing the pairs from the set that have a low similarity according to the Jaccard similarity”); and
inputting the potential matches into a random forest model in a second layer comprising a machine learning model generating a number of matched entities from among the potential matches (Faruquie, Fig. 1; Para. [0062], “the entity engine 150 utilizes, e.g., a classifier . . . the classifier may include, e.g., random forest . . . [and] the classifier may be configured to classify a match where the probability of a match exceeds a probability”, where, the potential matches, pairs of entities, are input into a “random forest” classifier to generate matched entities, “classify a match”, and where, as discussed in regard to Claim 1, Faruquie, Fig. 4, where a second layer is depicted, including the “Feature Generator 440” and the “Entity Engine 450”; which together form the “entity resolution” system, see Faruquie, Abstr., “In order to facilitate entity resolution, systems and methods include”; Faruquie, Para. [0101], “an entity engine 450, such as the entity engine 150”, where “450” and “150” can be the same “entity engine”),
the matched entities comprising confidence scores above a specified confidence threshold (Faruquie, Fig. 1; Para. [0064], “the entity merge engine 160 may select candidate matches from the set of candidate matches based on a threshold probability score”),
and wherein the matched entities are pairs of entity identifiers that refer to a same company (Faruquie, Abstr., “The processor merges records of candidate pairs of each cluster into a respective entity record. The processor determines an entity associated with each entity record and updates an entity database with the entity record”, where the association of the candidate pairs with a single entity indicates they are considered a same company).
The reasons of obviousness have been noted in the rejection of Claim 1 and remain applicable here.
Claims 8, 16, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Faruquie in view of Gundersen, Elmagarmid and Elfeky et al. (hereinafter Elfeky) (“Record Linkage: A Machine Learning Approach, A Toolbox, and a Digital Government Web Service”).
Regarding Claim 8, Faruquie in view of Gundersen and Elmagarmid teaches the method of Claim 1 . . . .
Faruquie in view of Gunderson and Elmagarmid do not explicitly teach . . . wherein the machine learning model is trained with supervised learning.
However, Elfeky teaches . . . wherein the machine learning model is trained with supervised learning (Pg. 1, Abstract, “The process of identifying the record pairs that represent the same entity (duplicate records), commonly known as record linkage”; Pg. 2, Para. 3, “The record linkage problem can be viewed as a pattern classification problem . . . Machine learning methods . . . are widely used in pattern classification . . . [, which] are categorized into two main groups: supervised learning and unsupervised learning. A method is supervised if training data is available”).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the inputting of sufficiently similar pairs to a machine learning model to determine whether the pairs are of matched entities, as indicated by a confidence score generated by the machine learning model of Faruquie in view of Gundersen and Elmagarmid with the use of supervised learning to train a machine learning model to recognize matching entity pairs of Elfeky in order to increase the accuracy of the trained model (Elfeky, Pg. 8-9, Sec. 3.3, Para. 1, “Supervised learning gives more accurate results for pattern classification than unsupervised learning”; see generally, Elfeky, Pg. 1, Abstract, “The process of identifying the record pairs that represent the same entity (duplicate records), commonly known as record linkage”; Elfeky, Pg. 2, Para. 3, “The record linkage problem can be viewed as a pattern classification problem).
Regarding Claim 16, the additional elements of the dependent claim are substantially the same as the limitations of Claim 8, therefore it is rejected under the same rationale.
Regarding Claim 24, the additional elements of the dependent claim are substantially the same as the limitations of Claim 8, therefore it is rejected under the same rationale.
Response to Arguments
Applicant's arguments filed on 02/05/2026 have been fully considered. Each argument is addressed below.
I. Applicant argues the after final amendments should be entered (Applicant’s Remarks, 02/05/2026, Pg. 8, Section “II. Request for Entry of After Final Amendment”).
In repose to Applicant’s request for continued examination under 37 CFR 1.114, the after final amendments filed on 02/05/2026 have been entered.
As a result, the argument is moot.
II. Applicant argues the rejections of the claims, under 35 U.S.C. § 103, should be withdrawn (Applicant’s Remarks, 02/05/2026, Pg. 9-16, Sections “III. Reply to Response to Arguments” and “IV. Asserted Obviousness Under 35 U.S.C. § 103”).
In response to Applicant’s amendments, the previously communicated rejections under 35 U.S.C. § 103, have been withdrawn. However, Applicants arguments are not persuasive in light of the new grounds for rejection, under 35 U.S.C. § 103, discussed in detail above. The new grounds of rejection rely on new combinations of the prior art of record to teach the new combination of elements in the amended independent claims, which were not presented in this arrangement in any of the previously presented claims. As a result, Applicant’s arguments are rendered moot.
However, in order to facilitate compact prosecution and in the interest of increased clarity, arguments still relevant to the new grounds of rejection are discussed below. In order to facilitate this discussion, arguments have been reorganized to group repeated arguments and relevant MPEP and CFR excerpts are reproduced here:
According to MPEP 2111, “During patent examination, the pending claims must be given their broadest reasonable interpretation consistent with the specification” (internal quotation marks omitted) (see also Phillips v. AWH Corp., 415 F.3d 1303, 1316, 75 USPQ2d 1321, 1329 (Fed. Cir. 2005)).
Additionally, according to MPEP 2145, “Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims” (see also In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993)).
Also, according to MPEP 2145, “One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references” (see also In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981)).
Next, according to MPEP 2143, “The Supreme Court . . . identified a number of rationales to support a conclusion of obviousness . . . [including] a person of ordinary skill in the art would have been motivated to combine the prior art to achieve the claimed invention and whether there would have been a reasonable expectation of success in doing so”. Furthermore, according to MPEP 2143.01, “If the proposed modification or combination of the prior art would change the principle of operation of the prior art invention being modified, then the teachings of the references are not sufficient to render the claims prima facie obvious.”
Furthermore, according to MPEP 2145, “Furthermore, "the prior art’s mere disclosure of more than one alternative does not constitute a teaching away from any of these alternatives because such disclosure does not criticize, discredit, or otherwise discourage the solution claimed” (internal quotation marks omitted).
Finally, according to 37 C.F.R. 1.111(b), “In order to be entitled to reconsideration or further examination, . . . The reply by the applicant or patent owner must . . . specifically points out the supposed errors in the examiner’s action . . . A general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references does not comply with the requirements of this section.”
First 1), Applicant argues the reliance on Gundersen to teach “data . . .for supply chains” (Claim 1, ln. 3-4) is insufficient (Pg. 9, Para. 2; Pg. 14, Para. 4). Specifically, according to the Applicant, while Gundersen’s teaching of delivery locations may be a part of a supply chain, Gundersen is not specifically concerned with supply chain entity resolution and does not teach the whole collection of entities that encompass a supply chain. Per the Applicant, these include “matching company names in addition to addresses, handling legal entity designation variations (Corporation, Corp., Inc., Ltd., LLC, GmbH, etc.), international company name variations across jurisdictions, or company name abbreviations and conventions that are essential to entity resolution defining a supply chain”. Here, Gundersen’s teaching of delivery locations is within the broadest reasonable interpretation of data for supply chains because, as pointed out by the Applicant, it is data that is part of a supply chain (MPEP 2111). Additionally, as discussed in detail above, Faruquie’s disclosure of variations between legal entity designations for the same company and different abbreviations for the same company (see Faruquie, Table 1) are within the broadest reasonable interpretation of the elements of supply chain identifiers that are positively recited in the amended claims (MPEP 2111). Whereas a requirement that the entity identifiers encompass every possible component of supply chain data is not positively recited in the claims and is, therefore, not read into the claims (MPEP 2145).
As a result, the argument is not persuasive.
Second 2), Applicant argues the proposed Faruquie combination requires a fundamental architecture redesign, which would require substantial reconstruction of Faruquie’s system, including “1. Removing or modifying Faruquie's sequential MinHash - Jaccard pipeline; 2. Adding three new similarity algorithms (Token Diff, Needleman-Wunsch, Smith-Waterman); 3. Implementing parallel execution of four algorithms on same entity pairs; 4. Implementing score combination logic to create composite scores; 5. Adding temporal batch processing architecture; 6. Adding state tracking for processed entities across batches; 7. Modifying pairing logic to avoid target-to- target pairing; 8. Adapting the system for company name-address matching” (Pg. 9, Para. 3). Here, Applicant-recited limitations labeled “3”, “4”, “5”, and “6” are not positively recited in the claims and are not read into the claims (MPEP 2145). Specifically, “applying each of” (Claim 1, ln. 16) and, to an even greater extent “based upon each of” (Claim 9, ln. 18), do not require parallel execution and “determining” (Claim 1, ln. 14) does not require score combination logic to create composite scores. Additionally, no specific temporal batch processing architectural elements, or even any specific architectural processing elements at all, are discussed, and state tracking across batches is not discussed.
Regarding “1” and “2”, as discussed in detail above, these modifications amount to adjusting a process where multiple iterations of a similarity algorithm are used and concurrent use of different similarity algorithms is envisioned (Faruquie, Para. [0073] – [0074]), such that different similarity algorithms are used instead of multiple iterations of a MinHash algorithm. This does not change the principle of operation of Faruquie (MPEP 21.43.01). As to “7” and “8”, as discussed in detail above and in the 12/11/2025 Office Action, these modifications do not alter the substance of any of Faruquie’s operational steps. Instead, these changes amount to specifying that Faruquie’s addresses (Faruquie, Para. [0044]) are delivery addresses and preprocessing Faruquie’s first and second sources of records (Faruquie, Para. [0080]) such that one consists of target records and the other consists of new records. This does not change the principle of operation of Faruquie (MPEP 21.43.01). Furthermore, Applicant has not provided any evidence for why these changes would change the principle of operation of Faruquie (37 C.F.R. 1.111(b)).
As a result, the argument is not persuasive.
Third 3), Applicant argues that Elmagarmid teaches algorithm section is highly data-dependent and that a known technique does not dominate over others across all datasets, and as a result, does not teach, and in fact contradicts that, one should combine all of the similarity algorithms it teaches (Pg. 10, Para. 1; Pg. 12-13, Para. 3-1). Additionally, Applicant argues Elmagarmid’s use of the term which indicates selection of only one similarity algorithm. However, as discussed in detail above, Faruquie teaches utilizing multiple iterations of a MinHash algorithm to generate a similarity score for each pair in order to reduce the risk of false negatives (Faruquie, Para. [0073]). Therefore, Applicant’s characterization of Elmagarmid, even if assumed to be true, would be sufficient to teach the limitation in combination with Faruquie. This is because, even in the light most favorable to the Applicant, Elmagarmid would teach that a given input of data may only be effectively analyzed by one of a collection of different similarity algorithms, such as one of token Diff, Needleman-Wunsch, Smith-Waterman, and MinHash. Thus, before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the application of each of multiple iterations of a MinHash algorithm to each entity pair of a number of entity pairs in order to determine a similarity score for each entity pair, wherein multiple different similarity algorithms are used concurrently, of Faruquie in view of Gundersen with the use of a Token Diff algorithm, a Needleman-Wunsch algorithm, and a Smith-Waterman algorithm for entity matching of Elmagarmid in order to utilize supplementary similarity algorithms to increase the effectiveness of the similarity scores by reducing the risk of false negatives (compare Faruquie, Para. [0073], where the “reduc[tion of] the risk of false negatives” is limited by the applicability of the “Minhash” to the text of the pairs, with Applicant’s characterization of Elmagarmid, where one of the highly data-dependent algorithms may identify a false positive missed by the other similarity algorithms because different algorithms are appropriate for different error types and no known technique dominates over others across all datasets) (MPEP 2143). As a result, Elmagarmid, encourages, as opposed to criticizing, discrediting, or otherwise discouraging the solution claimed (MPEP 2145). Additionally, “which” is not exclusively used for selection of only one entity. Given that Applicant has not pointed out which of the 62 recitations of “which” in Elmagarmid they are referring to, this argument fails to specifically point out the supposed error with combining Faruquie in view of Gundersen and Elmagarmid (37 C.F.R. 1.111(b)).
As a result, the argument is not persuasive.
Fourth 4), Applicant argues the combination of Gundersen with Faruquie would change the principle of operation of the prior art and the 12/11/2025 Office Action “assert[ed] in error that because the two cites achieve a similar outcome, that their principle of operation are the same” (Pg. 10, Para. 2; Pg. 14, Para. 2-3) (internal quotation marks omitted). This is an incorrect characterization of the 12/11/2025 Office Action. Applicant is encouraged to review the 12/11/2025 Office Action for a detailed response to this argument (see 12/11/2025 Office Action, Pg. 27-30, “Applicant is correct that two processes with similar outcomes do not, necessarily, have similar processes. As a result, the reference[']s shared outcomes of entity resolution would not, by itself, guarantee similar processes. However, . . . [reasoning not addressed by Applicant]”).
As a result, the argument is not persuasive.
Fifth 5), Applicant argues the combination of references are insufficient by attacking references individually where the rejections are based on combinations of references (Pg. 12, Para. 1; Pg. 14, Para. 4). Specifically, Applicant argues Faruquie fails to teach all of the recited similarity algorithms and that Gundersen fails to teach applying multiple algorithms in parallel or using machine learning. However, in addition to referring to elements, which as discussed above, are not positively recited in the claims and not read into the claims (MPEP 2145), this argument is insufficient because a combination of references is relied upon to teach these elements (MPEP 2145).
As a result, the arguments are not persuasive.
Sixth 6), Applicant argues the motivation to combine Faruquie in view of Gundersen with Elmagarmid is conclusory and unsupported by any technical reasoning (Pg. 12, Para. 2). Specifically, Applicant asserts “[t]he Office Action does not explain how the cited ar[t] teaches what problem in Faruquie’s system would adding on three additional algorithms solve or why/how adding algorithms that address different error types (character typos vs. word rearrangement) would “increase effectiveness””. This is an incorrect characterization of the 12/11/2025 Office Action. Applicant is encouraged to review the 12/11/2025 Office Action (Pg. 10-11, Para. 6-1, “utilize supplementary similarity algorithms to increase the effectiveness of the similarity scores . . . where combination of a “Token-based” similarity algorithm with “Character-based similarity”, such as Needleman-Wunsch or Smith-Waterman would help identify “typographical conventions”-related entity matches . . . [and] where use of both “Needleman and Wunsch” and “Smith-Waterman” would allow for entity matching where “prefixes and suffixes” are common, as well as instances where unimportant characters appear in the middle of identifiers”), where it is explained that adding additional algorithms would increase effectiveness by allowing the system to identify a greater number of matches in specific use cases. This rationale, as well as the above discussed updated rationale to teach the amended claims, are sufficient to support a conclusion of obviousness because it demonstrates a motivation to combine the algorithms to increase effectiveness by reducing false negatives with a reasonable expectation of success by increasing the coverage of use cases (MPEP 2143).
As a result, the argument is not persuasive.
Seventh 7), Applicant argues the prior art of record is insufficient because one or more of the cited references fail to teach or suggest one or more of temporal batch tracking, entity processing state metadata, conditional logic based on batch membership, state persistence across processing intervals, parallel algorithms with or without normalization, and weight filtering followed by a random forest model with vote aggregation confidence levels (Pg. 13, Para. 2-3; Pg. 14-15, Para. 4-2). However, parallel algorithms with or without normalization, temporal batch tracking, weight filtering followed by a random forest model with vote aggregation confidence levels, state persistence across processing intervals, and entity processing state metadata are not positively recited in the claims and are not read into the claims (MPEP 2145). Additionally, the aspects of conditional logic based on batch membership which are positively recited in the claims are taught by Gundersen’s disclosure of methods for comparing entities across databases (MPEP 2111) and Applicant’s arguments against the combination of Faruquie with Gundersen were not persuasive.
As a result, the arguments are not persuasive.
Eighth 8), Applicant argues Faruquie’s disclosed pipeline process “teaches away from the first layer application of four algorithms producing a single similarity score as recited in the currently amended claims” (Pg. 16, Para. 2). However, the claims, as currently formulated, positively recite “determining . . . a similarity score” “by applying each of” the algorithms (Claim 1, ln. 14-18; see also Claims 17 and 25) or “based on each of” the algorithms (Claim 9, ln. 16-20), but do not specifically require the generation of a single score. As a result, this single score limitation is not read into the claims (MPEP 2145). Additionally, Faruquie’s disclosed use of multiple MinHash algorithms to avoid false negatives as well as its disclosed use of different similarity algorithms concurrently (see Faruquie, Para. [0073] – [0074]) demonstrate both a desire to use multiple algorithms to determine similarity scores and a willingness to use different kinds of similarity algorithms. As a result, Faruquie encourages, as opposed to criticizing, discrediting, or otherwise discouraging the solution claimed (MPEP 2145).
As a result, the argument is not persuasive.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW BRYCE GOLAN whose telephone number is (571)272-5159. The examiner can normally be reached Monday through Friday, 8:00 AM to 5:00 PM ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Alexey Shmatov can be reached at (571) 270-3428. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MATTHEW BRYCE GOLAN/Examiner, Art Unit 2123
/ALEXEY SHMATOV/Supervisory Patent Examiner, Art Unit 2123
Prosecution Insights