WO2006020801A2

WO2006020801A2 - Technique for automatically determining and populating mortgage lending documents

Info

Publication number: WO2006020801A2
Application number: PCT/US2005/028624
Authority: WO
Inventors: Ty Jenkins; Mark Matthews; Calvin N. Slater
Original assignee: DOCUTECH Corp
Current assignee: DOCUTECH Corp
Priority date: 2004-08-11
Filing date: 2005-08-10
Publication date: 2006-02-23
Anticipated expiration: 2007-02-11
Also published as: WO2006020801A3

Abstract

Described are techniques used for automatic determination and population of forms or documents for mortgage applications. Input data is obtained which is needed for any loan application and for automatically determining particular forms for a requested loan application. Once the particular forms are determined, input data is automatically determined which is needed to populate the particular forms. The user is prompted for any missing data that may be required or optionally selected in accordance with a customization process. A rules engine is used in automatically determining forms and data used therein.

Description

TECHNIQUE FOR AUTOMATICALLY DETERMINING AND POPULATING MORTGAGE LENDING DOCUMENTS

BACKGROUND

Technical Field

This application generally relates to mortgage lending, and more particularly to automatically determining and populating documents in connection with mortgage lending.

Description of Related Art

Mortgages may be given as security for the payment of debts and may be characterized as time-honored instruments for financing the purchase of real estate, or improvements made thereon. A highly developed market exists for traditional real estate mortgages. There are many different factors that may affect which particular documents are needed for a particular mortgage transaction. For example, certain documents may be required in connection with the particular type and conditions of a loan, a particular type of investor, such as Ginnie Mae (GNMA — Government National Mortgage Association), and the like.

Existing techniques may include manually selecting and preparing paper documents for a mortgage lending transaction. Preparation and storage of copies of documents for paper transactions can be expensive and time consuming. As an alternative, electronic documents may be used. In existing systems, a user may select which one or more electronically stored documents or forms may be needed in connection with each particular mortgage lending transaction. A user may then print out the electronically stored documents to be filled out with the details of a particular transaction. One problem with existing electronic systems is the numerous documents or forms that a user may be required to view in selecting the particular ones needed for each mortgage lending transaction. The process can be time consuming and error prone. Thus, it may be desirable to have an efficient technique for automatically determining mortgage lending documents in accordance with each particular transaction. It may also be desirable to automatically determine the data required for the mortgage lending documents needed for a particular transaction and populate electronic copies of these documents with the data particular to each transaction.

SUMMARY OF THE INVENTION

In accordance with one aspect of the invention is a method for generating populated mortgage documents comprising: receiving first input; determining, in accordance with a first set of one or more rules, if additional input is needed to determine one or more documents for a mortgage transaction; determining, in accordance with a second set of one or more rules, if additional input is needed to populate said one or more documents; and generating a populated instance of said one or more documents. The method may also include in response to determining that additional input is needed to determine said one or more documents, receiving second input. The method may also include in response to determining that additional input is needed to populate said one or more documents, receiving third input. At least a portion of said first input may be imported from a data file of a predefined format. At least a portion of said first input may be obtained interactively. The method may also include prompting for additional input which is not required for said one or more documents in accordance with a customization option. The one or more documents may vary in accordance with at least one state-specified or federal-specified criteria. The determining, in accordance with a first set of one or more rules, if additional input is needed to determine one or more documents for a mortgage transaction, and the determining, in accordance with a second set of one or more rules, if additional input is needed to populate said one or more documents may be performed using a rules engine using said first and said second sets of rules as input. A document may be modified in accordance with a change in specified criteria for a mortgage. A document may be added in accordance with a change in specified criteria for a mortgage. The method may also include: storing said populated instance of said one or more documents; and generating, for each document in said populated instance, a corresponding link identifying a location at which said each document that is populated is stored. The method may also include using said corresponding link to obtain a copy of said each document included in said populated instance. The generating may be performed in accordance with a privilege level specified for a user account. The method may also include specifying at least one of: a default parameter value and an override parameter value; importing external data; if a first parameter has a first value included in said external data which is also specified as an override parameter value, replacing said first value with said override parameter value; and if said external data does not include a parameter value for said first parameter and a default parameter value is specified as a value for said first parameter, including said default parameter value in said external data.

In accordance with another aspect of the invention is a computer program product for generating populated mortgage documents comprising code that: receives first input; determines, in accordance with a first set of one or more rules, if additional input is needed to determine one or more documents for a mortgage transaction; determines, in accordance with a second set of one or more rules, if additional input is needed to populate said one or more documents; and generates a populated instance of said one or more documents. The computer program product may comprise code that, in response to determining that additional input is needed to determine said one or more documents, receives second input. The computer program product may include code that, in response to determining that additional input is needed to populate said one or more documents, receives third input. At least a portion of said first input may be imported from a data file of a predefined format. At least a portion of said first input may be obtained interactively. The computer program product may also include code that prompts for additional input which is not required for said one or more documents in accordance with a customization option. The one or more documents may vary in accordance with at least one state-specified or federal-specified criteria. The code that determines, in accordance with a first set of one or more rules, if additional input is needed to determine one or more documents for a mortgage transaction, and said code that determines, in accordance with a second set of one or more rules, if additional input is needed to populate said one or more documents may be performed using a rules engine using said first and said second sets of rules as input. A document may be modified in accordance with a change in specified criteria for a mortgage. A document may be added in accordance with a change in specified criteria for a mortgage. The computer program product may also include code that: stores said populated instance of said one or more documents; and generates, for each document in said populated instance, a corresponding link identifying a location at which said each document that is populated is stored. The computer program product may also include code that uses said corresponding link to obtain a copy of said each document included in said populated instance. The code that generates may be executed in accordance with a privilege level specified for a user account. The computer program product may also include code that: specifies at least one of: a default parameter value and an override parameter value; imports external data; if a first parameter has a first value included in said external data which is also specified as an override parameter value, replaces said first value with said override parameter value; and if said external data does not include a parameter value for said first parameter and a default parameter value is specified as a value for said first parameter, includes said default parameter value in said external data.

