Prosecution Insights
Last updated: April 19, 2026
Application No. 18/666,628

MODELING IMPROVEMENTS FOR COMPLEX DATA VERIFICATION

Final Rejection §101§103
Filed
May 16, 2024
Examiner
SHAIKH, MOHAMMAD Z
Art Unit
3694
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Verifast Inc.
OA Round
2 (Final)
52%
Grant Probability
Moderate
3-4
OA Rounds
3y 6m
To Grant
84%
With Interview

Examiner Intelligence

Grants 52% of resolved cases
52%
Career Allow Rate
285 granted / 544 resolved
At TC average
Strong +31% interview lift
Without
With
+31.3%
Interview Lift
resolved cases with interview
Typical timeline
3y 6m
Avg Prosecution
29 currently pending
Career history
573
Total Applications
across all art units

Statute-Specific Performance

§101
37.9%
-2.1% vs TC avg
§103
33.7%
-6.3% vs TC avg
§102
10.1%
-29.9% vs TC avg
§112
11.2%
-28.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 544 resolved cases

Office Action

§101 §103
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 . DETAILED ACTION 1. This office action is in response to an amendment received on 12/22/25. 2. Claims 1, 8,15 are amended. 3. Claims 1-20 are pending. RESPONSE TO ARGUMENTS Applicant argues#1 Claims 1-20 Recite Statutory Subject Matter under 101 Claims 1-20 stand rejected under 35 U.S.C. § 101 as allegedly being directed to non- statutory subject matter. Applicant respectfully traverses this rejection. Nevertheless, for the sole purpose of expediting allowance and without commenting on the propriety of the Office's rejections, Applicant herein amends claims 1, 8, and 15 as shown above. Applicant respectfully submits that these amendments render the § 101 rejection moot. Moreover, the claims do not include mental processes. Mental processes are defined as concepts performed in the human mind, such as observations, evaluations, judgments, and opinions. The courts consider a mental process (thinking) that "can be performed in the human mind, or by a human using a pen and paper" to be an abstract idea. See CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011). As the Federal Circuit explained, "methods which can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas - the 'basic tools of scientific and technological work' that are open to all." Id., at 1371, 1694 (citing Gottschalk v. Benson, 409 U.S. 63, 175 USPQ 673 (1972)). See also MPEP 2106.04(a)(2), section III. The claims, as amended, are not directed to any operations meant or able to be performed in the human mind. For instance, "determining first training data based at least in part on financial data associated with users, “training a first model based at least in part on the first training data," "verifying the financial information using the first model, wherein the first model is configured to verify information associated with the one or more information types, “determining second training data based at least in part on filter data associated with users, "training a second model based at least in part on the second training data," and "generating, responsive to the request from the third-party including the individual information type and using the second model, wherein the second model is configured to associate requests with the financial information, a representation of the second data," as amended claim 1 recites, cannot realistically be expected to be performed by a human mind or by a human using a pen and paper. “ Accordingly, Applicant respectfully requests that the rejection of claims 1-20 under § 101 be withdrawn. Examiner Response Examiner respectfully disagrees. The claims were not rejected under the Mental Process grouping of abstract ideas. The claims were rejected under the category of a commercial interaction (certain methods of organizing human activity). The limitations (verifying the financial information to verify information associated with the one or more information types; generating responsive to the request from the third party including the individual information type, a representation of the second data) is part of the identified abstract (a commercial interaction, “steps for verifying information of a user). The training a first model based on determining first training data and the training of the second model based on second training data, are additional elements that are recited at a high level of generality, being used as a tool to implement the steps of the identified abstract idea, see MPEP 2106.05(f). Also see the section 101 rejection below. The rejection is maintained. Applicant argues#2 Without conceding propriety of the asserted combination, Smith and Durvasula do not render claim 1 unpatentable. However, the combination of Smith and Durvasula does not teach or suggest at least "receiving, at a data verification system, first data representing financial information associated with a user, “determining first training data based at least in part on financial data associated with users, “training a first model based at least in part on the first training data, “identifying, based at least in part on the first data, one or more information types associated with the financial information, “verifying the financial information using the first model, wherein the first model is configured to verify information associated with the one or more information types, “applying one or more transformations to the first data to generate second data, wherein the second data includes at least a portion of the financial information and indicates an individual information type from the one or more information types, “storing the second data, wherein the second data is associated with a digital user passport and indicates that the financial information has been verified, “receiving a request from a third-party for the individual information type, “determining second training data based at least in part on filter data associated with users, “training a second model based at least in part on the second training data," and "generating, responsive to the request from the third-party including the individual information type and using the second model, wherein the second model is configured to associate requests with the financial information, a representation of the second data," as amended claim 1 recites. For at least the reasons presented herein, claim 1 would not have been obvious in view of Smith and Durvasula. Accordingly, Applicant respectfully requests that the Office withdraw the § 103 rejection of claim 1. Dependent Claims 2, 3, and 5-7 Claims 2, 3, and 5-7 ultimately depend from independent claim 1. As discussed above, claim 1 is allowable over the cited documents. Therefore, claims 2, 3, and 5-7 are allowable over the cited documents of record for at least their dependency from an allowable base claim, and also for the additional features that each recites. Accordingly, Applicant respectfully requests that the Office withdraw the § 103 rejection of claims 2, 3, and 5-7. Independent Claim 8 Claim 8, as amended herein, recites, in part (added language underlined): receiving, at a data verification system, first data representing financial information associated with a user; determining first training data based at least in part on financial data associated with users; training a first model based at least in part on the first training data; identifying, based at least in part on the first data, one or more information types associated with the financial information; verifying the financial information using the first model, wherein the first model is configured to verify information associated with the one or more information types; applying one or more transformations to the first data to generate second data, wherein the second data includes at least a portion of the financial information and indicates an individual information type from the one or more information types; storing the second data, wherein the second data is associated with a digital user passport and indicates that the financial information has been verified; receiving a request from a third-party for the individual information type; determining second training data based at least in part on filter data associated with users; training a second model based at least in part on the second training data; and generating, responsive to the request from the third-party including the individual information type and using the second model, wherein the second model is configured to associate requests with the financial information, a representation of the second data. The combination of Smith and Durvasula is described about with respect to independent claim 1. For at least reasons similar to those presented above with respect to claim 1, the combination of Smith and Durvasula does not teach or suggest at least "receiving, at a data verification system, first data representing financial information associated with a user," "determining first training data based at least in part on financial data associated with users," "training a first model based at least in part on the first training data," "identifying, based at least in part on the first data, one or more information types associated with the financial information," "verifying the financial information using the first model, wherein the first model is configured to verify information associated with the one or more information types," "applying one or more transformations to the first data to generate second data, wherein the second data includes at least a portion of the financial information and indicates an individual information type from the one or more information types," "storing the second data, wherein the second data is associated with a digital user passport and indicates that the financial information has been verified," "receiving a request from a third-party for the individual information type," "determining second training data based at least in part on filter data associated with users," "training a second model based at least in part on the second training data," and "generating, responsive to the request from the third-party including the individual information type and using the second model, wherein the second model is configured to associate requests with the financial information, a representation of the second data," as amended claim 8 recites. For at least the reasons presented herein, claim 8 would not have been obvious in view of Smith and Durvasula. Accordingly, Applicant respectfully requests that the Office withdraw the § 103 rejection of claim 8. Dependent Claims 9, 10, and 12-14 Claims 9, 10, and 12-14 ultimately depend from independent claim 8. As discussed above, claim 8 is allowable over the cited documents. Therefore, claims 9, 10, and 12-14 are allowable over the cited documents of record for at least their dependency from an allowable base claim, and also for the additional features that each recites. Accordingly, Applicant respectfully requests that the Office withdraw the § 103 rejection of claims 9, 10, and 12-14. Independent Claim 15 Claim 15, as amended herein, recites, in part (added language underlined): receiving, at a data verification system, first data representing financial information associated with a user; determining first training data based at least in part on financial data associated with users; training a first model based at least in part on the first training data; identifying, based at least in part on the first data, one or more information types associated with the financial information; verifying the financial information using the first model, wherein the first model is configured to verify information associated with the one or more information types; applying one or more transformations to the first data to generate second data, wherein the second data includes at least a portion of the financial information and indicates an individual information type from the one or more information types; storing the second data, wherein the second data is associated with a digital user passport and indicates that the financial information has been verified; receiving a request from a third-party for the individual information type; determining second training data based at least in part on filter data associated with users; training a second model based at least in part on the second training data; and generating, responsive to the request from the third-party including the individual information type and using the second model, wherein the second model is configured to associate requests with the financial information, a representation of the second data. The combination of Smith and Durvasula is described about with respect to independent claim 1. For at least reasons similar to those presented above with respect to claim 1, the combination of Smith and Durvasula does not teach or suggest at least "receiving, at a data verification system, first data representing financial information associated with a user," "determining first training data based at least in part on financial data associated with users," "training a first model based at least in part on the first training data," "identifying, based at least in part on the first data, one or more information types associated with the financial information," "verifying the financial information using the first model, wherein the first model is configured to verify information associated with the one or more information types," "applying one or more transformations to the first data to generate second data, wherein the second data includes at least a portion of the financial information and indicates an individual information type from the one or more information types," "storing the second data, wherein the second data is associated with a digital user passport and indicates that the financial information has been verified," "receiving a request from a third-party for the individual information type," "determining second training data based at least in part on filter data associated with users," "training a second model based at least in part on the second training data," and "generating, responsive to the request from the third-party including the indiviudal information type and using the second model, wherein the second model is configured to associate requests with the financial information, a representation of the second data," as amended claim 15 recites. For at least the reasons presented herein, claim 15 would not have been obvious in view of Smith and Durvasula. Accordingly, Applicant respectfully requests that the Office withdraw the § 103 rejection of claim 15. Dependent Claims 16, 17, 19, and 20 Claims 16, 17, 19, and 20 ultimately depend from independent claim 15. As discussed above, claim 15 is allowable over the cited documents. Therefore, claims 16, 17, 19, and 20 are allowable over the cited documents of record for at least their dependency from an allowable base claim, and also for the additional features that each recites. Accordingly, Applicant respectfully requests that the Office withdraw the § 103 rejection of claims 16, 17, 19, and 20. Claims 4, 11, and 18 Would Not Have Been Obvious over Smith in View of Durvasula and Further in View of Pead Claims 4, 11, and 18 stand rejected under 35 U.S.C. § 103 as allegedly being obvious over a combination of Smith in view of Durvasula and further in view of Pead. Applicant respectfully traverses the rejection. Dependent Claims 4, 11, and 18 Claims 4, 11, and 18 ultimately depend from independent claims 1, 8, and 15. As discussed above, claims 1, 8, and 15 are allowable over the combination of Smith and Durvasula. The Office cites Pead as allegedly teaching the respective features of dependent claims 4, 11, and 18. Without conceding the propriety of the combination of Smith, Durvasula and Pead, the combination fails to teach or suggest one or more features of independent claims 1, 8, and 15. Therefore, claims 4, 11, and 18 are allowable over the cited documents of record for at least their dependency from an allowable base claim, and also for the additional features that each recites. Accordingly, Applicant respectfully requests that the Office withdraw the § 103 rejection of claims 4, 11, and 18. Examiner Response Based on the amendments to the claims, a new ground of rejection is provided, see the section 103 rejection below. Claim Rejections- 35 U.S.C § 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. 1. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claims 1, 8, 15 are directed to a system, method and computer readable medium which are statutory categories of invention. (Step 1: YES). Representative claim 8 recites the limitations of: A system comprising: one or more processors; and one or more computer-readable media storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: receiving, at a data verification system, first data representing financial information associated with a user; determining first training data based at least in part on financial data associated with users; training a first model based at least in part on the first training data; identifying, based at least in part on the first data, one or more information types associated with the financial information; verifying the financial information using the first model, wherein the first model is configured to verify information associated with the one or more information types; applying one or more transformations to the first data to generate second data, wherein the second data includes at least a portion of the financial information and indicates an individual information type from the one or more information types; storing the second data, wherein the second data is associated with a digital user passport and indicates that the financial information has been verified; receiving a request from a third party for the individual information type; and determining second training data based at least in part on filter data associated with users; training a second model based at least in part on the second training data; and generating, responsive to the request from the third party including the individual information type and using the second model, wherein the second model is configured to associate requests with the financial information, a representation of the second data. These limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of organizing human activity. The claim recites elements that are in bold above, which covers performance of the limitation as a commercial interaction, steps for verifying financial information of a user (e.g., receiving, first data representing financial information associated with a user; identifying, based at least in part on the first data, one or more information types associated with the financial information; verifying the financial information to verify information associated with the one or more information types; applying one or more transformations to the first data to generate second data, wherein the second data includes at least a portion of the financial information and indicates an individual information type from the one or more information types; storing the second data, and indicates that the financial information has been verified; receiving a request from a third party for the individual information type; generating, responsive to the request from the third party including the individual information type and a representation of the second data.) If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a Commercial Interaction, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Claims 1,15 are abstract for similar reasons. (Step 2A-Prong 1: YES. The claims are abstract). This judicial exception is not integrated into a practical application. Limitations that are not indicative of integration into a practical application include: (1) Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05.f), (2) Adding insignificant extra solution activity to the judicial exception (MPEP 2106.05.g), (3) Generally linking the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05.h). Claims 1, 8, 15 includes the following additional elements: -One or more processors -A data verification system -A first model -A second model -The training a first model based on determining first training data and the training of the second model based on second training data - One or more non-transitory computer readable media The one or more processors, data verification system, first model, second model, the training a first model based on determining first training data and the training of the second model based on second training data and one or more non-transitory computer readable media are recited at a high level of generality and are being used in their ordinary capacity and are being used as a tool for implementing the steps of the identified abstract idea, see MPEP 2106.05(f), where applying a computer or using a computer as a tool to perform the abstract idea is not indicative of a practical application. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea Therefore claims 1, 8, 15 are directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application) The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, there are no additional elements recited in the claim beyond the judicial exception. Mere instructions to implement an abstract idea, on or with the use of generic computer components, or even without any computer components, cannot provide an inventive concept - rendering the claim patent ineligible. Thus claims 1,8, 15 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more) Dependent claims 2-7, 9-14, 16-20 further define the abstract idea that is present in their respective independent claims 1,8, 15 and thus correspond to Certain Methods of Organizing Human Activity and hence are abstract for the reasons presented above. Claims 2, 9, 16 further defines the identified abstract idea as recited in claims 1,8,15. The additional element of the block being part of one more multiple blocks of a blockchain are recited a high level of generality, operating in their ordinary capacity, and are being used as a tool to implement the steps of the identified abstract idea, see MPEP 2106.05(f) Therefore, the dependent claims do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Therefore, the dependent claims (2-7, 9-14, 16-20) are directed to an abstract idea. Thus, the claims 1-20 are not patent-eligible. Claim Rejections- 35 U.S.C § 103 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. 2. Claims 1-3, 5-10, 12-17, 19-20 are being rejected under 35 U.S.C. 103(a) as being unpatentable over US 2017/0004573 to Hussain in view of US 2024/0428229 to Durvasula et al, herein Durvasula. Regarding claim 1, Hussain discloses: A method comprising: receiving, at a data verification system, first data representing financial information associated with a user (At least: [0013]: [0013] The system may, at this point, obtain a set of internal data associated with the user. The set of internal data may include details stored with this system about previous transactions by the user, such as types of previous purchases, amounts of purchases, payment history, and so on. In some cases, internal data may include geographic and demographic data. In some implementations, the set of internal data includes specific details about one or more previous transactions, while in other implementations the specific details of one or more previous transactions are aggregated into a summary of attributes (e.g., has the user paid before, and if so, when did the user pay, what was the average payment, has the user previously been late with payment, did user pay debt off early, does the user only pay the minimum payment or less or more than the minimum payment, etc.), while, in still other implementations, the specific details are processed (e.g., by a neural network, by a vector machine (relevance or support), by a random forest, or some other supervised learning algorithm) to yield an internal data score, which may be used in part to generate a fidelity score, described below. determining first training data based at least in part on financial data associated with users (At least: [0013], [0035]: [0035] The model 204 may include a combination of hardware and software configured to output a risk assessment based on one or more of the internal data 206, the verification data 208, and the behavioral data 210. An advantage provided by the model 204 is that transactions can be processed and finalized more quickly, because an online transaction system may rely on a risk assessment generated by the model 204 without having to request a credit check of the user 244 by a third party entity, such as a credit bureau. Furthermore, because some credit bureau services charge a fee for credit checking services, cost savings may be achieved by relying on the risk assessment of the model 204. The risk engine 234 may be further configured to update/retrain the model 204 based on the collected data (e.g., client data, details about the transaction, etc.) by associating the collected data in a data store with payments by the user 244 as they are received in a timely, or, as the case may be, in a not so timely fashion from the user, and regenerating the logistic regression or retraining the neural network, vector machine, random forest, or other supervised learning algorithm upon which the model 204 is based. training a first model based at least in part on the first training data (At least: [0013], [0035], [0047] [0035] The model 204 may include a combination of hardware and software configured to output a risk assessment based on one or more of the internal data 206, the verification data 208, and the behavioral data 210. An advantage provided by the model 204 is that transactions can be processed and finalized more quickly, because an online transaction system may rely on a risk assessment generated by the model 204 without having to request a credit check of the user 244 by a third party entity, such as a credit bureau. Furthermore, because some credit bureau services charge a fee for credit checking services, cost savings may be achieved by relying on the risk assessment of the model 204. The risk engine 234 may be further configured to update/retrain the model 204 based on the collected data (e.g., client data, details about the transaction, etc.) by associating the collected data in a data store with payments by the user 244 as they are received in a timely, or, as the case may be, in a not so timely fashion from the user, and regenerating the logistic regression or retraining the neural network, vector machine, random forest, or other supervised learning algorithm upon which the model 204 is based. [0047] FIG. 3 illustrates a couple of scenarios 300 from an embodiment of the present disclosure. Specifically, FIG. 3 depicts a first user 344A and a second user 344B at a checkout stage of separate transactions. As can be seen, client data for the first user 344A is transmitted to the rules engine 302 of the system of the present disclosure. As noted, the client data may include personally identifiable information and data reflecting interactions of the first user 344A with the user interfaces during the course of conducting the transaction being finalized. The rules engine 302 determines whether, based on the client data received, any rules exist that would preempt risk processing of the first user 344A by the model 304. If not, the client data of the first user 344A is passed to the model 304. Based on the client data, internal data 306A, verification data 308A, behavioral data 310A are obtained or generated by the model 304 and processed to yield a first risk assessment 312A. Note that there are various methods by which the internal data 306A, the verification data 308A, and the behavioral data 310A may be processed. In one example, the internal data 306A, may be used to generate an internal data score based on details about previous transactions conducted by the user 344A. Similarly, the verification data 308A may be used to generate a verification data score indicating a confidence level with the accuracy of information provided by the user 344A. Likewise, the behavioral data 310A may be used to generate a behavioral data score reflecting a level of intent to pay by the user 344A. Each of these three scores may be weighted and/or fed into a risk algorithm, random forest, regression model, neural network, vector machine, other supervised learning algorithm to yield the risk assessment 312A. Alternatively, the internal data 306A, the verification data 308A, and the behavioral data 310A may be processed to yield a set of variables. An example of the set of variables, may be something like: “time_spent_reading_overall_terms=15,” “time_spent_reading_default_terms=1,” “browser=IE,” “browser_version=10.0,” “time_between_clickdown_submit_and_clickrelease=3,” “transaction_amount=308.00,” “current_debt=0,” “transactions_last 5 months=3,” “last_transaction_payment_method=credit,” “paid_in_full=yes,” “last_transaction_amount=12.99,” “verified_address=yes,” “address_matches_last_transaction_address=yes,” “verified_full_name=yes,” “verified_email=yes,” “verified_phone_number=no,” and so on. The set of variables themselves may be weighted and/or fed into a risk algorithm, random forest, regression model, neural network, vector machine, other supervised learning algorithm to yield the risk assessment 312A. identifying, based at least in part on the first data, one or more information types associated with the financial information (At least: [0036]: [0036] The internal data 206 used by the model 204 may include, if the user is a returning user, details about previous transactions, such as addresses used in previous transactions, purchase amounts of previous transactions, methods of payment used in previous transactions, whether the user paid more or less than the minimum payment, whether the user accrued any late fees, whether any funds are still owed on previous transactions, and so on. If the user 244 is a new user rather than a returning user, this lack of a purchase history for the user 244 is itself internal data 206 that may be taken into consideration by the model 204. In some implementations, the user 244 is determined to be a new user if the user 244 creates a new account/user profile with the merchant or payment services provider involved in the transaction. In other implementations, the determination that the user 244 is a new user is made by a record matching service of the type described in U.S. patent application Ser. No. 14/820,468, U.S. patent application Ser. No. 14/830,686, and U.S. patent application Ser. No. 14/830,690, incorporated herein by reference. In still other implementations, a determination that the user 244 is a new user is made by determining that there is not a match between personally identifiable information provided by the user 244 and records in the internal data 206. In the latter implementations, a user profile is created for a new user, and if the user 244 conducts transactions in the future, details of the future transactions may be stored in a data store hosting the internal data 206. verifying the financial information using [[a]]the first model, wherein the first model is configured to verify information associated with the one or more information types (At least: [0035], [0047]: [0047] FIG. 3 illustrates a couple of scenarios 300 from an embodiment of the present disclosure. Specifically, FIG. 3 depicts a first user 344A and a second user 344B at a checkout stage of separate transactions. As can be seen, client data for the first user 344A is transmitted to the rules engine 302 of the system of the present disclosure. As noted, the client data may include personally identifiable information and data reflecting interactions of the first user 344A with the user interfaces during the course of conducting the transaction being finalized. The rules engine 302 determines whether, based on the client data received, any rules exist that would preempt risk processing of the first user 344A by the model 304. If not, the client data of the first user 344A is passed to the model 304. Based on the client data, internal data 306A, verification data 308A, behavioral data 310A are obtained or generated by the model 304 and processed to yield a first risk assessment 312A. Note that there are various methods by which the internal data 306A, the verification data 308A, and the behavioral data 310A may be processed. In one example, the internal data 306A, may be used to generate an internal data score based on details about previous transactions conducted by the user 344A. Similarly, the verification data 308A may be used to generate a verification data score indicating a confidence level with the accuracy of information provided by the user 344A. Likewise, the behavioral data 310A may be used to generate a behavioral data score reflecting a level of intent to pay by the user 344A. Each of these three scores may be weighted and/or fed into a risk algorithm, random forest, regression model, neural network, vector machine, other supervised learning algorithm to yield the risk assessment 312A. Alternatively, the internal data 306A, the verification data 308A, and the behavioral data 310A may be processed to yield a set of variables. An example of the set of variables, may be something like: “time_spent_reading_overall_terms=15,” “time_spent_reading_default_terms=1,” “browser=IE,” “browser_version=10.0,” “time_between_clickdown_submit_and_clickrelease=3,” “transaction_amount=308.00,” “current_debt=0,” “transactions_last 5 months=3,” “last_transaction_payment_method=credit,” “paid_in_full=yes,” “last_transaction_amount=12.99,” “verified_address=yes,” “address_matches_last_transaction_address=yes,” “verified_full_name=yes,” “verified_email=yes,” “verified_phone_number=no,” and so on. The set of variables themselves may be weighted and/or fed into a risk algorithm, random forest, regression model, neural network, vector machine, other supervised learning algorithm to yield the risk assessment 312A. applying one or more transformations to the first data to generate second data, wherein the second data includes at least a portion of the financial information and indicates an individual information type from the one or more information types (At least: [0067]: [0067] In 708, the system performing the process 700 may determine whether additional data is available. For example, if a previous attempt to generate a fidelity score was made, and, per a determination such as the determination made via the operations of 508 of FIG. 5, the available behavioral data, verification data, and internal data was insufficient to generate a reliable fidelity score, the system of the present disclosure may have made a call to an external data source, such as a credit bureau, to obtain additional information. Thus, if such additional information is available, the system performing the process 700 may proceed to 710, whereupon the additional data is transformed into one or more variables having corresponding values. An example of such a variable may be credit_score. Hussain discloses storing the second data in a data store (At least: [0038]). Hussain does not disclose Durvasula in the same field of endeavor discloses: storing the second data, wherein the second data is associated with a digital user passport and indicates that the financial information has been verified (At least: [0019], [0020], [0040]); [0020] In yet another variation of this embodiment, the method further comprises: aggregating, by the one or more processors, security data from one or more data sources that are external to the digital wallet application, the aggregated security data being associated with one or more electronic accounts of the set of electronic accounts; updating, by the one or more processors, a set of security data that is stored as part of the digital wallet application based on the aggregated security data; generating, by the at least one ML model, a security recommendation for the user based on the updated set of security data, wherein the security recommendation indicates at least one of the one or more electronic accounts represented in the aggregated security data; causing, by the one or more processors, a user interface to display the security recommendation for analysis by the user; receiving, from the user, an input related to the security recommendation; and modifying, by the one or more processors, a security operation of the at least one of the one or more electronic accounts represented in the aggregated security data based on the user input. [0040] For example, a digital wallet application can utilize a linking application that can enable a user to securely connect external electronic accounts or applications to the digital wallet application. For example, for an external electronic account or application, a user can provide login credentials, and the linking application can securely retrieve data for the external electronic account or application. The linking application can employ cybersecurity measures to protect the user's login credentials and authorize data retrieval related to the external account or application. For example, the linking application can use an industry-standard authorization protocol, such as Open Authorization (OAuth), to securely authenticate a user. When a user links an external account or application, the linking application can send the login credentials to a server associated with the external account or application to authenticate and authorize the connection. The linking application can receive, from the server, an access token that can be used to access external account or application data pertaining to the user. The linking application can use one or more application programming interfaces (APIs) to retrieve data for an external account or application that has API integration. For example, the linking application can use a unified API that supports various programming languages and provides endpoints for enabling external account or application linking. One example of an API is a RESTful API, where REST refers to Representational State Transfer. A RESTful API is stateless, meaning that each request received by a server from a client contains all necessary information for the server to process the request and the server does not maintain a state of the client. The linking application can implement additional security features, such as data encryption, data tokenization, MFA, etc. The linking application can process data into a unified or normalized data format for each external account or application. One example of a unified data format is JSON. Therefore it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Hussain’s invention to include storing the second data, wherein the second data is associated with a digital user passport and indicates that the financial information has been verified in order to ensure that the security of the transaction is maintained (Durvasula: [0040]). Hussain further discloses: receiving a request from a third-party for the individual information type (At least: [0067]: [0067] In 708, the system performing the process 700 may determine whether additional data is available. For example, if a previous attempt to generate a fidelity score was made, and, per a determination such as the determination made via the operations of 508 of FIG. 5, the available behavioral data, verification data, and internal data was insufficient to generate a reliable fidelity score, the system of the present disclosure may have made a call to an external data source, such as a credit bureau, to obtain additional information. determining second training data based at least in part on filter data associated with users (At least: [0068], [0070]); [0068] In 712, the various variables and their corresponding values generated in steps 702-10 may be passed through a data model. It is contemplated that the data model may be any of various types of data models, such as a random forest generated from a large data set of similar data, neural network, vector machine, other supervised learning algorithm, or some other regression model generated from a sample set representative of typical user data for conducting transactions in the manner described in the present disclosure. The output of the model may be indicative of a risk of default on payment by the present user. Upon generating the output, in 714, the output may be provided to the merchant, some other entity, or to an internal process for determining which payment and credit options to present to the user in an interface, such as a checkout-type interface. [0070] In some embodiments, the system of the present disclosure is configured as a service that provides the fidelity score, and, in some cases, as the statistical certainty value based on internal data, verification data, and client data provided by a subscriber to the service. For example, the service may be offered to subscribers as a faster and cheaper alternative for obtaining credit risk data than traditional credit bureau services. In some embodiments, the system of the present disclosure is configured to update a checkout page with items other than payment and credit options, or may be configured to update one or more webpages with information different than payment and credit options but based on collected client data. For example, if the client data (i.e., personally identifiable information and behavioral data) suggests that the user is within a certain demographic, such as age group, the system of the present disclosure may present product offers believed to be of interest to such an age group, such as clothing of certain styles and so on. As another example, if the client data suggests that the user is within a certain age group or participates in certain high risk activities (such as conducting transactions while in a moving vehicle), this information may be usable by the system in determining insurance premiums, loan interest rates, whether to offer an option for a reverse mortgage, and so on. training a second model based at least in part on the second training data (At least: [0068]: [0068] In 712, the various variables and their corresponding values generated in steps 702-10 may be passed through a data model. It is contemplated that the data model may be any of various types of data models, such as a random forest generated from a large data set of similar data, neural network, vector machine, other supervised learning algorithm, or some other regression model generated from a sample set representative of typical user data for conducting transactions in the manner described in the present disclosure. The output of the model may be indicative of a risk of default on payment by the present user. Upon generating the output, in 714, the output may be provided to the merchant, some other entity, or to an internal process for determining which payment and credit options to present to the user in an interface, such as a checkout-type interface. and generating, responsive to the request from the third party including the individual information type and using the second model, wherein the second model is configured to associate requests with the financial information, a representation of the second data (At least: [0067], [0068] [0067] In 708, the system performing the process 700 may determine whether additional data is available. For example, if a previous attempt to generate a fidelity score was made, and, per a determination such as the determination made via the operations of 508 of FIG. 5, the available behavioral data, verification data, and internal data was insufficient to generate a reliable fidelity score, the system of the present disclosure may have made a call to an external data source, such as a credit bureau, to obtain additional information. Thus, if such additional information is available, the system performing the process 700 may proceed to 710, whereupon the additional data is transformed into one or more variables having corresponding values. An example of such a variable may be credit_score. Regarding claim 2, Hussain and Durvasula disclose the method of claim 1. Hussain further discloses further comprising: receiving a threshold associated with the financial information that is to be shared (AT least: [0056]). Hussain does not disclose, Durvasula discloses: storing the threshold with a block associated with the financial information, wherein the block is one of multiple blocks of a blockchain (At least: [0034]); and based at least in part on the threshold stored with the block, generating the representation of the second data in accordance with the threshold (At least: 0034]). Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Hussain’s invention to include storing the threshold with a block associated with the financial information, wherein the block is one of multiple blocks of a blockchain; and based at least in part on the threshold stored with the block, generating the representation of the second data in accordance with the threshold in order to ensure that digital wallets and linked electronic accounts, may be improved or enhanced with the disclosed techniques for implementing digital wallet applications supporting decentralized web integration (Durvasula: [0024]). Claims 9,16 are being rejected using the same rationale as claim 2. Regarding claim 3, Hussain and Durvasula discloses the method of claim 2. Hussain further discloses wherein the threshold includes at least one of: a quantity of the financial information that is to be shared (At least:[0017]); a threshold amount of time for sharing the financial information; or one or more individual information types associated with the financial information. Claims 10,17 are being rejected using the same rationale as claim 3. Regarding claim 5, Hussain and Durvasula disclose the method of claim 1. Hussain further discloses wherein the financial information associated with the user includes at least one of: a time at which the financial information was received by the data verification system; an identity of the user; an income associated with the user; banking information associated with the user (At least: [0045] ; employment history associated with the user; or rental history associated with the user. Claim 12 is being rejected using the same rationale as claim 5. Regarding claim 6, Hussain and Durvasula discloses the method of claim 1. Hussain further discloses wherein the financial information is included in a document, the method further comprising: identifying an indication included in the document of the user, wherein the indication at least partially includes verifying information associated with the financial information (At least: [0070]; and verifying the financial information associated with the user is based at least in part on the indication (At least: [0070]). Claims 13,19 are being rejected using the same rationale as claim 6. Regarding claim 7, Hussain and Durvasula discloses the method of claim 1. Hussain further discloses wherein the request is first request, the portion of financial information is a first portion of financial information, and the individual information type is a first individual information type (At least :[0036], [0045]) the method further comprising: based at least in part on the one or more transformations to the first data, generating third data, wherein the third data includes at least a second portion of the financial information and indicates a second individual information type from the one or more information types (At least: [0036], [0045]). Hussain does not disclose, Durvasula discloses: storing the third data, wherein the third data is associated with the digital user passport and indicates that the financial information has been verified (At least: [0025], [0044], [0105], [0094]) receiving a second request for the second individual information type; and generating, based at least in part on the second request and the second model configured to associate the requests with the financial information, a representation of the third data (At least: [0025], [0105], [0094]). Therefore it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Hussain’s invention to include storing the third data, wherein the third data is associated with the digital user passport and indicates that the financial information has been verified; receiving a second request for the second individual information type; and generating, based at least in part on the second request and the second model configured to associate the requests with the financial information, a representation of the third data in order to ensure that by leveraging multiple models, include improvements in computer functionality or in improvements to other technologies at least because the disclosure describes such models being trained with a plurality of training data (e.g., 10,000s of training data, etc.) to output recommendations configured to improve a respective user's efforts related to a digital wallet and linked electronic accounts (Durvasula: [0025]). Claims 14,20 are being rejected using the same rationale as claim 7. Regarding claim 8, Hussain discloses: A system comprising: one or more processors; and one or more computer-readable media storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising (At least: [0008], [0034], [0035], [0037]; receiving, at a data verification system, first data representing financial information associated with a user (At least: [0013]); determining first training data based at least in part on financial data associated with users (At least: [0013], [0035]); training a first model based at least in part on the first training data (At least: [0013], [0035], [0047]); identifying, based at least in part on the first data, one or more information types associated with the financial information (At least: [0036]); verifying the financial information using [[a]]the first model, wherein the first model is configured to verify information associated with the one or more information types (At least: [0035], [0047]); applying one or more transformations to the first data to generate second data, wherein the second data includes at least a portion of the financial information and indicates an individual information type from the one or more information types (At least: [0067]). Hussain discloses storing the second data in a data store (At least: [0038]). Hussain does not disclose Durvasula in the same field of endeavor discloses: storing the second data, wherein the second data is associated with a digital user passport and indicates that the financial information has been verified (At least: [0019], [0020], [0040]). Therefore it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Hussain’s invention to include storing the second data, wherein the second data is associated with a digital user passport and indicates that the financial information has been verified in order to ensure that the security of the transaction is maintained (Durvasula: [0040]). Hussain further discloses: receiving a request from a third-party for the individual information type (At least: [0067]); determining second training data based at least in part on filter data associated with users (At least: [0068], [0070]); training a second model based at least in part on the second training data (At least: [0068]); and generating, responsive to the request from the third party including the individual information type and using the second model, wherein the second model is configured to associate requests with the financial information, a representation of the second data (At least: [0067], [0068]). Regarding claim 15, Hussain discloses: A non-transitory computer-readable medium storing having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to perform operations comprising (At least: [0008], [0025], [0034]); receiving, at a data verification system, first data representing financial information associated with a user (At least: [0013]); determining first training data based at least in part on financial data associated with users (At least: [0013], [0035]); training a first model based at least in part on the first training data (At least: [0013], [0035], [0047]); identifying, based at least in part on the first data, one or more information types associated with the financial information (At least: [0036]); verifying the financial information using [[a]]the first model, wherein the first model is configured to verify information associated with the one or more information types (At least: [0035], [0047]); applying one or more transformations to the first data to generate second data, wherein the second data includes at least a portion of the financial information and indicates an individual information type from the one or more information types (At least: [0067]). Hussain discloses storing the second data in a data store (At least: [0038]). Hussain does not disclose Durvasula in the same field of endeavor discloses: storing the second data, wherein the second data is associated with a digital user passport and indicates that the financial information has been verified (At least: [0019], [0020], [0040]). Therefore it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Hussain’s invention to include storing the second data, wherein the second data is associated with a digital user passport and indicates that the financial information has been verified in order to ensure that the security of the transaction is maintained (Durvasula: [0040]). Hussain further discloses: receiving a request from a third-party for the individual information type (At least: [0067]); determining second training data based at least in part on filter data associated with users (At least: [0068], [0070]); training a second model based at least in part on the second training data (At least: [0068]); and generating, responsive to the request from the third party including the individual information type and using the second model, wherein the second model is configured to associate requests with the financial information, a representation of the second data (At least: [0067], [0068]). 4. Claims 4,11,18 are being rejected under 35 U.S.C 103(a) as being unpatentable over Hussain and Durvasula and further in view of US 2018/0144153 to Pead. Regarding claim 4, Hussain and Durvasula disclose the method of claim 1. Hussain does not disclose, Pead in the same field of endeavor discloses, identifying a user browsing pattern, the user browsing pattern indicating a context associated with the individual information type, wherein, generating the representation of the second data is based at least in part on the context associated with the individual information type. (At least: [0043], [0026]). Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Hussain’s invention to include identifying a user browsing pattern, the user browsing pattern indicating a context associated with the individual information type, wherein, generating the representation of the second data is based at least in part on the context associated with the individual information type in order to ensure that when digital verifiable information is shared, the individuals control the sharing (Pead: [0006]). Claims 11,18 are being rejected using the same rationale as claim 4, as they fail to cure the deficiency of claim 4. CONCLUSION Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 MOHAMMAD Z SHAIKH whose telephone number is (571)270-3444. The examiner can normally be reached M-T, 9-600; Fri, 8-11, 3-5. 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, BENNETT SIGMOND can be reached at 303-297-4411. 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. /MOHAMMAD Z SHAIKH/Primary Examiner, Art Unit 3694 2/17/2026
Read full office action

