DETAILED ACTION
This Office action is in response to communications filed on June 5th, 2026 for Application No. 17/455,629, in which claims 1-5, 7-13, 15-20, and 23-25 are presented for examination. The amendments filed on June 5th, 2026 have been entered, where claims 1, 3, 9, 11-12, 17, 19-20, and 25 are amended, with claims 6, 14, and 21-22 having been previously canceled.
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 .
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 . . . to expand 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, similarity scores 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 similarity scores are 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 the number of 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 that have 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 . . . wherein the different entity identifiers of the new data batches for supply chains comprise source entity identifiers comprising data that has not yet been processed, and wherein the previous data batch entity identifiers comprise target entity identifiers comprising data that has been previously processed, and wherein the target entity identifiers are not grouped into entity pairs with each other (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 batch entity identifiers 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, and therefore their associated identifiers, 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)
wherein the different entity identifiers of the new data batches for supply chains comprise source entity identifiers comprising data that has not yet been processed (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”, where “new” demonstrates that the above discussed different entity identifiers of the new data batches for supply chains comprise source entity identifiers comprising data that has not yet been processed; see also Col. 1, Ln. 5-7, “The application relates generally to database maintenance and, more particularly, to reconciling address records between related databases”),
and wherein the previous data batch entity identifiers comprise target entity identifiers comprising data that has been previously processed (Fig. 2; Col. 3, Ln. 6-7, “Production database 120 may be any information product that includes addresses to be updated”, where “to be updated” demonstrates that the above discussed previous data batch entity identifiers comprise target entity identifiers comprising data that has been previously processed; see also Col. 1, Ln. 5-7, “The application relates generally to database maintenance and, more particularly, to reconciling address records between related databases”),
and wherein the target entity identifiers are not grouped into entity pairs with each other (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, and therefore their associated identifiers, from the “production database” are not paired together).
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 entity identifiers only with entities of the new data batches, while also grouping different entities of the new data batches together, wherein the different entity identifiers of the new data batches for supply chains comprise source entity identifiers comprising data that has not yet been processed, wherein the previous data batch entity identifiers comprise target entity identifiers comprising data that has been previously processed, and wherein the target entity identifiers are not grouped into entity pairs with each other 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 are entity pairs having the similarity scores 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 is an entity pair having the similarity scores 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 to perform 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 to expand 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);
wherein the different entity identifiers of the new data batches for supply chains and the previous data batch entity identifiers together comprise source entity identifiers comprising data that has not yet been processed and target entity identifiers comprising data that has been previously processed (Gunderson, Fig. 2; Gunderson, 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”; and Gunderson, Col. 3, Ln. 6-7, “Production database 120 may be any information product that includes addresses to be updated”, where “new” demonstrates that the above discussed different entity identifiers of the new data batches for supply chains comprise source entity identifiers comprising data that has not yet been processed and where “to be updated” demonstrates that the above discussed previous data batch entity identifiers comprise target entity identifiers comprising data that has been previously processed, such that together they comprise source entity identifiers comprising data that has not yet been processed and target entity identifiers comprising data that has been previously processed; see also Gunderson, Col. 1, Ln. 5-7, “The application relates generally to database maintenance and, more particularly, to reconciling address records between related databases”),
and wherein the target entity identifiers are not grouped into entity pairs with each other (Gunderson, Fig. 3-5; Gunderson, 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, and therefore their associated identifiers, from the “production database” are not paired together);
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),
similarity scores 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 similarity scores are 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 06/05/2026 have been fully considered. Each argument is addressed below.
I. Applicant argues the rejections of the claims, under 35 U.S.C. § 103, should be withdrawn (Applicant’s Remarks, 06/05/2026, Pg. 9-17, Sections II and III).
First, Applicant argues Faruquie fails to teach elements of the amended independent claims, which Applicant characterizes as “the Integrated Asymmetric Pairing Architecture” (Applicant’s Remarks, Pg. 11-12, Section “Faruquie's Pairing Engine Does Not Teach the Integrated Asymmetric Pairing Architecture” and Pg. 17, Section “Conclusion”). However, as discussed in detail above, Faruquie is relied upon in combination with Gundersen to teach these elements. As a result, this argument is insufficient because it amounts to attacking references individually where the rejections are based on combinations of references (see MPEP 2145, “One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references”).
Therefore, the argument is not persuasive.
Second, Applicant argues Gundersen fails to teach elements of the amended independent claims, which Applicant characterizes as “Entity Pair Generation for Entity Resolution” (Applicant’s Remarks, Pg. 12-13, Section “Gundersen's Intradupe Check Is Not Entity Pair Generation for Entity Resolution”; Pg. 16, “Remarks on the Office Action’s Response to Applicant’s Prior Arguments”; and Pg. 17, Section “Conclusion”). However, as discussed in detail above, Gundersen is relied upon in combination with Faruquie to teach these elements. As a result, this argument is insufficient because it amounts to attacking references individually where the rejections are based on combinations of references (see MPEP 2145, “One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references”).
Therefore, the argument is not persuasive.
Third, Applicant argues the combination of Faruquie in view of Gundersen fail to teach elements of the amended independent claims, which Applicant characterizes as “the Integrated Asymmetric Pairing Architecture” (Applicant’s Remarks, Pg. 13-14, Section “The Combination Fails to Teach the Integrated Asymmetric Pairing Architecture as a Unified Architectural Constraint”; Pg. 16, “Remarks on the Office Action’s Response to Applicant’s Prior Arguments”; and Pg. 17, Section “Conclusion”). Specifically, Applicant argues “the claims, taken as a whole, demand that all three constraints operate together within a single integrated pairing operation whose outputs are jointly fed into the same downstream pipeline” (Applicant’s Remarks, Pg. 13, Para. 5). Whereas Applicant argues “[i]n Faruquie's system, the pairing engine generates one type of pair (cross-set) . . . [and i]n Gundersen's system, the intradupe check generates a separate type of output in a separate step for a separate purpose” such that “merging these two architecturally distinct operations into a single unified pairing engine - one that simultaneously generates source-to-source and source-to-target pairs while prohibiting target-to-target pairs, all as coordinated inputs to a single first-layer filter - would require a fundamental restructuring of Faruquie's blocking engine architecture. It would not merely adjust Faruquie's existing parameters; it would add new functional capabilities to Faruquie's pairing engine that are foreign to its design”, which “changes the principle of operation of Faruquie's pairing architecture - specifically, the principle that it generates all combinations from two input sets - and is therefore insufficient to establish a prima facie case of obviousness” (Applicant’s Remarks, Pg. 13-14, Para. 6-2).
Here, as discussed in detail above and in previous Office actions, Faruquie discloses grouping entities into a number of entity pairs and performing downstream operations on the number of entity pairs in order to implement entity resolution (see generally Faruquie, Abstract). Applicant is correct that Faruquie is not relied upon to teach the specific aspects of the grouping steps in the amended independent claims, which Applicant characterizes as “the Integrated Asymmetric Pairing Architecture.” Instead, Gundersen is relied upon to teach the grouping of target entities comprising previous data batch entity identifiers into pairs only with entities of the new data batches for supply chains (Gundersen, Abstract; Gundersen, Col. 3, Ln. 6-7; see also Gundersen, Fig. 3-5; Col. 5, Ln. 35-42) and the grouping between different entity identifiers of the new data batches for supply chains (Gundersen, Col. 5, Ln. 50-55), wherein the target entity identifiers are not grouped into entity pairs with each other (Gundersen, Fig. 3-5; Col. 5, Ln. 35-42). As a result, this modification amounts to adjusting the pairing mechanism such that the downstream operations of Faruquie are performed on what Applicant describes as asymmetrical pairs, which does not change Faruquie’s principle of operation because it does not change any of Faruquie’s core similarity-based machining operations that implement entity resolution (see 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, Applicant has not provided any evidence for why these changes would require a fundamental restructuring of Faruquie's blocking engine architecture (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”).
Therefore, the argument is not persuasive.
Fourth, Applicant argues “The Motivation to Combine Does Not Extend to the Integrated Asymmetric Pairing Architecture” (Applicant’s Remarks, Pg. 14-15, Section “The Motivation to Combine Does Not Extend to the Integrated Asymmetric Pairing Architecture” and Pg. 17, Section “Conclusion”). Specifically, Applicant argues “The Office Action's stated motivation to combine . . . [does not] provide[] an articulable reason why a person of ordinary skill in the art would have been specifically motivated to: (a) redefine Faruquie's two symmetric source record sets as a "previously processed" target set and a "not yet processed" source set governed by explicit processing-state semantics;(b) augment Faruquie's cross-set pairing engine with a within-set source-to-source pairing capability - a capability entirely absent from Faruquie's design; and (c) integrate that within-set pairing with the cross-set pairing into a single unified operation that jointly feeds both pair types into the same first-layer filter, while simultaneously imposing an explicit architectural prohibition on target-to-target pairing” (Applicant’s Remarks, Pg. 14, Para. 3). Additionally, Applicant argues “The Office Action's motivation addresses items at a level of generality that does not reach the specific integrated architecture required by the amended claims. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007), and In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006) require an articulated reasoning with rational underpinning for the specific combination proposed. The Office Action has not provided such reasoning at the level of specificity required to arrive at the integrated asymmetric pairing architecture as a unified design element, and a motivation to combine Faruquie with Gundersen for supply chain purposes does not inherently motivate the specific structural integration required by the amended claims” (Applicant’s Remarks, Pg. 1-15, Para. 4-1).
Here, as discussed in detail above and in previous Office actions, 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 entity identifiers only with entities of the new data batches, while also grouping different entities of the new data batches together, wherein the target entity identifiers are not grouped into entity pairs with each other 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). This demonstrates that a person of ordinary skill in the art would have been motivated to combine the prior art to achieve the aspects of the claimed invention, which Applicant refers to as an integrated asymmetric pairing architecture and discusses in regard to (a) through (c), at a level of specificity required by the amended claims, and with a reasonable expectation of success in doing so (see 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”).
Therefore, the argument is not persuasive.
Fifth, Applicant argues “The Integrated Asymmetric Pairing Architecture Provides a Technical Benefit Not Recognized by the Combination” (Applicant’s Remarks, Pg. 15, Section “The Integrated Asymmetric Pairing Architecture Provides a Technical Benefit Not Recognized by the Combination”). Specifically, Applicant argues “The integrated asymmetric pairing architecture serves a specific technical purpose that distinguishes it from the prior art combination: it eliminates computationally redundant target-to- target comparisons while ensuring complete coverage of all potentially novel entity relationships- both within the incoming data batch (source-to-source) and between the incoming batch and the established corpus (source-to-target). This design is particularly significant in a continuously updated entity resolution system for supply chain data, where the target corpus may be substantially larger than the new data batch. By prohibiting target-to-target pairing at the architectural level, the system avoids the O(n2) complexity that would arise from repeatedly pairing all previously reconciled target entities against each other on each new batch run, achieving meaningful computational efficiency that scales with corpus size. This technical benefit - recognized in the specification at paragraph [0043] - is not taught, suggested, or recognized by any of the cited references” (Applicant’s Remarks, Pg. 15, Para. 2). However, as discussed above in regard to the motivation to combine Faruquie with Gundersen, these technical benefits are taught, suggested, and recognized by the prior art of record. Specifically, Gundersen discloses that performance of maintenance on supply chain databases 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 that 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).
Therefore, the argument is not persuasive.
Sixth, Applicant argues Elfeky, which is relied upon as part of a combination with Faruquie in view of Gundersen and Elmagarmid to teach dependent claims 8, 16, and 24, fails to cure the alleged deficiencies with the rejections of the independent claims (Applicant’s Remarks, Pg. 15-16, Section “Response to Rejection of Claims 8, 16, and 24 Under § 103 (Adding Elfeky)”). However, as discussed in detail above, arguments in favor of the alleged deficiencies with the rejections of the independent claims are not persuasive. Furthermore, Elfeky is not relied upon to teach any elements of the amended independent claims.
Therefore, the argument is not persuasive.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
