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 
       [0001]    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 
       [0002]    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 
       [0003]    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. 
         [0004]    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&#39;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. 
         [0005]    These and other drawbacks exist. 
       SUMMARY OF THE INVENTION 
       [0006]    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). 
         [0007]    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 
         [0008]    The invention will be described with reference to the accompanying drawings, in which like elements are referenced with like numbers. 
           [0009]      FIG. 1  is a system architecture diagram, according to one embodiment of the invention. 
           [0010]      FIG. 2  is a process flow diagram from the perspective of a customer, according to one embodiment of the invention. 
           [0011]      FIG. 3  is a process flow diagram from the perspective of a provider of online payment services, according to one embodiment of the invention. 
           [0012]      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 
       [0013]      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 . 
         [0014]    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. 
         [0015]    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. 
         [0016]    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. 
         [0017]    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. 
         [0018]    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. 
         [0019]      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. 
         [0020]    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. 
         [0021]    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. 
         [0022]    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&#39;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. 
         [0023]    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. 
         [0024]    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. 
         [0025]    From the customer payor&#39;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&#39;s primary account. Once step  240  concludes, the payment transaction terminates in step  250 . 
         [0026]      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. 
         [0027]    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. 
         [0028]    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. 
         [0029]    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&#39;s bank account is credited for the amount of the payment), and the customer may be notified of a successful transaction in step  312 . 
         [0030]    If, on the other hand, the payor&#39;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&#39;s DDA to the merchant&#39;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 . 
         [0031]    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. 
         [0032]      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. 
         [0033]    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. 
         [0034]    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 . 
         [0035]    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. 
         [0036]    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. 
         [0037]    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. 
         [0038]    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.