CA2267042A1 - Method and system for local electronic bill presentment and payment ebpp - Google Patents

Description

Title Method and System for Local Electronic Bill Presentment and Payment EBPP
Background of the Invention Electronic Bill Presentment and Payment ("EBPP") is being used by billers such as utility companies and telephone companies to deliver billing information to their customers.
Traditionally this information has been delivered as a printed paper document through postal mail. With EBPP the bill information is converted to an electronic format such as HTML
("Hypertext Markup Language") (or any other suitable format), and posted on a web site (or other suitable access point) for the customer to view using the Internet (or other suitable electronic communication media). The customer can electronically make the payment while at the bill presentment web site. Two models are being used today, consolidator and direct. In the consolidator model, a number of billers send their bills electronically to the host consolidator providing a centralized presentment of bills for the consumer. In the direct model, billers host their own bill presentment web site and customers must visit each of their billers web sites.
Problem 1 Electronic Bill Presentment and Payment EBPP models proposed to date are based on the Consolidator Biller model and the Direct Biller models. Both models require the biller's customer to log onto the bill presentment web sites which is hosted by the consolidator in the consolidator model, or the biller in the direct model. There are several problems associated with both of these models.
Because the bills are processed and centrally consolidated by the consolidator, the consolidator is viewed as providing a service to the customer. In addition to other possible problems, there are the following problems with the consolidator model:
1. Loss of biller and customer direct relationship

2. Potential of cross selling to the biller's customer through the consolidator by other billers

3. Intermediary costs paid to the consolidator for hosting the web site

4. Loss of privacy for customer and the biller. The consolidator has the potential to monitor transactions and collect data.

