Consumer data request fulfillment system

[0001] Maintaining communication with consumers is an important part of creating a stable business. Sometimes, however, an entity may lose communication with a consumer if, for example, the consumer moves to a new location or gets a new telephone number. Sometimes reestablishing communications is easy. Other times, such as when a consumer has failed to repay a loan and does not desire communications with a lender, reestablishing communications may be difficult. Accordingly, there is tremendous value in making it possible for entities such as lenders, banks, credit card issuers, and/or collections agencies to maintain and/or re-open lines of communication with their customers and consumers.

[0005] In an embodiment, a consumer data request fulfillment system enables a client to easily and speedily obtain consumer contact data that the client does not already possess. The consumer data request fulfillment system provides bulk consumer data to a client upon request. The bulk data may include, for example, encrypted consumer identifiers (IDs) and a less than complete subset (“partial subset”) of consumer contact information for a particular specified segment of consumers. The consumer data request fulfillment system may be operated by an entity with access to contact information, such as, for example, a credit bureau, and the bulk data may be drawn from consumer credit data sources and consumer contact data sources that may or may not be operated by a credit bureau. The partial subset of consumer contact information may include, for example, the last three digits of a telephone number and/or a portion of a street address or email address. Additional customer contact information may also be provided such as, for example, contact information type and/or contact information source. For example, one piece of a partial subset of consumer contact information may be: 295; type: telephone number; source: credit issuer application. Alternatively, only the last three digits of the contact information (such as, 295) may be provided or only the last three digits of the contact information and the type may be provided.

[0006] When selecting the subset of information to provide, it may be useful to select a more unique set of data, such as the last three digits of the phone number, rather than the first three digits of the number, which is the area code. In addition, it may be useful to the amount of data that will allow the client to determine whether it already has the contact information, balancing enough data to allow the comparison to be meaningful (for example, needing to provide more than just “.com” for the email address) but not too much data where the client can determine the full set of information without purchasing the remainder of the data (for example, providing the entire email address except for the “.com” at the end).

[0007] After receiving the bulk consumer data, the client has the opportunity to compare the partial subset of consumer contact information with contact information that the client may already possess for particular consumers. If the partial subset of consumer contact information does not match the contact information the client already possess, the client may then request from the consumer data request fulfillment system a full set of consumer contact information. For example, the client may send a request for consumer contact information by identifying particular consumers by their consumer IDs. The consumer data request fulfillment system will then provide the full set of consumer contact information to the client. The requests and request fulfillments are advantageously accomplished automatically by the consumer data request fulfillment system, enabling the client to obtain the consumer contact information it is missing conveniently and rapidly.

[0008] The partial subset of consumer contact information may be sent to a client in conjunction with a set of consumer credit data and encrypted consumer identifiers (IDs) already being sent to a client on a periodic basis.

[0009] An example transaction of the consumer data request fulfillment system according to an embodiment of the present disclosure may be instructive. Such a transaction may proceed, for example, as follows:

• • [0010] 1. Client requests from an entity data relating to set of its customers each identified by an ID.
  • [0011] 2. Entity provides the client with bulk data in response to the request. The bulk data includes, for each consumer identified by an ID:
    • [0012] a. Encrypted consumer ID.
    • [0013] b. Partial subset of consumer contact information (for example, 295), and for each partial subset of consumer contact information, the following may also be provided:
      • [0014] i. Contact information type (for example, telephone)
      • [0015] ii. Contact information source (for example, public record)
  • [0016] 3. Client desires contact information on consumer with an ID. Currently client has a telephone number for the consumer, 310-000-0000, but it has been disconnected. Client compares the partial subset of the telephone number provided by the entity to its own information, and finds that the partial subset of the telephone number is different (that is, the last three digits, 295, do not match the last three digits, 000).
  • [0017] 4. Client transmits request to entity for a full set of consumer contact information, identifying the particular consumer by its encrypted consumer ID.
  • [0018] 5. Entity responds to request by providing the full consumer telephone number to the client.

[0019] In other embodiments, the client's requests could be based on other criteria than by identifier and may be combined with a request for other data. Another example is as follows:

