Abstract:
An automated method for generating Graphical User Interfaces (GUI&#39;s) is illustrated in the context of a system for processing financial applications. In one embodiment, the GUI generator converts domain data representing over one thousand application types into an equal number of corresponding user screens. The interface may also be bi-directional, operating on user inputs to validate data or check for double keying.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     The subject matter of this application is related to the subject matter of U.S. patent application Ser. No. 09/599,602 entitled “SYSTEM AND METHOD FOR PROCESSING APPLICATIONS FOR FINANCIAL SERVICES” filed of even date herewith, which application is assigned or under obligation of assignment to the same assignee as this application and which is incorporated by reference herein. The subject matter of this application is also related to the subject matter of provisional U.S. Patent Application Serial No. 60/182,674 filed Feb. 15, 2000 entitled “SYSTEM AND METHOD FOR PROCESSING AND TRACKING APPLICATIONS FOR FINANCIAL PRODUCTS AND SERVICES,” which application is assigned or under obligation of assignment to the same assignee as this application and which is incorporated by reference herein, and priority being claimed therefrom. 
    
    
     FIELD OF THE INVENTION 
     The invention described herein is for the automated generation of graphical user interfaces (GUI&#39;s). 
     BACKGROUND OF THE INVENTION 
     Present-day consumers have come to rely on the convenience of credit cards and other financial services. There is a high volume of new account applications for such services, even in the credit card industry, for example, where there is already a large base of existing credit card holders. Several factors may account for the high volume of credit card applications: consumers who have recently reached the age of majority are applying for their first credit card; existing credit card users often change from one credit service provider to another in order to obtain more favorable terms; and some credit card holders desire additional or upgraded credit cards. 
     The financial services industry is competitive. Banks and other financial service providers therefore may review a large number of applications in a limited amount of time, and they must make good decisions regarding the credit-worthiness of potential borrowers. Automated systems have been developed to process applications quickly and to track individual credit applications through the review process. Many application processing systems manage risk by employing a decision engine to consistently apply best business practices associated with the selection of customers. 
     Known systems and methods for processing high volumes of credit applications receive data from a single input channel, operate either in batch mode or in real-time mode, make credit decisions using a single decision engine, and customize user interfaces for different application types. Drawbacks of such implementations are considered below. 
     Credit applications typically include information such as name and address of the applicant(s), and may include information such as employment history, monthly income, monthly financial obligations, and the amount of credit being applied for. Potential customers submit credit applications to banks or other financial institutions through various channels. A drawback of existing application processing systems is that they are typically configured to accept applications from a single channel, for example paper applications received in the mail, applications submitted via the Internet, or applications received over the phone. Moreover, application processing systems may operate in a mode that is tailored to the type of input channel. For example, systems that process paper applications typically process in batch mode, whereas an interactive Internet application requires real time processing. It is inefficient for financial institutions to implement and maintain separate systems for processing applications that are submitted through different channels. On the other hand, it is a convenience to applicants, and thus a benefit to financial service providers, to offer a variety of application input alternatives. 
     Credit decisions are often made on the basis of information from the credit application itself, and from historical credit information provided by one or more independent credit bureaus. Decision engines typically include software implementations of algorithms designed to quantify risk based on such information, resulting in a determination as to whether credit should be offered to a particular applicant, and, if so, under what terms. Such algorithms are constantly evolving. As a consequence, application processing systems tailored to a particular decision engine may quickly become obsolete. 
     Additionally, many data processing systems, including those that process applications for financial services, are required to accommodate a variety of different user interface screens. A financial service provider may, for example, have hundreds of different new account application formats related to the variety of services it offers to consumers. System developers respond to this need by coding or scripting a variety of user interfaces that are tailored to the requirements of each application. Unfortunately, user interface requirements may be dynamic for many data processing operations. A financial services provider, for example, may wish to offer new services, may require new information to process existing products, or may simply change the layout of a user interface to make it more user-friendly. The result can be a high level of maintenance in the form of software support, which may be both costly and time-consuming. 
     Thus, existing application processing systems may have narrow operational value, and may require frequent modification. These and other drawbacks limit the efficiency of such systems. 
     SUMMARY OF THE INVENTION 
     The invention overcoming these and other drawbacks in the art relates a system and method that may accept applications for financial services from a variety of input channels, may operate in various processing modes, may utilize one or more decision engines during operation, and may generate user interface script automatically. 
     It is an object of the invention to make the process of applying for financial services more convenient for consumers. The techniques described herein for enabling a variety of input channels and for processing applications in a variety of modes may provide more data input options for applicants and may be a more efficient use of computing resources for financial institutions. 
     It is another object of the invention to provide financial institutions with a more powerful technique for automating credit decisions. A flexible interface to decision engines may be advantageous for several reasons. First, this type of interface may make multiple types of decision engines available simultaneously. This would be a benefit, for example, where different engines are used together to make decisions on different financial products, or where two or more decision engines are used to make a single determination. Moreover, a flexible interface may significantly reduce the cost of replacing decision engines in the overall system, when and if it becomes necessary. 
     It is another object of the invention to eliminate or reduce the amount of manual scripting required to support new user interfaces to data processing systems. By automatically generating user interface script based on functional parameters, it is no longer necessary to manually develop screen interfaces for the variety of applications that may be supported by any one system. This technique may be executed in situ (i.e., in the process of each user transaction), or it may be executed only once after a new application has been defined (in which case the resulting user interface script would be stored for later use). 
     In one embodiment of the invention, an applicant may communicate with the data processing system via the Internet. The applicant may further select a particular financial service from a menu of choices. In response, the script generator creates an appropriate user interface, which is presented to the user for completing and submitting an application for the selected financial service. The system processes the application data in a mode that is tailored to the input channel; here, it is likely that the system will operate in real time mode. The system may then select and employ one or more decision engines, as appropriate for the type of application that is to be processed. Once a determination has been made whether to perform financial services for the applicant, the data processing system notifies the applicant that their application has been either accepted or rejected. 
     The following drawings and descriptions further describe the invention, including several different embodiments of the major system components and processes. The construction of such a system, implementation of such a process, and advantages will be clear to a person skilled in the art of data processing generally, including financial services. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is the schematic diagram of a system that processes applications for financial services, according to one embodiment of the invention. 
         FIG. 2  is a flow diagram illustrating the logical relationship between functional components of a system that processes applications for financial services, according to one embodiment of the invention. 
         FIG. 3  is a flow diagram illustrating a method for processing applications related to financial services, according to one embodiment of the invention. 
         FIG. 4  is a flow diagram illustrating the inputs and outputs of an automated Graphical User Interface (GUI) generator, which has been adapted for mediating communication between an application processing system and an applicant. 
         FIG. 5  is a flow diagram illustrating a method for mediating communication between a system and a user, according to one embodiment of the invention. 
         FIG. 6  is the schematic of a user screen resulting from operation of an automated Graphical User Interface (GUI) generator, according to one embodiment of the invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       FIG. 1  illustrates a system architecture for processing applications related to financial services according to the invention. A purpose of the system is to connect sources of electronic application data to decision engines and credit bureaus, and to host programs that coordinate the processing of application data. The schematic depicts among other possible resources: servers  114 ,  116 ,  118 ,  120 ,  122 ,  126  and  130 ; clients  104 ,  108 , and  110 ; and databases  124 ,  128 ,  132  and  134 . Servers and clients are connected via communication link  112 , according to one embodiment of the invention. 
     Server  114  may perform or coordinate the processing of financial applications including functions such as data collection, validation, tracking, reconciliation, repair, routing, fulfillment, and reporting functions. Servers  116 ,  118 , and  120  represent a variety of decision engines that such a system may include or interface to. Servers  122 ,  126  and  130  illustrate various credit bureau servers that the system may utilize to obtain credit history for a given applicant. Servers  114 ,  116 ,  118 ,  120 ,  122 ,  126  and  130  may be or include, for instance, a workstation running the Microsoft Windows™ NT™, Windows™ 2000, Unix, Linux, Xenix, IBM AIX, Hewlett-Packard UX, Novell Netware™, Sun Microsystems Solaris™, OS/2™, BeOS™, Mach, Apache, OpenStep™ or other operating system or platform. 
     Clients  104 ,  108 , and  110  represent various sources for applications related to financial services. All provide applications to the processing system in electronic format. Client  104  depicts a source of electronic applications where paper documents  100  have been converted into electronic format by a scanner  102 . Client  108  depicts a source for electronic applications originating via telephonic input  106 . Client  110  depicts a direct user interface. Clients  104 ,  108 , and  110  may be or include, for instance, a personal computer running the Microsoft Windows™ 95, 98, Millenium™, NT™, or 2000, Windows™ TMC™, PalmOS™, Unix, Linux, Solaris™, OS/2™, BeOS™, MacOS™ or other operating system or platform. Clients  104 ,  108 , and  110  may include a microprocessor such as an Intel x86-based device, a Motorola 68K or PowerPC™ device, a MIPS, Hewlett-Packard Precision™, or Digital Equipment Corp. Alpha™ RISC processor, a microcontroller or other general or special purpose device operating under programmed control. Clients  104 ,  108 , and  110  may furthermore include electronic memory such as RAM (random access memory) or EPROM (electronically programmable read only memory), storage such as a hard drive, CDROM or rewritable CDROM or other magnetic, optical or other media, and other associated components connected over an electronic bus, as will be appreciated by persons skilled in the art. Clients  104 ,  108 , and  110  may also be or include a network-enabled appliance such as a WebTV™ unit, radio-enabled Palm™ Pilot or similar unit, a set-top box, a networkable game-playing console such as Sony Playstation™ or Sega Dreamcast™, a browser-equipped cellular telephone, or other TCP/IP client or other device. 
     Databases  124 ,  128  and  132  may include credit history data for applicants and non-applicants, as maintained by various credit bureaus. Database  134  may include application data, application status information, and programs used by the application processing system  114 . Databases  124 ,  128 ,  132  and  134  may be, include or interface to, for example, the Oracle™ relational database sold commercially by Oracle Corp. Other databases, such as Informix™, DB2 (Database 2) or other data storage or query formats or platforms such as OLAP (On Line Analytical Processing), SQL (Standard Query Language), Microsoft Access™ or others may also be used, incorporated or accessed in the invention. 
     Communication link  112  connects servers  114 ,  116 ,  118 ,  120 ,  122 ,  126  and  130  to each other and to clients  104 ,  108 , and  110 . Communications link  112  may be, include or interface to any one or more of, for instance, the Internet, an intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network) or a MAN (Metropolitan Area Network), a frame relay connection, an Advanced Intelligent Network (AIN) connection, a synchronous optical network (SONET) connection, a digital T1, T3, E1 or E3 line, Digital Data Service (DDS) connection, DSL (Digital Subscriber Line) connection, an Ethernet connection, an ISDN (Integrated Services Digital Network) line, a dial-up port such as a V.90, V.34 or V.34bis analog modem connection, a cable modem, an ATM (Asynchronous Transfer Mode) connection, or FDDI (Fiber Distributed Data Interface) or CDDI (Copper Distributed Data Interface) connections. Communications link  112  may furthermore be, include or interface to any one or more of a WAP (Wireless Application Protocol) link, a GPRS (General Packet Radio Service) link, a GSM (Global System for Mobile Communication) link, a CDMA (Code Division Multiple Access) or TDMA (Time Division Multiple Access) link such as a cellular phone channel, a GPS (Global Positioning System) link, CDPD (cellular digital packet data), a RIM (Research in Motion, Limited) duplex paging type device, a Bluetooth radio link, or an IEEE 802.11-based radio frequency link. Communications link  112  may yet further be, include or interface to any one or more of an RS-232 serial connection, an IEEE-1394 (Firewire) connection, a Fibre Channel connection, an IrDA (infrared) port, a SCSI (Small Computer Serial Interface) connection, a USB (Universal Serial Bus) connection or other wired or wireless, digital or analog interface or connection. 
     Servers  114 ,  116 ,  118 ,  120 ,  122 ,  126 ,  130  and clients  104 ,  108 , and  110  may utilize networked enabled code related to communication link  112 . Network enabled code may be, include or interface to, for example, Hyper text Markup Language (HTML), Dynamic HTML, Extensible Markup Language (XML), Extensible Stylesheet Language (XSL), Document Style Semantics and Specification Language (DSSSL), Cascading Style Sheets (CSS), Synchronized Multimedia Integration Language (SMIL), Java™, Jini™, C, C++, Perl, UNIX Shell, Visual Basic or Visual Basic Script, Virtual Reality Markup Language (VRML) or other compilers, assemblers, interpreters or other computer languages or platforms. 
       FIG. 2  is a flow diagram illustrating the logical relationship between functional components of a system that processes applications for financial services according to one embodiment of the invention. One purpose of the processes depicted in  FIG. 2  is to make a decision, for each application, whether an offer should be made to an applicant for financial services such as a credit card account or a mortgage. The processes may also be used to establish terms of such an offer, for instance the maximum amount of money to be loaned, or the minimum interest rate to be charged. 
     Many of the functional elements in  FIG. 2  can be related to components of the system architecture depicted in FIG.  1 . For example, scanned applications  200  may reside on client  104 ; telephonic applications  202  may reside on client  108 ; and online applications  204  may be provided by client  110 . Additionally, the functional elements in  FIG. 2  identified as the input interface  208 , processor  210 , and decision router  214  may be executed on server  114 . Memory  212  may correspond to database  134 . Decision engines  216 ,  218 , and  220  may be embodied in servers  116 ,  118 , and  120 . Credit bureaus  224 ,  226 , and  228  may operate through servers  122 ,  126  and  130 . Data source  206 , decision engine  222 , and credit bureau  230  are shown to indicate the expandability of the application processing method. The interface to fulfillment process  232  illustrates that a positive result from processing an application may be, for example, a downstream process that issues a credit card or provides some other consideration to the applicant. In another embodiment, fulfillment process  232  may interface more directly to decision engine  216 ,  218 ,  220 , or  222 . 
     Advantageously, input interface  208  is adapted to receive electronic application data from a variety of input sources and types, depicted in  FIG. 2  as  200 ,  202 ,  204 , and  206 . 
     Processor  210  may perform or coordinate functions such as data collection, validation, tracking, repair, routing, fulfillment, and reporting. Data collection relates to application data received through interface  208 . Validation may involve checking the application data received against a pre-defined set of criteria in order to identify data input or translation errors originating, for example, at sources  200 ,  202 ,  204 , or  206 . The repair function may be able to fix at least some of the errors types that are detected by the validation function. The routing function relates, for instance, to coordination of the decision router  214  described in more detail below. Processor  210  also may interface to or coordinate the passing of data to fulfillment process  232 , for example in the case where a credit account is to be established or where a credit card is to be physically mailed to the customer of a bank or other financial institution. 
     Processor  210  may operate on the application data in either batch or real time mode. Batch mode may operate on a group of applications only at off-peak hours. Alternatively, batch mode may operate both during peak and off-peak hours to achieve workload leveling (in effect reducing or eliminating peak loads). Real time mode is required for interactive processing sessions, for example where an applicant is making application online and where a response is made to that applicant regarding an offer of financial services within seconds or minutes. Together, the flexible input interface  208  and selectable modes of processor  210  maximize the efficiency of server  114  and decision engines  216 ,  218 ,  220 , and  222 , and eliminate the need for dedicated application processing systems for different application data sources or types. 
     Decision router  214  performs at least three functions. First, it controls the routing of application data to decision engine(s)  216 ,  218 ,  220 , and/or  222 . Decision router  214  may select a single decision engine, for example where decision engines  216 ,  218 ,  220 , and  222  are each tailored for different financial services and where the applicant has only applied for a single financial service. Decision router  214  may select two or more decision engines to process the application data simultaneously, for instance where the applicant has applied for more than one type of financial service. Such parallel processing may also be appropriate where the results of two or more decision engines are used to make a determination as to an offer for a single financial service. Decision router  214  may also select two or more decision engines to process the application data in serial fashion. This may be advantageous, for example, where the single financial service applied for was denied, but where the financial institution wishes to consider other financial services that it might offer to the applicant. Additionally, two or more decision engines may be selected for serial operation where the results of one decision engine can be used in subsequent calculations by another decision engine. Better decisions regarding offers for financial services may result from the ability to select and employ one or more decision engines during application processing. 
     A second function of decision router  214  is to provide formatting of the application data as required by each type of decision engine. In general, different developers may have coded decision engines  216 ,  218 ,  220 , and  222 , and they may have done so at different times. It is therefore unlikely that the required formats for the application data that they process are consistent. Decision router  214  may therefore utilize a library of decision engine proxies to format application data received from input sources  200 ,  202 ,  204 , or  206  into the appropriate format for decision engines  216 ,  218 ,  220 , and/or  222 . The flexibility of this interface allows those who maintain the application processing system to readily connect to new or different decision engines. This may result in substantial time and cost savings. 
     A third function performed by decision router  214  is to receive the decisions reached by decision engines  216 ,  218 ,  220 , and/or  222  and route them to other decision engines or to processor  210 , as appropriate. 
       FIG. 2  also illustrates that decision engines  216 ,  218 ,  220 , and  222  may each obtain historical credit information from one or more credit bureaus  224 ,  226 ,  228  and  230  that is considered together with application data from input sources  200 ,  202 ,  204 , and  206  in making credit or other decisions. The decision engines,  216 ,  218 ,  220  and  222  may include, for example, the commercial MagnuM™, ACAPS™, FirstClass™ or other engine or service. 
       FIG. 3  is a flow diagram illustrating a method for processing applications related to financial services according to one embodiment of the invention. The diagram demonstrates that after an appropriate start  300 , typically the receipt of application data, the processor must determine the input channel  302  from which the data came. If the data originated with a scanned paper application  304  or other non-interactive session  324 , then batch mode is selected  310 . Batch mode may function by placing data in a queue  312  until the queue becomes full  314  or until the processor determines that the decision engines have sufficient processing capacity (as with the load leveling technique described above). Thereafter, one or more decision engines are selected  316 , and all applications in the batch are sent  318  to the decision engine(s). After decisions are received  320 , positive results are sent to the fulfillment process  322 . 
       FIG. 3  also illustrates that data from telephonic applications  306  or Internet applications  308  that are part of an interactive session  324  are selected  326  for real time processing. In real time mode, one or more decision engines must also be selected  328  before applicant data is sent  330  to the decision engines. In contrast to the batch mode, however, once results are returned  332 , notification is made to the applicant in real time  334  before initiating the interface to the fulfillment process  322 . 
     The dual mode capability illustrated by  FIG. 3  provides an advantage for financial entities: separate systems for batch and real time processing of financial applications are not required. This may result in lower operating and support costs. 
     In an another embodiment of the process shown in  FIG. 3 , both alternatives operate in real time mode. In this instance, the only difference between alternative flows may be that one processing path provides for real-time feedback (process-and-notify) whereas the other does not (process). 
       FIG. 4  is a flow diagram illustrating the inputs and outputs of an automated Graphical User Interface (GUI) generator  500 , which has been adapted for mediating communication between an application processing system and an applicant. The initial input is represented by domain data  400 . Domain data  400  may include, for example, the name of an applicant and the location on the application that the name is to be found. Domain data  400  may similarly include the description and location of the applicant&#39;s address, present employer, or other information. Domain data  400  may be generated manually, for example by key entry, or it may be automated, as in the case of document scanning and character recognition. Generation of domain data  400  may further involve automatic conversion from a flat file format to XML format. The output of GUI generator  500  may be a User screen  600  that has been tailored for collecting and displaying information relevant to one or more financial services. There may be hundreds or even thousands of different embodiments of user screen  600 . Automated generation of the user interface eliminates the time and expense that would otherwise be associated with manual code generation. 
     User screen  600  may further have a spatial correspondence to the variety of paper applications that it relates to. This may be an advantage, for example, where an agent of the financial entity processing the application is comparing the electronic version of application data to an original paper copy of the application. Where a user adds data to user screen  600 , data from that screen may then become another input to GUI Generator. 
       FIG. 5  is a flow diagram illustrating a method for mediating communication between a system and a user, according to one embodiment of the invention. All processes shown may be implemented via application software included in input interface  208 , and may reside on server  114 . In the instance where GUI generator  500  is to display a user screen  600  based on domain data  400 , the GUI mediator  502  calls HTML factory  508  and utilizes XSL transformation  510  to convert XML formatted domain data  400  into an HTML user screen  600 . In the instance where GUI generator  500  is to receive data that is input on user screen  600 , GUI mediator  502  may validate the input data using GUI validator  504  and/or GUI double key checking  506 . 
     GUI validator  504  may use a rules engine to perform a validation on the data entered by the user in step  600 . Such rules may be encoded in a database using Java-like syntax, and may be loaded on instantiation of the service. GUI validator  504  may be implemented according to the JavaCC rules engine. 
     The GUI double key checking process  506  may be responsible for scanning the XML document to determine, for example, which fields need to be double keyed. In one embodiment, all double keyed fields may be cleared of text and returned to the user for re-keying. The original values may be stored in the document. If the re-key and the original input match, the document may be forwarded. 
       FIG. 6  is the schematic of a user screen resulting from operation of an automated Graphical User Interface (GUI) generator, according to one embodiment of the invention. The notional schematic illustrates that a user screen  600  may include a tool bar  602 , drop down menu, or similar technique for selecting user functions. User screen  600  may also include data fields for collecting or correcting applicant data  604 , or for defining, selecting, or viewing information about financial services that may be offered to the applicant  606 . 
     The specification and examples provided above should be considered exemplary only. It is contemplated that the appended claims will cover any other such embodiments or modifications as fall within the true scope of the invention.