Abstract:
The present invention provides a versatile, automated system for processing regulated applications in a convenient, easy and economical manner. The system of the present disclosure provides an operational kernel that consolidates all aspects of applying for, processing, underwriting, and approving a user application subject to regulation. The system provides various structures, engines and methods for consolidating all aspects of application, handling, administration and approval processes within a unified operational environment.

Description:
PRIORITY CLAIM 
       [0001]    This application claims priority of U.S. Provisional Application No. 61/721,357, filed Nov. 1, 2012 and U.S. Provisional Application No. 61/805,944, filed Mar. 28, 2013. 
     
    
     TECHNICAL FIELD OF THE INVENTION 
       [0002]    The present disclosure relates generally to the field of processing applications and other end-user submissions in a data-intensive, regulation-based environment, and, more particularly, to structures and methods for consolidating all aspects of application, administration, actuarial and approval processes for end-user submissions within a unified operational system, and specifically, to structures and methods for consolidating all aspects of mortgage application, administration and approval processes within a unified operational environment. 
       BACKGROUND OF THE INVENTION 
       [0003]    A fall 2012 study by the Competitive Enterprise Institute, aptly titled Tip of the Costberg, estimated that the total unreported cost of all government regulations, not just those affecting the mortgage industry, could be as high $1.8 trillion. Closer to home, the House Financial Services Committee recently estimated that the U.S. financial sector is already spending over 24 million man hours per year complying with Dodd-Frank—that is four million man hours longer than it took to build the entire Panama Canal. For mortgage lenders, federal rules are only part of the challenge: state and local regulations are also increasing. Taken together, there are approximately 350 different federal, state and local rules that could apply to a specific loan, depending on where it is originated according to Cheryl Hemingway, compliance solution specialist at Ellie Mae. No wonder that the average cost of originating a mortgage has climbed to over $3,000 in the third quarter of 2012, according to the Mortgage Bankers Association (MBA). And that&#39;s before the slew of new acronyms—OM, ORM and UDAAP—that could potentially transform our industry are actually spelled out or start taking effect. This paper will examine some of the more subtle ways the ever-increasing regulatory burden is translating into higher costs and risks for banks, community bankers, mortgage bankers and credit unions, as well as some of the steps they can take to reduce their costs of compliance and exposure. 
         [0004]    Some of the costs of compliance are relatively easy to calculate: salaries for compliance officers; legal fees; or compliance software. Additionally, there are substantial costs for non-compliance such as fines, penalties, or forfeiture of interest and fees on a loan. Such costs do not comprehend the cost of defending a lawsuit or even a class-action lawsuit, rate-locks that were mishandled, loans that are put back and cannot be resold, or other good will damage. Most such costs cannot be passed on to the borrower, and result in significant profit losses. 
         [0005]    Further complicating matters for lenders is the emerging trend of stricter, zero-tolerance regulations and the way that they are being interpreted and enforced. In certain instances, it is possible that certain errors—once considered clerical and minor—are now considered incurable. Over the next few years, many state-licensed lenders will need to review and adjust their procedures and systems to comply with changes in state regulations that will be driven by new federal rules. That is because many, if not most, state consumer credit and high-cost loan laws point to federal laws, usually for purposes of determining inclusion/exclusion list fees. This task will be potentially time consuming and expensive. For example, a certain state high-cost law will refer to a section of federal law, but it will not reference it except to say, “As amended.” Depending on how the state rule was drafted, the lender may be precluded from using the federally mandated fee tests and following one methodology. This is going to be true for almost every fee test as state laws are not limited to just one fee test 
         [0006]    Over the next few years, many state-licensed lenders will need to review and adjust their procedures and systems to comply with changes in state regulations that will be driven by new federal rules. That is because many, if not most, state consumer credit and high-cost loan laws point to federal laws, usually for purposes of determining inclusion/exclusion list fees. This task will be potentially time consuming and expensive. 
         [0007]    As a result, inaccurate data can prompt exceptions or violations, regardless of whether they exist or not in the actual loan files. A lender may be forced to go back into actual loan files and defend itself against a fine, or explain why an exception should not be applied. Ongoing data testing and scrubbing is becoming more important. This is complicated when a lender has their data spread over multiple systems—loan origination data on one system; closing documents on a vendor&#39;s system, etc. This makes identification and reporting more time-consuming, and increases the need to reconcile data. 
         [0008]    Certain automated compliance systems exist—but they do not obviate the need to have trained compliance experts in an organization or have knowledgeable outside counsel. A number of other automated systems—such as application systems, appraisal systems, and loan comparison tools—do exist, but those systems are not fully integrated and automated. As such, they still require a high level of manual interface with, and management by, lending personnel; over and above what is minimally required by laws and regulations. 
         [0009]    As a result, there is a need for a system of structures and methods that addresses the shortcomings of existing mortgage processing systems and programs—maximizing automation, compliance and efficiency while minimizing data errors, documentation errors and manual management by lending personnel. 
       SUMMARY OF THE INVENTION 
       [0010]    The present invention provides a versatile system, comprising various constructs and methods, processing mortgages in a convenient, easy and economical manner. The system of the present disclosure provides an operational kernel that consolidates all aspects of mortgage application, processing, underwriting, and approval. 
         [0011]    Specifically, the system of the present invention provides various structures and methods for consolidating all aspects of mortgage application, handling, administration and approval processes within a unified operational environment. Operational portals to external data sources are automated. Applicant interfaces and notification systems are also automated, and operational feedback systems provide the ability to update and/or modify the loan application as information is added or compiled. 
         [0012]    More specifically, the system of the present disclosure provides various structures and methods for processing a user application in an industry requiring regulatory compliance. The system comprises a module operable to acquire applicant goals, a module operable to acquire available options to an applicant, and a module operable to compare the available options to the applicant goals. The system comprises a module operable to identify one or more available options for presentation to the applicant, a module operable to present the identified option to the applicant, and a module operable to acquire an identification of a preferred option. 
         [0013]    Likewise, the methods of the present disclosure provide processing of a user application in an industry requiring regulatory compliance. These methods comprise providing a module operable to acquire applicant goals, a module operable to acquire available options to an applicant, and a module operable to compare the available options to the applicant goals. The methods of the present invention comprise providing a module operable to identify one or more available options for presentation to the applicant, a module operable to present the identified option to the applicant, and a module operable to acquire an identification of a preferred option. 
         [0014]    The system of the present disclosure provides various structures and methods for processing a user application in an industry requiring regulatory compliance. The system comprises a module operable to acquire applicant goals, a module operable to acquire available options to an applicant, and a module operable to compare the available options to the applicant goals. The system comprises a module operable to identify one or more available options for presentation to the applicant, a module operable to present the identified option to the applicant, and a module operable to acquire an identification of a preferred option. The system further comprises a module operable to modify the available options responsive to qualification data obtained based upon user input. 
         [0015]    Other features and advantages of the present invention will be apparent to those of ordinary skill in the art upon reference to the following detailed description taken in conjunction with the accompanying drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0016]    For a better understanding of the invention, and to show by way of example how the same may be carried into effect, reference is now made to the detailed description of the invention along with the accompanying figures in which corresponding numerals in the different figures refer to corresponding parts and in which: 
           [0017]      FIG. 1  provides an illustration depicting a network wherein the teachings of the present disclosure may be employed; 
           [0018]      FIG. 2  provides an illustration depicting certain operational elements of the present disclosure and their relationships to one another; 
           [0019]      FIG. 3  provides an illustration depicting one embodiment of the loan application process of the present disclosure; 
           [0020]      FIG. 4  provides an illustration depicting certain operational engines of the present disclosure and their connections to a central database and to one another; 
           [0021]      FIG. 5  provides an illustration depicting certain aspects of the application engine; 
           [0022]      FIG. 6  provides an illustration depicting certain aspects of a research engine; 
           [0023]      FIG. 7  provides an illustration depicting certain aspects of a regulatory engine; 
           [0024]      FIG. 8  provides an illustration depicting certain aspects of a compilation engine; 
           [0025]      FIG. 9  provides an illustration depicting certain aspects of an underwriting engine; 
           [0026]      FIG. 10  provides an illustration depicting certain aspects of a title engine; 
           [0027]      FIG. 11  provides an illustration depicting certain aspects of a closing engine; 
           [0028]      FIG. 12  provides an illustration depicting certain aspects of a notifications engine; 
           [0029]      FIG. 13  provides an illustration depicting certain aspects of an administration engine; 
           [0030]      FIG. 14  provides an illustration depicting certain aspects of a processing engine; 
           [0031]      FIG. 15  provides an illustration depicting an interface for an initiation engine; 
           [0032]      FIG. 16  provides an illustration depicting a goals interface; 
           [0033]      FIG. 17  provides an illustration depicting a preliminary application interface; 
           [0034]      FIG. 18  provides an illustration depicting a process flow for loan filtering; 
           [0035]      FIG. 19  provides an illustration depicting a loan comparison interface; 
           [0036]      FIG. 20  provides an illustration depicting an account creation interface; 
           [0037]      FIG. 21  provides an illustration depicting a full application interface; 
           [0038]      FIG. 22  provides an illustration depicting a process of applicant screening; 
           [0039]      FIG. 23  provides an illustration depicting a credit pull interface; 
           [0040]      FIG. 24  provides an illustration depicting a disclosures interface; 
           [0041]      FIG. 25  provides an illustration depicting an employment verification interface; 
           [0042]      FIG. 26  provides an illustration depicting an asset verification interface; 
           [0043]      FIG. 27  provides an illustration depicting a title company selection interface; 
           [0044]      FIG. 28  provides an illustration depicting an appraisal interface; 
           [0045]      FIG. 29  provides an illustration depicting a validation interface; 
           [0046]      FIG. 30  provides an illustration depicting an adjustments interface 
           [0047]      FIG. 31  provides an illustration depicting an underwriting interface; and 
           [0048]      FIG. 32  provides an illustration depicting a loan comparison interface arrangement, including data and review fields. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0049]    While the making and using of various embodiments of the present invention are discussed in detail below, it should be appreciated that the present invention provides many applicable inventive concepts, which can be embodied in a wide variety of specific contexts. The present invention is hereafter illustratively described primarily in conjunction with the design, deployment and operation of mortgage processing systems. Certain aspects of the present invention are further detailed in relation to specific functional and operational modules, structures and methods. Although described in relation to such constructs and schemes, the teachings and embodiments of the present invention may be beneficially implemented with a variety of systems and processes in industries where there are high degrees of regulatory compliance required, and/or substantial amounts of actuarial and/or user-entered data utilized. Processing systems in the fields of tax, insurance, governmental contracting, and other similar fields are comprehended by the present invention. The specific embodiments discussed herein are, therefore, merely demonstrative of specific ways to make and use the invention and do not limit the scope of the invention. 
         [0050]    The present invention provides present invention provides a versatile system, comprising various constructs, engines and methods, for consolidating all aspects of mortgage application, handling, administration and approval processes within a unified operational environment. Where practicable, such aspects are further automated so as to maximize efficiency and data integrity. The system of the present disclosure provides an operational kernel that consolidates and/or automates these processes, while providing a user with monitoring, editing and override capabilities. A number of operational constructs are provided within the overarching main operation kernel that are able to responsively interact with one another, and may further receive data from, and output data to, external manual and automated resources via engines, portals, modules or other similar constructs. Simple and intuitive user interfaces are provided to assist in simplifying the overall process. 
         [0051]    More specifically, the system of the present disclosure provides structures, engines and methods for mortgage application, handling, underwriting and approval processes, consolidated within a unified operational environment regardless of lower-level or third-party systems for data input resources and data output demands. 
         [0052]    A number of operational engines are provided to perform various data gathering, data entry, data output and/or data processing functions. These engines may be provided as independent structures, as segments of a larger structure, or as varied combinations of both. All such engines may communicate and/or interoperate with other engines, and the addition, update or development of data in one engine may be responsively updated in or used by other engines. All such engines may have a variety of manual and/or automated inputs or outputs. 
         [0053]    The various functional engines depicted and described herein may be constructed and implemented via a wide variety of structures, apparatuses and methods known to those of skill in the art. In certain embodiments, the engines may be implemented on an array of separate task-specific processing units, computers or servers. The engines may be implemented as software programs or routines running on a single processing unit, computer or server. The engines may be implemented within a server “cloud,” wherein various computers or processors may conduct various tasks at varying times, depending on system load and available resources. Any one or more of such engines may be structured as sub-segments of another engine, may share specific functionalities with one or more other engines or may have their functions divided in a different manner than the manner depicted and described herein. All of these are within the skill of one of skill in the art to which the present disclosure pertains. 
         [0054]      FIG. 1  is a schematic of a generalized network environment  100  wherein the teachings of the present disclosure may be employed. As seen in  FIG. 1 , an array of operational engines operate on one or more servers  102 , each having access to one or more databases  104 . At least one of servers  102  may be connected to an external network  106 , which may provide a connection to external resources and nodes. An array of users  110 ,  114 ,  118  are able to access the information and tools on servers  102  and databases  104  via client machines  108 ,  112 ,  116  operably connected to the network  106  via an internal network  120 . 
         [0055]    Although client machines  108 ,  112 ,  116  are depicted as being laptop or netbook type computers, those of skill in the art will appreciate that the network  106  may be accessed by desktop machines, tablets, smartphones, rack-mounted units or other types of equipment. These devices may operate on any one or more of a variety of operating systems, including Microsoft Windows, Apple MAC OS, Apple iOS, Android, Linux or Blackberry OS, as examples. Any of the client machines  108 ,  112 ,  116  may connect to network  106  via an Ethernet connection, an ADSL connection, cable internet, dial-up, 802.11 (Wi-Fi,) a cellular data connection or any combination of the above. In certain embodiments, the client user interface is designed to be implemented within a browser window, but may also be implemented as a stand-alone application running on any of the aforementioned operating systems and devices. 
         [0056]      FIG. 2  is a schematic showing certain key operational elements of the present disclosure and their relationships to one another. As seen in  FIG. 2 , a borrower  110  at client machine  108  may access Front End  132  either via Bank Website  130 , or more directly, without going through Bank Website  130 . Depending on the manner in which Front End  132  is accessed, the experience of borrower  110  may be different. 
         [0057]    Front End  132  serves as an operational portal to the various engines and related components running on servers  102 , certain of which are shown in  FIG. 2 . The engines and related components include Loan Origination System (LOS) Engine  134 , Automated Underwriting System (AUS) Engine  136 , Validations Engine  138 , Appraisal Management Company (AMC) Engine  140 , Automated Valuation model (AVM) Engine  142 , Pricing Engine  144 , Title Engine  146  and Credit Reporting Agency (CRA) Engine  148 . The function and characteristics of these modules and portals is described in detail below. 
         [0058]    Referring now to  FIGS. 3 and 4 , the present disclosure is described in reference to one general embodiment of unified mortgage processing system according to the present disclosure. As seen in  FIG. 3 , process flow begins with an Initiation Engine  160 . A screen view of one embodiment of an initiation engine interface is shown in  FIG. 15  and described in detail below. On this page, a user will be prompted for, and will make, selections according to the overall purpose of the loan—i.e., whether the applicant is seeking a mortgage for a new purchase ( 164 ) of a home or a mortgage refinance ( 166 ). If a loan for a new purchase is desired, the user will be prompted to indicate residence type, such as primary, secondary/vacation, investment property ( 168 ). 
         [0059]    If refinance is desired, the user will be prompted to indicate the residence type ( 170 ). Additionally, a drop down prompt may be provided to inquire about the purpose of the refinance (cash-out, no cash-out rate and term). After the necessary information is entered, the user clicks the ‘Next’ button to proceed. 
         [0060]    A Goals Interface Engine  172  presents a questionnaire to determine primary, secondary and possibly tertiary goals for the loan sought. A screen view of one embodiment of a Goals Interface is shown in  FIG. 16  and described in detail below. As an example, a user may register an intention to live in the property for less than 5 years as a primary goal, with obtaining the lowest interest rate and building equity as lower priority goals. These three goals may then, in turn, provide a 15 year fixed rate mortgage, an Adjustable Rate Mortgage or a 10 year fixed rate mortgage as possible options. After the necessary information is entered by the user, the user clicks the ‘Next’ button to proceed to the next screen. 
         [0061]    After the Goals Interface Engine  172  completes its work, control proceeds to the Preliminary Application Engine  176 . One embodiment of this page is shown in  FIG. 17  and described in detail below. This page may interface with the Application Engine  240 , Loan Type Engine  178  and Property Lookup Engine  180 . Information from this page can help determine additional important information, including approximate equity (if refinance) or down payment (if purchase), approximate credit profile, property lookup (for outside portals such as USDA search, AVM, FNMA/Freddie Mac, etc.) and income information. After the applicant enters the required information, the ‘Next’ button will move control to the next engine. 
         [0062]    From Preliminary Application Engine  176 , operation continues to Pricing Engine  144 , which may tie into another back-end pricing engine operable to determine pricing adjustments and rate lists for multiple scenarios. The information acquired via the Preliminary Application Engine  176  will be fed into the process set forth in  FIG. 18  and described in detail below. In certain embodiments, the user may see an equivalent of hourglass or some other graphic indicating processing of information while the Pricing Engine  144  is working. 
         [0063]    After the information is processed, it is presented via the Loan Comparison Engine  182 , which populates eligible loan programs and terms based off of the information given in the preceding pages.  FIG. 19  shows a screen layout of one interface for Loan Comparison Engine  182 . The information presented may include indicate rate lists, approximate closing costs, terms, eligibility, reserve requirements, amortization calendars, highlights and downfalls. The user may receive an indication or highlight of which programs best fit their goals. To proceed, the user selects a particular loan offer and clicks ‘Next.’ 
         [0064]    An alternative embodiment of a screen layout  3200  for the interface to LCE  182  is depicted in  FIG. 32 . Screen  3200  may provides detailed information on each of the programs presented, further informing the user and enabling the lender to provide a more disclosure compliant process. For example, the interface may comprise a data field  3202  displaying information points relevant to comparison of different programs. The interface may also comprise one or more review fields  3204  that provide, for a respective program, the data corresponding to each information point in field  3202 . 
         [0065]    In certain implementations, it may be desirable to provide a feedback or return process from the Loan Compare  182  back to the Goals Interface  172  (not shown). This may be useful to enable users to modify their goals information based upon the loan comparison information they receive in response to their input data, in an interactive or recursive process. Likewise, other return or update or modify operations may be linked from various points throughout the system to either the Goals Interface  172 , the Preliminary Application  176 , or other user interface constructs prior to submission to the Underwriting Submission  210 . 
         [0066]    From Loan Comparison Engine  182 , operation continues to an Account Creation Engine  184 , which requires the user create an account in order to proceed. An embodiment of an Account Creation Engine interface page is shown in  FIG. 20 . By the time the user has reached the account creation interface, the user has chosen a loan program, and is thus prompted to create an account in order to securely: 1) input personal data; and 2) be able to save and come back later to finish. Depending upon the details of the system, some embodiments may provide a user with an opportunity to log in via their online bank account, which can then authenticate the user to the server. 
         [0067]    After the user creates an account, operation continues to Full Application Engine  186 , which is, technically speaking, the beginning of the actual loan process. In certain embodiments, a complete traditional application may be included into the site, but with features designed to facilitate a much more user friendly experience. The Full Application Engine  186  may be divided into several sub-components, and the interface may be separated in to several pages, so as to not overwhelm the user with too much data entry on one page. 
         [0068]    Via a portion of the interface for the Full Application Engine  186  or as a separate page, a Credit Questionnaire Engine  188  presents a credit questionnaire to the user. One embodiment of an interface for Credit Questionnaire Engine  188  is included below as  FIG. 21 . It should be noted that at every milestone from the Full Application Engine  186  onward, the information given on each page will be measured against: 1) the guidelines for that program; and 2) any adjustments from the Pricing Engine  144 . This may occur each time the user pushes the ‘Next’ button to gain access to the next page. If there is a conflict with either the guidelines or Pricing Engine  144 , there may be a stop or block imposed that prevents the user from continuing until the conflict is resolved. This stop or block may also activate if the information given conflicts with the same information given previously, or if the data entry is not complete in that section. Certain pages, or all of them, may include a ‘Frequently Asked Questions’ (FAQ) or ‘Help’ button regarding the information on that page. 
         [0069]    Credit Questionnaire Engine  188  may provide a pop-up that prompts the user before allowing a credit pull. At this point the user may have already given permission in the application section to pull credit. Thus, Credit Questionnaire Engine  188  presents the user with an opportunity to indicate any items on their credit report that may significantly affect the eligibility of the user for the preferred loan program. This functionality may be provided to: 1) avoid any unnecessary costs associated with a credit inquiry for the bank; and 2) avoid any unnecessary inquiries for the user, as numerous inquiries are known to negatively affect credit scores. If the user elects not to proceed, control is transferred to Denial/Partner Portal  194 . 
         [0070]    One embodiment of the above-described pre-screening process is set forth in  FIG. 22  and described in detail below. One example of the questionnaire would prompt the user to indicate if they have had a negative indication on a public record, such as a bankruptcy, judgment, or tax lien and if so, when and if was it satisfied or discharged. If none of the questions apply to the user, the user may indicate that they do not apply or are not aware that of any such information. If the user&#39;s answer conflicts with the guidelines for the preferred loan package, an indicator may indicate that they do not currently qualify based on the guidelines, and indicate the statute of limitations in order to qualify. The user may still have the option to continue forward with the credit inquiry, but will be warned that the inquiry may affect their credit score. They may also choose to be redirected to a partner page/portal for education on credit and tools. If they do not have anything which conflicts with the guidelines, the application proceeds. 
         [0071]    If the user elects to perform a credit pull, the user is presented with a query for their social security number and an authorization to pull a credit report via the Credit Inquiry/Import Engine  190 . An embodiment of this page is included below as  FIG. 23 . Once the user enters their social security number and presses a button to pull their credit report, the system contacts the appropriate credit reporting agencies (CRAs) for information on the user&#39;s credit history. As the report populates, it may automatically import in the back end of the system without any further action or input from the user. In some embodiments, the Credit Inquiry/Import Engine  190  may provide opportunities for the user to add notes next to any account for explanation purposes, but does not allow them to edit any other portion of the information. 
         [0072]    Operation continues to the Disclosures Engine  192 . When a user provides their social security number, an indication may be given that this will be the sixth, and last, piece of information required before triggering disclosure obligations. One embodiment of a user interface for Disclosures Engine  192  is included as  FIG. 24 . These disclosures will be displayed and, similar to an online license or software terms and conditions, operation will not continue forward until all disclosures are accessed, viewed, clicked through and/or otherwise acknowledged. In some embodiments, video or visual tutorials may talk the user through each disclosure. If the credit report indicates that the applicant is not eligible for the loan, control may be transferred to Denial/Partner Portal  194 . 
         [0073]    After disclosures, operation continues to Verification of Employment (VOE) Engine  196 , which provides the user with the opportunity to enter information relating to his or her employer(s). One embodiment of an interface for VOE Engine  196  is included as  FIG. 25 . The user may be prompted for various types of information, including company address, phone number, and date hired. They may also select an automated VOE, if their employer is set up with one. They may have the option to input multiple employers. The VOE Engine  196  may then trigger a message to a loan coordinator at the bank, or some automated system, to order verification from the employer. 
         [0074]    After employment verification, operation continues with asset verification via the Asset Engine  198 , which may be provided in a variety of embodiments and using a variety of tools.  FIG. 26  is a screen layout of an asset verification interface page for the Asset Engine  198 . In certain embodiments, a user may import their bank statements directly over the web. This might be particularly feasible if their bank is the institution from which they are currently seeking a loan. Certain embodiments may provide a user with the ability to download, or import, their bank statements from their other banking institutions. Certain embodiments provide a user the ability to fax or scan such documents and upload them through a computer. Once the necessary bank statements are successfully imported, uploaded, scanned, faxed or otherwise provided to the system, the user may click ‘Next’ to move on to automated underwriting. 
         [0075]    After asset verification, operation continues via an Automated Underwriting System (AUS) Engine  136  which analyzes the data provided by the user. AUS Engine  136  may provide a suitable communicative connection to enable the applicant to order underwriting. The resulting findings are then imported into the system. The findings may include, but are not necessarily limited to, a determination as to whether or not the user is preliminarily approved for the preferred loan. The type of finding that may prevent approval may include, for example, a determination that the applicant has insufficient funds to proceed with closing. 
         [0076]    If automated underwriting indicates that the applicant is preliminarily approved for the loan, operation continues to Title Engine  146 . One embodiment of a title company selection interface is included as  FIG. 27 . The title company selection interface allows a user or loan process representative to search for title companies that are geographically nearby. After a title company is selected, the user may provide additional data for arranging a closing, such as address, telephone number and preferred closing date and time. In some embodiments, entry of this data may then notify a Loan Coordinator at the bank, or some automated system, to order or arrange a closing appointment. 
         [0077]    After a title company is successfully selected, operation continues to the appraisal process via Appraisal Management Company (AMC) Engine  140  working alone or in concert with FHA/VA Engine  204 .  FIG. 28  is a screen layout of one embodiment of an appraisal interface. According to certain embodiments, the appraisal interface may query for a user&#39;s credit card information if payment for the appraisal is required up front. In certain embodiments, the interface may enables a user to indicate up to three different dates and times for the appraiser to do the appraisal. In some embodiments, entry of such data may automatically generate an email or text message to the user, once the appraisal has been accepted by the appraisal management company. Similar notifications may be sent when the appointment is accepted by the appraiser, when a reminder for the appointment is due, and/or when the appraiser has submitted the appraisal to the bank. A similar notification process may be utilized as a mechanism to keep the user constantly and completely updated regarding any other process which a third party or company is involved. A notification module suitable for this purpose is illustrated in  FIG. 12 . 
         [0078]    Once an appraisal request is successfully entered, operation continues to validation via Validations Engine  138 . One embodiment of a validation interface for Validations Engine  138  is depicted in  FIG. 29 . The validation interface is provided to enable the user to indicate that they acknowledge their tax returns will be validated with the IRS. In certain embodiments, it may allow for addition of explanations or narratives. In terms of process flow, this acknowledgement may be inserted elsewhere, such as before the title or appraisal ordering portions, depending on the particular embodiment. 
         [0079]    Following validation, operation continues to Pricing Adjustments Engine  206 . An embodiment of a pricing adjustments interface for Pricing Adjustments Engine  206  is included as  FIG. 30 . This interface and module may automatically pull from the Pricing Engine  144  any additional adjustments to rate or closing costs because of changes in information from the initial application to the actual up-to-the-minute information acquired. As an example, if an appraisal comes in lower than expected, a pricing adjustment may be necessary. In certain cases, a user may choose to compare a higher rate with lower fees against a lower rate with additional fees, before submitting their file into underwriting. This module and interface may indicate to the user, based upon the user&#39;s initial goals, that there are additional programs that they now qualify for, or that they no longer qualify for one of the initial options. The user enters the preferred option in  208 . 
         [0080]    After pricing adjustments (if any) are addressed, operation continues to the Submission Engine  210  and then to Underwriting Engine  212 . At this point in the process, the user&#39;s tasks are complete. One embodiment of an underwriting confirmation page useful in combination with Underwriting Engine  212  is shown in  FIG. 31 . This page may provide the user with a timeline, based upon their preferred closing, as well as when certain milestones, such as the title work, appraisal, verifications and validations are expected to be completed or returned. Any conflicts in timing may be identified by the system and may result in a prompt to the user to adjust their preferred closing date and times. During the underwriting process, the user may receive, via a notifications module or process such as Notifications Engine  244 , automated emails or text messages that allow them to track the progress of the application through the underwriting process. 
         [0081]    After underwriting is initiated, operation continues to a determination as to whether the loan is to be approved, suspended or declined via an Approval/Declination Engine  214 . Once an application is underwritten and a decision is made, an alert message may be generated to notify the user to log in to the system and review the lender&#39;s decision. The user may then be presented with an opportunity to respond to or satisfy any conditions that the lender may have placed on the decision. The user may also be provided with the capabilities to contact the bank for clarification on any such items. Once conditions are cleared by an underwriter, automated underwriting module, or other similar construct, the loan application proceeds to Closing and Funding Engine  216 , and corresponding documents are transmitted to the title company for the user&#39;s closing. Subsequently, process flow proceeds to Post Closing Engine  218 . 
         [0082]    According to certain embodiments of the present disclosure, the broad variety of engines, modules and portals comprising the system are operably connected to one another and to a central database. Accordingly, the various modules are able to communicate and coordinate internally without requiring manual intervention or external input.  FIG. 4  depicts this relationship schematically, wherein Application Engine  240 , Closing/Funding Engine  216 , Post Closing Engine  218 , Approval/Declination Engine  214 , Underwriting Engine  212 , Front End  132 , Pricing Adjustments Engine  206 , FHA/VA Engine  204 , Validations Engine  138 , Research Engine  248 , Regulatory Engine  250 , Compilation Engine  252 , Purchase Engine  164 , Refinance Engine  166 , Administration Engine  242 , Loan Comparison Engine  182 , Property Lookup Engine  180 , Credit Questionnaire Engine  188 , Credit Inquiry/Import Engine  190 , Denial/Partner Engine  194 , CRA Engine  148 , VOE Engine  196 , Notifications Engine  244 , Processing Engine  246 , Goals Questionnaire Engine  174 , Title Engine  146 , Asset Engine  198 , AUS Engine  136 , Pricing Engine  144  and AMC Engine  140  are interconnected with one another, with servers  102  and with databases  104  via network  120 . It will be understood by those of skill in the art that other engines, modules and portals may be interconnected within the system. It will also be understood by those of skill in the art that certain embodiments may not incorporate all of the engines, modules and portals shown in  FIG. 4 , and that certain engines, modules and portals may be combined together in certain implementations. 
         [0083]      FIG. 5  illustrates numerous aspects of Application Engine  240 , which may be provided to manage the application portions of the system.  FIG. 5  is a block diagram showing certain aspects of an Application Engine  240  according to the present disclosure. As seen in  FIG. 5 , Application Engine  240  comprises a user interface operable to receive inputs from one or more banks and one or more consumers, and to provide outputs in the form of questionnaires, prompts and verifications. The User Interface  300  may be provided as part of, or in conjunction with, Application Engine  240 . The User Interface  300  may also be operatively coupled to and utilized by other engines, modules and portals as well. Application Engine  240  is further operable to connect and communicate with other modules, portals and processes in the system, including but not limited to the Preliminary Application Engine  176  and Full Application Engine  186 . 
         [0084]      FIG. 6  is a block diagram showing certain aspects of a Research Engine  248  of the present disclosure. Research Engine  248  may be provided and utilized to collect various application related data, including data on property, pricing, credit and rates, as examples. The output from the Research Engine  248  may be raw data, analysis, or some combination of the two. This module may be operatively coupled to or utilized by any of the modules requiring external data. In certain cases, a particular Research Engine  248  may be optimized to conduct a particular type of research. 
         [0085]      FIG. 7  is a block diagram showing certain aspects of a Regulatory Engine  250  according to the present disclosure. Regulatory Engine  250  receives regulatory rules and loan details, both via manual and automatic entry. Regulatory Engine  250  may output an approval of a proposal, a denial, a partial approval or a set of one or more corrective actions. This engine may be operatively coupled to or utilized by any of the modules requiring review for regulatory compliance. 
         [0086]      FIG. 8  is a block diagram showing certain aspects of a Compilation Engine  252  according to the present disclosure. Compilation Engine  252  compiles data received and outputs the compiled data to other modules and portals requiring such data. This engine may be operatively coupled to or utilized by any of the engines or other components requiring access to its functions. 
         [0087]      FIG. 9  is a block diagram showing certain aspects of an Underwriting Engine  212  according to the present disclosure. Underwriting Engine  212  receives inputs, including application data, credit history, employment and assets, and performs an underwriting analysis. The output from Underwriting Engine  212  may be an approval or a set of corrective actions. This engine may be operatively coupled to or utilized by any of the other engines, modules and portals. 
         [0088]      FIG. 10  is a block diagram showing certain aspects of a Title Engine  146  according to the present disclosure. Title Engine  146  receives various inputs including schedule, funding and closing costs. This engine may be operatively coupled to or utilized by any of the engines or other components requiring access to title-related information. 
         [0089]      FIG. 11  is a block diagram showing certain aspects of a Closing/Funding Engine  216  according to the present disclosure. This module receives certain inputs related to closing and funding and provides appropriate outputs. This engine may be operatively coupled to or utilized by any of the engines or other components providing or requiring access to closing or funding-related information. 
         [0090]      FIG. 12  is a block diagram showing certain aspects of a Notifications Engine  244  according to the present disclosure. Inputs may include messages, destination identifiers and message scheduling. Notifications may be delivered to applicants, banks or title companies. This engine may be operatively coupled to or utilized by any of the engines or other components requiring review for regulatory compliance. 
         [0091]      FIG. 13  is a block diagram showing certain aspects of an Administration Engine  242  according to the present disclosure. This engine may be operatively coupled to or utilized by any of the engines or other components requiring access to administration functions. 
         [0092]      FIG. 14  is a block diagram showing certain aspects of a Processing Engine  246  according to the present disclosure. This engine may be operatively coupled to or utilized by any of the components requiring access to processing functions. 
         [0093]      FIG. 15  is a screen layout of a user interface  350  for Initiation Engine  160  according to the present disclosure. Initiation Engine  160  is described in connection with  FIG. 3 , above. As shown in this figure, user interface  350  is shown being presented within a web browser window. Those of skill in the art will appreciate that the same functionality may be provided via a stand-alone application. User interface  350  comprises a variety of elements, including a header section  352 , a set of navigation tabs  354 - 378  and a content section  380 . 
         [0094]    Header section  352  incorporates a set of controls useful on any of the pages of the user interface, including a user id field  382 , a login button  384  and a help button  386 . This portion of the user interface is persistent from one page to another. 
         [0095]    Disposed immediately below the header section, the set of navigation tabs  354 - 378  comprises start tab  354 , goals tab  356 , preliminary application tab  358 , loan comparison tab  360 , decision tab  362 , full application tab  364 , credit pull tab  366 , disclosures tab  368 , employment tab  370 , assets tab  372 , title tab  374 , appraisal tab  376  and validation tab  378 . Each of navigation tabs  354 - 378  is operably connected to, and designed to open, the page corresponding to the tab when selected, in order to facilitate efficient navigation within the user interface. 
         [0096]    Immediately below navigation tabs  354 - 378 , a content section  380  comprises a page title  388 , purchase residence type field  390 , refinance residence type field  392 , refinance purpose field  394  and ‘next’ button  396 . The operation of these entry fields and controls is according to the manner described above in connection with element  160  of  FIG. 3 . 
         [0097]      FIG. 16  is a screen layout of a goals interface page  400  according to the present disclosure. Goals interface page  400  has been briefly described above in connection with  FIG. 3 . As seen in  FIG. 16 , the header section  352  remains the same as shown and described above in connection with  FIG. 15 . The content section  380 , however, has been modified from that shown above. In this page, content section  380  contains a set of data entry fields  402 - 406 . These include primary goal entry field  402 , secondary entry field  404  and tertiary entry field  406 . Depending on the implementation, fields may be simple text entry fields, drop downs, text entry with auto complete, or any combination thereof. This information relates generally to the desirable term of the loan, the balance between closing costs and rates, and the level of risk tolerance on adjustable rates, and this information will be used by the system to identify one or more loans suitable for the user. If the user finds it necessary to revise information on a prior page, the user may use ‘prev’ button  408 . When the user has entered the necessary data and is prepared to move forward, the user can press ‘next’ button  396  to proceed. 
         [0098]      FIG. 17  is a screen layout of a preliminary application interface page  420  according to the present disclosure. Preliminary application interface page  420  has been briefly described above in connection with  FIG. 3 . As seen in  FIG. 17 , the header section  352  remains the same as shown and described above in connection with prior pages. The content section  380 , however, is unique to this page. In this page, content section  380  contains a set of data entry fields  422 - 430 . These include equity query  422 , down payment query  424 , credit score query  426 , property address  429  and annual household income query  430 . Depending on the implementation, these fields may be simple text entry fields, drop downs, text entry with auto complete, or any combination thereof. This information relates generally to the applicant&#39;s ability to carry the requested loan, and this information will be used by the system to make a preliminary determination. If the user finds it necessary to revise information on a prior page, the user may use ‘prev’ button  408 . When the user has entered the necessary data and is prepared to move forward, the user can press ‘next’ button  396  to proceed. 
         [0099]      FIG. 18  is a flowchart showing a process flow for loan filtering and prioritizing according to the present disclosure. This process was described briefly above in connection with  FIG. 3 . According to the process shown, the first step, in block  450 , is to acquire the applicant&#39;s goals. This is done via the goals interface page  400  shown in  FIG. 15 . Once the applicant&#39;s goals are identified, the system acquires a set of available offers in block  452 . The available offers are filtered by the applicant&#39;s primary goal in block  454 . In block  456 , a determination is made as to whether any of the available offers comply with the primary goal. If no offers conform to the applicant&#39;s primary goal, the applicant is notified in block  458 , the goals are revised in block  460  and process flow returns to block  452 . 
         [0100]    If at least one offer conforms to the applicant&#39;s primary goal, process flow proceeds to block  462 , where the offers are filtered by the applicant&#39;s secondary goal, and process flow proceeds to decision block  464 . Process flow from decision block  464  depends on whether there are offers remaining after filtering by the applicant&#39;s secondary goal. If there are offers remaining, process flow proceeds to block  466 . If there are not offers remaining, process flow proceeds to block  458 . 
         [0101]    In block  466 , the remaining offers are filtered by the applicant&#39;s tertiary goal, and process flow proceeds to decision block  468 . Process flow from decision block  468  depends on whether there are offers remaining after filtering by the applicant&#39;s tertiary goal. If offers remain, process flow proceeds to block  470 . If there are no remaining offers, process flow proceeds to block  458 . 
         [0102]    In block  470 , the offers remaining after filtering are presented to the user, and process flow proceeds to decision block  472 . Process flow from decision block  472  depends on whether one of the remaining offers is acceptable to the applicant. If no remaining offer is acceptable to the applicant, process flow proceeds to block  458 . If at least one remaining offer is acceptable to the applicant, process flow proceeds to block  474 , where the user proceeds with the application. 
         [0103]      FIG. 19  is a screen layout of a loan comparison interface page  500  according to the present disclosure. Loan comparison interface page  500  has been briefly described above in connection with  FIG. 3 . As seen in  FIG. 19 , the header section  352  remains the same as shown and described above in connection with prior pages. The content section  380 , however, is unique to this page. In this page, content section  380  contains a table comprising a set of loan data columns  502 - 508  and a set of selection buttons  510 - 516 . The loan data columns include lender name column  502 , rate column  504 , term column  506  and loan type column  508 . Those of skill in the art will appreciate that alternate embodiments may include more types of information or less. This information relates generally to the loans meeting the applicant&#39;s previously-identified goals, and this information will be used by the system to identify which of the available offers is preferred by the applicant. In order to select one of the loan offers as the preferred offer, the user clicks the appropriate one of the loan selection buttons  510 - 516 . If the user finds it necessary to revise information on a prior page, the user may use ‘prev’ button  408 . When the user has selected a loan and is prepared to move forward, the user can press ‘next’ button  396  to proceed. 
         [0104]      FIG. 20  is a screen layout of an account creation interface page  550  according to the present disclosure. Account creation interface page  550  has been briefly described above in connection with  FIG. 3 . As seen in  FIG. 20 , the header section  352  remains the same as shown and described above in connection with prior pages. The content section  380 , however, is unique to this page. In this page, content section  380  contains a set of data entry fields  552 - 558 . These include user name query  552 , email address query  554 , login ID query  556  and password query  558 . Depending on the implementation, any of these fields may be simple text entry fields, drop downs, text entry with auto complete, or any combination thereof. This information will be used by the system to authenticate the user on future visits. When the user has entered the necessary data and is prepared to move forward, the ‘next’ button  396  will take the user to the next page. 
         [0105]      FIG. 21  is a screen layout of a full application interface page  600  according to the present disclosure. Full application interface page  600  has been briefly described above in connection with  FIG. 3 . As seen in  FIG. 21 , the header section  352  remains substantially the same as shown and described above in connection with prior pages, except that the header now reflects that the user has logged in to the system. As above, the content section  380  is unique to this page. In this page, content section  380  contains a set of data entry fields  602 - 610 . These include bankruptcy query  602 , judgements query  604 , tax liens query  606 , discharged query  608  and discharge date query  610 . Depending on the implementation, fields may be simple text entry fields, drop downs, text entry with auto complete, or any combination thereof. This information relates generally to the applicant&#39;s eligibility for the preferred loan offer, and this information will be used by the system to make that determination. When the user has entered the necessary data and is prepared to move forward, the ‘next’ button  396  will take the user to the next page. 
         [0106]      FIG. 22  is a flowchart showing a process of applicant screening according to the present disclosure. The applicant screening process has been briefly described above in connection with  FIG. 3 . Process flow begins in block  620 , wherein the credit questionnaire is presented to the user and information acquired, and the proceeds to decision block  622 . Process flow from block  622  depends on whether the user has indicated that there is a bankruptcy, judgment or tax lien on the applicant. If there are such credit issues, process flow proceeds to decision block  624 . If no such issues are present, process flow proceeds to decision block  626 . 
         [0107]    Process flow from decision block  624  depends on whether the identified credit issues have been satisfied or discharged. If the issues have been satisfied or discharged, process flow proceeds to decision block  626 . If the issues have not been satisfied or discharged, process flow proceeds to block  628 . 
         [0108]    Process flow from decision block  626  depends on whether the applicant meets the guidelines for the identified preferred loan. If the applicant does not meet the guidelines, process flow proceeds to block  628 . If the applicant does meet the guidelines, process flow proceeds to block  632 . 
         [0109]    In block  628 , the user is alerted that there are indications that the applicant may not meet the guidelines for the identified preferred loan, and advised that a credit pull may negatively affect the applicant&#39;s credit rating. Process flow then proceeds to decision block  630 . 
         [0110]    Process flow from decision block  630  depends on whether the user wishes to proceed with the credit pull. If the user elects to proceed with the credit pull, process flow proceeds to block  632 . If the user declines to authorize a credit pull, process flow proceeds to block  636 . 
         [0111]    In block  632 , the applicant&#39;s credit report is pulled from one or more credit reporting agencies (CRAs) and process flow proceeds to decision block  634 . Process flow from decision block  634  depends on whether the applicant&#39;s credit report reflects information establishing that the applicant meets the guidelines for the identified preferred offer. If the applicant does not appear to meet the guidelines, process flow proceeds to block  636 . If the applicant appears to meet the guidelines, process flow proceeds to block  638 . 
         [0112]    In block  636 , applicants whose credit history do not meet the loan eligibility criteria are redirected to one or more partner portals able to make additional loan offers having less stringent eligibility criteria. In block  638 , applicants having a credit history indicating eligibility for the identified preferred loan proceed with their application within the system. 
         [0113]      FIG. 23  is a screen layout of a credit pull interface page  650  according to the present disclosure. Credit pull interface page  650  has been briefly described above in connection with  FIG. 3 . As seen in  FIG. 23 , the header section  352  remains the same as shown and described above in connection with prior pages, but the content section  380  is unique to this page. In this page, content section  380  contains a social security number query  652  and an authorization block  654 . When the user has entered the necessary data and is prepared to move forward, the ‘next’ will advance to the next page. 
         [0114]      FIG. 24  is a screen layout of a disclosures interface page  680  according to the present disclosure. Disclosures interface page  680  has been briefly described above in connection with  FIG. 3 . In this page, content section  380  contains a disclosure display button  682  and a disclosure acknowledgement block  684 . Disclosure display button  682  is operable to display all the necessary disclosures to the user, either on one page or a series of pages. After the user has reviewed and acknowledged the disclosures, pressing the ‘next’ button  396  will advance to the next page. 
         [0115]      FIG. 25  is a screen layout of an employment verification interface page  700  according to the present disclosure. Employment verification interface page  700  has been briefly described above in connection with  FIG. 3 . In this page, content section  380  contains a set of data entry fields  702 - 708 , automated verification flag  710  and multiple employers button  712 . Data entry fields  702 - 708  include employer name query  702 , employer address query  704 , employer phone number query  706  and date hired query  708 . Depending on the implementation, fields may be simple text entry fields, drop downs, text entry with auto complete, or any combination thereof. When the user has entered the necessary data and is prepared to move forward, the user presses ‘next’ button  396  to proceed. 
         [0116]      FIG. 26  is a screen layout of an asset verification interface  720 . Asset verification interface  720  has been briefly described above in connection with  FIG. 3 . In this page, content section  380  contains a set of buttons  722 - 728 . Buttons  722 - 728  provide various channels through which a user can import bank statements to the system. These include a direct import button  722 , electronic statement upload button  724 , scanned statement upload button  726  and fax statement button  728 . When the user has entered the necessary data and is prepared to move forward, the pressing ‘next’ button  396  moves on to the next page. 
         [0117]      FIG. 27  is a screen layout of a title company selection interface  750 . Title company selection interface  750  has been briefly described above in connection with  FIG. 3 . In this page, content section  380  contains a zip code query  752 , a list of title companies, a series of selection buttons  754 - 762  a preferred closing date query  764  and an alternate closing date query  766 . Depending on the implementation, the data entry fields may be simple text entry fields, drop downs, text entry with auto complete, or any combination thereof. The zip code query employs a ‘store finder’ algorithm to sort title companies based on proximity to a particular location. The selection buttons  754 - 762  are used to select one of the title companies from the list. This information is used by the system to select a title company and schedule a closing date. When the user has selected a title company and closing dates and is prepared to move forward, the user presses ‘next’ button  396  to proceed. 
         [0118]      FIG. 28  is a screen layout of an appraisal interface  780 . Appraisal interface  780  has been briefly described above in connection with  FIG. 3 . In this page, content section  380  contains a set of data entry fields  782 - 790 . These include credit card number query  782 , credit card expiration date query  784 , preferred appraisal date query  786 , first backup appraisal date  788  and second backup appraisal date  790 . Depending on the implementation, fields may be simple text entry fields, drop downs, text entry with auto complete, calendar tools or any combination thereof. This information relates generally to the appraisal process, and this information will be used by the system to automatically schedule an appraisal. When the user has entered the necessary data and is prepared to move forward, pressing ‘next’ button  396  moves forward. 
         [0119]      FIG. 29  is a screen layout of a validation interface  800 . Validation interface  800  has been briefly described above in connection with  FIG. 3 . In this page, content section  380  contains a notification of validation and a validation authorization block  802  wherein the user can authorize the validation process. Once the user has authorized validation and is prepared to move forward, pressing ‘next’ button  396  advances the process. 
         [0120]      FIG. 30  is a screen layout of an adjustments interface page  820 . Adjustments interface page  820  has been briefly described above in connection with  FIG. 3 . In this page, content section  380  contains a table listing additional loan offers along with a corresponding set of selection buttons  822 ,  824 . If the user decides that one of the listed loan offers is preferable to the earlier-identified preferred offer, the user can select the offer by clicking the selection button  822 ,  824  adjacent to that offer. The user is not, however, under an obligation to select one of the alternate offers, unless the originally-identified loan offer is no longer available. When the user is prepared to move forward, the user can press ‘next’ button  396  to proceed. 
         [0121]      FIG. 31  is a screen layout of an underwriting interface page  850 . Underwriting interface page  850  has been briefly described above in connection with  FIG. 3 . In this page, content section  380  contains a status update message noting that the user has completed the data entry portion of the process, along with a timeline identifying the dates by which certain underwriting and closing milestones are expected to be completed. If the user finds it necessary to revise information on a prior page, the user may use ‘prev’ button  408 . Otherwise, the user presses ‘done’ button  852  when the user&#39;s data entry obligations are completed. 
         [0122]    Although the process and system has been described above in connection with certain illustrative embodiments, those of skill in the art will appreciate that the above-described embodiments are only provided by way of example. As an example, in certain embodiments, a user may, at any point in time, be given the ability to submit their file for a manual underwrite. This may be particularly desirable if the system is rejecting their information or indicating numerous problems. The user may also be given the ability to communicate with a help desk to troubleshoot any questions or problems they are having, or a number of automated videos and audio tutorials may be provided in each section. In alternative embodiments, utilized in industries outside of mortgage processsing, other individuals may interact with the user or the user process instead of loan officers or loan coordinators—such as contract administrators, insurance brokers, tax agents, or other professionals and their administrative personnel. 
         [0123]    In all embodiments of the present invention, the constituent constructs, routines, functions or components may be implemented in a wide variety of ways—comprising various suitable software, firmware or hardware constructs, or combinations of thereof. For example, certain algorithms and routines described herein as firmware may also comprise separate code segments, grouped together in functional segments or incorporated as part of a larger integrated code segment. They may comprise software operating on a host computer system, or routines operating on a digital signal processor. Certain functions or operations may be provided in exclusively in hardware. All of these variations, and all other similar variations and combinations, are comprehended by the present invention. All such embodiments may be employed to provide the benefits of the present invention. 
         [0124]    The entire system of the present disclosure may be pre-formatted in any language, or may provide user-selectable language toggles. Similarly, the entire system may be adapted to interface with disparate bank systems, or customized for use in a particular end-use. Similar embellishments, and various combinations thereof, are all comprehended by the present disclosure. All embodiments described herein are presented for purposes of illustration and explanation only. The specific compositions, configurations, orientations and operations of various features, portions and members may be provided in a number of ways in accordance with the present disclosure. 
         [0125]    Therefore, the embodiments and examples set forth herein are presented to best explain the present disclosure and its practical application and to thereby enable those skilled in the art to make and utilize the disclosure. As previously explained, those skilled in the art will recognize that the foregoing description and examples have been presented for the purpose of illustration and example only. The description as set forth is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in light of the above teaching without departing from the spirit and scope of the present disclosure.