• • [0020] 1. Client requests from an entity (for example, a credit bureau) credit bureau data relating to middle-income consumers in the Los Angeles, Calif., area.
  • [0021] 2. The credit bureau provides the client with the bulk data in response to the request. The bulk data includes, for each consumer that falls into the specified category (for example, middle-income individuals in the Los Angeles, Calif. area):
    • [0022] a. Encrypted consumer IDs.
    • [0023] b. Consumer credit data.
    • [0024] c. Partial subset of consumer contact information (for example, partial email address with first letter and domain name) along with:
      • [0025] i. Contact information type
      • [0026] ii. Contact information source
      • [0027] iii. Last update date indicating that last time the particular piece of contact information was updated in the consumer contact data sources
  • [0028] 3. Client compares the partial subset of consumer contact information provided by the credit bureau with its own information, and finds that there are 1458 records where the information is different.
  • [0029] 4. Client transmits request to credit bureau for a full set of consumer contact information for the 1458 consumers, identifying each of the particular consumers by its encrypted consumer ID.
  • [0030] 5. Credit bureau responds to request by providing the full set of email address information to the client.

[0031] The previous instructive transactions are only illustrative examples of embodiments of the consumer data request fulfillment system, and it is to be understood that more or fewer communications may be involved, and/or the communications may happen in a different order. Additionally, more or less, or different types of, information may be passed between the client and the entity. As described in detail below, the client is typically required to provide payment for the data furnished by the entity. Also, as noted above, the consumer data request fulfillment system may be operated by an entity other than a credit bureau.

[0032] As used herein, the terms “individual” and/or “consumer” may be used interchangeably, and should be interpreted to include applicants, customers, single individuals as well as groups of individuals, such as, for example, families, married couples or domestic partners, and business entities.

[0033] More particularly, the terms “individual” and/or “consumer” may refer to: an individual subject of the consumer data request fulfillment system (for example, an individual person whose credit bureau data is being provided and/or contact information is being provided). The terms “customer” and/or “client” may refer to: a large receiver or purchaser of the data provided by the consumer data request fulfillment system (for example, a lender that is receiving a credit data and/or contact information on individuals); and/or a small (or individual) receiver or purchaser of the consumer credit and/or contact data or information that is provided and/or produced by the consumer data request fulfillment system.

[0034] In general, however, for the sake of clarity, the present disclosure usually uses the term “consumer” to refer to an individual subject of the consumer data request fulfillment system, the term “customer” or “client” to refer to a receiver or purchaser of the information provided by the consumer data request fulfillment system.

[0035] Embodiments of the disclosure will now be described with reference to the accompanying figures, wherein like numerals refer to like elements throughout. The terminology used in the description presented herein is not intended to be interpreted in any limited or restrictive manner, simply because it is being utilized in conjunction with a detailed description of certain specific embodiments of the disclosure. Furthermore, embodiments of the disclosure may include several novel features, no single one of which is solely responsible for its desirable attributes or which is essential to practicing the embodiments of the disclosure herein described.

[0036] FIG. 1 is a data flow diagram showing an embodiment of the consumer data request fulfillment system. The consumer data request fulfillment system includes a network 160, a client 170, a data request fulfillment module 150, consumer credit data sources 180, consumer contact data sources 190, and a payment processor 195.

[0037] In the consumer data request fulfillment system of FIG. 1, the client 170 is in communication with the data request fulfillment module 150 and the payment processor 195 over the network 160. Further, the data request fulfillment module 150 is in communication with the consumer credit data sources 180 and the consumer contact data sources 190.

[0038] Client 170 may be any receiver or purchaser of the data provided by the consumer data request fulfillment system. For example, the client 170 may be a lender, bank, credit card issuer, and/or collections agency.