BRIEF DESCRIPTION QF THE DRAWINGS:

Features and advantages of the present invention will become more apparent from the following detailed description of exemplary embodiments thereof taken in conjunction with the accompanying drawings in which:

Figure 1 is an example of an embodiment of a computer system that may be used in connection with the techniques described herein;

Figure 2 is an example of an embodiment of components that may be included in a server of user system of the computer system of Figure 1 ;

Figure 3 is an example of components that may be included in an embodiment of the server system of Figure 1;

Figure 4 is a flowchart of processing steps that may be performed by an embodiment of the rules engine;

Figure 5 is an example representation of rules;

Figure 5 A is shown is a flowchart of steps of one embodiment that may be performed when there is a modification to regulations regarding mortgage documents;

Figures 6-18 are example screenshots that may be used in an embodiment of the computer system of Figure 1; and

Figure 19 is another example of an embodiment of a computer system that may be used in connection with the techniques described herein. DETAILED DESCRIPTION OF EMBODIMENTS):

Referring now to Figure 1 , shown is an example of an embodiment of a computer system according to the present invention. The computer system 10 includes a server system 12 connected to user systems 14a-14n through communication medium 18. In this embodiment of the computer system 10, the user systems 14a-14n may communicate with the server system 12, for example, to perform a data request. As will be described in more detail in following paragraphs, a user system 14a may issue a request to the server system 12 for data, for example, such as for a particular web page to be displayed on the user system 14a. The communication medium 18 may be any one of a variety of networks or other type of communication connections as known to those skilled in the art. The communication medium 18 may be a network connection, bus, and/or other type of data link, such as a hardwire, wireless, or other connection known in the art. For example, the communication medium 18 may be the Internet, an intranet, network or other connection(s) by which the user systems 14a-14n may access and communicate with the server system 12, and may also communicate with other systems that may be included in an embodiment of the computer system 10.

Each of the user systems 14a-14n and the server system 12 included in the computer system 10 may be connected to the communication medium 18 by any one of a variety of connections as may be provided and supported in accordance with the type of communication medium 18.

It should be noted that the particulars of the hardware and software included in each of the user systems 14a-14n, as well as those components that may be included in the server system 12, are described herein in more detail, and may vary with each particular embodiment. Each of the systems 12 and 14a-14n may all be located at the same physical site, or, alternatively, may also be located in more than one different physical location. The communication medium used to provide the different types of connections between the user and server systems of the computer system 10 may use a variety of different communication protocols such as SCSI, Fibre Channel, or GIGE (Gigabit Ethernet), and the like. Some or all of the connections by which the user and server systems may be connected to the communication medium 18 may pass through other communication devices, such as switching equipment that may exist including, for example, a phone line, a repeater, a multiplexer or even a satellite.

Each of the user systems may perform different types of data operations in accordance with different types of tasks. In the embodiment of Figure 1, any one of the user systems 14a-14n may issue a data request to the server system 12.

Referring now to Figure 2, shown is an example of an embodiment of a server and/or user system 100. It should be noted that although a particular configuration of system is described herein, an embodiment may include variations of the hardware and/or software described herein. Additionally, it should be noted that each system 100 may have any one of a variety of different configurations including different hardware and/or software components. Included in this embodiment of the system 100 is a processor 80, a memory, 84, one or more I/O devices 86 and one or more data storage devices 82 that may be accessed locally within the system 100. Each of the foregoing may communicate using a bus or other communication medium 90. Each of the foregoing components may be any one or more of a variety of different types in accordance with the particular host system 14a.

Each of the processors included in the system 100 may be any one of a variety of proprietary, or commercially available single or multi-processor system, such as an Intel-compatible x86 processor, an IBM mainframe or other type of commercially available processor, able to support incoming traffic in accordance with each particular embodiment and application. In one embodiment, an operating system, such as the Windows 2000 operating system by Microsoft Corporation, may reside and be executed on one or more of the user and/or server systems 100 included in the computer system 10 of Figure 1.

Computer instructions may be executed by the processor 80 to perform a variety of different operations. As known in the art, executable code may be produced, for example, using a linker, a language processor, and other tools that may vary in accordance with each embodiment. Computer instructions and data may also be stored on a data storage device 82, ROM, or other form of media or storage. The instructions may be loaded into memory 84 and executed by processor 80 to perform a particular task.

Referring back to Figure 1, the computer system 10 may be used in connection with generating mortgage lending documents as described in more detail below.

In connection with generating mortgage lending documents, different parties involved may be considered. The parties may include, for example, a title company, a lender, an investor and a broker. The title company may be, for example, a law firm or other entity that handles the closing transaction. The lender may be, for example, a bank, mortgage company, or other lending institution. The investor may be an entity that is in the business of purchasing mortgages such as, for example, GNMA and other organizations. The broker may be the entity that represents the lender. In connection with preparing documents for a mortgage lending transaction, the foregoing parties may each require different documents. The documents may vary with a particular type of party, such as the particular investor. The documents may also vary with particulars of the loan itself, such as whether the loan is a VA loan, an FHA loan, or a Conventional loan, and whether particular state or other federal regulations are invoked.

In one embodiment, a customer or user on a user system 14a of a bank or other lending institution may communicate with a server system 12 to generate mortgage lending documents in accordance with user input. The user input may include, for example, information about a particular loan type, information about a particular investor, information common to all loans, such as the amount to be borrowed, the address of the property, and the like. A user system 14a may issue a request to display one or more web pages retrieved from the server system 12. User input may be obtained, for example, interactively through a graphical user interface (GUI) implemented using the web pages retrieved from the server system 12. In response, software hosted on the server system 12 (as may be located at a website) may be executed to automatically determine the particular documents needed in accordance with the user input. Additionally, the software as may be hosted and executed on the server system 12 may also determine the data used for populating the particular documents and accordingly produce a populated instance of the particular documents. The processing performed in connection with generating mortgage lending documents is described elsewhere herein in more detail.

In accordance with another embodiment, the user or customer may have the software for generating the populated mortgage lending documents installed locally on a computer system. In other words, the software may be executed locally on a user system, or other system in a network including the user system, rather than having the software hosted on the server system 12.

In connection with any of the foregoing, user input may be entered interactively, such as using a GUI, a data file, or some combination thereof. For example, an initial set of information about a particular mortgage lending transaction may be stored in a data file. The software may determine that additional information is needed in determining the documents and/or populating the documents for the mortgage lending transaction. The additional information may be entered interactively after a user is prompted for the data.

Use of the software to generate populated mortgage documents as described herein may result in billing charges to the users or customers. The billing charges may be determined in any one or more different ways. For example, a user may pay a flat rate to use the software for a specified time period (e.g., monthly, annually, or quarterly) on a specified number of computer systems. Billing charges may also be determined on a per transaction basis. The information about the billing charges incurred on a per transaction basis may be communicated to a party to whom charges are paid for use of the software in any one of a variety of different ways. For example, data may be sent from the user system to the server system in response to a request from the server system. Data may be automatically reported from the user system to the server system on a periodic basis, such as a monthly basis, and the like. In return for the charges or fees paid, the users may receive updated documents, new documents, software maintenance, and the like. The users may obtain the documents, software updates, and the like, using any one or more techniques known to those of ordinary skill in the art. For example, documents and/or software updates may be downloaded using the Internet or other connection from the server system 12.

Referring now to Figure 3, shown is an example of components that may be included in an embodiment of the server system 12 of Figure 1. It should be noted that in an embodiment in which the software used to produce populated mortgage documents is included locally with respect to a user system or a network including the user system, the components 150 of Figure 3 may be stored locally on a user system or within components included in the network that includes the user system. As known to those of ordinary skill in the art, other arrangements and configurations than as described herein are possible and should not be construed as a limitation of the techniques described herein.

In one embodiment, the components 150 may include a rules file 160, user input

162, a database 164, a rules engine 166, populated mortgage documents 170 and an administrative component 152. The administrative component 152 may include an administrative module 154 that makes use of other administrative data 156. The administrative component 152 may be used in performing administrative tasks in addition to producing additional rules for the rules file 160 and updating the database 164 of electronic documents and other data. Also included in an embodiment of 150 may be raw data file(s) 180 and an import module 182 used to import data from third parties for use with other components of 150.

As will be described below, mortgage data may come from one or more different sources. In one embodiment, an initial set of mortgage data may be provided from an external source or third party as raw data 180. Data may be also be entered as user input 162, such as through an interactive graphical user interface (GUI). The raw data 180 may be imported for use by import module 182. The import module may perform a variety a different functions including, for example, converting one or more types of raw data input files into a format compatible for use with the database 164, and performing raw data input processing including, for example, cleaning and/or validating the raw input data. The particular types and formats of data that may be imported may vary in accordance with each embodiment as well as the particular input processing performed, if any.

In one embodiment, incoming data may be translated from one or more different types of formats to a single format used internally by the system components, such as the rules engine. It should be noted that the imported data is stored in this example in a database 164. Other embodiments may store the imported data in any one or more locations on the server system or other system upon which the components of 150 may be executed. An embodiment may obtain mortgage data using imported data, interactively entered data, or some combination thereof.

The rules engine 166 may take as input rules 160 that may be used in determining particular mortgage documents needed in accordance with user input 162 and/or imported data included in database 164. Rules 160 may also be used by the rules engine 166 in determining the data necessary to populate the particular mortgage documents needed in accordance with the particular mortgage transaction. As another input to the rules engine 166, data may come from a database 164. The database 164 in this example may include, for example, imported loan data. It should be noted that the imported loan data may include all or a portion of the data used by the rules engine 166 in connection with producing populated mortgage documents 170. In this example, the database 164 may also include electronic documents. The electronic documents in the database 164 may include the template or electronic document which has not yet been populated with user input data for a particular loan transaction. As an output, the rules engine 166 may produce populated mortgage documents 170. The populated mortgage documents 170 may be a particular instance of an electronic document retrieved from the database 164 which has been populated with data from the loan data of the database 164 and/or user input 162. An embodiment may produce populated mortgage documents 170 which are in any one or more different output types supported by an embodiment. The rules 160 may be stored in any one of a variety of different data formats known to those of ordinary skill in the art. In one embodiment, the rules 160 may be stored in a table-like format expressing relationships that will be described elsewhere herein in more detail using a database package, such as the Microsoft Sequel Server software. Other embodiments may use other formats and software packages than as described herein.

Included in this embodiment 150 is an administrative component 152. It should be noted that the administrative component 152 may be characterized as an optional component used in connection with administration of other elements of 150. The administrative component 152 includes an administrative module 154 and other data 156. The administrative module 154 may be used, for example, in user account management, maintaining electronic documents as stored within the database 164, maintaining the rules file 160, and other tasks. The electronic documents included in the database 164 in this embodiment may be modified, for example, in connection with a change to a rule or regulation at the state and/or federal level. Additionally, a change to a regulation or rule may also require new electronic documents to be created and added to the database 164. It should also be noted that the other data 156 used by the administrative module 154 may include, for example, user account information defining particular privilege levels used in connection with user authentication and control in performing a user request issued to the server system 12.

Although the loan data and the electronic documents are shown in 150 as being included in a single database 164, the data may actually be included in more than one database, file, or other data format and data container known to those of ordinary skill in the art. For example, an embodiment may include third party loan data in a first database and electronic documents in a second different database.

