U.S. patent application number 13/718362 was filed with the patent office on 2013-07-04 for system and method for interactively simulating a credit-worthiness score.
This patent application is currently assigned to EXPERIAN INFORMATION SOLUTIONS, INC.. The applicant listed for this patent is EXPERIAN INFORMATION SOLUTIONS, INC.. Invention is credited to Constance A. Elliott, Joseph L. Greenwald, Adam T. Kornegay.
Application Number | 20130173451 13/718362 |
Document ID | / |
Family ID | 41211155 |
Filed Date | 2013-07-04 |
United States Patent
Application |
20130173451 |
Kind Code |
A1 |
Kornegay; Adam T. ; et
al. |
July 4, 2013 |
SYSTEM AND METHOD FOR INTERACTIVELY SIMULATING A CREDIT-WORTHINESS
SCORE
Abstract
A system and method is provided to allow a consumer to
interactively explore his credit score by submitting hypothetical
values based on his actual credit data. The system uses the
consumer's real credit data and the submitted hypothetical values
to calculate a simulated credit score based on a simulator
scorecard. The consumer may then observe the changes in the
resultant scores. The system and the scorecard may utilize fewer
data elements than a complete credit-worthiness scorecard and may
instead focus on the key elements affecting a consumer's credit
score. The system may be implemented in part on a web server or as
a stand-alone application. The system may also update the score
dynamically as the consumer adjusts the hypothetical values or may
require the consumer to affirmatively submit the new hypothetical
data.
Inventors: |
Kornegay; Adam T.; (Irvine,
CA) ; Greenwald; Joseph L.; (Orange, CA) ;
Elliott; Constance A.; (Orange, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
EXPERIAN INFORMATION SOLUTIONS, INC.; |
Cost Mesa |
CA |
US |
|
|
Assignee: |
EXPERIAN INFORMATION SOLUTIONS,
INC.
Costa Mesa
CA
|
Family ID: |
41211155 |
Appl. No.: |
13/718362 |
Filed: |
December 18, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13225225 |
Sep 2, 2011 |
8335741 |
|
|
13718362 |
|
|
|
|
12606060 |
Oct 26, 2009 |
8015107 |
|
|
13225225 |
|
|
|
|
10452155 |
May 30, 2003 |
7610229 |
|
|
12606060 |
|
|
|
|
60384650 |
May 30, 2002 |
|
|
|
Current U.S.
Class: |
705/38 |
Current CPC
Class: |
G06Q 40/04 20130101;
G06Q 40/02 20130101; G06Q 40/025 20130101; G06Q 20/102 20130101;
G06Q 40/00 20130101 |
Class at
Publication: |
705/38 |
International
Class: |
G06Q 40/02 20120101
G06Q040/02 |
Claims
1. A computer system comprising: a computer processor configured to
execute software instructions in order to cause the computer system
to: transmit user interface data to a client computer, the user
interface data configured to cause the client computer to display a
user interface including a graphical representation of a first
credit score calculated based on credit-related information of a
user of the client computer, the user interface further including
one or more adjustable sliders configured to enable the user of the
client computer to adjust one or more credit-related parameters;
and transmit updated user interface data reflecting a second credit
score calculated based on adjusted credit-related parameters
received from the client computer.
Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] The present invention relates to a system and method for
teaching consumers about the interaction of credit data elements in
determining a credit risk score. More particularly, the present
invention relates to a system and method for simulating a
consumer's credit risk score and for providing the consumer the
opportunity to adjust his credit data to hypothetical values in
order to observe the changes in the simulated score.
[0003] 2. Description of Background Art
[0004] The practice of predicting a consumer's credit-worthiness is
well known. Conventional credit-worthiness, or credit risk,
analysis focuses on a consumer's credit history and other factors
to determine whether credit should be offered or granted to the
consumer.
[0005] Conventional credit risk analysis utilizes a risk model, or
scorecard, to give a relative weight to each data element in the
credit history to provide a credit-worthiness score. These models
vary from provider to provider depending on the needs of the
financial institution requesting the credit score. The methodology
behind creating a risk model is known in the art.
[0006] Financial institutions that request a consumer's
credit-worthiness score do so for several reasons. First,
institutions often pre-screen potential applicants to determine to
whom they should mail an offer of credit and at what terms.
Typically, an institution will provide a score cut-off or tiered
system for providing various terms and rates to different
credit-worthiness score brackets. Pre-screening is used primarily
to generate new business for the institution. Second, businesses
use the credit-worthiness score in granting real-time requests by a
consumer for a line of credit. This may include applying for a home
mortgage, buying a car, or opening a new credit card account at the
point of sale. In these instances, the credit score is requested
and compared against the institution's credit risk policy to
determine whether the new line of credit will be provided.
[0007] With creditors and lenders placing such a large emphasis on
a consumer's credit-worthiness score, it is common for a consumer
to want to improve his score. Typically, the scorecards utilize
complex mathematical models and algorithms to arrive at a
credit-worthiness score. The complexity of the scoring process is a
stumbling block for consumers who want to understand how their
scores were generated and how to improve their scores. Conventional
attempts to educate consumers have failed to provide clear answers
to consumers' questions. Most credit scoring vendors have
deliberately withheld information on how credit scores are
generated for fear of adding additional levels of confusion.
Explanations and tutorials offered to consumers have been
non-interactive and text-based. Furthermore, conventional solutions
have not used the consumer's own credit data to illustrate the
process.
[0008] Therefore there is a need for a system that (1) provides
information to the consumer regarding score improvement, (2) uses
the consumer's own credit data to illustrate the score generation
process, and (3) allows the user to interact with the system and to
experiment with different credit data in order to explore the
hypothetical changes in his credit-worthiness score.
SUMMARY OF THE INVENTION
[0009] A system and method for simulating a consumer's
credit-worthiness score based on both initial data and
consumer-modified data is described. In one embodiment, the initial
data is credit bureau data associated with a particular consumer.
In another embodiment, the initial data is census bureau data based
on the average consumer. In yet another embodiment, the initial
data can be made more relevant to the particular consumer by
refining the census bureau data based on certain factors such as
location, age, and profession.
[0010] In one embodiment, the system includes a client terminal, a
simulator server, a credit data server, and a scorecard data
server. The client terminal and the data servers are each coupled
to the simulator server. The client terminal and simulator server
are configured to allow a consumer using the client terminal to
communicate interactively with the simulator server to explore
various aspects and factors comprising his credit-worthiness score.
The simulator server calculates an initial credit-worthiness score
by applying a simulator scorecard to data from the credit data
server and then presents the consumer with options for modifying
this data. The consumer is prompted to adjust the values of the
initial data to produce modified data in order to observe the
resultant change in his credit score. As the data is adjusted, the
simulator server uses the simulator scorecard to recalculate the
credit-worthiness score based on any unaltered initial data and the
modified data.
[0011] In a preferred embodiment, the recalculation of the credit
score is performed automatically by the simulator server and does
not require an explicit submission of the modified data by the
consumer.
[0012] In another embodiment, the simulator server utilizes a
simulator scorecard that calculates the credit-worthiness score
based on only a portion of the credit data commonly used to
calculate credit scores. Since only a portion of the credit data is
used, the resulting credit score is an approximation of what the
credit score would be had all of the information been used. By
using a smaller set of data elements, the system is able to respond
more quickly to a consumer's submitted modified data, and the
interface with the consumer is simpler. This allows the consumer to
focus on the key data elements, which greatly affect his score,
without having to worry about all the less important data elements,
which only refine his score. The simulator server also analyzes the
initial data to determine which subset of data elements most affect
the consumer's score and calculates the simulated score based on
the values of those elements. In one embodiment, those data
elements are the only data elements presented to the consumer for
the submission of modified data.
[0013] In yet another embodiment, the data values are presented in
the form of graphical slider bars, first set to the initial data
values. The consumer adjusts the data values by clicking and
dragging the graphical slider bars to new values. In a preferred
embodiment, as a graphical slider bar is dragged, the simulator
score is updated. This allows the user to gain an understanding of
how his credit data affects his score and helps the consumer to
plan an effective path to better credit.
[0014] In the preferred embodiment, the client terminal, simulator
server, scorecard data server, and credit data server are each
coupled to a network in order to communicate with each other. In an
alternate embodiment, the system is self-contained, with the client
terminal, simulator server, scorecard data server, and credit data
server all residing on one computer. The computer is a
general-purpose computer or a computer specifically optimized to
calculate the simulated scores.
[0015] In yet another embodiment, the client terminal is
implemented as a web browser. In this embodiment, the client
terminal is situated at a point across the network from the
simulator server or is co-located with the simulator server.
Additionally, in this embodiment the simulator server creates and
serves a web page to the client terminal for interacting with the
consumer.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] The invention is illustrated by way of example, and not by
way of limitation, in the figures of the accompanying drawings in
which like reference numerals refer to similar elements.
[0017] FIG. 1 illustrates a block diagram overview of one
embodiment of a system for simulating a credit-worthiness score
based on initial and modified credit data.
[0018] FIG. 2 illustrates a block diagram of a preferred embodiment
of the architecture of the simulator server.
[0019] FIG. 3 illustrates a more detailed block diagram of the
contents of the memory unit in FIG. 2.
[0020] FIG. 4a illustrates how data gets into the working data
memory.
[0021] FIG. 4b illustrates how data gets into the scorecard
memory.
[0022] FIG. 4c is a diagram of the data flow through the simulated
score generator.
[0023] FIG. 5 illustrates a flow chart of a preferred embodiment of
a method for simulating a credit-worthiness score based on initial
and modified credit data.
[0024] FIG. 6a illustrates one embodiment of the user interface
shown on a client terminal.
[0025] FIG. 6b illustrates the embodiment depicted in FIG. 6a
showing modified data being entered.
[0026] FIG. 6c illustrates the embodiment depicted in FIG. 6a
showing the resultant score simulation.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0027] Financial risk scores, along with their associated risk
models, are designed to predict future consumer financial behaviors
such as delinquency, bankruptcy, and profitability. One example of
a financial risk score is the credit-worthiness score. While the
invention can be used in conjunction with any financial risk score,
the embodiments described below address credit-worthiness scores in
particular. Specifically, a system and method for simulating a
credit-worthiness score based on initial and modified credit data
is described.
[0028] In the following description, for purposes of explanation,
numerous specific details are set forth in order to provide a
thorough understanding of the invention. It will be apparent,
however, to one skilled in the art that the invention can be
practiced without these specific details. In other instances,
structures and devices are shown in block diagram form in order to
avoid obscuring the invention.
[0029] Reference in the specification to "one embodiment" or "an
embodiment" means that a particular feature, structure, or
characteristic described in connection with the embodiment is
included in at least one embodiment of the invention. The
appearances of the phrase "in one embodiment" in various places in
the specification are not necessarily all referring to the same
embodiment.
[0030] Some portions of the detailed descriptions that follow are
presented in terms of algorithms and symbolic representations of
operations on data bits within a computer memory. These algorithmic
descriptions and representations are the means used by those
skilled in the data processing arts to most effectively convey the
substance of their work to others skilled in the art. An algorithm
is here, and generally, conceived to be a self-consistent sequence
of steps leading to a desired result. The steps are those requiring
physical manipulations of physical quantities. Usually, though not
necessarily, these quantities take the form of electrical or
magnetic signals capable of being stored, transferred, combined,
compared, and otherwise manipulated. It has proven convenient at
times, principally for reasons of common usage, to refer to these
signals as bits, values, elements, symbols, characters, terms,
numbers, or the like.
[0031] It should be borne in mind, however, that all of these and
similar terms are to be associated with the appropriate physical
quantities and are merely convenient labels applied to these
quantities. Unless specifically stated otherwise, as apparent from
the following discussion, it is appreciated that throughout the
description, discussions utilizing terms such as "processing" or
"computing" or "computing" or "calculating" or "determining" or
"displaying" or the like, refer to the action and processes of a
computer system, or similar electronic computing device, that
manipulates and transforms data represented as physical
(electronic) quantities within the computer system's registers and
memories into other data similarly represented as physical
quantities within the computer system memories or registers or
other such information storage, transmission, or display
devices.
[0032] The present invention also relates to an apparatus for
performing the operations herein. This apparatus is specially
constructed for the required purposes, or it comprises a
general-purpose computer selectively activated or reconfigured by a
computer program stored in the computer. Such a computer program is
stored in a computer readable storage medium, such as, but not
limited to, any type of disk including floppy disks, optical disks,
CD-ROMs, and magnetic-optical disks, read-only memories (ROMs),
random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical
cards, or any type of media suitable for storing electronic
instructions, and each coupled to a computer system bus.
[0033] The algorithms and displays presented herein are not
inherently related to any particular computer or other apparatus.
Various general-purpose systems are used with programs in
accordance with the teachings herein, or more specialized apparatus
are constructed to perform the required method steps. The required
structure for a variety of these systems will appear from the
description below. In addition, the present invention is not
described with reference to any particular programming language. It
will be appreciated that a variety of programming languages may be
used to implement the teachings of the invention as described
herein.
Overview
[0034] FIG. 1 illustrates a block diagram overview of one
embodiment of a system 101 for simulating a credit-worthiness score
based on initial and modified credit data. Generally, system 101
includes a simulator server 110, a client terminal 120, a credit
data server 130, and a scorecard data server 140. Client terminal
120 is a general-purpose computer capable of running a web browser
or other user-interface program or it is a limited-function
electronic device configured to communicate with the simulator
server 110. The simulator server 110 is any general-purpose
computer configured to serve web pages or communicate with the
client terminal 120. It may be advantageous to utilize a
general-purpose computer configured to be an information-server
capable of handling communications with multiple client terminals
120. Likewise, credit data server 130 and scorecard data server 140
are general-purpose computers configured to provide remote access
to stored data.
[0035] The client terminal 120 and the data servers 130 and 140 are
each coupled to the simulator server 110. The client terminal 120
and simulator server 110 are configured to allow a consumer using
the client terminal to communicate interactively with the simulator
server 110. In a preferred embodiment, the client terminal 120 is
communicatively coupled to the simulator server 110 via a
communications network 150, such as the Internet. This facilitates
the centralization and segmentation of the system 101 for ease of
maintenance and accessibility.
[0036] System 101 operates as follows. A consumer who wishes to
learn how credit data affects credit-worthiness scores uses client
terminal 120 to communicate with simulator server 110. The
simulator server 110 retrieves scorecard data from the scorecard
data server 140 such as via a LAN 160. The scorecard data server
140 contains one or more simulator scorecards for use by the
simulator server 110. Generally, each scorecard provides a metric
for the simulator server 110 to weigh information contained in the
retrieved credit data to simulate the credit-worthiness score.
Scorecards represent these weights as coefficients. In a preferred
embodiment, the simulator server 110 uses a simulator scorecard
that simulates the scoring process of the credit industry's generic
scoring method. In an alternate embodiment, the consumer is able to
select which scoring method to simulate and thus the scorecard data
server 140 includes additional simulator scorecards for each
scoring method.
[0037] The simulator server 110 also communicates with the credit
data server 130 to obtain credit data such as via a LAN 160. The
credit data includes information related to a consumer's
credit-worthiness. In a preferred embodiment, this information
includes credit data that is generally collected by a credit
bureau. However, one skilled in the art will recognize that other
data may either replace or supplement the credit data in generating
and simulating the credit-worthiness score.
[0038] In one embodiment, the credit data server 130 holds credit
bureau data. In this embodiment, the consumer provides information
sufficient to identify himself (hereinafter "consumer
identification data"). In one embodiment, the consumer
identification data includes the consumer's name, social security
number, current address, or any other distinguishing data for
ensuring that the correct credit data is associated with the
consumer. In a preferred embodiment, the consumer identification
data needs to be entered only once and is stored in a profile on
the system 101. During subsequent uses, the consumer signs into the
system 101 to have the profile provide the consumer identification
data. The profile would be provided to only those users who possess
the correct security credentials, such as passwords or access
cards. In this embodiment, the profile would be stored on a
computer-readable medium. The computer-readable medium could be
stored in the client terminal 120, in the simulator server 110, or
elsewhere in system 101.
[0039] The client terminal 120 transmits the consumer
identification data to the simulator server 110. The simulator
server 110 then transmits the consumer identification data to the
credit data server 130. The credit data server 130 then returns
credit data corresponding to the particular consumer. While this
embodiment enables the consumer to experiment with his own actual
credit data, it is not always the preferred embodiment because
pulling actual credit data can cost money and adversely affect
one's credit rating.
[0040] In another embodiment, the credit data server 130 holds
census bureau data based on the average consumer. In this
embodiment, the consumer does not provide any information about
himself. Although credit data transmitted from the credit data
server 130 to the simulator server 110 is not specific to the
consumer, it provides a starting point for the consumer to explore
the effect that credit data has on a credit-worthiness score.
[0041] In yet another embodiment, the credit data server 130 also
holds census bureau data, but the consumer provides some
information about himself. In one embodiment, the information
corresponds to the categories of information stored by the census
bureau, such as location, age, and profession. The client terminal
120 transmits this information to the simulator server 110. The
simulator server 110 then transmits the information to the credit
data server 130. The credit data server 130 then returns credit
data based on the information. This embodiment allows the credit
data returned to be more relevant to the specific consumer while
not experiencing the disadvantages of pulling the consumer's actual
credit report.
[0042] Once the simulator scorecard and credit data have been
obtained, the simulator server 110 uses the simulator scorecard and
credit data to calculate an initial simulated score. The simulator
server 110 then outputs this score to the client terminal 120. In
one embodiment, the score is a simple numerical value, such as is
shown in FIGS. 6a-6c (described below). In another embodiment, the
score is a value representing a characteristic of a financial
transaction, such as a loan limit or a loan percentage rate. Many
other forms of scores are also possible.
[0043] The consumer interactively adjusts the values of the initial
credit data elements via the client terminal 120. The client
terminal 120 then transmits the modified credit data to the
simulator server 110. The simulator server 110 receives the
modified credit data and substitutes the modified credit data for
the corresponding initial credit data retrieved from the credit
data server 130. The simulator server 110 then recalculates a
credit-worthiness score based on the metric of the selected
scorecard data and the modified credit data. In one embodiment, the
recalculated score is output alongside the initial score to the
client terminal 120 to allow the consumer to interactively compare
the effect of the changes on the credit-worthiness score.
[0044] In a preferred embodiment, the simulator server 110
communicates with the client terminal 120 via a web page. This web
page is served by the simulator server 110 and typically runs on
the client terminal 120. The web page allows for user entry of the
consumer identification data, the modified data, and the additional
consumer information. The client terminal 120 also receives the
simulated score from the simulator server 110 and displays it on
the web page. In a preferred embodiment, the entry of the modified
data is interactive, allowing the simulated score to be
recalculated dynamically by the simulator server 110 responsive to
changes in the initial data, without requiring the user to actually
"submit" the changes to the simulator server 110. The user
interface for the client terminal 120 will be discussed in greater
detail below.
[0045] One skilled in the art will recognize that other
communication topologies exist that fall within the spirit of the
invention. For example, in an alternate embodiment, the simulator
server 110, credit data server 130, scorecard data server 140, and
client terminal 120 all reside or originate locally in one
general-purpose computer system. Furthermore, the present invention
advantageously simulates credit scoring methods currently used in
the credit industry to aid the consumer in determining the best
manner in which to improve his credit. As the credit industry
changes scoring methods, the present invention may be adapted to
these new methods as well.
Simulator Server
[0046] FIG. 2 illustrates a block diagram of a preferred embodiment
of simulator server 110. Simulator server 110 preferably includes a
processor 210, a main memory 220, a data storage device 230, and a
network controller 280, all of which are communicatively coupled to
a system bus 240.
[0047] Processor 210 processes data signals and comprises various
computing architectures including a complex instruction set
computer (CISC) architecture, a reduced instruction set computer
(RISC) architecture, or an architecture implementing a combination
of instruction sets. Although only a single processor is shown in
FIG. 2, multiple processors may be included.
[0048] Main memory 220 stores instructions and/or data that are
executed by processor 210. The instructions and/or data comprise
code for performing any and/or all of the techniques described
herein. Main memory 220 is preferably a dynamic random access
memory (DRAM) device, a static random access memory (SRAM) device,
or some other memory device known in the art.
[0049] Data storage device 230 stores data and instructions for
processor 210 and comprises one or more devices including a hard
disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device
a DVD-RAM device, a DVD-RW device, a flash memory device, or some
other mass storage device known in the art.
[0050] Network controller 280 links simulator server 110 to a
network 150 that may include multiple processing systems. In a
preferred embodiment, the credit data server 130, the scorecard
data server 140, and the client terminal 120 are also connected to
the network 150. The network 150 comprises a local area network
(LAN), a wide area network (WAN) (e.g., the Internet), and/or any
other interconnected data path across which multiple devices may
communicate.
[0051] System bus 240 represents a shared bus for communicating
information and data throughout simulator server 110. System bus
240 represents one or more buses including an industry standard
architecture (ISA) bus, a peripheral component interconnect (PCI)
bus, a universal serial bus (USB), or some other bus known in the
art to provide similar functionality.
[0052] Additional components that may be coupled to simulator
server 110 through system bus 240 include a display device 250, a
keyboard 260, and a cursor control device 270. Display device 250
represents any device equipped to display electronic images and
data to a local user or maintainer. Display device 250 is a cathode
ray tube (CRT), a liquid crystal display (LCD), or any other
similarly equipped display device, screen, or monitor. Keyboard 260
represents an alphanumeric input device coupled to simulator server
110 to communicate information and command selections to processor
210. Cursor control device 270 represents a user input device
equipped to communicate positional data as well as command
selections to processor 210. Cursor control 270 includes a mouse, a
trackball, a stylus, a pen, cursor direction keys, or other
mechanisms to cause movement of a cursor.
[0053] It should be apparent to one skilled in the art that
simulator server 110 includes more or fewer components than those
shown in FIG. 2 without departing from the spirit and scope of the
present invention. For example, simulator server 110 may include
additional memory, such as, for example, a first or second level
cache or one or more application specific integrated circuits
(ASICs). As noted above, simulator server 110 may be comprised
solely of ASICs. In addition, components may be coupled to
simulator server 110 including, for example, image scanning
devices, digital still or video cameras, or other devices that may
or may not be equipped to capture and/or download electronic data
to/from simulator server 110.
[0054] FIG. 3 is a block diagram of memory unit 220. Generally,
memory unit 220 comprises several code modules for simulating a
credit-worthiness score, responding to consumer identification
data, and presenting the user interface for output on client
terminal 120. Specifically, the code modules in memory unit 220
include: a main program 301, an initial credit data retriever 305,
a scorecard retriever 310, a simulated score generator 315, a
static data formatter 320, an interactive data formatter 325, a
user interface server 330, a modified credit data retriever 335, a
modified credit data parser 340, and a user information retriever
375.
[0055] Memory unit 220 also contains several memory storage areas
for storing various bytes of data required by the operation of the
code modules 301, 305, 310, 315, 320, 325, 330, 335 and 340.
Specifically, memory unit 220 includes an initial credit data
memory 350, a scorecard memory 355, in initial score memory 360, a
modified score memory 365, and a working data memory 370.
[0056] All code modules and memories 305, 310, 315, 320, 325, 330,
335, 340, 350, 355, 360, 365, 370, and 375 are communicatively
coupled with main program 301. Main program 301 centrally controls
the operation and process flow of simulator server 110,
transmitting instructions and data to as well as receiving data
from each code module and memory 305, 310, 315, 320, 325, 330, 335,
340, 350, 355, 360, 365, 370, and 275. The operation of memories
350, 355, 360, 365, and 370 and code modules 301, 305, 310, 315,
320, 325, 330, 335, 340, and 375 in memory unit 220 is best shown
in FIGS. 4a-4c.
[0057] FIG. 4a illustrates how data gets into the working data
memory 370. Initially, the data stored in working data memory 370
comes from the credit data server 130 as follows. The credit data
server 130 is coupled to the initial credit data retriever 305. The
credit data server 130 receives a query from the initial credit
data retriever 305. Based on information in the query, the credit
data server 130 transmits credit data to the initial credit data
retriever 305.
[0058] In one embodiment, there is a user information retriever 375
that is coupled to the client terminal 120 and the initial credit
data retriever 305. When the user enters information about himself
at client terminal 120 (either information sufficient to identify
himself or other information such as location or salary), client
terminal 120 transmits this information to the user information
retriever 375. The user information retriever 375 then transmits
this information to the initial credit data retriever 305. The
initial credit data retriever 305 uses this information to refine
its query to the credit data server 130, as described above.
[0059] The initial credit data retriever 305 is coupled to the
credit data server 130, the initial credit data memory 350, and the
working data memory 370. Once the initial credit data retriever 305
has received credit data from the credit data server 130, the
initial credit data retriever 305 transmits this credit data to the
initial credit data memory 350 and the working data memory 370.
[0060] The initial credit data memory 350 is coupled to the initial
credit data retriever 305. Once the initial credit data memory 350
has received credit data from the initial credit data retriever
305, the initial credit data memory 350 stores this credit data.
The working data memory 370 is also coupled to the initial credit
data retriever 305 (in addition to being coupled to the modified
credit data parser 340, as described below). Once the working data
memory 370 has received credit data from the initial credit data
retriever 305, the working data memory 370 stores this credit
data.
[0061] Since the working data memory 370 now has initial credit
data, simulated score generator 315 (see FIG. 4c) outputs the
initial credit score. This score is then stored in initial score
memory 360, as described in FIG. 4c.
[0062] When a user modifies the initial credit data, the entire set
of credit data (both modified data and initial data, if any) is
stored in working data memory 370 as follows. The client terminal
120 is coupled to the modified credit data retriever 335. The user
uses client terminal 120 to modify the initial credit data. The
client terminal 120 transmits the modified credit data to modified
credit data retriever 335.
[0063] The modified credit data retriever 335 is coupled to the
client terminal 120 and the modified credit data parser 340. Once
the modified credit data retriever 335 has received the modified
credit data from the client terminal 120, it transmits the data to
the modified credit data parser 340. The modified credit data
parser 340 is coupled to the modified credit data retriever 335 and
the working data memory 370. Once the modified credit data parser
340 has received the modified credit data from the modified credit
data retriever 335, it transmits the modified credit data to the
working data memory 370. The credit data values in working data
memory 370 that the user modified are thereby set to the new
(modified) values, while the unchanged data (if any) remains at the
same initial values. Since the working data memory 370 now has
modified credit data, simulated score generator 315 recalculates
the credit score and outputs it. This score is then stored in
modified score memory 365, as described in FIG. 4c.
[0064] FIG. 4b illustrates how data gets into the scorecard memory
355. The data stored in scorecard memory 355 comes from the
scorecard data server 140 as follows. The scorecard data server 140
is coupled to the scorecard retriever 310. The scorecard data
server 140 receives a request for a scorecard from scorecard
retriever 310. Based on information in the request, scorecard data
server 140 transmits scorecard data to scorecard retriever 310.
[0065] Scorecard retriever 310 is coupled to scorecard data server
140 and scorecard memory 355. Once scorecard retriever 310 has
received scorecard data from the scorecard data server 140, the
scorecard retriever 310 transmits this scorecard data to the
scorecard memory 355.
[0066] The scorecard memory 355 is coupled to the scorecard
retriever 310. Once the scorecard memory 355 has received scorecard
data from the scorecard retriever 310, the scorecard memory 355
stores this scorecard data.
[0067] FIG. 4c is a diagram of the data processing through the
simulated score generator 315. Simulated score generator 315 is
coupled to working data memory 370, scorecard memory 355, initial
score memory 360, and modified score memory 365. Simulated score
generator 315 takes as inputs data in the working data memory 370
and data in the scorecard memory 355. Simulated score generator 315
then calculates a credit-worthiness score using the scorecard data
in the scorecard memory 355 and the credit data in the working data
memory 370. This score is then transmitted to either initial score
memory 360 or modified score memory 365, depending on whether the
credit data in working data memory 370 was initial credit data or
contained some modified credit data, respectively. Initial score
memory 360 or modified score memory 365 then stores the received
score.
[0068] Static data formatter 320 and interactive data formatter 325
prepare the user interface that is shown on client terminal 120 via
user interface server 330. Static data formatter 320 is coupled to
initial credit data memory 350, initial score memory 360, and
modified score memory 365. Static data formatter 320 receives data
from these three memories and formats that data. Interactive data
formatter 325 is coupled to initial credit data memory 350 and
working data memory 370. Interactive data formatter 325 receives
data from these two memories and formats the data. User interface
server 330 is coupled to static data formatter 320 and interactive
data formatter 325. User interface server 330 receives as inputs
formatted data from both the static data formatter 320 and the
interactive data formatter 325 and transmits to client terminal 120
a single integrated user interface.
Start-Up/First Pass
[0069] The general method implemented by main program 301 is
further illustrated in FIG. 5. A consumer accesses system 101 via
client terminal 120 in order to learn how credit data affects
credit-worthiness scores. The first pass of the system 101 provides
the consumer with an initial simulated score. This score will be
based on credit data and can vary depending on whether the credit
data comes from a credit bureau, the census bureau, or another
source. The system 101 then allows the consumer to submit modified
credit data to view how changing credit data affect
credit-worthiness scores.
[0070] In one embodiment, the consumer provides no information to
the system. In another embodiment, he provides either consumer
identification data or some information (but not enough to identify
himself). If the consumer provides any information, the client
terminal 120 transmits the information to the simulator server 110,
and the information is received 505. Initial credit data retriever
305 then uses this information (if any) to obtain 510 initial
credit data from credit data server 130. Credit data retriever 305
then stores 525 the initial credit data in working data memory 370
as described in FIG. 4b.
[0071] Next, the scorecard retriever 310 retrieves 530 the
simulator scorecard as described in FIG. 4c. The simulated score
generator 315 then applies the scorecard coefficients stored in
scorecard memory 355 to the credit data stored in working data
memory 370 to generate 545 an initial simulated credit-worthiness
score.
[0072] In a preferred embodiment, the set of elements chosen for
inclusion in the score calculation is smaller than the total set of
elements present in the credit data. By working with a smaller set
of data elements, the simulator server 110 more quickly calculates
the simulated score, providing a response almost instantly.
However, the returned score may not be absolutely accurate since it
is based on a smaller subset of credit data. The simulator
scorecard approximates an industry-standard credit score based on
the fall set of credit data while using a smaller subset of the
data.
[0073] In the preferred embodiment, the set of elements is chosen
to reflect the data that most strongly influences the consumer's
credit score, thus providing the consumer with the best idea of
which aspects of his credit data he should try to improve first. In
one embodiment, these elements are predetermined and the set is
constant across all consumers. In another embodiment, the system
determines which elements are most influential in a particular
consumer's credit score and selects those elements. One method for
making such a determination includes examining the weighted value
of all the received data elements and choosing a set including the
highest valued elements. The system 101 may select only the
elements already existing in the received credit data or,
alternatively, may look for possible large swings in the modified
score by introducing a new type of data element. Examples of such a
data element include salary level and ownership of major assets.
For example, the modified data might include ownership of a home,
while the initial data did not. One skilled in the art will
recognize other methods for determining the set of data elements to
be included in the scoring procedure.
[0074] Once the score is generated 545, the simulated score
generator 315 stores the simulated score in both the initial score
memory 360 and in the modified score memory 365. By storing the
score in both memories 360 and 365, the static data formatter 320
is able to operate in the same manner regardless of whether the
system is in the first pass or another pass for any given consumer.
This is done in the preferred embodiment so that the user interface
may display a modified value and an initial value that are the same
when the interface is first presented. However, in an alternate
embodiment, the simulated score generator 315 could store the
simulated score just in the initial score memory 360. This would
result in the user interface displaying only an initial value until
the user has input modified data and the credit score was
recalculated for the modified data at least one time.
[0075] In subsequent passes, the simulated score generator 315 will
apply the scorecard coefficients to a set of modified credit data.
As discussed above, this will be a direct result of the consumer's
submission of modified data. As will be discussed in further detail
below, the data in working data memory 370 will be overwritten with
the modified credit data, and the simulated score generator 315
will recalculate the credit-worthiness score. However, unlike in
the first pass, the recalculated score will be stored only in the
modified score memory 365, not in the initial score memory 360.
This will preserve the initial score in the initial score memory
360 for output to the client terminal 120.
[0076] Static formatter 320 retrieves the credit data from initial
credit data memory 350 and both scores from initial score memory
360 and modified score memory 365 and formats 550 the information
for output to the consumer via user interface server 330 and the
client terminal 120. Interactive data formatter 325 selects and
formats 555 various elements from the initial credit data memory
350 and the working data memory 370 for inclusion in the user
interface presented to the consumer via user interface server 330
to client terminal 120.
[0077] As discussed above, in one embodiment, the simulator server
110 utilizes only a subset of the available credit data for a
consumer when calculating the simulated score. As discussed above,
this helps the score simulator more quickly calculate the updated
scores due to fewer possible variables. In another embodiment, the
interactive data formatter 325 presents only a subset of the data
to the consumer for modification. In this way, the consumer is
presented with the most common factors affecting credit-worthiness,
while the simulator server 110 bases its calculations on additional
credit data that is not made available to the consumer for
modification.
[0078] Once the scores, data, and user interface have been
formatted 550 and the interactive data has been selected and
formatted 555, the user interface server 330 combines the
information and outputs 560 the combined user interface to the
client terminal 120 for viewing and interaction by the consumer.
Once the information has been output 560, the system waits 565 for
the consumer to submit modified credit data via the user
interface.
Processing Modified Data
[0079] Once the consumer submits the modified credit data, it is
received 570 by the modified credit data retriever 335 and passed
to the modified credit data parser 340. The modified credit data
parser 340 merges 573 the received (modified) credit data with the
credit data stored in working data memory 370 and stores the
resulting data into the working data memory 370. In this
embodiment, the data in initial credit data memory 350 remains
unchanged once it is stored during the first pass. This allows the
consumer to compare the initial credit data with the newly input
modified credit data and see the resulting change in the credit
score.
[0080] In an alternate embodiment, after the consumer submits
modified credit data, but before the modified data is merged with
the data in working data memory 370, the data in working data
memory 370 is stored in initial credit data memory 350. In
addition, the data in modified score memory 365 is stored in
initial score memory 360. In this embodiment, the data in initial
credit data memory 350 and initial score memory 360 is the data
used in and calculated by the previous pass of the system 101,
respectively. In other words, this embodiment allows the consumer
to compare the previous pass credit data with the newly input
modified credit data and see the resulting change in the credit
score.
[0081] The scorecard retriever 310 retrieves 530 the simulator
scorecard as described in FIG. 4c. The simulated score generator
315 then applies the scorecard coefficients stored in scorecard
memory 355 to the credit data stored in working data memory 370 to
generate 545 a recalculated simulated credit-worthiness score. The
recalculated score is then stored in modified score memory 365 for
use by the static data formatter 320.
[0082] Static data formatter 320 formats 550 the initial score
stored in initial score memory 360, the newly recalculated score
stored in modified score memory 365, and the credit data stored in
the initial credit data memory 350 in a similar fashion as during
the first pass of the system. The interactive data formatter 325
likewise receives the new working data and the credit data from
their respective memories 370 and 350 and formats 555 the user
interface to reflect the consumer's latest submission of modified
credit data as stored in the working data memory 370.
[0083] Once the user interface server 330 outputs 560 the
information to the client terminal 120, the system 101 again waits
565 to see whether the consumer submits additional modified data.
If new modified data is submitted, the system 101 begins the
process again with the modified data retriever 335 receiving 570
the modified credit data.
[0084] FIGS. 6a-6c illustrate a preferred embodiment of the user
interface transmitted to the client terminal 120. FIG. 6a
illustrates a preferred embodiment of the user interface 601
outputted 560 during the first pass of the system 101, before
modified data has been submitted. The first pass user interface 601
includes a score comparison section 605a and an interactive section
610a.
[0085] The score comparison section 605a includes bar graph 615
representing the range of possible credit scores. In the embodiment
illustrated in FIGS. 6a-6c, the score is a simple numerical value,
and a higher score reflects a higher degree of credit-worthiness.
In another embodiment, the score is a value representing a
characteristic of a financial transaction, such as a loan limit or
a loan percentage rate. Many other forms of scores are also
possible.
[0086] Score comparison section 605a also includes an indicator 620
showing the consumer's initial credit-worthiness, and a second
indicator 625a, which shows the consumer's recalculated
credit-worthiness score based on submitted modified data. Note that
during the first pass, the two indicators 620, 625a point to the
same value. As will be discussed below, once modified credit data
has been submitted by the consumer, the second indicator 625a will
move to a different value allowing the consumer to both numerically
and visually compare the effects of changing the data.
[0087] While the score comparison section 605a has been illustrated
as including a bar-graph 615 and two indicators 620, 625a showing
the relative positions of the scores, one skilled in the art will
recognize that other graphical or textual methods exist by which to
enable the consumer to compare his initial score with a
recalculated score.
[0088] The interactive section 610a includes several elements
relating to selected data elements in the received credit data. As
illustrated, these include the total revolving credit card balance
owed 630a, the total revolving credit card limit, the number of
inquires from credit applications, and the number of accounts the
consumer is currently late in paying. This discussion will focus on
the first element 630a, the total revolving credit card balance
owed, when describing the operation of the preferred embodiment of
the first pass display 601. It will be apparent to one skilled in
the art that the remaining elements in the interactive section 610a
may operate in a similar manner. Likewise, it will be apparent to
one skilled in the art that additional or different data elements
may be included in the interactive section 610a.
[0089] Element 630a includes a legend 632 identifying the nature of
the data element displayed and providing a scale by which to
interpret the remaining parts of first element 630a. First element
630a also includes an initial value indicator 635, which reflects
the value of the corresponding data from the retrieved credit data,
and a graphical slider 640a whose value initially matches the
initial value indicator 635, but may subsequently be manipulated by
the consumer to submit the modified credit data. Finally, first
element 630a includes an information point 645 where the consumer
may access information or help regarding the associated data
element or regarding the operation of the client terminal 120.
While the preferred embodiment utilizes a graphical slider element,
one skilled in the art will recognize that various methods may
exist by which the consumer may be informed of their initial data
values and may adjust the modified values. One such alternative
includes a text-based system wherein the consumer simply types in a
new value in for the element in order to submit the modified credit
data.
[0090] FIG. 6b illustrates the user interface 602 while the
consumer is submitting modified data through client terminal 120.
While the user interface 602 includes the same elements as the
first pass display 601, the second indicator 625b and the data
element 630b have been modified to reflect the changes submitted by
the consumer.
[0091] As illustrated, the consumer is in the process of adjusting
the value for element 630b. The adjustment is accomplished by
clicking on the graphical slider 640b and dragging it in a
horizontal direction, as indicated by arrow 650. It should be
understood that any one of the multiple elements (e.g., total
revolving credit card balance, total revolving credit card limit,
number of credit applications, and number of late accounts)
affecting credit could be modified in a similar manner. Note that
arrow 650 is not part of the user interface; it is included in FIG.
6b in order to show the movement of graphical slider 640b. In a
preferred embodiment, the second indicator 625b will move in a
vertical direction as indicated by arrow 660 (also not part of the
user interface) in response to the movement in the graphical slider
640b.
[0092] In another preferred embodiment, the score generation is
optimized to allow for automatic updating of the second indicator
625b even before a final modified value for element 630b is chosen.
More specifically, as the user selects and drags the modified value
bar, the other elements of the user interface 601 are modified,
updated and displayed before the user releases the selection of the
value bar. As illustrated, the lower the value chosen for the
modified credit data in element 630b, the higher the credit score
as indicated by the second indicator 625b. In another embodiment,
the consumer may adjust the modified value and then "submit" the
value, by clicking on a button, for example, before the second
indicator 625b will update. However, it is advantageous to provide
the near-instant update for the second indicator 625b as it allows
the consumer to quickly understand how changing credit data affects
one's credit-worthiness score.
[0093] FIG. 6c illustrates the user interface 603 after the
consumer has selected final values for his modified data. As noted
above, in one embodiment, user interface 603 reflects the user
interface after the consumer has "submitted" the modified value.
While the user interface 603 includes the same elements as the
first pass display 601, the second indicator 625c and data element
630c have been modified to reflect the changes submitted by the
consumer.
[0094] As illustrated, the consumer has adjusted the value of first
element 630c to explore the ramifications of a lower revolving
balance owed on his credit cards. To this effect, the graphical
slider 640c has been dragged to the left to select a value of
approximately $1,000. Compare this with the graphical slider's
original position of approximately $20,000, which is also the
position of the initial value indicator 635. As discussed with
respect to FIGS. 4 and 5, once the value for the total debt is
submitted as modified credit data, the modified score generator 345
recalculates the score and the static data formatter 320 prepares
the new position for the second indicator 625c for display in the
user interface 603. As discussed above, the recalculation and
display of the new score may have occurred in near-real time,
reflecting the changes as the consumer dragged the graphical
slider, or the recalculation may have required the consumer to
affirmatively submit the newly selected modified data. As
illustrated, the modified reduction in debt to $1,000 has raised
the recalculated score indicated by second indicator 625c to a
higher value than the initial score indicated by indicator 620.
Thus by selecting a lower debt value via first element 630c, the
consumer may learn that a score improvement may be had by paying
off debt and lowering his actual total revolving credit card
balance owed.
[0095] Although the invention has been described in considerable
detail with reference to certain embodiments thereof, other
embodiments are possible as will be understood to those skilled in
the art. For example, other embodiments may address financial risk
scores other than credit-worthiness scores. These financial risk
scores can predict future consumer financial behaviors such as
delinquency, bankruptcy, and profitability.
* * * * *