[0039] The payment processor 195 may be any entity employed or used by the operator of the consumer data request fulfillment system to accept and process payments from clients. For example, the payment processor 195 may be a credit card transaction processor or other payment processor as known in the art. Preferably the payment processor communicates over the network 160 and may process many transactions and/or payments rapidly in real-time. Alternatively, the payment processor 195 may communicate over another type of connection or proprietary network. When payments are processed, both the client and the operator of the consumer data request fulfillment system are preferably notified instantly or nearly instantly. Additionally, typically payments are processed in an automated way. For example, when a payment is required by the data request fulfillment module 150, the payment processor 195 and the client 170 are automatically notified. The client 170 may be notified by the data request fulfillment module 150 directly, or indirectly by the payment processor 195. Then, once payment is received from the client 170 and processed by the payment processor 195, the data request fulfillment module 150 is automatically notified, either directly or indirectly. Thus, payment requests and notifications of payment completion are preferably accomplished quickly and automatically, facilitating rapid turnaround time between requests from the client 170 and fulfillment by the data request fulfillment module 150.

[0040] In the embodiment of FIG. 1, the network 160 comprises one or more of a LAN, WAN, and/or the Internet, for example, via a wired, wireless, or combination of wired and wireless communications link. The network 160 communicates with various computing devices and/or other electronic devices via wired or wireless communication links. In an embodiment, communications between the data request fulfillment module 150 and the consumer credit data sources 180 and consumer contact data sources 190 may be over a network similar to network 160. Alternatively, communications between data request fulfillment module 150 and consumer credit data sources 180 and consumer contact data sources 190 may be over a dedicated network or communications link, whether wired or wireless.

[0041] In an embodiment the data request fulfillment module 150 is implemented as a part of a computing system. In another embodiment, the data request fulfillment module 150 is implemented as a dedicated computing device. Further details concerning the implementation of the data request fulfillment module 150 and other aspects of the consumer data request fulfillment system, including the communications between the various components, will be described below in reference to FIG. 3.

[0042] The consumer credit data sources 180 and/or the consumer contact data sources 190 may include one or more internal and/or external databases, data sources, and physical data stores. The consumer credit data sources 180 may include internal and external data sources which store, for example, credit bureau data (for example, credit bureau data from File One™, including, for example, balances on lines of credit, and/or delinquency, among other things) and/or historical trade line data, among other things. The consumer contact data sources 190 may include internal and external data sources (such as, for example, MetroNet™) which store, for example, consumer contact information such as telephone numbers (such as, for example, land line and mobile), physical addresses (such as, for example, street addresses and post office boxes), email addresses, and so forth. Sources of consumer contact data may include, for example, consumer credit data (such as, for example, information from creditors, lenders, banks, and so forth) and/or publicly available records, among others. In some embodiments, one or more of the databases or data sources may be implemented using a relational database, such as Sybase, Oracle, CodeBase, and Microsoft® SQL Server, as well as other types of databases such as, for example, a flat file database, an entity-relationship database, and object-oriented database, and/or a record-based database.

[0043] The operation of the consumer data request fulfillment system, according to an embodiment, will now be described in reference to the data flow of FIG. 1. It should be understood that the following data flow is only illustrative, and should not be read to limit the scope of any of the claims of the present application. In particular, it is to be understood that more or fewer communications may be involved, and/or the communications may happen in a different order. Additionally, more or less, or different types of, information may be passed between the client and the credit bureau.

[0044] Referring to FIG. 1, at 1 the client 170 makes a request for credit data. The request is transmitted over the network 160 to the data request fulfillment module 150. The request may include identification of particular consumers about whom the client 170 would like to gather credit data. Alternatively, the request may include information about a particular segment, demographic, and/or group of consumers about whom the client 170 is interested.

[0045] At 2, the data request fulfillment module 150 processes the request by, among other things, accessing the consumer credit data sources 180 and consumer contact data sources 190. If a segment, demographic, and/or group of consumers has been identified by the client 170, the data request fulfillment module 150 may first determine the particular consumers within the segment, demographic, and/or group. For example, if the client 170 specifies “middle-income individuals in the Los Angeles, Calif. area,” the data request fulfillment module 150 may first determine the identities of the consumers that fall within that group. This may be accomplished by accessing consumer information from consumer credit data sources 180, by accessing information from consumer contact data sources 190, by accessing information from both consumer credit data sources 180 and consumer contact data sources 190, or by accessing demographic information and consumer identity information from sources not shown in FIG. 1. Once the identities or identifiers of the consumers are known, their credit data is accessed from the consumer credit data sources 180.