In connection with the information used by the rules engine 166 to generate populated mortgage documents 170, the information may generally be classified into three different categories. A first category includes data which is needed for any particular loan transaction. In other words, there may be a set of data that is required independent of the particular investor, loan type, and the like. Such information may include, for example, the name of the borrower, the amount of the loan, the address of the property for which financing is sought in connection with a mortgage, and the like. A second category of information may be used in determining the particular documents or forms needed. In other words, a particular set of data may be used in determining the particular documents or forms that are needed for a loan transaction. As an example, a loan may be a Conventional loan, a VA loan, or an FHA loan. One of the foregoing types of loans may be required in connection with processing any particular transaction for a mortgage. Depending on which of the foregoing loan types are specified, one or more documents may be determined by the rules engine 166 in accordance with data from the rules 160. Similarly, additional parameters associated with a Conventional loan, a VA loan, and a FHA loan may also determine other documents or forms that may be used. The third category of information includes additional data that may be used for populating mortgage documents 170. This additional data may be used to populate fields of the electronic copies of mortgage documents within the database 164. The fields may be optional fields and/or required fields as determined in accordance with each mortgage document. An example of this is described elsewhere herein in more detail.

Referring now to Figure 4, shown is a flowchart 200 of processing steps that may be performed by the rules engine 166 in connection with producing populated documents such as the populated mortgage documents 170 of Figure 3. At step 202, mortgage data is received. It should be noted that the input received at step 202 may come from interactive data entry, and/or from imported data that may be stored in the database 164 as described elsewhere herein. At step 204, any additional data cleansing and/or data validation of user input may be performed. For example, in the event that data is interactively entered by a user, additional data cleansing and/or validation may be performed. At step 206, a determination is made as to whether all generic data and all data needed to determine the particular mortgage documents has been received. If not, control proceeds to step 220 where the user is then prompted for any additional data. It should be noted that, as described elsewhere herein, a set of data may be required for all types of mortgages independent of loan type, investor, and the like. This may be referred to herein as generic data. Control then proceeds to step 204 to perform any additional data cleansing and/or data validation of the user input. This processing continues at steps 206, 220 and 204 until a YES determination is made at step 206. At this point, processing proceeds to step 208.

At step 208, the data required and/or desired optional data to populate the particular documents for this transaction. Data fields within the documents determined at step 206 processing may include required data as well as optional data. The optional data is not required to complete the forms but may be previously designated as desirable. An embodiment may include one or more customizations. As part of this customization process, one or more optional fields may be selected as preferably included in the form. In other words, even though not required for completion of a form, it may be desirable to include particular data elements used to populate one or more fields. In an embodiment, a user may be prompted to enter data for one or more optional data fields designated as preferred (using the customization option) in addition to any required data fields. At step 208, the required data and any designated optional data are determined. At step 210, a determination is made as to whether additional data is needed for the required and/or desired optional fields in order to populate the documents in accordance with the required and/or optionally specified fields. If so, control proceeds from step 210 to step 214 where the user is prompted for any additional data. Control then proceeds from step 214 to step 208. At step 210, if a determination is made that additional user input is not needed and/or desired in accordance with populating the documents, control proceeds to step 212 to obtain the electronic documents and populate them at step 216 in accordance with the user input. It should be noted that functionality associated with performing customizations described herein may be optionally included in an embodiment.

Referring now to Figure 5, shown is a representation 300 of the rules 160 of Figure 3. It should be noted that 300 may characterized as a rules schema or representation of the information included in the rules 160. Recall, that as described elsewhere herein, the rules 160 may be used in determining the particular mortgage documents needed, and additionally determining the information needed or desired to populate the particular mortgage documents. In this example, the representation 300 includes a rules file 160 organized into three sections. A first section 302 includes rules for determining information needed for all transactions. The information needed for any type of transactions as specified in accordance with section 302 may include that data which is used in all transactions independent of loan type, investor, and the like. Such information may include, for example, loan amount, borrower name, and the property address.

A second section 304 includes rules for determining information needed to determine the particular mortgage documents for a loan transaction. A rule included in section 304 may have a format specified in record 310 which specifies that one of the following of Conventional, "Conventional", "VA" or "FHA", is needed in connection with determining mortgage documents. In other words, in connection with loan information input either through imported loan data stored in the database 64 and/or user input, there must be some indication that the loan is either a Conventional, a VA or an FHA loan. If one of the foregoing three is not specified in accordance with the rule of record 310, the user will be prompted to specify one of these particular types. A rule in section 304 may also be of a format in a conditional statement as the if-then statement of record 312. In this example, once one of "Conventional", "VA" or "FHA" indicators from record 310 is specified, records 312 and 314 set forth additional rules for additional data required in determining particular mortgage documents.

The third section 306 includes rules for determining information required and/or optional data that may be desired to populate particular mortgage documents specified in section 304. Section 306 may include rules specifying the one or more required and/or desired optional data fields for each mortgage document. For example, record 316 indicates that if a loan type of VA is indicated, document "VA document 1 is used. For document "VA document 1", data values are required for data fields designated as: required_data 1 through required_data n. Record 318 indicates that if a loan type of VA is indicated, "VA document 2" is needed for the particular mortgage transaction and "VA document 2" requires required_data 1 and an additional optional_data 1 is desired as indicated in accordance with a previously executed customization option. In other words, the record 318 includes the optional_data 1 as indicated in record 318 in accordance with a customization feature used by a customer in which optional data 1 field has been specified as desired. Accordingly, when the rules engine 166 processes the record 318, the user will be prompted for data to populate the option_data 1 field if such data has not yet been entered.

It should be noted that the information specified using the rules of section 302 may or may not be used in connection with determining particular mortgage documents, and may or may not be used in populating particular mortgage documents. Similarly the information specified using the rules of 304 may or may not be included as actual data items in a populated form.

