PAYMENT REPORTING SYSTEMS
A system is disclosed for reporting payments to one or more credit bureaus according to instructions provided by a consumer. The system may provide the consumer with one or more user interfaces from which the consumer can select one or more options to report payments made to billers. In some embodiments, the reporting options are included as part of a biller's website or a bill payment center website. The system may enable faster reporting of payments made to some billers and may report payments made to billers who would not otherwise report payments.
This application is a continuation of U.S. patent application Ser. No. 14/252,701 filed Apr. 14, 2014, which is a continuation-in-part of U.S. patent application Ser. No. 14/164,561 filed Jan. 27, 2014, which claims the benefit of U.S. Provisional Application No. 61/919,618 filed Dec. 20, 2013 and U.S. Provisional App. No. 61/905,112 filed Nov. 15, 2013. Each of the above identified applications is hereby incorporated by reference as if set forth herein in its entirety.
BACKGROUNDThe credit score is an important indicator of a consumer's financial health. A consumer's credit score may impact availability and/or terms (e.g., interest rate) of such things as credit cards, loans, rentals, and real estate mortgages, as well as impacting the consumer's ability to find employment. Therefore, consumers have a substantial interest in monitoring and improving their credit scores.
SUMMARYIn one embodiment, a reporting system comprises hardware processors and one or more storage devices. The storage devices store software instructions for execution by the hardware processors. The system is configured to authenticate the identity of a consumer and access payment data associated with the consumer indicating a biller of the consumer. The system may then present the consumer with a user interface including the payment data and a selectable indicator enabling the consumer to instruct the system to report payments to one or more credit bureaus. In response to the consumer selecting the indicator, the system may initiate a report of the payment to one or more credit bureaus.
Data reporting is the reporting of consumer credit information by a business, such as a biller, to one or more credit bureaus. For example, business that require payment for a product or service that has been received or used by a consumer may report billing and payment information to one or more credit bureaus. Businesses that report data may be referred to as data reporters or data furnishers, while credit bureaus, such as Experian, are referred to as credit reporting agencies (CRA). Once billing and/or payment information is received by a credit bureau, a tradeline associated with the reporting business is created and/or updated with the new data. In general, a tradeline represents a particular financial account of a consumer (e.g., each credit card account is a different tradeline), and may be represented in various manners in a user interface displaying credit information. Consumers may have few or multiple tradelines on their record. Together, all tradelines reported on a specific consumer are included in the consumer's credit report and can be used to determine the consumer's overall risk or creditworthiness.
The credit score is an important indicator of a consumer's financial health. Consequently, having a high credit score is important to consumers for many reasons. A consumer's credit score may impact availability and/or terms (e.g., interest rate) of such things as credit cards, loans, leases, real estate mortgages, and so on. A poor credit score may even prevent a consumer from finding a good job. Thus, many consumers have a substantial interest in monitoring and finding ways to improve their credit scores. However, a consumer's credit report is based on the information on their credit report, and the information on a consumer's credit report doesn't change until it is updated by a data reporter. Typically, there are two types of data reporters. The first type is the billers themselves. Some billers report data about their consumer accounts directly to the credit bureaus. The second type is third party data furnishers (also referred to as third party data reporters). These companies report to the credit bureaus on behalf of one or more companies with consumer credit accounts. In both cases, the billers receiving payments from consumers and/or the third party data reporters typically aggregate payment information from many consumers and only report to the credit bureaus periodically (e.g., every 30 days). Thus, if a consumer makes a payment with the hope of improving his credit score there is often a substantial delay before any improvement actually occurs. For consumers seeking a quick improvement to their credit scores, this delay can be costly. In some embodiments of the disclosed systems, a consumer can report payment faster than relying on traditional reporting procedures and can ensure that some payments, that may otherwise not be reported, are reported.
Although several embodiments, examples and illustrations are disclosed below, the inventions described herein extend beyond the specifically disclosed embodiments, examples and illustrations and includes other uses of the inventions and modifications and equivalents thereof. Embodiments are 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 used in conjunction with a detailed description of certain specific embodiments of the invention. In addition, various embodiments can comprise several novel features and no single feature is solely responsible for its desirable attributes or is essential to practicing the inventions herein described.
System Block DiagramIn one embodiment, the payment reporting system 100 is configured to interface with multiple devices and/or data sources. The payment reporting system 100 may be configured to implement certain systems and methods described herein. The functionality provided for in the components and modules of the payment reporting system 100 may be combined into fewer components and modules or further separated into additional components and modules.
The payment reporting system 100 may be used to implement systems and methods described herein, such as providing billing information to a consumer, gathering a consumer's account data, enabling a consumer to initiate immediate payment reports to one or more credit bureaus, and/or processing payments to one or more billers. In the embodiment of
In some embodiments, the payment reporting system 100 includes an account data gathering module 150, which performs various tasks of gathering payment data and other data relating to one or more accounts of a consumer (e.g., a consumer operating the consumer computing device 162 in
The payment reporting system 100 may also include a payment module 170 configured to process payments from a consumer to one or more billers 164. The payments may be processed through the payment reporting system 100 or using a third party payment processor (e.g., Yodlee or Fiserv). When processing payments the system 100 may interact with one or more financial institutions to direct the transfer of money from an account associated with the consumer to an account associated with a biller 164. When processing payments through a third party payment processor, the system 100 may transmit payment information including account information for the consumer and the biller to the third party payment processor. The third party payment processor may then use the payment information to cause the transfer of money from the consumer to the biller.
In one embodiment, the reporting module 180 is configured to report payments to one or more credit bureaus. In some embodiments, the payment reporting module 180 may report payments that have been processed by payment module 170, and/or may report payments made through other modules or systems. Reporting module 180 may be configured to report payment information faster than waiting for reporting of the payment from the billers receiving payments. Reporting module 180 may also be configured to report payments made to a biller 164 that does not otherwise report payments. Payments may be reported directly by the reporting system 100 to the credit bureau 106 over the network 160, or may be made through an intermediate third-party reporter 168. Payment module 170 and reporting module 180 may include executable instructions for processing and reporting payments, respectively. The modules may include portions that are executed by the payment reporting system 100, by billers 164, by bill payment center 165, and/or by the computing device 162. Thus, discussion herein of operations performed by the payment module 170 and the reporting module 180 may be performed entirely by the payment reporting system 100, entirely by another computing device, or some portions may be performed by the payment reporting system 100 while other portions are performed by another computing device. Furthermore, other computing systems may also perform all or some of the processes discussed with reference to the payment module 170 or reporting module 180.
The payment reporting system 100 may also include a credit agreement validation module 190 which checks the authenticity of a consumer's accounts to verify terms of the credit agreement, e.g., to make sure that the consumer really has an account with a biller/biller for which the consumer is requesting payment reporting. The accounts may be validated with data from a credit bureau 106, a biller 164, other data sources 166, and/or information received from computing device 162. The identity verification module 195 verifies the consumer's identity, for example, before reporting payment information.
In some embodiments, the payment reporting system 100 further includes user interface module 110 which may access data from account data gathering module 150, billers 164, or other computing systems, and use that data to construct user interfaces that enable the consumer to report one or more payments to a credit bureau. Such visualization may be presented to the end user and are designed to be easily manipulated and/or understood by the user. In an embodiment, the user interfaces transmitted by user interface module 110 are interactive. Various embodiments of the user interfaces that may be provided by user interface module 110, are shown and described throughout this specification. Variations on such interfaces and other possible interfaces will be known to those of skill in the art. User interface module 110 may be configured to construct user interfaces of various types. In an embodiment, user interface module 110 constructs web pages to be displayed in a web browser or computer/mobile application. The web pages may, in an embodiment, be specific to a type of device, such as a mobile device or a desktop web browser, to maximize usability for the particular device. In an embodiment, user interface module 110 may also interact with a client-side application, such as a mobile phone application (an “app”) or a standalone desktop application, and provide data to the application as necessary to provide reporting functions to the consumer.
Client computing device 162, which may comprise software and/or hardware that implements the user interface module 110, may be an end user computing device that comprises one or more processors able to execute programmatic instructions. Examples of such a computing device 162 are a desktop computer workstation, a smart phone such as an Apple iPhone or an Android phone, a computer laptop, a tablet PC such as an iPad, Kindle, or Android tablet, a video game console, or any other device of a similar nature. In some embodiments, the client computing device 162 may comprise a touch screen that allows a user to communicate input to the device using their finger(s) or a stylus on a display screen. The computing device 162 and/or payment reporting system 100 may comprise storage systems such as a hard drive or memory, or comprise any other non-transitory data storage medium. The storage systems may be configured to store executable instructions that may be executed by one or more processors to perform computerized operations on the client computing device 162, such as accept data input from a user (e.g., on the touch screen), and/or provide output to a user using the display. These executable instructions may be transmitted to another device for execution or processing by the device to implement the systems and methods described herein.
The various computing devices illustrated in
As described above, some embodiments may include portions that are executed by the payment reporting system 100, biller(s) 164, bill payment centers 165, and/or by the computing device 162, or are entirely executed by the payment reporting system 100, biller(s) 164, bill payment center 165, or the computing device 162. Thus, discussion herein of any structure (e.g., CPU, memory, etc.) of a computing device 162 or operations performed by the computing device 162, billers 164, bill payment center 165 or modules of the payment reporting system 100 may be equally applied to the payment reporting system 100. Furthermore, other computing systems may also perform all or some of the processes discussed with reference to the modules of the payment reporting system 100.
The biller(s) 164 may be reporting or non-reporting billers. In either case, the biller is a biller of the consumer. Reporting billers may regularly report payments received from the consumer to one or more credit bureaus. Reporting billers may include credit card companies, mortgage lenders, auto-loan lenders, and/or other billers that have provided credit to a consumer. Reporting billers may be required to report payments by laws or regulations, or may report voluntarily. Non-reporting billers do not typically report payments received from consumer's to a credit bureau. For example, non-reporting billers may include landlords and/or utility companies that have not traditionally reported payments. A biller 164 may refer to the legal entity that lends money or other services to a consumer, or may refer to the hardware and software components implemented on a computer system that interact with the payment reporting system 100 and/or the associated modules. In some embodiments, the payment reporting system 100 may operate as part of the computer systems of a biller 164.
Bill payment center 165 may be an online portal from which a consumer can make payments to one or more billers. In some embodiments, the consumer may identify billers to the bill payment center 165 or the billers may be identified automatically. The bill payment center may interact with a payment reporting system 100 and/or associated modules or may perform some features and modules associated with the payment reporting system 100. In some embodiments, the bill payment center 165 may perform part of modules that are included in the payment reporting system 100 and other parts of the modules may be performed by other computing systems, such as those included as part of a biller 164 or the payment reporting system 100. A consumer may access and interact through the computing system 162 with the bill payment center 165 through a web page or other user interface provided by the bill payment center 165 or another computer system.
Example Computing System ComponentsIn 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++, C#. Software modules 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, Java, Perl, or Python. It will be appreciated that software modules may be callable from other modules or from themselves or may be invoked in response to detected events and interrupts, or both. The modules included in the payment reporting system 100 may be stored in the mass storage device 120 as executable software codes that are executed by the CPU 105. Modules in the payment reporting system 100 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. 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, magnetic disc, or any other tangible medium, or as a digital download (and may be originally stored in a compressed or installable format that requires installation, decompression or decryption prior to execution). Such software code may be stored, partially or fully, on a memory device of the executing computing device, such as the computing device 162, 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 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 devices into sub-modules despite their physical organization or storage. Other computing systems, such as, computing device 162, billers 164, and bill payment center 165 may comprise similar computing hardware, software, and functionality as described in reference to payment reporting system 100.
In one embodiment, the payment reporting system 100 includes, for example, one or more servers or personal computers that are IBM, Macintosh, or Linux/Unix compatible. In another embodiment, the payment reporting system 100 includes one or more laptop computers, smart phones, personal digital assistants, or other computing devices. The payment reporting system 100 may include a memory 130, which may include a random access memory (“RAM”) for temporary storage of information, a read only memory (“ROM”) for permanent storage of information, and/or a mass storage device, such as a hard drive, diskette, optical media storage device, or USB flash drive. The payment reporting system 100 may also contain a separate mass storage device 120 for permanent storage of information. Typically, the modules of the payment reporting system are in communication with each other 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.
The payment reporting system 100 may be generally controlled and coordinated by operating system software, such as Windows 95, 98, NT, 2000, XP, Vista, 7, 8, SunOS, Solaris, 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 other embodiments, the Payment reporting 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 systems, networking, and I/O services, and provide a user interface, such as a graphical user interface (“GUI”), among other functions.
The example payment reporting system 100 shown in
Some embodiments of a payment reporting system 100 may contain fewer or additional elements and modules than are present in the embodiment in
The payment reporting system 100 may present one or more user interfaces to the consumer through computing devices 162. In some embodiments, the user interfaces may be generated and/or configured by a user interface module 110, but one or more functions of the user interface module may be performed by one or more other modules, or other suitable hardware or software components.
In the user interfaces illustrated in
In the user interface illustrated in
In the user interface illustrated in
In the user interface illustrated in
If the consumer does not have login credentials, the consumer may need to sign up for reporting services account by first authenticating his identity. The user interface illustrated in
The user interface in
The user interface shown in
In the user interface illustrated in
In the third option 270 presented as part of the user interface of
The user interface of
In some embodiments, the payment reporting system 100 operates as part of, or in conjunction with a bill payment center 165.
The additional features described with reference to
The user interface illustrated in
For some billers, even those that do not report to credit bureaus, the biller may have an established relationship with the payment reporting system 100. In such embodiments, the biller and/or consumer may provide information about the credit relationship that the payment reporting system 100 can interpret and rely on to validate the credit agreement. Once a credit agreement is validated the payment reporting system 100 can report payments to the biller to one or more credit bureaus as needed. The user interface illustrated in
In the user interface illustrated in
If a consumer searches for a biller, but is unable to identify the desired biller, the consumer may be able to add a new biller to the system. For example, the second option 520 illustrated in
In the user interface illustrated in
In the embodiment of
The user interfaces illustrated in
Beginning in block 710, the system receives a selection from a consumer to make a payment. The selection may be made through any of the user interfaces discussed above, or other payment systems. The selection may be to make a payment immediately, to make a payment at a later time, or to setup automatic recurring payments.
In block 730, the system makes a payment on behalf of the consumer according to the instructions indicated by the selection received in block 710. In some embodiments, payments may be processed by the system through one or more banking institutions. Payments may also be made by passing financial information associated with the consumer to a third party to process the required payments. Also in Block 730, the system may receive confirmation that the payment was successful. For example, when funds are transferred to the biller (e.g., from a payment account of the consumer), the payment reporting system 100 may receive confirmation that the payment was on time and the amount was sufficient.
In block 740, the payment reporting system 100 determines if the consumer selected immediate reporting. The consumer may have selected immediate reporting from one of the user interfaces illustrated in
If the consumer did not select immediate reporting of the payment, in block 750 the payment reporting system stores the consumer's payment information in a payment database for later reporting to one or more credit bureaus. The payment database may be located in memory 130, mass storage device 120, or stored in a database associated with another entity. The stored information includes information necessary to report the payment to a credit bureau at a later time. For example, stored information may include the payment date, the payment amount, whether or not the payment was on time, successful payment confirmation, and other information important if the payment may be reported at a later time. Should the consumer select to report payments at a later time (see e.g., block 720), the payment reporting system 100 can use the stored information to make the report at that time.
If the system determines that the consumer selected immediate reporting of the payment at block 740, the method continues to block 770, wherein the payment reporting system 100 determines if the consumer has previously reported payments to this biller. The system may determine both if the consumer has previously reported any payments through payment reporting system 100, and whether those payments were to the particular biller that is at issue now. If the consumer has previously reported payments to the particular biller, then the system may not need to authenticate the relationship any further. If the consumer has not previously reported payments to the biller associated with this reporting before, the system needs to authenticate the credit agreement, and in some cases may need to further authenticate the consumer's identity as well.
In block 780, the credit reporting system 100 authenticates the consumer's identity. The consumer's identity may be authenticated by requiring additional information from the consumer as illustrated and discussed in reference to
In block 790, the consumer has indicated a payment for the system to report, and the relationship on which the payment is based has been authenticated. The system may now report the payment to one or more credit bureaus. Payments may be reported directly to the credit bureau(s) 106 by the payment reporting system 100 in some embodiments. Payments may also be reported through a third-party reporter 168. In one embodiment, payments reported directly to credit bureau(s) must be made in the proper format and from an approved entity. Entities approved to report to credit bureaus are generally reporting creditors or third party data furnishers that are approved by one or more credit bureaus to report payments on behalf of non-reporting creditors. When reporting directly to a credit bureau, a biller or third-party reporter must generally report payments in a specific format, such as the Metro2 credit reporting standard. Payment reporting processes are discussed in more detail below with reference to
Returning to Block 720, the processes of
In block 760, if one or more particular payments to be reported are not identified at block 720, the payment reporting system 100 may access payment records for the consumer. The payments may be stored in a database associated with the payment reporting system as described in reference to block 750. In some embodiments, the payments data is stored on a biller's website, or in a database associated with the biller, and the payment reporting system 100 accesses the payment data from the biller's resources. In some embodiments, determining which payments to report involves determining which payments have already been reported. For example, if a consumer selects to report all available payments, the system may determine that only payments made during the last 12 months are eligible to be reported. In addition, the system may take steps to avoid reporting a payment that has already been reported by another entity. For example, a payment may be reported by a biller before the consumer requests to report the same payment through the payment reporting system 100. The payment reporting system may determine which payments have already been reported by requesting the reporting data from the biller, receiving data from the biller at the time of reporting and recording it, or by accessing the consumer's credit report and determining if the payment to be reported already appears on the consumer's report.
After the payment reporting system 100 has accessed the payment data for the consumer and determined which payments are to be reported, the system continues to block 770. Blocks 770, 780, and 790 operate in the same manner whether the processes are initiated by receiving instructions to make a payment or receiving instructions to report payments.
In some embodiments of
The flowchart illustrated in
The block diagrams in
The block diagram in
In
When the consumer selects to make a payment or report a payment as described with reference to the user interfaces and flowcharts above through computing device 162, the biller 164 may perform some or all of the required actions. However, in the embodiment of
The block diagram of
The biller 164 in the embodiment of
In some embodiments, the biller 164 receives payment information from the consumer computing device 162, but does not process the payments directly. Information can be transmitted from a payment module 170 at the biller to a payment module 170 at the payment reporting system 100. The payment reporting system 100 can then initiate payments according to the instructions. In some embodiments, the payment reporting system 100 performs the actions necessary to process the payment according to the instructions with the payment module 170. In some embodiments, the payment module 170 on the payment reporting system 170 may also send the necessary payment information to a third-party payment processor 802 (such as Yodlee or Fiserv) to process the payment. Confirmation of completed payments may be processed by the reporting module 180 to report the payments to the credit bureau(s) 106. In some embodiments, the biller 164 may use the third party payment system directly (e.g., through payment module 170) without the assistance of a separate payment reporting system 100.
In some embodiments, the payment reporting system 100 gives a notification to the biller when a payment has been reported to the credit bureau(s) 106. The biller may then avoid sending a duplicate report. The payment reporting system 100 may also inform the credit bureau(s) 106 as part of the payment reporting that the biller is likely to send duplicate payment data, but that it should only be recorded only once. Although not pictured, the communications from the biller 164 to the payment reporting system 100 may be performed over an API associated with the biller or payment reporting system 100 as discussed with reference to
The block diagram in
Many processes of making and reporting payments may be performed as illustrated in
In some embodiments, the consumer may communicate with a non-reporting biller 164A, which does not regularly report payments to a credit bureau 106. Such billers may include utility companies and landlords, for example. Therefore, the traditional interaction would be for the consumer to make a payment to the biller, and no payment to be reported to the credit bureaus 106. However, the payment reporting system 100 may enable the biller 164A to also offer the ability to report payments to the credit bureau 106. In this example, the biller 164A includes a reporting module 180 configured to communicate with the payment reporting system 100 to provide payment data and instructions to report the payments to credit bureau 106. The payment reporting system 100 may then report the payment(s) directly to the credit bureau(s) 106 or through a third-party reporter 168. The reporting module 180 located at biller 164A may be provided by payment reporting system 100 to enable the biller to offer reporting features to the consumer, and enable the biller 164A to communicate with the payment reporting system 100 to execute those features. In some embodiments, the reporting module 180 located at biller 164A enables the biller to report payments to the credit bureau(s) 106 without passing information through the payment reporting system 100, such as by communicating directly with the third-party reporter 168. The biller 164A and consumer may perform additional communication with the payment reporting system 100 to authenticate the credit agreement.
In some embodiments, the consumer communicates with a reporting biller 164B to complete payments. Biller 164B is a reporting biller that will report payment information to the credit bureau(s) regardless of additional input from the consumer. For example, biller 164B may be a credit card company or mortgage lender. In some embodiments, biller 164B enables the consumer to report payments faster than the biller would report through a typical batch reporting process. For example, the biller 164B may provide the features described in reference to the sample user-interfaces above. The biller 164B may process these additional features by communicating with the payment reporting system 100. The reporting module 180 and/or payment reporting module 170 may provide payment information to the payment reporting system 100 to enable the system to report payments to the credit bureau(s) immediately instead of waiting for batch reporting 30 or more days later.
In some embodiments, the consumer communicates with the payment reporting system 100 through computing device 162. At the payment reporting system 100, the consumer may be able to make payments through the payment module 170, and report payments through reporting module 180. For example, the payment reporting system 100 may be operating as a bill payment center or in cooperation with a bill payment center. To make payments, the payment module 170 included in payment reporting system 100 may communicate with one or more billers (e.g., biller 164A and biller 164B) to receive information on payments due, payment processing information, and/or to execute payments to the billers. Payments may be processed directly by the payment reporting system 100, or through a third party payment processor as discussed in reference to
In some embodiments, the consumer may also report payments through communication with the payment reporting system 100. For example, the consumer may interact with one or more of the user-interfaces described above to provide instructions to the payment reporting system 100 to report payments made. The payments may have been made at the payment reporting system 100, or may have been made through communication with the billers. Reporting module 180 may communicate with the billers to receive information required to report the payments to the credit bureau(s), or the payment information may already be stored in the payment reporting system 100 when payments are made through the system. After the necessary information is acquired, the payment reporting system 100 may report payments to the credit bureau(s) 106 directly or through third-party reporter 168 according to instructions received from the consumer.
The block diagram in
Although the foregoing systems and methods have been described in terms of certain embodiments, other embodiments will be apparent to those of ordinary skill in the art from the disclosure herein. Additionally, other combinations, omissions, substitutions and modifications will be apparent to the skilled artisan in view of the disclosure herein. While some embodiments of the inventions have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms without departing from the spirit thereof. Further, the disclosure herein of any particular feature, aspect, method, property, characteristic, quality, attribute, element, or the like in connection with an embodiment can be used in all other embodiments set forth herein.
All of the processes described herein may be embodied in, and fully automated via, software code modules executed by one or more general purpose computers or processors. The code modules may be stored in any type of computer-readable medium or other computer storage device. Some or all the methods may alternatively be embodied in specialized computer hardware. In addition, the components referred to herein may be implemented in hardware, software, firmware or a combination thereof.
Conditional language such as, among others, “can,” “could,” “might” or “may,” unless specifically stated otherwise, are otherwise understood within the context as used in general 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.
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 elements 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.
Claims
1. A computing system, the computing system comprising:
- memory; and
- one or more processors in communication with the memory and configured by processor-executable instructions to: receive payment data from a plurality of third-party entities indicating payments made by a user to the third-party entities, including a first payment made to a first third-party entity; generate user interface data to be displayed on a user computing device, the user interface data comprising: an indication of the first payment made to the first third-party entity; and an interactive user interface element configured to initiate reporting of the first payment to a credit bureau; and in response to a user selection of the interactive user interface element, transmit information regarding the first payment to one or more credit bureaus, wherein the information regarding the first payment is transmitted to the one or more credit bureaus before information regarding the first payment is transmitted by the first third-party entity to the one or more credit bureaus.
2. The computing system of claim 1, wherein the computing system is further configured to determine whether or not there is a valid credit agreement between the user and the first third-party entity.
3. The computing system of claim 1, wherein the computing system is further configured to authenticate a user's identity.
4. The computing system of claim 1, wherein the user interface data further comprises payment indicators associated with respective third-party entities, wherein a first payment indicator associated with the first third-party entity is configured to enable the user to instruct the computing system to initiate a payment to the first third-party entity.
5. The computing system of claim 4, wherein the computing system is further configured to initiate the first payment to the first third-party entity in response to receiving the indication of selection of the first payment indicator.
6. The computing system of claim 5, wherein the computing system is further configured to:
- determine whether the first payment to the first third-party entity is successfully completed; and
- in response to determining that the first payment is successfully completed, initiate said reporting of the first payment to the one or more credit bureaus.
7. The computing system of claim 1, wherein transmitting the information regarding the first payment to the one or more credit bureaus comprises:
- determining whether first payment data associated with the first third-party entity indicates the first payment has been successfully completed; and
- transmitting at least a portion of the first payment data to the one or more credit bureaus or a third party data reporter.
8. The computing system of claim 1, wherein the computing system is further configured to:
- receive, from the user, recurring reporting instructions to report payments automatically in response to receiving indications that respective payments to the third-party entities are successfully completed;
- receive an indication that a second payment was successfully completed; and
- automatically initiate reporting of the second payment to the one or more credit bureaus in accordance with the recurring reporting instructions.
9. The computing system of claim 1, wherein the computing system is further configured to:
- receive an indication of selection of a second reporting indicator by the user; and
- in response to receiving the indication of selection of the second reporting indicator, initiating reporting, to one or more credit bureaus, of a second payment completed to a second third-party entity.
10. A computer-implemented method comprising:
- receiving payment data from a plurality of third-party entities indicating payments made by a user to the third-party entities, including a first payment made to a third-party entity;
- generating user interface data to be displayed on a user computing device, the user interface data comprising: an indication of the first payment made to the third-party entity; and an interactive user interface element configured to initiate reporting of the first payment to a credit bureau; and
- in response to a user selection of the interactive user interface element, transmitting information regarding the first payment to one or more credit bureaus, wherein the information regarding the first payment is transmitted to the one or more credit bureaus before information regarding the first payment is transmitted by the third-party entity to the one or more credit bureaus.
11. The computer-implemented method of claim 10, wherein the user interface data further comprises a payment indicator associated with the payment data, wherein the payment indicator is configured to enable the user to initiate payment to the third-party entity.
12. The computer-implemented method of claim 11, wherein the method further comprises:
- determining whether the payment to the third-party entity is successfully completed; and
- in response to determining that the payment is successfully completed, initiating reporting of the payment to the one or more credit bureaus.
13. The computer-implemented method of claim 10, wherein the user interface data is provided as part of a website associated with the third-party entity.
14. The computer-implemented method of claim 10, wherein initiating reporting of the payment to one or more credit bureau comprises:
- determining whether the payment data indicates the payment has been successfully completed; and
- transmitting at least a portion of the payment data to the one or more credit bureaus or a third party data reporter.
15. The method of claim 10, wherein the method further comprises:
- receiving, from the user, recurring reporting instructions to report payments automatically in response to receiving indications that payments to the third-party entity are successfully completed;
- receiving an indication that a second payment was successfully completed; and
- automatically initiating reporting of the second payment to the one or more credit bureaus in accordance with the recurring reporting instructions.
16. A non-transitory computer storage medium storing computer-executable instructions that, when executed by a processor, cause the processor to:
- receive payment data from a plurality of third-party entities indicating payments made by a user to the third-party entities, including a payment made to a third-party entity;
- generate user interface data to be displayed on a user computing device, the user interface data comprising: an indication of the payment made to the third-party entity; and an interactive user interface element configured to initiate reporting of the payment to a credit bureau; and
- in response to a user selection of the interactive user interface element, transmit information regarding the payment to one or more credit bureaus, wherein the information regarding the payment is transmitted to the one or more credit bureaus before information regarding the payment is transmitted by the third-party entity to the one or more credit bureaus.
17. The non-transitory computer storage medium of claim 16, wherein the computer-executable instructions further cause the processor to:
- receive terms of a credit agreement between the third-party entity and the user; and
- determine whether there is a valid credit agreement between the user and the third-party entity.
18. The non-transitory computer storage medium of claim 16, wherein the computer-executable instructions further cause the processor to:
- receive identification information for the user; and
- authenticate a user's identity.
19. The non-transitory computer storage medium of claim 16, wherein the computer-executable instructions further cause the processor to:
- receive an indication that the payment data has been reported to the one or more credit bureaus; and
- provide, to the third-party entity, confirmation that the payment data has been reported.
Type: Application
Filed: Jun 10, 2019
Publication Date: Sep 26, 2019
Inventors: Mark Joseph Kapczynski (Santa Monica, CA), Michael John Dean (Torrance, CA)
Application Number: 16/436,799