DETAILED ACTION
1. 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 § 112
2. The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
3. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
4. The term “relevant” in independent claims 1 & 10 and dependent claims 15 & 20 is a relative term which renders the claim indefinite. The term “relevant” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Dependent claims 2-9 and 11-20 are rejected for incorporating the deficiencies of independent claims 1 and 10 respectively.
The term “efficiently” in dependent claims 5 and 14 is a relative term which renders the claim indefinite. The term “efficiently” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
The term “large” in dependent claims 5 and 14 is a relative term which renders the claim indefinite. The term “large” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Claims 6 and 15 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Specifically, it is unclear as to whether the claimed “third-party data” in the limitation “wherein the graph builder is configured to apply context-specific criteria when incorporating third-party data into the first-party identity graph” refers to the earlier claimed “third-party data” in the limitation “incorporate relevant third-party data into the first-party identity graph” in parent independent claims 1 and 10 respectively.
Claim 20 recites the limitation "using the first-party identity graph to enhance first-party data with relevant third-party information while maintaining privacy and security of the underlying PII data" in Page 04. There is insufficient antecedent basis for this limitation in the claim as no “underlying PII data” is claimed earlier in the claim or in parent independent claim 20.
Claim Rejections - 35 USC § 101
5. 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.
6. Independent claim 1 is directed towards a system. However, all of the elements claimed could be reasonably interpreted by an ordinary artisan as being software alone, and thus is directed to software per se, which is non-statutory.
In order for such a software claim to be statutory, it must be claimed in combination with an appropriate medium and/or hardware such as a memory or processor to establish a statutory category of invention and enable any functionality to realized.
Claims 2-9 are rejected for incorporating the deficiencies of independent claim 1.
Claim Rejections - 35 USC § 103
7. 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.
8. 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.
9. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
10. Claims 1-3, 5-6, 8, 10-12, 14-15, 17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Xiao et al. (U.S. PGPUB 2025/0259177), in view of Vanasco (U.S. PGPUB 2024/0169322), and further in view of Saba et al. (U.S. PGPUB 2018/0349800), and further in view of Badawy et al. (U.S. PGPUB 2021/0360000).
11. Regarding claims 1 and 10, Xiao teaches a system and method comprising:
B) an identity matcher configured to: receive first-party personally identifiable information (PII) inputs (Paragraphs 16 and 60, Figure 4); and
C) generate embeddings in the form of vectors of floating point values based on the first-party PII inputs using the deep learning model (Paragraphs 51, 58, and 60, Figure 4);
D) a vector database configured to store, index, and retrieve vector data corresponding to the first-party PII embeddings (Paragraph 16);
E) a distributed similarity computation component configured to: take as input the first-party PII embeddings (Paragraph 64);
F) compare the first-party PII embeddings with third-party data embeddings (Paragraphs 34, 46, and 64); and
G) output similarity scores between first-party and third-party data points (Paragraphs 34, 46, and 64).
The examiner notes that Xiao teaches “an identity matcher configured to: receive first-party personally identifiable information (PII) inputs” as “When a new transaction (i.e. proposed identity) is presented to the system, one or more of the columns in the vector search database is compared against one or more data elements associated with the new transaction to determine if the proposed identity is a likely match with one or more of the rows in the vector search database. If a match is sufficiently likely, then the data associated with the transaction can be added to the vector search database as a new row representing a known identity. Alternatively, if certain of the columns match (e.g. image) but other don't match (e.g. date of birth, name, social security, address, etc.), the system may determine that proposed transaction is likely to be fraudulent and flag it as such” (Paragraph 16) and “if a new purported identity is to be validated, some or all of the data components associated with that purported identity (as represented in vector format and by the table in FIG. 4) can be compared against some or all of the data components associated with known identities (as represented in vector format and by the table in FIG. 3)” (Paragraph 60). The examiner further notes that example received address, date of birth, social security, etc. of a transaction teaches the claimed received first-party PII inputs. The examiner further notes that Xiao teaches “generate embeddings in the form of vectors of floating point values based on the first-party PII inputs using the deep learning model” as “In preferred embodiments, image models, such as convolutional neural networks and/or image transformers, can be used to transform an image into a vector. Correspondingly, transformer based language models can transform textual data into vectors” (Paragraph 51), “the trained model is configured to assess the level of similarity between vectorized identity components based on known identities as against vectorized identity components supplied in connection with a proposed transaction or some other request for identity verification and/or to minimize the risk of fraud. Therefore, at the time of production, the model applies these comparisons between and among the various components of a known identity versus a set of identity data purported to be valid with respect to a specific individual” (Paragraph 58), and “if a new purported identity is to be validated, some or all of the data components associated with that purported identity (as represented in vector format and by the table in FIG. 4) can be compared against some or all of the data components associated with known identities (as represented in vector format and by the table in FIG. 3)” (Paragraph 60). The examiner further notes that the vectorization (via a trained model) of input PII data for subsequent comparison against stored vectors teaches the claimed generation of vectors. The examiner further notes that Xiao teaches “a vector database configured to store, index, and retrieve vector data corresponding to the first-party PII embeddings” as “When a new transaction (i.e. proposed identity) is presented to the system, one or more of the columns in the vector search database is compared against one or more data elements associated with the new transaction to determine if the proposed identity is a likely match with one or more of the rows in the vector search database. If a match is sufficiently likely, then the data associated with the transaction can be added to the vector search database as a new row representing a known identity. Alternatively, if certain of the columns match (e.g. image) but other don't match (e.g. date of birth, name, social security, address, etc.), the system may determine that proposed transaction is likely to be fraudulent and flag it as such” (Paragraph 16). The examiner further notes that the vector search database that houses PII data (including from transactions) teaches the claimed vector database. The examiner further notes that Xiao teaches “a distributed similarity computation component configured to: take as input the first-party PII embeddings” as “vector comparisons to determine similarities and/or differences between vectorized data may be accomplished through use of cosine similarity measurements. These measurements may be implemented by determining the cosine of the angle between two vectors and thus deciding whether two vectors are pointing in roughly the same direction. A system threshold for cosine angle may be specified as a configuration parameter depending on the specific implementation of the system and these thresholds may vary depending on the specific data element being assessed for similarity” (Paragraph 64). The examiner further notes that performing vector comparison of first-party PII vectors teaches the claimed input. The examiner further notes that Xiao teaches “compare the first-party PII embeddings with third-party data embeddings” as “Aspects of the present disclosure are directed to identity verification and fraud detection systems and methodologies where data components associated with individuals are converted from either a textual string (in the case of identity data) or from an image to a vector format. The system of the present invention, in preferred embodiments, is first trained using exemplary data such that the model encompasses a reasonably large dataset of vectors” (Paragraph 34), “VBS 120 includes training control module 120a. This module is responsible for managing the training process required to train VBS 120 to determine whether an identity submitted with a proposed transaction is a likely match with known data associated with the identity. This includes processing sample textual data and images contained within training data 110 during the training phase and apply machine learning techniques to develop a data set which is used during the production phase to perform identity entity resolution functions. In some embodiments, VBS 120 may autogenerate a very large set of synthetic data (example images and textual data) based on a base set of training data sourced from training data 110 external to system 100” (Paragraph 46), and “vector comparisons to determine similarities and/or differences between vectorized data may be accomplished through use of cosine similarity measurements. These measurements may be implemented by determining the cosine of the angle between two vectors and thus deciding whether two vectors are pointing in roughly the same direction. A system threshold for cosine angle may be specified as a configuration parameter depending on the specific implementation of the system and these thresholds may vary depending on the specific data element being assessed for similarity” (Paragraph 64). The examiner further notes that performing a vector comparison of first-party PII vectors against vectors (which can include stored training data that can be external (i.e. the undefined 3rd-party embeddings in the broadest reasonable interpretation)) teaches the claimed comparing. The examiner further notes that Xiao teaches “output similarity scores between first-party and third-party data points” as “Aspects of the present disclosure are directed to identity verification and fraud detection systems and methodologies where data components associated with individuals are converted from either a textual string (in the case of identity data) or from an image to a vector format. The system of the present invention, in preferred embodiments, is first trained using exemplary data such that the model encompasses a reasonably large dataset of vectors” (Paragraph 34), “VBS 120 includes training control module 120a. This module is responsible for managing the training process required to train VBS 120 to determine whether an identity submitted with a proposed transaction is a likely match with known data associated with the identity. This includes processing sample textual data and images contained within training data 110 during the training phase and apply machine learning techniques to develop a data set which is used during the production phase to perform identity entity resolution functions. In some embodiments, VBS 120 may autogenerate a very large set of synthetic data (example images and textual data) based on a base set of training data sourced from training data 110 external to system 100” (Paragraph 46), and “vector comparisons to determine similarities and/or differences between vectorized data may be accomplished through use of cosine similarity measurements. These measurements may be implemented by determining the cosine of the angle between two vectors and thus deciding whether two vectors are pointing in roughly the same direction. A system threshold for cosine angle may be specified as a configuration parameter depending on the specific implementation of the system and these thresholds may vary depending on the specific data element being assessed for similarity” (Paragraph 64). The examiner further notes that the calculation of a cosine metric teaches the claimed output.
Xiao does not explicitly teach:
A) a deep learning model trained on a third-party identity graph;
Vanasco, however, teaches “a deep learning model trained on a third-party identity graph” as “wherein a first machine learning model used by the machine learning system is trained based on the first dataset and the first dataset comprises data determined based on a first identity graph at a first time, wherein the first identity graph is determined by identity information provided by one or more of: a user of the identity resolution service, a user of an associated system, an associated system, a user of a third party system or service, a third party system or service, the identity resolution service” (Claim 4).
The examiner further notes that although Xiao teaches a deep learning model, there is no explicit teaching that such a model is trained based on a third party identity graph. Nevertheless, Vanasco teaches the concept of a ML model (i.e. the claimed undefined deep learning model in the broadest reasonable interpretation) being trained on a dataset that includes data from an identity graph that includes information from a third party. Such an identity graph teaches the claimed undefined third-party identity graph in the broadest reasonable interpretation. The combination would result in the model of Xiao to be trained based on a third-party identity graph.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Vanasco’s would have allowed Xiao’s to provide a method for a more richer profile of a user, as noted by Vanasco (Paragraph 34).
Xiao and Vanasco do not explicitly teach:
H) a graph builder configured to: construct a first-party identity graph based on the similarity scores; and
I) incorporate relevant third-party data into the first-party identity graph.
Saba, however, teaches “a graph builder configured to: construct a first-party identity graph based a predefined threshold” as “FIG. 3 illustrates an example ID graph, in accordance with an embodiment. The ID graph 210 contains a plurality of edges linking one or more user accounts and one or more devices. For example, a first edge 305 links two different user accounts (a first account of type A associated with the user A, and a second account of type B associated with the user A), indicating that the two different accounts are associated with the same user (e.g., the user A). As used herein, an “account type” may refer to an account associated with a particular application, such as the online system 104, first party application 108, or third party application 106. For example, a “type A” account may correspond to an account for the online system 104, while a “type B” account may correspond to an account for the first party application 108” (Paragraph 43) and “the ID graph 210 may be updated based upon a temporal aspect. For example, a user device may change ownership over time, and so a user associated with a particular user device in the past may not always remain associated with the device. In some embodiments, if a user has not logged into an account through a device in a threshold amount of time, the edge of the ID graph 210 connecting the user's account to the device may be removed from the ID graph 210” (Paragraph 49) and “incorporate relevant third-party data into the first-party identity graph” as “FIG. 3 illustrates an example ID graph, in accordance with an embodiment. The ID graph 210 contains a plurality of edges linking one or more user accounts and one or more devices. For example, a first edge 305 links two different user accounts (a first account of type A associated with the user A, and a second account of type B associated with the user A), indicating that the two different accounts are associated with the same user (e.g., the user A). As used herein, an “account type” may refer to an account associated with a particular application, such as the online system 104, first party application 108, or third party application 106. For example, a “type A” account may correspond to an account for the online system 104, while a “type B” account may correspond to an account for the first party application 108” (Paragraph 43) and “the third party application 106 may transmit a portion of the attributes associated with an account when making a request to the online system 104. For example, where the user accesses the third party application 106 through an account, the third party application 106 may transmit one or more account attributes associated with the user's account to the online system 104 when making a request to the online system 104 (e.g., for one or more content items to be displayed to the user). The online system 104 may use the received account attributes to establish one or more edges in the ID graph 210 linking the third party application account with an account of the online system 104” (Paragraph 45).
The examiner further notes that Saba teaches the concept of generating a first-party identity graph that is based off a threshold. Such a generated first-party identity graph can also incorporate third-party data. The combination would result in generating an identity graph of the first and third party data of Xiao.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Saba’s would have allowed Xiao’s and Vanesco’s to provide a method for improving the user experience and system resources when delivering content, as noted by Saba (Paragraph 3).
Xiao, Vanesco, and Saba do not explicitly teach:
H) a graph builder configured to: construct a first-party identity graph based on the similarity scores.
Badawy, however, teaches “a graph builder configured to: construct a first-party identity graph based on the similarity scores” as “embodiments of the identity management systems as disclosed may create, maintain or utilize identity graphs. These identity graphs may include a graph comprised of nodes and edges, where the nodes may include identity management nodes representing, for example, an identity, entitlement or peer group, and the edges may include relationships between these identity management nodes. The relationships represented by the edges of the identity graph may be assigned weights or scores indicating a degree of similarity between the nodes related by a relationship, including, for example, the similarity between two nodes representing an identity or two nodes representing an entitlement, as discussed. Additionally, the relationships may be directional, such that they may be traversed only in a single direction, or have different weightings depending on the direction in which the relationship is traversed or the nodes related” (Paragraph 120).
The examiner further notes that although Saba teaches an identity graph with edges, there is no explicit teaching that such a graph is based off of scores. Nevertheless, Badawy teaches that an identity graph can include edges that are based off of similarity scores. The combination would result in the identity graph of Saba to be based off of similarity scores of Xiao.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Badawy’s would have allowed Xiao’s, Vanesco’s, and Saba’s to provide a method for indicating the degree of similarity between nodes of an identity graph, as noted by Badawy (Paragraph 120).
Regarding claims 2 and 11, Xiao does not explicitly teach a system and method comprising:
A) wherein the deep learning model is trained on the third-party identity graph.
Vanasco, however, teaches “wherein the deep learning model is trained on the third-party identity graph” as “wherein a first machine learning model used by the machine learning system is trained based on the first dataset and the first dataset comprises data determined based on a first identity graph at a first time, wherein the first identity graph is determined by identity information provided by one or more of: a user of the identity resolution service, a user of an associated system, an associated system, a user of a third party system or service, a third party system or service, the identity resolution service” (Claim 4).
The examiner further notes that although Xiao teaches a deep learning model, there is no explicit teaching that such a model is trained based on a third party identity graph. Nevertheless, Vanasco teaches the concept of a ML model (i.e. the claimed undefined deep learning model in the broadest reasonable interpretation) being trained on a dataset that includes data from an identity graph that includes information from a third party. Such an identity graph teaches the claimed undefined third-party identity graph in the broadest reasonable interpretation. The combination would result in the model of Xiao to be trained based on a third-party identity graph.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Vanasco’s would have allowed Xiao’s to provide a method for a more richer profile of a user, as noted by Vanasco (Paragraph 34).
Xiao and Vanesco do not explicitly teach:
A) wherein the deep learning model is trained using contrastive learning to improve differentiation between similar but distinct identities.
Saba, however, teaches “wherein the deep learning model is trained using contrastive learning to improve differentiation between similar but distinct identities” as “The user ID inference model 212 (hereinafter also referred to as the “inference model”) illustrated in FIG. 2 comprises a model that may be used to infer a user ID of a user most likely to be associated with a received request” (Paragraph 34) and “The machine learning training engine 214 shown in FIG. 2 trains the inference model 212 using one or more training sets. Each training set includes a set of requests, as well as current device usage data and historical device usage data associated with the requests. The training set includes positive and negative examples, such that a positive example identifies a user that made a particular request and a negative example identifies a user that did not make the request. In some embodiments, the inference model 212 receives information describing requests received from a user device and a user ID of a particular user of the device and generates a score indicating a likelihood that the user with the user ID made the request. In some embodiments, the inference model 212 is configured to receive a request and generate a user ID of a user of the user device that is most likely to have made the request” (Paragraph 35).
The examiner further notes that Saba teaches the use of positive & negative examples (i.e. contrasting learning) for machine learning for an inference model to improve the ascertaining of user identities. The combination would result in using contrasting learning for training the model of Vanesco.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Saba’s would have allowed Xiao’s and Vanesco’s to provide a method for improving the user experience and system resources when delivering content, as noted by Saba (Paragraph 3).
Regarding claims 3 and 12, Xiao further teaches a system and method comprising:
A) wherein the identity matcher is configured to generate embeddings that preserve similarities between different representations of the same identity across first-party and third-party data (Paragraphs 51, 58, 60, and 64, Figure 4).
The examiner notes that Xiao teaches “wherein the distributed similarity computation component is configured to efficiently process large volumes of first-party and third-party identity data” as “In preferred embodiments, image models, such as convolutional neural networks and/or image transformers, can be used to transform an image into a vector. Correspondingly, transformer based language models can transform textual data into vectors” (Paragraph 51), “the trained model is configured to assess the level of similarity between vectorized identity components based on known identities as against vectorized identity components supplied in connection with a proposed transaction or some other request for identity verification and/or to minimize the risk of fraud. Therefore, at the time of production, the model applies these comparisons between and among the various components of a known identity versus a set of identity data purported to be valid with respect to a specific individual” (Paragraph 58), “if a new purported identity is to be validated, some or all of the data components associated with that purported identity (as represented in vector format and by the table in FIG. 4) can be compared against some or all of the data components associated with known identities (as represented in vector format and by the table in FIG. 3)” (Paragraph 60), and “vector comparisons to determine similarities and/or differences between vectorized data may be accomplished through use of cosine similarity measurements. These measurements may be implemented by determining the cosine of the angle between two vectors and thus deciding whether two vectors are pointing in roughly the same direction. A system threshold for cosine angle may be specified as a configuration parameter depending on the specific implementation of the system and these thresholds may vary depending on the specific data element being assessed for similarity” (Paragraph 64). The examiner further notes that generated vectors (i.e. embeddings) of 1st & 3rd party data (which are compared against one another) preserve similarities (which is undefined in the claims and in the specification).
Regarding claims 5 and 14, Xiao further teaches a system and method comprising:
A) wherein the distributed similarity computation component is configured to efficiently process large volumes of first-party and third-party identity data (Paragraphs 34, 46, and 64).
The examiner notes that Xiao teaches “wherein the distributed similarity computation component is configured to efficiently process large volumes of first-party and third-party identity data” as “Aspects of the present disclosure are directed to identity verification and fraud detection systems and methodologies where data components associated with individuals are converted from either a textual string (in the case of identity data) or from an image to a vector format. The system of the present invention, in preferred embodiments, is first trained using exemplary data such that the model encompasses a reasonably large dataset of vectors” (Paragraph 34), “VBS 120 includes training control module 120a. This module is responsible for managing the training process required to train VBS 120 to determine whether an identity submitted with a proposed transaction is a likely match with known data associated with the identity. This includes processing sample textual data and images contained within training data 110 during the training phase and apply machine learning techniques to develop a data set which is used during the production phase to perform identity entity resolution functions. In some embodiments, VBS 120 may autogenerate a very large set of synthetic data (example images and textual data) based on a base set of training data sourced from training data 110 external to system 100” (Paragraph 46), and “vector comparisons to determine similarities and/or differences between vectorized data may be accomplished through use of cosine similarity measurements. These measurements may be implemented by determining the cosine of the angle between two vectors and thus deciding whether two vectors are pointing in roughly the same direction. A system threshold for cosine angle may be specified as a configuration parameter depending on the specific implementation of the system and these thresholds may vary depending on the specific data element being assessed for similarity” (Paragraph 64). The examiner further notes that performing a vector comparison of first-party PII vectors against vectors (which can include stored training data that can be external (i.e. the undefined 3rd-party embeddings in the broadest reasonable interpretation)) teaches the claimed processing. Furthermore, as explained in the 112 rejections above, the terms “efficiently” and “large” are indefinite as they are relative terms, and as a result, the processing of the 1st and 3rd party PII data in Xiao is done in an efficient manner on large amounts such PII data.
Regarding claims 6 and 15, Xiao and Vanesco do not explicitly teach a method and system comprising:
A) wherein the graph builder is configured to apply context-specific criteria when incorporating third-party data into the first-party identity graph.
Saba, however, teaches “wherein the graph builder is configured to apply context-specific criteria when incorporating third-party data into the first-party identity graph” as “FIG. 3 illustrates an example ID graph, in accordance with an embodiment. The ID graph 210 contains a plurality of edges linking one or more user accounts and one or more devices. For example, a first edge 305 links two different user accounts (a first account of type A associated with the user A, and a second account of type B associated with the user A), indicating that the two different accounts are associated with the same user (e.g., the user A). As used herein, an “account type” may refer to an account associated with a particular application, such as the online system 104, first party application 108, or third party application 106. For example, a “type A” account may correspond to an account for the online system 104, while a “type B” account may correspond to an account for the first party application 108” (Paragraph 43) and “the third party application 106 may transmit a portion of the attributes associated with an account when making a request to the online system 104. For example, where the user accesses the third party application 106 through an account, the third party application 106 may transmit one or more account attributes associated with the user's account to the online system 104 when making a request to the online system 104 (e.g., for one or more content items to be displayed to the user). The online system 104 may use the received account attributes to establish one or more edges in the ID graph 210 linking the third party application account with an account of the online system 104” (Paragraph 45).
The examiner further notes that the instant specification is devoid what the undefined claimed “context-specific criteria” constitutes. Moreover, Saba teaches a generated first-party identity graph can also incorporate third-party data based off of attributes (the undefined context-specific criteria in the broadest reasonable interpretation). The combination would result in generating an identity graph of the first and third party data of Xiao based on such context-specific criteria.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Saba’s would have allowed Xiao’s and Vanesco’s to provide a method for improving the user experience and system resources when delivering content, as noted by Saba (Paragraph 3).
Regarding claims 8 and 17, Xiao and Vanesco do not explicitly teach a system and method comprising:
A) wherein the system is configured to build the first-party identity graph without requiring movement of raw first-party PII data outside a secure environment.
Saba, however, teaches “wherein the system is configured to build the first-party identity graph without requiring movement of raw first-party PII data outside a secure environment” as “The first party application 108 may refer to an application that is managed by a common entity as the online system 104. As such, information received by the first party application 108 (e.g., user accounts, user information, user activity logs, and/or the like) may be accessible to the online system 104. For example, users 110 may access the first party application 108 through accounts different from the accounts used to access the online system 104. However, the online system 104 may have access to account information associated with the first party application accounts (e.g., usernames, personally identifiable information (PII) such as email addresses, user preferences or interests, user interaction histories, and/or the like). The online system 104 may make use of the information received by the first party application 108 to perform a variety of different functions, such as collect and aggregate information associated with different users 110 of the user device 102, track activities of different users 110 of the user device, and/or the like. In some embodiments, the first party application 108 may be managed by a subsidiary entity of the online system 104” (Paragraph 21), “In some embodiments, the ID graph 210 maintained by the online system 104 links one or more user accounts with one or more devices. Each individual user may be associated with one or more accounts corresponding to one or more different applications. For example, a particular user (e.g., user A) may be associated with an account on the online system 104, an account on the first party application 108, and an account on the third party application 106. The user may be associated with one or more devices, corresponding to user devices from which the user accesses the online system 104, first party application 108, and/or the third party application 106” (Paragraph 42), “FIG. 3 illustrates an example ID graph, in accordance with an embodiment. The ID graph 210 contains a plurality of edges linking one or more user accounts and one or more devices. For example, a first edge 305 links two different user accounts (a first account of type A associated with the user A, and a second account of type B associated with the user A), indicating that the two different accounts are associated with the same user (e.g., the user A). As used herein, an “account type” may refer to an account associated with a particular application, such as the online system 104, first party application 108, or third party application 106. For example, a “type A” account may correspond to an account for the online system 104, while a “type B” account may correspond to an account for the first party application 108” (Paragraph 43), “The online system 104 is able to maintain a record of when users having accounts associated with the online system 104 access their accounts and through which user devices. In addition, the online system 104 may receive information from the first party application 108 indicating through which devices users have accessed their accounts associated with the first party application 108. In some cases, a particular user may have accessed their account associated with a particular application through multiple different user devices. For example, the ID graph 210 indicates that user A has accessed their account of type A through device A as well as device B” (Paragraph 47).
The examiner further notes that the instant specification is devoid what the undefined claimed “secure environment” constitutes. Moreover, Saba teaches an online system 104 (which builds the first party identity graph) manages the first party application with raw PII data (which entails that such raw PII data is not moved outside the undefined secure environment). The combination would result in generating an identity graph of the first data of Xiao without moving from a secure environment.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Saba’s would have allowed Xiao’s and Vanesco’s to provide a method for improving the user experience and system resources when delivering content, as noted by Saba (Paragraph 3).
Regarding claim 19, Xiao further teaches a method comprising:
A) using the deep learning model to generate embeddings for the new data (Paragraphs 16, 51, 58, and 60, Figure 4).
The examiner notes that Xiao teaches “using the deep learning model to generate embeddings for the new data” as “When a new transaction (i.e. proposed identity) is presented to the system, one or more of the columns in the vector search database is compared against one or more data elements associated with the new transaction to determine if the proposed identity is a likely match with one or more of the rows in the vector search database” (Paragraph 16), “In preferred embodiments, image models, such as convolutional neural networks and/or image transformers, can be used to transform an image into a vector. Correspondingly, transformer based language models can transform textual data into vectors” (Paragraph 51), “the trained model is configured to assess the level of similarity between vectorized identity components based on known identities as against vectorized identity components supplied in connection with a proposed transaction or some other request for identity verification and/or to minimize the risk of fraud. Therefore, at the time of production, the model applies these comparisons between and among the various components of a known identity versus a set of identity data purported to be valid with respect to a specific individual” (Paragraph 58), and “if a new purported identity is to be validated, some or all of the data components associated with that purported identity (as represented in vector format and by the table in FIG. 4) can be compared against some or all of the data components associated with known identities (as represented in vector format and by the table in FIG. 3)” (Paragraph 60). The examiner further notes that the vectorization (via a trained model) of input PII data (which can include new PII data) for subsequent comparison against stored vectors teaches the claimed generation of embeddings.
Xiao and Vanesco do not explicitly teach:
A) updating the first-party identity graph incrementally as new first-party data becomes available, and incorporating it into the existing graph structure.
Saba, however, teaches “updating the first-party identity graph incrementally as new first-party data becomes available, and incorporating it into the existing graph structure” as “FIG. 3 illustrates an example ID graph, in accordance with an embodiment. The ID graph 210 contains a plurality of edges linking one or more user accounts and one or more devices. For example, a first edge 305 links two different user accounts (a first account of type A associated with the user A, and a second account of type B associated with the user A), indicating that the two different accounts are associated with the same user (e.g., the user A). As used herein, an “account type” may refer to an account associated with a particular application, such as the online system 104, first party application 108, or third party application 106. For example, a “type A” account may correspond to an account for the online system 104, while a “type B” account may correspond to an account for the first party application 108” (Paragraph 43) and “The online system 104 may update the ID graph 210 based upon recorded accesses to different user accounts over time. For example, referring back to FIG. 3, if the user A accesses their type B account through the device A, a new edge may be added to the ID graph connecting the user A type B account to the device A. If a user C (not shown) accesses an account of type A using the device A, a new node of the ID graph 210 may be constructed corresponding to the user C type A account, which will be connected to device A through a new edge in the ID graph 210. As the ID graph 210 is updated, the set of potential users that may be associated with the request 402 for a given device ID 404 may be maintained” (Paragraph 48).
The examiner further notes that Saba teaches the concept of updating a first-party identity graph based off of new PII data. The combination would result in updating the identity graph with the embedded new first party PII data of Xiao.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Saba’s would have allowed Xiao’s and Vanesco’s to provide a method for improving the user experience and system resources when delivering content, as noted by Saba (Paragraph 3).
12. Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Xiao et al. (U.S. PGPUB 2025/0259177), in view of Vanasco (U.S. PGPUB 2024/0169322), and further in view of Saba et al. (U.S. PGPUB 2018/0349800), and further in view of Badawy et al. (U.S. PGPUB 2021/0360000) as applied to claims 1-3, 5-6, 8, 10-12, 14-15, 17, and 19 above, and further in view of Bodapati et al. (U.S. PGPUB 2010/0005048).
13. Regarding claims 4 and 13, Xiao, Vanasco, Saba, and Badawy do not explicitly teach a system and method comprising:
A) a custom tokenizer configured to process first-party PII data, including names with variations in format and spelling, email addresses containing name information, addresses with abbreviations and variations, and telephone numbers with hierarchical information.
Bodapati, however, teaches “a custom tokenizer configured to process first-party PII data, including names with variations in format and spelling, email addresses containing name information, addresses with abbreviations and variations, and telephone numbers with hierarchical information” as “Standardization involves ensuring the information in various fields is represented in a standard format so that comparison is easy. For example, to standardize a name field having information "Fredson MD, Dr. Kevin" to the format [FName, LName]=[Kevin, Fredson] (where FName represents First Name and LName represents LName) requires field specific pattern rules where the pattern is "<last name><degree>, <salutation><first name><middle name>". The FPE 220 extracts (302) relevant information from appropriate field entries. The transformation unit 230 transforms the input data records using from extracted field information. Transformation involves ensuring the records have information in comparable fields. For example, it is possible that while comparing two records A and B, record A has phone information and record B does not contain the phone information but contains city and state information. For the two records A and B to be comparable, it would be easy to have information filled in corresponding fields so that comparison between records would be easier. The transformation unit 230 uses knowledge base 134 to fill in missing information using available information. So, continuing the example of records A and B, the transformation unit 230 may fill in city and state information in record A using the phone code information. The transformation unit 230 uses the extracted phone code information from record A in order to achieve that” (Paragraph 25), “The clustering Unit 240 comprising of the matching attribute generator 245 generates keys (303) as described hereafter for tokens, fields and records and clusters (304) similar records based on keys assigned. The Comparing Unit 230 compares the similar records using match percentage (304) as described hereafter. The Merging/purging Unit 240 merges the duplicate records based on match percentage (305)” (Paragraph 26), “Four-Gram MAF though catches variations; it generates different keys for tokens having spelling variation in the first N characters. Example "John" and "Jogn" would get different keys based on Four-Gram MAF. This is taken care by the Spell MAF. The Spell MAF generates n-1 gram combinations of tokens so that tokens with exactly one spelling error are grouped together. So for "John" Spell MAF generates--"ohn","jhn","jon","joh" keys and for "Jogn" it generates--"ogn", "jgn","jon","jog". Here both the tokens have one common key that is "Jon" based on this key they would be hashed together” (Paragraph 33), “Abbreviation MAF generates same key for abbreviations and actual tokens. Example "International Business Machine" and "IBM" get the same key and hence hashed together. There are certain extensions that are done to take care of complex abbreviations. Example "NY Times", "New York Times", "NewYork Times" and "NYT" should get the same key” (Paragraph 39), “Data may be standardized for presentation so that data is more comparable in its format. For example, as shown in Table 1, it is possible that same data is represented in different formats. One such example is presented through the name field, where a name field could be written in "<FName><LName>" format or "<LName>, <FName>". Also, second such example presented in Table 1 is relating to the phone number. Phone can be written in either "(area code) (number)" or "(area code)-(number)". Using the same phone number as in Table 1, it is also possible to write the phone number in many other ways including 17161231234 and so on. The knowledge base captures formats and rules that assists in matching data into different formats and subsequently convert all data into a single format using the standardization unit 210” (Paragraph 46), and “For example in Table 2, if record R-07 and R-02 have to be compared, name part has to be compared with the username part of the email, since corresponding field data is missing the two records. They are not directly comparable with the N-Gram approach as illustrated as representation of names and emails are different. In this example the email pattern of email id found in record R-02 is formed by concatenating the first letter of FName (first name) with the LName (last name) of record R-07. In some embodiments, transformation functions are applied on name field to generate email patterns. The knowledge base contains various rules for email pattern to generate email ids from name field. The email patterns captured by knowledge base may include but not limited to <FName>.<LName>, <First letter of FName><LName>, <FName><First letter of LName>, <FName>.<First letter of LName> and so on” (Paragraph 48).
The examiner further notes that Bodapati teaches the concept of a tokenizer that processes multiple types of PII data including names with variations & spellings, email addresses with name information, addresses with abbreviations & variations, and phone numbers with hierarchical information. The combination would result in using such a tokenizer for the first party PII of Xiao.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Bodapati’s would have allowed Xiao’s, Vanesco’s, Saba’s, and Badawy’s to provide a method for matching information across fields, as noted by Bodapati (Paragraph 22).
14. Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Xiao et al. (U.S. PGPUB 2025/0259177), in view of Vanasco (U.S. PGPUB 2024/0169322), and further in view of Saba et al. (U.S. PGPUB 2018/0349800), and further in view of Badawy et al. (U.S. PGPUB 2021/0360000) as applied to claims 1-3, 5-6, 8, 10-12, 14-15, 17, and 19 above, and further in view of Kundu et al. (U.S. PGPUB 2020/0358796).
15. Regarding claims 7 and 16, Xiao, Vanasco, Saba, and Badawy do not explicitly teach a system and method comprising:
A) a flexible schema handler configured to process input data without adhering to a strict schema, allowing for variations in data structure and content across first-party and third-party sources.
Kundu, however, teaches “a flexible schema handler configured to process input data without adhering to a strict schema, allowing for variations in data structure and content across first-party and third-party sources” as “assume that a first identity vector uses the term “residence” as a name for the field describing where a person lives, while another identity vector uses the term “street address” as the name for the field describing where a person lives. The system, using a lookup table or other correlation logic, recognizes that “residence” and “street address” are the same attribute for the person, and thus these two attributes/fields are compared to one another” (Paragraph 58) and “each identity profile for each person whose identity record/profile is within a particular identity network has an associated graph neural network (see FIGS. 5-6). That is assume that Person A has an identity profile in both identity network 402 as well as identity network 408. Assume further that a graph neural network for each of these identity profiles has a same structure, but perhaps with different labels and/or attribute values. That is, graph neural network 414 and graph neural network 416 are both for Person A, and they both have a same nodal structure. If the aggregate label values (see below with reference to aggregator 601 in FIG. 6) for graph neural network 414 and graph neural network 416 are different, even though they have the same structure and are supposed to both be for the same Person A, then one or both of these identity records/profiles for Person A are deemed to be not similar, and thus potentially fraudulent” (Paragraph 62).
The examiner further notes that Kundu teaches the concept of allowing for variations of input data (See examples of residence and street address) via correlation logic (i.e. a flexible schema handler). The combination would result in allowing for variations across the 1st and 3rd party sources of Xiao.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Kundu’s would have allowed Xiao’s, Vanesco’s, Saba’s, and Badawy’s to provide a method for an effective way to compute similarity across multiple networks, as noted by Kundu (Paragraph 41).
16. Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Xiao et al. (U.S. PGPUB 2025/0259177), in view of Vanasco (U.S. PGPUB 2024/0169322), and further in view of Saba et al. (U.S. PGPUB 2018/0349800), and further in view of Badawy et al. (U.S. PGPUB 2021/0360000) as applied to claims 1-3, 5-6, 8, 10-12, 14-15, 17, and 19 above, and further in view of Schuler et al. (U.S. PGPUB 2023/0325351).
17. Regarding claims 9 and 18, Xiao further teaches a system and method comprising:
A) entities that appear in both first-party and third-party data (Paragraphs 16, 34, 46, 60, and 64).
The examiner notes that Xiao teaches “entities that appear in both first-party and third-party data” as “When a new transaction (i.e. proposed identity) is presented to the system, one or more of the columns in the vector search database is compared against one or more data elements associated with the new transaction to determine if the proposed identity is a likely match with one or more of the rows in the vector search database. If a match is sufficiently likely, then the data associated with the transaction can be added to the vector search database as a new row representing a known identity. Alternatively, if certain of the columns match (e.g. image) but other don't match (e.g. date of birth, name, social security, address, etc.), the system may determine that proposed transaction is likely to be fraudulent and flag it as such” (Paragraph 16), “Aspects of the present disclosure are directed to identity verification and fraud detection systems and methodologies where data components associated with individuals are converted from either a textual string (in the case of identity data) or from an image to a vector format. The system of the present invention, in preferred embodiments, is first trained using exemplary data such that the model encompasses a reasonably large dataset of vectors” (Paragraph 34), “VBS 120 includes training control module 120a. This module is responsible for managing the training process required to train VBS 120 to determine whether an identity submitted with a proposed transaction is a likely match with known data associated with the identity. This includes processing sample textual data and images contained within training data 110 during the training phase and apply machine learning techniques to develop a data set which is used during the production phase to perform identity entity resolution functions. In some embodiments, VBS 120 may autogenerate a very large set of synthetic data (example images and textual data) based on a base set of training data sourced from training data 110 external to system 100” (Paragraph 46), “if a new purported identity is to be validated, some or all of the data components associated with that purported identity (as represented in vector format and by the table in FIG. 4) can be compared against some or all of the data components associated with known identities (as represented in vector format and by the table in FIG. 3)” (Paragraph 60), and “vector comparisons to determine similarities and/or differences between vectorized data may be accomplished through use of cosine similarity measurements. These measurements may be implemented by determining the cosine of the angle between two vectors and thus deciding whether two vectors are pointing in roughly the same direction. A system threshold for cosine angle may be specified as a configuration parameter depending on the specific implementation of the system and these thresholds may vary depending on the specific data element being assessed for similarity” (Paragraph 64). The examiner further notes that entities can appear in a new transaction (i.e. 1st party data) and stored training data (i.e. the claimed undefined 3rd party data).
Xiao, Vanasco, Saba, and Badawy do not explicitly teach:
A) a distributed cluster ID generation component configured to generate unique identifiers for entities.
Schuler, however, teaches “a distributed cluster ID generation component configured to generate unique identifiers for entities” as “Upon identifying that single tokens match, at least one set token (i.e., a consolidation of at least two Customer token records) may be indicated. A set token refers to the consolidation of multiple token records to create a single token record. In other instances, a set token may refer to multiple token sets aggregated together. For example, the Customer tokens may make up multiple token records associated with the same data subject (although, the third-party Consolidation Platform is unable to identify this data subject because the information is tokenized on the third-party Consolidation Platform). A composite of the data subject may be created by consolidating the multiple token records associated with that same data subject. The composite record, when transmitted back to the Customer and/or Reference Source environment and mapped via unique non-derived IDs in the Customer and/or Reference Source environment, the consolidated record would include all of the aforementioned data attributes: Name, DOB, Gender, physical address, email address, and age. The end result is a composite record, which is a single record associated with a certain data subject and/or entity. Such a composite record is created in the Customer Environment, so while the third-party Consolidation Platform may facilitate the identification of certain records to be consolidated and/or enriched, the actual consolidation and enrichment happens at the Customer Environment prior to transmission of the Customer tokens to the Consolidation Platform. As used herein, “data subject” may be a person, product, business, entity, etc. The systems and methods described herein are not limited to simply personal data related to human data subjects but can be applied to supply chain data, product data, business entity data, etc” (Paragraph 47).
The examiner further notes that Schuler teaches the generation of unique identifiers for entities. The combination would result in generating unique identifiers for the matched entities that appear in first and third party data of Xiao.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Schuler’s would have allowed Xiao’s, Vanesco’s, Saba’s, and Badawy’s to provide a method for establishing a golden record of data, as noted by Schuler (Paragraph 4).
18. Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Xiao et al. (U.S. PGPUB 2025/0259177), in view of Vanasco (U.S. PGPUB 2024/0169322), and further in view of Saba et al. (U.S. PGPUB 2018/0349800), and further in view of Badawy et al. (U.S. PGPUB 2021/0360000) as applied to claims 1-3, 5-6, 8, 10-12, 14-15, 17, and 19 above, and further in view of Deo et al. (U.S. PGPUB 2021/0105331).
19. Regarding claim 20, Xiao, Vanasco, Saba, and Badawy do not explicitly teach a method comprising:
A) using the first-party identity graph to enhance first-party data with relevant third-party information while maintaining privacy and security of the underlying PII data.
Deo, however, teaches “using the first-party identity graph to enhance first-party data with relevant third-party information while maintaining privacy and security of the underlying PII data” as “Enriching the first-party data may include retrieving from the cloud-based network third party data associated with one or more third-party user IDs that are linked to a first-party user ID, and extending a first-party user profile associated with the first-party user ID by appending the third-party data” (Paragraph 09) and “Thus, the performance of cloud services on the first-party user data is local to on-premises network, and thus, more secure. Additionally, companies can be provided with the ability control the data collection and profile linkages to the third-party user data stored in cloud network 110” (Paragraph 39).
The examiner further notes that the instant specification (as well as the parent applications) is devoid of any support for the claimed enhancing of first-party data with relevant third-party information via the use of the first-party identity graph while maintaining privacy and security of the underlying PII data. Simply put, there is no discussion whatsoever of the aforementioned enhancing of first-party data with relevant third-party information via the use of the first-party via the use of the first-party identity graph while maintaining privacy and security of the underlying PII data at all. The specification (as well as the parent applications) are utterly devoid of any support for this concept. Furthermore, Deo teaches the concept of enriching first-party user profiles with linked third-party data. Such first-party data that is linked to third-party data is a first-party identity graph in the broadest reasonable interpretation. The combination would result in using the first-party identity graph of Saba to enhance the first-party information of Xiao with relevant third-party information of Xiao.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Deo’s would have allowed Xiao’s, Vanesco’s, Saba’s, and Badawy’s to not violate security standards when mixing first an third party data, as noted by Deo (Paragraph 4).
Conclusion
20. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. PGPUB 2020/0250139 issued to Muffat et al. on 06 August 2020. The subject matter disclosed therein is pertinent to that of claims 1-20 (e.g., methods to process PII data).
U.S. PGPUB 2022/0083604 issued to Ojha on 17 March 2022. The subject matter disclosed therein is pertinent to that of claims 1-20 (e.g., methods to process PII data).
Contact Information
21. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mahesh Dwivedi whose telephone number is (571) 272-2731. The examiner can normally be reached on Monday to Friday 8:20 am – 4:40 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Charles Rones can be reached (571) 272-4085. The fax number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see 20. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Mahesh Dwivedi
Primary Examiner
Art Unit 2168
September 03, 2026
/MAHESH H DWIVEDI/Primary Examiner, Art Unit 2168