The representation 300 may include rules in any one of a variety of different formats. In this example, a rule may be of a first format where, if a data element is included in a rule, such as loan amount, borrower name, property address, and the like in section 302, this indicates that this data element is required. A rule in the representation 300 may also specify a set of data elements of which one or more may be specified. This is indicated, for example, by the record 308. A rule may also be of a format as indicated in record 310 where exactly one of a set of data elements included in the rule may be supplied. A rule may also include a conditional statement, such as indicated by records 312 and 314, which may be evaluated by the rules engine to conditionally determine data elements. In this example with reference to 312 and 314, if the object of the "if portion evaluates to true, the object of the "then" portion is determined as being needed. Elements 316 and 318 include another variation of an if/then conditional that may be included in an embodiment, hi this example, the rules in 306 may be used for a dual purpose. A rule in 306 may be used to determine a particular document and also the data elements for that particular document. For example, with reference to 316 and 318, if the loan type of "VA" has been specified, both documents "VA documentl" and "VA document 2" are required. The remainder of the "then" portion of each rule may be used to determine the particular required and/or optional data elements for each document. It should be noted that the particular format of the rules represented in 300 may vary in accordance with each embodiment. Additionally, the particular rules and how they are processed may also vary with each embodiment in accordance with the particular software and/or hardware.

The rules engine 166 of Figure 3 may use the rules file and evaluate the rules therein in connection with performing the steps of flowchart 200 of Figure 4 to provide for automated generation of populated mortgage documents. When a modification is made to an existing document or a new document is required in accordance, for example, with a federal or state law, rule or regulation, uniformity is guaranteed for subsequently populated sets of documents. A central repository may be maintained of the template or electronic documents which are populated.

An embodiment may also include other customizations that may be specified in connection with the rules file. For example, one embodiment may include one or more rules defining document override conditions. Two documents, document XYZ and document ABC, may both be determined as needed in a set of documents for a particular loan using a set of rales. Also included in a set of rules may be a document override rule stating that:

IF document ABC and XYZ are included in resulting set of documents for a loan THEN ABC replaces XYZ causing document XYZ to be disregarded or removed from the resulting set of documents.

Referring now to Figure 5 A, shown is a flowchart 450 of steps of one embodiment that may be performed when there is a modification to regulations regarding mortgage documents. The modification may be an amendment to an existing regulation as well as a new regulation. In response to this modification, the components 150 of the server system 12 may be accordingly updated so that mortgage documents subsequently generated will be in accordance with this modification. At step 452, a determination is made as to the impact of a regulation modification on mortgage documents. Processing of step 452 may include, for example, a determination as to what fields are added/removed/modified in existing mortgage documents, a determination as to which mortgage documents are removed, and a determination as to what new mortgage documents need to be added. At step 454, a user logs in to perform administrative functions associated with the regulation modification. At step 456, an administration menu may be displayed with one or more administration options. The administrator may now make one or more selections in order to update the mortgage documents in accordance with the regulation modification. At step 458, a determination is made as to whether there are new documents to be added in accordance with the regulation modification. If so, control proceeds to step 460 where the new document(s) are configured. Part of the configuration process includes specifying information as for what types of loans this new document is included. Additionally, part of the configuration may also include specifying the document fields, format of the data to be included in each field, whether the field is required or optional, and the like. At step 462, any additional rules or modification to existing rules are made in accordance with the new document. The rule modification may include, for example, adding a new rule to section 304 of the rules file specifying when the particular mortgage document is to be included in a set of mortgage documents, and adding new rules to section 306 in accordance with the particular fields of the document. At step 464, a new template for the additional document is created an added to the database or other central repository where the mortgage documents are stored for later retrieval and use with generating populated mortgage documents. Control proceeds to step 466 from step 464. If at step 458, a determination is made that no new mortgage documents are to be added, control proceeds directly to step 466.

At step 466, a determination is made as to whether an existing mortgage document is to be modified in accordance with the regulation modification. If so, control proceeds to step 468 where the configuration for that particular document is modified if needed. At step 470, any update needed is performed on the rules file. At step 472, modifications are made to the document template as stored in the database or other document repository. Control proceeds from step 472 to step 474. If at step 466 a determination is made that no modifications to existing mortgage documents are necessary, control proceeds directly to step 474.

At step 474, a determination is made as to whether all mortgage document additions and/or modification are complete. If so, processing stops. Otherwise, control returns to step 456.

It should be noted that one or more administrative menu options may be selected and included in an embodiment in performing the steps of flowchart 450. One embodiment is described in more detail in following paragraphs. The update/modification to the rules may be performed in an automated fashion, manual fashion, or combination thereof. For example, an embodiment may use software to generate the rules in accordance with the configuration information about when the document is to be included in a set of mortgage documents for a loan, what information is needed to make this determination, what fields are required and/or optional for the document, and the like.

In one embodiment, the rules may be stored in a set of one or more tables in a database. When performing different administrative functions, such as configuring a document as described elsewhere herein in more detail, a system may also include options for displaying corresponding rules as may be later processed by the rules engine.

What will now be described in connection with Figures 6 through 18 are various screen shots that may be displayed on an output terminal or device of a user system in response to a data request for information from a server system 12. The screen shots described in following paragraphs may also be used in connection with obtaining particular user input required and/or desired by the server system 12 in connection with producing the populated mortgage documents described herein. It should be noted that the screen shots described herein are examples that may be used in connection with producing populated mortgage documents. Other embodiments may use other screen shots and/or other forms of user interface in connection with obtaining user input data.

Referring now to Figure 6, shown is a screen shot 400 that may be displayed in connection with obtaining a particular user name and password. The screen shot 400 may be the first screen displayed to a user accessing the website of the server system 12 of Figure 1. The user name may be, for example, a user account of a particular bank, mortgage company, or other customer using the software described herein in order to obtain populated mortgage documents. Upon entry of a user name and password, data may be communicated from the user system to the server system 12. In one embodiment, the server system 12 may verify using, for example, the accounting module described herein, that a particular user name and password are valid resulting in a subsequent transmission and display of data by a user system as shown in screen shot 500 of Figure 7.

