US20140316982A1

US20140316982A1 - System and Method for Electronic Bill Pay and Presentment

Info

Publication number: US20140316982A1
Application number: US14/321,145
Authority: US
Inventors: Karen Lavern Brown; Lisa Kim Manarky
Original assignee: JPMorgan Chase Bank NA; Chase Bank USA NA
Current assignee: JPMorgan Chase Bank NA; Chase Bank USA NA
Priority date: 2001-01-30
Filing date: 2014-07-01
Publication date: 2014-10-23
Also published as: US20040158522A1; AU2002234275A1; WO2002061536A3; US8805739B2; WO2002061536A2

Abstract

A system and method is disclosed enabling a customer payor to make payment to a payee in a networked environment using a credit card, revolving credit, or other credit account. The payment system may provide for online receipt and review of bills, and may allow a customer payor to optionally select one or more alternative secondary accounts for payment in the event that payment cannot be made from a primary credit account. The secondary account may be another credit account, a checking account, a brokerage account, or another type of account. Actual payment may be accomplished by electronic settlement of a credit transaction, electronic funds transfer, or by printing and physically delivering a paper check. A customer payor using the system and method may receive notification concerning the success or failure of the transaction.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority from U.S. provisional application Ser. No. 60/264,681 filed Jan. 30, 2001, having one or more of the same inventors as this application, assigned or under an obligation of assignment to the same entity as this application, and which application is incorporated herein by reference.

FIELD OF INVENTION

The invention relates to the field of financial systems, and more particularly to enabling an individual consumer or other entity to pay bills on a network-based application using a credit account.

BACKGROUND OF THE INVENTION

In the modern economy, individual consumers and other entities are presented with bills for goods and services purchased from multiple vendors, service providers and others. Payment for many such goods and services are made on a periodic basis, often monthly. Others are one-time transactions. Consumers and other entities may wish to pay periodic and other bills using credit accounts. This may be desirable, for example, where liquid funds are not available to make payment, where the consumer or other entity seeks to take advantage of reward or other incentive programs for making payment with credit, or for other reasons.
In recent years, enabled by the pervasiveness of the Internet, some Web-based services have been developed to enable consumers to view and pay bills online. Such services, however, facilitate payment only from the consumer's checking account, or at times from brokerage or other accounts with check-writing privileges. Such systems therefore may not function for credit accounts, and may not be optimized for the consumer who wishes to pay with credit instead of cash or cash equivalent, on a recurring basis, at certain times of the month, or with other parameters taken into account.
These and other drawbacks exist.

SUMMARY OF THE INVENTION

The invention overcoming these and other problems in the art relates to a system and method for receiving, viewing, and paying bills online with an option to make payment from one or more credit accounts. One embodiment of the system relies on Internet architectures and Web-based components to arrange selective bill paying using credit facilities and other payment modes. One embodiment of the method includes receiving bills, selecting a bill for payment, selecting a time for payment, selecting a credit account for payment, automatically receiving authorization for payment, and automated settlement of the credit account transaction. Another embodiment allows a consumer to also send payments to persons where a bill has not been received (i.e. a “pay anyone” model).
An object of the invention in one regard is to facilitate the receipt of bills that a consumer wishes to pay with credit. Another object of the invention is to enable on-time payment of bills with credit, providing a benefit to both the payor and the payee. Another object of the invention is to provide for an automated backup or rollover mechanism for payment where a credit account has reached its credit limit, when a payee does not accept payment by credit, or for other reasons.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be described with reference to the accompanying drawings, in which like elements are referenced with like numbers.

FIG. 1 is a system architecture diagram, according to one embodiment of the invention.

FIG. 2 is a process flow diagram from the perspective of a customer, according to one embodiment of the invention.

FIG. 3 is a process flow diagram from the perspective of a provider of online payment services, according to one embodiment of the invention.

FIG. 4 is a functional architecture to implement the process flows of FIGS. 2 and 3, according to one embodiment of the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