[0046] Optionally, in 2 the identified consumers' contact data and/or information is accessed from the consumer contact data sources 190. In an embodiment, the client 170 may specify whether contact data is desired. In another embodiment, contact data may be automatically be provided. In either case, as mentioned above the contact data may include, for example, telephone numbers (land line and mobile), physical addresses (such as street addresses and post office boxes), email addresses, and so forth. For each item of consumer contact information, a contact information type and a contact information source may also be included. The contact information type indicates what type of information the contact information is. For example, contact information types may include, but are not limited to, first telephone number, second telephone number, third telephone number, home telephone, work telephone, facsimile number, home address, work address, email address, cell, non-cell, and so forth. The contact information source indicates the source of the contact information. For example, the contact information sources may include, by are not limited to, published white pages, credit issuer application, credit issuer, public record, other, unknown, and so forth. For each consumer, none, one, or many piece of contact information may be accessed and, after partial obfuscation as described below, provided to client 170. For example, for a given consumer, multiple telephone numbers and/or physical addresses may be provided.

[0047] Continuing in 2, if consumer contact information is going to be provided to the client 170, once the contact information is located, a partial subset of the information is obtained. In other embodiments, the entire set of information is obtained, but truncated. In an embodiment, a portion of each piece of contact information is designated and/or identified to be provided to the client 170. The portion designated is selected such that the contact information may be identified by the client, and compared to their own contact information, but not be useable by the client. For example, for a telephone number, the last three digits of the number may be designated (for example, 295 or XXX-XXX-X295). Thus, in this example, the partial subset of the telephone number or truncated telephone number provided to the client 170 would include only the last three designated digits. Alternatively, other portions of the telephone number, or more or fewer digits, may be designated. Similar criteria may be applied to other types of consumer contact information. For example, a physical address may be truncated by designating only the street name (for example, Main Street; or XXXX Main St., XXXXXXXXX, XX XXXXX). Alternatively, the city and/or zip code may be designated (for example, Homeville, Calif.; or XXX X XXXX XXX, Homeville, Calif. XXXXX. For an email address, one, two, three, or more letters/numbers/symbols of the address may be designated (for example, john or johnXXXXXXXXX, john/.com or [email protected], john/@example.com or [email protected], and so forth). As may be understood, designating more or less, or different parts of the contact information will provide the client 170 with more or less information, as may be desirable. Other designation criteria may be selected which, although not explicitly listed here, fall within the scope and spirit of the present disclosure. In an embodiment, the designated portion of the contact information is finally transmitted to the client 170, while the undesignated portion is not, thus advantageously reducing network usage and bandwidth. In other embodiments, the portion of the contact information not designated is simply modified (by, for example, replacing the data with X's or 0's), and whole information, including the modified portion, is finally transmitted to the client 170.

[0048] At 3, the requested data is provided to client 170. The requested data provided to the client 170 is herein referred to as bulk data, as typically data pertaining to many consumers is provided simultaneously. The bulk data provided includes, for each consumer specified, encrypted consumer IDs, consumer credit data, and a partial subset of consumer contact information. Additionally, for each piece of contact information, the contact information type and contact information source may also be included. In an embodiment, only the partial subset of consumer contact information, not including the contact information type and source, is provided. Encrypted consumer IDs comprise encrypted, unique numerical identifiers for each consumer. The consumer IDs are encrypted so as to protect the identity of the consumers in the event the bulk data information is stolen or lost. Encryption of the consumer IDs may be implemented via any suitable cryptographic system, for example symmetric or asymmetric (such as, for example, public/private key), among others. In an embodiment, the consumer IDs are provided in an unencrypted form. In another embodiment, the consumer IDs are non-numerical.

[0049] Having received the bulk data, the client 170 has the opportunity to compare the received, partial subset of consumer contact information with any information the client 170 already possesses. For example, if the client 170 desires to contact a consumer, the client 170 may first look to its own consumer contact information. If the client's 170 contact information is non-existent for the particular consumer, or if it is no longer valid, the client 170 may then consider requesting a full set of consumer contact information via the consumer data request fulfillment system. It is desirable, however, that the client 170 first verify that the full set of consumer contact information will not be duplicative of information the client 170 already possesses. Thus, the client 170 may compare the partial subset of consumer contact information already received with the information previously possessed. For example, the client 170 may have a telephone number for consumer, 310-000-0000, but it has been disconnected. The client 170 may then compare the partial subset of the telephone number received as part of the bulk data request to their own information. If the client 170 finds that the partial subset of the telephone number is different (for example, the last three digits, 295, do not match the last three digits, 000), the client may then desire to request the full set of consumer contact information for that consumer. On the other hand, if the numbers match, then the client 170 may choose not to request the full set of consumer contact information for that consumer. Thus, the client 170 may advantageously save time and expense by utilizing the consumer data request fulfillment system.

[0050] At 4, the client 170 requests full sets of consumer contact information. The client 170 specifies in the request the particular consumers for whom a full set of consumer contact information is desired. Additionally, in an embodiment the client 170 may also specify the type of contact information desired, and/or the particular sources from which contact information is desired. Typically, the request will be for a subset of the consumers included in the bulk data request, although this may not always be the case. Consumers about whom a full set of consumer contact information is requested may be identified according to their encrypted consumer IDs, the designated portion of the partial subset of consumer contact information, and so forth. In an embodiment, the client 170 may request “all phones,” or “all information” for a particular consumer. In an embodiment, the request may be accomplished as an interactive XML transaction, a batch file request, or some other computer-automated transaction or request.

[0051] At 5, the full set of consumer contact data request is received by the data request fulfillment module 150 and processed. The requested information is retrieved from the consumer contact data sources 190 similar to 2 above, however the retrieved information is not less than the full set of information as it was in 2.

[0052] At 6, the client 170 optionally pays for the full set of data. This is accomplished when the client 170 provides payment through the payment processor 195, and the payment is verified. The payment processor 195 may also be in communication with the data request fulfillment module 150. For example, in an embodiment, the data request fulfillment module 150 may notify the payment processor 195 of the request for payment, and the price to be charged. The payment processor 195 may then initiate communication with the client 170. Once the client 170 has tendered payment, and the payment is verified, the data request fulfillment module 150 may be notified by the payment processor 195. Preferably, the payment request, payment receipt, payment verification, and payment notification are accomplished automatically. Thus, the client may rapidly provide payment and prevent delays in delivery of the requested data. In an embodiment, the client 170 may pre-pay for the requested data. The price of the requested data may vary depending on the amount of the data requested, the type of data requested, the specificity of the data requested, and so forth. In an embodiment, the full set of consumer contact information is provided at an additional cost to other costs the client is paying for other data requests, such as the consumer credit data. In an embodiment, the additional cost for the full set of consumer contact information is dependent on the number of consumers about whom data is being provided. For example the charge may be on a per-hit, per-request, per-consumer, and/or per-datum basis. For example, payment on a per-hit basis would include a fee for each piece of contact information requested. The cost for the full set of consumer contact information may vary based on the amount of data requested and/or the type of data requested for each consumer. For example, cell (or mobile) telephone numbers may cost more or less than land-line telephone numbers and/or data from a credit issuer application may cost more or less that data from public records. Payment is tendered, verified, and the data request fulfillment module 150 is notified.

[0053] In another embodiment, the partial subset of consumer contact information is provided as part of the bulk data at no additional cost where as in other embodiments, there may be a charge.

[0054] At 7, the requested full set of consumer contact data is provided to client 170. The full set of consumer contact data provided may include, for each consumer specified, encrypted consumer IDs and full set of consumer contact information. Additionally, for each piece of full set of consumer contact information, a last update date, the contact information type, and contact information source may also be included. The last update date indicates that last time the particular piece of contact information was updated in the consumer contact data sources 190. The last update date information may provide an additional means for identifying new contact information, and requesting information again in the future. Advantageously, the client 170 may request a full set of consumer contact information many times and/or at any time. The consumer data request fulfillment system enables fulfillment of the requests on a per-consumer basis. Additionally, requests may be automatically fulfilled, optionally including payment for the data.

[0055] FIG. 2 is a flow chart showing an embodiment of the consumer data request fulfillment system. The flow chart of FIG. 2 illustrates an exemplary method of fulfilling a request for consumer credit and contact data with the consumer data request fulfillment system. The exemplary method may be stored as a process accessible by the data request fulfillment module 150 and/or other components of a computing system 100, as will be described in reference to FIG. 3 below. Depending on the embodiment, certain of the blocks described below may be removed, others may be added, and the sequence of the blocks may be altered.

[0056] Beginning in optional block 202, a request for bulk consumer data is received by the data request fulfillment module 150. The request for bulk consumer data may come from client 170, and, as described with reference to 1 of FIG. 1 above, may include, for example, identification of a specific consumer, a group of consumers, and/or a population of consumers designated by, for example, some demographic indicator. In other embodiments, the data request fulfillment module 150 stores the customer's request criteria such that the information is retrieved and does not need to be sent by the client 170.

[0057] At block 204, the data request fulfillment module 150 determines whether the request for bulk consumer data includes a request for a partial subset of consumer contact data. If not, then the process continues to block 206, where the bulk consumer data request is fulfilled. The request is fulfilled by the data request fulfillment module 150, which accesses the consumer credit data sources 180 to retrieve the consumer credit data associated with the consumers identified in the request. The data is then transmitted to the client 170 over the network 160. This process occurs substantially as described above with references to 1, 2, and 3 of FIG. 1, with the exception that the consumer contact data sources 190 are generally not accessed, and the partial subset of consumer contact information is generally not transmitted to the client 170. Thus, the bulk data request returns encrypted consumer IDs and consumer credit data to the client 170. In an embodiment, the client 170 makes a payment for the bulk consumer data via the payment processor 195 before the data is delivered. The amount of the payment may depend on the type of request, as described above.

[0058] Returning to block 204 of FIG. 2, if the request does include a request for a partial subset of consumer contact information, then the data request fulfillment module 150 prepares the necessary partial subset of consumer contact information as described above in reference to 2 of FIG. 1. At optional block 208, the client 170 may optionally be charged a contact-data fee as described above in reference to 3 and 6 of FIG. 1. In an embodiment, the charge for the contact data may be in addition to a charge for the bulk consumer credit data as described above. At block 210, the request is fulfilled as the bulk consumer data (optional) and the partial subset of consumer contact data is transmitted by the data request fulfillment module 150, over the network 160, to the client 170. This is accomplished generally as described in reference to 3 of FIG. 1 above.

[0059] At block 212 of FIG. 2, a request is received by the data request fulfillment module 150 for a full set of consumer contact information. The request is generally provided by the client 170, substantially as described above with reference to 4 of FIG. 1. The request may then be fulfilled by the data request fulfillment module 150, as described in reference to 5 of FIG. 1. Then, at block 214 of FIG. 2, the client 170 is optionally charged a pre-hit fee for the full set of consumer contact information, as described in reference to 6 of FIG. 1. The client 170 may request a single piece of the full set of consumer contact information, multiple pieces of the full set of consumer contact information pertaining to a single consumer, or the full set of consumer contact information pertaining to many consumers. The fee charged will vary depending on the type of request. Finally, at block 216, the request for the full set of consumer contact information is fulfilled by the data request fulfillment module 150, as the data is transmitted to the client 170 over the network 160, as described with reference to 7 of FIG. 1.

[0060] Turning now to FIG. 3, a block diagram illustrating an embodiment of the consumer data request fulfillment system is shown. The consumer data request fulfillment system includes a data request fulfillment computing system 100 (or simply “computing system 100”), communication links 115, and, from FIG. 1, the network 160, the client 170, the payment processor 195, the consumer credit data sources 180, and the consumer contact data sources 190. Additionally, the computing system 100 includes a central processing unit (CPU) 105, input/output (I/O) interfaces and devices 110, a mass storage device 120, a memory 130, multimedia devices 140, and the data request fulfillment module 150.

[0061] In the consumer data request fulfillment system of FIG. 3, the computing system 100, the client 170, and the payment processor 195 are in communication with the network 160. The communication link 115 is the communications link between the various components of the revenue estimation system and the network 160. As shown by the dashed line, the payment processor 195 may optionally be in direct communication with the computing system 100. The consumer credit data sources 180 and consumer contact data sources 190 are in direct communication with the computing system 100, so as to provide a secure communications channel. In certain embodiments, the consumer credit data sources 180 and consumer contact data sources 190 may be in communication with the network 160, and/or may communicate with the computing system 100 over the network 160. The computing system 100 may be used to implement systems and methods described herein.

[0062] The computing system 100 includes computing devices, for example, a personal computer that is IBM, Macintosh, or Linux/Unix compatible or a server or workstation. In one embodiment, the computing system 100 comprises a server, a laptop computer, a smart telephone, a personal digital assistant, a tablet, for example. In one embodiment, the exemplary computing system 100 includes one or more CPU 105, which may each include a conventional or proprietary microprocessor. The computing system 100 further includes one or more memory 130, such as random access memory (“RAM”) for temporary storage of information, one or more read only memory (“ROM”) for permanent storage of information, and one or more mass storage device 120, such as a hard drive, diskette, solid state drive, or optical media storage device. Typically, the modules of the computing system 100 are connected to the computer using a standard based bus system. In different embodiments, the standard based bus system could be implemented in Peripheral Component Interconnect (“PCI”), Microchannel, Small Computer System Interface (“SCSI”), Industrial Standard Architecture (“ISA”) and Extended ISA (“EISA”) architectures, for example. In addition, the functionality provided for in the components and modules of computing system 100 may be combined into fewer components and modules or further separated into additional components and modules.

[0063] The computing system 100 is generally controlled and coordinated by operating system software, such as Windows XP, Windows Vista, Windows 7, Windows 8, Windows Server, Unix, Linux, SunOS, Solaris, iOS, Blackberry OS, Android, or other compatible operating systems. In Macintosh systems, the operating system may be any available operating system, such as MAC OS X. In other embodiments, the computing system 100 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, I/O services, and provide a user interface, such as a graphical user interface (“GUI”), among other things.

[0064] The exemplary computing system 100 may include one or more commonly available I/O interfaces and devices 110, such as a keyboard, mouse, touchpad, and printer. In one embodiment, the I/O interfaces and devices 110 include one or more display devices, 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. The computing system 100 may also include one or more multimedia devices 140, such as speakers, video cards, graphics accelerators, and microphones, for example.

[0065] In the embodiment of the revenue estimation system of FIG. 3, the I/O interfaces and devices 110 provide a communication interface to various external devices. In the embodiment of FIG. 3, the computing system 100 is electronically coupled to a network 160, which comprises one or more of a LAN, WAN, and/or the Internet, for example, via a wired, wireless, or combination of wired and wireless, communication link 115, as described above in reference to FIG. 1. The network 160 communicates with various computing devices and/or other electronic devices via wired or wireless communication links.

[0066] According to FIG. 3, in some embodiments information may be provided to the computing system 100 over the network 160 from one or more of the consumer credit data sources 180 and/or consumer contact data sources 190, as described above with reference to FIG. 1. In some embodiments, the consumer credit data sources 180 are the same as or overlap with the consumer contact data sources 190. The consumer credit data sources 180 and consumer contact data sources 190 may also be referred to as data stores and/or databases.

[0067] In the embodiment of FIG. 3, the computing system 100 includes the data request fulfillment module 150 that may be stored in the mass storage device 120 as executable software codes that are executed by the CPU 105. These modules may include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. In the embodiment shown in FIG. 3, the computing system 100 is configured to execute the data request fulfillment module 150 in order to fulfill, for example, requests for consumer credit and contact data in accordance with the processes described with respect to FIGS. 1 and 2 above.

[0068] 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, Java, Lua, C and/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 configured for execution on computing devices may be provided on a computer readable medium, such as a compact disc, digital video disc, flash drive, or any other tangible medium. Such software code may be stored, partially or fully, on a memory device of the executing computing device, such as the computing system 100, for execution by the computing device. Software instructions may be embedded in firmware, such as an EPROM. 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.

[0069] In an embodiment, the consumer credit data sources 180 and consumer contact data sources 190 are provided by a credit bureau, and/or the data request fulfillment module 150 and consumer data request fulfillment system are operated by a credit bureau. Alternatively, one or more of the various components of the consumer data request fulfillment system may be provided by another entity. Clients that may receive the consumer credit and contact data include, but are not limited to: companies that make lending and underwriting decisions such as credit cards, banks, credit unions, auto financing companies, savings and loan companies, and/or mortgage and financing companies; collection agencies; and/or individual customers, such as individual persons.

[0070] In an embodiment, the full set of consumer contact information provided by the consumer data request fulfillment system is provided with an agreement by the client that the information furnished will only be used a single time, and that it may not be retained after that use, or after a certain period of time. In an embodiment, clients may be forbidden from reusing or storing the full set of consumer contact information.

[0071] Maintaining communication with consumers is an important part of creating a stable business and making lending safe and effective, and can be useful for other purposes. Accessing additional consumer contact information is critical to maintaining communication with consumers when consumers' contact information changes or becomes unavailable. The present disclosure describes a consumer data request fulfillment system capable of quickly and automatically fulfilling requests for additional consumer data, including consumer contact information. Embodiments of the system advantageously integrate contact information into a credit data request system that many clients already have implemented. Clients may save expense as the partial subset of consumer contact information allows them to determine whether the additional contact information available through the consumer data request fulfillment system is additive to, or duplicative of, to information they are already possess. In an embodiment, only the designated portion (the partial subset portion) of the contact information is initially transmitted to the client, thus advantageously reducing network usage and bandwidth. Additionally, when requesting the full set consumer contact information, the client may request a single piece of full sets of consumer contact information, multiple pieces of full sets of consumer contact information pertaining to a single consumer, or full sets of consumer contact information pertaining to many consumers. Many individual requests may be made at specific times when the client is in need of additional information. Also, payment may be made on a per-hit, per-request, per-consumer, or per-datum basis, further reducing costs to clients.

[0072] Each of the processes, methods, and algorithms described in the preceding sections may be embodied in, and fully or partially automated by, code modules executed by one or more computer systems or computer processors comprising computer hardware. The code modules may be stored on any type of non-transitory computer-readable medium or computer storage device, such as hard drives, solid state memory, optical disc, and/or the like. The systems and modules may also be transmitted as generated data signals (for example, as part of a carrier wave or other analog or digital propagated signal) on a variety of computer-readable transmission mediums, including wireless-based and wired/cable-based mediums, and may take a variety of forms (for example, as part of a single or multiplexed analog signal, or as multiple discrete digital packets or frames). The processes and algorithms may be implemented partially or wholly in application-specific circuitry. The results of the disclosed processes and process elements may be stored, persistently or otherwise, in any type of non-transitory computer storage such as, for example, volatile or non-volatile storage.

[0073] The various features and processes described above may be used independently of one another, or may be combined in various ways. All possible combinations and subcombinations are intended to fall within the scope of this disclosure. In addition, certain method or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular sequence, and the blocks or states relating thereto can be performed in other sequences that are appropriate. For example, described blocks or states may be performed in an order other than that specifically disclosed, or multiple blocks or states may be combined in a single block or state. The example blocks or states may be performed in serial, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The example systems and components described herein may be configured differently than described. For example, elements may be added to, removed from, or rearranged compared to the disclosed example embodiments. Additionally, the term “subset” is used herein according to its ordinary meaning. In particular, a subset is understood to include none, some, or all of the members of a particular set.

[0074] Conditional language, such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.

[0075] Any process descriptions, elements, or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those skilled in the art.

[0076] All of the methods and processes described above may be embodied in, and partially or fully automated via, software code modules executed by one or more general purpose computers. For example, the methods described herein may be performed by the category spend computing system 100 and/or any other suitable computing device. The methods may be executed on the computing devices in response to execution of software instructions or other executable code read from a tangible computer readable medium. A tangible computer readable medium is a data storage device that can store data that is readable by a computer system. Examples of computer readable mediums include read-only memory, random-access memory, other volatile or non-volatile memory devices, CD-ROMs, magnetic tape, flash drives, and optical data storage devices.

[0077] It should be emphasized that many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure. The foregoing description details certain embodiments of the disclosure. It will be appreciated, however, that no matter how detailed the foregoing appears in text, the systems and methods can be practiced in many ways. As is also stated above, it should be noted that the use of particular terminology when describing certain features or aspects of the disclosure should not be taken to imply that the terminology is being re-defined herein to be restricted to including any specific characteristics of the features or aspects of the disclosure with which that terminology is associated.