Prosecution Timeline

May 16, 2024
Application Filed
Sep 18, 2025
Non-Final Rejection — §101, §103
Dec 02, 2025
Interview Requested
Dec 15, 2025
Applicant Interview (Telephonic)
Dec 15, 2025
Examiner Interview Summary
Dec 22, 2025
Response Filed
Feb 21, 2026
Final Rejection — §101, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12602729
SYSTEMS AND METHODS FOR BUILDING, UTILIZING, AND/OR MAINTAINING AN AUTONOMOUS VEHICLE-RELATED EVENT DISTRIBUTED LED
2y 5m to grant Granted Apr 14, 2026
Patent 12586074
MODEL UTILIZATION SYSTEM, MODEL UTILIZATION METHOD, AND COMPUTER PROGRAM PRODUCT
2y 5m to grant Granted Mar 24, 2026
Patent 12579537
DIGITAL WALLET BALANCE DISPLAY IN AN ELECTRONIC DEVICE
2y 5m to grant Granted Mar 17, 2026
Patent 12547991
SYSTEMS, METHODS, AND APPARATUS FOR CONSOLIDATING A SET OF LOANS
2y 5m to grant Granted Feb 10, 2026
Patent 12548084
INDIVIDUALIZED REAL-TIME USER INTERFACE FOR EVENTS
2y 5m to grant Granted Feb 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
52%
Grant Probability
84%
With Interview (+31.3%)
3y 6m
Median Time to Grant
Moderate
PTA Risk
Based on 544 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month