FIG. 1 illustrates a network architecture in which the invention may be practiced, wherein Servers 100, 110, and 120 may be linked to clients 140, 150, and 160 via communications link 170.
Servers 100, 110, and 120 may host applications facilitating transactions for banks, merchants, or other financial institutions. Servers 100, 110, and 120 may be or include, for instance, a workstation running the Microsoft Windows NT™ NT™, Windows™ 2000, Unix, Linux, Xenix, IBM AIX™, Hewlett-Packard UX™, Novell Netware™, Sun Microsystems Solaris™, OS/2™, BeOS™, Mach, Apache, OpenStep™ or other operating system or platform.
Servers 100, 110 and 120 may interface to one or more databases. As an illustration, FIG. 1 depicts database 130, which is interfaced to server 120. Database 130 may be, include or interface to, for example, the Oracle™ relational database sold commercially by Oracle Corp. Other databases, such as Informix™, DB2 (Database 2), Sybase or other data storage or query formats, platforms or resources such as OLAP (On Line Analytical Processing), SQL (Standard Query Language), a storage area network (SAN), Microsoft Access™ or others may also be used, incorporated or accessed in the invention.
Clients 140, 150, and 160 may be customer terminals such as customer terminal 400 depicted in FIG. 4, or they may be, for example, terminals used by banks, merchants or other financial institutions for system administration or for other reasons. Clients 140, 150, and 160 may be or include, for instance, a personal computer running the Microsoft Windows™ 95, 98, Millenium™, NT™, or 2000, Windows™CE™, PalmOS™, Unix, Linux, Solaris™, OS/2™, BeOS™, MacOS™ or other operating system or platform. Clients 140, 150, and 160 may include a microprocessor such as an Intel x86-based device, a Motorola 68K or PowerPC™ device, a MIPS, Hewlett-Packard Precision™, or Digital Equipment Corp. Alpha™ RISC processor, a microcontroller or other general or special purpose device operating under programmed control. Clients 140, 150, and 160 may furthermore include electronic memory such as RAM (random access memory) or EPROM (electronically programmable read only memory), storage such as a hard drive, CDROM or rewritable CDROM or other magnetic, optical or other media, and other associated components connected over an electronic bus, as will be appreciated by persons skilled in the art. Clients 140, 150, and 160 may also be or include a network-enabled appliance such as a WebTV™ unit, radio-enabled Palm Pilot™ or similar unit, a set-top box, a networkable game-playing console such as Sony Playstation™ or Sega Dreamcast™, a browser-equipped cellular telephone, or other TCP/IP client or other device.
Servers 100, 110, and 120 may be connected to each other or to clients 140, 150, or 160 via communications link 170. Communications link 170 may be, include or interface to any one or more of, for instance, the Internet, an intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network) or a MAN (Metropolitan Area Network), a storage area network (SAN), a frame relay connection, an Advanced Intelligent Network (MN) connection, a synchronous optical network (SONET) connection, a digital T1, T3, E1 or E3 line, Digital Data Service (DDS) connection, DSL (Digital Subscriber Line) connection, an Ethernet connection, an ISDN (Integrated Services Digital Network) line, a dial-up port such as a V.90, V.34 or V.34bis analog modem connection, a cable modem, an ATM (Asynchronous Transfer Mode) connection, or an FDDI (Fiber Distributed Data Interface) or CDDI (Copper Distributed Data Interface) connection. Communications link 170 may furthermore be, include or interface to any one or more of a WAP (Wireless Application Protocol) link, a GPRS (General Packet Radio Service) link, a GSM (Global System for Mobile Communication) link, a CDMA (Code Division Multiple Access) or TDMA (Time Division Multiple Access) link such as a cellular phone channel, a GPS (Global Positioning System) link, CDPD (cellular digital packet data), a RIM (Research in Motion, Limited) duplex paging type device, a Bluetooth, BlueTeeth or WhiteTooth radio link, or an IEEE 802.11-based radio frequency link Communications link 170 may yet further be, include or interface to any one or more of an RS-232 serial connection, an IEEE-1394 (Firewire) connection, a Fibre Channel connection, an IrDA (infrared) port, a SCSI (Small Computer Systems Interface) connection, a USB (Universal Serial Bus) connection or other wired or wireless, digital or analog interface or connection.
Servers 100, 110, and 120, and clients 140, 150, and 160 may utilize network enabled code in order to facilitate functionality in a network-based environment. Network enabled code may be, include or interface to, for example, Hyper text Markup Language (HTML), Dynamic HTML, Extensible Markup Language (XML), Extensible Stylesheet Language (XSL), Document Style Semantics and Specification Language (DSSSL), Cascading Style Sheets (CSS), Synchronized Multimedia Integration Language (SMIL), Wireless Markup Language (WML), Java™, Jini™, C, C++, Perl, UNIX Shell, Visual Basic or Visual Basic Script, Virtual Reality Markup Language (VRML), ColdFusion™, Common Gateway Interface (CGI) or other compilers, assemblers, interpreters or other computer languages or platforms.
FIG. 2 is a process flow diagram from the perspective of a customer payor, according to one embodiment of the invention. The process may start in step 200, where, for example, the customer may utilize a client 140, 150 or 160 to log onto a payment system. Log on step 200 may require the customer to enter a username and password, and may entail additional security measures familiar to those skilled in the development of financial systems.
In step 210, the customer may receive and review bills online. An online bill may indicate, for example, the name of the payee, a description of the goods or services provided in exchange for payment, the amount owed, and the date payment is due. In one embodiment, the electronic bill may be posted to the system directly by the merchant. In another embodiment, a service provider may receive a hard copy of the bill, and post the information to the bill payment system so that the customer can receive and review the information online. In another embodiment, step 210 may not apply, for example in the case where a customer has received only a hard copy of a bill, or in the case where the customer seeks to make payment for goods or services, or to make a gift payment, in the absence of a bill or other invoice.
In step 220, the customer payor may enter payment data in preparation for an online payment transaction. In the case where a bill has not been received online, a customer payor may enter payee information 222 such as name, account number, and a description of the goods or services for which payment is to be made; in this instance, it is also necessary to specify the amount of payment 224. The customer may also specify one or more payor accounts 226 from which to make payment. Payor account 226 may be, for example, a checking, brokerage, or money market account, and may be a Direct Deposit Account (DDA). A DDA may be, for instance, a checking or savings account which a bank customer has authorized for direct deposit of wages from an employer.
Payor account 226 may also be a credit card account, a revolving credit account, or other credit account. In one embodiment of the invention, the customer payor may enter a primary account and one or more secondary accounts. A secondary account may be used for payment if, for instance, sufficient funds or credit are not available from the primary account. It also may be the case that certain payees will not accept payment from a credit account. In one embodiment of step 220, a customer may enter the date and time 228 that payment is to be made from the payor to the payee. It may be advantageous, for example, to schedule payment prior to the time that payment is due, but after automatic deposit of payroll funds into the customer's account. Step 228 may also allow a customer payor to request immediate payment to the payee. As described here, an immediate transaction may be a transaction that is initiated within minutes, seconds, or less.
Data entry in step 220 may be accomplished via menu selection, for example where a customer has received more than one online bill or where the customer has already specified one or more payor account alternatives. In another embodiment, data entry step 220 may entail manual entry of alphanumeric characters into pre-defined fields. In one embodiment, a customer may specify payment data for payment transactions in step 220 that are to be executed automatically and without further customer intervention on a recurring basis.
It may be that before a payment transaction can be executed, a certain set of data is required. In step 230, then, a decision may be made by the payment system as to whether the customer payor has specified all necessary data. Where the customer has not, the system may return the customer to step 220 to enter payment data, and the system may further prompt the customer for information that is both missing and necessary. In the case where the customer payor has entered all necessary information, the payment system may initiate the payment transaction.
From the customer payor's perspective, the next step may be an acknowledgement in step 240 that payment has been successfully made to the payee. In one embodiment, step 240 may be near real-time, and while the customer is still logged onto the system. In this instance, a customer payor may receive a system-generated message that is displayed within seconds or minutes from an immediate request for payment. In another embodiment of acknowledgment step 240, the system may send an email or other acknowledgment to the customer payor. In the case where a customer payor has specified a primary and at least one secondary account, the acknowledgement in step 240 may indicate which account or accounts from which payment has been drawn. In this instance, the system may also provide a reason in step 240 explaining why payment was not made from the customer's primary account. Once step 240 concludes, the payment transaction terminates in step 250.
FIG. 3 is a process flow diagram from the perspective of a provider of online payment services, according to one embodiment of the invention where payment is being made from a credit card, revolving credit account, or other credit account. The process may be initiated by entry of customer data as indicated by Step 220 in FIG. 3, and as described above.
In step 300, data related to payee information 222, amount 224, payor account 226, date and time 228, or other information, may be subjected to initial data processing in step 300. Step 300 processing may check for the availability of all necessary information, such as the decision described in step 230. Step 300 may also validate one or more pieces of data, for example to ensure that a valid date has been entered in step 220, or that the credit card account supplied by the customer payee in step 220 contains the correct number of numeric digits. Other validations may also be performed in step 300. Step 300 processing may additionally entail formatting data into a particular string format or other format required by downstream processes.
In step 302, formatted transaction data may be forwarded to a merchant processor, merchant, or other entity as a request for authorization. In the instance of a payment from a credit card or other credit account, credit approval step 306 will be required. The authorization performed in step 306 may involve several different entities, for example a merchant processor 406, a credit card association 408, an issuer processor 410, and a card issuer 412 as will be later described. The underlying inquiries in step 306 may be whether the credit card or other credit account is a valid account, whether the payee is an authorized user of the account, whether sufficient credit exists for the amount of payment requested, and other inquiries.
If credit is approved, a response code or other indication of approval may be sent to the merchant processor or merchant in step 308, the account may be settled with the merchant biller in step 310 (i.e., the merchant's bank account is credited for the amount of the payment), and the customer may be notified of a successful transaction in step 312.
If, on the other hand, the payor's credit is not approved in step 306, then the system may convert the payment request to a Direct Deposit Account (DDA) withdrawal in step 314, instead of a payment with credit. This may be the case, for instance, where the customer payor has specified a DDA as a secondary source for payment in step 220. In step 316, the system may verify that the DDA has sufficient funds for the requested payment transaction. If it does, then funds may be transferred from the payor's DDA to the merchant's account to settle with the merchant biller in step 310. Where the payment is made from the secondary DDA, step 312 notification may indicate that payment was made from the secondary account and not, for example, the primary credit card account that the customer payor previously selected. Of course, where it is determined in step 316 that the DDA also has insufficient funds, then the customer may be notified of a failed transaction in step 318.
In other embodiments, the secondary source for payment may be another credit account, a checking account, a brokerage account, or other account types that are not Direct Deposit Accounts.
FIG. 4 is a functional architecture to implement the process flows of FIGS. 2 and 3, according to one embodiment of the invention. Customer terminal 400 may be a client 140, 150, or 160, and may be used to perform log on step 200, review step 210, data entry step 220, receipt of acknowledgement step 240, and for other process steps.
Middleware platform 402, bank 404, Merchant processor 406, credit card association 408, issuer processor 410, and card issuer 412 may each be a server 100, 110, or 120 as illustrated in FIG. 1 and described above.
Middleware platform 402 may contain network enabled code to collect information entered in step 220, and may also perform step 300 initial data processing. In the event that credit is not approved in step 306, middleware platform 402 may execute conversion step 314. Additionally, middleware platform 402 may provide notification to customer terminal 402 as defined in notification steps 312 and 318, and as appropriate for the circumstances. The commercial Corillian™ or other service may supply the middleware platform or associated middleware services of functional element 402.
The functions of Bank 404 may include step 302 forwarding data to the merchant processor 406 and other process steps. Bank 404 may also perform step 316, determining the sufficiency of funds in a direct deposit account. In an alternative embodiment, the functional node of Bank 404 may be eliminated, in which case middleware platform 402 may communicate directly with merchant processor 406. It may be advantageous for developers of a system embodying the invention to retain Bank 404 as a component of the functional architecture as depicted in FIG. 4. Such may be the case, for instance, where interfaces already exist between bank 404 and middleware platform 402, or where interfaces already exist between bank 404 and merchant processor 406, or for other reasons.
Merchant processor 404 may initiate the request for authorization step 304. This request may be forwarded to credit card association 408, issuer processor 410, and card issuer 412 as shown in FIG. 4. Card issuer 412 may perform step 306, either approving or rejecting the credit transaction.
Credit card association 408 may be, for example, the VISA/MasterCard™, American Express™, or other payment network or interchange. Issuer processor 410 may be or include services, application software, or processors provided by, for example, First Data Corporation, Inc. (FDR), Total Systems Services, Inc. (Total), Electronic Data Systems, Inc. (EDS), or other providers. Card issuer 412 may be First USA, Citibank, or another financial institution that issued a credit card, opened a revolving credit account, or otherwise extended credit to the customer payor.
If the transaction is approved, card issuer 412 may initiate the step 308 approval message, which may be forwarded through the issuer processor 410 and credit card association 408 on its way to merchant processor 406. The actual settlement in step 310 may follow a path identical to that of request for authorization step 304 and approval step 306, except that settlement step 310 may also require that data be passed from merchant processor 406 to merchant biller 414. The execution of settlement step 310 just described is illustrated in FIG. 4 by data path 416. The foregoing description of the invention is illustrative, and variations in configuration and implementation will occur to persons skilled in the art. The scope of the invention is accordingly intended to be limited only by the following claims.

Claims

What is claimed is:

1-62. (canceled)

63. A method for enabling a payor to make one or more online payments to one or more payees using a payment system which enables the payor to make bill payments using a credit card account, of the payor, to payees who do not accept credit card payments, the method comprising:

providing the payor with access to an online payment system operated by a payment administrator, the online payment system operative to process payment to a payee regardless of whether the payee has agreed to use said online payment system;

displaying to the payor, by way of a user terminal, a bill owed to the payee who does not accept credit card payments for the bill;

receiving a bill payment instruction from the terminal, the bill payment instruction comprising information to identify a credit card account of the payor;

charging the credit card account of the payor an amount corresponding to the bill owed to the payee;

causing a payment to be made from the payment administrator to the payee by a payment mechanism not using the credit card account of the payor,

thereby allowing the payee to receive a non-credit card payment for the bill while the payor is charged against the payor's credit card account.

64. The method of claim 63, wherein the online payment system is operative to pay a payee without an electronic interface to the payee.

65. The method of claim 63, wherein causing the payment to be made comprises at least one of: electronic funds transfer into an account of the payee, and printing a paper check and causing the paper check to be delivered to an address of the payee by the online payment system.

66. The method of claim 63, wherein receiving the bill payment instruction comprises receiving identification of at least one secondary account to be used in the event that a payment transaction cannot be completed from the credit card account.

67. The method of claim 63, wherein incentives are credited based on use of the credit card account in connection with the payment.

68. The method of claim 63 wherein the payment administrator comprises the financial institution that issued the credit card account.

69. The method of claim 63, wherein the payor is provided with access to the online payment system via a browser-equipped device.

70. The method of claim 63, wherein the payment comprises a payment scheduled by the payor for a future date.

71. The method of claim 63, wherein the bill payment instruction comprises an instruction for a recurring payment.

72. A method for a payor to make one or more online payments using an online payment system which enables the payor to make bill payments using, a credit card account, to payees who accept credit cards as well as to payees who do not accept credit cards, the method comprising:

providing the payor with access to the online payment system operated by a payment administrator, the online payment system operative to process payment to a payee regardless of whether the payee has agreed to receive payment through said online payment system, wherein the online payment system is operative to pay the payee without an electronic interface to the payee;

presenting to the payor a payment mode of operation for payment of a bill owed the payee that does not accept payment by credit card, the payment mode comprising:

identifying the bill due to the payee, the payee being one that does not accept payment from credit card accounts, the identifying comprising at least one of:

(a) presenting to the payor, by way of a user terminal, the bill owed to the payee, and

(b) receiving from the payor, by way of the user terminal, information to identify an amount owed to the payee, the bill not being presented to the payor by way of the user terminal;

receiving a bill payment instruction, the bill payment instruction comprising information to identify a credit card account of the payor;

causing a payment to be made from the payment administrator to the payee by a payment mechanism not using the credit card account; and

charging the credit card account of the payor for the payment.

73. The method of claim 72, wherein the online payment system is further operative to receive and process online payment instructions for both bills received online and bills received off-line.

74. The method of claim 72, wherein the payment administrator that operates the online payment system comprises the financial institution that issued the credit card account.

75. The method of claim 72, wherein receiving the bill payment instruction comprises receiving identification of at least one secondary account to be used in the event that the payment cannot be completed from the credit card account.

76. The method of claim 75, wherein the at least one secondary account comprises a non-credit card account.

77. The method of claim 72, wherein incentives are credited based on use of the credit card account in connection with the payment.

78. The method of claim 72 wherein the payment mechanism comprises electronically transferring funds into a payee account owned by the payee.

79. A system for a payor to make a payment to a payee who does not accept credit cards, the system comprising a memory for storing instructions and a processor for executing the instructions, which instructions when executed cause the processor to:

provide the payor with access to an online payment interface operated by a payment administrator, the online payment interface operative to process payment to the payee regardless of whether the payee has agreed to receive payment through said online payment interface;

present to the payor a bill owed to the payee;

receive a bill payment data set comprising information to identify a credit card account of the payor;

request authorization for a credit card transaction on said credit card account;

cause a payment to be made from the payment administrator to the payee from the credit card account of the payor; and

charge the credit card account an amount corresponding to the payment.

80. The system of claim 79, wherein the online payment system is operative to pay the payee without an electronic interface to the payee.

81. The system of claim 79, wherein the payment administrator comprises the financial institution that issued the credit card account.

82. The system of claim 79, wherein the payment mechanism comprises electronically transferring funds into a payee account owned by the payee.

83. The system of claim 79, wherein the online payment interface is accessed via a browser-equipped device.

84. The system of claim 79, wherein the payment comprises a payment scheduled by the payor for a future date.

85. The system of claim 79, wherein the payment instruction comprises an instruction for a recurring payment.