US20080270295A1 - Method and Apparatus for Real Time Online Credit Approval - Google Patents

Method and Apparatus for Real Time Online Credit Approval Download PDF

Info

Publication number
US20080270295A1
US20080270295A1 US11/932,498 US93249807A US2008270295A1 US 20080270295 A1 US20080270295 A1 US 20080270295A1 US 93249807 A US93249807 A US 93249807A US 2008270295 A1 US2008270295 A1 US 2008270295A1
Authority
US
United States
Prior art keywords
applicant
credit
data
offer
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/932,498
Inventor
Jeremy R. Lent
Mary Lent
Eric R. Meeks
Yinzi Cai
Timothy J. Coltrell
David W. Dowhan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=22680019&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=US20080270295(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Priority claimed from US09/595,601 external-priority patent/US6795812B1/en
Priority claimed from US10/901,715 external-priority patent/US20050004864A1/en
Application filed by Individual filed Critical Individual
Priority to US11/932,498 priority Critical patent/US20080270295A1/en
Publication of US20080270295A1 publication Critical patent/US20080270295A1/en
Priority to US13/458,328 priority patent/US20120215682A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/03Credit; Loans; Processing thereof
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08Insurance

Definitions

  • the present invention relates generally to electronic commerce. More specifically, the invention relates to methods and apparatuses for providing real time credit approval to an applicant online by obtaining data from an applicant, verifying and formatting the data so obtained in a manner that permits accessing the applicant's credit report, and making an underwriting decision to grant or deny credit to the applicant in real time based on data from one or more credit bureau reports.
  • the present invention provides a system and method for obtaining information from an applicant, accessing credit bureau information and making a real time underwriting decision to accept or reject the applicant.
  • a parsing engine parses the information provided by the applicant so that it may be sent directly to a credit bureau. Information obtained from one or more credit bureaus is used by an underwriter engine to make a decision whether to grant credit to the applicant.
  • the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer readable medium. Several inventive embodiments of the present invention are described below.
  • a method of providing real time approval of credit over a network is disclosed. The method includes obtaining applicant data from an applicant.
  • the applicant data is analyzed into a form suitable for directly obtaining a credit report from a credit bureau for the applicant.
  • a credit report having credit report data is obtained from a credit bureau for the applicant. It is then determined whether to accept the applicant using the credit report data and it is communicated to the applicant that the applicant has been approved.
  • FIG. 1 is a block diagram illustrating a preferred architecture for a system that provides instant on-line credit card approval.
  • FIG. 2 is a block diagram illustrating an application data structure that is used in one embodiment to store the data contained in an application and to keep track of the status of the application as it progresses through the various modules described in FIG. 1 .
  • FIG. 3 is a flow chart illustrating the general process flow through the modules of FIG. 1 .
  • FIG. 4A is a flow chart illustrating a validation process that is used in step according to one embodiment of the invention.
  • FIG. 4B is a flow chart illustrating a process for parsing an address entered by an applicant.
  • FIG. 5 is a flow chart illustrating a pre-credit bureau test performed in one embodiment of the invention.
  • FIG. 6A is a flow chart illustrating a process for making an underwriting decision using multiple credit reports.
  • FIG. 6B is a flow chart illustrating a process implemented on the Underwriter for using credit bureau data to accept or reject an applicant in one embodiment.
  • FIG. 6C is a flow chart illustrating a process for using the FICO score combined with other attributes to accept or reject an applicant.
  • FIG. 7 is a flow chart illustrating a process for checking the status of an application and executing either an offer process or one of several rejection processes.
  • FIG. 8A is a flow chart illustrating a process for determining an appropriate reason to display for rejecting an applicant and displaying that reason.
  • FIG. 8B is a diagram illustrating one data structure used to map main FICO factors provided by the credit bureau (referred to as external codes) to internal decline codes as well as reasons for rejection to be provided to rejected applicants.
  • FIG. 9 is a flow chart illustrating how a rejection reason may be obtained.
  • FIG. 10A is a flowchart illustrating a process for providing a set of multiple offers to an applicant and receiving a balance transfer amount corresponding to an offer selected by the applicant.
  • FIG. 10B is a flow chart illustrating one such method of deriving a credit limit for an applicant based on the applicant's FICO score and income, as well as the amount of total revolving balance that the applicant elects to transfer.
  • FIG. 11 is another data representation illustrating another embodiment of how the offers may be determined based on FICO score, income range, income, and total revolving balance transfer.
  • FIG. 12 is a diagram illustrating a display provided to the applicant for the purpose of presenting multiple offers to the applicant.
  • FIG. 13 is a flow chart illustrating a process for obtaining a real-time balance transfer from an applicant.
  • FIG. 14 is a block diagram illustrating one computer network scheme that may be used to implement the system described herein.
  • FIG. 15 is a block diagram illustrating a system for providing real time chat help to an applicant and generating a counter offer when appropriate.
  • FIG. 16 is a flowchart illustrating a general process implemented on the chat server.
  • FIG. 17 is a flow chart illustrating a general process implemented on the web server for sending dynamic web pages to the applicant.
  • FIG. 18 is a flow chart illustrating a process implemented on a browser for establishing a connection to a chat server.
  • FIG. 19 is a flowchart illustrating a typical process implemented on the browser for the purpose of initializing chat when the user does not respond to a downloaded web page in a certain period of time.
  • FIG. 20 is a flow chart illustrating a process implemented on a chat server when a chat session is requested by a browser as described above.
  • FIG. 21A is a flow chart illustrating a process implemented at a customer service agent for the purpose of supporting the chat session.
  • FIG. 21B is a screen shot illustrating a display of offer terms used in one embodiment for determining which terms are unacceptable.
  • FIG. 22 is a flow chart illustrating in detail a process implemented in step 712 for obtaining the unacceptable terms of an offer from an applicant.
  • FIG. 23 is a flow chart illustrating the process implemented on the counter offer server when more than one term is selected as being unacceptable to the applicant.
  • FIG. 24 is a flow chart illustrating an example process for generating a counter offer.
  • FIG. 25 is a flowchart illustrating a process implemented on a counter offer server to generate and confirm a new offer for display to the applicant.
  • FIG. 26 is a flowchart illustrating a process implemented on the web server portion of the application server for the purpose of displaying a new counter offer to the applicant.
  • FIG. 27 is a flow chart illustrating a process used in one embodiment to automatically generate a refresh on the applicant's browser.
  • FIG. 1 is a block diagram illustrating a preferred architecture 102 for a system that provides instant on-line credit card approval.
  • an application engine 104 creates an application by prompting an applicant for data and storing the entered data.
  • the application engine creates an application by communicating with the applicant over the World Wide Web using Java, html or other commonly used Internet protocols. In other embodiments, other types of connections may be established between the applicant and the application engine.
  • the application includes applicant data such as the applicant's address and social security number. Once created, the application is received by the parsing engine 106 which parses an applicant's name and address and creates appropriate software objects.
  • the parsing engine 106 parses the data into an exact format that may be used to directly access credit bureau data. The applicant is given an opportunity to view how the data submitted has been parsed and to make corrections to parsed data, if necessary.
  • the parsing engine 106 is described in further detail in FIG. 4B .
  • the parsed data is passed to a Validator 108 .
  • Validator 108 validates certain data entered by the applicant such as the social security number and zip code. Validation may include checking either the form of a number to ensure that the correct number of digits have been entered or checking content such as checking that the area code portion of a phone number is a valid area code or checking that a zip code matches a city. If the data is determined to be valid, then the validated data is input to an Underwriter 110 . It is important to avoid sending invalid data to the Underwriter to avoid the cost of requesting credit reports that cannot be used.
  • Underwriter 110 receives data from the parsing engine and evaluates the data to determine if the applicant should receive an offer for credit.
  • the Underwriter sends the parsed data to at least two credit bureaus, receives data from the credit bureaus, and makes an underwriting decision based on an analysis of the credit bureau data. The analysis may include, but is not limited to, comparing the applicant's Fair Isaac Risk Score (FICO score) to certain thresholds.
  • FICO score Fair Isaac Risk Score
  • Underwriter 110 is described in further detail in FIGS. 6A and 6B . If the Underwriter determines that an offer of credit should be extended to the applicant, then an offer is made in real time to the applicant.
  • the offer may include one or more sets of alternative terms and those terms may be conditioned on the applicant taking certain actions such as transferring balances. The applicant may be required to actually take such actions in real time before an offer conditioned on such actions is confirmed. If the Underwriter determines that no offer of credit should be extended, then the Underwriter determines a reason for rejecting the applicant.
  • FDR First Data Resources, Inc.
  • an application object loader 114 loads the appropriate application for reentry into the system.
  • the data that is processed and stored by each module is stored as an application object as is described further in FIG. 2 .
  • the data is stored in other ways, such as in a table or in a database.
  • FIG. 2 is a block diagram illustrating an application data structure 202 that is used in one embodiment to store the data contained in an application and to keep track of the status of the application as it progresses through the various modules described in FIG. 1 .
  • Application data structure 202 includes an application object 204 that is created by the application engine.
  • Application object 204 points to a number of associated data structures, including an applicant object 206 .
  • Applicant object 206 stores applicant data and includes one or more data elements 208 .
  • an applicant data element 208 may include information such as the applicant's address, phone number, or social security number.
  • the application data structure also includes one or more test result objects 210 .
  • Each test result object 210 stores a validation status 212 associated with a validation test applied to the data associated with applicant object 206 .
  • a test result object may include a social security number status indicating whether the social security number entered by the applicant is a valid social security number.
  • a test result object 210 may include a zip code status indicating whether the zip code entered by the applicant matches the rest of the address entered by the applicant. Test result objects are used to check whether data entered by the applicant is valid before certain actions are taken, such as a credit report being ordered.
  • the application data structure further includes a set of credit report objects 214 associated with each credit report ordered.
  • the Underwriter requires at least two credit reports from two of three credit bureaus before a decision to grant credit is made. This rule effectively enables a real time credit decision to be made without incurring an unacceptable amount of risk. Since credit reports are preferably ordered from more than one credit bureau, the application data structure will likely include several credit report objects.
  • Each credit report object 214 includes a plurality of attributes 216 .
  • An attribute is an item of data provided by the credit bureau in the credit report. For example, one such attribute is a 90 day attribute that indicates the number of times that the applicant has been more than 90 days late in payment of a debt. Similarly, a 60 day attribute may be provided.
  • Other attributes may include a FICO score, the number of times the applicant has been severely delinquent, existence of a derogatory public record, whether the applicant is now delinquent, the applicant's total revolving balance, and the amount of time that a credit report has been on file for the applicant (also referred to as “thickness of file” or “time on file.”
  • the Underwriter bases its decision on the FICO score alone when the FICO score is below a rejection threshold. In some embodiments, there may be automatic approval when the FICO score is above an approval threshold.
  • the application data structure further includes FDR data object 218 associated with the application.
  • FDR data is created by the creditor module for the purpose of sending application information to FDR so that FDR may send credit cards to successful applicants and send rejections to unsuccessful applicants, when that is required.
  • the application object also includes a status object 220 .
  • the status of the application object is determined at various times by the modules. For example, the Validator module may determine that the application is invalid based on an invalid social security number or zip code.
  • the Underwriter module may also determine that the application is a duplicate, as will be described below.
  • the Underwriter may also change the status of an application to accepted or declined.
  • certain applications may be tagged with a fraud status flag indicating that there is a likelihood of fraud.
  • the application data structure also may include a set of offers 222 to be provided to the applicant.
  • FIG. 3 is a flow chart illustrating the general process flow through the modules of FIG. 1 .
  • the process starts at 300 .
  • applicant data is obtained via html, Java or other suitable network protocol.
  • the information entered by the applicant may be either parsed first by the parsing engine or validated first by the Validator.
  • FIG. 3 shows Validation occurring first in a step 306 .
  • FIG. 1 alternatively shows the parsing engine operating first. If the information is not valid, then control is transferred from a step 308 to a step 309 and the applicant is given an opportunity to edit the data. The Validator then rechecks the edited data.
  • control is transferred to a step 310 where the data entered is displayed along with the field assigned to each part of the data by the parsing engine.
  • This step is important to ensure that the data will be readable when it is sent to a credit bureau by the Underwriter. An exact match is required by the credit bureaus for the correct credit report to be sent.
  • Various ambiguities in the way that an address may be expressed can cause difficulties. Such difficulties have been a significant factor in preventing other systems from allowing individuals to directly access credit bureau data. For example, it is necessary to distinguish a street direction that is part of a street address from a street name that happens to be a direction, such as “North.”
  • the parsing engine categorizes each part of the entered address and presents the field names along with that portion of the address that it has assigned to each field name. So, for example, the applicant can move “North” from a street direction field to a street name field if that is appropriate.
  • the parsing engine enables applicants with no knowledge of the Byzantine structure required by the credit bureaus to enter personal data in a manner that allows a credit report to be obtained without human intervention.
  • Initial parsing is achieved by analyzing the form of the address and dividing, for example, the street number, street name, city and state.
  • a step 311 transfers control to a step 312 where pre-credit bureau tests are run on the data. If the applicant edits the data, then control is transferred back to step 306 and the data is re-checked for validity. If the applicant fails the pre-credit bureau test, then the applicant's status is changed to rejected in a step 313 and if the applicant passes the pre-credit bureau test, then the credit bureaus are accessed and credit bureau tests based on the data obtained from the credit bureau and other applicant data are performed in a step 314 . If the applicant passes the credit bureau tests, then post credit bureau tests are run in a step 316 . If the applicant passes the post credit bureau tests, then the applicant is accepted to receive an offer for credit and the approval process ends at 320 .
  • the application status is changed to rejected in a step 315 .
  • an on line rejection process is executed for applications with a rejected status.
  • the applicant information is input to a series of tests and the result of the tests determines whether the applicant is accepted or rejected.
  • FIG. 4A is a flow chart illustrating a validation process that is used in step 306 according to one embodiment of the invention.
  • the Validator performs a plurality of validation tests on the applicant data.
  • the process starts at 400 .
  • the applicant's address is validated according to an address validation test.
  • address validation includes checking that a street number and street name are entered and not a P0 box.
  • a validation status associated with the address validation test is stored in a test result object.
  • the applicant's phone number is validated according to a phone number validation test.
  • the phone number validation test may include checking the number versus one or more tables or checking that an appropriate number of digits are provided.
  • a validation status associated with the phone number validation test is stored in a test result object.
  • the applicant's social security number is validated according to a social security number validation test.
  • a validation status associated with the social security number validation test is stored in a test result object and the process ends at 420 .
  • the form of the data entered by the applicant is checked to determine whether the data entered is at least potentially correct. For example, if a social security number that does not exist for anyone is entered, it can be determined that the entered data must be invalid.
  • additional validation tests may be performed. Specifically, validation tests that help detect fraud may be implemented.
  • the validation status associated with each test result object includes a time stamp. Multiple applications with the same or similar names may be tracked and a history may be saved. Fraud tests may be implemented that track the number of applications submitted by a given individual and check the consistency of applicant data between multiple submitted applications.
  • FIG. 4B is a flow chart illustrating a process for parsing an address entered by an applicant.
  • the process starts at 450 .
  • the address is split into fields using a parser.
  • the parsing result is displayed.
  • the applicant is prompted to indicate whether or not the parsing result is correct in a step 456 . If the result is not correct, then control is transferred to a step 458 and the applicant is allowed to change the fields assigned to each part of the data.
  • control is transferred to a step 460 and the parsed data is sent to the Underwriter. It should be noted that the data may also be sent through the Validator again if the data was changed by the user.
  • the process ends at 462 .
  • FIG. 5 is a flow chart illustrating a pre-credit bureau test performed in step 312 in one embodiment of the invention.
  • Pre-credit bureau tests are performed prior to obtaining one or more credit reports for the applicant for the purpose of avoiding the expense of obtaining a credit report for certain applicants who would not be approved regardless of the content of the credit report. For an example, an applicant could be rejected based the applicant being of a minor age.
  • the pre-credit bureau test is performed by the Underwriter. In other embodiments, the pre-credit bureau test may be performed by the parsing engine or a separate module.
  • the process starts at 500 .
  • the applicant's income is obtained.
  • the status of the application may be set to declined in a step 506 .
  • the applicant's age is obtained.
  • the applicant is verified to meet a minimum age criteria. For example, the minimum age may be 18 . If the applicant fails to meet the minimum age criteria, the application status may similarly be set to declined in a step 512 . It should be noted that the above description recites that age and income are checked in separate steps. Alternatively, they may be checked together.
  • Step 514 checks whether the application entered is a duplicate application. If the applicant has previously entered the information in the application database, then the current application is a duplicate application. It is important to recognize such duplicate applications so that a single applicant cannot require multiple credit reports to be obtained.
  • duplicate applications are recognized by checking for duplicate social security numbers, duplicate names and/or duplicate addresses. In order to be rejected by the system, an application must match two of the three criteria. A rule is established that an applicant may reapply for a credit card after a specified time period has elapsed (e.g., 60 days).
  • Such a rule is implemented in a step 516 that checks whether the application submission date exceeds a specified time period since the submission date of the found duplicate application. If the application is submitted prior to the specified time period, the status of the application is changed to duplicate in a step 518 and the process ends at 520 .
  • pre-credit bureau tests have been shown for the purpose of illustration. Other tests can be used within the scope of this invention. Also, it should be noted that if one test is failed, then remaining tests are skipped in some embodiments. Alternatively, all of the pre-credit bureau tests may be performed and the pre-credit bureau test results may be stored in separate question objects. This may help detect potentially fraudulent applicants who create many duplicates. If an application is determined potentially to be fraudulent, the status of the application is changed to fraud. Alternatively a separate flag may be set to indicate the potential fraud.
  • the application is ready to be checked by the Underwriter to determine whether credit should be approved for the applicant.
  • the Underwriter makes such a determination based on the information obtained from credit bureaus. Since the decision made by the Underwriter is made without human intervention, it is particularly important that the method of determination made by the Underwriter is reliable. For this reason, it is preferred that, in order for an applicant to be approved, at least two credit bureaus must provide information about that applicant that passes a series of tests. In some embodiments, this rule may be relaxed, but a process that requires data from at least two credit bureaus for approval has been shown to have superior reliability to processes without such a requirement. In particular, it has been determined that requiring data from at least two credit bureaus for approval is an important factor in enabling the real time credit approval system to make sufficiently reliable determinations.
  • FIG. 6A is a flow chart illustrating a process for making an underwriting decision using multiple credit reports.
  • the process starts at 600 .
  • a step 602 a first credit bureau test is performed.
  • the process of performing a test on individual credit bureau data is further described in FIG. 6B . If that test is failed, then the application is rejected in a step 604 and the process ends at 606 .
  • Immediately rejecting the application after a first failure saves the cost of obtaining a second credit bureau report.
  • the first credit bureau test does not fail, either because no report is obtained or because the test is passed, then control is transferred to a step 608 and a second credit bureau test is performed. If that test is failed, then the application is rejected in step 604 and the process ends at 606 .
  • the second credit bureau test does not fail, then it is determined in a step 612 whether two credit bureau tests have been passed. If two tests have been passed, then the application is accepted in a step 614 and an offer is determined as described below.
  • step 616 it is determined whether one credit bureau test has been passed. If one credit bureau test has not been passed, then the application is rejected in a step 618 for not having a record in at least two credit bureaus. The third credit bureau is not checked since it is not possible to get at least two credit reports at that point. If one credit bureau test has been passed, then a third credit bureau is consulted in a step 620 . If the third credit bureau test is failed, then the application is rejected in a step 622 and the process ends at 606 . If the third credit bureau report does not have a record for the applicant, then the application is rejected in step 618 for not having enough credit records and the process ends at 606 . If the third credit bureau test is passed, then the application is accepted in a step 624 and the process ends at 606 .
  • the Underwriter only accepts applications that pass at least two credit bureau tests. It should be noted that a special reason for rejection may be given to applicants who are rejected because they do not have a record in at least two credit bureaus. Also, it should be noted that in some embodiments, it is distinguished whether a credit report is not obtained because a credit bureau is temporarily unavailable or whether a credit report is not obtained because there is no record for the applicant. In the event that a credit bureau is unavailable, an applicant that cannot be found in the remaining two credit bureaus may be given a special rejection notice indicating that a later attempt should be made by the applicant when the unavailable credit bureau is functioning. Also, when two credit bureaus are unavailable at the same time, all applicants may be requested to reapply when the credit bureaus return on line.
  • FIG. 6B is a flow chart illustrating a process implemented on the Underwriter for using credit bureau data to accept or reject an applicant in one embodiment.
  • the process starts at 650 .
  • a credit report is requested from the credit bureau.
  • the credit report can be requested using data entered directly by the applicant because the parsing engine classifies the data into appropriate fields to be sent to the credit bureau.
  • the Underwriter performs tests on the data in the credit report. Data entered by the applicant may be used for Underwriter tests as well.
  • a set of attribute tests are performed using the credit report. Attribute tests are general tests that may be applied to any credit report. Each attribute test corresponds to a general attribute provided in the credit report.
  • Attribute tests may include threshold tests, which compare certain parameters such as a FICO score to a threshold, or logical tests, which check for the existence of certain adverse records.
  • a set of credit report specific tests are performed using the credit report.
  • a set of credit report specific tests may be defined for each credit bureau. Each credit report specific test corresponds to data that is specific to a particular credit bureau.
  • the credit bureau tests may be separately performed to avoid performing the remaining tests once the failure of the application to pass a test results in a determination that the application will be declined. However, each of the set of attribute tests and credit report specific tests are preferably performed so that the best basis for rejection may be identified and provided to the applicant. Determining an appropriate basis of rejection to display to the applicant is described further below in connection with FIG. 7 . It is determined in a step 660 whether the applicant passed the credit tests and the application is rejected in a step 662 if the applicant failed the tests. If the applicant passes the tests, that is noted in a step 664 for the purpose of determining whether the applicant should be accepted as described in FIG. 6A . The process then ends at 670 .
  • the process of performing the various tests may generally be considered as performing various attribute tests and credit specific tests and combining the results of those tests in some fashion to make a decision to pass or fail an applicant.
  • FIG. 6C is a flow chart illustrating a process for using the FICO score combined with other attributes to accept or reject an applicant.
  • the process starts at 680 .
  • the FICO score is checked. If the FICO score is below a rejection threshold, then the application is rejected in a step 684 . If the FICO score is above an acceptance threshold, then control is transferred to a step 688 and other attributes are checked. If any attribute tests are failed, then control is transferred to step 688 by a step 690 and the application is rejected. If all attribute tests are passed, then control is transferred to a step 692 and the application is accepted.
  • the process ends at 694 .
  • an applicant is accepted automatically if he or she has a FICO score that is above a certain threshold.
  • the attribute tests performed in step 688 may take on various forms.
  • a list of attributes is checked including attributes such as whether the applicant is severely delinquent, currently delinquent, has a derogatory public record, or has been delinquent a certain number of times in a past period.
  • a test may be defined for each attribute such as a maximum number of times delinquent above which the test is failed.
  • a list of tests is defined and all of the tests must be passed.
  • a list of tests is defined and certain subsets of the list are also defined. At least one subset must be passed for the applicant to pass.
  • the status of the applicant is set to be accepted or rejected.
  • Rejected applications are processed in a rejection process described in FIG. 7 .
  • Accepted applications are processed in an offer and confirmation process described in FIG. 10A .
  • FIG. 7 is a flow chart illustrating a process for checking the status of an application and executing either an offer process or one of several rejection processes.
  • the process starts at 700 .
  • the status of the application is checked based on the processing performed by the Underwriter. As mentioned above, the Underwriter determines whether the application is a duplicate application, whether enough credit bureaus are available to provide sufficient credit reports to evaluate the application, and whether applications having sufficient credit reports should be accepted or rejected.
  • a link to a reentry screen is provided to the applicant.
  • the reentry screen allows the applicant to execute a process that finds the earlier application and allows the applicant to review or resume the earlier application. For example, if the earlier application was accepted but the applicant did not accept an offer, then the process may resume at that point and the applicant may be given another opportunity to accept. This is preferable to allowing the application process to be repeated from the beginning since that could needlessly cause a new credit report to be obtained.
  • the process ends at 720 .
  • control is transferred to a step 714 and an offer process is executed.
  • the offer process is described in further detail in FIG. 10 . If the status of the application is that a credit bureau error occurred, then control is transferred to a step 710 and an error message is displayed indicating that not enough credit bureaus are currently available to allow the application to be processed. Also, in a step 712 , a link is provided to a site that allows the applicant to report the error and request further information or request to be contacted. After the offer process or the credit bureau error process is executed, the process ends at 720 .
  • control is transferred to a step 704 and a rejection process is executed.
  • the rejection process is described in further detail in FIG. 8A and FIG. 8B . Once the rejection process is executed, the process ends at 720 .
  • FIG. 8A is a flow chart illustrating a process for determining an appropriate reason to display for rejecting an applicant and displaying that reason.
  • the process starts at 800 .
  • the main factors given by the credit bureau that affect the FICO score are obtained.
  • the main factors identified by the credit bureau for the FICO score are provided in the form of a numerical code that corresponds to a predetermined factor.
  • the credit bureau code is mapped to an internal code that is determined from a data structure that maps bureau codes to internal factors.
  • the data structure is a table such as that illustrated in FIG. 8B .
  • a step 806 checks whether any of the FICO reasons have been mapped to any specific rejection reasons. If all of the FICO reasons map only to the general reason, then control is transferred to a step 808 .
  • step 808 the rejection process begins to attempt to find a more appropriate reason for rejection of the applicant.
  • the results of the various attribute tests generated by the Underwriter are obtained.
  • a step 810 it is checked whether any of the attribute test results map to an appropriate rejection reason. If an attribute test result maps to an appropriate reason, then control is transferred to a step 812 and the attribute reason is assigned as the reason given to the applicant upon rejection. If the attribute test does not map to an appropriate reason, then control is transferred to a step 816 and a general reason is assigned as the reason given to the applicant upon rejection.
  • step 806 If, in step 806 , it was determined that one or more of the FICO score factors identified by the credit bureau correspond to an acceptable rejection reason other than the general rejection reason, then that reason is assigned as the reason to be given to the applicant in a step 814 . Whether or not a specific reason is identified by that above mentioned steps, control is transferred to a step 818 where the reason is displayed to the applicant and the process then ends at 820 .
  • FIG. 8B is a diagram illustrating one data structure used to map main FICO factors provided by the credit bureau (referred to as external codes) to internal decline codes as well as reasons for rejection to be provided to rejected applicants.
  • external codes main FICO factors provided by the credit bureau
  • Each external code maps to an internal code that corresponds to an internal reason for rejecting the applicant. The actual reason is also stored for each internal code. As described above, certain external codes correspond to internal codes that provide only a general rejection reason. Other external codes are mapped to internal codes that allow a specific rejection reason to be given.
  • FIG. 9 is a flow chart illustrating how a rejection reason may be obtained.
  • the process starts at 900 .
  • the reason for rejection is retrieved.
  • the rejection reason is displayed.
  • a link to a credit counseling site is also displayed.
  • the acknowledgement button is displayed in a step 908 .
  • a step 910 checks whether the acknowledgement button has been activated.
  • control is transferred to a step 912 where the application is marked as having had an acknowledgement to a rejection. If the acknowledgement button has not been activated, then control is transferred to a step 914 and the application is marked as not having had an acknowledgement to a rejection. The process ends at 916 .
  • an applet is sent along with the rejection that sends a message back to the credit approval system when the rejection message page is completely downloaded by the applicant. In this manner, the fact that a rejection was delivered to the applicant can be verified without requiring any action by the applicant.
  • the rejection or acknowledgement status may be provided to an entity such as FDR for the purpose of generating hard copies of rejection letters and either sending such hard copies as confirmations to all rejected applicants or else, in some embodiments, only sending hard copies of rejection letters to applicants that have not acknowledged an on line rejection.
  • Accepted applications have an accepted status and they also contain important applicant information supplied by the applicant and obtained from the credit bureau reports that can be used to design a custom account level offer for the applicant.
  • multiple offers are presented to the applicant, allowing the applicant to select an offer that includes terms that the applicant desires to accept.
  • FIG. 10A is a flowchart illustrating a process for providing a set of multiple offers to an applicant and receiving a balance transfer amount corresponding to an offer selected by the applicant.
  • the process starts at 1000 .
  • the application object is retrieved.
  • the application object includes the information provided by the applicant as well as information obtained from credit bureaus and analyzed by the Underwriter.
  • offer selection criteria are obtained from the credit report object.
  • the offer selection criteria include FICO score, income and a balance transfer requirement.
  • Offer selection criteria also may include data entered by the applicant.
  • the offer selection criteria also may include other attributes such as time on file.
  • the offer selection criteria are selected from information obtained from the applicant and from the credit bureaus for the purpose of estimating the applicant's risk of default to determine an expectation of future loss as well as an expected future total revolving balance (TRB). In this manner, an appropriate offer may be determined.
  • the balance transfer requirement is calculated as a selected percentage of the applicant's TRB. As described below, different offer terms may be provided for different balance transfer requirements.
  • other data structures than the application object are used to store this information.
  • a set of offers is derived from the credit report data and other applicant information stored in the application object.
  • the set of offers is displayed.
  • the offers are derived from the FICO score and income of the applicant, which determine the risk of default, and also from a balance transfer amount specified in the offer.
  • the balance transfer amount may be determined as a percentage of the total revolving balance that the applicant has on all outstanding credit cards in the credit report for the applicant. Both the credit limit offered to the applicant and the interest rate offered to the applicant may vary according to the amount of the total revolving balance that the applicant chooses to transfer to the new account.
  • offers may present incentives such as frequent flier miles, cash back on purchases, or favorable interest rates.
  • a step 1010 the system notes the selected offer and balance transfer amount.
  • a step 1012 the system obtains the balance transfer amount from the applicant. Preferably, the balance transfer is actually executed while the applicant is on line. The process for obtaining and executing the balance transfer in real time on line is described further in FIG. 13 .
  • a data file is assembled for transmission to FDR for the purpose of issuing a credit card in a step 1014 .
  • the system derives a set of offers based on information from the applicant's credit reports and displays the set of offers to the applicant. The applicant then can select an offer based on the amount of balance transfer that the applicant wishes to make.
  • the system actually executes the balance transfer by allowing the applicant to select the accounts from which to transfer balances.
  • the data relating the application is assembled and sent to FDR.
  • FIG. 10B is a flow chart illustrating one such method of deriving a credit limit for an applicant based on the applicant's FICO score and income, as well as the amount of total revolving balance that the applicant elects to transfer.
  • the process starts at 1020 .
  • the system obtains applicant information and the credit bureau information. This information may include the FICO score and income of the applicant.
  • applicant information and the credit bureau information are used to determine an expected unit loss rate for the applicant In a step 1024 .
  • the unit loss rate corresponds to the probability that the applicant will default on the credit line extended. That probability multiplied by the credit limit extended to the applicant determines the dollar loss rate for that applicant.
  • the dollar loss rate divided by the average total outstanding balance of the account is the dollar charge off rate for the applicant.
  • a dollar charge off rate be kept within a determined range for different applicants. To accomplish this, it is desirable to extend smaller amounts of credit to applicants with a higher probability of defaulting. It is also useful to extend different amounts of credit based on a total outstanding balance transferred by the applicant since the balance transfer influences the likely future total outstanding balance of the account.
  • Conventional offer systems have been able to extend offers to applicants with credit limits that are controlled by the applicant's predicted average dollar loss. However, prior systems have not been able to extend credit and determine a credit limit based on a predicted total outstanding balance for the client because they have failed to be able to present offers and condition the acceptance of the offers in real-time on a balance transfer made by the applicant.
  • the system determines one or more balance transfer amounts based on the total revolving balance that the applicant has in various other credit card accounts.
  • the balance transfer amounts are calculated based on different percentages of the total revolving balance determined from all of the applicant's accounts found in the credit report.
  • the system calculates for each total balance transfer amount choice that will be presented to the applicant, a predicted estimated revolving balance for the future that the applicant would be expected to maintain.
  • the estimated total revolving balance may be equal to the balance transfer amount or may be a function of the balance transfer amount. In one embodiment, the estimated total revolving balance does not depend on the balance transfer amount.
  • the system calculates a predicted total revolving balance for the future. Then, in a step 1030 , the credit limit for the applicant is set to achieve a target dollar charge off rate based on the amount of the total revolving balance that the applicant elects to transfer and the risk of default. The process then ends at 1032 .
  • FIG. 10B shows conceptually how a credit limit could be determined based on an amount of balance transfer and a FICO score and income. This process may be implemented directly in some embodiments. However, in other embodiments, it is preferred that a table be precalculated that includes amounts of credit limit that the applicant will be given based on certain amounts of balance transfer and FICO score. Using such a table, the applicant's FICO score and balance transfer amount may be looked up and then the credit limit may be found in the corresponding cell.
  • FIG. 10C is a table illustrating how this is accomplished. Each row of the table corresponds to a different FICO score, and each column of the table corresponds to a different balance transfer amount. When the cell corresponding to the FICO score and balance transfer amount is determined, the credit limit obtained.
  • a cut-off line 1040 is also shown which represents an upper limit for a balance transfers for a given FICO score.
  • separate tables are prepared for applicants of different incomes.
  • separate tables may also be prepared for applicants having other different characteristics such as time on file for the applicant.
  • the tabular representation of the data is presented as an example only and the data may be represented in many ways including in three-dimensional or four-dimensional arrays, linked lists or other data representations optimized for a particular system.
  • FIG. 11 is another data representation illustrating another embodiment of how the offers may be determined based on FICO score, income range, income, and total revolving balance transfer.
  • a single table includes a range of FICO scores 1108 , an income range 1110 , a balance transfer column 1112 , and four offer columns, 1114 , 1116 , 1118 , and 1120 .
  • Each of the offer columns includes a link to a web page that describes the offer in more detail. Once the proper row of the table is found, multiple offers may be displayed to the applicant by assembling the various links either in a single frame or in consecutive frames for the applicant to view and select an offer.
  • a teaser rate is an interest rate that is temporarily extended to the applicant either on the amount transferred or on the amount transferred and purchases made for a certain period of time.
  • the teaser rate is intended to incent the applicant to transfer a greater balance to a new account.
  • the teaser rate is determined based on the percentage of the applicant's total revolving balance that the applicant elects to transfer. Thus, the amount transferred by the applicant controls not only the applicant's credit limit but also determines a teaser rate extended to the applicant.
  • FIG. 12 is a diagram illustrating a display provided to the applicant for the purpose of presenting multiple offers to the applicant.
  • the display includes a first offer 1204 , a second offer 1206 , a third offer 1208 , and a fourth offer 1210 .
  • For each offer there is a column 1214 corresponding to the initial teaser rate, a column 1216 corresponding to the annual fee offer, a column 1218 corresponding to the credit limit, and a column 1220 corresponding to the required balance transfer for that offer to be accepted.
  • the applicant selects one of the offers from the table.
  • the offers are provided as part of a web page and the offers are presented using html. By selecting an offer, the applicant selects a link that indicates to the system which offer is selected. Once an offer is selected, the process of acquiring the required balance transfer in real-time from the applicant is executed. That process is described further in FIG. 13 .
  • FIG. 13 is a flow chart illustrating a process for obtaining a real-time balance transfer from an applicant.
  • the process starts at 1300 .
  • the system retrieves the accounts and balances that the applicant has based on the credit report data obtained for the applicant.
  • the estimated balances for each of the accounts that were retrieved in step 1302 are presented to the applicant and the accounts are identified. Identification of the accounts is a sensitive issue because the specific account data for the applicant is confidential and if the information is displayed to an unauthorized person, fraud could result. Therefore, in one embodiment, a partial account number that lists the account granting institution as well as part of the account number for the account held by the applicant with that institution is displayed. Generally, this information is sufficient for the applicant to recognize the account, but is not enough information to present a fraud risk.
  • the accounts chosen for display by the underwriter are selected in a manner to facilitate a simpler balance transfer. For example, the largest account balances may be displayed first so that amounts may be efficiently transferred to meet the required transfer. Also, a group of balances to transfer may be presented to the applicant by highlighting certain accounts.
  • the applicant is given an opportunity to indicate a balance transfer by selecting one of the accounts and indicating the amount to be transferred. It should be noted that the applicant in this manner does not need to provide account information to execute a balance transfer. If a transfer is indicated, control is transferred to a step 1306 and the amount of the user balance transfer is obtained. Next, in a step 1307 , it is determined whether the sum of the balance transfers is greater than or equal to the required transfer amounts for the offer selected by the applicant. If the amount is not greater than or equal to the required-transferred amount, then control is transferred back to step 1304 and the applicant is given an opportunity to select further balances to transfer.
  • control is transferred to a step 1308 and the system requests final confirmation from the applicant of the balance transfers. If it is determined in a step 1310 that a confirmation of the balance transfer has been received, then control is transferred to a step 1312 and the balance transfers are executed. The process ends at 1314 .
  • step 1304 If in step 1304 , it is determined that the applicant has elected to exit the balance transfer screen instead of indicating a balance transfer, or if it is determined in step 1310 that the applicant elects not to confirm the balance transfer amounts selected, then control is transferred to a step 1316 and the applicant is returned to the offer selection screen so that the applicant will have an opportunity to select another offer that either does not require a balance transfer or requires less of a balance transfer. The process then ends at 1314 .
  • FIG. 14 is a block diagram illustrating one computer network scheme that may be used to implement the system described herein.
  • An applicant host system 1402 is connected to the Internet 1404 .
  • the applicant host system may be a PC, a network computer, or any type of system that is able to transmit and receive information over the Internet.
  • a private network such as a LAN or WAN or a dedicated network may be used by the applicant to communicate.
  • a web server 1406 is also connected to the Internet and communicates with the applicant host system via the Internet to request receive applicant information and to notify the applicant of the results of the approval process.
  • Web server 1406 in one embodiment accesses a business logic server 1408 that implements the various approval checking processes described herein.
  • the web server and the business logic server are implemented on a single computer system with one microprocessor. However, for the sake of efficiency, the system implemented as shown is often used with different servers dedicated to communicating with applicants and processing applicant data, respectively.
  • the business logic server wherever implemented, includes a communication line on which communication may be had with credit bureaus or other outside data sources. In some embodiments, an Internet connection may be used for that purpose.
  • applicant data is obtained by the business logic server either over the Internet either directly or through a Web server.
  • data may be obtained by the business logic server from an applicant using a direct dial in connection or some other type of network connection.
  • a real time credit approval system has been described herein primarily for the purpose of determining whether a credit card should be issued to an applicant.
  • Software written to implement the system may be stored in some form of computer-readable medium, such as memory or CD-ROM, or transmitted over a network via a carrier wave in the form of Java® applets, other forms of applets or servlets, and executed by a processor.
  • the system may be implemented on a PC or other general purpose computer known in the computer art.
  • the system described may also be used for the purpose of granting credit to an applicant for the purpose of making a single transaction.
  • a transaction is interrupted and the application for credit is made. Based on the real time approval decision made, credit may or may not be granted for the purpose of completing the transaction.
  • an applicant who requests a counter offer is directed to a chat agent.
  • the applicant ID is transferred to the chat agent so the chat agent can access information about the state of the applicant's application.
  • the chat interface uses the chat interface, the applicant explains to the chat agent why the original offer was not acceptable and the chat agent interacts with an application database to determine a counter offer.
  • the counter offer is transferred to the applicant through an application server.
  • a method of offering credit to an applicant includes determining a plurality of offers using information about the applicant. A displayed offer is displayed and a withheld offer is withheld. An indication that the displayed offer is unacceptable is received and the withheld offer is displayed.
  • a method of offering credit to an applicant includes determining a plurality of offers using information about the applicant.
  • a displayed offer is displayed and a plurality of withheld offers are withheld.
  • An indication that the displayed offer is unacceptable is received including an indication that an attribute is unacceptable.
  • a selected withheld offer is selected using the attribute that is unacceptable and the selected withheld offer is displayed.
  • a method of offering credit to an applicant includes determining a plurality of offers using information about the applicant.
  • a displayed offer is displayed and a plurality of withheld offers are withheld.
  • An indication that the displayed offer is unacceptable is received including an indication that a plurality of attributes are unacceptable.
  • a primary unacceptable attribute is determined and a selected withheld offer is selected using the primary unacceptable attribute. The selected withheld offer is displayed.
  • a method of offering credit to an applicant includes determining an offer using information about the applicant and displaying the offer to the applicant. An indication that the displayed offer is unacceptable is received. An attribute of the offer that is unacceptable is determined. In the event that the unacceptable attribute is the amount of the credit limit; the credit limit is recalculated for the applicant.
  • a method of offering credit to an applicant includes determining a first offer using information about the applicant and displaying the first offer to the applicant.
  • a chat interface is activated between the applicant and a customer service agent.
  • a second offer for the applicant is determined based on chat between the applicant and the customer service agent and the second offer is displayed to the applicant.
  • an application server for providing a counter offer of credit includes an applicant interface configured to receive applicant data from an applicant browser and to communicate an offer of credit to the applicant and the counter offer of credit to the applicant.
  • a processor is configured to determine the offer of credit based on the applicant data and the counter offer of credit based on an unacceptable attribute of the first offer of credit and an agent interface is configured to receive the unacceptable attribute from an agent.
  • a chat server for providing a counter offer of credit includes an applicant interface configured to receive chat from an applicant.
  • An agent interface is configured to receive chat from an agent and an unacceptable attribute determined from the chat from the applicant.
  • An application server interface is configured to send the unacceptable attribute and to receive a counter offer.
  • an applicant client for obtaining a counter offer of credit includes an application server interface configured to send applicant information and to receive and offer of credit and a counter offer of credit.
  • a chat server interface is configured to be activated upon an indication that the offer of credit is not acceptable.
  • an applicant interacts with a web server and receives a web page containing offers of credit that may be accepted by the applicant.
  • an online chat button or process may be activated that sends an applicant ID to a chat server and opens a chat window so that the applicant can receive help.
  • the help takes the form of the applicant describing why a displayed offer is unacceptable and a counter offer being generated for the applicant.
  • FIG. 15 is a block diagram illustrating a system for providing real time chat help to an applicant and generating a counter offer when appropriate.
  • a web server 1102 is in communication with an application database 1103 .
  • Application database 1103 is used to store information about the applicant and the application. The information stored includes information provided by the applicant as well as information derived from various credit bureaus (not shown) that are accessed by the web server either directly or indirectly.
  • Each application included in the application database is referenced by an applicant identifier that can be used to identify the application.
  • Web server 1102 provides a web page 1104 to a browser 1106 .
  • the web server and browser communicate over the Internet using HTTP.
  • Web page 1104 is shown for the purpose of illustration as an offer web page that includes three offers made to the applicant for a credit card as well as an on-line chat button that may be activated by the applicant to obtain help or to discuss the offers.
  • Other web pages provided by the web server include forms that the applicant fills out to provide information so that a credit report may be obtained and an offer of credit generated based on the applicant's personal information.
  • the process described herein will refer to the online credit application as being an application for a credit card.
  • the process can also be applied to other offers of credit including an offer of instant credit for the purpose of consummating a single pending online transaction.
  • the system and processes disclosed herein may be applied to other types of business transactions over the Internet.
  • the particular architecture and processes described are especially useful for processing online credit card applications and the benefit of their application to online credit card applications is particularly strong.
  • Web server 1102 and browser 1106 continue to interact in a standard fashion with web pages being provided by web server 1102 and the applicant filling out information as needed.
  • an applicant may activate the online chat button included on the web page and a chat window 1104 a opens up for the chat application and a connection is established with a chat server 1108 .
  • chat window is opened and the connection with chat server 1108 may be initiated by events other than just the activation of the online chat button.
  • Chat server 1108 implements a standard chat environment such as the chat environment available from e-share. Other chat environments may be used that include the ability to pass a variable to the chat server from the browser.
  • the various servers shown in FIG. 15 may be implemented on any typical platform such as a Windows NT platform, a Linux platform, or other UNIX platform or other commercially available web server platform.
  • the browser may be implemented on any system such as a Macintosh or a PC which are readily available.
  • the chat process is initiated when the applicant cancels out of the application. In other embodiments, the chat process is initiated when the applicant lingers on a page for an amount of time that exceeds a threshold. In other embodiments, the chat process is initiated when the applicant's response to a request for information is somehow inadequate. For example, it may be detected that the answers provided by the applicant are incomplete or in the wrong form. The chat process may be initiated for the purpose of providing the applicant more detailed instructions or pointing out to the applicant the information that is required to complete the application.
  • browser 1106 In addition to opening the chat connection to chat server 1108 , browser 1106 also sends the applicant identifier to the chat server.
  • the chat server uses the applicant identifier to access information about the application in the application database.
  • the applicant identifier may be used as an application identifier in circumstances such as would be expected for an online credit card application where there is one and only one application per applicant.
  • an application identifier that is unique for each application is assigned and used. In this description, wherever an applicant identifier is mentioned, an application identifier could also be used.
  • Sending the applicant identifier to the chat server instead of sending the current web page or other information to the chat server is preferable from a security standpoint because the applicant identifier can only be used to obtain information about the application by accessing application database 1103 .
  • the applicant identifier is encrypted, adding a further level of security.
  • chat server 1108 does not have a direct link to the application database 1103 .
  • Chat server 1108 is connected to a customer service agent 1110 .
  • Customer service agent 1110 handles the chat session, responding to requests made by the applicant.
  • Other customer service agents 1112 and 1114 are also standing by to handle other chat sessions generated by chat server 1108 .
  • requests made to the chat server are queued and the next available customer service agent is assigned to the first chat session request found in the queue.
  • Customer service agent 1110 is connected to a counter offer server that is connected to application database 1103 .
  • a counter offer server that is connected to application database 1103 .
  • information about the applicant can be obtained from the application database.
  • Connections from the customer service agent to the counter offer server and from the counter offer server to the application database may be made over the Internet or may be a dedicated secure connection.
  • a separate web server 1102 and counter offer server 1120 are shown. This divides the processing demand generated by normal communication with a browser from the processing demand generated by interaction initiated by chat with a customer service agent. This architecture is particularly useful since the two types of traffic are isolated.
  • the functions of the web server and the counter offer server are performed by a single application server.
  • Dashed box 1122 represents a single application server that may include both the web server and the counter offer server.
  • the term application server is used to describe either the web server and counter offer server operating collectively or to describe a single server performing both the function of the web server and the counter offer server.
  • counter offer server 1120 may be referred to as a customer service agent server or some other term describing its primary function.
  • the important point is that both the web server and the counter offer server both access the application data base to obtain information about the status of the application.
  • both the web server and the counter offer server may write data to the application database in some embodiments.
  • the common access to the application database enables the customer service agent to obtain information about the status of the application using the applicant identifier received through the chat server and also allows the customer service agent to alter the status of the application based on information received from the applicant through the chat server by sending that information to the counter offer server for posting to the application database.
  • an applicant provides information to database 1103 via the Internet using web pages in a standard manner.
  • the applicant may communicate via chat with a customer service agent who also is connected to the application database and may change the state of the application according to information received by the applicant via chat.
  • the customer service agent interacts with a special purpose counter offer server that uses the information provided by the applicant to determine a counter offer using information in the application database.
  • the counter offer is stored in the application database and provided to the applicant's browser via the web server.
  • the counter offer server and the web server may be implemented on a single machine referred to as the application server.
  • FIG. 16 is a flowchart illustrating a general process implemented on the chat server.
  • the process starts at 1200 .
  • the applicant identifier is obtained from a browser.
  • the chat server validates the applicant information by communicating with the application database.
  • the chat server may communicate directly with the application database.
  • the chat server communicates with the application database through an application server.
  • a response is received from the applicant via chat. Based on the response, the applicant account is configured in a step 1208 and the process ends at 1210 .
  • FIG. 17 is a flow chart illustrating a general process implemented on the web server for sending dynamic web pages to the applicant.
  • the dynamic web pages differ from a standard web page used to interact with the applicant because they contain a page object used to initiate a chat section with a chat server upon the occurrence of certain events.
  • the page object includes an applicant identifier that is passed to the chat server.
  • the process starts at 1300 when chat is initiated based on a user action.
  • the user action may be the activation of a help or chat button or the user canceling out of the application. Chat may also be activated by user inaction when a response is not received or by an improper action taken by a user resulting in an invalid response.
  • the state of the application is determined.
  • a step 1304 the content of the page to be sent to applicant is determined based on the state of the application.
  • the applicant identifier is inserted into a page object.
  • the page is sent to the applicant browser and the process ends at 1310 .
  • FIG. 18 is a flow chart illustrating a process implemented on a browser for establishing a connection to a chat server.
  • the process starts at 1400 .
  • a link to the chat server is activated either directly by the user or as a result of the occurrence of an event as described above.
  • a connection is established to the chat server. Typically the connection uses a protocol such as HTTPS.
  • the applicant identification is sent to the chat server and the process ends at 1408 .
  • FIG. 19 is a flowchart illustrating a typical process implemented on the browser for the purpose of initializing chat when the user does not respond to a downloaded web page in a certain period of time.
  • the process starts at 1500 .
  • a timer is initialized. Control is then transferred to 1504 where periodic checks are made to determine whether the timer has expired. If a valid user input is received, control is transferred to a step 1506 and the timer is reset. If the timer expires, then control is transferred to a step 1508 and a chat session is initiated as described above. The process then ends at 1510 .
  • FIG. 20 is a flow chart illustrating a process implemented on a chat server when a chat session is requested by a browser as described above.
  • the process starts at 1600 when the request is received.
  • the request for a chat session includes both a connection request and the applicant identifier.
  • the request is put into a queue and the applicant identifier is stored in a manner that associates it with the request.
  • the chat server uses the applicant identifier while the request is still in the queue to obtain the application information from the application database.
  • the applicant identifier is not used to access the application database until the request is assigned to a customer service agent. This insures that when the customer service agent accesses the information about the application, the information is up to date.
  • a status message is sent to the user and the system then waits for an available customer service agent. So long as no customer service agent is available, the system continues to wait at 1604 .
  • control is transferred to a step 1606 and the application information is sent to the customer service agent. The customer service agent then uses the application information to discuss the state of the application with the applicant.
  • FIG. 21A is a flow chart illustrating a process implemented at a customer service agent for the purpose of supporting the chat session.
  • the process may be implemented on a client machine accessed by the customer service agent or may be implemented on the application server which may include a dedicated counter-offer server.
  • the process starts at 1700 .
  • the customer service agent notifies the chat server that it is available.
  • the applicant identifier is received from the chat server.
  • the applicant record in the application database is accessed using the applicant identifier as mentioned above.
  • the application record may be accessed either directly or via the application server.
  • the chat server displays the application data retrieved using the applicant identifier to the customer service agent.
  • the application data is displayed by displaying the same web page that the applicant is viewing.
  • the web page may be augmented with other information about the status of the application.
  • a completely separate application information screen may be displayed to the customer service agent.
  • a display is provided showing various offer terms that the applicant may indicate are not acceptable in the chat between the applicant and the customer service agent.
  • the customer service agent may check one or more of the terms and the terms checked by the customer service agent are sent to the counter offer server to be used in generating a counter offer.
  • the terms or attributes of the offer that the applicant considers to be unacceptable are obtained in a step 1712 and the initial process for receiving applicant information and providing information to the counter offer server ends at 1714 .
  • a number of different methods of obtaining the unacceptable terms from the applicant may be used.
  • a set of offer terms are shown to the customers service agent and the customer service agent selects terms identified by the applicant in chat that are unacceptable.
  • a display of terms is provided to the applicant and the applicant picks the unacceptable terms with the aid of the customer service agent.
  • the chat generated by the applicant is automatically analyzed by a program which generates the list of unacceptable terms for the counter offer server.
  • FIG. 21B is a screen shot illustrating a display of offer terms used in one embodiment for determining which terms are unacceptable.
  • the display includes indications that interest rate attributes are not acceptable, indicating that the annual percentage rate or long term interest rate is too high, a longer introductory interest rate is desired, or an introductory interest rate is desired.
  • the introductory interest rate is a very low rate offered for a short period of time when the account is established, also referred to as a teaser rate.
  • buttons are provided for the customer service agent to check whether the credit limit is too low either for purchases or for balance transfers.
  • the customer service agent can fill in a balance transfer amount that the applicant wants to transfer as well as a requested credit limit.
  • a box is provided for the customer service agent to check and send the data to the counter offer server.
  • FIG. 22 is a flow chart illustrating in detail a process implemented in step 1712 for obtaining the unacceptable terms of an offer from an applicant.
  • the process starts at step 1800 .
  • a chat message is received from a user indicating a term that the user would like to change.
  • the message is displayed to the customer service agent along with a checklist as shown in FIG. 21B illustrating terms to change. As noted above, the checklist may also be displayed and checked by the applicant.
  • an input is received from the customer service agent of a selected term that the applicant would like to change of an offer.
  • the term is sent to the counter offer server and the process ends at 1810 .
  • FIG. 23 is a flow chart illustrating the process implemented on the counter offer server when more than one term is selected as being unacceptable to the applicant.
  • a counter offer is selected based on only one unacceptable term being changed. This simplifies the process of determining a counter offer since changing two terms is somewhat more complex. Therefore, a hierarchy of terms that may be changed by the applicant is provided and the highest priority term selected is used to determine the counter offer. All of the unacceptable terms are still transmitted to the counter offer server and recorded for the purpose of data gathering and analysis of the system.
  • the process starts at 1900 .
  • a step 1902 multiple unacceptable terms or attributes of the offer are received by the counter offer server.
  • the highest priority term or attribute that is unacceptable is determined.
  • the offer is adjusted and a counter offer is determined based on the highest priority term.
  • the process ends at 1908 .
  • the counter offer server may use many different methods to generate a counter offer based on attributes or terms identified by the applicant as being unacceptable.
  • a number of potential offers are identified based on the applicant information provided and an assessment of the risk associated with extending credit to the applicant. Some of the generated offers are withheld while others are displayed to the applicant.
  • a number of schemes may be used to decide which offers are displayed and which offers are withheld. Some methods may include a statistical selection or a selection according to a marketing scheme designed to increase the rate of acceptance. It may also be the case that the best offer is withheld and kept in reserve to use as a counter offer. In general, certain potential offers are withheld.
  • the identification by the applicant of an unacceptable term is used by the counter offer server to identify a better offer for the counter offer.
  • offer strategies are identified and the counter offer is identified by simply looking up an offer strategy associated with the applicant and the identified unacceptable term.
  • an offer strategy may include a set of offers shown to the applicant as well as offers that are not displayed and that correspond to various unacceptable terms. When an unacceptable term is identified, the offer corresponding to the strategy and the unacceptable term is used as the counter offer.
  • the counter offer strategy is dependent on characteristics of the applicant. For example, the applicant may be classified as a “surfer” or “non-surfer”. A “surfer” is a person who shifts or surfs balances among credit cards, taking advantage of low teaser rates. A determination that an applicant is a surfer is made based on an analysis of the applicant's credit report. A counter offer strategy designed for such an applicant may adopt the strategy of extending the period of an introductory rate if requested by the applicant, but requiring the applicant to make a certain number of purchases or not transfer the balance for a certain period of time.
  • added terms and conditions such as purchase requirements or a length of time that a balance may not be transferred from the card may be added to counter offers for the purpose of creating a perceived barrier to receive the counter offer. Such a barrier or condition prevents the applicant from deciding that the first offer should always be rejected.
  • the conditions are determined based on characteristics of the applicant. As described above, surfers may receive balance transfer time restrictions.
  • the counter offer server may also recalculate a customized offer based on the identification of an unacceptable term and an actual requested term by the applicant. For example, the applicant may express that the credit limit is too low, either for a desired balance transfer that the applicant wants to make or new purchases. The amount of the credit limit minus the amount of the balance transfer is referred to as the amount of credit that is “open to buy”.
  • the information sent to the counter offer server may include a requested credit limit and a requested balance transfer amount. From that information, the counter offer server can determine that the offer credit limit is too low either for the balance transfer requested or for the amount that the applicant wants open to buy. To minimize risk, it is desirable that the credit limit be as low as possible. Therefore, it is desirable not to simply select a withheld offer with a higher credit limit, but instead to customize an offer that conforms to the applicant's request but does not exceed the applicant's request.
  • a new credit limit may be calculated that incorporates the requested balance transfer and the amount that the applicant wants open to buy.
  • the calculated new offer is of course checked versus the risk profile of the user and it is verified that the higher credit limit is appropriate for the user. Any of the various techniques well known in the art of assigning credit may be used to assess the risk of the applicant and determine an appropriate upper credit limit.
  • the counteroffer in the case of a requested higher credit limit is specifically customized for the applicant based on what the applicant requests. In general, any counter offer provided is based on the applicant's identification of an unacceptable term.
  • the offer strategy may include an offer with the best annual percentage rate available in the set of offers initially displayed to the applicant. In such a case, if the applicant identifies the annual percentage rate as the unacceptable term, then no counter offer improving that term can be generated.
  • FIG. 24 is a flow chart illustrating an example process for generating a counter offer.
  • the process starts at 11000 .
  • the counter offer server receives the term that is to be changed.
  • the counter offer determination process then ends at 11040 . If the term is the credit limit, then control is transferred to a step 11050 and it is determined whether the credit limit is too low for a requested balance transfer or for new purchases (open to buy). If the credit limit is too low for new purchases, then control is transferred to a step 11060 and the required balance transfer and credit limit are adjusted if that is allowed by the scheme being used to assign credit based on an assessment of the applicant's risk.
  • control is transferred to a step 11070 and the credit limit is adjusted based on the balance transfer requested if allowed by the credit line assignment being used.
  • the counter offer is defined and the counter offer determination process ends at 11080 . Whether a precomputed offer is determined for display in 11030 or the credit limit is recomputed in step 11060 or 11070 , if no better offer can be generated, then a message noting that no better offer can be generated is sent either to the chat server or to the applicant directly.
  • a new offer page is generated in the application server based on data written to the application database by the application server.
  • the counter offer server writes data to the application database and the web server generates a counter offer page based on the data written to the application database.
  • the application server also provides information to the chat server indicating what counter offer, if any, has been generated. The customer service agent then discusses the counter offer with the applicant via the chat interface.
  • the applicant In order to view the counter offer page generated by the web server, the applicant is asked to refresh his browser. Refreshing the browser causes the offer page to be requested from the web server and the web server responds with the counter offer page.
  • a button labeled “view offer” is provided on the displayed page. When the button is selected, the page is downloaded again and any changes are then viewed by the user.
  • the chat server enables the display of the page through the applicant's browser automatically, without requiring the applicant to refresh the screen. This can be accomplished in a variety of ways.
  • the chat server writes a variable to a memory location that the browser checks periodically. When the browser checks the location and finds a variable indicating that the counter offer page should be downloaded, the browser automatically refreshes itself.
  • the applet that enables the browser to check the location and refresh itself may be used in some cases but not others. When such an applet is not used, the process of instructing the applicant through the chat interface to refresh his own browser or to select a button to view the offer may be implemented.
  • FIG. 25 is a flowchart illustrating a process implemented on a counter offer server to generate and confirm a new offer for display to the applicant.
  • the process starts at 11100 .
  • the counter offer server receives a chat generated term to change.
  • the term can be identified based on chat by a customer service agent or the term can be automatically determined by analysis of the chat provided by the applicant or the term can be identified using a pick list provided to the applicant.
  • a new offer is selected from an offer set included in the offer strategy being used for the applicant. As described above, in some embodiments, a new offer is actually calculated based on information provided by the applicant such as a requested credit limit.
  • the new offer is displayed to the customer service agent.
  • the customer service agent then communicates with the applicant about the new offer to determine the applicant's interest.
  • the customer service agent then confirms to the counter offer server that the new offer is to be shown to the applicant.
  • the confirmation is received in step 11140 and in a step 11150 , the counter offer server confirms the new offer in the data base so that it is ready to be displayed when the applicant's browser refreshes.
  • the process ends at 11160 .
  • the new offer is confirmed in the database concurrent with it being displayed to the customer service agent. Then, whenever the applicant's browser refreshes, the counter offer will be displayed. In some embodiments, it is desired that the display of the counter offer not be enabled until customer service agent has an opportunity to chat with the applicant about the new offer and confirm that display is appropriate.
  • FIG. 26 is a flowchart illustrating a process implemented on the web server portion of the application server for the purpose of displaying a new counter offer to the applicant.
  • the process starts at 11200 .
  • the web server receives a refresh request from the applicant's browser.
  • the counter offer parameters are retrieved from the application data base and a web page including the counter offer is generated.
  • the counter offer page is sent to the browser.
  • the process ends at 11240 .
  • FIG. 27 is a flow chart illustrating a process used in one embodiment to automatically generate a refresh on the applicant's browser.
  • the process starts at 11300 .
  • a request is received for a different offer from the customer service agent.
  • the new offer is determined in a step 11320 .
  • the terms of the new offer are communicated to the customer service agent in step 11330 .
  • the customer service agent describes the offer to the user.
  • the customer service agent receives an indication that the user wants to view the new offer.
  • the customer service agent then sends a message to the user in step 11360 that causes a refresh to be activated.
  • the message may include writing a certain value to a defined memory location that is periodically examined by the browser for the purpose of determining whether a refresh has been requested by the customer service agent. Once one refresh is generated in this manner, the value that the browser looks for may be incremented so that each time it finds the same value, a new refresh is not generated. The process ends at 11370 .
  • a system and method for activating a chat interface with a customer service agent that has access to information about an application for credit has been described.
  • the chat interface is used to obtain information about why an applicant is rejecting an offer of credit and to identify unacceptable terms. Those unacceptable terms are communicated to a counter offer server and the counter offer server generates a new offer that improves the unacceptable term.
  • the new offer is communicated to the applicant using the chat interface and a web page showing the new offer with an opportunity to accept the offer is displayed to the applicant when the applicant's browser is refreshed.

Abstract

A system and method are described for providing real time approval of credit over a network. The method includes obtaining applicant data from an applicant. The applicant data is analyzed into a form suitable for directly obtaining a credit report from a credit bureau for the applicant. A credit report having credit report data is obtained from a credit bureau for the applicant. It is then determined whether to accept the applicant using the credit report data and it is communicated to the applicant that the applicant has been approved.

Description

    CROSS REFERENCE TO RELATED APPLICATIONS
  • This application is a continuation of U.S. patent application Ser. No. 10/782,311,” filed Feb. 18, 2004, which is a continuation of U.S. patent application Ser. No. 09/595,556, filed Jun. 15, 2000, now U.S. Pat. No. 6,718,313, which is a continuation-in-part of U.S. patent application Ser. No. 09/185,201, filed Nov. 3, 1998, now U.S. Pat. No. 6,405,181, and of U.S. patent application Ser. No. 09/858,878, now U.S. Pat. No. 6,567,791, all of which are herein incorporated by reference.
  • TECHNICAL FIELD OF THE INVENTION
  • The present invention relates generally to electronic commerce. More specifically, the invention relates to methods and apparatuses for providing real time credit approval to an applicant online by obtaining data from an applicant, verifying and formatting the data so obtained in a manner that permits accessing the applicant's credit report, and making an underwriting decision to grant or deny credit to the applicant in real time based on data from one or more credit bureau reports.
  • BACKGROUND
  • With the advent of electronic commerce on the Internet, applicants have begun to expect decisions that have historically required a period of days or weeks to be made instantly when processed on line. Numerous transactions such as purchases of consumer goods, airline tickets, and movie tickets have been adapted for execution on line in a matter of seconds. What has not been perfected is the ability to make a credit decision and grant credit to a party on line in real time. (For the purpose of this specification, “instant” or “real time” credit means within a short period of time within less than about five minutes.) As a result, virtually all Internet commerce to date requires some previously secured method of payment such as a credit card obtained by conventional means or other previously ananged payment source such as a bank account or electronic money.
  • One factor that has prevented Internet applicants from providing information and receiving instant approval for credit is the difficulty of interfacing with the various credit bureau databases (Equifax, Trans Union, and Experian). Personal information must be entered by a party authorized by the credit bureaus to communicate with the credit bureaus for the purpose of accessing credit bureau reports. Such information must be in exactly the correct form in order for an individual's credit report to be retrieved. Another difficulty has been that the decision to grant credit carries with it significant risk and systems have not been successfully designed that can make a sufficiently reliable underwriting decision using data provided directly by an applicant. Many credit card issuers provide applications on line that may be filled out by applicants. However, data from those applications must be entered manually into the credit card issuer's system for processing before a credit report is obtained and an underwriting decision can be made. Other applicants may be preapproved by an existing card issuer's system before an offer is made and accepted online. However, the underwriting process has not been sufficiently automated to allow a credit decision to be made in real time for an applicant who has entered personal data into an application system.
  • What is needed is a system and method for obtaining personal data from a credit applicant, parsing the data into a format that is compatible with that used by the credit bureaus, obtaining credit bureau information and making an underwriting decision in real time. Such a system would be useful for conveniently obtaining a credit card on line. Automation of a process for obtaining a credit report and making
  • an underwriting decision without human intervention would be beneficial because credit approval decisions could be made faster and more cheaply. The true power of such a system would be realized when the system is accessed in the midst of a transaction to obtain credit specifically for the purpose of that transaction.
  • SUMMARY
  • The present invention provides a system and method for obtaining information from an applicant, accessing credit bureau information and making a real time underwriting decision to accept or reject the applicant. A parsing engine parses the information provided by the applicant so that it may be sent directly to a credit bureau. Information obtained from one or more credit bureaus is used by an underwriter engine to make a decision whether to grant credit to the applicant. It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer readable medium. Several inventive embodiments of the present invention are described below. In one embodiment, a method of providing real time approval of credit over a network is disclosed. The method includes obtaining applicant data from an applicant. The applicant data is analyzed into a form suitable for directly obtaining a credit report from a credit bureau for the applicant. A credit report having credit report data is obtained from a credit bureau for the applicant. It is then determined whether to accept the applicant using the credit report data and it is communicated to the applicant that the applicant has been approved. These and other features and advantages of the present invention will be presented in more detail in the following specification of the invention and the accompanying figures which illustrate by way of example the principles of the invention.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:
  • FIG. 1 is a block diagram illustrating a preferred architecture for a system that provides instant on-line credit card approval.
  • FIG. 2 is a block diagram illustrating an application data structure that is used in one embodiment to store the data contained in an application and to keep track of the status of the application as it progresses through the various modules described in FIG. 1.
  • FIG. 3 is a flow chart illustrating the general process flow through the modules of FIG. 1.
  • FIG. 4A is a flow chart illustrating a validation process that is used in step according to one embodiment of the invention.
  • FIG. 4B is a flow chart illustrating a process for parsing an address entered by an applicant.
  • FIG. 5 is a flow chart illustrating a pre-credit bureau test performed in one embodiment of the invention.
  • FIG. 6A is a flow chart illustrating a process for making an underwriting decision using multiple credit reports.
  • FIG. 6B is a flow chart illustrating a process implemented on the Underwriter for using credit bureau data to accept or reject an applicant in one embodiment.
  • FIG. 6C is a flow chart illustrating a process for using the FICO score combined with other attributes to accept or reject an applicant.
  • FIG. 7 is a flow chart illustrating a process for checking the status of an application and executing either an offer process or one of several rejection processes.
  • FIG. 8A is a flow chart illustrating a process for determining an appropriate reason to display for rejecting an applicant and displaying that reason.
  • FIG. 8B is a diagram illustrating one data structure used to map main FICO factors provided by the credit bureau (referred to as external codes) to internal decline codes as well as reasons for rejection to be provided to rejected applicants.
  • FIG. 9 is a flow chart illustrating how a rejection reason may be obtained.
  • FIG. 10A is a flowchart illustrating a process for providing a set of multiple offers to an applicant and receiving a balance transfer amount corresponding to an offer selected by the applicant.
  • FIG. 10B is a flow chart illustrating one such method of deriving a credit limit for an applicant based on the applicant's FICO score and income, as well as the amount of total revolving balance that the applicant elects to transfer.
  • FIG. 11 is another data representation illustrating another embodiment of how the offers may be determined based on FICO score, income range, income, and total revolving balance transfer.
  • FIG. 12 is a diagram illustrating a display provided to the applicant for the purpose of presenting multiple offers to the applicant.
  • FIG. 13 is a flow chart illustrating a process for obtaining a real-time balance transfer from an applicant.
  • FIG. 14 is a block diagram illustrating one computer network scheme that may be used to implement the system described herein.
  • FIG. 15 is a block diagram illustrating a system for providing real time chat help to an applicant and generating a counter offer when appropriate.
  • FIG. 16 is a flowchart illustrating a general process implemented on the chat server.
  • FIG. 17 is a flow chart illustrating a general process implemented on the web server for sending dynamic web pages to the applicant.
  • FIG. 18 is a flow chart illustrating a process implemented on a browser for establishing a connection to a chat server.
  • FIG. 19 is a flowchart illustrating a typical process implemented on the browser for the purpose of initializing chat when the user does not respond to a downloaded web page in a certain period of time.
  • FIG. 20 is a flow chart illustrating a process implemented on a chat server when a chat session is requested by a browser as described above.
  • FIG. 21A is a flow chart illustrating a process implemented at a customer service agent for the purpose of supporting the chat session.
  • FIG. 21B is a screen shot illustrating a display of offer terms used in one embodiment for determining which terms are unacceptable.
  • FIG. 22 is a flow chart illustrating in detail a process implemented in step 712 for obtaining the unacceptable terms of an offer from an applicant.
  • FIG. 23 is a flow chart illustrating the process implemented on the counter offer server when more than one term is selected as being unacceptable to the applicant.
  • FIG. 24 is a flow chart illustrating an example process for generating a counter offer.
  • FIG. 25 is a flowchart illustrating a process implemented on a counter offer server to generate and confirm a new offer for display to the applicant.
  • FIG. 26 is a flowchart illustrating a process implemented on the web server portion of the application server for the purpose of displaying a new counter offer to the applicant.
  • FIG. 27 is a flow chart illustrating a process used in one embodiment to automatically generate a refresh on the applicant's browser.
  • DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
  • Reference will now be made in detail to the preferred embodiment of the invention. An example of the preferred embodiment is illustrated in the accompanying drawings. While the invention will be described in conjunction with that preferred embodiment, it will be understood that it is not intended to limit the invention to one preferred embodiment. On the contrary, it is intended to cover alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. The present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.
  • FIG. 1 is a block diagram illustrating a preferred architecture 102 for a system that provides instant on-line credit card approval. As shown, an application engine 104 creates an application by prompting an applicant for data and storing the entered data. In one embodiment, the application engine creates an application by communicating with the applicant over the World Wide Web using Java, html or other commonly used Internet protocols. In other embodiments, other types of connections may be established between the applicant and the application engine. The application includes applicant data such as the applicant's address and social security number. Once created, the application is received by the parsing engine 106 which parses an applicant's name and address and creates appropriate software objects.
  • The parsing engine 106 parses the data into an exact format that may be used to directly access credit bureau data. The applicant is given an opportunity to view how the data submitted has been parsed and to make corrections to parsed data, if necessary. The parsing engine 106 is described in further detail in FIG. 4B. The parsed data is passed to a Validator 108. Validator 108 validates certain data entered by the applicant such as the social security number and zip code. Validation may include checking either the form of a number to ensure that the correct number of digits have been entered or checking content such as checking that the area code portion of a phone number is a valid area code or checking that a zip code matches a city. If the data is determined to be valid, then the validated data is input to an Underwriter 110. It is important to avoid sending invalid data to the Underwriter to avoid the cost of requesting credit reports that cannot be used.
  • Underwriter 110 receives data from the parsing engine and evaluates the data to determine if the applicant should receive an offer for credit. In one embodiment, the Underwriter sends the parsed data to at least two credit bureaus, receives data from the credit bureaus, and makes an underwriting decision based on an analysis of the credit bureau data. The analysis may include, but is not limited to, comparing the applicant's Fair Isaac Risk Score (FICO score) to certain thresholds. Underwriter 110 is described in further detail in FIGS. 6A and 6B. If the Underwriter determines that an offer of credit should be extended to the applicant, then an offer is made in real time to the applicant. As is described below, the offer may include one or more sets of alternative terms and those terms may be conditioned on the applicant taking certain actions such as transferring balances. The applicant may be required to actually take such actions in real time before an offer conditioned on such actions is confirmed. If the Underwriter determines that no offer of credit should be extended, then the Underwriter determines a reason for rejecting the applicant.
  • Whether an offer is extended and accepted or not, information about the offer or the rejection is passed to a creditor module 112 that finalizes the offer and builds a data file that is in the proper form to be sent to First Data Resources, Inc. (FDR), or another such entity that provides a similar service to FDR's service. During the finalization of the offer, FDR data is built for all approved and declined applications. FDR handles the embossing of the card and delivering it to approved applicants. FDR also handles sending rejection letters to rejected applicants.
  • If, at any time during the process, a system error occurs that interrupts the process, then an application object loader 114 loads the appropriate application for reentry into the system. It should be noted that in one embodiment, the data that is processed and stored by each module is stored as an application object as is described further in FIG. 2. In other embodiments, the data is stored in other ways, such as in a table or in a database.
  • FIG. 2 is a block diagram illustrating an application data structure 202 that is used in one embodiment to store the data contained in an application and to keep track of the status of the application as it progresses through the various modules described in FIG. 1. It should be noted that other data structures may be used in other embodiments within the scope of this invention. Application data structure 202 includes an application object 204 that is created by the application engine. Application object 204 points to a number of associated data structures, including an applicant object 206. Applicant object 206 stores applicant data and includes one or more data elements 208. For example, an applicant data element 208 may include information such as the applicant's address, phone number, or social security number. The application data structure also includes one or more test result objects 210. Each test result object 210 stores a validation status 212 associated with a validation test applied to the data associated with applicant object 206. For example, a test result object may include a social security number status indicating whether the social security number entered by the applicant is a valid social security number. Also, a test result object 210 may include a zip code status indicating whether the zip code entered by the applicant matches the rest of the address entered by the applicant. Test result objects are used to check whether data entered by the applicant is valid before certain actions are taken, such as a credit report being ordered.
  • The application data structure further includes a set of credit report objects 214 associated with each credit report ordered. In one embodiment, the Underwriter requires at least two credit reports from two of three credit bureaus before a decision to grant credit is made. This rule effectively enables a real time credit decision to be made without incurring an unacceptable amount of risk. Since credit reports are preferably ordered from more than one credit bureau, the application data structure will likely include several credit report objects. Each credit report object 214 includes a plurality of attributes 216. An attribute is an item of data provided by the credit bureau in the credit report. For example, one such attribute is a 90 day attribute that indicates the number of times that the applicant has been more than 90 days late in payment of a debt. Similarly, a 60 day attribute may be provided. Other attributes may include a FICO score, the number of times the applicant has been severely delinquent, existence of a derogatory public record, whether the applicant is now delinquent, the applicant's total revolving balance, and the amount of time that a credit report has been on file for the applicant (also referred to as “thickness of file” or “time on file.”
  • As is described below, in one embodiment, the Underwriter bases its decision on the FICO score alone when the FICO score is below a rejection threshold. In some embodiments, there may be automatic approval when the FICO score is above an approval threshold.
  • The application data structure further includes FDR data object 218 associated with the application. FDR data is created by the creditor module for the purpose of sending application information to FDR so that FDR may send credit cards to successful applicants and send rejections to unsuccessful applicants, when that is required.
  • The application object also includes a status object 220. The status of the application object is determined at various times by the modules. For example, the Validator module may determine that the application is invalid based on an invalid social security number or zip code. The Underwriter module may also determine that the application is a duplicate, as will be described below. The Underwriter may also change the status of an application to accepted or declined. In addition, certain applications may be tagged with a fraud status flag indicating that there is a likelihood of fraud. The application data structure also may include a set of offers 222 to be provided to the applicant.
  • Thus far, the software architecture and data structure used to make a real time credit decision in one embodiment have been described. Next, the processes implemented in the modules will be described.
  • FIG. 3 is a flow chart illustrating the general process flow through the modules of FIG. 1. The process starts at 300. In a step 304, applicant data is obtained via html, Java or other suitable network protocol. It should be noted that in different embodiments, the information entered by the applicant may be either parsed first by the parsing engine or validated first by the Validator. For the purpose of illustrating this point, FIG. 3 shows Validation occurring first in a step 306. FIG. 1 alternatively shows the parsing engine operating first. If the information is not valid, then control is transferred from a step 308 to a step 309 and the applicant is given an opportunity to edit the data. The Validator then rechecks the edited data.
  • If the information is valid, then control is transferred to a step 310 where the data entered is displayed along with the field assigned to each part of the data by the parsing engine. This step is important to ensure that the data will be readable when it is sent to a credit bureau by the Underwriter. An exact match is required by the credit bureaus for the correct credit report to be sent. Various ambiguities in the way that an address may be expressed can cause difficulties. Such difficulties have been a significant factor in preventing other systems from allowing individuals to directly access credit bureau data. For example, it is necessary to distinguish a street direction that is part of a street address from a street name that happens to be a direction, such as “North.”
  • To make certain that such distinctions as well as other distinctions are made correctly, the parsing engine categorizes each part of the entered address and presents the field names along with that portion of the address that it has assigned to each field name. So, for example, the applicant can move “North” from a street direction field to a street name field if that is appropriate. Thus, by parsing the address and assigning the different parts to fields and then allowing the applicant to check and edit the assignment, the parsing engine enables applicants with no knowledge of the Byzantine structure required by the credit bureaus to enter personal data in a manner that allows a credit report to be obtained without human intervention. Initial parsing is achieved by analyzing the form of the address and dividing, for example, the street number, street name, city and state. However, regardless of the care taken in designing initial parsing, some miscategorization will likely occur. Displaying the parsing to the applicant and allowing the applicant to correct parsing errors enables the imperfect output of the parsing engine to be corrected. At the same time, the process is much more user friendly and less tedious for the user than if the user had been asked to enter each field that the address is divided into by the parsing engine separately. By having the parsing engine parse the address and present the result of the parsing to the user, tedium is minimized and accuracy is achieved.
  • If the applicant responds that the data and parsing is correct instead of editing the parsing of the data into the displayed fields in step 310, then a step 311 transfers control to a step 312 where pre-credit bureau tests are run on the data. If the applicant edits the data, then control is transferred back to step 306 and the data is re-checked for validity. If the applicant fails the pre-credit bureau test, then the applicant's status is changed to rejected in a step 313 and if the applicant passes the pre-credit bureau test, then the credit bureaus are accessed and credit bureau tests based on the data obtained from the credit bureau and other applicant data are performed in a step 314. If the applicant passes the credit bureau tests, then post credit bureau tests are run in a step 316. If the applicant passes the post credit bureau tests, then the applicant is accepted to receive an offer for credit and the approval process ends at 320.
  • If the applicant fails the credit bureau tests, then the application status is changed to rejected in a step 315. As described below, an on line rejection process is executed for applications with a rejected status. Thus, the applicant information is input to a series of tests and the result of the tests determines whether the applicant is accepted or rejected.
  • FIG. 4A is a flow chart illustrating a validation process that is used in step 306 according to one embodiment of the invention. The Validator performs a plurality of validation tests on the applicant data. The process starts at 400. In a step 402, the applicant's address is validated according to an address validation test. In one embodiment, address validation includes checking that a street number and street name are entered and not a P0 box. Next, in a step 404, a validation status associated with the address validation test is stored in a test result object. In a step 406, the applicant's phone number is validated according to a phone number validation test. The phone number validation test may include checking the number versus one or more tables or checking that an appropriate number of digits are provided. In a step 408, a validation status associated with the phone number validation test is stored in a test result object. Finally, in a step 410, the applicant's social security number is validated according to a social security number validation test. In a step 412, a validation status associated with the social security number validation test is stored in a test result object and the process ends at 420.
  • In this manner, the form of the data entered by the applicant is checked to determine whether the data entered is at least potentially correct. For example, if a social security number that does not exist for anyone is entered, it can be determined that the entered data must be invalid. In other embodiments, additional validation tests may be performed. Specifically, validation tests that help detect fraud may be implemented. In one embodiment, the validation status associated with each test result object includes a time stamp. Multiple applications with the same or similar names may be tracked and a history may be saved. Fraud tests may be implemented that track the number of applications submitted by a given individual and check the consistency of applicant data between multiple submitted applications.
  • FIG. 4B is a flow chart illustrating a process for parsing an address entered by an applicant. The process starts at 450. In a step 452, the address is split into fields using a parser. Next, In a step 454, the parsing result is displayed. The applicant is prompted to indicate whether or not the parsing result is correct in a step 456. If the result is not correct, then control is transferred to a step 458 and the applicant is allowed to change the fields assigned to each part of the data. Once the parsing is approved by the applicant, control is transferred to a step 460 and the parsed data is sent to the Underwriter. It should be noted that the data may also be sent through the Validator again if the data was changed by the user. The process ends at 462.
  • FIG. 5 is a flow chart illustrating a pre-credit bureau test performed in step 312 in one embodiment of the invention. Pre-credit bureau tests are performed prior to obtaining one or more credit reports for the applicant for the purpose of avoiding the expense of obtaining a credit report for certain applicants who would not be approved regardless of the content of the credit report. For an example, an applicant could be rejected based the applicant being of a minor age. In one embodiment, the pre-credit bureau test is performed by the Underwriter. In other embodiments, the pre-credit bureau test may be performed by the parsing engine or a separate module. The process starts at 500. In a step 502, the applicant's income is obtained. Next, at step 504, it is determined if the applicant's income exceeds an annual income criteria. If the applicant does not meet the annual income criteria, the status of the application may be set to declined in a step 506. By way of example, if the income entered by the applicant is less than $15,000, the status of the application maybe set to declined. In a step 508, the applicant's age is obtained. In a step 510, the applicant is verified to meet a minimum age criteria. For example, the minimum age may be 18. If the applicant fails to meet the minimum age criteria, the application status may similarly be set to declined in a step 512. It should be noted that the above description recites that age and income are checked in separate steps. Alternatively, they may be checked together.
  • If the applicant meets the minimum age and income requirements, then control is transferred to a step 514. Step 514 checks whether the application entered is a duplicate application. If the applicant has previously entered the information in the application database, then the current application is a duplicate application. It is important to recognize such duplicate applications so that a single applicant cannot require multiple credit reports to be obtained. In one embodiment, duplicate applications are recognized by checking for duplicate social security numbers, duplicate names and/or duplicate addresses. In order to be rejected by the system, an application must match two of the three criteria. A rule is established that an applicant may reapply for a credit card after a specified time period has elapsed (e.g., 60 days). Such a rule is implemented in a step 516 that checks whether the application submission date exceeds a specified time period since the submission date of the found duplicate application. If the application is submitted prior to the specified time period, the status of the application is changed to duplicate in a step 518 and the process ends at 520.
  • When a duplicate application is submitted, then the applicant is notified and a message is provided that informs the applicants that duplicate applications may not be submitted within a certain time period of each other. In addition, the applicant may also be prompted to go to a re-entry screen that allows the found duplicate application to be processed if processing of that application was previously interrupted. In this manner, if an applicant quit in the middle of the application process, then the application process can be completed for the previously submitted application.
  • It should be noted that a specific series of pre-credit bureau tests have been shown for the purpose of illustration. Other tests can be used within the scope of this invention. Also, it should be noted that if one test is failed, then remaining tests are skipped in some embodiments. Alternatively, all of the pre-credit bureau tests may be performed and the pre-credit bureau test results may be stored in separate question objects. This may help detect potentially fraudulent applicants who create many duplicates. If an application is determined potentially to be fraudulent, the status of the application is changed to fraud. Alternatively a separate flag may be set to indicate the potential fraud.
  • Once it is determined the applicant has entered data that is at least potentially valid and the applicant has approved the output of the parsing engine, the application is ready to be checked by the Underwriter to determine whether credit should be approved for the applicant. The Underwriter makes such a determination based on the information obtained from credit bureaus. Since the decision made by the Underwriter is made without human intervention, it is particularly important that the method of determination made by the Underwriter is reliable. For this reason, it is preferred that, in order for an applicant to be approved, at least two credit bureaus must provide information about that applicant that passes a series of tests. In some embodiments, this rule may be relaxed, but a process that requires data from at least two credit bureaus for approval has been shown to have superior reliability to processes without such a requirement. In particular, it has been determined that requiring data from at least two credit bureaus for approval is an important factor in enabling the real time credit approval system to make sufficiently reliable determinations.
  • Because at least two credit reports from two different credit bureaus are required, it is possible that certain applicants may be rejected because they are only included in the records of a single credit bureau. When this occurs, that reason for rejection is given to the applicant instead of a reason based on the failure of the applicant to pass a test based on credit bureau data.
  • FIG. 6A is a flow chart illustrating a process for making an underwriting decision using multiple credit reports. The process starts at 600. In a step 602, a first credit bureau test is performed. The process of performing a test on individual credit bureau data is further described in FIG. 6B. If that test is failed, then the application is rejected in a step 604 and the process ends at 606. Immediately rejecting the application after a first failure saves the cost of obtaining a second credit bureau report. If the first credit bureau test does not fail, either because no report is obtained or because the test is passed, then control is transferred to a step 608 and a second credit bureau test is performed. If that test is failed, then the application is rejected in step 604 and the process ends at 606. If the second credit bureau test does not fail, then it is determined in a step 612 whether two credit bureau tests have been passed. If two tests have been passed, then the application is accepted in a step 614 and an offer is determined as described below.
  • If two credit bureau tests have not been passed, then control is transferred to a step 616 where it is determined whether one credit bureau test has been passed. If one credit bureau test has not been passed, then the application is rejected in a step 618 for not having a record in at least two credit bureaus. The third credit bureau is not checked since it is not possible to get at least two credit reports at that point. If one credit bureau test has been passed, then a third credit bureau is consulted in a step 620. If the third credit bureau test is failed, then the application is rejected in a step 622 and the process ends at 606. If the third credit bureau report does not have a record for the applicant, then the application is rejected in step 618 for not having enough credit records and the process ends at 606. If the third credit bureau test is passed, then the application is accepted in a step 624 and the process ends at 606.
  • Thus, the Underwriter only accepts applications that pass at least two credit bureau tests. It should be noted that a special reason for rejection may be given to applicants who are rejected because they do not have a record in at least two credit bureaus. Also, it should be noted that in some embodiments, it is distinguished whether a credit report is not obtained because a credit bureau is temporarily unavailable or whether a credit report is not obtained because there is no record for the applicant. In the event that a credit bureau is unavailable, an applicant that cannot be found in the remaining two credit bureaus may be given a special rejection notice indicating that a later attempt should be made by the applicant when the unavailable credit bureau is functioning. Also, when two credit bureaus are unavailable at the same time, all applicants may be requested to reapply when the credit bureaus return on line.
  • FIG. 6B is a flow chart illustrating a process implemented on the Underwriter for using credit bureau data to accept or reject an applicant in one embodiment. The process starts at 650. In a step 652, a credit report is requested from the credit bureau. As described above, the credit report can be requested using data entered directly by the applicant because the parsing engine classifies the data into appropriate fields to be sent to the credit bureau. Once the report is received, the Underwriter performs tests on the data in the credit report. Data entered by the applicant may be used for Underwriter tests as well. In a step 656, a set of attribute tests are performed using the credit report. Attribute tests are general tests that may be applied to any credit report. Each attribute test corresponds to a general attribute provided in the credit report. Attribute tests may include threshold tests, which compare certain parameters such as a FICO score to a threshold, or logical tests, which check for the existence of certain adverse records. Next, in a step 658, a set of credit report specific tests are performed using the credit report. A set of credit report specific tests may be defined for each credit bureau. Each credit report specific test corresponds to data that is specific to a particular credit bureau.
  • The credit bureau tests may be separately performed to avoid performing the remaining tests once the failure of the application to pass a test results in a determination that the application will be declined. However, each of the set of attribute tests and credit report specific tests are preferably performed so that the best basis for rejection may be identified and provided to the applicant. Determining an appropriate basis of rejection to display to the applicant is described further below in connection with FIG. 7. It is determined in a step 660 whether the applicant passed the credit tests and the application is rejected in a step 662 if the applicant failed the tests. If the applicant passes the tests, that is noted in a step 664 for the purpose of determining whether the applicant should be accepted as described in FIG. 6A. The process then ends at 670.
  • As described above, the process of performing the various tests may generally be considered as performing various attribute tests and credit specific tests and combining the results of those tests in some fashion to make a decision to pass or fail an applicant.
  • FIG. 6C is a flow chart illustrating a process for using the FICO score combined with other attributes to accept or reject an applicant. The process starts at 680. In a step 682, the FICO score is checked. If the FICO score is below a rejection threshold, then the application is rejected in a step 684. If the FICO score is above an acceptance threshold, then control is transferred to a step 688 and other attributes are checked. If any attribute tests are failed, then control is transferred to step 688 by a step 690 and the application is rejected. If all attribute tests are passed, then control is transferred to a step 692 and the application is accepted. The process ends at 694.
  • It should be noted that in other embodiments, other methods of determining whether to accept or reject an applicant are used. For example, in one embodiment, an applicant is accepted automatically if he or she has a FICO score that is above a certain threshold.
  • The attribute tests performed in step 688 may take on various forms. In one embodiment, a list of attributes is checked including attributes such as whether the applicant is severely delinquent, currently delinquent, has a derogatory public record, or has been delinquent a certain number of times in a past period. A test may be defined for each attribute such as a maximum number of times delinquent above which the test is failed. In one embodiment, a list of tests is defined and all of the tests must be passed. In another embodiment, a list of tests is defined and certain subsets of the list are also defined. At least one subset must be passed for the applicant to pass.
  • Once the decision is made to accept or reject an applicant, the status of the applicant is set to be accepted or rejected. Rejected applications are processed in a rejection process described in FIG. 7. Accepted applications are processed in an offer and confirmation process described in FIG. 10A.
  • FIG. 7 is a flow chart illustrating a process for checking the status of an application and executing either an offer process or one of several rejection processes. The process starts at 700. In a step 702, the status of the application is checked based on the processing performed by the Underwriter. As mentioned above, the Underwriter determines whether the application is a duplicate application, whether enough credit bureaus are available to provide sufficient credit reports to evaluate the application, and whether applications having sufficient credit reports should be accepted or rejected.
  • If the status of the application determined by the Underwriter is that the application is a duplicate of a previously entered application, then control is transferred to a step 706 and a message indicating that the application is a duplicate is displayed to the applicant. Next, in a step 708, a link to a reentry screen is provided to the applicant. The reentry screen allows the applicant to execute a process that finds the earlier application and allows the applicant to review or resume the earlier application. For example, if the earlier application was accepted but the applicant did not accept an offer, then the process may resume at that point and the applicant may be given another opportunity to accept. This is preferable to allowing the application process to be repeated from the beginning since that could needlessly cause a new credit report to be obtained. After the reentry screen is displayed, the process ends at 720.
  • If the status of the application indicates that the application has been accepted, then control is transferred to a step 714 and an offer process is executed. The offer process is described in further detail in FIG. 10. If the status of the application is that a credit bureau error occurred, then control is transferred to a step 710 and an error message is displayed indicating that not enough credit bureaus are currently available to allow the application to be processed. Also, in a step 712, a link is provided to a site that allows the applicant to report the error and request further information or request to be contacted. After the offer process or the credit bureau error process is executed, the process ends at 720.
  • If the status of the application indicates that the application has been rejected, then control is transferred to a step 704 and a rejection process is executed. The rejection process is described in further detail in FIG. 8A and FIG. 8B. Once the rejection process is executed, the process ends at 720.
  • FIG. 8A is a flow chart illustrating a process for determining an appropriate reason to display for rejecting an applicant and displaying that reason. The process starts at 800. In a step 802, the main factors given by the credit bureau that affect the FICO score are obtained. Generally, the main factors identified by the credit bureau for the FICO score are provided in the form of a numerical code that corresponds to a predetermined factor. In a step 804, the credit bureau code is mapped to an internal code that is determined from a data structure that maps bureau codes to internal factors. In one embodiment, the data structure is a table such as that illustrated in FIG. 8B.
  • Certain credit bureau codes that indicate positive factors that would be inappropriate bases for rejection such as home ownership are mapped by the data structure to a general rejection reason such as “Applicant rejected based on FICO score” or “Applicant rejected based on credit bureau data.” Although such general reasons may be provided to the applicant as a last resort, it is preferred that a more specific reason be given. To that end, a step 806 checks whether any of the FICO reasons have been mapped to any specific rejection reasons. If all of the FICO reasons map only to the general reason, then control is transferred to a step 808.
  • In step 808, the rejection process begins to attempt to find a more appropriate reason for rejection of the applicant. First, the results of the various attribute tests generated by the Underwriter are obtained. In a step 810, it is checked whether any of the attribute test results map to an appropriate rejection reason. If an attribute test result maps to an appropriate reason, then control is transferred to a step 812 and the attribute reason is assigned as the reason given to the applicant upon rejection. If the attribute test does not map to an appropriate reason, then control is transferred to a step 816 and a general reason is assigned as the reason given to the applicant upon rejection. If, in step 806, it was determined that one or more of the FICO score factors identified by the credit bureau correspond to an acceptable rejection reason other than the general rejection reason, then that reason is assigned as the reason to be given to the applicant in a step 814. Whether or not a specific reason is identified by that above mentioned steps, control is transferred to a step 818 where the reason is displayed to the applicant and the process then ends at 820.
  • FIG. 8B is a diagram illustrating one data structure used to map main FICO factors provided by the credit bureau (referred to as external codes) to internal decline codes as well as reasons for rejection to be provided to rejected applicants. It should be noted that although a table is shown, other data structures such as a linked list are used in other embodiments. Each external code maps to an internal code that corresponds to an internal reason for rejecting the applicant. The actual reason is also stored for each internal code. As described above, certain external codes correspond to internal codes that provide only a general rejection reason. Other external codes are mapped to internal codes that allow a specific rejection reason to be given.
  • Once an appropriate rejection reason is selected, it is necessary to display the reason to the applicant. In one embodiment, the reason is displayed on a web page along with an acknowledgement button that allows the applicant to acknowledge that he or she has read the rejection message. FIG. 9 is a flow chart illustrating how a rejection reason may be obtained. The process starts at 900. In a step 902, the reason for rejection is retrieved. Next, in a step 904, the rejection reason is displayed. In addition, in a step 906, a link to a credit counseling site is also displayed. The acknowledgement button is displayed in a step 908. When the applicant leaves the rejection page, a step 910 checks whether the acknowledgement button has been activated. If the button has been activated, then control is transferred to a step 912 where the application is marked as having had an acknowledgement to a rejection. If the acknowledgement button has not been activated, then control is transferred to a step 914 and the application is marked as not having had an acknowledgement to a rejection. The process ends at 916.
  • It should be noted that other methods of verifying that a rejection has been received are used in other embodiments. For example, in one embodiment, an applet is sent along with the rejection that sends a message back to the credit approval system when the rejection message page is completely downloaded by the applicant. In this manner, the fact that a rejection was delivered to the applicant can be verified without requiring any action by the applicant.
  • Once the rejection has been sent and acknowledged or not, the rejection or acknowledgement status may be provided to an entity such as FDR for the purpose of generating hard copies of rejection letters and either sending such hard copies as confirmations to all rejected applicants or else, in some embodiments, only sending hard copies of rejection letters to applicants that have not acknowledged an on line rejection.
  • Accepted applications have an accepted status and they also contain important applicant information supplied by the applicant and obtained from the credit bureau reports that can be used to design a custom account level offer for the applicant. Preferably, multiple offers are presented to the applicant, allowing the applicant to select an offer that includes terms that the applicant desires to accept.
  • FIG. 10A is a flowchart illustrating a process for providing a set of multiple offers to an applicant and receiving a balance transfer amount corresponding to an offer selected by the applicant. The process starts at 1000. In the step 1002, the application object is retrieved. The application object includes the information provided by the applicant as well as information obtained from credit bureaus and analyzed by the Underwriter.
  • Next, in a step 1004, offer selection criteria are obtained from the credit report object. In one embodiment, the offer selection criteria include FICO score, income and a balance transfer requirement. Offer selection criteria also may include data entered by the applicant. The offer selection criteria also may include other attributes such as time on file. In general, the offer selection criteria are selected from information obtained from the applicant and from the credit bureaus for the purpose of estimating the applicant's risk of default to determine an expectation of future loss as well as an expected future total revolving balance (TRB). In this manner, an appropriate offer may be determined. In one embodiment, the balance transfer requirement is calculated as a selected percentage of the applicant's TRB. As described below, different offer terms may be provided for different balance transfer requirements. As noted above, in other embodiments, other data structures than the application object are used to store this information.
  • Next, in a step 1006, a set of offers is derived from the credit report data and other applicant information stored in the application object. In a step 1008, the set of offers is displayed. In one embodiment, the offers are derived from the FICO score and income of the applicant, which determine the risk of default, and also from a balance transfer amount specified in the offer. The balance transfer amount may be determined as a percentage of the total revolving balance that the applicant has on all outstanding credit cards in the credit report for the applicant. Both the credit limit offered to the applicant and the interest rate offered to the applicant may vary according to the amount of the total revolving balance that the applicant chooses to transfer to the new account.
  • In addition offers may present incentives such as frequent flier miles, cash back on purchases, or favorable interest rates.
  • In a step 1010, the system notes the selected offer and balance transfer amount. Next, in a step 1012, the system obtains the balance transfer amount from the applicant. Preferably, the balance transfer is actually executed while the applicant is on line. The process for obtaining and executing the balance transfer in real time on line is described further in FIG. 13. Once the balance transfer is executed, a data file is assembled for transmission to FDR for the purpose of issuing a credit card in a step 1014. The process ends at 1016. Thus, the system derives a set of offers based on information from the applicant's credit reports and displays the set of offers to the applicant. The applicant then can select an offer based on the amount of balance transfer that the applicant wishes to make. Once the applicant selects an offer and a balance transfer amount, the system actually executes the balance transfer by allowing the applicant to select the accounts from which to transfer balances. Once the balance transfer is executed, the data relating the application is assembled and sent to FDR.
  • In different embodiments, the system uses different methods of determining the terms of the offer extended to the applicant based on the information derived from the credit report. FIG. 10B is a flow chart illustrating one such method of deriving a credit limit for an applicant based on the applicant's FICO score and income, as well as the amount of total revolving balance that the applicant elects to transfer. The process starts at 1020. In a step 1022, the system obtains applicant information and the credit bureau information. This information may include the FICO score and income of the applicant. Next, applicant information and the credit bureau information are used to determine an expected unit loss rate for the applicant In a step 1024. The unit loss rate corresponds to the probability that the applicant will default on the credit line extended. That probability multiplied by the credit limit extended to the applicant determines the dollar loss rate for that applicant. The dollar loss rate divided by the average total outstanding balance of the account is the dollar charge off rate for the applicant.
  • In one embodiment it is desired that a dollar charge off rate be kept within a determined range for different applicants. To accomplish this, it is desirable to extend smaller amounts of credit to applicants with a higher probability of defaulting. It is also useful to extend different amounts of credit based on a total outstanding balance transferred by the applicant since the balance transfer influences the likely future total outstanding balance of the account. Conventional offer systems have been able to extend offers to applicants with credit limits that are controlled by the applicant's predicted average dollar loss. However, prior systems have not been able to extend credit and determine a credit limit based on a predicted total outstanding balance for the client because they have failed to be able to present offers and condition the acceptance of the offers in real-time on a balance transfer made by the applicant.
  • Next, in a step 1026 the system determines one or more balance transfer amounts based on the total revolving balance that the applicant has in various other credit card accounts. In one embodiment, the balance transfer amounts are calculated based on different percentages of the total revolving balance determined from all of the applicant's accounts found in the credit report. Then, in a step 1028, the system calculates for each total balance transfer amount choice that will be presented to the applicant, a predicted estimated revolving balance for the future that the applicant would be expected to maintain. The estimated total revolving balance may be equal to the balance transfer amount or may be a function of the balance transfer amount. In one embodiment, the estimated total revolving balance does not depend on the balance transfer amount. In one embodiment, four possible percentages of the applicant's total revolving balance as determined by the credit report are presented to the applicant. Those choices are none of the balance, one-third of the balance, two-thirds of the balance, and the full balance. Depending on which of those amounts is selected by the applicant, the system calculates a predicted total revolving balance for the future. Then, in a step 1030, the credit limit for the applicant is set to achieve a target dollar charge off rate based on the amount of the total revolving balance that the applicant elects to transfer and the risk of default. The process then ends at 1032.
  • The process described in FIG. 10B shows conceptually how a credit limit could be determined based on an amount of balance transfer and a FICO score and income. This process may be implemented directly in some embodiments. However, in other embodiments, it is preferred that a table be precalculated that includes amounts of credit limit that the applicant will be given based on certain amounts of balance transfer and FICO score. Using such a table, the applicant's FICO score and balance transfer amount may be looked up and then the credit limit may be found in the corresponding cell. FIG. 10C is a table illustrating how this is accomplished. Each row of the table corresponds to a different FICO score, and each column of the table corresponds to a different balance transfer amount. When the cell corresponding to the FICO score and balance transfer amount is determined, the credit limit obtained. A cut-off line 1040 is also shown which represents an upper limit for a balance transfers for a given FICO score.
  • In the embodiment described above, separate tables are prepared for applicants of different incomes. In addition, separate tables may also be prepared for applicants having other different characteristics such as time on file for the applicant. It should be noted that the tabular representation of the data is presented as an example only and the data may be represented in many ways including in three-dimensional or four-dimensional arrays, linked lists or other data representations optimized for a particular system. By allowing the account credit limit to be a function of FICO score, balance transfer, and income, a credit limit may be selected for each individual account that enables the dollar charge off rate for all applicants to be controlled.
  • FIG. 11 is another data representation illustrating another embodiment of how the offers may be determined based on FICO score, income range, income, and total revolving balance transfer. A single table includes a range of FICO scores 1108, an income range 1110, a balance transfer column 1112, and four offer columns, 1114, 1116, 1118, and 1120. Each of the offer columns includes a link to a web page that describes the offer in more detail. Once the proper row of the table is found, multiple offers may be displayed to the applicant by assembling the various links either in a single frame or in consecutive frames for the applicant to view and select an offer.
  • Another component of the offer granted to the applicant that may be varied based on the balance transfer selected is a teaser rate or annual rate. A teaser rate is an interest rate that is temporarily extended to the applicant either on the amount transferred or on the amount transferred and purchases made for a certain period of time. The teaser rate is intended to incent the applicant to transfer a greater balance to a new account. In one embodiment, the teaser rate is determined based on the percentage of the applicant's total revolving balance that the applicant elects to transfer. Thus, the amount transferred by the applicant controls not only the applicant's credit limit but also determines a teaser rate extended to the applicant.
  • FIG. 12 is a diagram illustrating a display provided to the applicant for the purpose of presenting multiple offers to the applicant. The display includes a first offer 1204, a second offer 1206, a third offer 1208, and a fourth offer 1210. For each offer, there is a column 1214 corresponding to the initial teaser rate, a column 1216 corresponding to the annual fee offer, a column 1218 corresponding to the credit limit, and a column 1220 corresponding to the required balance transfer for that offer to be accepted. The applicant selects one of the offers from the table. As noted above, in one embodiment, the offers are provided as part of a web page and the offers are presented using html. By selecting an offer, the applicant selects a link that indicates to the system which offer is selected. Once an offer is selected, the process of acquiring the required balance transfer in real-time from the applicant is executed. That process is described further in FIG. 13.
  • FIG. 13 is a flow chart illustrating a process for obtaining a real-time balance transfer from an applicant. The process starts at 1300. In a step 1302, the system retrieves the accounts and balances that the applicant has based on the credit report data obtained for the applicant. Next, in a step 1304, the estimated balances for each of the accounts that were retrieved in step 1302 are presented to the applicant and the accounts are identified. Identification of the accounts is a sensitive issue because the specific account data for the applicant is confidential and if the information is displayed to an unauthorized person, fraud could result. Therefore, in one embodiment, a partial account number that lists the account granting institution as well as part of the account number for the account held by the applicant with that institution is displayed. Generally, this information is sufficient for the applicant to recognize the account, but is not enough information to present a fraud risk.
  • It should be noted that in some embodiments, the accounts chosen for display by the underwriter are selected in a manner to facilitate a simpler balance transfer. For example, the largest account balances may be displayed first so that amounts may be efficiently transferred to meet the required transfer. Also, a group of balances to transfer may be presented to the applicant by highlighting certain accounts.
  • Next, the applicant is given an opportunity to indicate a balance transfer by selecting one of the accounts and indicating the amount to be transferred. It should be noted that the applicant in this manner does not need to provide account information to execute a balance transfer. If a transfer is indicated, control is transferred to a step 1306 and the amount of the user balance transfer is obtained. Next, in a step 1307, it is determined whether the sum of the balance transfers is greater than or equal to the required transfer amounts for the offer selected by the applicant. If the amount is not greater than or equal to the required-transferred amount, then control is transferred back to step 1304 and the applicant is given an opportunity to select further balances to transfer. If the amount of the balance transfers is greater than or equal to a required transfer amount, then control is transferred to a step 1308 and the system requests final confirmation from the applicant of the balance transfers. If it is determined in a step 1310 that a confirmation of the balance transfer has been received, then control is transferred to a step 1312 and the balance transfers are executed. The process ends at 1314.
  • If in step 1304, it is determined that the applicant has elected to exit the balance transfer screen instead of indicating a balance transfer, or if it is determined in step 1310 that the applicant elects not to confirm the balance transfer amounts selected, then control is transferred to a step 1316 and the applicant is returned to the offer selection screen so that the applicant will have an opportunity to select another offer that either does not require a balance transfer or requires less of a balance transfer. The process then ends at 1314.
  • FIG. 14 is a block diagram illustrating one computer network scheme that may be used to implement the system described herein. An applicant host system 1402 is connected to the Internet 1404. The applicant host system may be a PC, a network computer, or any type of system that is able to transmit and receive information over the Internet. Also, in other embodiments, a private network such as a LAN or WAN or a dedicated network may be used by the applicant to communicate. A web server 1406 is also connected to the Internet and communicates with the applicant host system via the Internet to request receive applicant information and to notify the applicant of the results of the approval process. Web server 1406 in one embodiment accesses a business logic server 1408 that implements the various approval checking processes described herein. It should be noted that in some embodiments, the web server and the business logic server are implemented on a single computer system with one microprocessor. However, for the sake of efficiency, the system implemented as shown is often used with different servers dedicated to communicating with applicants and processing applicant data, respectively. The business logic server, wherever implemented, includes a communication line on which communication may be had with credit bureaus or other outside data sources. In some embodiments, an Internet connection may be used for that purpose. Thus applicant data is obtained by the business logic server either over the Internet either directly or through a Web server. Also, data may be obtained by the business logic server from an applicant using a direct dial in connection or some other type of network connection.
  • A real time credit approval system has been described herein primarily for the purpose of determining whether a credit card should be issued to an applicant. Software written to implement the system may be stored in some form of computer-readable medium, such as memory or CD-ROM, or transmitted over a network via a carrier wave in the form of Java® applets, other forms of applets or servlets, and executed by a processor. The system may be implemented on a PC or other general purpose computer known in the computer art.
  • It should be recognized that the system described may also be used for the purpose of granting credit to an applicant for the purpose of making a single transaction. In such a system, a transaction is interrupted and the application for credit is made. Based on the real time approval decision made, credit may or may not be granted for the purpose of completing the transaction.
  • Referring now to FIGS. 15-27, system for providing an applicant with a counter offer of credit when the applicant rejects a first offer is disclosed. In one embodiment, an applicant who requests a counter offer is directed to a chat agent. The applicant ID is transferred to the chat agent so the chat agent can access information about the state of the applicant's application. Using the chat interface, the applicant explains to the chat agent why the original offer was not acceptable and the chat agent interacts with an application database to determine a counter offer. The counter offer is transferred to the applicant through an application server.
  • In one embodiment, a method of offering credit to an applicant includes determining a plurality of offers using information about the applicant. A displayed offer is displayed and a withheld offer is withheld. An indication that the displayed offer is unacceptable is received and the withheld offer is displayed.
  • In one embodiment, a method of offering credit to an applicant includes determining a plurality of offers using information about the applicant. A displayed offer is displayed and a plurality of withheld offers are withheld. An indication that the displayed offer is unacceptable is received including an indication that an attribute is unacceptable. A selected withheld offer is selected using the attribute that is unacceptable and the selected withheld offer is displayed.
  • In one embodiment, a method of offering credit to an applicant includes determining a plurality of offers using information about the applicant. A displayed offer is displayed and a plurality of withheld offers are withheld. An indication that the displayed offer is unacceptable is received including an indication that a plurality of attributes are unacceptable. A primary unacceptable attribute is determined and a selected withheld offer is selected using the primary unacceptable attribute. The selected withheld offer is displayed.
  • In one embodiment, a method of offering credit to an applicant includes determining an offer using information about the applicant and displaying the offer to the applicant. An indication that the displayed offer is unacceptable is received. An attribute of the offer that is unacceptable is determined. In the event that the unacceptable attribute is the amount of the credit limit; the credit limit is recalculated for the applicant.
  • In one embodiment, a method of offering credit to an applicant includes determining a first offer using information about the applicant and displaying the first offer to the applicant. A chat interface is activated between the applicant and a customer service agent. A second offer for the applicant is determined based on chat between the applicant and the customer service agent and the second offer is displayed to the applicant.
  • In one embodiment, an application server for providing a counter offer of credit includes an applicant interface configured to receive applicant data from an applicant browser and to communicate an offer of credit to the applicant and the counter offer of credit to the applicant. A processor is configured to determine the offer of credit based on the applicant data and the counter offer of credit based on an unacceptable attribute of the first offer of credit and an agent interface is configured to receive the unacceptable attribute from an agent.
  • In one embodiment, a chat server for providing a counter offer of credit includes an applicant interface configured to receive chat from an applicant. An agent interface is configured to receive chat from an agent and an unacceptable attribute determined from the chat from the applicant. An application server interface is configured to send the unacceptable attribute and to receive a counter offer.
  • In one embodiment, an applicant client for obtaining a counter offer of credit includes an application server interface configured to send applicant information and to receive and offer of credit and a counter offer of credit. A chat server interface is configured to be activated upon an indication that the offer of credit is not acceptable.
  • In one embodiment, an applicant interacts with a web server and receives a web page containing offers of credit that may be accepted by the applicant. At any point during the interaction with the web server, an online chat button or process may be activated that sends an applicant ID to a chat server and opens a chat window so that the applicant can receive help. In one embodiment, the help takes the form of the applicant describing why a displayed offer is unacceptable and a counter offer being generated for the applicant.
  • FIG. 15 is a block diagram illustrating a system for providing real time chat help to an applicant and generating a counter offer when appropriate. A web server 1102 is in communication with an application database 1103. Application database 1103 is used to store information about the applicant and the application. The information stored includes information provided by the applicant as well as information derived from various credit bureaus (not shown) that are accessed by the web server either directly or indirectly. Each application included in the application database is referenced by an applicant identifier that can be used to identify the application.
  • Web server 1102 provides a web page 1104 to a browser 1106. Typically, the web server and browser communicate over the Internet using HTTP. Web page 1104 is shown for the purpose of illustration as an offer web page that includes three offers made to the applicant for a credit card as well as an on-line chat button that may be activated by the applicant to obtain help or to discuss the offers. Other web pages provided by the web server include forms that the applicant fills out to provide information so that a credit report may be obtained and an offer of credit generated based on the applicant's personal information.
  • An online application process for a credit card is described in detail in U.S. patent application Ser. No. 09/185,201, entitled: “Method And Apparatus For Real Time Online Credit Approval”, filed Nov. 17, 1998, which was previously incorporated by reference; and U.S. patent application Ser. No. 09/185,878, entitled: “Method And Apparatus For A Verifiable Online Rejection Of An Applicant For Credit”, filed Nov. 17, 1998, which was previously incorporated by reference; and U.S. patent application Ser. No. 09/185,000, entitled: “Method And Apparatus For An Account Level Offer Of Credit And Real Time Balance Transfer”, filed Nov. 17, 1998 which was previously incorporated by reference.
  • It should be noted that the process described herein will refer to the online credit application as being an application for a credit card. The process can also be applied to other offers of credit including an offer of instant credit for the purpose of consummating a single pending online transaction. In addition, the system and processes disclosed herein may be applied to other types of business transactions over the Internet. However, the particular architecture and processes described are especially useful for processing online credit card applications and the benefit of their application to online credit card applications is particularly strong.
  • Web server 1102 and browser 1106 continue to interact in a standard fashion with web pages being provided by web server 1102 and the applicant filling out information as needed. At some point, an applicant may activate the online chat button included on the web page and a chat window 1104 a opens up for the chat application and a connection is established with a chat server 1108. As is described further below, the chat window is opened and the connection with chat server 1108 may be initiated by events other than just the activation of the online chat button. Chat server 1108 implements a standard chat environment such as the chat environment available from e-share. Other chat environments may be used that include the ability to pass a variable to the chat server from the browser.
  • The various servers shown in FIG. 15 may be implemented on any typical platform such as a Windows NT platform, a Linux platform, or other UNIX platform or other commercially available web server platform. The browser may be implemented on any system such as a Macintosh or a PC which are readily available.
  • In some embodiments, the chat process is initiated when the applicant cancels out of the application. In other embodiments, the chat process is initiated when the applicant lingers on a page for an amount of time that exceeds a threshold. In other embodiments, the chat process is initiated when the applicant's response to a request for information is somehow inadequate. For example, it may be detected that the answers provided by the applicant are incomplete or in the wrong form. The chat process may be initiated for the purpose of providing the applicant more detailed instructions or pointing out to the applicant the information that is required to complete the application.
  • In addition to opening the chat connection to chat server 1108, browser 1106 also sends the applicant identifier to the chat server. The chat server then uses the applicant identifier to access information about the application in the application database. It should be noted that the applicant identifier may be used as an application identifier in circumstances such as would be expected for an online credit card application where there is one and only one application per applicant. In other embodiments, an application identifier that is unique for each application is assigned and used. In this description, wherever an applicant identifier is mentioned, an application identifier could also be used.
  • Sending the applicant identifier to the chat server instead of sending the current web page or other information to the chat server is preferable from a security standpoint because the applicant identifier can only be used to obtain information about the application by accessing application database 1103. In addition, preferably, the applicant identifier is encrypted, adding a further level of security.
  • In the embodiment shown, chat server 1108 does not have a direct link to the application database 1103. Chat server 1108 is connected to a customer service agent 1110. Customer service agent 1110 handles the chat session, responding to requests made by the applicant. Other customer service agents 1112 and 1114 are also standing by to handle other chat sessions generated by chat server 1108. In one embodiment, requests made to the chat server are queued and the next available customer service agent is assigned to the first chat session request found in the queue.
  • Customer service agent 1110 is connected to a counter offer server that is connected to application database 1103. By passing the applicant identifier from the chat server to the customer service agent to the application database through the counter offer server, information about the applicant can be obtained from the application database. Connections from the customer service agent to the counter offer server and from the counter offer server to the application database may be made over the Internet or may be a dedicated secure connection.
  • In the embodiment shown, which is adapted specifically for implementing a counter offer strategy as is described below, a separate web server 1102 and counter offer server 1120 are shown. This divides the processing demand generated by normal communication with a browser from the processing demand generated by interaction initiated by chat with a customer service agent. This architecture is particularly useful since the two types of traffic are isolated. In other embodiments, the functions of the web server and the counter offer server are performed by a single application server. Dashed box 1122 represents a single application server that may include both the web server and the counter offer server. In general, the term application server is used to describe either the web server and counter offer server operating collectively or to describe a single server performing both the function of the web server and the counter offer server.
  • Additionally, in a system where a counter offer is not generated, counter offer server 1120 may be referred to as a customer service agent server or some other term describing its primary function. The important point is that both the web server and the counter offer server both access the application data base to obtain information about the status of the application. In addition, both the web server and the counter offer server may write data to the application database in some embodiments. The common access to the application database enables the customer service agent to obtain information about the status of the application using the applicant identifier received through the chat server and also allows the customer service agent to alter the status of the application based on information received from the applicant through the chat server by sending that information to the counter offer server for posting to the application database.
  • Thus, an applicant provides information to database 1103 via the Internet using web pages in a standard manner. In addition, the applicant may communicate via chat with a customer service agent who also is connected to the application database and may change the state of the application according to information received by the applicant via chat. In the embodiment shown, the customer service agent interacts with a special purpose counter offer server that uses the information provided by the applicant to determine a counter offer using information in the application database. The counter offer is stored in the application database and provided to the applicant's browser via the web server. As noted above, the counter offer server and the web server may be implemented on a single machine referred to as the application server. The various processes operating on the application server, the chat server and the browser are described below for the purpose of illustrating how the chat window may be activated and a counter offer generated for the applicant.
  • FIG. 16 is a flowchart illustrating a general process implemented on the chat server. The process starts at 1200. In a step 1202, the applicant identifier is obtained from a browser. In a step 1204, the chat server validates the applicant information by communicating with the application database. In some embodiments, the chat server may communicate directly with the application database. In other embodiments, as shown in FIG. 15, the chat server communicates with the application database through an application server. After the applicant information is validated, a response is received from the applicant via chat. Based on the response, the applicant account is configured in a step 1208 and the process ends at 1210.
  • FIG. 17 is a flow chart illustrating a general process implemented on the web server for sending dynamic web pages to the applicant. The dynamic web pages differ from a standard web page used to interact with the applicant because they contain a page object used to initiate a chat section with a chat server upon the occurrence of certain events. The page object includes an applicant identifier that is passed to the chat server. The process starts at 1300 when chat is initiated based on a user action. As described above, the user action may be the activation of a help or chat button or the user canceling out of the application. Chat may also be activated by user inaction when a response is not received or by an improper action taken by a user resulting in an invalid response. In a step 1302, the state of the application is determined. Next, in a step 1304, the content of the page to be sent to applicant is determined based on the state of the application. Next, in a step 1306, the applicant identifier is inserted into a page object. In a step 1308, the page is sent to the applicant browser and the process ends at 1310.
  • FIG. 18 is a flow chart illustrating a process implemented on a browser for establishing a connection to a chat server. The process starts at 1400. In a step 1402, a link to the chat server is activated either directly by the user or as a result of the occurrence of an event as described above. In a step 1404, a connection is established to the chat server. Typically the connection uses a protocol such as HTTPS. Next, in a step 1406, the applicant identification is sent to the chat server and the process ends at 1408.
  • FIG. 19 is a flowchart illustrating a typical process implemented on the browser for the purpose of initializing chat when the user does not respond to a downloaded web page in a certain period of time. The process starts at 1500. In a step 1502, a timer is initialized. Control is then transferred to 1504 where periodic checks are made to determine whether the timer has expired. If a valid user input is received, control is transferred to a step 1506 and the timer is reset. If the timer expires, then control is transferred to a step 1508 and a chat session is initiated as described above. The process then ends at 1510.
  • FIG. 20 is a flow chart illustrating a process implemented on a chat server when a chat session is requested by a browser as described above. The process starts at 1600 when the request is received. The request for a chat session includes both a connection request and the applicant identifier. In a step 1602, the request is put into a queue and the applicant identifier is stored in a manner that associates it with the request. In some embodiments, the chat server uses the applicant identifier while the request is still in the queue to obtain the application information from the application database. In other embodiments, the applicant identifier is not used to access the application database until the request is assigned to a customer service agent. This insures that when the customer service agent accesses the information about the application, the information is up to date. In a step 1604, a status message is sent to the user and the system then waits for an available customer service agent. So long as no customer service agent is available, the system continues to wait at 1604. When a customer service agent becomes available, control is transferred to a step 1606 and the application information is sent to the customer service agent. The customer service agent then uses the application information to discuss the state of the application with the applicant.
  • FIG. 21A is a flow chart illustrating a process implemented at a customer service agent for the purpose of supporting the chat session. The process may be implemented on a client machine accessed by the customer service agent or may be implemented on the application server which may include a dedicated counter-offer server. The process starts at 1700. In a step 1702, the customer service agent notifies the chat server that it is available. Next, in a step 1704, the applicant identifier is received from the chat server. In a step 1706, the applicant record in the application database is accessed using the applicant identifier as mentioned above. The application record may be accessed either directly or via the application server. In a step 1708, the chat server displays the application data retrieved using the applicant identifier to the customer service agent. In one embodiment, the application data is displayed by displaying the same web page that the applicant is viewing. In addition, the web page may be augmented with other information about the status of the application. Alternatively, a completely separate application information screen may be displayed to the customer service agent.
  • In an embodiment where a counter offer is generated by the customer service agent, a display is provided showing various offer terms that the applicant may indicate are not acceptable in the chat between the applicant and the customer service agent. The customer service agent may check one or more of the terms and the terms checked by the customer service agent are sent to the counter offer server to be used in generating a counter offer. The terms or attributes of the offer that the applicant considers to be unacceptable are obtained in a step 1712 and the initial process for receiving applicant information and providing information to the counter offer server ends at 1714.
  • It should be noted that a number of different methods of obtaining the unacceptable terms from the applicant may be used. In one embodiment, as described above, a set of offer terms are shown to the customers service agent and the customer service agent selects terms identified by the applicant in chat that are unacceptable. In other embodiments, a display of terms is provided to the applicant and the applicant picks the unacceptable terms with the aid of the customer service agent. In yet another embodiment, the chat generated by the applicant is automatically analyzed by a program which generates the list of unacceptable terms for the counter offer server.
  • FIG. 21B is a screen shot illustrating a display of offer terms used in one embodiment for determining which terms are unacceptable. The display includes indications that interest rate attributes are not acceptable, indicating that the annual percentage rate or long term interest rate is too high, a longer introductory interest rate is desired, or an introductory interest rate is desired. The introductory interest rate is a very low rate offered for a short period of time when the account is established, also referred to as a teaser rate. In addition, buttons are provided for the customer service agent to check whether the credit limit is too low either for purchases or for balance transfers. In addition, the customer service agent can fill in a balance transfer amount that the applicant wants to transfer as well as a requested credit limit. Finally, a box is provided for the customer service agent to check and send the data to the counter offer server.
  • FIG. 22 is a flow chart illustrating in detail a process implemented in step 1712 for obtaining the unacceptable terms of an offer from an applicant. The process starts at step 1800. In a step 1802, a chat message is received from a user indicating a term that the user would like to change. The message is displayed to the customer service agent along with a checklist as shown in FIG. 21B illustrating terms to change. As noted above, the checklist may also be displayed and checked by the applicant. In a step 1806, an input is received from the customer service agent of a selected term that the applicant would like to change of an offer. In a step 1808, the term is sent to the counter offer server and the process ends at 1810.
  • FIG. 23 is a flow chart illustrating the process implemented on the counter offer server when more than one term is selected as being unacceptable to the applicant. In one embodiment, a counter offer is selected based on only one unacceptable term being changed. This simplifies the process of determining a counter offer since changing two terms is somewhat more complex. Therefore, a hierarchy of terms that may be changed by the applicant is provided and the highest priority term selected is used to determine the counter offer. All of the unacceptable terms are still transmitted to the counter offer server and recorded for the purpose of data gathering and analysis of the system. The process starts at 1900. In a step 1902, multiple unacceptable terms or attributes of the offer are received by the counter offer server. Next, in a step 1904, the highest priority term or attribute that is unacceptable is determined. Next, in a step 1906, the offer is adjusted and a counter offer is determined based on the highest priority term. The process ends at 1908.
  • Many different methods may be used by the counter offer server to generate a counter offer based on attributes or terms identified by the applicant as being unacceptable. In one embodiment, a number of potential offers are identified based on the applicant information provided and an assessment of the risk associated with extending credit to the applicant. Some of the generated offers are withheld while others are displayed to the applicant. A number of schemes may be used to decide which offers are displayed and which offers are withheld. Some methods may include a statistical selection or a selection according to a marketing scheme designed to increase the rate of acceptance. It may also be the case that the best offer is withheld and kept in reserve to use as a counter offer. In general, certain potential offers are withheld.
  • The identification by the applicant of an unacceptable term is used by the counter offer server to identify a better offer for the counter offer. In one embodiment, offer strategies are identified and the counter offer is identified by simply looking up an offer strategy associated with the applicant and the identified unacceptable term. In one embodiment, an offer strategy may include a set of offers shown to the applicant as well as offers that are not displayed and that correspond to various unacceptable terms. When an unacceptable term is identified, the offer corresponding to the strategy and the unacceptable term is used as the counter offer.
  • In some embodiments, the counter offer strategy is dependent on characteristics of the applicant. For example, the applicant may be classified as a “surfer” or “non-surfer”. A “surfer” is a person who shifts or surfs balances among credit cards, taking advantage of low teaser rates. A determination that an applicant is a surfer is made based on an analysis of the applicant's credit report. A counter offer strategy designed for such an applicant may adopt the strategy of extending the period of an introductory rate if requested by the applicant, but requiring the applicant to make a certain number of purchases or not transfer the balance for a certain period of time.
  • In general, added terms and conditions such as purchase requirements or a length of time that a balance may not be transferred from the card may be added to counter offers for the purpose of creating a perceived barrier to receive the counter offer. Such a barrier or condition prevents the applicant from deciding that the first offer should always be rejected. In some embodiments, the conditions are determined based on characteristics of the applicant. As described above, surfers may receive balance transfer time restrictions.
  • In addition to selecting a withheld offer based on a pre-determined offer scheme, the counter offer server may also recalculate a customized offer based on the identification of an unacceptable term and an actual requested term by the applicant. For example, the applicant may express that the credit limit is too low, either for a desired balance transfer that the applicant wants to make or new purchases. The amount of the credit limit minus the amount of the balance transfer is referred to as the amount of credit that is “open to buy”. The information sent to the counter offer server may include a requested credit limit and a requested balance transfer amount. From that information, the counter offer server can determine that the offer credit limit is too low either for the balance transfer requested or for the amount that the applicant wants open to buy. To minimize risk, it is desirable that the credit limit be as low as possible. Therefore, it is desirable not to simply select a withheld offer with a higher credit limit, but instead to customize an offer that conforms to the applicant's request but does not exceed the applicant's request.
  • Accordingly, a new credit limit may be calculated that incorporates the requested balance transfer and the amount that the applicant wants open to buy. The calculated new offer is of course checked versus the risk profile of the user and it is verified that the higher credit limit is appropriate for the user. Any of the various techniques well known in the art of assigning credit may be used to assess the risk of the applicant and determine an appropriate upper credit limit. Significantly, the counteroffer in the case of a requested higher credit limit is specifically customized for the applicant based on what the applicant requests. In general, any counter offer provided is based on the applicant's identification of an unacceptable term. In some embodiments, if no counter offer is available that improves an unacceptable term identified by the applicant, then a message is returned to the applicant either directly or through the chat interface that indicates that no counter offer can be provided at that time. For example, in one embodiment, the offer strategy may include an offer with the best annual percentage rate available in the set of offers initially displayed to the applicant. In such a case, if the applicant identifies the annual percentage rate as the unacceptable term, then no counter offer improving that term can be generated.
  • FIG. 24 is a flow chart illustrating an example process for generating a counter offer. The process starts at 11000. In a step 11010, the counter offer server receives the term that is to be changed. Next, in a step 11020, it is determined whether the term is the credit limit or not. If the term is not the credit limit, then control is transferred to a step 11030 and a precomputed offer that was withheld is determined for display. The counter offer determination process then ends at 11040. If the term is the credit limit, then control is transferred to a step 11050 and it is determined whether the credit limit is too low for a requested balance transfer or for new purchases (open to buy). If the credit limit is too low for new purchases, then control is transferred to a step 11060 and the required balance transfer and credit limit are adjusted if that is allowed by the scheme being used to assign credit based on an assessment of the applicant's risk.
  • If the credit limit is too low for a requested balance transfer, then control is transferred to a step 11070 and the credit limit is adjusted based on the balance transfer requested if allowed by the credit line assignment being used. After the credit limit is adjusted in steps 11060 or 11070, the counter offer is defined and the counter offer determination process ends at 11080. Whether a precomputed offer is determined for display in 11030 or the credit limit is recomputed in step 11060 or 11070, if no better offer can be generated, then a message noting that no better offer can be generated is sent either to the chat server or to the applicant directly.
  • Once a counter offer has been defined or it has been determined that no counter offer that improves the unacceptable terms can be generated, the applicant is notified of the counter offer terms. In different embodiments, notification may be accomplished in various ways. For example, in one embodiment, a new offer page is generated in the application server based on data written to the application database by the application server. In the embodiment where the application server is split into a web server and a counter offer server, the counter offer server writes data to the application database and the web server generates a counter offer page based on the data written to the application database. In addition, the application server also provides information to the chat server indicating what counter offer, if any, has been generated. The customer service agent then discusses the counter offer with the applicant via the chat interface. In order to view the counter offer page generated by the web server, the applicant is asked to refresh his browser. Refreshing the browser causes the offer page to be requested from the web server and the web server responds with the counter offer page. In one embodiment, a button labeled “view offer” is provided on the displayed page. When the button is selected, the page is downloaded again and any changes are then viewed by the user.
  • In other embodiments, the displaying of the counter offer page to the applicant is handled somewhat differently. In one embodiment, the chat server enables the display of the page through the applicant's browser automatically, without requiring the applicant to refresh the screen. This can be accomplished in a variety of ways. In one embodiment, the chat server writes a variable to a memory location that the browser checks periodically. When the browser checks the location and finds a variable indicating that the counter offer page should be downloaded, the browser automatically refreshes itself. The applet that enables the browser to check the location and refresh itself may be used in some cases but not others. When such an applet is not used, the process of instructing the applicant through the chat interface to refresh his own browser or to select a button to view the offer may be implemented.
  • FIG. 25 is a flowchart illustrating a process implemented on a counter offer server to generate and confirm a new offer for display to the applicant. The process starts at 11100. In a step 11110, the counter offer server receives a chat generated term to change. As described above, the term can be identified based on chat by a customer service agent or the term can be automatically determined by analysis of the chat provided by the applicant or the term can be identified using a pick list provided to the applicant. In a step 11120, a new offer is selected from an offer set included in the offer strategy being used for the applicant. As described above, in some embodiments, a new offer is actually calculated based on information provided by the applicant such as a requested credit limit. Next, in a step 11130, the new offer is displayed to the customer service agent. The customer service agent then communicates with the applicant about the new offer to determine the applicant's interest. The customer service agent then confirms to the counter offer server that the new offer is to be shown to the applicant. The confirmation is received in step 11140 and in a step 11150, the counter offer server confirms the new offer in the data base so that it is ready to be displayed when the applicant's browser refreshes. The process then ends at 11160.
  • In some embodiments, the new offer is confirmed in the database concurrent with it being displayed to the customer service agent. Then, whenever the applicant's browser refreshes, the counter offer will be displayed. In some embodiments, it is desired that the display of the counter offer not be enabled until customer service agent has an opportunity to chat with the applicant about the new offer and confirm that display is appropriate.
  • FIG. 26 is a flowchart illustrating a process implemented on the web server portion of the application server for the purpose of displaying a new counter offer to the applicant. The process starts at 11200. In a step 11210, the web server receives a refresh request from the applicant's browser. Next, in a step 11220, the counter offer parameters are retrieved from the application data base and a web page including the counter offer is generated. Then in a step 11230, the counter offer page is sent to the browser. The process ends at 11240.
  • FIG. 27 is a flow chart illustrating a process used in one embodiment to automatically generate a refresh on the applicant's browser. The process starts at 11300. In a step 11310, a request is received for a different offer from the customer service agent. The new offer is determined in a step 11320. The terms of the new offer are communicated to the customer service agent in step 11330. In a step 11340, the customer service agent describes the offer to the user. Then, in a step 11350, the customer service agent receives an indication that the user wants to view the new offer. The customer service agent then sends a message to the user in step 11360 that causes a refresh to be activated. As described above, the message may include writing a certain value to a defined memory location that is periodically examined by the browser for the purpose of determining whether a refresh has been requested by the customer service agent. Once one refresh is generated in this manner, the value that the browser looks for may be incremented so that each time it finds the same value, a new refresh is not generated. The process ends at 11370.
  • A system and method for activating a chat interface with a customer service agent that has access to information about an application for credit has been described. In one embodiment, the chat interface is used to obtain information about why an applicant is rejecting an offer of credit and to identify unacceptable terms. Those unacceptable terms are communicated to a counter offer server and the counter offer server generates a new offer that improves the unacceptable term. The new offer is communicated to the applicant using the chat interface and a web page showing the new offer with an opportunity to accept the offer is displayed to the applicant when the applicant's browser is refreshed.
  • Although the foregoing invention has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. It should be noted that there are many alternative ways of implementing both the process and apparatus of the present invention. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims (7)

1. A method implemented on one or more computers for providing approval of credit over a network, comprising:
receiving via a computer network applicant data from an applicant for a credit application;
prior to obtaining credit report data from a credit bureau for the applicant, determining compliance of the applicant with one or more one or more requirements, the one or more requirements comprising a duplicate check comprising comparing one or more elements of the applicant data with data previously submitted by previous applicants;
transmitting electronically to applicant a determination to decline approval for credit to the applicant if the applicant data fails to meet one or more of the one or more requirements;
if the applicant is not declined:
processing one or more elements of the applicant data into a predetermined electronic form;
electronically transmitting the one or more elements of applicant data in the predetermined electronic form to a credit bureau for obtaining a credit report from a credit bureau for the applicant;
receiving electronically the credit report data from a credit bureau for the applicant; and
determining, without intervention of a human, whether to approve or reject the applicant based for credit based at least in part on the credit report data; and
if it is determined to approve the applicant for credit, communicating electronically to the applicant that the applicant has been approved for credit.
2. The method of claim 1, wherein the determination of whether to approve the applicant for credit occurs in real time.
3. A system for providing approval of credit over a network implemented on one or more computer processors, comprising:
an application engine configured to obtain applicant data from an applicant;
an address parser configured to format the applicant data into a form suitable for directly obtaining a credit report from a credit bureau for the applicant; and
an underwriter module configured to:
determine whether to continue to process or to reject the applicant based on the applicant data prior to obtaining a credit report from a credit bureau for the applicant, said determining whether to continue to process comprising:
checking based on the applicant data entered by the applicant and prior to obtaining a credit report whether some or all of the applicant data is a duplicate of applicant data previously entered by the applicant; and
declining the applicant, in the event it is determined that the applicant data is a duplicate of applicant data previously entered by the applicant after a predetermined duplication cutoff date; and
obtain, in the event it is determined based on the applicant data to process the applicant, a credit report having credit report data from a credit bureau for the applicant;
determine whether to accept the applicant using the credit report data; and,
communicate, if it is determined to accept the applicant for credit, to the applicant that the applicant has been approved for credit.
4. The system of claim 3, wherein the determination of whether to accept the applicant for credit occurs in real time.
5. A computer readable medium having program code embodied therein for providing approval of credit over a network, which, when read by a computer, causes the computer to perform a process, the program code comprising:
program code for receiving via a computer network applicant data from an applicant for a credit application;
program code for determining, prior to obtaining credit report data from a credit bureau for the credit application, compliance of the applicant data with one or more one or more requirements, the one or more requirements comprising a duplicate check comprising comparing automatically one or more elements of the applicant data with data previously submitted by applicants;
program code for declining approval for credit to the applicant if the applicant data fails to meet one or more of the one or more requirements;
program code for, if the applicant is not declined:
processing automatically one or more elements of the applicant data into a predetermined electronic form;
electronically transmitting the one or more elements of applicant data in the predetermined electronic form to a credit bureau for obtaining a credit report from a credit bureau for the applicant;
receiving electronically a credit report having credit report data from a credit bureau for the applicant; and
determining automatically, without intervention of a human, whether to accept or reject the applicant for credit based at least in part on the credit report data; and
program code for communicating, if it is determined to accept the applicant for credit, to the applicant that the applicant has been approved for credit.
6. A computer system, the computer system comprising:
means for receiving via a computer network applicant data from an applicant for a credit application;
means for determining, prior to obtaining a credit report from a credit bureau for the credit application, compliance of the applicant with one or more requirements, the means for determining compliance with one or more requirements including means for determining whether applicant has previously made application for credit within a predetermined period of time;
means for processing automatically, if the applicant is in compliance with the one or more requirements, one or more elements of the applicant data into a predetermined electronic form and automatically electronically transmitting to a credit bureau for obtaining a credit report from a credit bureau for the applicant;
means for receiving electronically a credit report having credit report data from a credit bureau for the applicant;
decision means for determining, without intervention of a human, whether to accept or reject the applicant for credit based at least in part on the credit report data; and
means for communicating automatically with the applicant the determination of the decision means.
7. The computer system of claim 6, wherein the decisions means makes the determination in real time.
US11/932,498 1998-11-03 2007-10-31 Method and Apparatus for Real Time Online Credit Approval Abandoned US20080270295A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/932,498 US20080270295A1 (en) 1998-11-03 2007-10-31 Method and Apparatus for Real Time Online Credit Approval
US13/458,328 US20120215682A1 (en) 1998-11-03 2012-04-27 Method and apparatus for real time online credit approval

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US09/185,201 US6405181B2 (en) 1998-11-03 1998-11-03 Method and apparatus for real time on line credit approval
US09/595,601 US6795812B1 (en) 1998-11-03 2000-06-15 Implementing a counter offer for an on line credit card application
US10/901,715 US20050004864A1 (en) 2000-06-15 2004-07-28 Implementing a counter offer for an on line credit card application
US11/932,498 US20080270295A1 (en) 1998-11-03 2007-10-31 Method and Apparatus for Real Time Online Credit Approval

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/901,715 Continuation US20050004864A1 (en) 1998-11-03 2004-07-28 Implementing a counter offer for an on line credit card application

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/458,328 Continuation US20120215682A1 (en) 1998-11-03 2012-04-27 Method and apparatus for real time online credit approval

Publications (1)

Publication Number Publication Date
US20080270295A1 true US20080270295A1 (en) 2008-10-30

Family

ID=22680019

Family Applications (3)

Application Number Title Priority Date Filing Date
US09/185,201 Expired - Lifetime US6405181B2 (en) 1998-11-03 1998-11-03 Method and apparatus for real time on line credit approval
US11/932,498 Abandoned US20080270295A1 (en) 1998-11-03 2007-10-31 Method and Apparatus for Real Time Online Credit Approval
US13/458,328 Abandoned US20120215682A1 (en) 1998-11-03 2012-04-27 Method and apparatus for real time online credit approval

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US09/185,201 Expired - Lifetime US6405181B2 (en) 1998-11-03 1998-11-03 Method and apparatus for real time on line credit approval

Family Applications After (1)

Application Number Title Priority Date Filing Date
US13/458,328 Abandoned US20120215682A1 (en) 1998-11-03 2012-04-27 Method and apparatus for real time online credit approval

Country Status (5)

Country Link
US (3) US6405181B2 (en)
EP (1) EP1138009A4 (en)
AU (1) AU2143600A (en)
CA (1) CA2347133A1 (en)
WO (1) WO2000026831A1 (en)

Cited By (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050004864A1 (en) * 2000-06-15 2005-01-06 Nextcard Inc. Implementing a counter offer for an on line credit card application
US20080052377A1 (en) * 2006-07-11 2008-02-28 Robert Light Web-Based User-Dependent Customer Service Interaction with Co-Browsing
US20090119181A1 (en) * 2007-11-07 2009-05-07 At&T Knowledge Ventures, L.P. Point of sale transaction processing
US7552080B1 (en) 2001-03-09 2009-06-23 Nextcard, Llc Customized credit offer strategy based on terms specified by an applicant
US20100169444A1 (en) * 2007-07-11 2010-07-01 International Business Machines Corporation Method, system and program product for assigning a responder to a requester in a collaborative environment
US7756781B2 (en) 1998-11-03 2010-07-13 Nextcard, Llc Method and apparatus for a verifiable on line rejection of an applicant for credit
US20110166987A1 (en) * 2008-09-28 2011-07-07 Alibaba Group Holding Limited Evaluating Loan Access Using Online Business Transaction Data
US8010422B1 (en) 1998-11-03 2011-08-30 Nextcard, Llc On-line balance transfers
US8364588B2 (en) 2007-05-25 2013-01-29 Experian Information Solutions, Inc. System and method for automated detection of never-pay data sets
US8412593B1 (en) 2008-10-07 2013-04-02 LowerMyBills.com, Inc. Credit card matching
US8452611B1 (en) 2004-09-01 2013-05-28 Search America, Inc. Method and apparatus for assessing credit for healthcare patients
US8464939B1 (en) 2007-12-14 2013-06-18 Consumerinfo.Com, Inc. Card registry systems and methods
US8606694B2 (en) 2010-07-02 2013-12-10 Experian Credit Advisors, Inc. Online registration system for CROA-compliant credit advice services
US8626646B2 (en) 2006-10-05 2014-01-07 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US8738732B2 (en) 2005-09-14 2014-05-27 Liveperson, Inc. System and method for performing follow up based on user interactions
US8738516B1 (en) 2011-10-13 2014-05-27 Consumerinfo.Com, Inc. Debt services candidate locator
US8762313B2 (en) 2008-07-25 2014-06-24 Liveperson, Inc. Method and system for creating a predictive model for targeting web-page to a surfer
US8799200B2 (en) 2008-07-25 2014-08-05 Liveperson, Inc. Method and system for creating a predictive model for targeting webpage to a surfer
US8799148B2 (en) 2006-08-31 2014-08-05 Rohan K. K. Chandran Systems and methods of ranking a plurality of credit card offers
US8805941B2 (en) 2012-03-06 2014-08-12 Liveperson, Inc. Occasionally-connected computing interface
US8805844B2 (en) 2008-08-04 2014-08-12 Liveperson, Inc. Expert search
US20140236614A1 (en) * 2013-02-15 2014-08-21 Passport Health Communications, Inc. Financial Triage
US8868448B2 (en) 2000-10-26 2014-10-21 Liveperson, Inc. Systems and methods to facilitate selling of products and services
US8918465B2 (en) 2010-12-14 2014-12-23 Liveperson, Inc. Authentication of service requests initiated from a social networking site
US8930263B1 (en) 2003-05-30 2015-01-06 Consumerinfo.Com, Inc. Credit data analysis
US8930262B1 (en) 2010-11-02 2015-01-06 Experian Technology Ltd. Systems and methods of assisted strategy design
US8943002B2 (en) 2012-02-10 2015-01-27 Liveperson, Inc. Analytics driven engagement
US20150081388A1 (en) * 2013-09-16 2015-03-19 International Business Machines Corporation Customer selection for service offerings
US9106691B1 (en) 2011-09-16 2015-08-11 Consumerinfo.Com, Inc. Systems and methods of identity protection and management
US9147042B1 (en) 2010-11-22 2015-09-29 Experian Information Solutions, Inc. Systems and methods for data verification
US9256904B1 (en) * 2008-08-14 2016-02-09 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US9350598B2 (en) 2010-12-14 2016-05-24 Liveperson, Inc. Authentication of service requests using a communications initiation feature
USD759690S1 (en) 2014-03-25 2016-06-21 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
USD759689S1 (en) 2014-03-25 2016-06-21 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
USD760256S1 (en) 2014-03-25 2016-06-28 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
US9400589B1 (en) 2002-05-30 2016-07-26 Consumerinfo.Com, Inc. Circular rotational interface for display of consumer credit information
US9406085B1 (en) 2013-03-14 2016-08-02 Consumerinfo.Com, Inc. System and methods for credit dispute processing, resolution, and reporting
US9432468B2 (en) 2005-09-14 2016-08-30 Liveperson, Inc. System and method for design and dynamic generation of a web page
US9443268B1 (en) 2013-08-16 2016-09-13 Consumerinfo.Com, Inc. Bill payment and reporting
US9477737B1 (en) 2013-11-20 2016-10-25 Consumerinfo.Com, Inc. Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules
US9558519B1 (en) 2011-04-29 2017-01-31 Consumerinfo.Com, Inc. Exposing reporting cycle information
US9563336B2 (en) 2012-04-26 2017-02-07 Liveperson, Inc. Dynamic user interface customization
US9569797B1 (en) 2002-05-30 2017-02-14 Consumerinfo.Com, Inc. Systems and methods of presenting simulated credit score information
US9607336B1 (en) 2011-06-16 2017-03-28 Consumerinfo.Com, Inc. Providing credit inquiry alerts
US9654541B1 (en) 2012-11-12 2017-05-16 Consumerinfo.Com, Inc. Aggregating user web browsing data
US9672196B2 (en) 2012-05-15 2017-06-06 Liveperson, Inc. Methods and systems for presenting specialized content using campaign metrics
US9690820B1 (en) 2007-09-27 2017-06-27 Experian Information Solutions, Inc. Database system for triggering event notifications based on updates to database records
US9697263B1 (en) 2013-03-04 2017-07-04 Experian Information Solutions, Inc. Consumer data request fulfillment system
US9710852B1 (en) 2002-05-30 2017-07-18 Consumerinfo.Com, Inc. Credit report timeline user interface
US9721147B1 (en) 2013-05-23 2017-08-01 Consumerinfo.Com, Inc. Digital identity
US9767212B2 (en) 2010-04-07 2017-09-19 Liveperson, Inc. System and method for dynamically enabling customized web content and applications
US9819561B2 (en) 2000-10-26 2017-11-14 Liveperson, Inc. System and methods for facilitating object assignments
US9830646B1 (en) 2012-11-30 2017-11-28 Consumerinfo.Com, Inc. Credit score goals and alerts systems and methods
US9853959B1 (en) 2012-05-07 2017-12-26 Consumerinfo.Com, Inc. Storage and maintenance of personal data
US9870589B1 (en) 2013-03-14 2018-01-16 Consumerinfo.Com, Inc. Credit utilization tracking and reporting
US9892417B2 (en) 2008-10-29 2018-02-13 Liveperson, Inc. System and method for applying tracing tools for network locations
US9892457B1 (en) 2014-04-16 2018-02-13 Consumerinfo.Com, Inc. Providing credit data in search results
US10075446B2 (en) 2008-06-26 2018-09-11 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
US10102570B1 (en) 2013-03-14 2018-10-16 Consumerinfo.Com, Inc. Account vulnerability alerts
US10169761B1 (en) 2013-03-15 2019-01-01 ConsumerInfo.com Inc. Adjustment of knowledge-based authentication
US10176233B1 (en) 2011-07-08 2019-01-08 Consumerinfo.Com, Inc. Lifescore
US10255598B1 (en) 2012-12-06 2019-04-09 Consumerinfo.Com, Inc. Credit card account data extraction
US10262364B2 (en) 2007-12-14 2019-04-16 Consumerinfo.Com, Inc. Card registry systems and methods
US10278065B2 (en) 2016-08-14 2019-04-30 Liveperson, Inc. Systems and methods for real-time remote control of mobile applications
US10325314B1 (en) 2013-11-15 2019-06-18 Consumerinfo.Com, Inc. Payment reporting systems
US10373240B1 (en) 2014-04-25 2019-08-06 Csidentity Corporation Systems, methods and computer-program products for eligibility verification
US10586279B1 (en) 2004-09-22 2020-03-10 Experian Information Solutions, Inc. Automated analysis of data to generate prospect notifications based on trigger events
US10621657B2 (en) 2008-11-05 2020-04-14 Consumerinfo.Com, Inc. Systems and methods of credit information reporting
US10664936B2 (en) 2013-03-15 2020-05-26 Csidentity Corporation Authentication systems and methods for on-demand products
US10671749B2 (en) 2018-09-05 2020-06-02 Consumerinfo.Com, Inc. Authenticated access and aggregation database platform
US10685398B1 (en) 2013-04-23 2020-06-16 Consumerinfo.Com, Inc. Presenting credit score information
US10735183B1 (en) 2017-06-30 2020-08-04 Experian Information Solutions, Inc. Symmetric encryption for private smart contracts among multiple parties in a private peer-to-peer network
US10757154B1 (en) 2015-11-24 2020-08-25 Experian Information Solutions, Inc. Real-time event-based notification system
US10869253B2 (en) 2015-06-02 2020-12-15 Liveperson, Inc. Dynamic communication routing based on consistency weighting and routing rules
US10909617B2 (en) 2010-03-24 2021-02-02 Consumerinfo.Com, Inc. Indirect monitoring and reporting of a user's credit data
US10911234B2 (en) 2018-06-22 2021-02-02 Experian Information Solutions, Inc. System and method for a token gateway environment
US10937090B1 (en) 2009-01-06 2021-03-02 Consumerinfo.Com, Inc. Report existence monitoring
US10992593B2 (en) * 2017-10-06 2021-04-27 Bank Of America Corporation Persistent integration platform for multi-channel resource transfers
US20210182828A1 (en) * 2012-11-05 2021-06-17 Mfoundry, Inc. Cloud-based systems and methods for providing consumer financial data
US11157997B2 (en) 2006-03-10 2021-10-26 Experian Information Solutions, Inc. Systems and methods for analyzing data
US11227001B2 (en) 2017-01-31 2022-01-18 Experian Information Solutions, Inc. Massive scale heterogeneous data ingestion and user resolution
US11238656B1 (en) 2019-02-22 2022-02-01 Consumerinfo.Com, Inc. System and method for an augmented reality experience via an artificial intelligence bot
US11315179B1 (en) 2018-11-16 2022-04-26 Consumerinfo.Com, Inc. Methods and apparatuses for customized card recommendations
US11386442B2 (en) 2014-03-31 2022-07-12 Liveperson, Inc. Online behavioral predictor
US11410230B1 (en) 2015-11-17 2022-08-09 Consumerinfo.Com, Inc. Realtime access and control of secure regulated data
US11620403B2 (en) 2019-01-11 2023-04-04 Experian Information Solutions, Inc. Systems and methods for secure data aggregation and computation
US11756009B1 (en) * 2009-08-19 2023-09-12 United Services Automobile Association (Usaa) Apparatuses, methods and systems for a publishing and subscribing platform of depositing negotiable instruments
US11783306B1 (en) 2008-02-07 2023-10-10 United Services Automobile Association (Usaa) Systems and methods for mobile deposit of negotiable instruments
US11797960B1 (en) 2012-01-05 2023-10-24 United Services Automobile Association (Usaa) System and method for storefront bank deposits
US11875314B1 (en) 2006-10-31 2024-01-16 United Services Automobile Association (Usaa) Systems and methods for remote deposit of checks
US11887175B2 (en) 2006-08-31 2024-01-30 Cpl Assets, Llc Automatically determining a personalized set of programs or products including an interactive graphical user interface
US11893628B1 (en) 2010-06-08 2024-02-06 United Services Automobile Association (Usaa) Apparatuses, methods and systems for a video remote deposit capture platform

Families Citing this family (324)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7631343B1 (en) 1993-03-24 2009-12-08 Endgate LLC Down-line transcription system using automatic tracking and revenue collection
US5369704A (en) * 1993-03-24 1994-11-29 Engate Incorporated Down-line transcription system for manipulating real-time testimony
US7249026B1 (en) * 1993-03-24 2007-07-24 Engate Llc Attorney terminal having outline preparation capabilities for managing trial proceedings
US6249775B1 (en) * 1997-07-11 2001-06-19 The Chase Manhattan Bank Method for mortgage and closed end loan portfolio management
US7364068B1 (en) 1998-03-11 2008-04-29 West Corporation Methods and apparatus for intelligent selection of goods and services offered to conferees
US6055513A (en) 1998-03-11 2000-04-25 Telebuyer, Llc Methods and apparatus for intelligent selection of goods and services in telephonic and electronic commerce
US7386485B1 (en) 2004-06-25 2008-06-10 West Corporation Method and system for providing offers in real time to prospective customers
US7437313B1 (en) 1998-03-11 2008-10-14 West Direct, Llc Methods, computer-readable media, and apparatus for offering users a plurality of scenarios under which to conduct at least one primary transaction
US8315909B1 (en) 1998-03-11 2012-11-20 West Corporation Methods and apparatus for intelligent selection of goods and services in point-of-sale commerce
US20020198806A1 (en) * 1998-04-24 2002-12-26 First Data Corporation Systems and methods for accessing and modifying usage parameters associated with a financial transaction account
US20040049452A1 (en) * 2002-09-09 2004-03-11 First Data Corporation Multiple credit line presentation instrument
US7050996B1 (en) * 1998-04-24 2006-05-23 First Data Corporation Method for linking accounts corresponding to different products together to create a group
US20030171992A1 (en) * 1999-04-23 2003-09-11 First Data Corporation System and methods for redeeming rewards associated with accounts
US7076465B1 (en) * 1998-04-24 2006-07-11 First Data Corporation Methods for processing a group of accounts corresponding to different products
JP4426722B2 (en) * 1998-05-19 2010-03-03 ケルシウス,エルエルシー Towel mat with frame member and removably attached membrane
JP2001303934A (en) * 1998-06-23 2001-10-31 Toyota Motor Corp Exhaust emission control device for internal combustion engine
US6405181B2 (en) * 1998-11-03 2002-06-11 Nextcard, Inc. Method and apparatus for real time on line credit approval
US6718313B1 (en) * 1998-11-03 2004-04-06 Next Card, Inc. Integrating live chat into an online credit card application
AU763571B2 (en) 1998-12-23 2003-07-24 Chase Manhattan Bank, The System and method for integrating trading operations including the generation, processing and tracking of and trade documents
US20040019560A1 (en) * 1999-03-12 2004-01-29 Evans Scott L. System and method for debt presentment and resolution
AUPP962599A0 (en) * 1999-04-07 1999-04-29 Liberty Financial Pty Ltd Application apparatus and method
US7539628B2 (en) 2000-03-21 2009-05-26 Bennett James D Online purchasing system supporting buyer affordability screening
US8099359B1 (en) 1999-04-19 2012-01-17 The Western Union Company System and method for issuing negotiable instruments by licensed money transmitter from direct deposits
US7542922B2 (en) * 2000-03-21 2009-06-02 Bennett James D Online purchasing system supporting sellers with affordability screening
US8036941B2 (en) * 2000-03-21 2011-10-11 Bennett James D Online purchasing system supporting lenders with affordability screening
AU2597200A (en) * 1999-04-23 2000-11-10 First Data Resources, Inc. Methods for processing a group of accounts corresponding to different products
US20070055628A1 (en) * 1999-04-23 2007-03-08 First Data Corporation Authorizing transactions associated with accounts
US20030212620A1 (en) * 1999-04-23 2003-11-13 First Data Corporation Systems and methods for authorizing transactions
US7797730B2 (en) * 1999-06-24 2010-09-14 Engate Llc Downline transcription system using automatic tracking and revenue collection
US20020184152A1 (en) * 1999-06-30 2002-12-05 Martin David A. Method and device for preventing check fraud
US7058817B1 (en) 1999-07-02 2006-06-06 The Chase Manhattan Bank System and method for single sign on process for websites with multiple applications and services
US7062462B1 (en) 1999-07-26 2006-06-13 The Chase Manhattan Bank On-line higher education financing system
US7542921B1 (en) 1999-09-30 2009-06-02 Jpmorgan Chase Bank, N.A. Network-based financial planning system and method
US6876991B1 (en) 1999-11-08 2005-04-05 Collaborative Decision Platforms, Llc. System, method and computer program product for a collaborative decision platform
US8793160B2 (en) 1999-12-07 2014-07-29 Steve Sorem System and method for processing transactions
AU2105001A (en) * 1999-12-15 2001-06-25 E-Scoring, Inc. Systems and methods for providing consumers anonymous pre-approved offers from aconsumer-selected group of merchants
US7069234B1 (en) 1999-12-22 2006-06-27 Accenture Llp Initiating an agreement in an e-commerce environment
US7103570B1 (en) * 1999-12-28 2006-09-05 First Data Corporation Merchant account activation system
US7775425B1 (en) * 1999-12-29 2010-08-17 First Data Corporation System and method for approving a limit of check cashing over time
US7593898B1 (en) 1999-12-30 2009-09-22 First Data Corporation Method and system for payment transactions and shipment tracking over the internet
US7613653B2 (en) * 1999-12-30 2009-11-03 First Data Corporation Money order debit from stored value fund
US7177836B1 (en) 1999-12-30 2007-02-13 First Data Corporation Method and system for facilitating financial transactions between consumers over the internet
US7376587B1 (en) 2000-07-11 2008-05-20 Western Union Financial Services, Inc. Method for enabling transfer of funds through a computer network
US8036978B1 (en) * 1999-12-31 2011-10-11 Pitney Bowes Inc. Method of upgrading third party functionality in an electronic fraud management system
US7822656B2 (en) 2000-02-15 2010-10-26 Jpmorgan Chase Bank, N.A. International banking system and method
US6867789B1 (en) 2000-02-15 2005-03-15 Bank One, Delaware, National Association System and method for generating graphical user interfaces
US7421409B1 (en) * 2000-02-16 2008-09-02 International Business Machines Corporation Method and system for identifying teaser surfers with time series credit history
US8504438B2 (en) * 2000-03-21 2013-08-06 James D. Bennett Online purchasing system supporting lenders with affordability screening
US7599879B2 (en) * 2000-03-24 2009-10-06 Jpmorgan Chase Bank, National Association Syndication loan administration and processing system
EP1271370A4 (en) * 2000-03-29 2006-03-22 Riskmonster Com System for anonymity electronic commerce having crediting function and method
US6738740B1 (en) * 2000-05-31 2004-05-18 Kenneth Barash Speech recognition system for interactively gathering and storing verbal information to generate documents
US20100057459A1 (en) * 2000-05-31 2010-03-04 Kenneth Barash Voice recognition system for interactively gathering information to generate documents
US7702580B1 (en) 2000-06-13 2010-04-20 Fannie Mae System and method for mortgage loan pricing, sale and funding
US7593893B1 (en) 2000-06-13 2009-09-22 Fannie Mae Computerized systems and methods for facilitating the flow of capital through the housing finance industry
US6988082B1 (en) 2000-06-13 2006-01-17 Fannie Mae Computerized systems and methods for facilitating the flow of capital through the housing finance industry
US7949600B1 (en) 2000-06-27 2011-05-24 Western Union Financial Services, Inc. Method for facilitating payment of a computerized transaction
EP1312012A4 (en) 2000-07-11 2006-09-06 First Data Corp Wide area network person-to-person payment
US20040199456A1 (en) * 2000-08-01 2004-10-07 Andrew Flint Method and apparatus for explaining credit scores
US7280980B1 (en) * 2000-08-01 2007-10-09 Fair Isaac Corporation Algorithm for explaining credit scores
AU2001282935A1 (en) 2000-08-01 2002-02-13 First Usa Bank, N.A. System and method for transponder-enabled account transactions
US20020038284A1 (en) * 2000-08-08 2002-03-28 Muneyasu Fukunaga Method for electronically setting credits and system therefor
US7555459B2 (en) * 2000-10-02 2009-06-30 International Projects Consultancy Services, Inc. Automated loan processing system and method
AU2002211466A1 (en) * 2000-10-05 2002-04-15 American Express Company System methods and computer program products for offering consumer loans having customized terms for each customer
US7831467B1 (en) 2000-10-17 2010-11-09 Jpmorgan Chase Bank, N.A. Method and system for retaining customer loyalty
US8209257B2 (en) * 2000-10-19 2012-06-26 Peter K. Trzyna System for transfering an inbound communication to one of a plurality of credit-counseling agencies
US7827097B2 (en) * 2000-10-19 2010-11-02 Peter K. Trzyna System for transferring an inbond communication to one of a plurality of credit-counseling agencies
US7295999B1 (en) 2000-12-20 2007-11-13 Jpmorgan Chase Bank, N.A. System and method for determining eligibility and enrolling members in various programs
US7472088B2 (en) * 2001-01-19 2008-12-30 Jpmorgan Chase Bank N.A. System and method for offering a financial product
US8805739B2 (en) 2001-01-30 2014-08-12 Jpmorgan Chase Bank, National Association System and method for electronic bill pay and presentment
CA2333342A1 (en) * 2001-01-31 2002-07-31 Curomax Corporation Automotive finance portal
US7689502B2 (en) * 2001-02-12 2010-03-30 Capital One Financial Corporation System and method for providing extra lines of credit
US7480633B2 (en) * 2001-02-13 2009-01-20 American Express Bank Ltd. Real-time brokerage account application system and method
US7356503B1 (en) * 2001-02-21 2008-04-08 Fair Isaac And Company, Inc. ASP business decision engine
US8078524B2 (en) * 2001-02-22 2011-12-13 Fair Isaac Corporation Method and apparatus for explaining credit scores
US7711635B2 (en) * 2001-02-22 2010-05-04 Fair Isaac Corporation System and method for helping consumers understand and interpret credit scores
US6820802B2 (en) * 2001-02-27 2004-11-23 American Express Travel Related Services Company, Inc. Online card activation system and method
US7895098B2 (en) 2001-03-01 2011-02-22 Jpmorgan Chase Bank, N.A. System and method for measuring and utilizing pooling analytics
US7778920B2 (en) * 2001-03-20 2010-08-17 American Express Travel Related Services Company, Inc. Method and apparatus for providing pre-existing and prospective customers with an immediately accessible account
US8209246B2 (en) * 2001-03-20 2012-06-26 Goldman, Sachs & Co. Proprietary risk management clearinghouse
US8849716B1 (en) 2001-04-20 2014-09-30 Jpmorgan Chase Bank, N.A. System and method for preventing identity theft or misuse by restricting access
US7028052B2 (en) 2001-05-10 2006-04-11 Equifax, Inc. Systems and methods for notifying a consumer of changes made to a credit report
US7542993B2 (en) * 2001-05-10 2009-06-02 Equifax, Inc. Systems and methods for notifying a consumer of changes made to a credit report
US7313546B2 (en) 2001-05-23 2007-12-25 Jp Morgan Chase Bank, N.A. System and method for currency selectable stored value instrument
WO2002099598A2 (en) 2001-06-07 2002-12-12 First Usa Bank, N.A. System and method for rapid updating of credit information
US7266839B2 (en) 2001-07-12 2007-09-04 J P Morgan Chase Bank System and method for providing discriminated content to network users
US7860789B2 (en) 2001-07-24 2010-12-28 Jpmorgan Chase Bank, N.A. Multiple account advanced payment card and method of routing card transactions
US7835919B1 (en) 2001-08-10 2010-11-16 Freddie Mac Systems and methods for home value scoring
US7711574B1 (en) 2001-08-10 2010-05-04 Federal Home Loan Mortgage Corporation (Freddie Mac) System and method for providing automated value estimates of properties as of a specified previous time period
US8020754B2 (en) 2001-08-13 2011-09-20 Jpmorgan Chase Bank, N.A. System and method for funding a collective account by use of an electronic tag
US7269737B2 (en) * 2001-09-21 2007-09-11 Pay By Touch Checking Resources, Inc. System and method for biometric authorization for financial transactions
US7546266B2 (en) * 2001-10-18 2009-06-09 General Electric Company Method, system, and storage medium for pre-screening customers for credit card approval at a point of sale
US8244632B2 (en) * 2001-10-26 2012-08-14 First Data Corporation Automated transfer with stored value
US8374962B2 (en) 2001-10-26 2013-02-12 First Data Corporation Stored value payouts
US7366693B2 (en) * 2001-10-31 2008-04-29 Accenture Global Services Gmbh Dynamic credit management
US7987501B2 (en) 2001-12-04 2011-07-26 Jpmorgan Chase Bank, N.A. System and method for single session sign-on
JP4025544B2 (en) * 2001-12-18 2007-12-19 富士通株式会社 Credit account integration method and program for realizing control of credit account integration in computer
US20100287458A1 (en) * 2002-02-01 2010-11-11 Providian Financial Corporation Method, system and computer program for furnishing information to customer representatives
US7890393B2 (en) 2002-02-07 2011-02-15 Ebay, Inc. Method and system for completing a transaction between a customer and a merchant
US20030154162A1 (en) * 2002-02-11 2003-08-14 Danaher John Thomas Credit report retrieval system including voice-based interface
US20040078318A1 (en) * 2002-02-21 2004-04-22 Miller Hugh I. System and method for facilitating loan provision
US20060074793A1 (en) * 2002-02-22 2006-04-06 Hibbert Errington W Transaction management system
US6799720B2 (en) * 2002-03-26 2004-10-05 First Data Corporation System for forecasting amounts of materials needed for credit card reissue
US20030187781A1 (en) * 2002-03-26 2003-10-02 First Data Corporation Method and system for processing card reissue transactions
US6651884B2 (en) * 2002-03-26 2003-11-25 First Data Corporation System for ranking card reissue transactions
US7962405B2 (en) * 2002-03-27 2011-06-14 First Data Corporation Merchant activation tracking systems and methods
US20030187778A1 (en) * 2002-03-27 2003-10-02 First Data Corporation Merchant application and underwriting systems and methods
US20030229587A1 (en) * 2002-03-27 2003-12-11 First Data Corporation Computerized application and underwriting systems and methods
US20040210498A1 (en) 2002-03-29 2004-10-21 Bank One, National Association Method and system for performing purchase and other transactions using tokens with multiple chips
AU2003230751A1 (en) 2002-03-29 2003-10-13 Bank One, Delaware, N.A. System and process for performing purchase transaction using tokens
US7610229B1 (en) 2002-05-30 2009-10-27 Experian Information Solutions, Inc. System and method for interactively simulating a credit-worthiness score
US7593891B2 (en) * 2003-05-30 2009-09-22 Experian Scorex Llc Credit score simulation
US7386528B2 (en) * 2002-05-31 2008-06-10 American Express Travel Related Services Company, Inc. System and method for acquisition, assimilation and storage of information
US8224723B2 (en) 2002-05-31 2012-07-17 Jpmorgan Chase Bank, N.A. Account opening system, method and computer program product
US20030229553A1 (en) * 2002-06-07 2003-12-11 Phanporn Kongyingyong Automated online underwriting
US7505938B2 (en) * 2002-06-20 2009-03-17 Alliance Data Systems Corporation Interactive voice response quick credit system and associated methods
AU2003237586A1 (en) * 2002-07-08 2004-01-23 Consumer Data Technologies Ltd. Confidential information sharing system
US20040019543A1 (en) * 2002-07-25 2004-01-29 First Data Corporation Systems and methods for non-account based liability reporting
US20040030637A1 (en) * 2002-08-12 2004-02-12 Robison Sharon K. Method for conducting electronic commerce
US20040044541A1 (en) * 2002-08-30 2004-03-04 Capital One Financial Corporation Method of telemarketing supplier oversight
US7409369B1 (en) 2002-09-05 2008-08-05 Capital One Financial Corporation Providing a customer one or more options for increasing a line of credit
US8762262B1 (en) 2002-09-06 2014-06-24 Capital One Financial Corporation Method and system for automatically collecting payment for a credit account
US7058660B2 (en) 2002-10-02 2006-06-06 Bank One Corporation System and method for network-based project management
US20040122736A1 (en) 2002-10-11 2004-06-24 Bank One, Delaware, N.A. System and method for granting promotional rewards to credit account holders
US7797166B1 (en) 2002-10-30 2010-09-14 Federal Home Loan Mortgage Corporation (Freddie Mac) Systems and methods for generating a model for income scoring
US7451095B1 (en) * 2002-10-30 2008-11-11 Freddie Mac Systems and methods for income scoring
US8301493B2 (en) 2002-11-05 2012-10-30 Jpmorgan Chase Bank, N.A. System and method for providing incentives to consumers to share information
AU2003293206A1 (en) * 2002-11-27 2004-06-23 Delta Funding Corporation System and method for facilitating loan provision
US8666879B1 (en) 2002-12-30 2014-03-04 Fannie Mae Method and system for pricing forward commitments for mortgage loans and for buying committed loans
US7742981B2 (en) * 2002-12-30 2010-06-22 Fannie Mae Mortgage loan commitment system and method
AU2003297296A1 (en) * 2002-12-30 2004-07-29 Fannie Mae System and method for creating and tracking agreements for selling loans to a secondary market purchaser
AU2003298688A1 (en) * 2002-12-30 2004-07-29 Fannie Mae System and method for pricing loans in the secondary mortgage market
WO2004061748A1 (en) * 2002-12-30 2004-07-22 Fannie Mae System and method for defining loan products
US7593889B2 (en) * 2002-12-30 2009-09-22 Fannie Mae System and method for processing data pertaining to financial assets
AU2003297295A1 (en) * 2002-12-30 2004-07-29 Fannie Mae System and method of processing data pertaining to financial assets
WO2004061565A2 (en) * 2002-12-30 2004-07-22 Fannie Mae System and method for facilitating sale of a loan to a secondary market purchaser
US20050102226A1 (en) * 2002-12-30 2005-05-12 Dror Oppenheimer System and method of accounting for mortgage related transactions
US20040128230A1 (en) * 2002-12-30 2004-07-01 Fannie Mae System and method for modifying attribute data pertaining to financial assets in a data processing system
US7885889B2 (en) 2002-12-30 2011-02-08 Fannie Mae System and method for processing data pertaining to financial assets
AU2003295807A1 (en) * 2002-12-30 2004-07-29 Fannie Mae System and method for verifying loan data at delivery
US20040126284A1 (en) * 2002-12-31 2004-07-01 Lilly Joseph D. System and method for a combination breath analysis device and credit card
US7472090B1 (en) 2002-12-31 2008-12-30 Capital One Financial Corporation Method and system for providing a higher credit limit to a customer
US8306908B1 (en) * 2002-12-31 2012-11-06 West Corporation Methods and apparatus for intelligent selection of goods and services in telephonic and electronic commerce
US20040158521A1 (en) * 2003-02-06 2004-08-12 First Data Corporation Credit enhancement systems and methods
US10311412B1 (en) 2003-03-28 2019-06-04 Jpmorgan Chase Bank, N.A. Method and system for providing bundled electronic payment and remittance advice
US8117101B1 (en) * 2003-03-28 2012-02-14 Innovis, Inc. Database structure for a consumer reporting agency
US8712857B1 (en) 2003-03-31 2014-04-29 Tuxis Technologies Llc Methods and apparatus for intelligent selection of goods and services in mobile commerce
US20040199458A1 (en) * 2003-04-07 2004-10-07 Thinh Ho System and method for on-line mortgage services
US8626642B2 (en) * 2003-08-22 2014-01-07 Compucredit Intellectual Property Holdings Corp. Iii System and method for dynamically managing a financial account
US20040225545A1 (en) * 2003-05-08 2004-11-11 Turner James E. System and method for offering unsecured consumer credit transactions
US8799121B2 (en) 2003-05-15 2014-08-05 Cantor Index, Llc System and method for managing trading order requests
US8001039B2 (en) * 2003-05-15 2011-08-16 Cantor Index, Llc System and method for establishing and providing access to an online account
US7925577B2 (en) 2003-05-15 2011-04-12 Cantor Index Llc System and method for establishing and providing access to various types of online accounts
US7996297B2 (en) * 2003-05-15 2011-08-09 Cantor Index, Llc System and method for providing access to and managing account activity for an online account
US7835974B2 (en) * 2003-05-15 2010-11-16 Cantor Index, LLC. System and method for managing risk associated with product transactions
US7716113B2 (en) * 2003-05-15 2010-05-11 Cantor Index, Llc System and method for providing an intermediary for a transaction
US20040236647A1 (en) * 2003-05-23 2004-11-25 Ravi Acharya Electronic checkbook register
US8306907B2 (en) 2003-05-30 2012-11-06 Jpmorgan Chase Bank N.A. System and method for offering risk-based interest rates in a credit instrument
US20050010509A1 (en) * 2003-07-11 2005-01-13 Straub Russell Andrew Response management device providing statistical tracking of contacts
US20050010507A1 (en) * 2003-07-11 2005-01-13 Russell Straub Device and method for financial services contact management
US8046298B1 (en) 2003-07-21 2011-10-25 Fannie Mae Systems and methods for facilitating the flow of capital through the housing finance industry
US7668777B2 (en) * 2003-07-25 2010-02-23 Jp Morgan Chase Bank System and method for providing instant-decision, financial network-based payment cards
US6817521B1 (en) * 2003-08-21 2004-11-16 International Business Machines Corporation Credit card application automation system
US8175908B1 (en) 2003-09-04 2012-05-08 Jpmorgan Chase Bank, N.A. Systems and methods for constructing and utilizing a merchant database derived from customer purchase transactions data
US20050055296A1 (en) * 2003-09-08 2005-03-10 Michael Hattersley Method and system for underwriting and servicing financial accounts
US7949594B2 (en) * 2003-09-26 2011-05-24 First Data Corporation Systems and methods for participant controlled communications regarding financial accounts
US20050182713A1 (en) * 2003-10-01 2005-08-18 Giancarlo Marchesi Methods and systems for the auto reconsideration of credit card applications
EP1673686A4 (en) * 2003-10-09 2008-10-01 First American Corelogic Inc Automated financial transaction due diligence systems and methods
US8219487B2 (en) * 2003-10-15 2012-07-10 Blackrock, Inc. System and method for managing credit risk for investment portfolios
US7225982B2 (en) * 2003-11-14 2007-06-05 First Data Corporation Bulk card ordering system and methods
US8015085B2 (en) 2003-11-14 2011-09-06 First Data Corporation System for distributing funds
FR2862454A1 (en) * 2003-11-18 2005-05-20 Atmel Corp RANDOM MODULAR REDUCTION METHOD AND EQUIPMENT THEREFOR
US8489498B1 (en) 2003-12-01 2013-07-16 Fannie Mae System and method for processing a loan
US8458073B2 (en) * 2003-12-02 2013-06-04 Dun & Bradstreet, Inc. Enterprise risk assessment manager system
US7814003B2 (en) 2003-12-15 2010-10-12 Jp Morgan Chase Billing workflow system for crediting charges to entities creating derivatives exposure
US7756778B1 (en) 2003-12-18 2010-07-13 Fannie Mae System and method for tracking and facilitating analysis of variance and recourse transactions
US7146159B1 (en) * 2003-12-23 2006-12-05 Sprint Communications Company L.P. Over-the-air card provisioning system and method
US7657475B1 (en) 2003-12-31 2010-02-02 Fannie Mae Property investment rating system and method
US7822680B1 (en) 2003-12-31 2010-10-26 Fannie Mae System and method for managing data pertaining to a plurality of financial assets for multifamily and housing developments
AU2004316986A1 (en) * 2004-02-23 2005-09-15 Pay Pal Pte Ltd. Verification and authorization of a consumer transaction
US8190517B1 (en) 2004-04-07 2012-05-29 American Express Travel Related Services Company, Inc. System and method for transferring a line of credit balance to a cash account
US20050234789A1 (en) * 2004-04-14 2005-10-20 Czyzewski Nathan T Systems, methods and computer readable media for providing and managing balance transfer accounts
US20050278426A1 (en) * 2004-06-15 2005-12-15 First Data Corporation Systems and methods for merging communications
US8554673B2 (en) 2004-06-17 2013-10-08 Jpmorgan Chase Bank, N.A. Methods and systems for discounts management
US8121944B2 (en) 2004-06-24 2012-02-21 Jpmorgan Chase Bank, N.A. Method and system for facilitating network transaction processing
US8510300B2 (en) 2004-07-02 2013-08-13 Goldman, Sachs & Co. Systems and methods for managing information associated with legal, compliance and regulatory risk
US8442953B2 (en) * 2004-07-02 2013-05-14 Goldman, Sachs & Co. Method, system, apparatus, program code and means for determining a redundancy of information
US8996481B2 (en) 2004-07-02 2015-03-31 Goldman, Sach & Co. Method, system, apparatus, program code and means for identifying and extracting information
US7987124B1 (en) 2004-08-20 2011-07-26 Fannie Mae Method of and system for evaluating an appraisal value associated with a loan
US7970672B2 (en) * 2004-09-01 2011-06-28 Metareward, Inc. Real-time marketing of credit-based goods or services
US7178720B1 (en) 2004-09-30 2007-02-20 West Corporation Methods, computer-readable media, and computer program product for intelligent selection of items encoded onto portable machine-playable entertainment media
US7593892B2 (en) * 2004-10-04 2009-09-22 Standard Chartered (Ct) Plc Financial institution portal system and method
US20070016501A1 (en) 2004-10-29 2007-01-18 American Express Travel Related Services Co., Inc., A New York Corporation Using commercial share of wallet to rate business prospects
US7792732B2 (en) 2004-10-29 2010-09-07 American Express Travel Related Services Company, Inc. Using commercial share of wallet to rate investments
US20070244732A1 (en) * 2004-10-29 2007-10-18 American Express Travel Related Services Co., Inc., A New York Corporation Using commercial share of wallet to manage vendors
US20070226114A1 (en) * 2004-10-29 2007-09-27 American Express Travel Related Services Co., Inc., A New York Corporation Using commercial share of wallet to manage investments
US8204774B2 (en) * 2004-10-29 2012-06-19 American Express Travel Related Services Company, Inc. Estimating the spend capacity of consumer households
US8326672B2 (en) * 2004-10-29 2012-12-04 American Express Travel Related Services Company, Inc. Using commercial share of wallet in financial databases
US7822665B2 (en) 2004-10-29 2010-10-26 American Express Travel Related Services Company, Inc. Using commercial share of wallet in private equity investments
US8086509B2 (en) 2004-10-29 2011-12-27 American Express Travel Related Services Company, Inc. Determining commercial share of wallet
US7788147B2 (en) 2004-10-29 2010-08-31 American Express Travel Related Services Company, Inc. Method and apparatus for estimating the spend capacity of consumers
US8131614B2 (en) * 2004-10-29 2012-03-06 American Express Travel Related Services Company, Inc. Using commercial share of wallet to compile marketing company lists
US20070016500A1 (en) * 2004-10-29 2007-01-18 American Express Travel Related Services Co., Inc. A New York Corporation Using commercial share of wallet to determine insurance risk
US8326671B2 (en) * 2004-10-29 2012-12-04 American Express Travel Related Services Company, Inc. Using commercial share of wallet to analyze vendors in online marketplaces
US8630929B2 (en) 2004-10-29 2014-01-14 American Express Travel Related Services Company, Inc. Using commercial share of wallet to make lending decisions
US8543499B2 (en) 2004-10-29 2013-09-24 American Express Travel Related Services Company, Inc. Reducing risks related to check verification
US7685064B1 (en) 2004-11-30 2010-03-23 Jp Morgan Chase Bank Method and apparatus for evaluating a financial transaction
US8001040B2 (en) 2005-01-25 2011-08-16 Ebay Inc. Computer-implemented method and system for dynamic consumer rating in a transaction
US20060190399A1 (en) * 2005-02-22 2006-08-24 Silverman Milton B Data processing technique for providing a cash rebate in a loan program
US7527195B2 (en) * 2005-04-11 2009-05-05 Bill Me Later, Inc. Method and system for risk management in a transaction
US20060229974A1 (en) * 2005-04-11 2006-10-12 I4 Licensing Llc Method of extending credit to at least one consumer and method of processing a transaction between a consumer and a merchant
US8756099B2 (en) * 2005-04-11 2014-06-17 Bill Me Later, Inc. Consumer processing system and method
US7401731B1 (en) 2005-05-27 2008-07-22 Jpmorgan Chase Bank, Na Method and system for implementing a card product with multiple customized relationships
US20060277139A1 (en) * 2005-06-06 2006-12-07 Poltorak Alexander I System and method for credit account management
US7822682B2 (en) 2005-06-08 2010-10-26 Jpmorgan Chase Bank, N.A. System and method for enhancing supply chain transactions
US20060282375A1 (en) * 2005-06-09 2006-12-14 Valued Services Intellectual Property Management, Credit underwriting for multiple financial transactions
US7801809B1 (en) 2005-06-24 2010-09-21 Fannie Mae System and method for management of delegated real estate project reviews
US20070011083A1 (en) * 2005-07-08 2007-01-11 Bird Alan H System and method of processing asset financing transactions
US8126772B1 (en) 2005-08-15 2012-02-28 Dale LeFebvre Rebate cross-sell network and systems and methods implementing the same
US20070061206A1 (en) * 2005-08-15 2007-03-15 Lefebvre Dale System and method for providing rapid rebate payments
US7925578B1 (en) 2005-08-26 2011-04-12 Jpmorgan Chase Bank, N.A. Systems and methods for performing scoring optimization
US20070061254A1 (en) * 2005-09-15 2007-03-15 Richard Blunck Systems and methods for opening, funding, and managing financial accounts
US8556165B2 (en) * 2005-09-21 2013-10-15 Bank Of America Corporation Method and system for enabling teller presentation of pre-approved credit offers
US20080033852A1 (en) * 2005-10-24 2008-02-07 Megdal Myles G Computer-based modeling of spending behaviors of entities
CA2527538A1 (en) * 2005-11-12 2007-05-14 Matt Celano Method and apparatus for a consumer interactive credit report analysis and score reconciliation adaptive education and counseling system
US8150762B1 (en) * 2005-12-29 2012-04-03 United Services Automobile Association System and method for providing credit
US8489497B1 (en) * 2006-01-27 2013-07-16 Jpmorgan Chase Bank, N.A. Online interactive and partner-enhanced credit card
US7645926B2 (en) * 2006-02-28 2010-01-12 Clennon Wayne Jerrolds Fiddolin
US7747526B1 (en) 2006-03-27 2010-06-29 Fannie Mae System and method for transferring mortgage loan servicing rights
US20070244816A1 (en) * 2006-04-14 2007-10-18 Mustafa Patni Systems and methods for opening, funding, and/or using a financial account, such as a checking account
US20070288359A1 (en) * 2006-04-18 2007-12-13 Susan Amadio Processing of credit applications
US8027888B2 (en) * 2006-08-31 2011-09-27 Experian Interactive Innovation Center, Llc Online credit card prescreen systems and methods
US8484554B2 (en) * 2006-08-31 2013-07-09 Sap Ag Producing a chart
US20080091818A1 (en) * 2006-10-11 2008-04-17 Rmb World Enterprises, Llc System And Method Of Employing Web Services Applications To Obtain Real-Time Information From Distributed Sources
US20080109348A1 (en) * 2006-11-02 2008-05-08 Hsbc Finance Corporation Credit System with Over-Limit Analysis
US7548900B2 (en) * 2006-11-30 2009-06-16 Sap Ag Systems and methods for data management
US8239250B2 (en) * 2006-12-01 2012-08-07 American Express Travel Related Services Company, Inc. Industry size of wallet
US8554669B2 (en) 2007-01-09 2013-10-08 Bill Me Later, Inc. Method and system for offering a credit product by a credit issuer to a consumer at a point-of sale
US8606626B1 (en) 2007-01-31 2013-12-10 Experian Information Solutions, Inc. Systems and methods for providing a direct marketing campaign planning environment
US8606666B1 (en) 2007-01-31 2013-12-10 Experian Information Solutions, Inc. System and method for providing an aggregation tool
US8433648B2 (en) * 2007-02-26 2013-04-30 Bill Me Later, Inc. Method and system for engaging in a transaction between a consumer and a merchant
WO2008118974A1 (en) * 2007-03-26 2008-10-02 Revolution Money Inc. System and method for fluid financial markets
US8285656B1 (en) 2007-03-30 2012-10-09 Consumerinfo.Com, Inc. Systems and methods for data verification
US20090043690A1 (en) * 2007-08-06 2009-02-12 Maclellan Paul System and method for validating indirect financing transactions
US20090048957A1 (en) * 2007-04-02 2009-02-19 Matthew Celano Method and system for financial counseling
US20080272188A1 (en) 2007-05-02 2008-11-06 I4 Commerce Inc. Distributed system for commerce
US7809707B2 (en) * 2007-07-23 2010-10-05 Sap Ag System and method for identifying element usage in a deep element structure
US8219533B2 (en) 2007-08-29 2012-07-10 Enpulz Llc Search engine feedback for developing reliable whois database reference for restricted search operation
US8055671B2 (en) 2007-08-29 2011-11-08 Enpulz, Llc Search engine using world map with whois database search restriction
US8762259B1 (en) * 2007-09-21 2014-06-24 United Services Automobile Association (Usaa) Real-time prescreening for credit offers
US9883381B1 (en) 2007-10-02 2018-01-30 Sprint Communications Company L.P. Providing secure access to smart card applications
US20090099914A1 (en) * 2007-10-16 2009-04-16 Alliance Data Systems Corporation Automated transactional credit system and method for electronic transactions
US7653593B2 (en) 2007-11-08 2010-01-26 Equifax, Inc. Macroeconomic-adjusted credit risk score systems and methods
US8622308B1 (en) 2007-12-31 2014-01-07 Jpmorgan Chase Bank, N.A. System and method for processing transactions using a multi-account transactions device
US7766244B1 (en) 2007-12-31 2010-08-03 Jpmorgan Chase Bank, N.A. System and method for processing transactions using a multi-account transactions device
US8083140B1 (en) 2008-02-05 2011-12-27 Sprint Communications Company L.P. System and method of over-the-air provisioning
US7853520B2 (en) * 2008-02-29 2010-12-14 American Express Travel Related Services Company, Inc. Total structural risk model
US7814008B2 (en) * 2008-02-29 2010-10-12 American Express Travel Related Services Company, Inc. Total structural risk model
US20090222378A1 (en) * 2008-02-29 2009-09-03 American Express Travel Related Services Company, Inc. Total structural risk model
US20090222373A1 (en) * 2008-02-29 2009-09-03 American Express Travel Related Services Company, Inc. Total structural risk model
US20090222380A1 (en) * 2008-02-29 2009-09-03 American Express Travel Related Services Company, Inc Total structural risk model
US7849004B2 (en) * 2008-02-29 2010-12-07 American Express Travel Related Services Company, Inc. Total structural risk model
US20090222376A1 (en) * 2008-02-29 2009-09-03 American Express Travel Related Services Company, Inc. Total structural risk model
US8458083B2 (en) 2008-02-29 2013-06-04 American Express Travel Related Services Company, Inc. Total structural risk model
US20090259585A1 (en) * 2008-04-09 2009-10-15 Kenneth Beirne Event-driven credit offers
US8229911B2 (en) 2008-05-13 2012-07-24 Enpulz, Llc Network search engine utilizing client browser activity information
US8190623B2 (en) 2008-06-05 2012-05-29 Enpulz, L.L.C. Image search engine using image analysis and categorization
US8180788B2 (en) 2008-06-05 2012-05-15 Enpulz, L.L.C. Image search engine employing image correlation
US8171041B2 (en) 2008-05-15 2012-05-01 Enpulz, L.L.C. Support for international search terms
US8250083B2 (en) 2008-05-16 2012-08-21 Enpulz, Llc Support for international search terms—translate as you crawl
US20090287471A1 (en) 2008-05-16 2009-11-19 Bennett James D Support for international search terms - translate as you search
US8832777B2 (en) * 2009-03-02 2014-09-09 Headwater Partners I Llc Adapting network policies based on device service processor configuration
US8719164B2 (en) 2008-06-19 2014-05-06 Bill Me Later, Inc. Method and system for engaging in a transaction between a business entity and a merchant
US20100010930A1 (en) * 2008-07-11 2010-01-14 American Express Travel Related Services Company, Inc. Providing a real time credit score as part of a transaction request
US7991689B1 (en) 2008-07-23 2011-08-02 Experian Information Solutions, Inc. Systems and methods for detecting bust out fraud using credit data
US8706588B1 (en) 2008-10-20 2014-04-22 Sprint Communications Company L.P. System and method of provisioning confidential information via a mobile device
US20100125482A1 (en) * 2008-11-14 2010-05-20 President And Fellows Of Harvard College Contractor Assessment
US8060449B1 (en) 2009-01-05 2011-11-15 Sprint Communications Company L.P. Partially delegated over-the-air provisioning of a secure element
US9980146B2 (en) 2009-01-28 2018-05-22 Headwater Research Llc Communications device with secure data path processing agents
US9572019B2 (en) 2009-01-28 2017-02-14 Headwater Partners LLC Service selection set published to device agent with on-device service selection
US9706061B2 (en) * 2009-01-28 2017-07-11 Headwater Partners I Llc Service design center for device assisted services
US8768845B1 (en) 2009-02-16 2014-07-01 Sprint Communications Company L.P. Electronic wallet removal from mobile electronic devices
US8639920B2 (en) 2009-05-11 2014-01-28 Experian Marketing Solutions, Inc. Systems and methods for providing anonymized user profile data
US20100306072A1 (en) * 2009-05-29 2010-12-02 Bank Of America Corporation Instant financial credit system
US8386381B1 (en) 2009-12-16 2013-02-26 Jpmorgan Chase Bank, N.A. Method and system for detecting, monitoring and addressing data compromises
US8447641B1 (en) 2010-03-29 2013-05-21 Jpmorgan Chase Bank, N.A. System and method for automatically enrolling buyers into a network
US8554631B1 (en) 2010-07-02 2013-10-08 Jpmorgan Chase Bank, N.A. Method and system for determining point of sale authorization
US8589288B1 (en) 2010-10-01 2013-11-19 Jpmorgan Chase Bank, N.A. System and method for electronic remittance of funds
US8484186B1 (en) 2010-11-12 2013-07-09 Consumerinfo.Com, Inc. Personalized people finder
EP2676197B1 (en) 2011-02-18 2018-11-28 CSidentity Corporation System and methods for identifying compromised personally identifiable information on the internet
US8352370B1 (en) 2011-03-28 2013-01-08 Jpmorgan Chase Bank, N.A. System and method for universal instant credit
US8543504B1 (en) 2011-03-30 2013-09-24 Jpmorgan Chase Bank, N.A. Systems and methods for automated invoice entry
US8543503B1 (en) 2011-03-30 2013-09-24 Jpmorgan Chase Bank, N.A. Systems and methods for automated invoice entry
US11030562B1 (en) 2011-10-31 2021-06-08 Consumerinfo.Com, Inc. Pre-data breach monitoring
US8781954B2 (en) 2012-02-23 2014-07-15 American Express Travel Related Services Company, Inc. Systems and methods for identifying financial relationships
US8538869B1 (en) 2012-02-23 2013-09-17 American Express Travel Related Services Company, Inc. Systems and methods for identifying financial relationships
US9477988B2 (en) 2012-02-23 2016-10-25 American Express Travel Related Services Company, Inc. Systems and methods for identifying financial relationships
US8473410B1 (en) 2012-02-23 2013-06-25 American Express Travel Related Services Company, Inc. Systems and methods for identifying financial relationships
US10453128B2 (en) * 2012-10-09 2019-10-22 Communitylend Holdings Inc. System and method for processing loan applications
US10672008B2 (en) 2012-12-06 2020-06-02 Jpmorgan Chase Bank, N.A. System and method for data analytics
US9027109B2 (en) * 2013-02-28 2015-05-05 Citibank, N.A. Methods and systems for accessing account information electronically
US8812387B1 (en) 2013-03-14 2014-08-19 Csidentity Corporation System and method for identifying related credit inquiries
US10643276B1 (en) * 2013-03-15 2020-05-05 Capital One Services, Llc Systems and computer-implemented processes for model-based underwriting
US20160328794A1 (en) * 2013-07-24 2016-11-10 Pitch Point Solutions, Inc. Methods and systems for improved application submissions
US9058626B1 (en) 2013-11-13 2015-06-16 Jpmorgan Chase Bank, N.A. System and method for financial services device usage
US10102536B1 (en) 2013-11-15 2018-10-16 Experian Information Solutions, Inc. Micro-geographic aggregation system
US9529851B1 (en) 2013-12-02 2016-12-27 Experian Information Solutions, Inc. Server architecture for electronic data quality processing
US20150199756A1 (en) * 2014-01-10 2015-07-16 Bank Of America Corporation Linking logic feature
US10262362B1 (en) 2014-02-14 2019-04-16 Experian Information Solutions, Inc. Automatic generation of code for attributes
US20150262304A1 (en) * 2014-03-11 2015-09-17 Victor Eli Velazquez-Gonzalez Obligatory Methods And Systems For Generating Funds for Retirement And Special Needs
US20150287138A1 (en) * 2014-04-08 2015-10-08 Ebay Inc. Extending temporary credit based on risk factors
US9576030B1 (en) 2014-05-07 2017-02-21 Consumerinfo.Com, Inc. Keeping up with the joneses
US10339527B1 (en) 2014-10-31 2019-07-02 Experian Information Solutions, Inc. System and architecture for electronic fraud detection
US10445152B1 (en) 2014-12-19 2019-10-15 Experian Information Solutions, Inc. Systems and methods for dynamic report generation based on automatic modeling of complex data structures
US11151468B1 (en) 2015-07-02 2021-10-19 Experian Information Solutions, Inc. Behavior analysis using distributed representations of event data
US20180060954A1 (en) 2016-08-24 2018-03-01 Experian Information Solutions, Inc. Sensors and system for detection of device movement and authentication of device user based on messaging service data from service provider
US20180096434A1 (en) * 2016-10-05 2018-04-05 The Toronto-Dominion Bank System and Method for Controlling Access to Content to be Displayed on an Electronic Display
US10503394B2 (en) * 2016-10-05 2019-12-10 The Toronto-Dominion Bank System and method for facilitating access to electronic data
CN111340498B (en) * 2017-06-23 2024-03-12 创新先进技术有限公司 Method and device for realizing off-line transaction
US10699028B1 (en) 2017-09-28 2020-06-30 Csidentity Corporation Identity security architecture systems and methods
US11121870B2 (en) * 2017-10-12 2021-09-14 Mastercard International Incorporated Method and system for interacting public and private blockchains with controlled participation
US10896472B1 (en) 2017-11-14 2021-01-19 Csidentity Corporation Security and identity verification system and architecture
US10529018B1 (en) 2018-07-16 2020-01-07 Capital One Services, Llc Credit scoring and pre-approval engine integration
US10963434B1 (en) 2018-09-07 2021-03-30 Experian Information Solutions, Inc. Data architecture for supporting multiple search models
US11880377B1 (en) 2021-03-26 2024-01-23 Experian Information Solutions, Inc. Systems and methods for entity resolution

Citations (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4736294A (en) * 1985-01-11 1988-04-05 The Royal Bank Of Canada Data processing methods and apparatus for managing vehicle financing
US4860341A (en) * 1987-06-02 1989-08-22 Motorola, Inc. Radiotelephone credit card call approval synchronization
US5187735A (en) * 1990-05-01 1993-02-16 Tele Guia Talking Yellow Pages, Inc. Integrated voice-mail based voice and information processing system
US5221838A (en) * 1990-12-24 1993-06-22 Motorola, Inc. Electronic wallet
US5235519A (en) * 1991-02-27 1993-08-10 Atsushi Miura Card vending machine
US5239462A (en) * 1992-02-25 1993-08-24 Creative Solutions Groups, Inc. Method and apparatus for automatically determining the approval status of a potential borrower
US5285382A (en) * 1991-02-25 1994-02-08 Keyosk Corporation System and method for processing credit and debit card validity and funds transactions from vending machines and similar terminals
US5387783A (en) * 1992-04-30 1995-02-07 Postalsoft, Inc. Method and apparatus for inserting and printing barcoded zip codes
US5481647A (en) * 1991-03-22 1996-01-02 Raff Enterprises, Inc. User adaptable expert system
US5491817A (en) * 1993-05-25 1996-02-13 Bell Communications Research Inc. Linking system and method for accessing directory information about an object in one context when information in another context is known
US5604341A (en) * 1995-03-13 1997-02-18 At&T Global Information Solutions Company ATM as video conferencing station
US5611052A (en) * 1993-11-01 1997-03-11 The Golden 1 Credit Union Lender direct credit evaluation and loan processing system
US5659165A (en) * 1995-07-24 1997-08-19 Citibank. N.A. Customer-directed, automated process for transferring funds between accounts via a communications network
US5724155A (en) * 1993-12-30 1998-03-03 Olympus Optical Co., Ltd. Electronic imaging system
US5727163A (en) * 1995-03-30 1998-03-10 Amazon.Com, Inc. Secure method for communicating credit card data when placing an order on a non-secure network
US5732400A (en) * 1995-01-04 1998-03-24 Citibank N.A. System and method for a risk-based purchase of goods
US5734659A (en) * 1984-06-01 1998-03-31 Digital Equipment Corporation Computer network having a virtual circuit message carrying a plurality of session messages
US5745654A (en) * 1996-02-13 1998-04-28 Hnc Software, Inc. Fast explanations of scored observations
US5748755A (en) * 1992-05-08 1998-05-05 Moore Business Forms, Inc. Picture checks
US5761640A (en) * 1995-12-18 1998-06-02 Nynex Science & Technology, Inc. Name and address processor
US5764916A (en) * 1996-09-27 1998-06-09 Ichat, Inc. Method and apparatus for real time communication over a computer network
US5774882A (en) * 1992-03-12 1998-06-30 Keen; Regina D. Credit approval system
US5774883A (en) * 1995-05-25 1998-06-30 Andersen; Lloyd R. Method for selecting a seller's most profitable financing program
US5778164A (en) * 1993-09-24 1998-07-07 Eastman Kodak Company System for custom imprinting a variety of articles with images obtained from a variety of different sources
US5857079A (en) * 1994-12-23 1999-01-05 Lucent Technologies Inc. Smart card for automatic financial records
US5866889A (en) * 1995-06-07 1999-02-02 Citibank, N.A. Integrated full service consumer banking system and system and method for opening an account
US5870721A (en) * 1993-08-27 1999-02-09 Affinity Technology Group, Inc. System and method for real time loan approval
US5878404A (en) * 1996-10-08 1999-03-02 Mechanics Savings Bank System and method for managing the amortization of a loan
US5878403A (en) * 1995-09-12 1999-03-02 Cmsi Computer implemented automated credit application analysis and decision routing system
US5911136A (en) * 1987-04-15 1999-06-08 Proprietary Financial Products, Inc. System for prioritized operation of a personal financial account comprising liabilities and investment assets
US5920847A (en) * 1993-11-01 1999-07-06 Visa International Service Association Electronic bill pay system
US5930776A (en) * 1993-11-01 1999-07-27 The Golden 1 Credit Union Lender direct credit evaluation and loan processing system
US6014645A (en) * 1996-04-19 2000-01-11 Block Financial Corporation Real-time financial card application system
US6029890A (en) * 1998-06-22 2000-02-29 Austin; Frank User-Specified credit card system
US6044360A (en) * 1996-04-16 2000-03-28 Picciallo; Michael J. Third party credit card
US6049784A (en) * 1997-12-16 2000-04-11 Capital One Financial Corporation Method for creating and managing a lease agreement
US6058428A (en) * 1997-12-05 2000-05-02 Pictra, Inc. Method and apparatus for transferring digital images on a network
US6064987A (en) * 1997-03-21 2000-05-16 Walker Digital, Llc Method and apparatus for providing and processing installment plans at a terminal
US6070149A (en) * 1998-07-02 2000-05-30 Activepoint Ltd. Virtual sales personnel
US6070798A (en) * 1997-02-21 2000-06-06 Nethery; Kee Purchaser generated transaction recording and negotiable instrument payment system
US6085126A (en) * 1997-11-21 2000-07-04 St. Paul Stamp Works, Inc. System and method for preparing custom designs for multiple types of imprintable media
US6085195A (en) * 1998-06-02 2000-07-04 Xstasis, Llc Internet photo booth
US6088686A (en) * 1995-12-12 2000-07-11 Citibank, N.A. System and method to performing on-line credit reviews and approvals
US6092057A (en) * 1997-12-12 2000-07-18 Commstar, Inc. Unattended POS system for automatic control of bank system rejections
US6182124B1 (en) * 1998-01-30 2001-01-30 International Business Machines Corporation Token-based deadline enforcement system for electronic document submission
US6185543B1 (en) * 1998-05-15 2001-02-06 Marketswitch Corp. Method and apparatus for determining loan prepayment scores
US6192380B1 (en) * 1998-03-31 2001-02-20 Intel Corporation Automatic web based form fill-in
US6199079B1 (en) * 1998-03-09 2001-03-06 Junglee Corporation Method and system for automatically filling forms in an integrated network based transaction environment
US6202053B1 (en) * 1998-01-23 2001-03-13 First Usa Bank, Na Method and apparatus for generating segmentation scorecards for evaluating credit risk of bank card applicants
US6202155B1 (en) * 1996-11-22 2001-03-13 Ubiq Incorporated Virtual card personalization system
US6208979B1 (en) * 1998-11-09 2001-03-27 E-Fin, Llc Computer-driven information management system for selectively matching credit applicants with money lenders through a global communications network
US6233565B1 (en) * 1998-02-13 2001-05-15 Saranac Software, Inc. Methods and apparatus for internet based financial transactions with evidence of payment
US6240396B1 (en) * 1996-09-04 2001-05-29 Priceline.Com Incorporated Conditional purchase offer management system for event tickets
US6267292B1 (en) * 1997-06-13 2001-07-31 Walker Digital, Llc Method and apparatus for funds and credit line transfers
US6343279B1 (en) * 1998-08-26 2002-01-29 American Management Systems, Inc. System integrating credit card transactions into a financial management system
US20020016731A1 (en) * 2000-05-26 2002-02-07 Benjamin Kupersmit Method and system for internet sampling
US6349290B1 (en) * 1998-06-30 2002-02-19 Citibank, N.A. Automated system and method for customized and personalized presentation of products and services of a financial institution
US20020023051A1 (en) * 2000-03-31 2002-02-21 Kunzle Adrian E. System and method for recommending financial products to a customer based on customer needs and preferences
US20020029188A1 (en) * 1999-12-20 2002-03-07 Schmid Stephen J. Method and apparatus to facilitate competitive financing activities among myriad lenders on behalf of one borrower
US6356909B1 (en) * 1999-08-23 2002-03-12 Proposal Technologies Network, Inc. Web based system for managing request for proposal and responses
US20020035543A1 (en) * 1998-04-27 2002-03-21 Aurora Wireless Technologies, Ltd. System and method for detecting high credit risk customers
US6374230B1 (en) * 1997-03-12 2002-04-16 Walker Digital, Llc Method, apparatus and program for customizing credit accounts
US6385594B1 (en) * 1998-05-08 2002-05-07 Lendingtree, Inc. Method and computer network for co-ordinating a loan over the internet
US20020055906A1 (en) * 1998-03-11 2002-05-09 Katz Ronald A. Methods and apparatus for intelligent selection of goods and services in telephonic and electronic commerce
US6389541B1 (en) * 1998-05-15 2002-05-14 First Union National Bank Regulating access to digital content
US20020067500A1 (en) * 1997-05-12 2002-06-06 Yoshikazu Yokomizo Method of and system for editing images
US6405181B2 (en) * 1998-11-03 2002-06-11 Nextcard, Inc. Method and apparatus for real time on line credit approval
US6505176B2 (en) * 1998-06-12 2003-01-07 First American Credit Management Solutions, Inc. Workflow management system for an automated credit application system
US6510418B1 (en) * 1996-09-04 2003-01-21 Priceline.Com Incorporated Method and apparatus for detecting and deterring the submission of similar offers in a commerce system
US6513018B1 (en) * 1994-05-05 2003-01-28 Fair, Isaac And Company, Inc. Method and apparatus for scoring the likelihood of a desired performance result
US6516421B1 (en) * 1999-10-27 2003-02-04 International Business Machines Corporation Method and means for adjusting the timing of user-activity-dependent changes of operational state of an apparatus
US6535492B2 (en) * 1999-12-01 2003-03-18 Genesys Telecommunications Laboratories, Inc. Method and apparatus for assigning agent-led chat sessions hosted by a communication center to available agents based on message load and agent skill-set
US20030055778A1 (en) * 1998-10-24 2003-03-20 Michael David Erlanger Data processing system for providing an efficient market for loans and lines of credit
US6542936B1 (en) * 1997-07-03 2003-04-01 Ipac Acquisition Subsidiary I, Llc System for creating messages including image information
US6567791B2 (en) * 1998-11-03 2003-05-20 Nextcard, Inc. Method and apparatus for a verifiable on line rejection of an application for credit
US20030105725A1 (en) * 1994-11-28 2003-06-05 Ned Hoffman Tokenless identification system for authorization of electronic transactions and electronic transmissions
US6584467B1 (en) * 1995-12-08 2003-06-24 Allstate Insurance Company Method and apparatus for obtaining data from vendors in real time
US6598030B1 (en) * 1997-05-27 2003-07-22 Visa International Service Association Method and apparatus for pattern generation
US20040019558A1 (en) * 1998-07-22 2004-01-29 Mcdonald Russell W. Mortgage loan data collection method and apparatus for a financial planning originator and/or financial institution originator of a mortgage loan
US20040064412A1 (en) * 1998-06-22 2004-04-01 Bank One, Delaware, National Association Debit purchasing of stored value card for use by and/or delivery to others
US6718313B1 (en) * 1998-11-03 2004-04-06 Next Card, Inc. Integrating live chat into an online credit card application
US6766302B2 (en) * 1998-11-09 2004-07-20 Joseph Bach Method and apparatus for advertisement
US20050004864A1 (en) * 2000-06-15 2005-01-06 Nextcard Inc. Implementing a counter offer for an on line credit card application
US20060036543A1 (en) * 1998-04-24 2006-02-16 First Data Corporation Creating groups of linked accounts
US7020631B2 (en) * 1997-07-11 2006-03-28 The Chase Manhattan Bank Method for mortgage and closed end loan portfolio management
US20060153350A1 (en) * 1996-06-05 2006-07-13 David Felger Method of billing a communication session conducted over a computer network
US7194436B2 (en) * 1998-08-10 2007-03-20 Ford Motor Company Method and system for internet based financial auto credit application
US20070072585A1 (en) * 1992-11-12 2007-03-29 Lightbridge, Inc. Apparatus and Method for Credit Based Management of Telecommunication Activity
US20070124214A1 (en) * 1998-06-26 2007-05-31 American Express Travel Related Services Company, Inc. Stored value transaction system including an integrated database server
US7230927B1 (en) * 1999-12-07 2007-06-12 Aspect Software, Inc. Non-blocking expandable call center architecture
US20080021816A1 (en) * 2000-06-15 2008-01-24 Nextcard, Llc Integrating Live Chat Into an Online Credit Card Application
US7395239B1 (en) * 1999-07-19 2008-07-01 American Business Financial System and method for automatically processing loan applications

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6289319B1 (en) * 1984-05-24 2001-09-11 Lawrence B. Lockwood Automatic business and financial transaction processing system
JPH03180968A (en) * 1989-12-08 1991-08-06 Hitachi Ltd Data base retrieving method and formated document outputting method using the retrieving method
US5262941A (en) * 1990-03-30 1993-11-16 Itt Corporation Expert credit recommendation method and system
US5940811A (en) * 1993-08-27 1999-08-17 Affinity Technology Group, Inc. Closed loop financial transaction method and apparatus
US5704029A (en) * 1994-05-23 1997-12-30 Wright Strategies, Inc. System and method for completing an electronic form
US5797133A (en) * 1994-08-31 1998-08-18 Strategic Solutions Group, Inc Method for automatically determining the approval status of a potential borrower
US5696907A (en) * 1995-02-27 1997-12-09 General Electric Company System and method for performing risk and credit analysis of financial service applications
US5819236A (en) * 1995-06-12 1998-10-06 Carreker-Antinori, Inc. System and method for providing advance notification of potential presentment returns due to account restrictions
US5987434A (en) 1996-06-10 1999-11-16 Libman; Richard Marc Apparatus and method for transacting marketing and sales of financial products
US5819291A (en) * 1996-08-23 1998-10-06 General Electric Company Matching new customer records to existing customer records in a large business database using hash key
US5966699A (en) * 1996-10-11 1999-10-12 Zandi; Richard System and method for conducting loan auction over computer network
US6603487B1 (en) * 1996-10-31 2003-08-05 International Business Machines Corporation System for electronically developing and processing a document
US5950179A (en) 1996-12-03 1999-09-07 Providian Financial Corporation Method and system for issuing a secured credit card
US5819029A (en) * 1997-02-20 1998-10-06 Brittan Communications International Corp. Third party verification system and method
US5832465A (en) 1997-04-07 1998-11-03 General Electric Company Method for building a self-learning evidential reasoning system
US6119103A (en) 1997-05-27 2000-09-12 Visa International Service Association Financial risk prediction systems and methods therefor
US6112190A (en) * 1997-08-19 2000-08-29 Citibank, N.A. Method and system for commercial credit analysis
US5940812A (en) * 1997-08-19 1999-08-17 Loanmarket Resources, L.L.C. Apparatus and method for automatically matching a best available loan to a potential borrower via global telecommunications network
US5995947A (en) * 1997-09-12 1999-11-30 Imx Mortgage Exchange Interactive mortgage and loan information and real-time trading system
US6272506B1 (en) * 1997-09-12 2001-08-07 Doxis, Llc Computerized verification form processing system and method
US5960411A (en) * 1997-09-12 1999-09-28 Amazon.Com, Inc. Method and system for placing a purchase order via a communications network
JP4077909B2 (en) * 1997-10-03 2008-04-23 富士通株式会社 Form processing device
US6311169B2 (en) * 1998-06-11 2001-10-30 Consumer Credit Associates, Inc. On-line consumer credit data reporting system

Patent Citations (99)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5734659A (en) * 1984-06-01 1998-03-31 Digital Equipment Corporation Computer network having a virtual circuit message carrying a plurality of session messages
US4736294A (en) * 1985-01-11 1988-04-05 The Royal Bank Of Canada Data processing methods and apparatus for managing vehicle financing
US5911136A (en) * 1987-04-15 1999-06-08 Proprietary Financial Products, Inc. System for prioritized operation of a personal financial account comprising liabilities and investment assets
US5911135A (en) * 1987-04-15 1999-06-08 Proprietary Financial Products, Inc. System for managing financial accounts by a priority allocation of funds among accounts
US4860341A (en) * 1987-06-02 1989-08-22 Motorola, Inc. Radiotelephone credit card call approval synchronization
US5187735A (en) * 1990-05-01 1993-02-16 Tele Guia Talking Yellow Pages, Inc. Integrated voice-mail based voice and information processing system
US5221838A (en) * 1990-12-24 1993-06-22 Motorola, Inc. Electronic wallet
US5285382A (en) * 1991-02-25 1994-02-08 Keyosk Corporation System and method for processing credit and debit card validity and funds transactions from vending machines and similar terminals
US5235519A (en) * 1991-02-27 1993-08-10 Atsushi Miura Card vending machine
US5481647A (en) * 1991-03-22 1996-01-02 Raff Enterprises, Inc. User adaptable expert system
US5239462A (en) * 1992-02-25 1993-08-24 Creative Solutions Groups, Inc. Method and apparatus for automatically determining the approval status of a potential borrower
US5774882A (en) * 1992-03-12 1998-06-30 Keen; Regina D. Credit approval system
US5387783A (en) * 1992-04-30 1995-02-07 Postalsoft, Inc. Method and apparatus for inserting and printing barcoded zip codes
US5748755A (en) * 1992-05-08 1998-05-05 Moore Business Forms, Inc. Picture checks
US20070072585A1 (en) * 1992-11-12 2007-03-29 Lightbridge, Inc. Apparatus and Method for Credit Based Management of Telecommunication Activity
US5491817A (en) * 1993-05-25 1996-02-13 Bell Communications Research Inc. Linking system and method for accessing directory information about an object in one context when information in another context is known
US5870721A (en) * 1993-08-27 1999-02-09 Affinity Technology Group, Inc. System and method for real time loan approval
US5778164A (en) * 1993-09-24 1998-07-07 Eastman Kodak Company System for custom imprinting a variety of articles with images obtained from a variety of different sources
US6029149A (en) * 1993-11-01 2000-02-22 The Golden 1 Credit Union Lender direct credit evaluation and loan processing system
US5930776A (en) * 1993-11-01 1999-07-27 The Golden 1 Credit Union Lender direct credit evaluation and loan processing system
US5920847A (en) * 1993-11-01 1999-07-06 Visa International Service Association Electronic bill pay system
US5611052A (en) * 1993-11-01 1997-03-11 The Golden 1 Credit Union Lender direct credit evaluation and loan processing system
US5724155A (en) * 1993-12-30 1998-03-03 Olympus Optical Co., Ltd. Electronic imaging system
US6513018B1 (en) * 1994-05-05 2003-01-28 Fair, Isaac And Company, Inc. Method and apparatus for scoring the likelihood of a desired performance result
US20030105725A1 (en) * 1994-11-28 2003-06-05 Ned Hoffman Tokenless identification system for authorization of electronic transactions and electronic transmissions
US5857079A (en) * 1994-12-23 1999-01-05 Lucent Technologies Inc. Smart card for automatic financial records
US5732400A (en) * 1995-01-04 1998-03-24 Citibank N.A. System and method for a risk-based purchase of goods
US5604341A (en) * 1995-03-13 1997-02-18 At&T Global Information Solutions Company ATM as video conferencing station
US5727163A (en) * 1995-03-30 1998-03-10 Amazon.Com, Inc. Secure method for communicating credit card data when placing an order on a non-secure network
US5774883A (en) * 1995-05-25 1998-06-30 Andersen; Lloyd R. Method for selecting a seller's most profitable financing program
US5866889A (en) * 1995-06-07 1999-02-02 Citibank, N.A. Integrated full service consumer banking system and system and method for opening an account
US6354490B1 (en) * 1995-06-07 2002-03-12 Citibank, N.A. Integrated full service consumer banking system and system and method for opening an account
US5659165A (en) * 1995-07-24 1997-08-19 Citibank. N.A. Customer-directed, automated process for transferring funds between accounts via a communications network
US5878403A (en) * 1995-09-12 1999-03-02 Cmsi Computer implemented automated credit application analysis and decision routing system
US6584467B1 (en) * 1995-12-08 2003-06-24 Allstate Insurance Company Method and apparatus for obtaining data from vendors in real time
US6088686A (en) * 1995-12-12 2000-07-11 Citibank, N.A. System and method to performing on-line credit reviews and approvals
US5761640A (en) * 1995-12-18 1998-06-02 Nynex Science & Technology, Inc. Name and address processor
US5745654A (en) * 1996-02-13 1998-04-28 Hnc Software, Inc. Fast explanations of scored observations
US6044360A (en) * 1996-04-16 2000-03-28 Picciallo; Michael J. Third party credit card
US6014645A (en) * 1996-04-19 2000-01-11 Block Financial Corporation Real-time financial card application system
US20060153350A1 (en) * 1996-06-05 2006-07-13 David Felger Method of billing a communication session conducted over a computer network
US6510418B1 (en) * 1996-09-04 2003-01-21 Priceline.Com Incorporated Method and apparatus for detecting and deterring the submission of similar offers in a commerce system
US6240396B1 (en) * 1996-09-04 2001-05-29 Priceline.Com Incorporated Conditional purchase offer management system for event tickets
US5764916A (en) * 1996-09-27 1998-06-09 Ichat, Inc. Method and apparatus for real time communication over a computer network
US5878404A (en) * 1996-10-08 1999-03-02 Mechanics Savings Bank System and method for managing the amortization of a loan
US6202155B1 (en) * 1996-11-22 2001-03-13 Ubiq Incorporated Virtual card personalization system
US6070798A (en) * 1997-02-21 2000-06-06 Nethery; Kee Purchaser generated transaction recording and negotiable instrument payment system
US6374230B1 (en) * 1997-03-12 2002-04-16 Walker Digital, Llc Method, apparatus and program for customizing credit accounts
US6064987A (en) * 1997-03-21 2000-05-16 Walker Digital, Llc Method and apparatus for providing and processing installment plans at a terminal
US20020067500A1 (en) * 1997-05-12 2002-06-06 Yoshikazu Yokomizo Method of and system for editing images
US6598030B1 (en) * 1997-05-27 2003-07-22 Visa International Service Association Method and apparatus for pattern generation
US6267292B1 (en) * 1997-06-13 2001-07-31 Walker Digital, Llc Method and apparatus for funds and credit line transfers
US6542936B1 (en) * 1997-07-03 2003-04-01 Ipac Acquisition Subsidiary I, Llc System for creating messages including image information
US7020631B2 (en) * 1997-07-11 2006-03-28 The Chase Manhattan Bank Method for mortgage and closed end loan portfolio management
US6085126A (en) * 1997-11-21 2000-07-04 St. Paul Stamp Works, Inc. System and method for preparing custom designs for multiple types of imprintable media
US6058428A (en) * 1997-12-05 2000-05-02 Pictra, Inc. Method and apparatus for transferring digital images on a network
US6092057A (en) * 1997-12-12 2000-07-18 Commstar, Inc. Unattended POS system for automatic control of bank system rejections
US6049784A (en) * 1997-12-16 2000-04-11 Capital One Financial Corporation Method for creating and managing a lease agreement
US6202053B1 (en) * 1998-01-23 2001-03-13 First Usa Bank, Na Method and apparatus for generating segmentation scorecards for evaluating credit risk of bank card applicants
US6182124B1 (en) * 1998-01-30 2001-01-30 International Business Machines Corporation Token-based deadline enforcement system for electronic document submission
US6233565B1 (en) * 1998-02-13 2001-05-15 Saranac Software, Inc. Methods and apparatus for internet based financial transactions with evidence of payment
US6199079B1 (en) * 1998-03-09 2001-03-06 Junglee Corporation Method and system for automatically filling forms in an integrated network based transaction environment
US20020055906A1 (en) * 1998-03-11 2002-05-09 Katz Ronald A. Methods and apparatus for intelligent selection of goods and services in telephonic and electronic commerce
US6192380B1 (en) * 1998-03-31 2001-02-20 Intel Corporation Automatic web based form fill-in
US20060036543A1 (en) * 1998-04-24 2006-02-16 First Data Corporation Creating groups of linked accounts
US20020035543A1 (en) * 1998-04-27 2002-03-21 Aurora Wireless Technologies, Ltd. System and method for detecting high credit risk customers
US6385594B1 (en) * 1998-05-08 2002-05-07 Lendingtree, Inc. Method and computer network for co-ordinating a loan over the internet
US6389541B1 (en) * 1998-05-15 2002-05-14 First Union National Bank Regulating access to digital content
US6185543B1 (en) * 1998-05-15 2001-02-06 Marketswitch Corp. Method and apparatus for determining loan prepayment scores
US6085195A (en) * 1998-06-02 2000-07-04 Xstasis, Llc Internet photo booth
US6505176B2 (en) * 1998-06-12 2003-01-07 First American Credit Management Solutions, Inc. Workflow management system for an automated credit application system
US20040064412A1 (en) * 1998-06-22 2004-04-01 Bank One, Delaware, National Association Debit purchasing of stored value card for use by and/or delivery to others
US6029890A (en) * 1998-06-22 2000-02-29 Austin; Frank User-Specified credit card system
US20070124214A1 (en) * 1998-06-26 2007-05-31 American Express Travel Related Services Company, Inc. Stored value transaction system including an integrated database server
US6349290B1 (en) * 1998-06-30 2002-02-19 Citibank, N.A. Automated system and method for customized and personalized presentation of products and services of a financial institution
US6070149A (en) * 1998-07-02 2000-05-30 Activepoint Ltd. Virtual sales personnel
US20040019558A1 (en) * 1998-07-22 2004-01-29 Mcdonald Russell W. Mortgage loan data collection method and apparatus for a financial planning originator and/or financial institution originator of a mortgage loan
US7315841B1 (en) * 1998-07-22 2008-01-01 Sourcetec, Inc. Mortgage loan and financial services data processing system
US7194436B2 (en) * 1998-08-10 2007-03-20 Ford Motor Company Method and system for internet based financial auto credit application
US6343279B1 (en) * 1998-08-26 2002-01-29 American Management Systems, Inc. System integrating credit card transactions into a financial management system
US20030055778A1 (en) * 1998-10-24 2003-03-20 Michael David Erlanger Data processing system for providing an efficient market for loans and lines of credit
US7756781B2 (en) * 1998-11-03 2010-07-13 Nextcard, Llc Method and apparatus for a verifiable on line rejection of an applicant for credit
US6718313B1 (en) * 1998-11-03 2004-04-06 Next Card, Inc. Integrating live chat into an online credit card application
US7346576B2 (en) * 1998-11-03 2008-03-18 Nextcard, Llc Integrating live chat into an online credit card application
US6405181B2 (en) * 1998-11-03 2002-06-11 Nextcard, Inc. Method and apparatus for real time on line credit approval
US6567791B2 (en) * 1998-11-03 2003-05-20 Nextcard, Inc. Method and apparatus for a verifiable on line rejection of an application for credit
US20070027785A1 (en) * 1998-11-03 2007-02-01 Nextcard, Inc. Method and apparatus for a verifiable on line rejection of an applicant for credit
US6208979B1 (en) * 1998-11-09 2001-03-27 E-Fin, Llc Computer-driven information management system for selectively matching credit applicants with money lenders through a global communications network
US6766302B2 (en) * 1998-11-09 2004-07-20 Joseph Bach Method and apparatus for advertisement
US7395239B1 (en) * 1999-07-19 2008-07-01 American Business Financial System and method for automatically processing loan applications
US6356909B1 (en) * 1999-08-23 2002-03-12 Proposal Technologies Network, Inc. Web based system for managing request for proposal and responses
US6516421B1 (en) * 1999-10-27 2003-02-04 International Business Machines Corporation Method and means for adjusting the timing of user-activity-dependent changes of operational state of an apparatus
US6535492B2 (en) * 1999-12-01 2003-03-18 Genesys Telecommunications Laboratories, Inc. Method and apparatus for assigning agent-led chat sessions hosted by a communication center to available agents based on message load and agent skill-set
US7230927B1 (en) * 1999-12-07 2007-06-12 Aspect Software, Inc. Non-blocking expandable call center architecture
US20020029188A1 (en) * 1999-12-20 2002-03-07 Schmid Stephen J. Method and apparatus to facilitate competitive financing activities among myriad lenders on behalf of one borrower
US20020023051A1 (en) * 2000-03-31 2002-02-21 Kunzle Adrian E. System and method for recommending financial products to a customer based on customer needs and preferences
US20020016731A1 (en) * 2000-05-26 2002-02-07 Benjamin Kupersmit Method and system for internet sampling
US20080021816A1 (en) * 2000-06-15 2008-01-24 Nextcard, Llc Integrating Live Chat Into an Online Credit Card Application
US20050004864A1 (en) * 2000-06-15 2005-01-06 Nextcard Inc. Implementing a counter offer for an on line credit card application

Cited By (226)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7756781B2 (en) 1998-11-03 2010-07-13 Nextcard, Llc Method and apparatus for a verifiable on line rejection of an applicant for credit
US8010422B1 (en) 1998-11-03 2011-08-30 Nextcard, Llc On-line balance transfers
US20050004864A1 (en) * 2000-06-15 2005-01-06 Nextcard Inc. Implementing a counter offer for an on line credit card application
US9819561B2 (en) 2000-10-26 2017-11-14 Liveperson, Inc. System and methods for facilitating object assignments
US10797976B2 (en) 2000-10-26 2020-10-06 Liveperson, Inc. System and methods for facilitating object assignments
US9576292B2 (en) 2000-10-26 2017-02-21 Liveperson, Inc. Systems and methods to facilitate selling of products and services
US8868448B2 (en) 2000-10-26 2014-10-21 Liveperson, Inc. Systems and methods to facilitate selling of products and services
US7552080B1 (en) 2001-03-09 2009-06-23 Nextcard, Llc Customized credit offer strategy based on terms specified by an applicant
US9710852B1 (en) 2002-05-30 2017-07-18 Consumerinfo.Com, Inc. Credit report timeline user interface
US9569797B1 (en) 2002-05-30 2017-02-14 Consumerinfo.Com, Inc. Systems and methods of presenting simulated credit score information
US9400589B1 (en) 2002-05-30 2016-07-26 Consumerinfo.Com, Inc. Circular rotational interface for display of consumer credit information
US10565643B2 (en) 2002-05-30 2020-02-18 Consumerinfo.Com, Inc. Systems and methods of presenting simulated credit score information
US8930263B1 (en) 2003-05-30 2015-01-06 Consumerinfo.Com, Inc. Credit data analysis
US8930216B1 (en) 2004-09-01 2015-01-06 Search America, Inc. Method and apparatus for assessing credit for healthcare patients
US8452611B1 (en) 2004-09-01 2013-05-28 Search America, Inc. Method and apparatus for assessing credit for healthcare patients
US11562457B2 (en) 2004-09-22 2023-01-24 Experian Information Solutions, Inc. Automated analysis of data to generate prospect notifications based on trigger events
US11373261B1 (en) 2004-09-22 2022-06-28 Experian Information Solutions, Inc. Automated analysis of data to generate prospect notifications based on trigger events
US11861756B1 (en) 2004-09-22 2024-01-02 Experian Information Solutions, Inc. Automated analysis of data to generate prospect notifications based on trigger events
US10586279B1 (en) 2004-09-22 2020-03-10 Experian Information Solutions, Inc. Automated analysis of data to generate prospect notifications based on trigger events
US9525745B2 (en) 2005-09-14 2016-12-20 Liveperson, Inc. System and method for performing follow up based on user interactions
US9948582B2 (en) 2005-09-14 2018-04-17 Liveperson, Inc. System and method for performing follow up based on user interactions
US8738732B2 (en) 2005-09-14 2014-05-27 Liveperson, Inc. System and method for performing follow up based on user interactions
US11526253B2 (en) 2005-09-14 2022-12-13 Liveperson, Inc. System and method for design and dynamic generation of a web page
US10191622B2 (en) 2005-09-14 2019-01-29 Liveperson, Inc. System and method for design and dynamic generation of a web page
US9432468B2 (en) 2005-09-14 2016-08-30 Liveperson, Inc. System and method for design and dynamic generation of a web page
US11743214B2 (en) 2005-09-14 2023-08-29 Liveperson, Inc. System and method for performing follow up based on user interactions
US9590930B2 (en) 2005-09-14 2017-03-07 Liveperson, Inc. System and method for performing follow up based on user interactions
US11394670B2 (en) 2005-09-14 2022-07-19 Liveperson, Inc. System and method for performing follow up based on user interactions
US11157997B2 (en) 2006-03-10 2021-10-26 Experian Information Solutions, Inc. Systems and methods for analyzing data
US20080052377A1 (en) * 2006-07-11 2008-02-28 Robert Light Web-Based User-Dependent Customer Service Interaction with Co-Browsing
US8799148B2 (en) 2006-08-31 2014-08-05 Rohan K. K. Chandran Systems and methods of ranking a plurality of credit card offers
US11887175B2 (en) 2006-08-31 2024-01-30 Cpl Assets, Llc Automatically determining a personalized set of programs or products including an interactive graphical user interface
US8626646B2 (en) 2006-10-05 2014-01-07 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US10963961B1 (en) 2006-10-05 2021-03-30 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US11631129B1 (en) 2006-10-05 2023-04-18 Experian Information Solutions, Inc System and method for generating a finance attribute from tradeline data
US9563916B1 (en) 2006-10-05 2017-02-07 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US10121194B1 (en) 2006-10-05 2018-11-06 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US11875314B1 (en) 2006-10-31 2024-01-16 United Services Automobile Association (Usaa) Systems and methods for remote deposit of checks
US9251541B2 (en) 2007-05-25 2016-02-02 Experian Information Solutions, Inc. System and method for automated detection of never-pay data sets
US8364588B2 (en) 2007-05-25 2013-01-29 Experian Information Solutions, Inc. System and method for automated detection of never-pay data sets
US20100169444A1 (en) * 2007-07-11 2010-07-01 International Business Machines Corporation Method, system and program product for assigning a responder to a requester in a collaborative environment
US8266227B2 (en) * 2007-07-11 2012-09-11 International Business Machines Corporation Method, system and program product for assigning a responder to a requester in a collaborative environment
US20120297323A1 (en) * 2007-07-11 2012-11-22 International Business Machines Corporation Method, system and program product for assigning a responder to a requester in a collaborative environment
US8443048B2 (en) * 2007-07-11 2013-05-14 International Business Machines Corporation Method, system and program product for assigning a responder to a requester in a collaborative environment
US10528545B1 (en) 2007-09-27 2020-01-07 Experian Information Solutions, Inc. Database system for triggering event notifications based on updates to database records
US9690820B1 (en) 2007-09-27 2017-06-27 Experian Information Solutions, Inc. Database system for triggering event notifications based on updates to database records
US11347715B2 (en) 2007-09-27 2022-05-31 Experian Information Solutions, Inc. Database system for triggering event notifications based on updates to database records
US20090119181A1 (en) * 2007-11-07 2009-05-07 At&T Knowledge Ventures, L.P. Point of sale transaction processing
US8818872B2 (en) * 2007-11-07 2014-08-26 At&T Intellectual Property I, L.P. Point of sale transaction processing
US8464939B1 (en) 2007-12-14 2013-06-18 Consumerinfo.Com, Inc. Card registry systems and methods
US9767513B1 (en) 2007-12-14 2017-09-19 Consumerinfo.Com, Inc. Card registry systems and methods
US10262364B2 (en) 2007-12-14 2019-04-16 Consumerinfo.Com, Inc. Card registry systems and methods
US11379916B1 (en) 2007-12-14 2022-07-05 Consumerinfo.Com, Inc. Card registry systems and methods
US10614519B2 (en) 2007-12-14 2020-04-07 Consumerinfo.Com, Inc. Card registry systems and methods
US9542682B1 (en) 2007-12-14 2017-01-10 Consumerinfo.Com, Inc. Card registry systems and methods
US10878499B2 (en) 2007-12-14 2020-12-29 Consumerinfo.Com, Inc. Card registry systems and methods
US9230283B1 (en) 2007-12-14 2016-01-05 Consumerinfo.Com, Inc. Card registry systems and methods
US11783306B1 (en) 2008-02-07 2023-10-10 United Services Automobile Association (Usaa) Systems and methods for mobile deposit of negotiable instruments
US11157872B2 (en) 2008-06-26 2021-10-26 Experian Marketing Solutions, Llc Systems and methods for providing an integrated identifier
US11769112B2 (en) 2008-06-26 2023-09-26 Experian Marketing Solutions, Llc Systems and methods for providing an integrated identifier
US10075446B2 (en) 2008-06-26 2018-09-11 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
US9104970B2 (en) 2008-07-25 2015-08-11 Liveperson, Inc. Method and system for creating a predictive model for targeting web-page to a surfer
US8762313B2 (en) 2008-07-25 2014-06-24 Liveperson, Inc. Method and system for creating a predictive model for targeting web-page to a surfer
US9336487B2 (en) 2008-07-25 2016-05-10 Live Person, Inc. Method and system for creating a predictive model for targeting webpage to a surfer
US9396436B2 (en) 2008-07-25 2016-07-19 Liveperson, Inc. Method and system for providing targeted content to a surfer
US8954539B2 (en) 2008-07-25 2015-02-10 Liveperson, Inc. Method and system for providing targeted content to a surfer
US9396295B2 (en) 2008-07-25 2016-07-19 Liveperson, Inc. Method and system for creating a predictive model for targeting web-page to a surfer
US11263548B2 (en) 2008-07-25 2022-03-01 Liveperson, Inc. Method and system for creating a predictive model for targeting web-page to a surfer
US8799200B2 (en) 2008-07-25 2014-08-05 Liveperson, Inc. Method and system for creating a predictive model for targeting webpage to a surfer
US11763200B2 (en) 2008-07-25 2023-09-19 Liveperson, Inc. Method and system for creating a predictive model for targeting web-page to a surfer
US11386106B2 (en) 2008-08-04 2022-07-12 Liveperson, Inc. System and methods for searching and communication
US9563707B2 (en) 2008-08-04 2017-02-07 Liveperson, Inc. System and methods for searching and communication
US10891299B2 (en) 2008-08-04 2021-01-12 Liveperson, Inc. System and methods for searching and communication
US10657147B2 (en) 2008-08-04 2020-05-19 Liveperson, Inc. System and methods for searching and communication
US9569537B2 (en) 2008-08-04 2017-02-14 Liveperson, Inc. System and method for facilitating interactions
US9558276B2 (en) 2008-08-04 2017-01-31 Liveperson, Inc. Systems and methods for facilitating participation
US9582579B2 (en) 2008-08-04 2017-02-28 Liveperson, Inc. System and method for facilitating communication
US8805844B2 (en) 2008-08-04 2014-08-12 Liveperson, Inc. Expert search
US10650448B1 (en) * 2008-08-14 2020-05-12 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US9489694B2 (en) * 2008-08-14 2016-11-08 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US9792648B1 (en) * 2008-08-14 2017-10-17 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US11004147B1 (en) * 2008-08-14 2021-05-11 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US11636540B1 (en) * 2008-08-14 2023-04-25 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US9256904B1 (en) * 2008-08-14 2016-02-09 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US10115155B1 (en) * 2008-08-14 2018-10-30 Experian Information Solution, Inc. Multi-bureau credit file freeze and unfreeze
US20110166987A1 (en) * 2008-09-28 2011-07-07 Alibaba Group Holding Limited Evaluating Loan Access Using Online Business Transaction Data
US8412593B1 (en) 2008-10-07 2013-04-02 LowerMyBills.com, Inc. Credit card matching
US10867307B2 (en) 2008-10-29 2020-12-15 Liveperson, Inc. System and method for applying tracing tools for network locations
US9892417B2 (en) 2008-10-29 2018-02-13 Liveperson, Inc. System and method for applying tracing tools for network locations
US11562380B2 (en) 2008-10-29 2023-01-24 Liveperson, Inc. System and method for applying tracing tools for network locations
US10621657B2 (en) 2008-11-05 2020-04-14 Consumerinfo.Com, Inc. Systems and methods of credit information reporting
US10937090B1 (en) 2009-01-06 2021-03-02 Consumerinfo.Com, Inc. Report existence monitoring
US11756009B1 (en) * 2009-08-19 2023-09-12 United Services Automobile Association (Usaa) Apparatuses, methods and systems for a publishing and subscribing platform of depositing negotiable instruments
US10909617B2 (en) 2010-03-24 2021-02-02 Consumerinfo.Com, Inc. Indirect monitoring and reporting of a user's credit data
US11615161B2 (en) 2010-04-07 2023-03-28 Liveperson, Inc. System and method for dynamically enabling customized web content and applications
US9767212B2 (en) 2010-04-07 2017-09-19 Liveperson, Inc. System and method for dynamically enabling customized web content and applications
US11893628B1 (en) 2010-06-08 2024-02-06 United Services Automobile Association (Usaa) Apparatuses, methods and systems for a video remote deposit capture platform
US11915310B1 (en) 2010-06-08 2024-02-27 United Services Automobile Association (Usaa) Apparatuses, methods and systems for a video remote deposit capture platform
US8606694B2 (en) 2010-07-02 2013-12-10 Experian Credit Advisors, Inc. Online registration system for CROA-compliant credit advice services
US8930262B1 (en) 2010-11-02 2015-01-06 Experian Technology Ltd. Systems and methods of assisted strategy design
US10417704B2 (en) 2010-11-02 2019-09-17 Experian Technology Ltd. Systems and methods of assisted strategy design
US9147042B1 (en) 2010-11-22 2015-09-29 Experian Information Solutions, Inc. Systems and methods for data verification
US9684905B1 (en) 2010-11-22 2017-06-20 Experian Information Solutions, Inc. Systems and methods for data verification
US10104020B2 (en) 2010-12-14 2018-10-16 Liveperson, Inc. Authentication of service requests initiated from a social networking site
US10038683B2 (en) 2010-12-14 2018-07-31 Liveperson, Inc. Authentication of service requests using a communications initiation feature
US11777877B2 (en) 2010-12-14 2023-10-03 Liveperson, Inc. Authentication of service requests initiated from a social networking site
US9350598B2 (en) 2010-12-14 2016-05-24 Liveperson, Inc. Authentication of service requests using a communications initiation feature
US8918465B2 (en) 2010-12-14 2014-12-23 Liveperson, Inc. Authentication of service requests initiated from a social networking site
US11050687B2 (en) 2010-12-14 2021-06-29 Liveperson, Inc. Authentication of service requests initiated from a social networking site
US11861691B1 (en) 2011-04-29 2024-01-02 Consumerinfo.Com, Inc. Exposing reporting cycle information
US9558519B1 (en) 2011-04-29 2017-01-31 Consumerinfo.Com, Inc. Exposing reporting cycle information
US10115079B1 (en) 2011-06-16 2018-10-30 Consumerinfo.Com, Inc. Authentication alerts
US9607336B1 (en) 2011-06-16 2017-03-28 Consumerinfo.Com, Inc. Providing credit inquiry alerts
US10719873B1 (en) 2011-06-16 2020-07-21 Consumerinfo.Com, Inc. Providing credit inquiry alerts
US11232413B1 (en) 2011-06-16 2022-01-25 Consumerinfo.Com, Inc. Authentication alerts
US10685336B1 (en) 2011-06-16 2020-06-16 Consumerinfo.Com, Inc. Authentication alerts
US9665854B1 (en) 2011-06-16 2017-05-30 Consumerinfo.Com, Inc. Authentication alerts
US10798197B2 (en) 2011-07-08 2020-10-06 Consumerinfo.Com, Inc. Lifescore
US11665253B1 (en) 2011-07-08 2023-05-30 Consumerinfo.Com, Inc. LifeScore
US10176233B1 (en) 2011-07-08 2019-01-08 Consumerinfo.Com, Inc. Lifescore
US9106691B1 (en) 2011-09-16 2015-08-11 Consumerinfo.Com, Inc. Systems and methods of identity protection and management
US11790112B1 (en) 2011-09-16 2023-10-17 Consumerinfo.Com, Inc. Systems and methods of identity protection and management
US10061936B1 (en) 2011-09-16 2018-08-28 Consumerinfo.Com, Inc. Systems and methods of identity protection and management
US9542553B1 (en) 2011-09-16 2017-01-10 Consumerinfo.Com, Inc. Systems and methods of identity protection and management
US11087022B2 (en) 2011-09-16 2021-08-10 Consumerinfo.Com, Inc. Systems and methods of identity protection and management
US10642999B2 (en) 2011-09-16 2020-05-05 Consumerinfo.Com, Inc. Systems and methods of identity protection and management
US9536263B1 (en) 2011-10-13 2017-01-03 Consumerinfo.Com, Inc. Debt services candidate locator
US11200620B2 (en) 2011-10-13 2021-12-14 Consumerinfo.Com, Inc. Debt services candidate locator
US8738516B1 (en) 2011-10-13 2014-05-27 Consumerinfo.Com, Inc. Debt services candidate locator
US9972048B1 (en) 2011-10-13 2018-05-15 Consumerinfo.Com, Inc. Debt services candidate locator
US11797960B1 (en) 2012-01-05 2023-10-24 United Services Automobile Association (Usaa) System and method for storefront bank deposits
US8943002B2 (en) 2012-02-10 2015-01-27 Liveperson, Inc. Analytics driven engagement
US10326719B2 (en) 2012-03-06 2019-06-18 Liveperson, Inc. Occasionally-connected computing interface
US11711329B2 (en) 2012-03-06 2023-07-25 Liveperson, Inc. Occasionally-connected computing interface
US11134038B2 (en) 2012-03-06 2021-09-28 Liveperson, Inc. Occasionally-connected computing interface
US9331969B2 (en) 2012-03-06 2016-05-03 Liveperson, Inc. Occasionally-connected computing interface
US8805941B2 (en) 2012-03-06 2014-08-12 Liveperson, Inc. Occasionally-connected computing interface
US11323428B2 (en) 2012-04-18 2022-05-03 Liveperson, Inc. Authentication of service requests using a communications initiation feature
US11689519B2 (en) 2012-04-18 2023-06-27 Liveperson, Inc. Authentication of service requests using a communications initiation feature
US10666633B2 (en) 2012-04-18 2020-05-26 Liveperson, Inc. Authentication of service requests using a communications initiation feature
US11269498B2 (en) 2012-04-26 2022-03-08 Liveperson, Inc. Dynamic user interface customization
US11868591B2 (en) 2012-04-26 2024-01-09 Liveperson, Inc. Dynamic user interface customization
US10795548B2 (en) 2012-04-26 2020-10-06 Liveperson, Inc. Dynamic user interface customization
US9563336B2 (en) 2012-04-26 2017-02-07 Liveperson, Inc. Dynamic user interface customization
US11356430B1 (en) 2012-05-07 2022-06-07 Consumerinfo.Com, Inc. Storage and maintenance of personal data
US9853959B1 (en) 2012-05-07 2017-12-26 Consumerinfo.Com, Inc. Storage and maintenance of personal data
US9672196B2 (en) 2012-05-15 2017-06-06 Liveperson, Inc. Methods and systems for presenting specialized content using campaign metrics
US11687981B2 (en) 2012-05-15 2023-06-27 Liveperson, Inc. Methods and systems for presenting specialized content using campaign metrics
US11004119B2 (en) 2012-05-15 2021-05-11 Liveperson, Inc. Methods and systems for presenting specialized content using campaign metrics
US20210182828A1 (en) * 2012-11-05 2021-06-17 Mfoundry, Inc. Cloud-based systems and methods for providing consumer financial data
US11715088B2 (en) * 2012-11-05 2023-08-01 Fidelity Information Services, Llc Cloud-based systems and methods for providing consumer financial data
US11863310B1 (en) 2012-11-12 2024-01-02 Consumerinfo.Com, Inc. Aggregating user web browsing data
US11012491B1 (en) 2012-11-12 2021-05-18 ConsumerInfor.com, Inc. Aggregating user web browsing data
US9654541B1 (en) 2012-11-12 2017-05-16 Consumerinfo.Com, Inc. Aggregating user web browsing data
US10277659B1 (en) 2012-11-12 2019-04-30 Consumerinfo.Com, Inc. Aggregating user web browsing data
US11132742B1 (en) 2012-11-30 2021-09-28 Consumerlnfo.com, Inc. Credit score goals and alerts systems and methods
US11651426B1 (en) 2012-11-30 2023-05-16 Consumerlnfo.com, Inc. Credit score goals and alerts systems and methods
US10366450B1 (en) 2012-11-30 2019-07-30 Consumerinfo.Com, Inc. Credit data analysis
US11308551B1 (en) 2012-11-30 2022-04-19 Consumerinfo.Com, Inc. Credit data analysis
US9830646B1 (en) 2012-11-30 2017-11-28 Consumerinfo.Com, Inc. Credit score goals and alerts systems and methods
US10963959B2 (en) 2012-11-30 2021-03-30 Consumerinfo. Com, Inc. Presentation of credit score factors
US10255598B1 (en) 2012-12-06 2019-04-09 Consumerinfo.Com, Inc. Credit card account data extraction
US20140236614A1 (en) * 2013-02-15 2014-08-21 Passport Health Communications, Inc. Financial Triage
US9697263B1 (en) 2013-03-04 2017-07-04 Experian Information Solutions, Inc. Consumer data request fulfillment system
US11769200B1 (en) 2013-03-14 2023-09-26 Consumerinfo.Com, Inc. Account vulnerability alerts
US9870589B1 (en) 2013-03-14 2018-01-16 Consumerinfo.Com, Inc. Credit utilization tracking and reporting
US10043214B1 (en) 2013-03-14 2018-08-07 Consumerinfo.Com, Inc. System and methods for credit dispute processing, resolution, and reporting
US10102570B1 (en) 2013-03-14 2018-10-16 Consumerinfo.Com, Inc. Account vulnerability alerts
US11514519B1 (en) 2013-03-14 2022-11-29 Consumerinfo.Com, Inc. System and methods for credit dispute processing, resolution, and reporting
US9406085B1 (en) 2013-03-14 2016-08-02 Consumerinfo.Com, Inc. System and methods for credit dispute processing, resolution, and reporting
US10929925B1 (en) 2013-03-14 2021-02-23 Consumerlnfo.com, Inc. System and methods for credit dispute processing, resolution, and reporting
US11113759B1 (en) 2013-03-14 2021-09-07 Consumerinfo.Com, Inc. Account vulnerability alerts
US9697568B1 (en) 2013-03-14 2017-07-04 Consumerinfo.Com, Inc. System and methods for credit dispute processing, resolution, and reporting
US11164271B2 (en) 2013-03-15 2021-11-02 Csidentity Corporation Systems and methods of delayed authentication and billing for on-demand products
US10169761B1 (en) 2013-03-15 2019-01-01 ConsumerInfo.com Inc. Adjustment of knowledge-based authentication
US11790473B2 (en) 2013-03-15 2023-10-17 Csidentity Corporation Systems and methods of delayed authentication and billing for on-demand products
US11288677B1 (en) 2013-03-15 2022-03-29 Consumerlnfo.com, Inc. Adjustment of knowledge-based authentication
US11775979B1 (en) 2013-03-15 2023-10-03 Consumerinfo.Com, Inc. Adjustment of knowledge-based authentication
US10740762B2 (en) 2013-03-15 2020-08-11 Consumerinfo.Com, Inc. Adjustment of knowledge-based authentication
US10664936B2 (en) 2013-03-15 2020-05-26 Csidentity Corporation Authentication systems and methods for on-demand products
US10685398B1 (en) 2013-04-23 2020-06-16 Consumerinfo.Com, Inc. Presenting credit score information
US11803929B1 (en) 2013-05-23 2023-10-31 Consumerinfo.Com, Inc. Digital identity
US11120519B2 (en) 2013-05-23 2021-09-14 Consumerinfo.Com, Inc. Digital identity
US9721147B1 (en) 2013-05-23 2017-08-01 Consumerinfo.Com, Inc. Digital identity
US10453159B2 (en) 2013-05-23 2019-10-22 Consumerinfo.Com, Inc. Digital identity
US9443268B1 (en) 2013-08-16 2016-09-13 Consumerinfo.Com, Inc. Bill payment and reporting
US20150081388A1 (en) * 2013-09-16 2015-03-19 International Business Machines Corporation Customer selection for service offerings
US20150081390A1 (en) * 2013-09-16 2015-03-19 International Business Machines Corporation Customer selection for service offerings
US10325314B1 (en) 2013-11-15 2019-06-18 Consumerinfo.Com, Inc. Payment reporting systems
US10269065B1 (en) 2013-11-15 2019-04-23 Consumerinfo.Com, Inc. Bill payment and reporting
US11461364B1 (en) 2013-11-20 2022-10-04 Consumerinfo.Com, Inc. Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules
US9477737B1 (en) 2013-11-20 2016-10-25 Consumerinfo.Com, Inc. Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules
US10025842B1 (en) 2013-11-20 2018-07-17 Consumerinfo.Com, Inc. Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules
US10628448B1 (en) 2013-11-20 2020-04-21 Consumerinfo.Com, Inc. Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules
USD760256S1 (en) 2014-03-25 2016-06-28 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
USD759689S1 (en) 2014-03-25 2016-06-21 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
USD759690S1 (en) 2014-03-25 2016-06-21 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
US11386442B2 (en) 2014-03-31 2022-07-12 Liveperson, Inc. Online behavioral predictor
US9892457B1 (en) 2014-04-16 2018-02-13 Consumerinfo.Com, Inc. Providing credit data in search results
US10482532B1 (en) 2014-04-16 2019-11-19 Consumerinfo.Com, Inc. Providing credit data in search results
US10373240B1 (en) 2014-04-25 2019-08-06 Csidentity Corporation Systems, methods and computer-program products for eligibility verification
US11587150B1 (en) 2014-04-25 2023-02-21 Csidentity Corporation Systems and methods for eligibility verification
US11074641B1 (en) 2014-04-25 2021-07-27 Csidentity Corporation Systems, methods and computer-program products for eligibility verification
US11638195B2 (en) 2015-06-02 2023-04-25 Liveperson, Inc. Dynamic communication routing based on consistency weighting and routing rules
US10869253B2 (en) 2015-06-02 2020-12-15 Liveperson, Inc. Dynamic communication routing based on consistency weighting and routing rules
US11410230B1 (en) 2015-11-17 2022-08-09 Consumerinfo.Com, Inc. Realtime access and control of secure regulated data
US11893635B1 (en) 2015-11-17 2024-02-06 Consumerinfo.Com, Inc. Realtime access and control of secure regulated data
US11729230B1 (en) 2015-11-24 2023-08-15 Experian Information Solutions, Inc. Real-time event-based notification system
US10757154B1 (en) 2015-11-24 2020-08-25 Experian Information Solutions, Inc. Real-time event-based notification system
US11159593B1 (en) 2015-11-24 2021-10-26 Experian Information Solutions, Inc. Real-time event-based notification system
US10278065B2 (en) 2016-08-14 2019-04-30 Liveperson, Inc. Systems and methods for real-time remote control of mobile applications
US11227001B2 (en) 2017-01-31 2022-01-18 Experian Information Solutions, Inc. Massive scale heterogeneous data ingestion and user resolution
US11681733B2 (en) 2017-01-31 2023-06-20 Experian Information Solutions, Inc. Massive scale heterogeneous data ingestion and user resolution
US11652607B1 (en) 2017-06-30 2023-05-16 Experian Information Solutions, Inc. Symmetric encryption for private smart contracts among multiple parties in a private peer-to-peer network
US10735183B1 (en) 2017-06-30 2020-08-04 Experian Information Solutions, Inc. Symmetric encryption for private smart contracts among multiple parties in a private peer-to-peer network
US10992593B2 (en) * 2017-10-06 2021-04-27 Bank Of America Corporation Persistent integration platform for multi-channel resource transfers
US11588639B2 (en) 2018-06-22 2023-02-21 Experian Information Solutions, Inc. System and method for a token gateway environment
US10911234B2 (en) 2018-06-22 2021-02-02 Experian Information Solutions, Inc. System and method for a token gateway environment
US11399029B2 (en) 2018-09-05 2022-07-26 Consumerinfo.Com, Inc. Database platform for realtime updating of user data from third party sources
US10671749B2 (en) 2018-09-05 2020-06-02 Consumerinfo.Com, Inc. Authenticated access and aggregation database platform
US10880313B2 (en) 2018-09-05 2020-12-29 Consumerinfo.Com, Inc. Database platform for realtime updating of user data from third party sources
US11265324B2 (en) 2018-09-05 2022-03-01 Consumerinfo.Com, Inc. User permissions for access to secure data at third-party
US11315179B1 (en) 2018-11-16 2022-04-26 Consumerinfo.Com, Inc. Methods and apparatuses for customized card recommendations
US11620403B2 (en) 2019-01-11 2023-04-04 Experian Information Solutions, Inc. Systems and methods for secure data aggregation and computation
US11842454B1 (en) 2019-02-22 2023-12-12 Consumerinfo.Com, Inc. System and method for an augmented reality experience via an artificial intelligence bot
US11238656B1 (en) 2019-02-22 2022-02-01 Consumerinfo.Com, Inc. System and method for an augmented reality experience via an artificial intelligence bot

Also Published As

Publication number Publication date
AU2143600A (en) 2000-05-22
WO2000026831A1 (en) 2000-05-11
US20020007341A1 (en) 2002-01-17
US6405181B2 (en) 2002-06-11
EP1138009A4 (en) 2002-07-17
WO2000026831A9 (en) 2001-11-29
EP1138009A1 (en) 2001-10-04
US20120215682A1 (en) 2012-08-23
CA2347133A1 (en) 2000-05-11

Similar Documents

Publication Publication Date Title
US20080270295A1 (en) Method and Apparatus for Real Time Online Credit Approval
US6324524B1 (en) Method and apparatus for an account level offer of credit and real time balance transfer
US7143063B2 (en) Method and apparatus for a verifiable on line rejection of an applicant for credit
US6795812B1 (en) Implementing a counter offer for an on line credit card application
US8538857B2 (en) Online trading system having real-time account opening
US7818228B1 (en) System and method for managing consumer information
US20050004864A1 (en) Implementing a counter offer for an on line credit card application
US20020178113A1 (en) System and method for offering customized credit card products
US7092904B1 (en) Web-based account management for hold and release of funds
WO2002007059A1 (en) Web-based account management
RU2728532C1 (en) Automated system for selecting combined credit offers
CA2408243A1 (en) Web-based account management

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION