DETAILED ACTION
Notice to Applicant
The following is a NON-FINAL Office action upon examination of application number 19/222,696, filed on 05/29/2025. Claims 1-19 are pending in the application and have been examined on the merits discussed below.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Application 19/222,696 filed 05/29/2025 is a Continuation of application 16/885,159, filed 05/27/2020. Application 16/885,159 claims Priority from Provisional Application 62/853,640, filed 05/28/2019.
Claim Interpretation
4. The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
5. This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: a data preparation module, a quality-assurance framework, and a development version of the unsecured loan-lending system in claim 1, a data-extraction module in claim 5, a data-scrubbing module in claim 7, a test-processing module, a validation module, a data-extraction module, and a validation-report module in claim 11, and a decryption module in claim 19.
The claim limitations a data preparation module, a quality-assurance framework, and a development version of the unsecured loan-lending system in claim 1, a data-extraction module in claim 5, a data-scrubbing module in claim 7, a test-processing module, a validation module, a data-extraction module, and a validation-report module in claim 11, and a decryption module in claim 19 invoke 112(f). Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
6. The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
7. Claims 1-19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites a data preparation module, a quality-assurance framework, and a development version of the unsecured loan-lending system, claim 5 recites a data-extraction module, claim 7 recites a data-scrubbing module, claim 11 recites a test-processing module, a validation module, a data-extraction module, and a validation-report module, and claim 19 recites a decryption module. These limitations invoke an interpretation under 35 U.S.C. § 112(f). The disclosure does not provide adequate structure to perform the claimed functions of prepare sample loan-application input values for borrower-related information and loan- product information, extract loan-product data from the loan-product information of the sample loan-application input values, scrub the borrower-related information of the sample loan- application input values and the loan-product data extracted from the loan-product information of the sample loan-application input values, modify or remove borrower-related information, loan-product data, or borrower-related information and loan-product data that is incorrect, incomplete, improperly formatted, or duplicated to produce at least scrubbed input data and scrubbed files, generate the sample loan applications from the sample loan-application input values, or the scrubbed input data therefrom, extract loan-application data from the processed sample loan applications upon decryption thereof for validation by the validation module, validate the processed sample loan applications, or the loan-application data extracted therefrom, against the processed-as-expected loan applications, provide validation reports for the processed sample loan applications, or the loan-application data extracted therefrom, validated against the processed-as-expected loan applications, and decrypt the processed sample loan applications for subsequently extracting the loan-application data from the processed sample loan applications by the data-extraction module of the quality-assurance framework. No association between the structure and the functions performed by the “data preparation module, quality-assurance framework, development version of the unsecured loan-lending system, data-extraction module, data-scrubbing module, test-processing module, validation module, data-extraction module, validation-report module, and decryption module” can be found in the Specification. Even though paragraph 0097 of the Specification explains that “Many functions performed by electronic hardware components can be duplicated by software emulation. Thus, a software program written to accomplish those same functions can emulate the functionality of the hardware components in input-output circuitry” it is not clear if the “data preparation module, quality-assurance framework, development version of the unsecured loan-lending system, data-extraction module, data-scrubbing module, test-processing module, validation module, data-extraction module, validation-report module, and decryption module” are hardware components or simply controlled by a hardware component. The Specification does not demonstrate that applicant has made an invention that achieved the claimed functions because the invention is not described with sufficient detail that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention.
All claims dependent from above rejected claims are also rejected due to dependency.
8. 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.
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.
9. Claims 1-19 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 pre-AIA the applicant regards as the invention.
10. Claim 1 limitations “a data preparation module, a quality-assurance framework, and a development version of the unsecured loan-lending system,” claim 5 limitation “a data-extraction module,” claim 7 limitation “a data-scrubbing module,” claim 11 limitations “a test-processing module, a validation module, a data-extraction module, and a validation-report module,” and claim 19 limitation “a decryption module” invoke an interpretation under 35 U.S.C. § 112(f). However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed functions and to clearly link the structure, material, or acts to the functions. Even though paragraph 0097 of the Specification explains that “Many functions performed by electronic hardware components can be duplicated by software emulation. Thus, a software program written to accomplish those same functions can emulate the functionality of the hardware components in input-output circuitry,” it is not clear if the “data preparation module, quality-assurance framework, development version of the unsecured loan-lending system, data-extraction module, data-scrubbing module, test-processing module, validation module, data-extraction module, validation-report module, and decryption module” are hardware components or simply controlled by a hardware component. No association between the structure and the functions can be found in the Specification. Consequently, it is not clear which structure and equivalents may be read into each of these limitations. The Specification does not provide sufficient details such that one of ordinary skill in the art would understand which structure or structures perform(s) the claimed functions of prepare sample loan-application input values for borrower-related information and loan-product information, extract loan-product data from the loan-product information of the sample loan-application input values, scrub the borrower-related information of the sample loan- application input values and the loan-product data extracted from the loan-product information of the sample loan-application input values, modify or remove borrower-related information, loan-product data, or borrower-related information and loan-product data that is incorrect, incomplete, improperly formatted, or duplicated to produce at least scrubbed input data and scrubbed files, generate the sample loan applications from the sample loan-application input values, or the scrubbed input data therefrom, extract loan-application data from the processed sample loan applications upon decryption thereof for validation by the validation module, validate the processed sample loan applications, or the loan-application data extracted therefrom, against the processed-as-expected loan applications, provide validation reports for the processed sample loan applications, or the loan-application data extracted therefrom, validated against the processed-as-expected loan applications, and decrypt the processed sample loan applications for subsequently extracting the loan-application data from the processed sample loan applications by the data-extraction module of the quality-assurance framework. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
11. Claim 1 recites “An integrity-and-volume testing system coupled to an unsecured-loan lending system for confirming all data gathered for processing unsecured loans is correctly gathered.” The phrase “correctly gathered” is ambiguous because “correctly” is a relative term. There is no basis or standard provided for determining whether data is “correctly” gathered. “Correctly” could mean complete accurate, etc. Therefore, the claim is rendered indefinite. Appropriate correction is required.
12. Claim 2 recites “wherein the sample loan-application input values can be up to at least 32K sample loan-application input values.” The phrase “wherein the sample loan-application input values can be up to at least 32K sample loan-application input values” is unclear because the phrase “up to at least 32K” is contradictory. The term “up to” indicates a maximum value, while “at least” indicates a minimum value. It is unclear whether “up to at least 32K” is a minimum, maximum, or approximate value. Therefore, the claim is rendered indefinite. Appropriate correction is required.
13. Claim 14 recites “wherein the data-extraction module is configured to extract loan-application data from the processed sample loan applications upon decryption thereof for validation by the validation module.” The phrase “upon decryption thereof” renders the scope of the claim unclear because it is ambiguous what object is being decrypted. It is unclear whether “thereof” refers to the processed sample loan applications or the loan-application data, or other data. Therefore, the claim is rendered indefinite. Appropriate correction is required.
14. All claims dependent from above rejected claims are also rejected due to dependency.
Claim Rejections - 35 USC § 101
15. 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.
16. Claims 1-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-patentable subject matter. The claims are directed to an abstract idea without significantly more.
17. Claims 1-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The eligibility analysis in support of these findings is provided below, in accordance with MPEP 2106.
With respect to Step 1 of the eligibility inquiry (as explained in MPEP 2106), it is first noted that the claimed system (claims 1-19) are directed to potentially eligible categories of subject matter (i.e., machine), and therefore claims 1-19 satisfy Step 1 of the eligibility inquiry.
With respect to Step 2A Prong One, it is next noted that the claims recite an abstract idea that falls into the “Certain Methods of Organizing Human Activity” abstract idea set forth in MPEP 2106 because the claims recite steps for processing a borrower’s loan application and facilitating financial services provided by financial institutions (see paragraph 0003 of the Specification: “Lending, particularly, originating loans such as unsecured loans, requires many fragments, often manual processes of both borrowers and lenders.”), which encompasses activity for managing personal behavior or relationships or interactions (e.g., managing relationships or interactions between borrowers and lenders) or commercial interactions, and steps that can be performed in the human mind (including observation, evaluation, judgment, opinion), and therefore fall under the “Mental Processes” abstract idea grouping. With respect to independent claim 1, the limitations reciting the abstract idea are indicated in bold below: an integrity-and-volume testing system coupled to an unsecured-loan lending system for confirming all data gathered for processing unsecured loans is correctly gathered, comprising: a data preparation module; a quality-assurance framework; and a development version of the unsecured loan-lending system coupled to the integrity-and-volume testing system. These steps cover organizing human activity because the claim recites limitations related to confirming data gathered for processing loans is correctly gathered. The claim limitations are directed to managing and verifying information used in processing of unsecured loans. The Specification supports the Examiner’s finding that the claims recite the judicial exception of a certain method of organizing human activities because the Specification discloses addressing the relationship between lenders and borrowers when processing a loan application, which necessarily relates to managing commercial interactions including business relations. The claimed data preparation and quality assurance function merely facilitate the administration of a lending process. Additionally, the “confirming” can be accomplished mentally via human evaluation or judgment even if aided with pen and paper, and thus fits within the “Mental Processes” abstract idea grouping. Therefore, because the limitations above set forth activities falling within the “Certain methods of organizing human activity” and “Mental Processes” abstract idea groupings described in MPEP 2106, the additional elements recited in the claims are further evaluated, individually and in combination, under Step 2A Prong Two and Step 2B below.
With respect to Step 2A Prong Two, the judicial exception is not integrated into a practical application. The additional elements are: an integrity-and-volume testing system coupled to an unsecured-loan lending system, a data preparation module, a quality-assurance framework, and a development version of the unsecured loan-lending system coupled to the integrity-and-volume testing system. (claim 1). These additional elements have been evaluated, but fail to integrate the abstract idea into a practical application because they amount to using generic computing elements or computer-executable instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment. See MPEP 2106.05(f) and 2106.05(h). Furthermore, these additional elements fail to integrate the abstract idea into a practical application because they fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.”).
Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception.
With respect to Step 2B of the eligibility inquiry, it has been determined that the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The additional elements are: an integrity-and-volume testing system coupled to an unsecured-loan lending system, a data preparation module, a quality-assurance framework, and a development version of the unsecured loan-lending system coupled to the integrity-and-volume testing system. (claim 1). The additional elements have been fully considered, but fail to add significantly more because they merely serve to tie the invention to a particular operating environment (i.e., computer-based implementation) by describing the use of generic computing elements to implement the claimed invention, though at a very high level of generality and without imposing meaningful limitation on the scope of the claim, similar to simply saying "apply it” or “apply it using a general purpose computer,” which is not enough to transform an abstract idea into eligible subject matter. Notably, Applicant’s Specification describes generic off-the-shelf computing elements for implementing the claimed invention and suggests that virtually any generic computing devices could be used to implement the invention (See, e.g., Specification paragraph [0092]). Therefore, these additional elements describe generic computing elements that merely serve to tie the abstract idea to a particular operating environment, which does not add significantly more to the abstract idea. See, e.g., Alice Corp., 134 S. Ct. 2347, 110 USPQ2d 1976.
In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements integrate the abstract idea into a practical application. Their collective functions merely provide generic computer implementation. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a practical application of the abstract idea or that the ordered combination amounts to significantly more than the abstract idea itself.
Dependent claims 2-19 recite the same abstract idea as recited in the independent claims, and when evaluated under Step 2A Prong One of the eligibility inquiry, merely recite further details of the same abstract idea recited in the independent claims accompanied by, at most, the involvement of the same generic computing elements as the independent claims which, as noted above, are not sufficient to amount to a practical application or significantly more than the abstract idea itself. In particular, dependent claims 2-19 recite “prepare sample loan-application input values for borrower-related information and loan-product information,” “wherein the sample loan-application input values can be up to at least 32K sample loan-application input values,” “wherein the input values can include any of input values corresponding to borrowers, lender representatives, and third-party data,” “data extraction,” “extract loan-product data from the loan-product information of the sample loan-application input values,” “scrub the borrower-related information of the sample loan-application input values and the loan-product data extracted from the loan-product information of the sample loan-application input values,” “modify or remove borrower-related information, loan-product data, or borrower-related information and loan-product data that is incorrect, incomplete, improperly formatted, or duplicated to produce at least scrubbed input data and scrubbed files,” “generate sample loan applications from the sample loan-application input values, or scrubbed input data therefrom, as well as validate processed sample loan applications against processed-as-expected loan applications,” “wherein the processed-as-expected loan applications can include sample loan applications from the sample loan-application input values processed through an existing version of the unsecured loan-lending system as opposed to the development version of the unsecured loan-lending system,” “test-processing, validation, data-extraction, an a validation-report,” “generate the sample loan applications from the sample loan-application input values, or the scrubbed input data therefrom,” “data-extraction,” “extract loan-application data from the processed sample loan applications upon decryption thereof for validation,” “validate the processed sample loan applications, or the loan-application data extracted therefrom, against the processed-as-expected loan applications,” “provide validation reports for the processed sample loan applications, or the loan-application data extracted therefrom, validated against the processed-as-expected loan applications,” “process sample loan applications into processed sample loan applications for validation against processed-as-expected loan applications,” “encrypt the sample loan applications during the processing thereof,” “decrypt the processed sample loan applications for subsequently extracting the loan-application data from the processed sample loan applications,” however, these claims also set forth steps falling within the same Certain methods of organizing human activity and/or Mental Processes abstract idea groupings recited in the independent claim. The additional elements recited in the dependent claims including a data-extraction module having a data-extraction library (claim 5), a data-scrubbing module configured to (claim 7), an existing version of the unsecured loan-lending system (claim 10), a test-processing module, a validation module, a data-extraction module, and a validation-report module (claim 11), a data-extraction library (claim 13), a decryption module configured to (claim 19) are recited at a high level of generality and fails to yield any discernible improvement to the computer or to any technology, nor set forth any additional function or result that provided meaningful limitation beyond linking the abstract idea to a particular technological environment (i.e., automated/computing environment), and thus fail to integrate the abstract idea into a practical application. When evaluated under Step 2A Prong Two and Step 2B, the additional elements do not amount to a practical application or significantly more since they merely require generic computing devices (or computer-implemented instructions/code) which as noted in the discussion of the independent claims above is not enough to render the claims as eligible.
The ordered combination of elements in the dependent claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide generic computer implementation. Accordingly, the subject matter encompassed by the dependent claims fails to amount to a practical application or significantly more than the abstract idea itself.
For more information, see MPEP 2106.
Claim Rejections - 35 USC § 103
18. 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.
19. 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 of this title, 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.
20. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
21. 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.
22. Claims 1-2, 9-13, 15, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over James et al., Pub. No.: US 2020/0265512 A1, [hereinafter James], in view of Gupta et al., Pub. No.: US 2018/0189680 A1, [hereinafter Gupta].
As per claim 1, James teaches an integrity-and-volume testing system coupled to an unsecured-loan lending system for confirming all data gathered for processing unsecured loans is correctly gathered (paragraph 0001: “The present invention relates to loan processing.”; paragraph 0012: “A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions.”; paragraph 0003: “Loans may be secured with an asset or unsecured. Unsecured installment loans are short term, unsecured loans extended to borrowers.”; paragraph 0009: “When a potential borrower desires to obtain an unsecured installment loan, the potential borrower is required to complete a loan application. The information requested in the loan application may include financial information...”), comprising:
a data preparation module (paragraph 00013, discussing that the system where the pre-processing subsystem pre-processes the external data by formatting, cleaning, and sampling the external data; paragraph 0031, discussing that the pre-processing subsystem pre-processes the data by formatting, cleaning, and sampling the data. The formatting step converts the data into a format that is suitable for use by the machine learning module. Cleaning of the data is the removal or fixing of missing data; paragraph 0025: “Aspects of the present disclosure may be embodied as an apparatus, system, method, or computer program product. Accordingly, aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects. These aspects may all generally be referred to as a “module,” “system”, or “subsystem.”; paragraph 0015); and
a quality-assurance framework (paragraph 0016, discussing collecting external data related to the applicant, and pre-processing the external data using a machine learning module to generate processed external data; paragraph 0031, discussing that the formatting step converts the data into a format that is suitable for use by the machine learning module. Cleaning of the data is the removal or fixing of missing data. Sampling of data relates to the selection of a smaller representative sample of the collected data that may be much faster for exploring and prototyping solutions before considering the whole data set. For example, the pre-processing subsystem may process or analyze different instances of data, such as historic customer data, simulated data, projected data, estimated data, and/or a combination of several of the above; paragraph 0032, discussing that customer datasets often include features like customer id, income, etc.…; paragraph 0036, discussing that the model creation and testing subsystem includes a model creation subsystem that creates models and associated algorithms for prediction purposes. Model creation is the task of creating statistical models from a set of candidate models given certain data. Automated model creation selects which predictive modeling technique matches a business problem. The model creation and testing subsystem also includes model testing subsystem that implements automated model testing to verify that derived models remain valid, and triggers relearning of a new model upon model failure; paragraph 0056, discussing that the loan approval and processing system processes the customer data. This step may include pre-processing the data to: format the data so that it is suitable for use by the machine learning module; clean the data by the removal or fixing of missing data; and sample the data by selecting a smaller representative sample of the collected data; paragraph 0046).
Gupta does not explicitly teach a development version of the unsecured loan-lending system coupled to the integrity-and-volume testing system. However, Gupta in the analogous art of credit application processing systems teaches this concept. Gupta teaches:
a development version of the unsecured loan-lending system coupled to the integrity-and-volume testing system (paragraph 0004, discussing that various embodiments involve software development platforms for performing one or more of testing, modifying, and deploying decision algorithms. For example, a computing system provides software development interface to a client device…The system also configures the decision engine in the test mode to execute a different decision algorithms on the test data; paragraph 0031, discussing that various embodiments involve software development and decisioning platforms for performing one or more of testing, modifying, and deploying decision algorithms. For example, a software development computing system can provide a software management interface to one or more client devices. The software management interface allows real-time switching from test data sources to production data sources, switching among different decision algorithms to be tested, etc. For example, in a given computing session, the software management interface allows an end user device to toggle between a test environment, which allows program code for a decision algorithm to be tested and refined while protecting live data sources from being impacted by the execution of a decision algorithm, and a live environment to which the tested and refined program code for the decision algorithm can be deployed; paragraph 0033, discussing that the software development system configures a development environment into a test mode based on the client computing device selecting, via the software management interface, the test data. In the test mode, the software development system executes different decision algorithms by applying one or more operations of these algorithms to the test data; paragraph 0120).
Examiner notes that Gupta, in addition to James as cited above, also teaches a quality-assurance framework (paragraph 0106, discussing that the workflow component can support workflow management, and in conjunction with the decision sub-engine, can provide queue management, work distribution, work management, and other workflow services. For instance, a particular decision algorithm can be programmed for supporting certain operations of a system involving a client device…These operations can include, for example, data validation that ensures that a complete decision data object is available (e.g., information such as employment verification data is present) or that an incomplete decision data object can be supplemented with missing data (e.g., by verifying missing data as needed), transmission of notifications to one or more client devices indicating actions required by an entity (e.g., if completion of the application requires the applicant to be present at some specific location or requires involvement of some specific role players such as supervisors or branch managers), delaying notification of a decision algorithm's output to certain devices (e.g., notifying a client device associated with a financial institution using the software development and decisioning platform prior to notifying a client device associated with an applicant described in one or more of the data sources), transmitting follow-ups to entities, terminating transactions if no response is received from a client device a certain time period after notifying the client device of a decision algorithm's output, etc.; paragraph 0138, discussing that if the online communication sub-engine determines that the applicant information in a service request form contains one or more missing required fields, then the process returns to block 1404. That is, if information has not been entered or is otherwise incomplete in one or more required fields, the online communication sub- engine can prompt the user to enter or otherwise correct the information until the required fields contain valid information; paragraph 0173, discussing that if a decision such as “False” or “No” is determined, then the process continues to an activity block labeled “Escalate Validation Failure”; paragraph 0140).
James is directed towards a system and method for underwriting and processing of loans. Gupta is directed towards a credit application data processing system. Therefore, they are deemed to be analogous as they both are directed towards loan processing systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine James with Gupta because the references are analogous art because they are both directed to solutions for loan processing, which falls within applicant’s field of endeavor (loan-lending method and system), and because modifying James to include Gupta’s feature for including a development version of the unsecured loan-lending system coupled to the integrity-and-volume testing system, in the manner claimed, would serve the motivation of allowing for efficient testing and refinement of program code in a test environment and deployment of the refined program code to a live environment and facilitating application processing (Gupta at paragraphs 0034, 0108); or in the pursuit of providing efficient, and accurate aggregating and analysis of loan application data, thereby providing systems and methods that verify the completeness, accuracy, authenticity, and risk of a loan application and the data it contains; and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 2, the James-Gupta combination teaches the system of claim 1. James further teaches wherein the data-preparation module is configured to prepare sample loan-application input values for borrower-related information and loan-product information (paragraph 0009: “When a potential borrower desires to obtain an unsecured installment loan, the potential borrower is required to complete a loan application. The information requested in the loan application may include financial information...”; paragraph 0010, discussing that lenders will look at a variety of available data sources that provide information about the creditworthiness of a borrower. A typical data source would be a credit bureau, an entity that collects and researches individual credit information and sells it for a fee to creditors so they can make a decision on granting loans. Assessment of the information collected will typically require assessment by a person who will use their judgment in making decisions to approve deny a loan; paragraph 0013, discussing that the system where the pre-processing subsystem pre-processes the external data by formatting, cleaning, and sampling the external data. The system where the automated feature engineering subsystem is used to transform the external data by scaling, decomposition, and aggregation; paragraph 0027, discussing that the environment may include a loan approval and processing system having an underwriting module and a machine learning module…The underwriting module accesses a plurality of data sources including credit bureau data sources, bank transaction data sources and social media data sources. Other sources of data that may provide insights on the ability of the borrower to repay a loan on time may be accessed…The loan approval and processing system will also receive input from a customer application subsystem; paragraph 0033, discussing that in feature engineering a dataset is prepared for machine learning by changing features or deriving new features to improve machine learning model performance. For example, suppose a lender wants to predict which loans will go bad. The lender has the borrowers' incomes and the monthly repayment amount of each loan. While these two values are individually predictive of the probability of default, creating a new feature based on the calculation of the loan repayment amounts as a percentage of the borrowers' income may add additional insights and will get the lender an even more accurate model; paragraph 0053, discussing that loan application information would include the customer name, the customer address, customer phone number, the requested amount of the loan, the reason for the loan request, email address,…, income, income source, and banking information; paragraphs 0014, 028, 0043).
As per claim 9, the James-Gupta combination teaches the system of claim 1. James further teaches wherein the quality-assurance framework is configured to generate sample loan applications from the sample loan-application input values, or scrubbed input data therefrom (paragraph 0016, discussing collecting external data related to the applicant, and pre-processing the external data using a machine learning module to generate processed external data; paragraph 0031, discussing that the formatting step converts the data into a format that is suitable for use by the machine learning module. Cleaning of the data is the removal or fixing of missing data. Sampling of data relates to the selection of a smaller representative sample of the collected data that may be much faster for exploring and prototyping solutions before considering the whole data set. For example, the pre-processing subsystem may process or analyze different instances of data, such as historic customer data, simulated data, projected data, estimated data, and/or a combination of several of the above; paragraph 0032, discussing that customer datasets often include features like customer id, income, etc.…; paragraph 0053, discussing that loan application information would include the customer name, the customer address, customer phone number, the requested amount of the loan, the reason for the loan request, email address,…, income, income source, and banking information; paragraph 0056, discussing that the loan approval and processing system processes the customer data. This step may include pre-processing the data to: format the data so that it is suitable for use by the machine learning module; clean the data by the removal or fixing of missing data; and sample the data by selecting a smaller representative sample of the collected data; paragraph 0035).
James does not explicitly teach as well as validate processed sample loan applications against processed-as-expected loan applications. However, Gupta in the analogous art of credit application processing systems teaches this concept. Gupta teaches:
as well as validate processed sample loan applications against processed-as-expected loan applications (paragraph 0042, discussing that an online service request database can communicate with the software development and decisioning platform. An online communication sub-engine of the software development and decisioning platform can store a decision data object (e.g., a credit application) and a new decision data object identifier or decision data object identification code in the online service request database; paragraph 0045, discussing that an example of the software development and decisioning platform can include an online communication sub-engine and a decision sub-engine…The components of the software development and decisioning platform can support the automation of one or more decisioning operations performed with online services (e.g., credit decisions, loan-origination,…, application processing, etc.); paragraph 0049, discussing that the service request form can be used to collect information about an applicant for a bank loan; paragraph 0137, discussing that a validity check is performed…The online communication sub-engine can perform one or more validity checks on the applicant information. The online communication sub-engine can perform a check whether information has been entered in any number of predefined required fields. For example, the online communication sub-engine can permit certain fields to be associated with predefined requirements relative to availability, formatting, and content. In general, such fields will have to be validated relative to these issues. By way of further example, users can designate required fields to be completed such as name, address, social security number, tax identification number, and product selection fields; paragraph 0138, discussing that if information has not been entered or is otherwise incomplete in one or more required fields, the online communication sub-engine can prompt the user to enter or otherwise correct the information until the required fields contain valid information; paragraph 0139, discussing that the online communication sub-engine can perform a check whether particular information from users is valid. The online communication sub-engine can access one or more data sources, compare user-entered information to predefined information or previously stored information, and perform one or more checking routines or methods; paragraph 0140, discussing that if the online communication sub-engine determines that information is not valid, then the process 1400 returns to block 1404…The online communication sub-engine can check and validate user-entered or provided information against previously collected information stored in one or more data sources…).
James is directed towards a system and method for underwriting and processing of loans. Gupta is directed towards a credit application data processing system. Therefore, they are deemed to be analogous as they both are directed towards loan processing systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine James with Gupta because the references are analogous art because they are both directed to solutions for loan processing, which falls within applicant’s field of endeavor (loan-lending method and system), and because modifying James to include Gupta’s feature for including a quality-assurance framework configured to validate processed sample loan applications against processed-as-expected loan applications, in the manner claimed, would serve the motivation of allowing for efficient testing and refinement of program code in a test environment and deployment of the refined program code to a live environment and facilitating application processing (Gupta at paragraphs 0034, 0108); or in the pursuit of providing efficient, and accurate aggregating and analysis of loan application data, thereby providing systems and methods that verify the completeness, accuracy, authenticity, and risk of a loan application and the data it contains; and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 10, the James-Gupta combination teaches the system of claim 9. James, further teaches wherein the processed-as-expected loan applications can include sample loan applications from the sample loan-application input values processed through an existing version of the unsecured loan-lending system as opposed to the development version of the unsecured loan-lending system (paragraph 0028, discussing that the underwriting module automatically decides whether to approve the loan based on information received from customer application, credit bureau data sources, bank transaction data sources, social media data sources and other data sources. The automatic decision of loan approval is made using machine learning module. The underwriting module may select one or more recommended actions based on one or more machine learning results. The underwriting module may select or recommend an action based on a confidence metric associated with the action; paragraph 0030, discussing that in embodiments where the machine learning module and/or the pre-processing module collect learning results, the underwriting module may access a results data structure to analyze or process the pre-computed machine learning results to determine one or more recommended actions for loan application; paragraph 0031, discussing that the pre-processing subsystem may process or analyze different instances of data, such as historic customer data, simulated data, projected data, estimated data, and/or a combination of several of the above; paragraph 0056, discussing that the loan approval and processing system processes the customer data. This step may include pre-processing the data to: format the data so that it is suitable for use by the machine learning module; clean the data by the removal or fixing of missing data; and sample the data by selecting a smaller representative sample of the collected data; paragraph 0058, discussing that a loan approval determination of is made).
As per claim 11, the James-Gupta combination teaches the system of claim 10. James further teaches wherein the quality-assurance framework includes a test-processing module and a validation module (paragraph 0013, discussing that the pre-processing subsystem pre-processes the external data by formatting, cleaning, and sampling the external data; paragraph 0025: “Aspects of the present disclosure may be embodied as an apparatus, system, method, or computer program product. Accordingly, aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects. These aspects may all generally be referred to as a “module,” “system”, or “subsystem.”; paragraph 0026, discussing that a module may be implemented as a hardware circuit or in programmable hardware devices. Modules may also be implemented in software for execution by various types of processors. Modules or portions of a module that are implemented in software, may be stored on one or more computer readable storage media; paragraph 0027, discussing that the environment may include a loan approval and processing system having an underwriting module and a machine learning module…The loan approval and processing system will also receive input from a customer application subsystem; paragraph 0028, discussing that the underwriting module automatically decides whether to approve the loan based on information received from customer application, credit bureau data sources, bank transaction data sources, social media data sources and other data sources; paragraph 0036, discussing that the model creation and testing subsystem includes model creation subsystem that creates models and associated algorithms for prediction purposes. Model creation is the task of creating statistical models from a set of candidate models given certain data. Automated model creation selects which predictive modeling technique matches a business problem. Model creation and testing subsystem also includes model testing subsystem that implements automated model testing to verify that derived models remain valid, and triggers relearning of a new model upon model failure; paragraph 0049).
James does not explicitly teach wherein the quality-assurance framework includes a data-extraction module and a validation-report module (paragraph 0056, discussing that the presentation/interface layer can also extract decision-related data about a particular applicant from one or more data sources. The presentation/interface layer can interact with other layers or components of the software development and decisioning platform to build analytical models based upon the extracted decision-related data information for one or more entities. Such analytical models can then be displayed for presentation and analysis to the user by the presentation/interface layer. The software development and decisioning platform can provide the presentation/interface layer with decision information such as a decision as to which electronic services can be approved for use by one or more entities based on the extracted decision-related data and the analytical models; paragraph 0061, discussing that the decision sub-engine can include, but is not limited to, a data resource layer. The data resource layer can provide integration and archival capabilities for all relevant entity and decision-related data in a suitable format that can be user-friendly and easily searched. Such data can also be stored by the data resource layer for subsequent retrieval, analysis, and reporting; paragraph 0064, discussing that a data resource layer can accommodate varying data input and data output formats when integrating multiple data sources and third party service providers. The data resource layer can automatically extract, transform, and load heterogeneous data fields from the one or more data sources, minimizing or otherwise reducing the need for custom coded processing of such data; paragraph 0068, discussing that the data analysis layer forms inferences and conclusions that can be further processed and delivered by various com ponents of the services layer. These include generating data describing the information, inferences and/or conclusions appropriately in communications, performing audits, controlling workflow, allowing trial runs, and managing documents reflecting reports of such information, inferences and/or conclusions and other services which may relate to the data, the entity extending credit, the subject of the diligence or other related matters or entities; paragraph 0125, discussing that the data output component can provide a range of reporting options from rudimentary to comprehensive. A variety of standard reports, seamless uploads to key reporting vendors, and data streams to users who maintain proprietary or open reporting systems can be supported. The data output component can also deliver reports online through a user interface to meet users' general needs).
James is directed towards a system and method for underwriting and processing of loans. Gupta is directed towards a credit application data processing system. Therefore, they are deemed to be analogous as they both are directed towards loan processing systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine James with Gupta because the references are analogous art because they are both directed to solutions for loan processing, which falls within applicant’s field of endeavor (loan-lending method and system), and because modifying James to include Gupta’s feature for including wherein the quality-assurance framework includes a data-extraction module and a validation-report module, in the manner claimed, would serve the motivation of allowing for efficient testing and refinement of program code in a test environment and deployment of the refined program code to a live environment and facilitating application processing (Gupta at paragraphs 0034, 0108); or in the pursuit of providing efficient, and accurate aggregating and analysis of loan application data, thereby providing systems and methods that verify the completeness, accuracy, authenticity, and risk of a loan application and the data it contains; and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 12, the James-Gupta combination teaches the system of claim 11. James further teaches wherein the test-processing module is configured to generate the sample loan applications from the sample loan-application input values, or the scrubbed input data therefrom (paragraph 0016, discussing collecting external data related to the applicant, and pre-processing the external data using a machine learning module to generate processed external data; paragraph 0031, discussing that the formatting step converts the data into a format that is suitable for use by the machine learning module. Cleaning of the data is the removal or fixing of missing data. Sampling of data relates to the selection of a smaller representative sample of the collected data that may be much faster for exploring and prototyping solutions before considering the whole data set. For example, the pre-processing subsystem may process or analyze different instances of data, such as historic customer data, simulated data, projected data, estimated data, and/or a combination of several of the above; paragraph 0032, discussing that customer datasets often include features like customer id, income, etc.…; paragraph 0053, discussing that loan application information would include the customer name, the customer address, customer phone number, the requested amount of the loan, the reason for the loan request, email address,…, income, income source, and banking information; paragraph 0056, discussing that the loan approval and processing system processes the customer data. This step may include pre-processing the data to: format the data so that it is suitable for use by the machine learning module; clean the data by the removal or fixing of missing data; and sample the data by selecting a smaller representative sample of the collected data).
As per claim 13, the James-Gupta combination teaches the system of claim 12. Although not explicitly taught by James, Gupta in the analogous art of credit application processing systems teaches wherein the data-extraction module includes a data-extraction library (paragraph 0056, discussing that the presentation/interface layer can also extract decision-related data about a particular applicant from one or more data sources. The presentation/interface layer can interact with other layers or components of the software development and decisioning platform to build analytical models based upon the extracted decision-related data information for one or more entities. Such analytical models can then be displayed for presentation and analysis to the user by the presentation/interface layer. The software development and decisioning platform can provide the presentation/interface layer with decision information such as a decision as to which electronic services can be approved for use by one or more entities based on the extracted decision-related data and the analytical models; paragraph 0120, discussing a database having test data is included in a test environment, which is a non-production version of an existing online environment. The software development and decisioning platform or another suitable computing service can be used to create such a test environment from historical production data or other test data; paragraph 0202, discussing that the computing system obtains test information. For example, the computing system accesses a first database that includes test data (e.g., off-line data, archived data, etc.). The first database is segregated or otherwise separate from a second database that includes live data; paragraph 0204).
James is directed towards a system and method for underwriting and processing of loans. Gupta is directed towards a credit application data processing system. Therefore, they are deemed to be analogous as they both are directed towards loan processing systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine James with Gupta because the references are analogous art because they are both directed to solutions for loan processing, which falls within applicant’s field of endeavor (loan-lending method and system), and because modifying James to include Gupta’s feature for including wherein the data-extraction module includes a data-extraction library, in the manner claimed, would serve the motivation of allowing for efficient testing and refinement of program code in a test environment and deployment of the refined program code to a live environment and facilitating application processing (Gupta at paragraphs 0034, 0108); or in the pursuit of providing efficient, and accurate aggregating and analysis of loan application data, thereby providing systems and methods that verify the completeness, accuracy, authenticity, and risk of a loan application and the data it contains; and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 15, the James-Gupta combination teaches the system of claim 13. Although not explicitly taught by James, Gupta in the analogous art of credit application processing systems teaches wherein the validation module is configured to validate the processed sample loan applications, or the loan-application data extracted therefrom, against the processed-as-expected loan applications (paragraph 0042, discussing that an online service request database can communicate with the software development and decisioning platform. An online communication sub-engine of the software development and decisioning platform can store a decision data object (e.g., a credit application) and a new decision data object identifier or decision data object identification code in the online service request database; paragraph 0045, discussing that an example of the software development and decisioning platform can include an online communication sub-engine and a decision sub-engine…The components of the software development and decisioning platform can support the automation of one or more decisioning operations performed with online services (e.g., credit decisions, loan-origination,…, application processing, etc.); paragraph 0049, discussing that the service request form can be used to collect information about an applicant for a bank loan; paragraph 0137, discussing that a validity check is performed…The online communication sub-engine can perform one or more validity checks on the applicant information. The online communication sub-engine can perform a check whether information has been entered in any number of predefined required fields. For example, the online communication sub-engine can permit certain fields to be associated with predefined requirements relative to availability, formatting, and content. In general, such fields will have to be validated relative to these issues. By way of further example, users 112a-n can designate required fields to be completed such as name, address, social security number, tax identification number, and product selection fields; paragraph 0138, discussing that if information has not been entered or is otherwise incomplete in one or more required fields, the online communication sub-engine can prompt the user to enter or otherwise correct the information until the required fields contain valid information; paragraph 0139, discussing that the online communication sub-engine can perform a check whether particular information from users is valid. The online communication sub-engine can access one or more data sources, compare user-entered information to predefined information or previously stored information, and perform one or more checking routines or methods; paragraph 0140, discussing that if the online communication sub-engine determines that information is not valid, then the process 1400 returns to block 1404…The online communication sub-engine can check and validate user-entered or provided information against previously collected information stored in one or more data sources…).
James is directed towards a system and method for underwriting and processing of loans. Gupta is directed towards a credit application data processing system. Therefore, they are deemed to be analogous as they both are directed towards loan processing systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine James with Gupta because the references are analogous art because they are both directed to solutions for loan processing, which falls within applicant’s field of endeavor (loan-lending method and system), and because modifying James to include Gupta’s feature for including wherein the validation module is configured to validate the processed sample loan applications, or the loan-application data extracted therefrom, against the processed-as-expected loan applications, in the manner claimed, would serve the motivation of allowing for efficient testing and refinement of program code in a test environment and deployment of the refined program code to a live environment and facilitating application processing (Gupta at paragraphs 0034, 0108); or in the pursuit of providing efficient, and accurate aggregating and analysis of loan application data, thereby providing systems and methods that verify the completeness, accuracy, authenticity, and risk of a loan application and the data it contains; and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 17, the James-Gupta combination teaches the system of claim 1. Although not explicitly taught by James, Gupta in the analogous art of credit application processing systems teaches wherein the development version of the unsecured loan-lending system is configured to process sample loan applications into processed sample loan applications for validation against processed-as-expected loan applications (paragraph 0002: “This disclosure involves interfaces and tools for creating and modifying software, and more particular involves software development platforms for performing one or more of testing, modifying, and deploying decision algorithms.”; paragraph 0003: “Development systems are used for controlling data processing operations that develop software programs executed by processing devices. These operations can include, for example, maintaining different versions of source code under development to facilitate software development.”; paragraph 0032, discussing that the software management interface can include one or more menus or other elements for selecting different decision algorithms (e.g., a current version and an alternative version of an algorithm); paragraph 0120, discussing that a database having test data is included in a test environment, which is a non-production version of an existing online environment; paragraph 0139, discussing that the online communication sub-engine can perform a check whether particular information from users is valid. The online communication sub-engine can access one or more data sources, compare user-entered information to predefined information or previously stored information, and perform one or more checking routines or methods; paragraph 0140, discussing that the online communication sub-engine can check and validate user-entered or provided information against previously collected information stored in one or more data sources…; paragraph 0143, discussing that FIG. 15 illustrates a process 1500 for determining a duplicate match…A duplicate match can be determined by an online communication sub-engine comparing a new application and associated applicant information with a previously stored application and its respective associated applicant information; paragraph 0145, discussing that the online communication sub-engine can determine one or more elements such as fields in a service request form to compare with previously stored elements stored in a database such as an online service request database; paragraphs 0041, 0117, 0126, 0160, 0206).
James is directed towards a system and method for underwriting and processing of loans. Gupta is directed towards a credit application data processing system. Therefore, they are deemed to be analogous as they both are directed towards loan processing systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine James with Gupta because the references are analogous art because they are both directed to solutions for loan processing, which falls within applicant’s field of endeavor (loan-lending method and system), and because modifying James to include Gupta’s feature for including wherein the development version of the unsecured loan-lending system is configured to process sample loan applications into processed sample loan applications for validation against processed-as-expected loan applications, in the manner claimed, would serve the motivation of allowing for efficient testing and refinement of program code in a test environment and deployment of the refined program code to a live environment and facilitating application processing (Gupta at paragraphs 0034, 0108); or in the pursuit of providing efficient, and accurate aggregating and analysis of loan application data, thereby providing systems and methods that verify the completeness, accuracy, authenticity, and risk of a loan application and the data it contains; and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
23. Claims 3-5 are rejected under 35 U.S.C. 103 as being unpatentable over James in view of Gupta, in further view of Zadeh et al., Pub. No.: US 2018/0204111 A1, [hereinafter Zadeh].
As per claim 3, the James-Gupta combination teaches the system of claim 2. Although not explicitly taught by the James-Gupta combination, Zadeh in the analogues art of data processing systems teaches wherein the sample loan-application input values can be up to at least 32K sample loan-application input values (paragraph 2313, discussing that In one embodiment, e.g. for loan analysis, if there is a rule forbidding anybody less than 18 to get a loan, then instead of linear regression, we can use a non-linear function in there, or use a second order term for the cut-off age, or use the moment terms of the second order, to mimic the effect of the cut-off age. In one embodiment, e.g. for loan analysis, if it turns out that the age bracket is important, e.g. bracket or range of age between e.g. “low 40 to mid 50”, then we have fuzzy range and parameters, rather than crisp number(s). In one embodiment, for stochastic gradient descent, we use more than one data points; paragraph 2316, discussing that in one embodiment, for classification, e.g. for one million data points, we choose one thousand points only, randomly or uniformly, if possible (i.e. a subset), and find the support vector machines for the subset (derived SVM), which is much faster than that of the original data set, and then try the remaining data points (999,000 points, in this example) against the resulting the support vector machines and the support vectors, to adjust, if needed. Since, in average, for most cases, most of the original 1 million data points are far from the support vectors, and thus, not contributing to the support vectors, the adjustment is usually limited to (or required for) a small fraction of those remaining 999,000 points. This increases the efficiency of the calculation of the SVM; paragraph 2330, discussing that in one embodiment, we have lots of data coming in real time, as input. First, we calculate our first SVM for the first e.g. 1000 data points, and store the result in the library. Then, we adjust the first SVM result, based on the coming data (millions of points) in real time, as they come in, based on the methods shown above, as an approximation (similar to running average of data points coming in, in real time). Thus, we can handle large amount of data, in real time, to get the SVM, for classification, recognition, and verification purposes (or the like)).
The James-Gupta combination described features related to loan processing. Zadeh is directed towards big data processing. Therefore, they are deemed to be analogous as they both are directed towards data processing systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the James-Gupta combination with Zadeh because the references are analogous art because they are both directed to solutions for data processing, which falls within applicant’s field of endeavor (loan-lending method and system), and because modifying the James-Gupta combination to include Zadeh’s feature for including wherein the sample loan-application input values can be up to at least 32K sample loan-application input values, in the manner claimed, would serve the motivation of better understanding and processing the information (Zadeh at paragraph 2368); and because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 4, the James-Gupta-Zadeh combination teaches the system of claim 3. James further teaches wherein the input values can include any of input values corresponding to borrowers, lender representatives, and third-party data (paragraph 0010, discussing that lenders will look at a variety of available data sources that provide information about the creditworthiness of a borrower. A typical data source would be a credit bureau, an entity that collects and researches individual credit information and sells it for a fee to creditors so they can make a decision on granting loans. Assessment of the information collected will typically require assessment by a person who will use their judgment in making decisions to approve deny a loan; paragraph 0014, discussing receiving at a lender a loan application from a loan applicant; paragraph 0027, discussing that the underwriting module accesses a plurality of data sources including credit bureau data sources, bank transaction data sources and social media data sources. Other sources of data that may provide insights on the ability of the borrower to repay a loan on time may be accessed…The loan approval and processing system will also receive input from a customer application subsystem; paragraph 0028, discussing that the underwriting module automatically decides whether to approve the loan based on information received from customer application, credit bureau data sources, bank transaction data sources, social media data sources and other data sources).
As per claim 5, the James-Gupta-Zadeh combination teaches the system of claim 4. Although not explicitly taught by James, Gupta in the analogous art of credit application processing systems teaches wherein the data-preparation module includes a data-extraction module having a data-extraction library (paragraph 0056, discussing that the presentation/interface layer can also extract decision-related data about a particular applicant from one or more data sources. The presentation/interface layer can interact with other layers or components of the software development and decisioning platform to build analytical models based upon the extracted decision-related data information for one or more entities. Such analytical models can then be displayed for presentation and analysis to the user by the presentation/interface layer. The software development and decisioning platform can provide the presentation/interface layer with decision information such as a decision as to which electronic services can be approved for use by one or more entities based on the extracted decision-related data and the analytical models; paragraph 0120, discussing a database having test data is included in a test environment, which is a non-production version of an existing online environment. The software development and decisioning platform or another suitable computing service can be used to create such a test environment from historical production data or other test data; paragraph 0202, discussing that the computing system obtains test information. For example, the computing system accesses a first database that includes test data (e.g., off-line data, archived data, etc.). The first database is segregated or otherwise separate from a second database that includes live data; paragraph 0204).
James is directed towards a system and method for underwriting and processing of loans. Gupta is directed towards a credit application data processing system. Therefore, they are deemed to be analogous as they both are directed towards loan processing systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine James with Gupta because the references are analogous art because they are both directed to solutions for loan processing, which falls within applicant’s field of endeavor (loan-lending method and system), and because modifying James to include Gupta’s feature for including wherein the data-preparation module includes a data-extraction module having a data-extraction library, in the manner claimed, would serve the motivation of allowing for efficient testing and refinement of program code in a test environment and deployment of the refined program code to a live environment and facilitating application processing (Gupta at paragraphs 0034, 0108); or in the pursuit of providing efficient, and accurate aggregating and analysis of loan application data, thereby providing systems and methods that verify the completeness, accuracy, authenticity, and risk of a loan application and the data it contains; and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
24. Claims 6-8 are rejected under 35 U.S.C. 103 as being unpatentable over James in view of Gupta, in view of Zadeh, in further view of Swaminathan et al., Pub. No.: US 2019/0095991 A1, [hereinafter Swaminathan].
As per claim 6, the James-Gupta-Zadeh combination teaches the system of claim 5, but it does not exactly teach wherein the data-extraction module is configured to extract loan-product data from the loan-product information of the sample loan-application input values. However, Swaminathan in the analogous art of loan application systems teaches this concept. Swaminathan teaches:
wherein the data-extraction module is configured to extract loan-product data from the loan-product information of the sample loan-application input value (paragraph 0002, discussing a computer-implemented mortgage processing system and method for facilitating a mortgage fulfillment process between a mortgage processor computing device and a borrower computing device; paragraph 0008, discussing that a loan origination document is stored in the memory of the mortgage processor computing device, wherein the loan origination document includes a plurality of loan origination data fields configured for receiving loan data, and wherein the first set of computer instructions is further configured for performing the steps of: after the server receives the associated data file, analyzing the associated data file to extract loan data from the associated data file, and automatically populating at least one of the plurality of loan origination data fields with the extracted loan data. The step of analyzing the associated data file may be performed using at least one of robotics process automation (RPA) or screen-scraping. Also, the loan data extracted from the associated data file may be modified or transformed (used in a calculation) prior to automatically populating the at least one of the plurality of loan origination data fields with the modified or transformed extracted loan data).
The James-Gupta-Zadeh combination described features related to loan processing. Swaminathan is directed towards a computer-implemented mortgage processing system and method. Therefore, they are deemed to be analogous as they both are directed towards loan processing systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the James-Gupta-Zadeh combination with Swaminathan because the references are analogous art because they are both directed to solutions for loan processing, which falls within applicant’s field of endeavor (loan-lending method and system), and because modifying the James-Gupta-Zadeh combination to include Swaminathan’s feature for including wherein the data-extraction module is configured to extract loan-product data from the loan-product information of the sample loan-application input value, in the manner claimed, would serve the motivation of facilitating the mortgage fulfillment process (Swaminathan at paragraph 0031); and because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 7, the James-Gupta-Zadeh- Swaminathan combination teaches the system of claim 6. James further teaches wherein the data-preparation module includes a data-scrubbing module configured to scrub the borrower-related information of the sample loan-application input values (paragraph 0012, discussing a system including: a loan approval decision module that receives input from a loan applicant and collects external data including credit bureau data, bank transaction data, and social media data. The system also includes a machine learning module having a pre-processing subsystem, an automated feature engineering subsystem and a feature statistical assessment subsystem…; paragraph 0013, discussing that the pre-processing subsystem pre-processes the external data by formatting, cleaning, and sampling the external data; paragraph 0014, discussing that the method include the steps of collecting external data related to the applicant and pre-processing the external data to generate processed external data; paragraph 0031, discussing that cleaning of the data is the removal or fixing of missing data… the pre-processing subsystem pre-processes the data by formatting, cleaning, and sampling the data…the pre-processing subsystem may process or analyze different instances of data, such as historic customer data, simulated data, projected data, estimated data, and/or a combination of several of the above. Pre-processing subsystem may determine simulated, estimated, or projected data to fill-in or complete data from a user based on the data from the user; paragraph 0056, discussing that the loan approval and processing system processes the customer data. This step may include pre-processing the data to: format the data; clean the data by the removal or fixing of missing; paragraph 0079, discussing that the bank transaction data is pre-processed and cleaned up).
James does not exactly teach scrub the loan-product data extracted from the loan-product information of the sample loan-application input values. However, Swaminathan in the analogous art of loan application systems teaches this concept. Swaminathan teaches:
scrub the loan-product data extracted from the loan-product information of the sample loan-application input values (paragraph 0002, discussing a computer-implemented mortgage processing system and method for facilitating a mortgage fulfillment process between a mortgage processor computing device and a borrower computing device; paragraph 0008, discussing that a loan origination document is stored in the memory of the mortgage processor computing device, wherein the loan origination document includes a plurality of loan origination data fields configured for receiving loan data, and wherein the first set of computer instructions is further configured for performing the steps of: after the server receives the associated data file, analyzing the associated data file to extract loan data from the associated data file, and automatically populating at least one of the plurality of loan origination data fields with the extracted loan data. The step of analyzing the associated data file may be performed using at least one of robotics process automation (RPA) or screen-scraping. Also, the loan data extracted from the associated data file may be modified or transformed (used in a calculation) prior to automatically populating the at least one of the plurality of loan origination data fields with the modified or transformed extracted loan data).
The James-Gupta-Zadeh combination described features related to loan processing. Swaminathan is directed towards a computer-implemented mortgage processing system and method. Therefore, they are deemed to be analogous as they both are directed towards loan processing systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the James-Gupta-Zadeh combination with Swaminathan because the references are analogous art because they are both directed to solutions for loan processing, which falls within applicant’s field of endeavor (loan-lending method and system), and because modifying the James-Gupta-Zadeh combination to include Swaminathan’s feature for including scrubbing the loan-product data extracted from the loan-product information of the sample loan-application input values, in the manner claimed, would serve the motivation of facilitating the mortgage fulfillment process (Swaminathan at paragraph 0031); and because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 8, the James-Gupta-Zadeh-Swaminathan combination teaches the system of claim 7. James further teaches wherein the data-scrubbing module is configured to modify or remove borrower-related information, loan-product data, or borrower-related information and loan-product data that is incorrect, incomplete, improperly formatted, or duplicated to produce at least scrubbed input data and scrubbed files. (paragraph 0012, discussing a system including: a loan approval decision module that receives input from a loan applicant and collects external data including credit bureau data, bank transaction data, and social media data. The system also includes a machine learning module having a pre-processing subsystem [i.e., the pre-processing subsystem corresponds to “a data-scrubbing module”], an automated feature engineering subsystem and a feature statistical assessment subsystem…; paragraph 0013, discussing that the pre-processing subsystem pre-processes the external data by formatting, cleaning, and sampling the external data; paragraph 0014, discussing that the method include the steps of collecting external data related to the applicant and pre-processing the external data to generate processed external data; paragraph 0031, discussing that cleaning of the data is the removal or fixing of missing data… the pre-processing subsystem pre-processes the data by formatting, cleaning, and sampling the data…the pre-processing subsystem may process or analyze different instances of data, such as historic customer data, simulated data, projected data, estimated data, and/or a combination of several of the above. Pre-processing subsystem may determine simulated, estimated, or projected data to fill-in or complete data from a user based on the data from the user; paragraph 0056, discussing that the loan approval and processing system processes the customer data. This step may include pre-processing the data to: format the data; clean the data by the removal or fixing of missing data; paragraph 0079, discussing that the bank transaction data is pre-processed and cleaned up).
25. Claims 14, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over James in view of Gupta, in further view of Rosenblatt et al. Pub. No.: US 2017/0337625 A1, [hereinafter Rosenblatt].
As per claim 14, the James-Gupta combination teaches the system of claim 13, but it does not explicitly teach wherein the data-extraction module is configured to extract loan-application data from the processed sample loan applications upon decryption thereof for validation by the validation module. However, Rosenblatt in the analogous art of loan origination systems teaches this concept (paragraph 0015, discussing that in the automated process of supporting due diligence of a third party, which seeks to acquire a contract for a loan associated with a financial transaction from a second party, the data relied upon by the second party must be validated via electronic transmission from a trusted repository; paragraph 0016, discussing an electronic Data Validation System, which verifies the correspondence of processed data to that contained on documents actually used in transactions and that provides greater assurances of data integrity than is provided with conventional electronic document validation by providing a mechanism whereby, in the secondary mortgage market, the third party of the mortgage receives from the second party, an encryption key allowing the third party to acquire first set of data and perform validation on said first set of data; paragraph 0021, discussing that the electronic document validation verifies data provided by a first party to a second party. The second party provides an encryption key to a third party allowing the third party to receive an audit copy of data from the original trusted repository and to validate the data through a set of validation rules which are retrieved and applied to the data; paragraph 0024, discussing that a method for validating data using an encryption key to support end user decisions, the method comprising electronically receiving a query for a financial transaction between a first party and a second party; electronically transmitting an encryption key from the second party to a third party, electronically transmitting the encryption key from the second party to a data source and accessing a first set of a data associated with the financial transaction, electronically receiving the first set of data associated with the financial transaction and validating the first set of data associated with the financial transaction; paragraph 0092, discussing that the data validation system Server uses an encryption key to access databases to retrieve a delivered loan particular to the entered criteria related to the delivered loan stored within the data sources).
The James-Gupta combination described features related to loan processing. Rosenblatt is directed towards a using automated data validation in loan origination to evaluate credit worthiness and data reliability. Therefore, they are deemed to be analogous as they both are directed towards loan processing systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the James-Gupta combination with Rosenblatt because the references are analogous art because they are both directed to solutions for loan processing, which falls within applicant’s field of endeavor (loan-lending method and system), and because modifying the James-Gupta combination to include Rosenblatt’s feature for including wherein the data-extraction module is configured to extract loan-application data from the processed sample loan applications upon decryption thereof for validation by the validation module, in the manner claimed, would serve the motivation of improving the mortgage process for both consumers and service providers (Rosenblatt at paragraph 0007); or in the pursuit of identifying discrepancies in loan applications in order to make more educated decisions regarding loan decisions and transaction validations; and further obvious because Gupta describes that the data output component can generate customized reports such as ad hoc reports and data extracts that are specific to user requirements (paragraph 0128) and because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 18, the James-Gupta-Rosenblatt combination teaches the system of claim 17, but it does not explicitly teach wherein the development version of the unsecured loan-lending system is configured to encrypt the sample loan applications during the processing thereof. However, Rosenblatt in the analogous art of loan origination systems teaches this concept. Rosenblatt teaches:
wherein the development version of the unsecured loan-lending system is configured to encrypt the sample loan applications during the processing thereof (paragraph 0016, discussing an electronic Data Validation System, which verifies the correspondence of processed data to that contained on documents actually used in transactions and that provides greater assurances of data integrity than is provided with conventional electronic document validation by providing a mechanism whereby, in the secondary mortgage market, the third party of the mortgage receives from the second party, an encryption key allowing the third party to acquire first set of data and perform validation on said first set of data; paragraph 0021, discussing that the electronic document validation verifies data provided by a first party to a second party. The second party provides an encryption key to a third party allowing the third party to receive an audit copy of data from the original trusted repository and to validate the data through a set of validation rules which are retrieved and applied to the data; paragraph 0024, discussing that a method for validating data using an encryption key to support end user decisions, the method comprising electronically receiving a query for a financial transaction between a first party and a second party; electronically transmitting an encryption key from the second party to a third party, electronically transmitting the encryption key from the second party to a data source and accessing a first set of a data associated with the financial transaction, electronically receiving the first set of data associated with the financial transaction and validating the first set of data associated with the financial transaction; paragraph 0025, discussing a system comprising a device including a memory with an application which is configured to validate data using an encryption key to support end user decisions installed thereon, where the application is configured to receive a query for a financial transaction between a first party and a second party; electronically transmit an encryption key from the second party to a third party, electronically transmit the encryption key from the second party to a data source and accessing a first set of a data associated with the financial transaction, electronically receive the first set of data associated with the financial transaction and validate the first set of data associated with the financial transaction by apply validation heuristics and output a finding report and automatically release the second party from liability based on the finding report; paragraph 0092, discussing that the data validation system Server uses an encryption key to access databases to retrieve a delivered loan particular to the entered criteria related to the delivered loan stored within the data sources; paragraph 0097, discussing that the exemplary decision support system provides information about a transferable electronic record or group of records, including controller information and custodian information. The exemplary decision support system is an automated system for receiving information from the data sources using the encryption key).
The James-Gupta combination described features related to loan processing. Rosenblatt is directed towards a using automated data validation in loan origination to evaluate credit worthiness and data reliability. Therefore, they are deemed to be analogous as they both are directed towards loan processing systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the James-Gupta combination with Rosenblatt because the references are analogous art because they are both directed to solutions for loan processing, which falls within applicant’s field of endeavor (loan-lending method and system), and because modifying the James-Gupta combination to include Rosenblatt’s feature for including wherein the development version of the unsecured loan-lending system is configured to encrypt the sample loan applications during the processing thereof, in the manner claimed, would serve the motivation of improving the mortgage process for both consumers and service providers (Rosenblatt at paragraph 0007); or in the pursuit of identifying discrepancies in loan applications in order to make more educated decisions regarding loan decisions and transaction validations; and further obvious because Gupta describes that the data output component can generate customized reports such as ad hoc reports and data extracts that are specific to user requirements (paragraph 0128) and because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 19, the James-Gupta-Rosenblatt combination teaches the system of claim 18, but it does not explicitly teach wherein the unsecured loan-lending system includes a decryption module configured to decrypt the processed sample loan applications for subsequently extracting the loan-application data from the processed sample loan applications by the data-extraction module of the quality-assurance framework. However, Rosenblatt in the analogous art of loan origination systems teaches this concept. Rosenblatt teaches:
wherein the unsecured loan-lending system includes a decryption module configured to decrypt the processed sample loan applications for subsequently extracting the loan-application data from the processed sample loan applications by the data-extraction module of the quality-assurance framework (paragraph 0021, discussing that the electronic document validation verifies data provided by a first party to a second party. The second party provides an encryption key to a third party allowing the third party to receive an audit copy of data from the original trusted repository and to validate the data through a set of validation rules which are retrieved and applied to the data; paragraph 0024, discussing that a method for validating data using an encryption key to support end user decisions, the method comprising electronically receiving a query for a financial transaction between a first party and a second party; electronically transmitting an encryption key from the second party to a third party, electronically transmitting the encryption key from the second party to a data source and accessing a first set of a data associated with the financial transaction, electronically receiving the first set of data associated with the financial transaction and validating the first set of data associated with the financial transaction; paragraph 0025, discussing a system comprising a device including a memory with an application which is configured to validate data using an encryption key to support end user decisions installed thereon, where the application is configured to receive a query for a financial transaction between a first party and a second party; electronically transmit an encryption key from the second party to a third party, electronically transmit the encryption key from the second party to a data source and accessing a first set of a data associated with the financial transaction, electronically receive the first set of data associated with the financial transaction and validate the first set of data associated with the financial transaction by apply validation heuristics and output a finding report and automatically release the second party from liability based on the finding report; paragraph 0092, discussing that the data validation system Server uses an encryption key to access databases to retrieve a delivered loan particular to the entered criteria related to the delivered loan stored within the data sources; paragraph 0097, discussing that the exemplary decision support system provides information about a transferable electronic record or group of records, including controller information and custodian information. The exemplary decision support system is an automated system for receiving information from the data sources using the encryption key).
The James-Gupta combination described features related to loan processing. Rosenblatt is directed towards a using automated data validation in loan origination to evaluate credit worthiness and data reliability. Therefore, they are deemed to be analogous as they both are directed towards loan processing systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the James-Gupta combination with Rosenblatt because the references are analogous art because they are both directed to solutions for loan processing, which falls within applicant’s field of endeavor (loan-lending method and system), and because modifying the James-Gupta combination to include Rosenblatt’s feature for including wherein the unsecured loan-lending system includes a decryption module configured to decrypt the processed sample loan applications for subsequently extracting the loan-application data from the processed sample loan applications by the data-extraction module of the quality-assurance framework, in the manner claimed, would serve the motivation of improving the mortgage process for both consumers and service providers (Rosenblatt at paragraph 0007); or in the pursuit of identifying discrepancies in loan applications in order to make more educated decisions regarding loan decisions and transaction validations; and further obvious because Gupta describes that the data output component can generate customized reports such as ad hoc reports and data extracts that are specific to user requirements (paragraph 0128) and because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
26. Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over James in view of Gupta, in further view of Simpson, Pub. No.: US 2013/0085925 A1, [hereinafter Simpson].
As per claim 16, the James-Gupta combination teaches the system of claim 15. Although not explicitly taught by James, Gupta in the analogous art of credit application processing systems teaches wherein the validation-report module is configured to provide validation reports (paragraph 0033, discussing that the software development system can display results of these tests via the software management interface; paragraph 0069, describes provisioning results of the analytics; paragraph 0125, discussing that the data output component can provide a range of reporting options from rudimentary to comprehensive…The data output component can also deliver reports online through a user interface to meet users' general needs…; paragraph 0139, discussing that the online communication sub-engine can perform a check whether particular information from users 112a-n is valid. The online communication sub-engine can access one or more data sources, compare user-entered information to predefined information or previously stored information, and perform one or more checking routines or methods; paragraphs 0061, 0068, 0128, 0140).
James is directed towards a system and method for underwriting and processing of loans. Gupta is directed towards a credit application data processing system. Therefore, they are deemed to be analogous as they both are directed towards loan processing systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine James with Gupta because the references are analogous art because they are both directed to solutions for loan processing, which falls within applicant’s field of endeavor (loan-lending method and system), and because modifying James to include Gupta’s feature for including wherein the validation-report module is configured to provide validation reports, in the manner claimed, would serve the motivation of allowing for efficient testing and refinement of program code in a test environment and deployment of the refined program code to a live environment and facilitating application processing (Gupta at paragraphs 0034, 0108); or in the pursuit of providing efficient, and accurate aggregating and analysis of loan application data, thereby providing systems and methods that verify the completeness, accuracy, authenticity, and risk of a loan application and the data it contains; and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
The James-Gupta combination does not explicitly teach provide validation reports for the processed sample loan applications, or the loan-application data extracted therefrom, validated against the processed-as-expected loan applications. However, Simpson in the analogous art of loan processing systems teaches this concept. Simpson teaches:
provide validation reports for the processed sample loan applications, or the loan-application data extracted therefrom, validated against the processed-as-expected loan applications (paragraph 0002: “the field of invention is for a system and method that allows for the use of proprietary programming to audit and analyze loan information”; paragraph 0007, discussing a system and method for use by verification of authorities to audit, review and verify information received by applicants or individuals, such as those that have applied for loans; paragraph 0051, discussing that after all of the information is obtained, evaluated, and verified, an analysis of the transaction may be performed…A verification analysis and transaction analysis may be performed. The verification analysis may identify potentially conflicting information relied on during the original loan application process. The transaction analysis may review the original loan application transaction to determine if any problems arose that were inadequately handled. Finally, a report may be created containing all of the data obtained and/or verified and the conclusions drawn therefrom; paragraph 0060, discussing that since multiple sources of data may be used to populate a loan file (e.g., credit report, income and asset documents, etc.) some sources may be given priority over others, such that the information from one source supersede another. In certain circumstances, the data may be flagged as containing a discrepancy whether a priority determination is made or not. Each data may also be tracked as either declared or verified. The quality control processes may be used to set these preferences to compare the data received from the file process. For example, loan information obtained from the original loan documents may be a declared source of a social security number while the credit report is a verified source of that same information. For example, if the name on a W2 has a different spelling or maybe a different middle initial than the loan documents or other supporting documentation, then a flag may be set to identify the discrepancy. A log of the alternative information as source for each alternative may also be maintained. The ILR (initial loan review) may present this data in an easy to understand format for the client. The report delivery process may generate ILR report including all of the data found as well as an indication of whether it is declared or verified, its sources, and whether any discrepancies were present).
The James-Gupta combination described features related to loan processing. Simpson is directed towards a system and method for reviewing and verifying loan information. Therefore, they are deemed to be analogous as they both are directed towards loan processing systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the James-Gupta combination with Simpson because the references are analogous art because they are both directed to solutions for loan processing, which falls within applicant’s field of endeavor (loan-lending method and system), and because modifying the James-Gupta combination to include Simpson’s feature for providing validation reports for the processed sample loan applications, or the loan-application data extracted therefrom, validated against the processed-as-expected loan applications, in the manner claimed, would serve the motivation of providing an improved system and method for auditing, reviewing and verifying information including loan documents, loan files, and supporting documentation (Simpson at paragraph 0006); or in the pursuit of identifying discrepancies in loan applications in order to make more educated decisions regarding loan decisions and transaction validations; and further obvious because Gupta describes that the data output component can generate customized reports such as ad hoc reports and data extracts that are specific to user requirements (paragraph 0128) and because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Straub et al., Pub. No.: US 2016/0071208 A1 – describes that data integration can include data preparation steps such as parsing, profiling, cleansing, normalization, and parsing and standardization of the raw input data prior to record linkage to improve the quality of the input data and to make the data more consistent and comparable (these data preparation steps are sometimes referred to as ETL or extract, transform, load).
Malik et al., Pub. No.: US 2014/0143126 A1 – describes a loan analysis and management system.
Christiansen et al., Pub. No.: US 2016/0189293 A1 – describes systems and methods for inferring the performance of rejected credit applicants.
Yahi et al., Pub. No.: US 2015/0081262 A1 – describes that large-scale problems may contain millions of data points and millions of parameters.
Breeden, Joseph L. "Incorporating lifecycle and environment in loan-level forecasts and stress tests." European Journal of Operational Research 255.2 (2016): 649-658 – describes loan-level version of Age-Period-Cohort (APC) models suitable for forecasting individual loan performance at a point-in-time or for the loan’s lifetime.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DARLENE GARCIA-GUERRA whose telephone number is (571) 270-3339. The examiner can normally be reached M-F 7:30a.m.-5:00p.m. EST.
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, Brian M. Epstein can be reached on (571) 270-5389. 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.
/Darlene Garcia-Guerra/
Primary Examiner, Art Unit 3625
Prosecution Insights