5. Payment may need to be handled by an intermediary payment processor resulting in more costs.
In addition to other possible problems, there are the following problems with the direct biller model:
1. Difficulty for a customer to manage many direct biller hosted web sites 2. Payment may need to be handled by an intermediary payment processor It is an object ofthe invention to provide a novel method and system for Electronic Bill Presentment and Payment which obviates or mitigates at least one of the disadvantages of the prior art.
Solution to Problem 1 In the present invention for EBPP, based on existing electronic check or "echeck" technology, bills are locally consolidated by the customer rather then being centrally consolidated by the consolidator. One type of electronic check is discussed in U.S. Patent 5,677,955. As an example of local consolidation, the billers send bills directly to the customer over Internet email in the same flow as paper bills are now sent from billers to customers. Local consolidation provides the customer with the benefit of the automated consolidation but unlike existing EBPP systems it also preserves the benefit of the direct and private relationship between the biller and customer, as is now found in paper bills mailed to the customer. Accordingly, Billers do not need to hand their customers to others.
Furthermore, because there is no need for an intermediary, the costs can be reduced. Payments can be made using echeck eliminating the need for a payment processor.
Upon receiving and reviewing the ebill, the customer emails an echeck to the biller directly. In a particular aspect of the invention, electronic document processing allows for the automated creation of the echeck from the ebill ("electronic bill"). In addition, local consolidation of EBPP, which can also be called private EBPP, can enable mobile eBilling using PDA's ("Personal Digital Assistants" such as a Palm Pilot III equipped with a pager card or a RIM
Pager) that access Internet email.
Problem 2 The electronic cheque or "echeck" as a payment mechanism will require an echeck payers bank to be echeck enabled in order for echeck issuers and echeck depositors to use echecks. This lack of echeck infrastructure could inhibit the quick adoption of echeck for use in electronic bill presentment and electronic payment (EBPP) where a biller has many customers who may bank with many different banks who may not even be aware of echeck.
Solution to problem 2 For private EBPP, electronic check conversion of the echeck to an ACH
("Automated Clearing House") funds transfer payment, by the biller, would allow all customers of the biller to pay their bill with an echeck, regardless of their bank's ability to process echecks.
(Additional information regarding prior art methods of converting paper checks to ACH can be found at http://www.nacha.org/ecc/default.htm, an extract of which has been provided below.
"A check (being used as a source document), which is voided, is presented by the consumer and provides the MICR data necessary to format and route the electronic transaction to~the consumer' s account. The retail merchant obtains the consumer' s signature on an authorization and once the transaction is complete, the check is handed back to the consumer.
The ACH debit transaction is originated by the retail merchant or its processor (originator) and deposited with the collecting bank (ODFI). Each ACH debit transaction is sent by the ODFI through an ACH
Operator to the paying bank (RDFI). There is no storage requirement for the paper check, since it is handed back to the consumer.
However, since this transaction is governed by Regulation E, the retail merchant/originator is required to retain a copy of the signed authorization, and to produce a copy in the event of a dispute. The Originator will locate the signed authorization and other information as necessary to collect the returned ACH debit.
ACH returns are originated by the RDFI as necessary back through the ACH
Operator to the ODFI. The ODFI returns the ACH entry to the Originator. The ODFI or Originator can re-initiate in accordance with NACHA Rules." ) For those customers whose banks (payer bank) are not echeck enabled, the biller, biller's bank or other authorized agent for the biller could convert those echecks to an ACH
transaction. For those customers whose banks are echeck enabled, the check could be deposited in the biller's account as an echeck. As more banks become echeck enabled, the RDM echeck sorting technology would direct the legal echecks to now be echeck deposited.
The biller will deploy common echeck based electronic presentment and payment check issuing software to all of its customers regardless of the customers bank's (payer bank) ability to process an echeck.
Ebills would be emailed directly to the customer. The customer would pay their bills with an echeck payment. The echeck processing software at the biller (or at the bank) would sort the echecks by the customer's bank's ability to process echecks. The sort could be done by keeping a database of echeck enabled banks or by determining the origin of the customers digital certificate. Other sorts will occur to those of skill in the art and are within the scope of the invention. For example a biller or biller bank could issue the certificate.
If the sort determined that the customers bank could process echecks, (directly or through a third party) the biller would deposit the echeck.
If the sort determined that the customer's bank could not process echecks the biller could convert the echeck to an ACH payment that all banks can accept.

This solution would allow the immediate use of echeck for EBPP regardless of the infrastructure that exists for echecks.
If the customer's bank is echeck-enabled they may obtain their certificates directly from their bank. If the customer's bank is not echeck-enabled, the biller would deploy the certificates to the customer via a hardware token or as a software token via the Internet.
Innovations 1 The concept of EBPP where the biller(s) sends the bill directly to the customer and not by posting the bill on a web site hosted by the biller or by a consolidator.
2 The concept of consolidating the bills locally by the customer 3 The concept of interpreting a print stream, parsing it and converting the information to a machine processable electronic document and emailing it to a customer.
4 The concept of sorting an echeck by the payer bank's ability to process echecks The concept of sorting echecks by the origin of the certificates used to sign the echeck

6 Based on the echeck sort, the concept of converting the echeck to an electronic payment form, such as ACH, that will allow the transaction to complete, using the echeck in effect as a source document for obtaining payers bank account information and using the fact that it has been signed by the payer using a digital signature that has been accepted by both the biller and the payer as an authorization to do the ACH conversion.

7 Based on the echeck sort, the concept of converting the echeck to an electronic payment form, such as ACH, that will allow the transaction to complete, using the echeck in effect as a source document for obtaining payers bank account information and using the fact that it has been signed by the payer using a digital signature that has been accepted by both the biller and the payer and accompanied (attached) by an authorization document as referenced above in the quote from NACHA digitally signed by the Payer.
In an embodiment of the invention there is also provided a method to void the echeck which can be a necessary part of the conversion to ACH process. Here is an example of how this could be done:
a) Remove the signature block of the Payer from the eCheck and resave the eCheck so that the original eCheck is deleted. This copy of the eCheck will no longer validate.
b) Encrypt the signature block of the Payer using the public key of the Payee or the Public key of a third party such as the legal firm of the Payee. This allows the Payee to recover the signature block of the Payer (using the Payee's private key or have your legal firm recover it and provide a signed testament to that effect) reassemble the original eCheck and validate the signature. This ensures that the Payer can not repudiate the source document (the "voided" eCheck) used to support the conversion to ACH.
The Payee (or the Payee's legal firm or 3rd party as appropriate) will need to maintain in a secure location a history of Private Keys which expire from time to time.
c) Store the encrypted signature in such a way that it can be associated with the "voided" eCheck.
The attached Figures are examples of the present invention which reference certain embodiments.
Figure 1 is a flowchart of a method for local consolidation of electronic bill presentment to a customer and payment by the customer Figure 2 is a flowchart of a method for processing an electronic check received by a customer in payment of an electronic bill.
While only specific combinations of the various features and components of the present invention have been discussed herein, it will be apparent to those of skill in the art that desired sub-sets of the disclosed features and components and/or alternative combinations of these features and components can be utilized, as desired.

Claims