Note: Descriptions are shown in the official language in which they were submitted.
CA 02267042 1999-03-26
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
CA 02267042 1999-03-26
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
2
CA 02267042 1999-03-26
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.
CA 02267042 1999-03-26
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
4
CA 02267042 1999-03-26
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.
