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 .
Response to Amendment
In the remarks filed on 09/08/2025. The applicant amended claims 1, 8-9, 14-16, and 18-20 are amended. No claims were added.
Response to Arguments
With respect to 35 U.S.C. §101 rejections:
Applicant’ claim amendments and remarks filed on 09/08/2025 have been fully considered and does not overcame the101 rejection as presented in the non-final office action filed 06/10/2025. Applicant argues that the claims are directed to a practical application because they allow separate entities to find matching record across separate databases with out disclosing private information and without relying on trusted third party. Applicant further asserts that the claimed subject matter goes beyond the capacity of a human mind, since a human would inherently have access to all the data and thereby defeat the privacy preserving purpose. Applicant also contends that the claims enables multiple independent users to compare records sets and identify matching records without revealing the actual data of the record sets to each other or to a third party which cannot be practically be done by the human mind. Examiner acknowledged the applicant’s perspective; However, the applicant’s argument with respect to the 101 rejection of claims 1, 14, and 20 are unpersuasive.
Firstly, Examiner cannot give weight on applicant arguments such as “enabling separate entities to find matching……..for sharing private or sensitive information,” having access to the data of two record sets has already defeated the purpose of the claim wherein separate entities find matching data records without disclosure of private information” and “enables multiple independent users to compare records sets and identify matching records without revealing the actual data of the record sets to each other or to a third party” since claim 1 does not positively recites “separate entities” and “multiple independent users”. Secondly, Applicant argues that “a single human mind…cannot practically perform these steps without revealing private information”. This argument misapplies the test. The 101 analysis does not turn on whether it would be practical or convenient for human to perform the steps at scale, it analyzes the claim limitations whether it recites activities that fall into a judicial exception such as mental process. Here, the claim limitations of comparing data sets, identifying matches, and computing similarity scores are precisely the types of activities that constitute abstract ideas, regardless of whether they are carried out more quickly or securely by a computer.
The claims in independent claims 1, 14, and 20 are directed to comparing, filtering, and matching data records. The claim 1 recite the accessing step (“access data over a network from a separate network server”) is just a data gathering and adding network server seems generic or conventional and does not articulate specific technical improvements or a novel architecture for the network/server beyond standard data retrieval or sharing and is an insignificant input-solution activity that is necessary/required for the use of the recited judicial exception. Also, “performing private set intersection between two record sets to determine identical intersecting records corresponding to a particular record field”, “removing any identical intersecting records from each of the two record sets to form two respective record subsets, each respective record subset including records remaining after the removal of the identical intersecting records from the corresponding record set”, “separately computing locality sensitive hash values for each of the two record subsets, wherein the locality sensitive hash values are computed for records corresponding to the particular record field, and the locality sensitive hash values for a first records subset of the two record subsets are computed without access to the second record subset”, “sharing signed locality sensitive hashes of the data over the network” , “jointly performing the private set intersection between the locality sensitive hash values separately computed for each of the two record subsets”, “determining that an intersecting pair of records between the two record subsets are a match based, at least in part, on a similarity score associated with the intersecting pair of records being above a predetermined threshold”, “storing, over the network, information associated with the intersecting pair of records, in a data record database”, and “providing a user access to the information associated with the intersecting pair of records, in the data record database over the network” claim as a whole merely describes how to generally “apply” the concept of sharing and storing that under its broadest reasonable interpretation. The amended claims are still directed to an abstract ideas namely data comparison, information matching using operation (e.g., set intersections, hashing, similarity scores), which enumerates a mental evaluation. These claims amount to data comparisons and mathematical evaluation that can be performed by a huma using pen and paper. Just reciting that such steps are performed by “a computer” or “over a network” does not remove them from realm of abstract ideas.
Applicant further argues that the claims integrate the alleged abstract idea into a practical application because they enable private matching between entities without a trusted third party. This argument is also not persuasive. The claims do not recite any specific technological mechanism that improves the functioning of a computer or another technology. Rather, the claims broadly involve generic computer components (servers, networks, databases) as tools to carry out the abstract steps. The claimed privacy benefit is not tied to any specific technical improvement in how computer operates; instead, it just reflects a desired result of carrying out the abstract idea in a routine computing environment. In addition, Examiner respectfully disagrees that dependent claims 2-13 are also directed to abstract ideas at least by virtue of their dependency on non-abstract independent claims, and for the additional features that they recite. Analogous claims 14-20 are also patent ineligible. For this reason, Examiner will maintain the 101 rejections as set forth below.
With respect to 35 U.S.C. §102 and 135 U.S.C. §103 rejections:
Applicant's arguments filed on 09/08/2025 have been received and entered. Applicant's arguments with respect to the newly amended independents “Claim Rejections - 35 USC § 103” remarks pages 11 -13, have been considered but the argument are not persuasive.
Applicant argues that Funk (US 11061874 B1) in view of Amisano (US 20190378599 A1) cannot be beneficially combined. Applicant further argues that Funk already assumes full access to both record sets, and therefore the privacy preserving aspects of Amisano would provide no benefit in Funk’s system, such that there is no motivation to combine. Examiner acknowledged the applicant’s perspective; however, the arguments are not persuasive. Funk discloses resolving entity records across multiple independent data stores (see Funk col 5-6). A PHOSITA would recognize that such independent datastores may be operated by the separate entities or domains, and that privacy and security considerations are relevant in these contexts. Amisano teaches a private set intersection (PSI) technique that enables record matching across entities without disclosing sensitive data (see Amisano, [0025], [0057-0058]) A PHOSITA would have found it obvious to apply Amisano’s PSI techniques in Funk’s environment to achieve the well-recognized benefit of enabling Funk’s record matching process to be performed in privacy preserving manner.
Applicant’s further asserts that Amisano’s privacy preserving aspects would complicate Funk without providing benefit. However, it is sufficient for PHOSITA to recognize that combining these two references yields predictable benefits. The benefit is clear: Funk’s entity resolution system can be implemented in a way that protects sensitive records across distributed data stores. Even if Funk discloses the scenarios where both sets are accessible, it is still obvious to apply Amisano’s teachings in contexts where Funk’s system is deployed across the independent parties with privacy concerns. Hence, Funk teaches performing record intersections and Amisano teaches using PSI to privately perform intersections between two record sets. Combining these teachings amounts to predictable substitution of one technique record intersection (i.e., direct comparison) with another (private set intersection) to achieve a goal of protecting sensitive information. Thus, applicant’s arguments on there is “no motivation” to combine Funk and Amisano is not persuasive because it ignores the recognized privacy benefits of Amisano’s technique when applied in Funk’s distributed, multiparty environment. The rejection of claims 1-20 under 103 is maintained.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Independent claims 1, 14 and 20:
Step1:
Claims 1 is drawn to “a method”, claim 14 is drawn to “a non-transitory computer-readable storage media configured to store instructions to perform the method”, and claim 20 is drawn to “a system”, therefore each of these claim groups falls under one of four categories of statutory subject matter (process/method, machines/products/apparatus, manufactures, and compositions of matter).
Step 2A, Prong 1:
Claims 1, 14, and 20 are directed to a judicially recognized exception of an abstract idea without significantly more. Each of claims 1, 14, and 20 recites limitations the accessing step (“access data over a network from a separate network server”) is just a data gathering and adding network server seems generic or conventional and does not articulate specific technical improvements or a novel architecture for the network/server beyond standard data retrieval or sharing and is an insignificant input-solution activity that is necessary/required for the use of the recited judicial exception. Also, “performing private set intersection between two record sets to determine identical intersecting records corresponding to a particular record field”, “removing any identical intersecting records from each of the two record sets to form two respective record subsets, each respective record subset including records remaining after the removal of the identical intersecting records from the corresponding record set”, “separately computing locality sensitive hash values for each of the two record subsets, wherein the locality sensitive hash values are computed for records corresponding to the particular record field, and the locality sensitive hash values for a first records subset of the two record subsets are computed without access to the second record subset”, “sharing signed locality sensitive hashes of the data over the network” , “jointly performing the private set intersection between the locality sensitive hash values separately computed for each of the two record subsets”, “determining that an intersecting pair of records between the two record subsets are a match based, at least in part, on a similarity score associated with the intersecting pair of records being above a predetermined threshold”, “storing, over the network, information associated with the intersecting pair of records, in a data record database”, and “providing a user access to the information associated with the intersecting pair of records, in the data record database over the network” claim as a whole merely describes how to generally “apply” the concept of sharing and storing that under its broadest reasonable interpretation. The amended claims are still directed to an abstract ideas namely data comparison, information matching using operation (e.g., set intersections, hashing, similarity scores), which enumerates a mental evaluation. Other than reciting a generic “one or more computer processors” (Claim 20), nothing in the claims preclude the steps from practically being performed in the human mind. For example, other than the “computer processors” language, the claims encompass a user visually and manually compares two record sets to determine identical records of a particular record field (e.g. social security numbers), extracts the identical records to form two subsets of the particular record field, manually calculate locality sensitive hash values for each of the two subsets of the particular record field, compare the hash values between the two subsets, and determine the two subsets of the particular record field is a match based on the similarity score of the locality sensitive hash values being above a predetermined threshold. The mere nominal recitation of a generic computer component (computer processor) to automate the mental evaluation does not take the claim limitations out of the as such, the steps of determining identical records, removing the identical records, computing locality sensitive hash values and determining a match based on similarity scores are nothing more than abstract mental ideas (See MPEP 2106.04(a)(2)(I)(III)).
Step 2A, Prong 2:
Claims 1 and 14 do not recite any additional elements/or steps that would integrate the abstract idea into a practical application. However, claim 20 recites additional element “one or more computer readable storage media” to store computer program instructions and “one or more computer processors” to execute the computer program instructions. The computer readable storage media and the computer processor are recited at a high level of generality (i.e., as generic computer components performing generic computer functions to store and to process data respectively). These generic computer functions are no more than mere instructions to apply the exception using generic computer components. The combination of these additional elements does not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea (MPEP 2106.05(f)).
Step 2B:
The additional elements “one or more computer readable storage media” to store computer program instructions and “one or more computer processors” to execute the computer program instructions are no more than generic, off-the-shelf computer components, and the Symantec, TLI, OIP Techs, and Versata court decisions cited in MPEP 2106.05(d)(II) indicate that mere collection/receipt of data over a network and/or storing and retrieving information in memory are well-understood, routine, and conventional functions when it is claimed in a merely generic manner (See MPEP 2106.05(d)(II)(IV)). As such, claims 1, 14, and 20 are not patent eligible.
Dependent claims 2-7, 9-14, and 16-20:
Step 1:
Claims 2-13 are drawn to “a method” and 15-19 are drawn to “Computer program product” therefore each of these claims falls under one of four categories of statutory subject matter (process/method, machines/products/apparatus, manufactures, and compositions of matter).
Steps 2A-2B:
Dependent claims 2-13 and 15-19 are also ineligible for the same reasons given with respect to claims 1 and 14. Claims 2-13 and 15-19 recite further abstract ideas/mental evaluation of computing private set intersection between data records and hash values by computing a predetermined number of min-hash signatures, dividing the min-hash signatures, using probability to determine a match, adjusting different hash signatures as mentioned in the claim based on particular accuracy and performance requirements, generating a set of overlapping substrings, generating a hash value for each overlapping, generating a hash value for each overlapping, generating a hash value for each overlapping, separately computing the Jaccard similarity, determining one or more matching pairs of LSH values, applying two or more different hashing functions (MPEP 2106.04(a)(2)(I)). Claims 2-13 and 15-19 fail to recite any additional elements/steps that might integrates the abstract idea into a practical application. As such, claims 2-13 and 15-19 are not patent eligible.
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, 9, 14,19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Funk (US 11061874 B1) in view of Amisano (US 20190378599 A1).
Regarding claim 1, Funk teaches a computer-implemented method for determining data intersection, the computer-implemented method comprising:
accessing each of two record sets over a network, wherein each record set is accessed from a separate network server (Fig 1, system 100 for resolving entity names across multiple data stores includes a client computing device 110, an entity resolution system 120, a first data store 130 which may include a first list 140 (i.e., first record set), and a second data store 135 which may include a second list 150. (i.e., second record set) Further, client computing device 110, entity resolution system 120, the first data store 130, and the second data store 135 can communicate over a network 160, Col 5, lines 36-45, entity resolution system 120 includes one or more computing devices (e.g., servers) that access first list 140 and second list 150 over network 160; col.6 lines 37-54; Thus, Funk teaches the first list and the second list are accessed from separate server of computing devices)
performing intersection between the two record sets to determine identical intersecting records corresponding to a particular record field (Funk, performs comparison character by character from the first list 140 to the second list 150 to determine matched string of characters relating to a data entry from the first list 140 and from the second list 150, col.14 lines 25-40) [Examiner interprets first list 140 and second list 150 in figure 5 as two record lists];
removing any identical intersecting records from each of the two record sets to form two respective record subsets, each respective record subset including records remaining after the removal of the identical intersecting records from the corresponding record set (Funk the first list 140 and the second list 150 are updated to completely remove the direct match entries from both lists, col.14 lines 45-47. Thus, the updated lists including only the remaining entries after removing the matched entries)
separately computing locality sensitive hash values for each of the two record subsets, wherein the locality sensitive hash values are computed for records corresponding to the particular record field, (Funk, At fig 5, Step 540, the unresolved updated first list 522 (i.e. first entity) and the updated second list 515 (i.e. second entity) are processed via fuzzy name/keyword matching, where result of the computation has a likeness score between two data entries and the likeliness score correspond to the probability that an entry from the updated second list 524 to the same entity as an entry from the updated first list 522, col.15 lines 14-32) [ In light of specification, examiner interprets “Locality-sensitive hashing (LSH) is an algorithmic technique that hashes similar input items into the same "buckets" with high probability”. Such that a likeness score between two data entries and the likeliness score correspond to the probability that an entry from the updated second list 524 to the same entity as an entry from the updated first list 522 and With the Broadest Reasonable Interpretation, examiner interprets that processing the unresolved updated first list 522 (i.e., first entity) and the updated second list 515 (i.e., second entity) separately via fuzzy name/keyword matching and computing their likeness score corresponding to the probability that an entry from the updated second list 524 to the same entity as an entry from the updated first list 522 as separately computing locality sensitive hash values for each of the two record subsets, wherein the locality sensitive hash values are computed for records corresponding to the particular record field];
jointly performing the intersection between the locality sensitive hash values separately computed for each of the two record subsets (At step advanced match filtering, matching is based on a product of a Jaccard similarity calculation, where the records may only contain those data entries that were unresolved by the direct match evaluation, col.17 lines 43-51) [ In light of specification, examiner interprets “data intersection program 101 determines a Jaccard similarity to determine if there is a match between at least two data records”. Such that locality hash values of the two record subsets are interpreted as determining a match between the updated first list 522 and an updated second list 515 based a product of a Jaccard similarity calculation];
determining that an intersecting pair of records between the two record subsets are a match based, at least in part, on a similarity score associated with the intersecting pair of records being above a predetermined threshold (Funk, At S560, distinguishing pairs with a match probability above certain threshold, result showing matched records with a probability that the pair is associated with the same entity to result as resolved entities at S580, col.16 lines 25-67)
storing, over the network, information associated with the intersecting pair of records, in a data record database (Funk, After the advanced match filtering, the result can be provided in a number of ways, for example, such as showing one or more matching records, a probability that the pair is associated with the same entity, or any combination thereof. The result can then be recorded as a second set of resolved entities 580, see Col 16, lines 34-42 and fig 6 at step 616 the candidate pair exceeding the threshold is added to the resolved records list containing the resolved entities (i.e., information associated with the intersecting pair of records), see Col 18, lines 15-18) [Examiner interprets that recording the results as a second set of resolved entities and adding resolved records list to the resolved entities as storing, over the network, information associated with the intersecting pair of records, in a data record database]; and
providing a user access to the information associated with the intersecting pair of records, in the data record database over the network (Funk, fig 1, client computing device 110, entity resolution system 120, the first data store 130, and the second data store 135 can communicate over a network 160. Also, first data store 130 does not need to include only first list 140. First data store 130 can include any numbers of lists. Also, example system 100 can include any number of data stores. In the case of more than two data stores, first list 140 and second list 150 can be in different data storage devices or can be in the same data storage device, see Col 5, lines 43-54) and fig 6 at step 616 the candidate pair exceeding the threshold is added to the resolved records list containing the resolved entities, see Col 18, lines 15-18) [ Examiner interprets that client computing device interacting with data stores and entity resolution system as user’s ability to access the stored resolved record list in any data stores over the network as providing a user access to the information associated with the intersecting pair of records, in the data record database over the network].
Funk does not appear to explicitly teach:
Performing PSI between the two record sets, computing the locality sensitive hash values for a first records subset of the two record subsets without having access to a second record, jointly performing the intersection between the locality sensitive hash values, sharing the locality sensitive hash values over the network with each of two users
However, Amisano teaches:
Performing PSI between the two record sets (Amisano, private set intersection (PSI) is the multi-party computation technique used to allow the two parties (e.g., provider computing device 110 and prescription database host server 120) with secret inputs to interactively compute the intersection of two sets of data (e.g., the proposed drug prescription information for a patient and the current drug prescription information for a patient), without revealing the full sets to each other. For example, if a healthcare provider needs to prescribe a certain medication to a patient, the present invention is capable of returning a collision value, only, to the healthcare provider, advising that the patient already has a current prescription for the proposed drug (perhaps prescribed by another healthcare provider), without revealing any other private information about the patient, [0028]) Examiner interprets that performing PSI between provider computing device 110 and prescription database host server 120 as performing PSI between the two record sets].
computing the locality sensitive hash values for a first records subset of the two record subsets without having access to a second record (Amisano, FIGS. 1 and 2, generating module 136 further generates, by the first computer (i.e., prescription database host server 120), a private ID based on the received patient identifier and the generated second patient identifier (step 208). generating module 136 generates the private ID through a multi-party computation technique known as oblivious pseudo-random function (OPRF), [0041] and oblivious pseudo random function (OPRF) is the multi-party computation technique used to generate the private ID. OPRF thus enables two parties (e.g., healthcare provider 110 and prescription database host server 120) with secret inputs to interactively compute a pseudo-random string, similar to a hash, without either party revealing their input to the other, [0025] Thus, the generated private ID is derived through the OPRF function from the combination of the healthcare provider's patient identifier (e.g., social security number) and the prescription database hosts randomly assigned private key, [0042] searching module 140 identifies a duplication of the received input, from the provider, that corresponds to the private ID in the secure database, and identifies a contraindication of the received input, from the provider, with one or more inputs that correspond to the private ID in the secure database, through a multi-party computation technique known as private set intersection (PSI), [0057]) [ Examiner interprets that computing OPRF -generated private ID separately for the prescription database host server 120 (i.e. the first record) and OPRF -generated private ID for healthcare provider's patient identifier (e.g., social security number) (i.e. the second record) to identify the particular record of the particular patient as the locality sensitive hash values for a first records subset of the two record subsets are computed without access to a second record subset];
jointly performing the intersection between the locality sensitive hash values (Amisano, FIGS. 1 and 2, generating module 136 further generates, by the first computer (i.e., prescription database host server 120), a private ID based on the received patient identifier and the generated second patient identifier (step 208). generating module 136 generates the private ID through a multi-party computation technique known as oblivious pseudo-random function (OPRF), [0041] and OPRF enables two parties with secret inputs to interactively compute a pseudo-random string similar to a hash, but without either party revealing their input to the other. As such, the generated private ID is derived through the OPRF function from the combination of the healthcare provider's patient identifier (e.g., social security number) and the prescription database hosts randomly assigned private key, [0042] Fig 1 and 3, when health care provider submits the input to searching Module 140 to identify whether a proposed drug prescription has previously, or is currently, prescribed to a patient or whether a proposed drug prescription will have any adverse reactions, or contraindications, with other drugs or medical conditions that a patient currently has, or is taking., [0051], searching module 140 identifies a duplication of the received input, from the provider, that corresponds to the private ID in the secure database, and identifies a contraindication of the received input, from the provider, with one or more inputs that correspond to the private ID in the secure database, through a multi-party computation technique known as private set intersection (PSI), [0057] PSI allows two parties with secret inputs, or sets of items, to interactively compute the intersection of the two sets, without revealing the full sets to each other. As such, PSI based service allows an authenticated healthcare provider to see if a patient already has a prescription. The healthcare provider does not learn of any other prescriptions of a patient, and the prescription database host server 120 does not learn what the healthcare provider is searching for, [0058]) [Examiner interprets that identifying the a contraindication of the received input, from the provider, with one or more inputs that correspond to the private ID (i.e., a particular record field) generated using OPRF in the secure database using private set intersection (PSI) as jointly performing the private set intersection between the locality sensitive hash values].
sharing the locality sensitive hash values over the network with each of two users (Amisano, Multi-party computing environment 100 includes provider computing device 110 and prescription database host server 120 connected via network 102, [0018], FIGS. 1 and 2, generating module 136 further generates, by the first computer (i.e., prescription database host server 120), a private ID based on the received patient identifier and the generated second patient identifier (step 208). generating module 136 generates the private ID through a multi-party computation technique known as oblivious pseudo-random function (OPRF), [0041] and OPRF enables two parties with secret inputs to interactively compute a pseudo-random string similar to a hash, but without either party revealing their input to the other. As such, the generated private ID is derived through the OPRF function from the combination of the healthcare provider's patient identifier (e.g., social security number) and the prescription database hosts randomly assigned private key, [0042] FIGS. 1 and 3, receiving module 132 receives, by the first computer (i.e., prescription database host server 120) (i.e., first record set) , an input from the provider (i.e., provider computing device 110) (i.e., second record set) that corresponds to the patient identifier (step 308). An input may be a proposed drug prescription for the patient, a search query regarding a patient's drug history, a patient's medical conditions, [0049]) [Examiner interprets that private IDs(hash values) generated by using OPRF function are shared between the prescription database host server 120 and client device of health care provider over the network for performing PSI as sharing the locality sensitive hash values over the network with each of two users].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk to include the concept of performing PSI between the two record sets, computing the locality sensitive hash values for a first records subset of the two record subsets without having access to a second record, jointly performing the intersection between the locality sensitive hash values, sharing the locality sensitive hash values over the network with each of two users as taught by Amisano for the purpose of allowing the two parties (e.g., provider computing device 110 and prescription database host server 120) with secret inputs to interactively compute the intersection of two sets of data (e.g., the proposed drug prescription information for a patient and the current drug prescription information for a patient), without revealing the full sets to each other, [Amisano:0028].
Regarding claim 9, Funk in combination with Amisano teaches the computer-implemented method of claim 1, wherein determining that the intersecting pair of records between the two record subsets are a match is further based, at least in part, on a Jaccard similarity (Funk, At fig 6, Step 606 advanced match evaluation, the unresolved records (the first updated list and second updated list are matched based on a product of a Jaccard similarity calculation, Col 6, lines 43-51) being above a predetermined Jaccard threshold.(At fig 6, Step 614, the output of advanced match evaluation i.e. match score is used to determine it exceeds the threshold, Col 18 line 6-8) The threshold can be user specified or automatically generated based on the output of advanced match filter and threshold adjuster, Col 16, lines 31-33) [In light of specification as the Jaccard threshold (JT) is selected based on user input and match control is when a user selects a Jaccard threshold (JT), Examiner interprets that user inputting and adjusting predetermined threshold to determine the match between records using Jaccard similarity calculation as determining that an intersecting pair of records between the two record subsets are a match is further based, at least in part, on a Jaccard similarity being above a predetermined Jaccard threshold, see instant application at spec [0057]).
Regarding claim 14 and 20, Claims 14 and 20 recite commensurate subject matter as claims 1. Therefore, they are rejected for the same reasons. Except the additional elements:
Funk further teaches:
a computer program product for determining data intersection, the computer program product comprising one or more computer readable storage media and program instructions stored on the one or more computer readable storage media (Computer systems 400, fig 4, Col 10, lines 42- 61) the program instructions including instructions to
a computer system (i.e., Computer systems 400, fig 4, Col 10 line 42) for determining data intersection, comprising:
one or more computer processors (Processer 404, fig 4, Col 10, lines 42- 61);
one or more computer readable storage media (Main memory 406, fig 4, Col 10, lines 42- 61);
computer program instructions (fig 4, Col 10, lines 42- 61);
the computer program instructions being stored on the one or more computer readable storage media for execution by the one or more computer processors (fig 4, Col 10, lines 42- 61);and the computer program instructions including instructions
Regarding claim 19, Claim 19 recites commensurate subject matter as Claim 9. Therefore, it is rejected for the same reasons.
Claims 2-8, 10-13, and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Funk (US 11061874 B1) in view of Amisano (US 20190378599 A1) in further view of Hunt (US 20170286544 A1).
Regarding claim 2, Funk combined with Amisano teaches the computer-implemented method of claim 1, wherein
Funk further teaches:
separately computing the locality sensitive hash values for each of the two record subsets (Funk, at fig 5, Step 540, the unresolved updated first list 522 and the updated second list 515 are processed via fuzzy name/keyword matching, where result of the computation has a likeness score between two data entries and the likeliness score correspond to the probability that an entry from the updated second list 524 to the same entity as an entry from the updated first list 522, col.15 lines 14-32).
Funk and Amisano does not explicitly teach:
computing a predetermined number of min-hash signatures for each locality sensitive hash value; and dividing the min-hash signatures computed for each locality sensitive hash value into a predetermined number of signature bands.
However, Hunt teaches:
computing a predetermined number of min-hash signatures for each locality sensitive hash value (Hunt, the predetermined number of hashed shingles are used to create the hash signature, Par [0033] and hash signature generation module 216 applies one or more hash function including min-hash function, par [0028, 0072]);
dividing the min-hash signatures computed for each locality sensitive hash value into a predetermined number of signature bands (Hunt, LSH algorithm use Input number of bands 911 as parameter to subdivide hash signature into N /number of bands which hashed into LSH buckets (i.e., signature bands), see par [0110]).
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk and Amisano to include a concept of computing a predetermined number of min-hash signatures and dividing the min-hash signatures into number of signature bands as taught by Hunt for the purpose of reducing the amount of data required for a signature to be used to estimate Jaccard similarity [Hunt: 0028] to identify phishing websites, defaced websites, spam websites, significant changes in the content of a webpage, copyright infringement, and any other suitable purposes related to the similarity between website DOM object content [Hunt: 0033].
Regarding claim 3, Funk combined with Amisano and Hunt teach the computer-implemented method of claim 2, wherein
Funk further teaches:
determining that an intersecting pair of records between the two record subsets are a match (Funk, fig 5, At S560, distinguishing pairs with a match probability above certain threshold, result showing matched records with a probability that the pair is associated with the same entity to result as resolved entities at S580, col.16 lines 25-67),
Funk and Amisano does not explicitly teach:
further based, at least in part on, each of the intersecting pair or records sharing a same signature band
However, Hunt teaches:
further based, at least in part on, each of the intersecting pair or records sharing a same signature band (Hunt, Input number of bands 911 subdivide hash signature into N /number of bands) and hashed into LSH buckets (i.e., signature bands, see par [0110] and candidate pairs are similar if at least one of their LSH buckets (i.e., signature bands) are identical and share the same offset with in the signature, see par [0030, 0107]).
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk and Amisano to include the concept of determining a match based on shared same signature band as taught by Hunt for the purpose of comparing large number of documents quickly (Hunt, par [0107]) to identify phishing websites, defaced websites, spam websites, significant changes in the content of a webpage, copyright infringement, and any other suitable purposes related to the similarity between website DOM object content [Hunt: 0033].
Regarding claim 4, Funk combined with Amisano and Hunt teach the computer-implemented method of claim 3, wherein
Funk further teaches:
a probability of determining that the intersecting pair of records between the two record subsets are a match (Funk, fig 5, At S560, distinguishing pairs with a match probability above certain threshold, result showing matched records with a probability that the pair is associated with the same entity to result as resolved entities at S580, col.16 lines 25-67)
Funk and Amisano does not explicitly teach:
and an amount of time for finding all intersecting pairs of records between the two record subsets is dependent on a total number of min-hash signatures computed for each locality sensitive hash value and a total number of signature bands created
However, Hunt teaches:
and an amount of time for finding all intersecting pairs of records between the two record subsets is dependent on a total number of min-hash signatures computed for each locality sensitive hash value and a total number of signature bands created (Hunt, if number of shingles (i.e., overlapping substrings increases then the calculation and comparison of number of shared elements increases (i.e., processing times), see par [0028,0031,0089-0091,0154]).
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk and Amisano to include the concept of dependency of creating of min-has signatures with a probability of determining intersections and amount of time to find intersections as taught by Hunt for the purpose of making processing of similarity process much faster (Hunt, par [0091]) to identify phishing websites, defaced websites, spam websites, significant changes in the content of a webpage, copyright infringement, and any other suitable purposes related to the similarity between website DOM object content [Hunt: 0033].
Regarding claim 5, Funk combined with Amisano and Hunt teach the computer-implemented method of claim 3,
Funk and Amisano does not explicitly teach:
wherein the predetermined number of min- hash signatures to be computed for each locality sensitive hash value and the predetermined number of signature bands created are adjusted based on particular accuracy and performance requirements
However, Hunt teaches:
wherein the predetermined number of min- hash signatures to be computed for each locality sensitive hash value and the predetermined number of signature bands created are adjusted based on particular accuracy and performance requirements (Hunt, Number of bands affects the processing resources and accuracy and minimizing size of LSH buckets (i.e., signature bands) to use less processing resources, see par [0028, 0111]) [Examiner interprets trading off between accuracy and processing resources by manipulating number of bands is equivalent to adjusting based on particular accuracy and performance requirements].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk and Amisano to include the adjusting predetermined signature bands based on particular accuracy and performance requirements as taught by Hunt for the purpose of creating flexibility and extensive use of hash algorithms for various applications (Hunt, par [0091])) to identify phishing websites, defaced websites, spam websites, significant changes in the content of a webpage, copyright infringement, and any other suitable purposes related to the similarity between website DOM object content [Hunt: 0033].
Regarding claim 6, Funk combined with Amisano teaches the computer-implemented method of claim 1, wherein
Funk further teaches:
separately computing the locality sensitive hash values for each of the two record subsets (Funk, In fig 5, At S540, the unresolved updated first list 522 and the updated second list 515 are processed via fuzzy name/keyword matching, where result of the computation has a likeness score between two data entries and the likeliness score correspond to the probability that an entry from the updated second list 524 to the same entity as an entry from the updated first list 522, col.15 lines 14-32); ) further includes:
Funk and Amisano does not explicitly teach:
generating a set of overlapping substrings for a record corresponding to the particular record field; and for each hash function in a set of hash functions: generating a hash value for each overlapping substring in the set of overlapping substrings for the record corresponding to the particular record field; and determining a minimum value of any hash value generated amongst the set of overlapping substrings of the record.
However, Hunt teaches:
generating a set of overlapping substrings for a record (i.e., a website) corresponding to the particular record field (i.e., Dom object of a website) (Hunt, Fig 6, separating a document into polarity of data portions of fixed length (i.e., shingles), see par [0033,0034,0084,0085,0087]) [In light of specification, examiner interprets shingles as overlapping substrings]; and
for each hash function in a set of hash functions:
generating a hash value for each overlapping substring in the set of overlapping substrings for the record corresponding to the particular record field (Hunt, generating N hash values for each shingles (i.e., overlapping substrings) using N hash functions, see par [0102]);
determining a minimum value of any hash value generated amongst the set of overlapping substrings of the record (Hunt, choosing min has value for each shingles with N generated hash values, see par [0102]).
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk and Amisano to include the generating set of overlapping substrings and determining its minimum hash values by using set of hash functions by as taught by Hunt for the purpose of minimizing the length of documents and making processing of similarity process much faster (Hunt, par [0091]) to identify phishing websites, defaced websites, spam websites, significant changes in the content of a webpage, copyright infringement, and any other suitable purposes related to the similarity between website DOM object content [Hunt: 0033].
Regarding claim 7, Funk combined with Amisano and Hunt teaches the computer-implemented method of claim 6, further comprising:
Funk and Amisano does not explicitly teach:
for each minimum value generated from each hash function in the set of hash functions, computing a hash-based signature
However, Hunt teaches:
for each minimum value generated from each hash function in the set of hash functions, computing a hash-based signature (Hunt, Min hash selection criteria are applied to generate minimum value for each hash functions and the vector of minimum hash values 815 represents the min-hash signature, Hunt see par [0102]).
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk and Amisano to include the computing hash-based signature of minimum value generated by as taught by Hunt for the purpose of for the purpose of minimizing the length of documents and making processing of similarity process much faster than one to one comparison of Shingles across documents (Hunt, par [0091]) to identify phishing websites, defaced websites, spam websites, significant changes in the content of a webpage, copyright infringement, and any other suitable purposes related to the similarity between website DOM object content [Hunt: 0033].
Regarding claim 8, Funk combined with Amisano and Hunt teaches the computer-implemented method of claim 7, wherein
Funk further teaches:
determining the intersecting pair of records between the two record subsets (at S560, distinguishing pairs with a match probability above certain threshold, result showing matched records with a probability that the pair is associated with the same entity to result as resolved entities at S580, col.16 lines 25-67) is further based on:
Funk and Amisano does not explicitly teach:
determining that the intersecting pair of records share the hash-based signature
However, Hunt teaches:
determining that the intersecting pair of records share the hash-based signature (Hunt, Jaccard similarity is calculated using intersecting sets of shingles and each shingles are converted into min-hash signatures, Hunt see par [0031,0102]).
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk and Amisano to include the determining intersections based on shared hashed based signature by as taught by Hunt for the purpose of minimizing the length of documents and making processing of similarity process much faster (Hunt, par [0091]) to identify phishing websites, defaced websites, spam websites, significant changes in the content of a webpage, copyright infringement, and any other suitable purposes related to the similarity between website DOM object content [Hunt: 0033].
Regarding claim 10, Funk combined with Amisano teaches the computer-implemented method of claim 9, further comprising:
Funk further teaches:
separately computing the Jaccard similarity for each of the two record subsets (Funk, Fig 6, step 606, Advanced match evaluation calculates the Jaccard similarity for records with unresolved data entries (i.e., first updated and second updated list), Col 17, lines 43-51)
Funk and Amisano does not explicitly teach:
separately computing the Jaccard similarity for each of the two record subsets, wherein the Jaccard similarity is a number of shared substrings corresponding to the particular record field divided by a total number of overlapping substrings of each record subset
However, Hunt teaches:
the Jaccard similarity is a number of shared substrings corresponding to the particular record field divided by a total number of overlapping substrings of each record subset (Hunt, Jaccard similarity is calculated between two sets of information is the magnitude of the set intersection of shared elements divided by magnitude of set union of distinct elements, see par [0031, 0089]).
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk and Amisano to include the Jaccard similarity as a number of shared substrings divided by a total number of overlapping substrings taught by Hunt for the purpose of computing fractional similarity between two documents (Hunt, par [0089]) to identify phishing websites, defaced websites, spam websites, significant changes in the content of a webpage, copyright infringement, and any other suitable purposes related to the similarity between website DOM object content [Hunt: 0033]. As well known, the usage of Jaccard similarity is simple and intuitive. It can account for the frequency of the words, since it only considers the presence or absence of the terms. It can also handle documents of different lengths, since it normalizes by the size of the union.
Regarding claim 11, Funk combined with Amisano teaches the computer-implemented method of claim 1, wherein
Funk further teaches:
jointly performing private set intersection between the locality sensitive hash values separately computed for each of the two record subsets (Funk, at step advanced match filtering, matching is based on a product of a Jaccard similarity calculation, where the records may only contain those data entries that were unresolved by the direct match evaluation, col.17 lines 43-51) further include
Funk and Amisano does not explicitly teach:
determining one or more matching pairs of LSH values based on the jointly performed private set intersection
However, Hunt teaches:
determining one or more matching pairs of LSH values based on the jointly performed private set intersection (Hunt, number of matching hash values are used to calculate the Jaccard similarity, see par [0030,0126]) [Examiner interprets that to calculate the Jaccard similarity, it needs number of the intersection of hashed values between two datasets and hash values are being calculated using LSH function, see par [0106].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk and Amisano to include determining one or more matching pairs of LSH values during taught by Hunt for the purpose of approximating similarity between two webpages for classification (Hunt, par [0126]) to identify phishing websites, defaced websites, spam websites, significant changes in the content of a webpage, copyright infringement, and any other suitable purposes related to the similarity between website DOM object content [Hunt: 0033].
Regarding claim 12, Funk combined with Amisano teaches the computer-implemented method of claim 1, further comprising:
Funk and Amisano does not explicitly teach:
applying two or more different hashing functions to the two record subsets to generate a plurality of hash values for the two record subsets.
However, Hunt teaches:
applying two or more different hashing functions to the two record subsets to generate a plurality of hash values for the two record subsets. (Hunt, Predetermined hashing functions are applied to datasets to create a predetermined number of hashes for each piece of data within the set of data, see par [0028, 0029, 0130]).
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk and Amisano to include the concept of applying multiple hash functions to the two record subsets to generate plurality of hash values taught by Hunt for the purpose of identifying a distinctive pattern, product, or characteristic of the content within documents and limiting the content by converting into predetermined number of sample hash values to be compared between documents (Hunt, par [0029]) to identify phishing websites, defaced websites, spam websites, significant changes in the content of a webpage, copyright infringement, and any other suitable purposes related to the similarity between website DOM object content [Hunt: 0033].
Regarding claim 13, Funk combined with Amisano teaches the computer-implemented method of claim 1, wherein
Funk further teaches:
the similarity score (Funk, At S560 distinguishing pairs with a match probability above certain threshold, result showing matched records with a probability that the pair is associated with the same entity to result as resolved entities at S580, col.16 lines 25-67) is based, at least in part, on
Funk and Amisano does not explicitly teach:
determining the number of shared hash-based signatures.
However, Hunt teaches:
determining the number of shared hash-based signatures. (Hunt, Similarity score is determined by number of matches between hashes of target hash signature and stored hash signature for each of the known hash signature i.e., Shared hash signatures, see par [0157])
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk and Amisano to include determining the number of shared hash-based signatures taught by Hunt for the purpose of approximating similarity between two webpages for classification (Hunt, par [0126]) to identify phishing websites, defaced websites, spam websites, significant changes in the content of a webpage, copyright infringement, and any other suitable purposes related to the similarity between website DOM object content [Hunt: 0033].
Regarding claim 15, Funk combined with Amisano teaches the computer program product of claim 14, wherein
Funk and Amisano does not explicitly teach:
one record subset matches another record subset if each record subset shares at least one b signatures and wherein the probability of the match increases if the number of shared band signatures among the b band signature increases
However, Hunt teaches:
one record subset matches another record subset if each record subset shares at least one b signatures (Hunt, Input number of bands 911 subdivide hash signature into N /number of bands) and hashed into LSH buckets (i.e., signature bands, see par [0110] and candidate pairs are similar if at least one of their LSH buckets are identical and share the same offset with in the signature, see par [0107]) [In light of specification (i.e., one bucket per band), examiner interprets that signature bands are equivalent to their respective LSH bucket. Hence, b signatures being LSH records, b signatures are also signature bands or LSH buckets] and wherein
the probability of the match increases if the number of shared band signatures among the b band signature increases (Hunt, if number of shingles (i.e., overlapping substrings increases then the calculation and comparison of number of shared elements increases (i.e., processing times), see par [0028,0031,0090,0091,0154], also see Funk col.15 lines 14-32).
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk and Amisano to include the concept of applying multiple hash functions to the two record subsets to generate plurality of hash values taught by Hunt for the purpose of comparing large number of documents quickly (Hunt, par [0107]) to identify phishing websites, defaced websites, spam websites, significant changes in the content of a webpage, copyright infringement, and any other suitable purposes related to the similarity between website DOM object content [Hunt: 0033].
Regarding claim 16, Amisano combined with teaches the computer program product of claim 14, wherein
Funk further teaches:
the instructions to separately compute the locality sensitive hash values for each of the two record subsets (Funk, at S540, the unresolved updated first list 522 and the updated second list 515 are processed via fuzzy name/keyword matching, where result of the computation has a likeness score between two data entries and the likeliness score correspond to the probability that an entry from the updated second list 524 to the same entity as an entry from the updated first list 522, col.15 lines 14-32); further includes instructions to:
Funk and Amisano does not explicitly teach:
generate a set of overlapping substrings for a record corresponding to the particular record field; and for each hash function in a set of hash functions: generate a hash value for each overlapping substring in the set of overlapping substrings for the record corresponding to the particular record field; and determine a minimum value of any hash value generated amongst the set of overlapping substrings of the record.
However, Hunt teaches:
generate a set of overlapping substrings for a record corresponding to the particular record field (Hunt, Fig 6, separating a document into polarity of data portions of fixed length (i.e., shingles), see par [0033,0034, 0084, 0085,0087]) [In light of specification, examiner interprets shingles as overlapping substrings]; and
for each hash function in a set of hash functions:
generate a hash value for each overlapping substring in the set of overlapping substrings for the record corresponding to the particular record field (Hunt, generating N hash values for each shingles (i.e., overlapping substrings) using N hash functions, see par [0033,0102]); and
determine a minimum value of any hash value generated amongst the set of overlapping substrings of the record (Hunt, choosing min hash value for each shingles (i.e., overlapping substrings) with N generated hash values, see par [0102]).
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk and Amisano to include the generating set of overlapping substrings and determining its minimum hash values by using set of hash functions by as taught by Hunt for the purpose of for the purpose of minimizing the length of documents and making processing of similarity process much faster (Hunt, par [0091]) to identify phishing websites, defaced websites, spam websites, significant changes in the content of a webpage, copyright infringement, and any other suitable purposes related to the similarity between website DOM object content [Hunt: 0033].
Regarding claim 17 Funk combined with Amisano and Hunt teach the computer program product of claim 16, further comprising instructions:
Funk and Amisano does not explicitly teach:
for each minimum value generated from each hash function in the set of hash functions, computing a hash-based signature.
However, Hunt teaches:
for each minimum value generated from each hash function in the set of hash functions, computing a hash-based signature (Hunt, Min hash selection criteria are applied to generate minimum value for each hash functions and the vector of minimum hash values 815 represents the min-hash signature, see par [0102]).
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk and Amisano to include the computing hash-based signature of minimum value generated by as taught by Hunt for the purpose of for the purpose of minimizing the length of documents and making processing of similarity process much faster (Hunt, par [0091]) to identify phishing websites, defaced websites, spam websites, significant changes in the content of a webpage, copyright infringement, and any other suitable purposes related to the similarity between website DOM object content [Hunt: 0033].
Regarding claim 18, Funk combined with Amisano and Hunt teach the computer program product of claim 17, wherein
Funk further teaches:
the instructions to determine the intersecting pair of records between the two record subsets (Funk, at S560, distinguishing pairs with a match probability above certain threshold, result showing matched records with a probability that the pair is associated with the same entity to result as resolved entities at S580, col.16 lines 25-67) is further based on instructions to:
Funk and Amisano does not explicitly teach:
determine that the intersecting pair of records share the hash-based signature
However, Hunt teaches:
determine that the intersecting pair of records share the hash-based signature (Hunt, Jaccard similarity is calculated using intersecting sets of shingles and each shingles are converted into min-hash signatures, see par [0031,0102]).
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk and Amisano to include the determining intersections based on shared hashed based signature by as taught by Hunt for the purpose of minimizing the length of documents and making the processing of similarity process much faster (Hunt, par [0091]) to identify phishing websites, defaced websites, spam websites, significant changes in the content of a webpage, copyright infringement, and any other suitable purposes related to the similarity between website DOM object content [Hunt: 0033].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20230185783 A1 : “relate to reducing duplicate data storage. Specifically, aspects of the disclosure relate to reducing duplicate data storage using hash-values generated when hashing stored documents”
WO2019204711A1: “securely determining a private set intersection, or characteristics of a private set intersection, for data items maintained by untrusted and/or independent parties”
US20110314045 A1: “generally directed towards a fast and efficient set intersection mechanism based upon algorithms and data structures”
US10778707A1: “A matching record set with respect to a particular data record of a stream is identified based on output values produced by a particular band of locality sensitive hash functions. Using respective matching record sets corresponding to the particular data record and one or more other bands of locality sensitive hash functions, an estimate of a count of data records of the stream which meet a particular inter-record distance criterion is obtained”
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 SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri.
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, SHEWAYE GELAGAY can be reached at (571)272-4219. 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.
/S.N.P./Examiner, Art Unit 2436
/MOEEN KHAN/Primary Examiner, Art Unit 2436
Prosecution Insights