In screen shot 500 of Figure 7, a selection may be made to either begin processing and importation of a new loan, or to continue processing an existing loan which has already been loaded into the server system 12. As will be described in more detail in following paragraphs, the option in this example for beginning a new loan includes importing data into the database 164 from an external or third party. An existing loan in this example may be characterized as loan data that has already been imported and loaded into the database 164 of Figure 3.

Referring now to Figure 8, shown is a screen shot 600 that may be displayed in response to selecting the existing loan option from Figure 7. Selection of continuing with an existing loan in this example results in display of the screen shot 600 to display information about loans that have already been loaded into the server system 12 and stored in the database 164. In this screen shot 600, a row or record of information is displayed for each of the existing loans. In this example, no work has been done in connection with generating mortgage documents associated with each of these existing loans displayed in the screen shot 600. In one embodiment, an option may be provided such that a user may view the actual imported data prior to performing any additional processing described herein for generating populated mortgage documents. This option of viewing the data may be performed in response to selection of a "view" option as indicated by an entry in the worksheet column 602 of screen shot 600. Selection of such an option in one embodiment results in displaying the screen shot 700 of Figure 9.

Referring now to Figure 10, shown is a screen shot 800 that may be displayed in response to selection of the new loan option from the main menu of Figure 7. In response to selection of a new loan processing, screen shot 800 displays the one or more loans which have not yet been imported into the system described herein into the database 164. The data listed in screen shot 800 may include a row of information for each particular loan. A separate data file may exist for each particular loan, or a single data file may include data corresponding to multiple loans. This may vary in accordance with the form that data has been provided by a third party system to be imported.

It should be noted that screen shot 800 may include one or more fields 802. In this example, a user may specify information optionally in one or more of the data fields 802. Subsequently, a loan may be selected for importing by selecting one of the rows in screen shot 800. As the data for a particular loan number is imported, the one or more data items in 802 may affect the content of the imported data. The values specified in the one or more fields of 802 may act as an override perimeter for any data specified in an imported loan data set. This may occur, for example, if an imported data file for a loan includes a lender value for the lender data field, and a lender value is also specified in field 802. In the foregoing example, there are two values provided for the same data field which in this instance is lender. The value specified in field 802 overrides the value which may also exist and be duplicated in the imported data for a particular loan. In the event that the data imported does not include duplicate information for a value of a data field in 802, the value specified for a data field in 802 may alternatively be a default value. In other words, for a set of loan data being imported, no data value may be specified for the lender data field or the investor data field. Accordingly, in this instance, the values of "ABC Lending" for the lender data field and "United Trust Bank" for the investor data field specified in 802 may act as default values and be added to the data imported from the third party.

It should be noted that as part of the importing of the data from the data file, data validation and/or data cleansing may also be performed, for example, to remove extraneous characters, perform uniform capitalization, and the like. Once the data has been imported and optionally cleansed and/or validated, as may vary in accordance with each embodiment, the data may be stored in the database 164 as described in connection with Figure 3. Subsequently, the rules engine 166 may then operate and begin the processing in accordance with the input data using the steps of flowchart 200 of Figure 4.

Referring now to Figure 11, shown is a screen shot 900 that may be used in obtaining missing or invalid fields required for a particular loan. It should be noted that the particular data items prompted for in connection with screen shot 600 may include a combination of those fields required for all transactions, to determine the particular documents needed for a loan, and to populate the mortgage documents. Alternately, an embodiment may display multiple screens in connection with obtaining the data.

Referring now to Figure 12, shown is a screen shot 1000 that may be displayed in connection with obtaining one or more required and/or optional data values. Note that in this example, the "output type" field 1002 and the "fee" 1004 field are indicated as required by the exclamation point in the required column 1006. In screen shot 1000, the closing conditions or instructions are not a required data field, but rather an optional data item that has been indicated as desirable in accordance with a customization option described elsewhere herein. A customization option has been performed in this example so that, although the closing condition or instruction is not required in accordance with rules, regulations and the like, for a form in accordance with the Conventional fixed 30 year mortgage, the user is prompted to enter closing conditions or instructions. Such a customization may be performed to prompt for optional data values, for example, if the data field may be overlooked or may otherwise be desirable for inclusion in the form. It should be noted that in an embodiment which does not 2005/028624

include such a customization option, the only fields that may be displayed in screen shot 1000 are those which are indicated as required. It should also be noted that once the required fields have been entered, the user may not be repeatedly prompted for the optional data fields that have been intentionally omitted for the optional fields, such as the closing conditions or instruction. In other words, the user may be prompted once for that selected information which is optional. The user may choose to intentionally omit and not include optional information, such as the closing condition or instructions, when prompted. Other embodiments may perform other processing than as described herein.

Referring now to Figure 13, shown is a screen shot 1100 that may be used in connection with displaying fees associated with this particular loan. It should be noted that display of the fee screen 1100 may also be included as a customization option. In other words, a customer or user may select to have the fee screen 1100 automatically displayed after all of the required and/or desirable input is obtained from the user data prior to producing the mortgage documents. In one embodiment with this customization option enabled for fee screen display viewing and/or modification, the screen shot 1100 may be automatically displayed in response to closing out of screen shot 1000 of Figure 12.

It should be noted that the particular fees displayed in screen shot 1100 are known to those of ordinary skill in the art as fees that may be associated with processing a mortgage. Screen shot 1100 optionally provides the functionality that may be used in connection with reviewing and/or modifying the particular fee values in an embodiment. It should be noted that the option for display of a fee screen as well as whether a modification may be made to a particular fee value and other values of an input field described herein for screen shots may be determined in accordance with a particular privilege or access for a user name and password. This information may be maintained and determined by the administration module 154 using accounting data, such as user name and associated permissions, that may be stored in element 156. In other words, different screen displays as well as different allowed operations associated with a screen display may vary in accordance with a particular user name, password and associated access or privilege level as determined by the administration component 152.

