DETAILED ACTION
Status of Application
This action is a Non-Final Rejection. This action is in response to the application filed on December 20, 2024.
Claims 1-20 have been canceled.
Claims 21-40 have been added.
Claims 21-40 are pending and rejected.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . 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 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.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. Applicant has not complied with one or more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 120 as follows:
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosure of the prior-filed applications, Application Nos. 18/477.883 and 18/631,998 fail to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. For example, the instant claims appear to be based on Figure 7. However, the embodiment of Figure 7 does not include performing a custom risk assessment based on the completed user data fields, the verification, and the completed data fields. Additionally, the dependent claims are not supported by the Specification. For example, the Specification does not refer to demographic data or a user information verification page (claim 22); public business data elements or public business data source (claim 23); demographic data rules or metadata (claim 24); or negative custom risk assessment (claim 26). These are not exhaustive examples of claim limitations that are not disclosed in the Specification/priority applications.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on November 6, 2025 and January 20, 2026 have been considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Does the Claim Fall within a Statutory Category? (see MPEP 2106.03)
Yes, with respect to claims 21-27, which recite a system and, therefore, are directed to the statutory class of machine or manufacture.
Yes, with respect to claims 28-34, which recite a non-transitory computer readable medium and, therefore, are directed to the statutory class of manufacture.
Yes, with respect to claims 35-40, which recite a method and, therefore, are directed to the statutory class of process.
Step 2A, Prong One: Is a Judicial Exception Recited? (see MPEP 2106.04(a))
The following claims (Claims 21-27 are representative) identify the limitations that recite the abstract idea in regular text and that recite additional elements in bold:
21. A system comprising:
a memory storing a set of instructions; and
a processor configured to execute the set of instructions to perform operations including:
generating a custom risk assessment validation request form associated with a user, the custom risk assessment validation request form including a plurality of user data fields;
retrieving one or more stored user information fields associated with the custom risk assessment validation request form from a database;
completing one or more of the plurality of user data fields based on the one or more stored user information fields to create completed user data fields;
providing, over a network, the custom risk assessment validation request form and the completed user data fields to a user device associated with the user via a graphical user interface;
requesting verification by the user of the one or more completed user data fields through the graphical user interface;
requesting completion by the user of one or more of the plurality of user data fields;
receiving one or more completed data fields in response to the request for completion, the one or more completed data fields corresponding to a different set of the plurality of user data fields than the one or more completed user data fields; and
performing a custom risk assessment based on the completed user data fields, the verification, and the completed data fields.
22. The system of claim 21, wherein the instructions further include:
sending a user information verification page for display through the graphical user interface, the user information verification page configured to request one or more user demographic fields;
receiving, based on the request, responsive user demographic data associated with the one or more user demographic fields;
retrieving one or more stored user demographic data elements associated with the one or more user demographic fields from the database; and
verifying the responsive user demographic data against the one or more stored user demographic data elements.
23. The system of claim 22, wherein the instructions further include:
retrieving one or more public business data elements from a public business data source; and
verifying the responsive user demographic data against the one or more public business data elements.
24. The system of claim 22, wherein the instructions further include:
retrieving one or more user demographic data rules; and
verifying one or more metadata elements associated with the responsive user demographic data against the one or more user demographic data rules.
25. The system of claim 21, wherein performing the custom risk assessment includes determining a risk rating based on the completed user data fields, the verification, and the one or more completed data fields.
26. The system of claim 25, wherein the risk rating is a high risk rating and the custom risk assessment is a negative custom risk assessment based on the high risk rating.
27. The system of claim 21, wherein the operations further include:
comparing the one or more completed data fields to a high-risk information dataset.
Yes. But for the recited additional elements as shown above in bold, the remaining limitations of the claims recite certain methods of organizing human activity. The claims are directed to generating and completing a form for risk assessment. This type of method of organizing human activity is a fundamental economic practice because it includes mitigating risk, a commercial interaction such as agreements in the form of contracts, legal obligations, sales activities or behaviors, and business relations, and managing personal behavior or relationships or interactions between people such as following rules or instructions. Thus, the claims recite an abstract idea.
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application? (see MPEP 2106.04(d))
No. The claims as a whole merely use a computer as a tool to perform the abstract idea. The computing components (i.e., additional elements that are in bold above) are recited at a high level of generality and are merely invoked as a tool to implement the steps. For example, only a programmed general purpose computing device (i.e., claimed processor) is needed to implement the claimed process. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Additionally, there is no improvement to the functioning of a computer or technology. Therefore, the abstract idea is not integrated into a practical application.
Step 2B: Does the Claim Provide an Inventive Concept? (see MPEP 2106.05)
No. As discussed with respect to Step 2A, Prong 2, the additional elements in the claims, both individually and in combination, amount to no more than tools to perform the abstract idea. Merely performing the abstract idea using a computer cannot provide an inventive concept. Therefore, the claims do not provide an inventive concept.
As such, the claims are not patent eligible.
Claim Rejections - 35 USC § 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.
Claims 21-40 are rejected under 35 U.S.C. 103 as being unpatentable over Pennington et al., U.S. Patent Application Publication No. 2016/0253303 A1 and deOliveira et al., U.S. Patent Application Publication Number 2015/0339769 A1.
Claim 21:
Pennington teaches:
a memory storing a set of instructions; and a processor configured to execute the set of instructions to perform operations including: (see at least Pennington, Figure 4 and associated text).
generating a custom risk assessment validation request form associated with a user, the custom risk assessment validation request form including a plurality of user data fields (see at least Pennington, Figure 2 and associated text (A form is generated.); paragraph 0020 (“As another example, a bank may provide a digital form to be filled out by a loan applicant to obtain a loan.”); paragraph 0050 (“In Step 224, the captured image and the field metadata, known collectively as the processed form document, are exported or sent to the form completion engine. In some embodiments of Step 224, the processed form document is stored until retrieved by the form completion engine.”)).
retrieving one or more stored user information fields associated with the custom risk assessment validation request form from a database (see at least Pennington, paragraph 0062 (“In Step 306, the form completion engine populates the fields with known user information from the set of user information as stored in the user information data store. The form completion engine accesses, receives, or otherwise acquires at least a portion of the set of user information.”)).
completing one or more of the plurality of user data fields based on the one or more stored user information fields to create completed user data fields (see at least Pennington, paragraph 0062 (“In Step 306, the form completion engine populates the fields with known user information from the set of user information as stored in the user information data store. The form completion engine accesses, receives, or otherwise acquires at least a portion of the set of user information. The field completion engine compares the metadata associated with each item of information in the set of user information and determines similarities. For example, to fill a field with associated field name of “Taxpayer Address,” the form completion engine would search or otherwise analyze the set of taxpayer information for a corresponding or related item of information. If a corresponding or related item of information is located, the form completion engine will enter that item of information into the field.”)).
providing, over a network, the custom risk assessment validation request form and the completed user data fields to a user device associated with the user via a graphical user interface (see at least Pennington, paragraph 0075 (“The user verifies the information in the fields that were populated in Step 306. The user may then add to or edit the information in these fields. The form completion engine may also specifically present or highlight the fields that were not completed, as discussed in Step 310. The form completion engine may also error check the user's edits and additions, and verify that the user has completed all of the fields on the form document. The form completion engine may highlight or otherwise bring to the user's attention any discovered errors or uncompleted fields.”)).
requesting verification by the user of the one or more completed user data fields through the graphical user interface (see at least Pennington, paragraph 0075 (“The user verifies the information in the fields that were populated in Step 306. The user may then add to or edit the information in these fields. The form completion engine may also specifically present or highlight the fields that were not completed, as discussed in Step 310. The form completion engine may also error check the user's edits and additions, and verify that the user has completed all of the fields on the form document. The form completion engine may highlight or otherwise bring to the user's attention any discovered errors or uncompleted fields.”)).
requesting completion by the user of one or more of the plurality of user data fields (see at least Pennington, paragraph 0065 (“If there are fields without associated data following Step 306 and 308, these fields may be highlighted or otherwise designated for completion by the user in Step 310. These fields may be cycled or toggled through for the user to complete. It should be appreciated though, that some fields on the form document might be optional or not applicable to the user. For example, the form document may include a field for “Spouse Name” which would not be applicable to an unmarried user. These fields may have associated field metadata indicative that they are mandatory, recommended, optional, or not applicable.”); paragraph 0075).
receiving one or more completed data fields in response to the request for completion, the one or more completed data fields corresponding to a different set of the plurality of user data fields than the one or more completed user data fields (see at least Pennington, paragraph 0066 (“In Step 312, as the user completes the additional fields, the information entered into the additional fields may be associated with metadata and saved to the set of user information in the user information data store. This allows future form documents for this user to be more quickly and efficiently completed. It should also be appreciated that in some embodiments, Steps 310 and 312 are performed after Step 318, discussed below. In these embodiments, the form completion engine displays the processed form document to the user and highlights (or otherwise indicates) the forms to be completed thereon.”)).
Pennington does not explicitly teach, but deOliveira, however, does teach:
performing a custom risk assessment based on the completed user data fields, the verification, and the completed data fields (see at least deOliveira, paragraph 0055 (“The implementation of a rule-based relationship analysis model can be better understood with reference to the following simplified example that uses a series of binary inquiries to classify the customer or loan application as high, moderate, or low risk.”)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate deOliveira’s method of determining a risk rating for a loan applicant with Pennington’s system and method of processing and completing form documents. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of determining whether to grant a loan to the loan applicant because loans are granted or denied based on risk.
Claim 22:
Pennington further teaches:
sending a user information verification page for display through the graphical user interface, the user information verification page configured to request one or more user demographic fields; receiving, based on the request, responsive user demographic data associated with the one or more user demographic fields; retrieving one or more stored user demographic data elements associated with the one or more user demographic fields from the database; and verifying the responsive user demographic data against the one or more stored user demographic data elements (see at least Pennington, paragraph 0076 (“In Step 320, any new information that is added or edited by the user is then saved or changed in the set of user information. As discussed above, in some instances the information entered into the fields will be of no relevance to future form documents. In some embodiments such information will not be added to the set of user information. New items of information will be added to the set of user information along with associated metadata. Edited items of information are edited in the set of user information. In some instances, the form management application (or another application) may inquire of the user whether such edits are of a recent change and whether such edits may represent an error in a previously completed form document. For example, if the user changes the house number in the taxpayer address, and such information was pulled from the previous year's tax return, there is a potential error in that tax return that may need to be corrected.”)).
Claim 23:
Pennington further teaches:
retrieving one or more public business data elements from a public business data source; and verifying the responsive user demographic data against the one or more public business data elements (see at least Pennington, paragraph 0076 (“In Step 320, any new information that is added or edited by the user is then saved or changed in the set of user information. As discussed above, in some instances the information entered into the fields will be of no relevance to future form documents. In some embodiments such information will not be added to the set of user information. New items of information will be added to the set of user information along with associated metadata. Edited items of information are edited in the set of user information. In some instances, the form management application (or another application) may inquire of the user whether such edits are of a recent change and whether such edits may represent an error in a previously completed form document. For example, if the user changes the house number in the taxpayer address, and such information was pulled from the previous year's tax return, there is a potential error in that tax return that may need to be corrected.”)).
Claim 24:
Pennington further teaches:
retrieving one or more user demographic data rules; and verifying one or more metadata elements associated with the responsive user demographic data against the one or more user demographic data rules (see at least Pennington, paragraph 0076 (“In Step 320, any new information that is added or edited by the user is then saved or changed in the set of user information. As discussed above, in some instances the information entered into the fields will be of no relevance to future form documents. In some embodiments such information will not be added to the set of user information. New items of information will be added to the set of user information along with associated metadata. Edited items of information are edited in the set of user information. In some instances, the form management application (or another application) may inquire of the user whether such edits are of a recent change and whether such edits may represent an error in a previously completed form document. For example, if the user changes the house number in the taxpayer address, and such information was pulled from the previous year's tax return, there is a potential error in that tax return that may need to be corrected.”)).
Claim 25:
Pennington does not explicitly teach, but deOliveira, however, does teach:
wherein performing the custom risk assessment includes determining a risk rating based on the completed user data fields, the verification, and the one or more completed data fields (see at least deOliveira, paragraph 0055 (“The implementation of a rule-based relationship analysis model can be better understood with reference to the following simplified example that uses a series of binary inquiries to classify the customer or loan application as high, moderate, or low risk.”)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate deOliveira’s method of determining a risk rating for a loan applicant with Pennington’s system and method of processing and completing form documents. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of determining whether to grant a loan to the loan applicant because loans are granted or denied based on risk.
Claim 26:
Pennington does not explicitly teach, but deOliveira, however, does teach:
wherein the risk rating is a high risk rating and the custom risk assessment is a negative custom risk assessment based on the high risk rating (see at least deOliveira, paragraph 0055 (“The implementation of a rule-based relationship analysis model can be better understood with reference to the following simplified example that uses a series of binary inquiries to classify the customer or loan application as high, moderate, or low risk.”); paragraph 0056 (“But if any of the inquiries are answered in the negative, the relationship analysis returns a fail result, and the customer might be classified as a high risk. Continuing with this example, the rule-based model can be modified to require two negative answers before returning a fail or high risk result. Or a negative answer to one of the inquiries can return a result classifying the customer as a medium risk rather than a high risk to account for factors that are less predictive of risk. In other words, a provider might determine that instances of prior loan default correlate strongly to high risk customers but having an instance of a NSF withdrawal does not. Thus, the provider can incorporate a rule into the model requiring that a negative response to the NSF inquiry returns a result classifying the customer as a medium risk whereas a response to the default inquiry classifies the customer as a high risk.”)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate deOliveira’s method of determining a risk rating for a loan applicant with Pennington’s system and method of processing and completing form documents. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of determining whether to grant a loan to the loan applicant because loans are granted or denied based on risk.
Claim 27:
Pennington does not explicitly teach, but deOliveira, however, does teach:
comparing the one or more completed data fields to a high-risk information dataset (see at least deOliveira, paragraph 0054 (Certain factors indicate a higher risk.)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate deOliveira’s method of determining a risk rating for a loan applicant by comparing an applicant’s information with factors that indicate high risk with Pennington’s system and method of processing and completing form documents. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of determining whether to grant a loan to the loan applicant because loans are granted or denied based on risk.
Claim 28:
Claim 28 is rejected using the same rationale that was used for the rejection of claim 21.
Claim 29:
Claim 29 is rejected using the same rationale that was used for the rejection of claim 22.
Claim 30:
Claim 30 is rejected using the same rationale that was used for the rejection of claim 23.
Claim 31:
Claim 31 is rejected using the same rationale that was used for the rejection of claim 24.
Claim 32:
Claim 32 is rejected using the same rationale that was used for the rejection of claim 25.
Claim 33:
Claim 33 is rejected using the same rationale that was used for the rejection of claim 26.
Claim 34:
Claim 34 is rejected using the same rationale that was used for the rejection of claim 27.
Claim 35:
Claim 35 is rejected using the same rationale that was used for the rejection of claims 21 and 27.
Claim 36:
Claim 36 is rejected using the same rationale that was used for the rejection of claim 22.
Claim 37:
Claim 37 is rejected using the same rationale that was used for the rejection of claim 23.
Claim 38:
Claim 38 is rejected using the same rationale that was used for the rejection of claim 24.
Claim 39:
Claim 39 is rejected using the same rationale that was used for the rejection of claim 25.
Claim 40:
Claim 40 is rejected using the same rationale that was used for the rejection of claim 26.
Relevant Prior Art
The following references are relevant to Applicant’s invention:
Cawley, U.S. Patent Application Publication Number 2020/0005393 A1. This reference teaches auto-populating a loan application.
Email Communications
Per MPEP 502.03, Applicant may authorize email communications by filing Form PTO/SB/439, available at https://www.uspto.gov/sites/default/files/documents/sb0439.pdf, via the USPTO patent electronic filing system.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ELIZABETH H ROSEN whose telephone number is (571) 270-1850 and email address is elizabeth.rosen@uspto.gov. The examiner can normally be reached Monday - Friday, 10 AM ET - 7 PM ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Michael Anderson, can be reached at 571-270-0508. 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.
/ELIZABETH H ROSEN/Primary Examiner, 3693
Prosecution Insights