U.S. patent application number 15/482318 was filed with the patent office on 2017-09-28 for indirect monitoring and reporting of a user's credit data.
The applicant listed for this patent is CONSUMERINFO.COM, INC.. Invention is credited to Sheldon Kasower.
Application Number | 20170278182 15/482318 |
Document ID | / |
Family ID | 58670550 |
Filed Date | 2017-09-28 |
United States Patent
Application |
20170278182 |
Kind Code |
A1 |
Kasower; Sheldon |
September 28, 2017 |
INDIRECT MONITORING AND REPORTING OF A USER'S CREDIT DATA
Abstract
Methods and systems of monitoring and reporting of changes to a
user's credit data are provided. One embodiment includes providing
a service, hosted by a data server, that allows the user to access
the service via a communication terminal. The service may also
request enrollment data, including identity verification data, from
the user. Further, the service may periodically access and monitor
the user's credit data for a change in the user's credit data via a
connection between the data server and a credit bureau even if the
data server has not received sufficient identity verification data
from the user. Additionally, the service may determine whether a
change detected in the user's credit data is a significant event.
When an event or a significant event in the user's credit data is
detected, the service may alert the user of the fact that an event
has occurred even if the data server has not received sufficient
identity verification data from the user.
Inventors: |
Kasower; Sheldon; (Bell
Canyon, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
CONSUMERINFO.COM, INC. |
Costa Mesa |
CA |
US |
|
|
Family ID: |
58670550 |
Appl. No.: |
15/482318 |
Filed: |
April 7, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13069896 |
Mar 23, 2011 |
9652802 |
|
|
15482318 |
|
|
|
|
61316994 |
Mar 24, 2010 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 40/00 20130101 |
International
Class: |
G06Q 40/00 20060101
G06Q040/00 |
Claims
1. (canceled)
2. A method comprising: by a computing system of one or more
processors, obtaining information identifying a credit history
event in a credit history associated with a user, wherein the
credit history of the user is monitored; determining an enrollment
status of the user, indicating whether the user is a complete
enrollee in a credit monitoring service or is an incomplete
enrollee in the credit monitoring service; and generating, based on
the enrollment status, a notification to be transmitted to the
user, wherein based on the user being a complete enrollee, the
notification includes detailed information associated with the
credit event, and wherein based on the user being an incomplete
enrollee, the notification includes: information alerting the user
to the credit history event, and a link to an internet-accessible
user interface indicating enrollment information associated with
the user that is required before providing the detailed
information.
3. The method of claim 2, further comprising: monitoring, by the
system, credit history associated with the user; wherein said
identifying the credit history event in the credit history
associated with the user is based on said monitoring.
4. The method of claim 2, wherein monitoring credit history
associated with the user is performed by a third party system, and
wherein the system receives information from the third party
system.
5. The method of claim 2, further comprising: obtaining
acknowledgement that the user's enrollment status has been updated
to a complete enrollee and transmitting, to the user, the detailed
information associated with the credit history event.
6. The method of claim 2, wherein enrollment status as an
incomplete enrollee indicates that the user has provided some but
not all of the enrollment information needed to enroll in the
credit monitoring service.
7. The method of claim 2, wherein enrollment status as an
incomplete enrollee indicates that the user has not provided
enrollment information usable to enroll in the credit monitoring
service.
8. The method of claim 7, wherein the user is indicated as an
incomplete enrollee in response to information regarding the user
being provided from a third party.
9. The method of claim 8, wherein the third party comprises a
marketing entity, a merchant, or a lender.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to, and is a continuation
of, U.S. patent application Ser. No. 13/069,896, filed Mar. 23,
2011, titled INDIRECT MONITORING AND REPORTING OF A USER'S CREDIT
DATA. U.S. patent application Ser. No. 13/069,896 claims the
benefit of U.S. Provisional Pat. App. No. 61/316,994, filed Mar.
24, 2010, entitled "METHODS AND SYSTEMS FOR INDIRECT MONITORING AND
REPORTING OF A USER'S CREDIT REPORT." Each of these applications is
incorporated by reference in their entirety.
BACKGROUND
[0002] Field
[0003] This disclosure generally relates to indirect monitoring of
a user's credit data, and more particularly to methods and systems
for indirect monitoring and reporting of changes to a user's credit
data.
[0004] Description of the Related Art
[0005] Conventional credit monitoring services, such as those
provided by current credit reporting bureaus, require the user to
enroll into the credit monitoring service prior to the user being
able to, for example, access their credit report from the credit
monitoring service, or receive detailed alerts of changes to the
user's credit data from the credit monitoring service that explain
in detail what has changed. The enrollment process typically
includes an extensive questionnaire that requires the user to
provide enrollment information, including, for example, user
identity information data, user credit data, user customized
settings data, and identity verification data.
[0006] The identity verification data is provided to ensure that an
unwanted third party is not able to gain access to the details of
the user's credit information. In order for the enrollment process
to be complete, so that users can view the details of their credit
data (such as credit data included in a credit report provided to
the consumer) or receive notification alerts of changes to their
credit data from the credit monitoring service, users must provide
sufficient identity verification data to the credit monitoring
service. In some systems, if a user has not entered sufficient
identification verification data, the credit monitoring service may
determine that the user has not finished enrollment process and the
credit monitoring service will not monitor the user's credit data
or send notification alerts to the user.
[0007] However, in many instances the user does not provide
sufficient identity verification data. This may occur even though
the user has already paid for the service. The user may not provide
the identity verification data because of time constraints, because
the user does not have all necessary information on hand, or simply
because the user forgets to provide the identity verification
data.
[0008] This can result in the user thinking he has completed the
registration process and is now enrolled within the credit
monitoring service, even though the user has not finished the
enrollment process. Or the user may be under the assumption that
the identity verification data can be entered once the user is sent
a notification alert by the credit monitoring service. However,
this may not be the case, as conventional credit monitoring
services do not monitor credit reports or send notification alerts
to users that have not entered sufficient identity verification
data.
[0009] Thus, the user is lulled into a false sense of security,
because the user has likely paid for the service and expects the
credit monitoring service to be monitoring the user's credit report
and sending notification alerts to the user, despite not having
entered sufficient identity verification data.
SUMMARY
[0010] This application provides methods and systems for indirect
monitoring and reporting of changes to a user's credit report. The
methods and systems provided herein may provide a notification
alert of the fact that a change or a significant event has occurred
in a user's credit report, without providing details as to what
change or significant event has occurred, even if the user has not
provided sufficient identity verification data. The methods and
systems provided herein also may enable the user to save
significant time in not having to complete the lengthy process of
entering identity verification data, until, for example, a change
or significant event to the user's credit report is detected by the
credit monitoring service.
[0011] Once a change or significant event is detected by the credit
monitoring service, some embodiments of the methods and systems
provided herein may alert the user of the fact that a change or a
significant event has occurred. In an embodiment, the notification
alert does not provide any details of the change or the significant
event, as such details are only provided to users that have entered
sufficient identity verification data. Unlike existing credit
monitoring services, the notification alert may elicit further
investigation by the user who can then act immediately to provide
the necessary identity verification data in order to obtain details
of the change or the significant event. Thus, the user is
incentivized to complete the authentication process (e.g., provide
sufficient necessary identity verification data) for their own
protection.
[0012] Accordingly, some embodiments described herein allow the
user to be able to bypass the authentication steps (e.g., enter the
identity verification data) during the enrollment process and still
provide the user with the service of monitoring the user's credit
report and notifying the user of the fact that a change or
significant event has occurred. Thus, the user obtains the benefit
of being enrolled with the credit monitoring service and the credit
monitoring service can charge the user for its service, even if the
user has not provided any identification verification data. When
the user is notified that a change or significant event has
occurred, the user can then finish the authentication process
(e.g., provide sufficient identity verification data) in order to
see the specific details of the change or significant event.
[0013] In one embodiment, a method for indirect monitoring and
reporting of changes to a user's credit report is provided. The
method includes providing a service, by a monitoring device, that
allows the user to access the service via a communication terminal.
The method may also include the service requesting enrollment data,
including identity verification data, from the user. Further, the
method may include the service periodically accessing and
monitoring the user's credit report for a change in the user's
credit report via a connection between the monitoring device and
one or more credit bureaus (and/or agents of the credit bureaus)
even if the monitoring device has not received any identity
verification data from the user. Additionally, the method may
include determining whether a change detected in the user's credit
report is a significant event. When a significant event in the
user's credit report is detected, the monitoring device may be
configured to alert the user of the fact that a significant event
has occurred, without providing details of the significant event,
even if the data server has not received any identity verification
data (and/or other enrollment information) from the user.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] FIG. 1 is a high-level block diagram of a monitoring device
in communication with a credit bureau, multiple user computing
devices, and a data store.
[0015] FIG. 2 is a block diagram illustrating one embodiment of the
credit monitoring device of FIG. 1.
[0016] FIG. 3 is a flowchart illustrating one embodiment of a
method of monitoring credit data of users.
[0017] FIG. 4 is an example of an alert email that may be sent to a
user who has not provided sufficient identity verification data
requested by the indirect credit monitoring service.
[0018] FIG. 5 is an example of an alert email that may be sent to a
user who has provided sufficient identity verification data
requested by the indirect credit monitoring service.
[0019] FIG. 6 is a flowchart illustrating one embodiment of a
method of providing credit monitoring alerts.
[0020] FIG. 7 is an example notification transmitted to a user.
DETAILED DESCRIPTION
[0021] In the following detailed description, reference is made to
the accompanying drawings that form a part hereof, and in which is
shown by way of illustration specific illustrative embodiments.
These embodiments are described in sufficient detail to enable
those skilled in the art to practice what is claimed, and it is to
be understood that other embodiments may be utilized without
departing from the spirit and scope of the claims. The following
detailed description is, therefore, not to be taken in a limiting
sense.
[0022] The embodiments presented herein are directed to methods and
systems for indirect monitoring and reporting of changes to a
user's credit report. In some embodiments, the methods and systems
for indirect monitoring and reporting of changes to a user's credit
report allows the user to become aware of the fact that a change or
significant event has occurred in their credit report, without
specific details as to the change or significant event. This may
occur, for example, even if the user has completed enrollment in a
credit monitoring service. For example, in one embodiment the
credit monitoring service may monitor credit files of individuals
that have not provided any enrollment information to the credit
monitoring service. In other embodiments, the credit monitoring
service may monitor credit files of individuals that have partially
completed enrollment in a credit monitoring service, but have not
provided all of the information necessary to complete the
enrollment, such as not providing sufficient identity verification
data. Thus, the user may be able to bypass the authentication steps
during the enrollment process of the credit monitoring service, for
example by not entering identity verification data into the system,
while the system still provides the user with the service of
monitoring the user's credit report and notifying the user when a
change or a significant event to the user's credit report occurs,
without providing details of the change or the significant
event.
[0023] In one embodiment, examples of significant events in the
user's credit report that would cause a notification alert to be
sent to the user include, for example, an application for or an
addition of a new credit line (e.g., a new credit card, loan or
mortgage account). Other significant events may include, for
example, a change of address, an account reported for collection,
and other such events. In an embodiment, examples of changes in the
user's credit report that may not cause a notification alert to be
sent to the user include, for example, current payment
notifications that change the total amount owed for a particular
credit line. However, in other embodiments, the types of changes in
the user's credit report that would cause a notification alert to
be sent to the user can be modified based on the requirements of
the credit monitoring service or the user. Thus, the events deemed
significant by the system may, in an embodiment, be configurable by
either the user or by an administrator of the service.
[0024] As the credit report is the basis of most credit scores, the
embodiments herein thus advantageously ensure the user is aware of
the fact that changes or significant events to the user's credit
report have occurred even if the user has not provided sufficient
identity verification data to the credit monitoring service. The
embodiments described herein also allow the credit monitoring
service to provide the user with a portion of the service the user
may have already paid for even though the user has not yet provided
sufficient information to complete enrollment in a credit
monitoring service. Thus, the embodiments described herein allow
the user to obtain the benefits of being enrolled in a credit
monitoring service, even though the user has not yet finished
providing sufficient enrollment data, such as identity verification
data. Also, the embodiments described herein allow the indirect
credit monitoring service to monitor the user's credit report and
send notification alerts to the user that a change or a significant
event has occurred, even though the user has not yet provided
sufficient enrollment data.
[0025] In some embodiments, indirect credit monitoring (e.g.,
monitoring credit data of an individual that has not completed
enrollment in a credit monitoring service) includes alerting users
of any changes detected in the users' credit data (e.g., one or
more credit reports may be accessed in order to detect changes in a
particular user's credit data). In other embodiments, indirect
credit monitoring includes alerting users of only changes detected
in the user's credit data that are determined to be significant
events. The rules for determining whether a change to a user's
credit data is a significant event can be set by the credit
monitoring service and/or by the user.
[0026] Enrollment information may include, for example, user
identity information data, user credit data, user customized
settings data, and/or identity verification data. User identity
data may include, for example, name, home address, home and work
phone numbers, social security number, and/or driver's license
number. User credit data may include, for example, credit card
information of credit cards used by the user, loan and mortgage
information, and/or savings and checking bank account information.
User customized settings data may include, for example, username
settings, payment for service information, preferred alert
communication information, and/or the like. Identity verification
data includes password settings, security questions and answers
and/or any other data used to prevent unwanted third parties from
gaining access to the user's credit information stored in the
service database. Depending on the embodiment, the credit
monitoring service may use all of the above data or any subset
thereof, and may also use other such data, for enrolling
individuals in a credit monitoring service.
[0027] Depending on the embodiment, various communications options
may be employed in order to alert the user of changes or
significant events to the user's credit report. Email to the user
is described in detail as one form of communication used by various
embodiments. However, other forms of communication may also be used
to alert users of changes or significant events in the respective
user's credit report. Such communication options include, for
example, email, text message (e.g., short messaging service--SMS),
courier mail, voice message, telephone calls, social networking
systems, MMS messages, postal mail, and so forth. Combinations of
communication options may be used as well, for example to more
efficiently reach a user. In an embodiment, the mode or modes of
communication employed for a particular alert are chosen based on
the nature or content of the alert. For example, in an embodiment,
the system would determine whether a particular credit alert is
urgent or not, and it would send urgent alerts by text message or
phone to ensure a faster response from the user, while sending
non-urgent alerts by email in order to avoid having the user incur
telecommunications costs.
[0028] FIG. 1 is a high-level block diagram of an of a monitoring
device 110 in communication with a credit bureau 170, multiple user
computing devices 130, and a data store 120. In one embodiment, the
monitoring device 110 acts as the central location for credit
monitoring, including indirect credit monitoring of individuals
that have not completed enrollment. The monitoring device 110
comprises one or more computer processors, either within a single
computing device or within several computing devices connected by a
network or other form of communication. The monitoring device 110
may further be configured to communicate with external data
sources, such as public records data sources. The monitoring device
110 may also maintain data records such as public records
internally or at the data store 120. These records may be used, for
example, to verify enrollment information received from users.
[0029] The data store 120 stores enrollment information including
user identity data, user credit data, user customized settings
data, and/or identity verification data. The data store 120 may
also store credit information obtained from the credit bureau 170
(or other sources of credit data). The data store 120 may be
internal to the monitoring device 110 or external to the monitoring
device 110 and operated on separate computing devices. In an
embodiment, the data store 120 is operated by an external service
provider. In an embodiment, the monitoring device 110 communicates
with the data store 120 via a standard protocol such as HTTP or
ODBC. The data store 120 may be a relational database such as a SQL
database, or a non-relational database.
[0030] A user of the user computing devices 130A can access the
indirect credit monitoring service, hosted by the monitoring device
110, via the network 140, which may include one or more of any
available networks, such as local area networks, personal area
networks, wide area networks, and/or the Internet. The user
computing devices 130A can be any type of device that can access
the network 140, such as, for example, a desktop computer, a laptop
computer, a mobile phone, or any other suitable device. The user
computing devices 130A may communicate with the monitoring device
110 via any number of networking protocols, whether standard
protocols or protocols specifically developed for the application.
In an embodiment, the user computing devices 130 communicate using
web pages via an HTTP or HTTPS protocol.
[0031] A user of the user computing device 130B, can also access
the indirect credit monitoring service, hosted by the monitoring
device 110, via a direct line 150. In one embodiment, the user
computing device 130B is a land line telephone or a mobile phone
and the direct line 150 is a telephone line. In this embodiment,
the user calls a telephone number that provides the user access to
the monitoring device 110. The user may interact with the
monitoring device 110 using an automated voice prompt service, for
example, which may recognize user input based on either dial-tone
numbers or voice recognition. Additionally, other communications
protocols such as SMS text messages may be used to communicate
between the user computing device 130B and the service. In an
embodiment, the communication is not directly between the user
computing device 1308 and the monitoring device 110, but rather is
transmitted through one or more intermediary devices.
[0032] In the embodiment of FIG. 1, the monitoring device 110 is
also in communication with the credit bureau 170 via a secure data
line 160. The implementation 100 allows the monitoring device 110
to act as a hub between users and the credit bureau 170 in order to
monitor and report the fact that a change or a significant event
has occurred to the user's credit report. In other embodiments, the
monitoring device 110 communicates with the credit bureau, and/or
other credit data devices, via the network 140.
[0033] FIG. 2 is a block diagram illustrating one embodiment of the
credit monitoring device 110 (FIG. 1). In one embodiment, the
credit monitoring device 110 is configured to interface with
multiple devices and/or data sources, such as in the exemplary
network configuration of FIG. 1. The credit monitoring device 110
may be used to implement certain systems and methods described
herein. For example, in one embodiment the credit monitoring device
110 may be configured to monitor credit data of consumers,
including consumers that have not completed enrollment in a credit
monitoring service (e.g., the consumers may not have completed a
validation, or other, portion of enrollment). The functionality
provided for in the components and modules of the credit monitoring
device 110 may be combined into fewer components and modules or
further separated into additional components and modules.
[0034] In general, the word module, as used herein, refers to logic
embodied in hardware or firmware, or to a collection of software
instructions, possibly having entry and exit points, written in a
programming language, such as, for example, C, C++, or C#. A
software module may be compiled and linked into an executable
program, installed in a dynamic link library, or may be written in
an interpreted programming language such as, for example, BASIC,
Perl, or Python. It will be appreciated that software modules may
be callable from other modules or from themselves, and/or may be
invoked in response to detected events or interrupts. Software
modules may be stored in any type of computer-readable medium, such
as a memory device (e.g., random access, flash memory, and the
like), an optical medium (e.g., a CD, DVD, BluRay, and the like),
firmware (e.g., an EPROM), or any other storage medium. The
software modules may be configured for execution by one or more
CPUs in order to cause the credit monitoring device 110 to perform
particular operations.
[0035] It will be further appreciated that hardware modules may be
comprised of connected logic units, such as gates and flip-flops,
and/or may be comprised of programmable units, such as programmable
gate arrays or processors. The modules described herein are
preferably implemented as software modules, but may be represented
in hardware or firmware. Generally, the modules described herein
refer to logical modules that may be combined with other modules or
divided into sub-modules despite their physical organization or
storage.
[0036] In one embodiment, the credit monitoring device 110
includes, for example, one or more server or a personal computer
that is IBM, Macintosh, or Linux/Unix compatible. In another
embodiment, the credit monitoring device 110 comprises one or more
laptop computer, smart phone, personal digital assistant, or other
computing device, for example. In one embodiment, the credit
monitoring device 110 includes one or more central processing units
("CPU") 220, which may include one or more conventional or
proprietary microprocessors. The credit monitoring device 110
further includes a memory 240, such as random access memory ("RAM")
for temporary storage of information and a read only memory ("ROM")
for permanent storage of information, and a data store 200, such as
a hard drive, diskette, or optical media storage device. In certain
embodiments, the data store 200 stores credit data of consumer
local to the credit monitoring device 110. For example, the data
store 200 may store previous credit data of consumers that are
monitored by the credit monitoring service so that new credit data
received from a credit bureau may be compared to the stored data in
order to identify possible significant changes in the credit data.
Depending on embodiment, such data may be stored on one or both of
the data store 200 and/or the data store 120 (FIG. 1). Embodiments
of data store 200 may store data in databases, flat files,
spreadsheets, or any other data structure known in the art.
Typically, the modules of the credit monitoring device 110 are in
communication with one another via a standards based bus system. In
different embodiments, the standards based bus system could be
Peripheral Component Interconnect (PCI), Microchannel, SCSI,
Industrial Standard Architecture (ISA) and Extended ISA (EISA)
architectures, for example. In another embodiment, the credit
monitoring device 110 leverages computing and storage services
available over the Internet (cloud computing).
[0037] The credit monitoring device 110 is generally controlled and
coordinated by operating system and/or server software, such as the
Windows 95, 98, NT, 2000, XP, Vista, Linux, SunOS, Solaris, PalmOS,
Blackberry OS, or other compatible operating systems. In Macintosh
systems, the operating system may be any available operating
system, such as MAC OS X. In another embodiment, the credit
monitoring device 110 may be controlled by a proprietary operating
system. Conventional operating systems control and schedule
computer processes for execution, perform memory management,
provide file system, networking, and I/O services, and provide a
user interface, such as a graphical user interface ("GUI"), among
other things.
[0038] The exemplary credit monitoring device 110 may include one
or more commonly available input/output (I/O) devices and
interfaces 230, such as a keyboard, mouse, touchpad, and printer.
In one embodiment, the I/O devices and interfaces 230 include one
or more display device, such as a monitor, that allows the visual
presentation of data to a user. More particularly, a display device
provides for the presentation of GUIs, application software data,
and multimedia presentations, for example. In one embodiment, I/O
devices and interfaces 230 comprise devices that are in
communication with modules of the credit monitoring device 110 via
a network, such as network 140 and/or any secured local area
network, for example. In the embodiment of FIG. 2, the I/O devices
and interfaces 230 provide a communication interface to various
external devices. For example, in this embodiment the credit
monitoring device 110 is in communication with the network 140,
such as any combination of one or more LANs, WANs, or the Internet,
for example, via a wired, wireless, or combination of wired and
wireless, connections via a network interface of the I/O devices
and interfaces 230.
[0039] In the embodiment of FIG. 2, the credit monitoring device
110 also includes application modules that may be executed by CPU
220. More particularly, the application modules include enrollment
module 250 and credit monitoring module 260. In one embodiment, the
enrollment module 250 provides user interfaces and receives
responses from consumers for the purpose of enrolling the consumers
into a credit monitoring service. In order for enrollment to
complete, a predetermined set of information is required from a
consumer, such as demographic information, authentication
information, payment information, and/or other information. As
described further below, in some embodiments credit monitoring may
be performed prior to the enrollment module 250 receiving all of
the required enrollment information. In such an embodiment, the
credit monitoring device 110 may provide a simple notice to a
consumer when activity has been detected in the consumer's credit
data, but only provide details of the activity after any missing
enrollment information is provided to the enrollment module 250.
The credit monitoring module 260 is configured to monitor credit
data associated with each of a plurality of consumers. Credit
monitoring may be performed in any known manner, such as by
comparison of new credit data (e.g., a current month's credit
report) with older credit data (e.g., a past month's credit
report).
[0040] FIG. 3 is a flowchart illustrating one embodiment of a
method of monitoring credit data of users, including monitoring of
credit data of users that have not completed enrollment with the
credit monitoring service. The method may be performed on a system
such as that monitoring device 110 of FIG. 1, or on another system.
Depending on the embodiment, the method of FIG. 3 may include fewer
or additional blocks and/or the blocks may be performed in a
different order than is illustrated.
[0041] The method 300 begins at block 310 where the indirect credit
monitoring service, hosted by the monitoring device 110, waits for
a user to access and request enrollment into the indirect credit
monitoring service to monitor and report changes or significant
events to the user's credit report. As shown in FIG. 1, the user
can access the indirect credit monitoring service, hosted by the
monitoring device 110, via the network 140 using one of the
plurality of user computing devices 130A or via the direct line 150
using the user computing device 1308. The method 300 then proceeds
to block 320.
[0042] At block 320, the monitoring device 110 receives an
enrollment request from the user and the monitoring device 110
provides an input questionnaire to the user to get enrollment
information (e.g., user identity data, user credit data, customized
settings data, and/or identity verification data) from the end
user. In one embodiment, the questionnaire is presented to the user
as one or more HTML forms with which the user can submit responses.
The questionnaire may also be presented in other forms, such as by
telephone voice prompts, emails, text messages, and so forth. In an
embodiment, the monitoring device 110 provides multiple ways for
users to respond to the questionnaire, so that users have options
as to how to provide responses to the system. In one embodiment,
the monitoring device 110 uses responses from the user to determine
further enrollment information to request. For example, if the user
indicates having a home mortgage, the system may request
information about the particular home and the amount of the
mortgage, but not ask those detailed questions if the user does not
indicate having a home mortgage. Additionally, the user may provide
payment information in embodiments where the credit monitoring
service, or indirect credit monitoring service, require payment,
either before the questionnaire, after the questionnaire, or at
both times. The method 300 then proceeds to block 330.
[0043] At block 330, the monitoring device 110 then waits for the
user, using one of the plurality of user computing devices 130A-B,
to provide enrollment information in response to questions included
in the input questionnaire. Enrollment information received by the
monitoring device 110 may then be stored in the data store 120. In
an embodiment, a user account is located or created for the user,
and the enrollment information received and stored in the database
is associated with the appropriate user account.
[0044] In one embodiment, the user is provided with an option to
enroll in an indirect monitoring service and, thus, certain
information regarding the user, such as validation information, is
not requested by the monitoring device 110. Alternatively, the
monitoring device 110 may request enrollment information that is
sufficient to complete enrollment of the user in a full monitoring
service that provides alert details to users without later
requiring further enrollment information. In this embodiment, if
the user fails to provide sufficient information to complete
enrollment in the monitoring service, the monitoring device 110 may
default to enrolling the user in an indirect monitoring service.
Depending on the embodiment, certain minimum information
requirements may be required before enrolling the user even in the
indirect monitoring service.
[0045] In other embodiments, users may be enrolled in an indirect
monitoring service without directly providing any information to
the credit monitoring device 110, possibly without ever contacting
the credit monitoring service (e.g., via a website provided by the
credit monitoring device 110). For example, if compliant with
applicable credit monitoring regulations, the credit monitoring
device 110 may receive names of users to add to the indirect credit
monitoring service from sources other than the users themselves,
such as from merchants or lenders with which the users have done
business. Thus, in one embodiment a user may receive an alert of
potentially fraudulent activity in the user's credit data without
the user ever providing enrollment information to a credit
monitoring service (e.g., the user's identification information may
have been provided to the credit monitoring service by a lender of
the user). Accordingly, in certain embodiments the method of FIG. 3
does not include blocks 310, 320 and/or 330.
[0046] Also, at this point or at other points during this method,
the monitoring device 110 may verify the enrollment information.
For example, address data may be verified against public records
data. Data may also be checked to ensure that it is not
conflicting: for example, a ZIP code may be checked to ensure that
it is within the city and state specified by the user. Other
information, such as biographical information about the user,
credit information, and any other information received by the
monitoring device 110, may be verified by the system. In an
embodiment, the monitoring device 110 notifies the user if
information cannot be verified or is found to be inconsistent or
incorrect. The monitoring device 110 may also discard or attempt to
correct such information.
[0047] Alternatively, or in addition to, presenting the user with a
questionnaire and receiving responses, the monitoring device 110
may also collect enrollment information from third-party sources.
For example, information about a user's home or work address may be
collected from public data sources, from third-party associates, or
other sources of data.
[0048] The method 300 then proceeds to block 340 where the
monitoring device 110 periodically accesses and monitors the user's
credit data and waits for a change in the user's credit data. In
one embodiment, the monitoring device 110 accesses and monitors the
user's credit data on a daily basis. In other embodiments the
monitoring device 110 can access and monitor the user's credit data
on an hourly, weekly, monthly, quarterly or yearly basis, based on
the needs of the indirect credit monitoring service or the user. In
an embodiment, the monitoring device 110 is configured to
automatically receive notifications from a credit report service,
where the credit report service offers such notifications. Credit
data, as discussed herein, includes any portion of data that is
maintained by one or more credit bureaus and/or is derived from
such data. For example, credit data may include some or all of the
data that is provided in credit reports that are provided to
consumers/lenders. Credit data may include additional data that is
not included in credit reports.
[0049] In some embodiments, where only significant events detected
in the user's credit report are alerted to the user, the flowchart
300 proceeds to block 350 when the monitoring device 110 identifies
a change in the user's credit report. In other embodiments, where
any change detected in the user's credit report is alerted to the
user, the flowchart 300 proceeds to block 360 when the monitoring
device 110 identifies a change in the user's credit report.
[0050] In embodiments that include block 350, the monitoring device
110 determines whether the change detected in the user's credit
report is a significant event. In these embodiments, the indirect
credit monitoring service or the user has specified certain changes
in the user's credit report that are significant events worth
noting to the user. Examples of changes in the user's credit report
that can be considered a significant event include, for example, an
application for or an addition of a new credit line (e.g., a new
credit card, loan or mortgage account). Other significant events
include, for example, a change of address, an account reported for
collection, and so forth. If the monitoring device 110 determines
that the change detected in the user's credit report is a
significant event, the flowchart 300 proceeds to block 360. If the
monitoring device 110 determines that the change detected in the
user's credit report is not a significant event, the flowchart 300
proceeds back to block 340.
[0051] The determination of whether an event is significant may be
based on any number of factors. For example, the type of event, as
described above, may be used to determine whether an event is
significant. User-specified preferences or administrator-provided
settings may also be used in making the determination. In an
embodiment, the determination of whether an event is significant
for a user depends on the enrollment information that the user has
provided. So, for example, if the user has provided sufficient
enrollment information, then the system may deem more or fewer
events significant than if the user has not provided sufficient
enrollment information.
[0052] At block 360, the monitoring device 110 accesses the data
store 120 and determines whether the user has provided sufficient
identity verification data. If the monitoring device 110 determines
that the user has not provided sufficient identity verification
data, the flowchart proceeds to block 370. If the monitoring device
110 determines that the user has provided sufficient identity
verification data, the flowchart proceeds to block 380. The
particular identity verification data may include all of the
enrollment data, or it may be any subset of that enrollment data.
In an embodiment, determining whether sufficient identity
verification data has been provided involves determining whether
all of the requested identity verification data has been provided.
In other embodiments, the system may only require a subset of the
identity verification data to be provided. For example, the system
may request three forms of ID but only require two for
verification. The subset of identity verification that is required
may depend on characteristics of the user assessed from the
enrollment information or from other sources, in an embodiment. For
example, the system may require more identity verification data if
a user is determined to have a history of identity theft or if
there is a freeze or hold placed on the user's credit accounts. The
monitoring device 110 may apply one or more authorization rules to
perform this determination. The authorization rules may be fixed or
modifiable by an administrator or other entity, and may be embodied
in executable code, preference settings, configuration files, data
tables, or the like.
[0053] In an embodiment, the block 360 determination of whether the
user has provided sufficient identity verification data is
performed prior to initiating monitoring at block 340. In such an
embodiment, the system may store the result of the determination in
association with the user, and thereafter, when the user is to be
notified of an event, the system uses the stored result of the
determination in order to determine the type of alert to send to
the user. In another embodiment, the system determines whether the
user maintains separate lists or queues of users who have provided
sufficient identity verification data and users who have not
provided sufficient identity verification data, and then responds
to events based on the queue or list in which the associated user
is placed.
[0054] At block 370, the monitoring device 110 prepares and sends
an alert message to the user that a change and/or a significant
event has been detected in the user's credit data. The alert
message can be sent to the user, for example, via email, via text
message, via courier mail, via voice message, or via other
communications methods described in this specification or known to
those of skill in the art. FIG. 4 is an example email that may be
sent to a user in order to notify the user that significant
activity has been detected in the user's credit data (e.g., block
370). The email of FIG. 4 does not provided details regarding the
detected activity, but does include instructions that may be
followed by the consumer in order to obtain details regarding the
detected activity. For example, the consumer may visit a website of
the credit monitoring service and complete enrollment into a credit
monitoring program in order to have access to details regarding the
detected activity. The details omitted from the communication may
include, in various embodiments, identifying information relating
to the user, dollar amounts and/or account balances relating to the
credit event, credit card numbers, account numbers, address
information, loan information, credit scores, and/or other such
credit-related or personal information. In some embodiments, the
information to be omitted may be specified by an administrator of
the credit monitoring service or by the user.
[0055] Depending on the embodiment, the content of the emails of
Figure is determined by system settings set by an administrator of
the system, user preference settings, and/or the event that was
detected. These settings may determine, among other things, the
address to which the emails are sent, the time of day or day of the
week when the email is sent, the level of detail to be sent, the
text content of the email, the reply address for the email, and so
on. Additionally, the system settings may indicate whether the
alert is to be sent by email or by other communication means. In an
embodiment, the system sends multiple communications, of the same
type or of different types, to the user on a periodic basis after
the event is detected.
[0056] The embodiments described above and other embodiments allow
the user to become aware of the fact that a change or significant
event to their credit data has occurred even if the user has not
provided sufficient identity verification data required to finish
enrollment with the indirect credit monitoring service. They also
allow the indirect credit monitoring service to provide the user
with a portion of the service the user may have already paid for
even though the user has not provided sufficient identity
verification data. Once the alert message is sent to the user, the
method then proceeds back to block 350.
[0057] At block 380, the monitoring device 110 prepares and sends a
detailed alert message to the user that a change or significant
event in the user's credit data has been detected. The detailed
alert message can be sent to the user, for example, via email, via
text message, via courier mail, via voice message, or via other
communications methods described in this specification or known to
those of skill in the art. FIG. 5 is an example email may be sent
to a user that has completed enrollment in a credit monitoring
program, in response to detection of significant activity in the
user's credit data (e.g., block 380). In the embodiment of FIG. 5,
the notification does not provide the specific details of the
detected activity, but in other embodiments, and as authorized by
applicable regulations, such an email notification may include
details regarding the particular detected activity. For example, in
other embodiments, the email 500 may both notify the user of the
fact that a significant event in the user's credit data has been
detected, and also specify in detail what has changed in the credit
data. The example email 500 also provides a hyperlink for the user
to access the indirect credit monitoring service, hosted by the
monitoring device 110, in order to see the user's credit data in
detail or to correct a possible error in the credit data. Once the
alert message is sent to the user, the method then proceeds back to
block 350. While email 500 notifies the user that a significant
event in the user's credit data has been detected, in other
embodiments, the email will alert the user of any change in the
user's credit data. The details included the communication may
include, in various embodiments, identifying information relating
to the user, dollar amounts and/or account balances relating to the
credit event, credit card numbers, account numbers, address
information, loan information, credit scores, and/or other such
credit-related or personal information. In some embodiments, the
information to be included may be specified by an administrator of
the credit monitoring service or by the user.
[0058] In an embodiment, the content of email 500 is determined by
system settings set by an administrator of the system, user
preference settings, and/or the event that was detected. These
settings may determine, among other things, the address to which
email 500 is sent, the time of day or day of the week when the
email is sent, the level of detail to be sent, the text content of
the email, the reply address for the email, and so on.
Additionally, the system settings may indicate whether the alert is
to be sent by email or by other communication means. In an
embodiment, the system sends multiple communications, of the same
type or of different types, to the user on a periodic basis after
the event is detected.
[0059] FIG. 6 is a flowchart illustrating one embodiment of a
method that may be performed by the monitoring device 110 in order
to provide credit monitoring alerts to enrolled consumers.
Depending on the embodiment, the method of FIG. 6 may include fewer
or additional blocks and/or the blocks may be performed in a
different order than is illustrated.
[0060] Beginning in block 610, a consumer is added to a monitor
list maintained by the monitoring device 110. In one embodiment,
the consumer information is provided directly by the consumer, such
as via an enrollment form that has been partially completed by the
consumer (e.g., either online or in paper form). In other
embodiments, the consumer information may be provided from other
sources, such as from a merchant that has recently completed a
transaction with the consumer. For example, a commercial website
may provide consumer information to the credit monitoring device
110 that is sufficient to allow the credit monitoring device 110 to
monitor the credit information of the consumer.
[0061] Next, in block 620, the monitoring device periodically
performs an analysis of the credit data associated with the
consumer in order to determine if changes in the credit data, such
as the significant events discussed above, have occurred. In some
embodiments, the actual analysis of credit data is performed by a
separate entity, such as by a credit bureau or agency of a credit
bureau. When an indication of activity with respect to the
consumer's credit data (e.g., "an alert") is received by the
monitoring device 110, the method continues to block 630 where a
notification of the detected activity is transmitted to the
consumer. In one embodiment, a notification such as the sample
notification 700 of FIG. 7 may be transmitted directly to the
consumer. As shown in the example of FIG. 7, in certain embodiments
the consumer is provided with information indicating that activity
with respect to the consumer's credit data has been undetected, and
is provided with an opportunity to view details regarding the
activity by enrolling in a credit monitoring service. Thus, such a
monitoring service that monitors credit data of non-enrolled
consumers may increase enrollment into the credit monitoring
service because consumers are encouraged to enroll in the credit
monitoring service in response to receiving notifications that
there is activity in the consumer's credit data. In other
embodiments, notification of activity in the consumer's credit data
may be provided to the consumer via the entity that provided that
consumers information to the monitoring device 110. For example, if
the consumers identification information was provided to the credit
monitoring device 110 by a commercial website, alerts regarding
activity in the consumer's credit data may be provided to the
consumer via the commercial website, such as via a messaging system
(e.g., an e-mail system) that is accessible through the commercial
website. The notification may be transmitted in any other manner,
such as via text messages, voice calls, or via a mail service, for
example.
[0062] In a further embodiment, the monitoring device 110 of FIG. 1
is configured to allow users to log in to the system and review
their credit data manually. In this embodiment, a user may log into
the system and then request information about the user's credit
history, for example by clicking on a hyperlink or otherwise
specifying a command. The monitoring device 110, upon receiving the
request, determines whether the user has provided sufficient
identity verification information. The determination may be
performed in real time, or the system may have previously made such
a determination and stored the result of the determination, in
which case the system looks up the stored result. Based on the
determination, the monitoring device 110 may present the user with
the requested information in response to determining that the user
has provided sufficient identity verification information, or the
monitoring device 110 presents the user with a request for identity
verification information otherwise. Thus, in this embodiment, the
system ensures that the user has provided sufficient identity
verification information prior to presenting requested information
about the user's credit report that may be confidential or
otherwise sensitive. Such a system could be implemented alone or in
combination with an embodiment of the monitoring system as
described previously.
[0063] In one embodiment, the monitoring device includes an
administration module configured to receive and store system
configuration information. Configurability of the system may be
useful, for example, where the desired alerts, enrollment
information, or other aspects of the system should be easily
changeable to meet consumer demands, legal requirements, marketing
campaigns, and so on. The administrative module may include
security features to ensure that unauthorized users cannot access
the administrative module, such as a password or encryption key
system. The administrative module may be accessible as web pages,
via a desktop application, directly at the data server, or by other
means.
[0064] An administrative module may enable an administrator to
configure the enrollment information to be requested. It may also
allow configuration of how the information is requested. For
example, an administrator may be able to select an order in which
the enrollment information is requested or separate the information
into several pages. In a system that uses a telephone service, an
administrator may, for example, be able to record voice prompts and
select the options available to users. The administrator may also
be able to configure what information is mandatory and optional,
set what information is sufficient to begin monitoring, set what
information is sufficient to provide detailed alert information,
and so on. This may be provided in the form of rules or
requirements specified by the administrator. The administrator may
also be able to configure payment systems to receive payments from
users.
[0065] The administrative module may also allow for configuration
of alerts to be sent to users. The administrator may be able to
define means of communication and provide the content of particular
communications, such as by providing a template email or template
sound recording. The administrator may also be able to configure
the determination of which events are significant and to be
reported. For example, the administrator may specify directly that
certain types of events are significant, or provide rules for
determining the significance of events. In some embodiments, the
consumer may specify which events are significant, and possibly
have various levels of significance that each are associated with
different notification actions. Thus, the administrative module may
provide an administrator with the ability to specify different
levels or scores of significance. The administrator may also be
able to configure the amount of information that is displayed or
presented to a user when that user has or has not provided
sufficient identity verification information to the system.
[0066] The administrative module may also allow for configuration
for receiving alerts from credit bureaus or receiving data from
other third-party sources. For example, the administrator may be
able to select different credit bureaus from which information is
to be collected. The administrator may also be able to specify the
frequency of collecting information. In certain embodiments, the
consumer may be able to customize certain of the settings discussed
with respect to the administrative module.
[0067] In an embodiment, the monitoring device 110 verifies the
user's enrollment information or identity verification information
multiple times. In one embodiment, this is done on a periodic
basis, and in another embodiment, this is done upon receiving
events or other activities on the system. The repeated verification
may include repeatedly determining if sufficient identity
verification information has been provided, determining if the
provided information is still accurate, or a combination of these
and other verifications. Such repeated verification may be
advantageous, for example, to detect when a user's personal
information has changed, so as to avoid communicating with an
outdated address, for example. It may also be advantageous in that
it may detect identity theft. In the case where the user's
information is determined to be no longer valid, the system may
take appropriate precautionary measures, including, for example,
alerting the user. The monitoring device 110 may also then treat
the user as not having provided sufficient identity verification
information, and thus send less detailed alert information to the
user, as described in this specification.
[0068] The embodiments disclosed in this application are to be
considered in all respects as illustrative and not limitative. The
scope of the invention is indicated by the appended claims rather
than by the foregoing description; and all changes which come
within the meaning and range of equivalency of the claims are
intended to be embraced therein.
* * * * *