Referring now to Figure 14, shown is a screen shot 1200 of all of the populated mortgage documents as produced by the rules engine 166. The screen shot 1200 includes a list of all of the different mortgage documents which have been identified and populated in accordance with the previously entered user data. The screen shot 1200 includes different options in connection with processing the mortgage documents produced 170. An option may be selected to print the documents. Additionally, an option may be selected to e-mail links to the documents created and populated as a result of the processing described herein. In response to selecting the e-mail option in screen shot 1200, screen shot 1300 of Figure 15 is displayed. The screen shot 1300 of Figure 15 provides for entering user information including an e-mail address and subject line. Within the body of the e-mail in this example may be links to the particular generated mortgage documents stored within the server system 12. In other words, in one embodiment, the populated mortgage documents 170 may be stored in another database or other data container for retrieval at a later date. In one embodiment, the documents may be stored in any one of a variety of different formats including, for example, pdf.

Referring now to Figure 16, shown is a screen shot 1400 that displays an administrative menu and operations that may be included in an embodiment. The administrative menu may be displayed in response to invoking the administrative component 152. The administrative screen shot 1400 may be displayed and available only for those users, for example, which have administrative access or privilege. An embodiment may provide varying degrees of granularity of administrative access that may be specified for a particular user name. For example, a first type of administrative user may be allowed to perform only a portion of those options displayed on an administration menu. A second type of administrative user may be allowed to perform all operations displayed. 5 028624

An administrative option may also exist in connection with configuring documents, such as element 1402. Such an administrative option may be used, for example, to update the database 164 with new or modified versions of electronic documents in accordance with rule and regulation changes, and the like. The configured documents option 1402 may also be used in connection with modifying the rules 160. Recall that the rules 160 determine what particular inputs are required to determine the documents needed. Additionally, rules are also specified in connection with determining the particular data fields which are required and/or optionally desirable for a particular document. Accordingly, if a particular documents format changes, or a new document is needed, the appropriate rule or rules 160 may be modified and/or created as well. The rules may be generated by manual entry and/or in an automated fashion by reading the various forms and associated document configurations.

It should be noted that an embodiment may also perform different customization options for validity checking of a particular loan. In one embodiment, a customization option may be enabled to perform validity checking or determination as to whether a particular loan is categorized as a high cost loan. For example, in accordance with a particular loan amount and the particular finance fees associated with a loan, regulations may determine whether this loan will be categorized as high cost. This is just one type of additional validity checking or processing that may be performed on a loan or mortgage after processing is complete. Such validity checking and categorization of a loan may be useful, for example, in determining the salability or marketability of a mortgage with respect to particular investors or types of investors and the like.

Referring now to Figure 17, shown is a screen shot 1500 that may be displayed in connection with document configuration. As described herein, each mortgage document is initially configured and may also be reconfigured. A first document may be configured using screenshot 1500 in which six fields and associated values are used in determining when the first document should be included for a loan. Referring now to Figure 18, shown is a screen shot 1600 that may be used for another second document configuration. In 1600, whether the second document is included in mortgage documents depends on Document Package Type and Loan Purpose. This second document may be included for any loan that is a closing package for any Loan Purpose (Allow Any). In one embodiment importing data, both

Document Package Type and Loan Purpose are fields having values included in the imported data file. Document Package Type is a classification of what type of loan closing is being performed. With reference to this example, Figure 18 is related to processing when the Document Package Type is "Closing" corresponding to the actual closing of the loan. Figure 18 also lists other Document Package Types, such as Initial Disclosure, corresponding to when a loan is being applied for. Each type of Document Package Type corresponds to a different set of documents.

It should be noted that as described herein, an embodiment may include a customization option to enable or disable one or more different types of customizations. Such customizations may include, for example, the optional field designation or selection for which the user is prompted for optional input data. Customization options may also include selective display of a fee screen to users with particular privileges, and additional validity checking, such as that associated with determination of whether a loan is "high cost". These and other customization options may be included in an embodiment in accordance with the functionality of a particular system, and the particular rules and regulations supported and embodied within a system described herein.

It should be noted that the electronic documents or forms included in the database 164 which are used as templates in the example described herein and subsequently populated with data particular to a mortgage transaction may be in any one of a variety of different formats. In one embodiment, the electronic documents or forms are in XML format. The forms themselves may include any type of XML statements. As described herein, an embodiment may include support for one or more different import types and one or more different output types for the mortgage documents generated as 170. In one embodiment, supported output types may include, for example, xHTML documents, SmartDoc documents, PDF documents, and HP PCL (Printer Control Language) documents. In one embodiment, supported import types may include, for example, documents in accordance with the following formats: Datatrac, Calyx, Contour, XML documents using the Mismo standard as described as www.mismo.org. The electronic documents in template format within database 164 as well as the populated mortgage documents 170 may be in any one of a variety of different formats that may vary in accordance with each particular embodiment.

The foregoing describes a system and methods for producing populated documents on a given set of input data. The amount of processing performed may vary in accordance with the input data in a variety of different ways. The amount of processing depends on the complexity of the mortgage transaction as specified using the input data. Additionally, the amount of processing depends on the completeness of the input data. In one embodiment, the completeness of the data may vary in accordance with the source of the imported data, such the various loan origination systems (LOS). The foregoing may be used in generating a set of mortgage documents in accordance with a set of compliance conditions including, for example, federal and/or state laws, regulations, codes, and the like. The set of mortgage documents may also vary in accordance with the lender, investor and loan type.

The foregoing may be used in an embodiment in connection with Web Services and/or Web Applications, both known to those in the art and as illustrated in an embodiment in Figure 19. Web Services provides for a user, such as element 1708, requesting a web service in which a client may handle obtaining data from a user and then making a request of a Webserver (1716) to perform the service. The request may be made using, for example, XML-based web services. A request may also be made from a client Web Application 1702 to a Web Application 1714 providing a web-based interface to generate the mortgage documents. The Web Application 1714 may obtain additional user input, for example, using screens to prompt for such information. Data 28624

may be imported from the LOS system 1704 for use directly or indirectly. In this example, data from the LOS database 1706 may be exported to a file 1710 prior to importation. Alternatively, data from 1706 may be directly accessed for use, for example, as part of the processing a request from a WebService API User request 1708.

In Figure 19, as illustrated by arrow 1730, the Web Application 1714 may retrieve the LOS data 1706 directly without using any third-party software to access the LOS data. This data flow of arrow 1730 is illustrated, for example, with reference to Figure 10 described elsewhere herein. Arrow 1734 illustrates that an embodiment may also have the Web Service 1716 import data from the LOS Export file 1710.

It should be noted that Figure 19 illustrates multiple ways in which loan data may be accessed by the system 12. An embodiment may include any one or more of those described herein as well as other ways not illustrated herein which may vary with each embodiment.

Although the foregoing describes techniques that are used in connection with mortgage documents, the foregoing techniques may also be used in connection with other industrial applications using documents such as, for example, applications in the legal, medical, and real estate areas.

While the invention has been disclosed in connection with preferred embodiments shown and described in detail, their modifications and improvements thereon will become readily apparent to those skilled in the art. Accordingly, the spirit and scope of the present invention should be limited only by the following claims.

Claims

What is Claimed is:

1. A method for generating populated mortgage documents comprising: receiving first input; determining, in accordance with a first set of one or more rules, if additional input is needed to determine one or more documents for a mortgage transaction; determining, in accordance with a second set of one or more rules, if additional input is needed to populate said one or more documents; and generating a populated instance of said one or more documents.

2. The method of Claim 1, further comprising: in response to determining that additional input is needed to determine said one or more documents, receiving second input.

3. The method of Claim 2, further comprising: in response to determining that additional input is needed to populate said one or more documents, receiving third input.

4. The method of Claim 1, wherein at least a portion of said first input is imported from a data file of a predefined format.

5. The method of Claim 1, wherein at least a portion of said first input is obtained interactively.

6. The method of Claim 1, further comprising: prompting for additional input which is not required for said one or more documents in accordance with a customization option.

7. The method of Claim 1, wherein said one or more documents varies in accordance with at least one state-specified or federal-specified criteria. 005/028624

8. The method of Claim 1, wherein said determining, in accordance with a first set of one or more rules, if additional input is needed to determine one or more documents for a mortgage transaction, and said determining, in accordance with a second set of one or more rules, if additional input is needed to populate said one or more documents are performed using a rules engine using said first and said second sets of rules as input.

9. The method of Claim 7, wherein a document is modified in accordance with a change in specified criteria for a mortgage.

10. The method of Claim 7, wherein a document is added in accordance with a change in specified criteria for a mortgage.

11. The method of Claim 1 , further comprising: storing said populated instance of said one or more documents; and generating, for each document in said populated instance, a corresponding link identifying a location at which said each document that is populated is stored.

12. The method of Claim 11, further comprising: using said corresponding link to obtain a copy of said each document included in said populated instance.

13. The method of Claim 1, wherein said generating is performed in accordance with a privilege level specified for a user account.

14. The method of Claim 4, further comprising: specifying at least one of: a default parameter value and an override parameter value; importing external data; if a first parameter has a first value included in said external data which is also specified as an override parameter value, replacing said first value with said override parameter value; and if said external data does not include a parameter value for said first parameter and a default parameter value is specified as a value for said first parameter, including said default parameter value in said external data.

15. A computer program product for generating populated mortgage documents comprising code that: receives first input; determines, in accordance with a first set of one or more rules, if additional input is needed to determine one or more documents for a mortgage transaction; determines, in accordance with a second set of one or more rules, if additional input is needed to populate said one or more documents; and generates a populated instance of said one or more documents.

16. The computer program product of Claim 15, further comprising code that: in response to determining that additional input is needed to determine said one or more documents, receives second input.

17. The computer program product of Claim 16, further comprising code that: in response to determining that additional input is needed to populate said one or more documents, receives third input.

18. The computer program product of Claim 15, wherein at least a portion of said first input is imported from a data file of a predefined format.

19. The computer program product of Claim 15, wherein at least a portion of said first input is obtained interactively.

20. The computer program product of Claim 15, further comprising code that: prompts for additional input which is not required for said one or more documents in accordance with a customization option.

21. The computer program product of Claim 15, wherein said one or more documents varies in accordance with at least one state-specified or federal-specified criteria.

22. The computer program product of Claim 15, wherein said code that determines, in accordance with a first set of one or more rules, if additional input is needed to determine one or more documents for a mortgage transaction, and said code that determines, in accordance with a second set of one or more rules, if additional input is needed to populate said one or more documents are performed using a rules engine using said first and said second sets of rules as input.

23. The computer program product of Claim 21, wherein a document is modified in accordance with a change in specified criteria for a mortgage.

24. The computer program product of Claim 21 , wherein a document is added in accordance with a change in specified criteria for a mortgage.

25. The computer program product of Claim 15, further comprising code that: stores said populated instance of said one or more documents; and generates, for each document in said populated instance, a corresponding link identifying a location at which said each document that is populated is stored.

26. The computer program product of Claim 25, further comprising code that: uses said corresponding link to obtain a copy of said each document included in said populated instance.

27. The computer program product of Claim 15, wherein said code that generates is executed in accordance with a privilege level specified for a user account.

28. The computer program product of Claim 18, further comprising code that: specifies at least one of: a default parameter value and an override parameter value; imports external data; if a first parameter has a first value included in said external data which is also specified as an override parameter value, replaces said first value with said override parameter value; and if said external data does not include a parameter value for said first parameter and a default parameter value is specified as a value for said first parameter, includes said default parameter value in said external data.