U.S. patent application number 10/752874 was filed with the patent office on 2004-08-26 for integrated systems for electronic bill presentment and payment.
Invention is credited to Sharma, Dushyant.
Application Number | 20040167853 10/752874 |
Document ID | / |
Family ID | 22641497 |
Filed Date | 2004-08-26 |
United States Patent
Application |
20040167853 |
Kind Code |
A1 |
Sharma, Dushyant |
August 26, 2004 |
Integrated systems for electronic bill presentment and payment
Abstract
The present invention relates generally to electronic commerce,
and more particularly to methods and systems for integrating
electronic bill presentment and payment among billers, consumers,
banks and other financial institutions, electronic payment
facilitators, and web portals and other spaces able to support an
interface for presentment and/or payment of bills.
Inventors: |
Sharma, Dushyant; (Richmond
Hill, CA) |
Correspondence
Address: |
REINHART BOERNER VAN DEUREN S.C.
ATTN: LINDA GABRIEL, DOCKET COORDINATOR
1000 NORTH WATER STREET
SUITE 2100
MILWAUKEE
WI
53202
US
|
Family ID: |
22641497 |
Appl. No.: |
10/752874 |
Filed: |
January 7, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10752874 |
Jan 7, 2004 |
|
|
|
09751265 |
Dec 29, 2000 |
|
|
|
60175753 |
Jan 12, 2000 |
|
|
|
Current U.S.
Class: |
705/40 |
Current CPC
Class: |
G06Q 20/02 20130101;
G06Q 20/14 20130101; G06Q 30/04 20130101; G06Q 30/06 20130101; G06Q
20/102 20130101; G06Q 20/04 20130101 |
Class at
Publication: |
705/040 |
International
Class: |
G06F 017/60 |
Claims
What is claimed is:
1. An electronic bill presentment and payment system, said system
comprising: a database for storing data relating to a plurality of
bills sourced from a plurality of billers, and corresponding to a
plurality of consumers; a conversion processing communicating with
said database for converting data from said plurality of billers
into a format compatible with said database; a biller interface
communicating with said database for allowing at least some of said
plurality of billers to review and obtain reports in real time from
data relating to said billers and status of said biller's bills
stored in said database; a processing capacity communicating with
said database for supporting a plurality of visual interfaces, each
of said visual interfaces allowing a consumer to review and pay
said consumer's bills; a consumer interface communicating with said
database for allowing said consumer to change information in said
database; and an authentication capacity communicating with said
database for determining whether said consumer meets certain
predetermined requirements before a new account is authorized to
access said database.
2. A system as defined in claim 1, wherein said authentication
capacity includes an input capacity for allowing said consumer to
input personal information that can be used to identify and
authenticate said consumer.
3. A system as defined in claim 1, wherein said authentication
capacity includes a credit verifier for determining whether said
consumer has been authorized to access said database, said credit
verifier providing consumer credit information to said
authentication capacity.
4. A system as defined in claim 1, wherein said credit verifier is
a third party credit reporting agency.
5. A system as defined in claim 4, wherein said consumer is
authorized access to said database by said credit verifier during a
particular consumer session on a visual interface, only after an
interactive session between said system and said credit verifier
during said consumer session.
6. A system as defined in claim 1, further comprising: a biller
authentication capacity communicating with said database for
authenticating each of said plurality of billers.
7. A system as defined in claim 1, further comprising: processing
capacity capable of communicating with a plurality of financial
institutions to couple said financial institutions to said database
to facilitate payment of bills.
8. A system as defined in claim 1, further comprising: processing
capacity capable of communicating with a plurality of payment
facilitators to couple said payment facilitators to said database
to facilitate payment of bills.
9. A method for electronic billing presentment and payment, said
method comprising the steps of: storing data relating to a
plurality of bills sourced from a plurality of billers, and
corresponding to a plurality of consumers in a database; converting
data from said plurality of billers into a format compatible with
said database; allowing at least some of said plurality of billers
to review and obtain reports in real time from data relating to
said billers and status of said biller's bills stored in said
database; supporting a plurality of visual interfaces, each of said
visual interfaces allowing a consumer to review and pay said
consumer's bills; determining whether said consumer meets certain
predetermined requirements before a new account is authorized to
access said database; communicating with said database for allowing
said consumer to change information in said database; and allowing
said consumer to pay bills from one of said visual interfaces.
10. A method as defined in claim 9, wherein said step of allowing a
consumer to pay bills further comprises the steps of: receiving
from said consumer logon information; initiating an interactive
session with a credit verifier to obtain authorization for said
consumer to have access to information from said database, said
credit verifier providing consumer credit information to said
authentication capacity; and after said authorization from said
credit verifier has been received from said credit verifier,
allowing said consumer to access information in said database in
order to pay bills.
11. A method as defined in claim 10, wherein said credit verifier
is a third party credit reporting agency.
12. A method as defined in claim 10, wherein said consumer is
authorized access to said database by said credit verifier during a
particular consumer session on a visual interface, only after an
interactive session between said database and said credit verifier
during said consumer session.
13. A method as defined in claim 9, further comprising the step of:
allowing said consumer to input personal information that can be
used to identify and authenticate said consumer.
14. A method as defined in claim 9, further comprising the step of:
communicating with said database for authenticating each of said
plurality of billers.
15. A method as defined in claim 9, further comprising the step of:
allowing said consumer to inquire online about status of at least
one bill, said inquiry being conveyed to particular billers.
16. A method as defined in claim 9, further comprising the step of:
automatically notifying a biller when a consumer has paid a
bill.
17. A method as defined in claim 9, further comprising the step of:
allowing a biller to modify, online, the format in which a bill is
presented to said consumer on said visual interface.
18. A method as defined in claim 9, further comprising the step of:
allowing said consumer to modify, online, the format in which a
bill is presented to said consumer on said visual interface.
19. A method as defined in claim 9, further comprising the step of:
allowing said consumer to pay bills from a plurality of visual
interfaces, wherein each of said visual interfaces resides on a
different Internet Website.
20. A method for electronic billing presentment and payment, said
method comprising the steps of: storing data relating to a
plurality of bills sourced from a plurality of billers, and
corresponding to a plurality of consumers in a database;
communicating with said database for authenticating each of said
plurality of billers; converting data from said plurality of
billers into a format compatible with said database; allowing at
least some of said plurality of billers to review and obtain
reports in substantially real time from data relating to said
billers and status of said biller's bills stored in said database;
supporting a plurality of visual interfaces, each of said visual
interfaces allowing a consumer to review and pay said consumer's
bills; determining whether said consumer meets certain
predetermined requirements before a new account is authorized to
access said database, said determining step including obtaining
consumer credit information; allowing said consumer to input
personal information that can be used to identify and authenticate
said consumer wherein said input information is compared to said
consumer credit information; communicating with said database for
allowing said consumer to change information in said database; and
allowing said consumer to pay bills from one of said visual
interfaces.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This patent application is a continuation of U.S. patent
application Ser. No. 09/751,265, filed on Dec. 29, 2000, entitled
"Integrated Systems for Electronic Bill Presentment and Payment,"
the entirety of which is incorporated herein by reference.
BACKGROUND OF THE INVENTION
[0002] Field of Invention
[0003] The present invention relates generally to electronic
commerce, and more particularly to methods and systems for
integrating electronic bill presentment and payment among billers,
consumers, banks and other financial institutions, electronic
payment facilitators, and web portals and other spaces able to
support an interface for presentment and/or payment of bills.
[0004] Billing consumers for goods and services has always been a
necessary exercise and transaction cost of engaging in credit-based
commerce. Traditionally, businesses bill consumers for goods and
services by generating and mailing paper bills or invoices. There
are many obvious business concerns relative to paper-based billing.
Companies utilizing paper-based billing do so at a substantial
cost. For example, a company with 100,000 accounts which are billed
on a monthly basis may spend over two million dollars a year in
paper-based billing expenses. Much of this expense stems from the
cost of materials, postage, and manual processing of the paper
bills, inserts, and envelopes.
[0005] Other significant logistical and business concerns detract
from the paper-based billing option. The time delay associated with
sending bills and receiving payments via conventional mailing
deprive companies of the time value of money and therefore create
additional transactional costs. This time delay is particularly
troublesome to small billers and non-recurrent billers who tend to
rely more heavily on cash flow.
[0006] Paper-based billing can also deprive billers of an
opportunity to build brand. Although many paper billers include
various types of marketing inserts with their bills in an attempt
to use the billing activity as an additional opportunity to make
favorable brand impressions on the consumer, those materials cannot
be targeted as effectively as in an interactive session. For
instance, billers do not have significant realistic control over
the circumstances under which, or whether, a consumer views
particular inserts. Indeed, studies have shown that many consumers
disregard such inserts altogether.
[0007] The development of the Internet creates new opportunities to
transact business electronically, including to conduct the billing
presentment and payment process electronically, in an on-line way
or otherwise. Some refer to various aspects of the electronic
billing process as electronic bill presentment and payment (EBPP).
Instead of mailing paper bills, EBPP enables businesses to publish,
distribute and/or present bills electronically on web pages.
Instead of writing checks and applying stamps, consumers have the
opportunity to pay bills by an electronic credit card charge or
direct bank draft. The biller benefits by avoiding the cost of
generating and mailing paper bills, and by avoiding the payment
float occasioned by two-way mail delay and other delays in
paper-based remittance. The consumer benefits with the added
convenience of conducting transactions online, and the opportunity
to pay many or all bills on one site or in one virtual space.
[0008] In practice, however, there are significant concerns with
conventional approaches to EBPP. For example, in one common
approach to EBPP, which is often referred to as the custom
development method, billers create a proprietary electronic billing
system and link it to a third-party for payment processing. Because
custom development is mostly an internal EBPP solution, it gives
billers the advantage of tight control over the billing system.
However, this type of solution is very costly. Not only is it a
technology risk because billers lose the flexibility to adapt to
other EBPP standards, but it requires a substantial amount of
manpower and infrastructure. Furthermore, such systems innately
discourage consumer use or popularity, since the consumer is
required to log onto and initiate a session on a separate site for
each different bill the consumer wishes to pay.
[0009] A second common EBPP approach, which is referred to as the
consolidator approach, presents its own set of problems. This
method of enabling EBPP trades control of the billing interface and
branding opportunity for a reduction in cost, risk, and internal
staffing by outsourcing the EBPP to a third party consolidator.
Here, the electronic payment processor takes on a lock box function
of holding and moving cash during billing and payment. The payment
processor performs an aggregation function by presenting multiple
billers' statements at a single, consolidating web site. Not only
does interposition of the consolidator and its interface between
billers and consumers interrupt any existing relationship, but it
also precludes exploitation of new biller opportunities to interact
with consumers.
[0010] In addition to the problems already mentioned, existing EBPP
enabling methods have various other disadvantages. For example,
they remain an expensive option for most billers who lack
sufficient economies of scale necessary to overcome the high fixed
cost of implementation. These EBPP methods, which primarily focus
on reducing biller costs, also often fail to address the issue of
consumer convenience adequately, much less to provide effective
incentives for consumer adoption.
[0011] Furthermore, conventional EBPP approaches, which seek to
implement EBPP on portal interfaces, often require redundant
resources supported by multiple entities and consequently waste
processing and transport resources. For example, using existing
EBPP methods, if a consumer desires to pay AT&T bills
electronically at a website such as Yahoo.com, the following
occurs. First, the consumer requests that Yahoo.com receive the
AT&T bill and send it to the consumer. Then, assuming AT&T
partners with an electronic payment facilitator such as CheckFree,
Yahoo.com makes a request to CheckFree. Finally, CheckFree
initiates the request to AT&T. Because each of these entities
are independent, each requires its own resident database and other
support functionality. Such conventional portal-supported EBPP
approaches provide significant opportunity for improvement.
SUMMARY OF THE INVENTION
[0012] The present invention provides fully integrated, end-to-end
electronic bill presentment and payment systems. Such systems
support integrated EBPP access and functionality for billers,
consumers, banks, other financial institutions, and other
electronic payment facilitators, any or all of which can be
transacted at a web portal, web site or other interface or virtual
space ("Portal Interface"). Such systems can support such
activities at multiple portals, so that consumers and others have
the choice of paying bills and accomplishing other EBPP
transactions in whatever virtual space or at whatever site they
desire. The systems provide consumers, billers and others the
ability to self-enable EBPP by interacting with the portal
interface such as via a series of web pages. Such systems of the
present invention can control all interactions between billers and
consumers from the portal interface. In addition, the systems can
seamlessly orchestrate all other transactions with payment
facilitators and banks. Therefore, all EBPP functionality and
processes can be controlled by systems and processes according to
the present invention.
[0013] The Portal Interface controlled by systems of the present
invention provides individual consumers with a secure personalized
electronic bill portfolio where they can schedule, view, and pay
their electronic bills. The Portal Interface controlled by such
systems also enables billers to create consumer accounts and
electronically publish their bills on a personalized electronic
bill portfolio for viewing and payment. The systems can provide all
bill processing, payment processing, consumer and biller data
storage, and arrange all external billing transactions.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] FIG. 1 is a block diagram showing external connectivity of a
preferred embodiment of integrated electronic bill presentment and
payment systems of the present invention.
[0015] FIG. 2 is a block diagram illustrating the architecture of a
preferred embodiment of integrated electronic bill presentment and
payment systems of the present invention.
[0016] FIG. 3 is a block diagram illustrating general functionality
of a customer-related portal interface supported by a preferred
embodiment of integrated electronic bill presentment and payment
systems of the present invention.
[0017] FIG. 4 is a block diagram illustrating general functionality
of a biller-related portal interface supported by a preferred
embodiment of integrated electronic bill presentment and payment
systems of the present invention.
[0018] FIG. 5 is a sign in screenface of a portal interface
generated by a preferred embodiment of systems of the present
invention.
[0019] FIG. 6 is a help screenface of a portal interface generated
by a preferred embodiment of systems of the present invention.
[0020] FIG. 7 is an inbox screenface of a portal interface
generated by a preferred embodiment of systems of the present
invention.
[0021] FIG. 8 is a bill summary list screenface of a portal
interface generated by a preferred embodiment of systems of the
present invention.
[0022] FIG. 9 is a company list screenface of a portal interface
generated by a preferred embodiment of systems of the present
invention.
[0023] FIG. 10 is an add a company screenface of a portal interface
generated by a preferred embodiment of systems of the present
invention.
[0024] FIG. 11 is a my outbox screenface of a portal interface
generated by a preferred embodiment of systems of the present
invention.
[0025] FIG. 12 is a pay accounts screenface of a portal interface
generated by a preferred embodiment of systems of the present
invention.
[0026] FIG. 13 is a preferences screenface of a portal interface
generated by a preferred embodiment of systems of the present
invention.
[0027] FIG. 14 is a change password screenface linked off the
preferences screenface of a portal interface generated by a
preferred embodiment of systems of the present invention.
[0028] FIG. 15 is a personal information screenface linked off the
preferences screenface of a portal interface generated by a
preferred embodiment of systems of the present invention.
[0029] FIG. 16 is payment reminder creation screenface linked off
the preferences screenface of a portal interface generated by a
preferred embodiment of systems of the present invention.
[0030] FIG. 17 is a generic create a reminder screenface linked off
the preferences screenface of a portal interface generated by a
preferred embodiment of systems of the present invention.
[0031] FIG. 18 is a contact customer service screenface linked off
the preferences screenface of a portal interface generated by a
preferred embodiment of systems of the present invention.
[0032] FIG. 19 is a biller signup screenface of a portal interface
generated by a preferred embodiment of systems of the present
invention.
[0033] FIG. 20 is a bill template design step 1 screenface of a
portal interface generated by a preferred embodiment of systems of
the present invention.
[0034] FIG. 21 is a bill template design step 3 screenface of a
portal interface generated by a preferred embodiment of systems of
the present invention.
[0035] FIG. 22 is a bill template design step 2 screenface of a
portal interface generated by a preferred embodiment of systems of
the present invention.
[0036] FIG. 23 is an invoice creation step 1 screenface of a portal
interface generated by a preferred embodiment of systems of the
present invention.
[0037] FIG. 24 is an invoice creation step 2 screenface of a portal
interface generated by a preferred embodiment of systems of the
present invention.
[0038] FIG. 25 is an invoice preview screenface of a portal
interface generated by a preferred embodiment of systems of the
present invention.
[0039] FIG. 26 is a report builder screenface of a portal interface
generated by a preferred embodiment of systems of the present
invention.
[0040] FIG. 27 is a reports screenface of a portal interface
generated by a preferred embodiment of systems of the present
invention.
[0041] FIG. 28 is an upload bills screenface of a portal interface
generated by a preferred embodiment of systems of the present
invention.
[0042] FIG. 29 is bill quality assurance screenface of a portal
interface generated by a preferred embodiment of systems of the
present invention.
[0043] FIG. 30 is a second bill quality assurance screenface of a
portal interface generated by a preferred embodiment of systems of
the present invention.
[0044] FIG. 31 is a third bill quality assurance screenface of a
portal interface generated by a preferred embodiment of systems of
the present invention.
[0045] FIG. 32 is an add an account screenface of a portal
interface generated by a preferred embodiment of systems of the
present invention.
[0046] FIG. 33 is a send customer e-mail screenface of a portal
interface generated by a preferred embodiment of systems of the
present invention.
DETAILED DESCRIPTION OF THE INVENTION
[0047] FIG. 1 shows connectivity of a preferred embodiment 10 of
integrated electronic bill presentment and payment systems
("systems") of the present invention. System embodiment 10
interfaces with, among other external entities, billers 12, which
may include very small and non-recurrent billers 14, banks and
other financial institutions 16, payment facilitators 18, web
portals and bill presenters 20, and consumers 22. System embodiment
10 shown in FIG. 1 is implemented on a Sun platform using an Oracle
database with other programs that allow connectivity via any
desired network or transport infrastructure, preferably the
Internet, to a portal interface in spaces 20 via an Extensible
Markup Language or other standard markup or other common data
interchange model or language. Portal interfaces 15 may be
implemented in Hypertext Markup Language or as otherwise desired to
operate on browsers, whether or not applet enabled, or as otherwise
desired.
[0048] FIG. 2 shows an architecture diagram for a preferred
embodiment 10 of systems according to the present invention. System
embodiment 10 supports a portal interface 15 which allows consumers
22 and billers 12 and/or 14 the ability to self-enable EBPP by
interacting with a series of web pages or other interfaces or
presentations of whatever desired design or type on a web portal 20
or at any other location in actual, electronic or virtual space,
supported by the global information infrastructure, successor
systems, private systems or any other communications network or
system. System embodiment 10 can enable all EBPP functionality via
the portal interface 15. System embodiment 10 can control all
interactions or transactions between billers 12 and/or 14 and
consumers 22 using portal interface 15 as the communications and/or
presentation medium. System embodiment 10 can also arrange all
other necessary transactions with payment facilitators 18 and banks
16.
[0049] System embodiment 10 may be created to allow consumers 22 to
define whatever portal or any other location or space they desire
to access system embodiment 10. This can be any web portal 20 or
other bill presentment web site, such as Yahoo.com.RTM. or
G02Net.RTM.. In order to initialize a bill portfolio, consumers 22
can go to the selected web portal or other space 20. System
embodiment 10 prompts consumers 22 for personal information
sufficient for authentication. System embodiment 10 can be adapted
only to assign consumers 22 a secure bill portfolio when consumers
22 can be authenticated by a third party credit reporting agency.
After being verified, a consumer bill portfolio may be access
controlled by any desirable schema or paradigm, including by using
a bill portfolio identification number, a unique consumer
identification number, and an encryption key defined by consumers
22. Consumers 22 may also define multiple accounts at the same bill
portfolio.
[0050] FIG. 3 illustrates the general functionality of a preferred
embodiment of a consumer portal interface supported by system
embodiment 10. System embodiment 10 provides consumers 22 a secure
personalized portfolio for viewing and paying electronic bills that
are input into system embodiment 10 by various billers. System
embodiment 10 directs all incoming electronic bills to the bill
portfolio of consumers 22. Consumers 22 also have the option of
notifying paper-based billers that they desire to have bills
presented electronically. System embodiment 10 can notify the
billers and initiate electronic scanning of paper bills. Consumers
22 may access the portfolio at any location of choice using any
interface, such as, for instance, a conventional web browser, other
online device, any wireless device, or any other device which may
communicate with system embodiment 10 in any manner. Any such
device is a candidate to support presentation of or transaction
with portal interface 15 by consumers 22. Consumers 22 can also
define the format of the billing information. For example, the
billing data may be supplied to consumers 22 in a variety of
standard accounting formats.
[0051] System embodiment 10 also enables consumers 22 to pay
electronic bills via credit card, ACH, or electronic funds transfer
or using any other mode or medium of payment or reconciliation.
System embodiment 10 can also support payments between different
consumer bill portfolios. In addition, system embodiment 10 can
provide for various types of communication between or among billers
12 and/or 14 and consumers 22 and between or among consumers
22.
[0052] FIG. 4 illustrates the general functionality of a preferred
embodiment of a biller interface in accordance with the present
invention with system embodiment 10. Billers 12 and/or 14 may
self-enable EBPP by accessing system embodiment 10. System
embodiment 10 can obtain information from billers 12 and/or 14 and
authenticate by a credit verifier service if desired. After a
biller is authenticated, system embodiment 10 enables billers 12
and/or 14 to define the presentation of the bill, among other
things. Billers 12 and/or 14 may also do such things as customize
bill templates, upload logos, addresses, and define bill fields.
System embodiment 10 may support billers 12 and/or 14 carrying out
any desired or desirable task, such as specifying marketing
messages that are defined by consumer specific rules, set up
consumers 22 to bill and/or set up specialized consumer groups
based on predefined rules.
[0053] Billers 12 and/or 14 can also specify various other bill
generation criteria. The bill criteria can accommodate criteria
such as whether the bill is for a fixed amount or whether it is
formula based. Billers can also specify the bill schedule.
[0054] Billers 12 and/or 14 may bill consumers 22 by inputting any
bill data. System embodiment 10 enables billers 12 and/or 14 to
predefine how the electronic bill is to be displayed. System
embodiment 10 also manages the routing of the bills. System
embodiment 10 selects the biller-defined delivery channel, which
could be either paper or electronic. If a bill portfolio exists,
the bill is placed in it. If the billed consumer 22 does not have a
bill portfolio, electronic deliveries can be sent via email along
with a message notifying consumer 22 that the biller is using
electronic billing. If neither exists, system embodiment 10 can
perform standard paper billing. System embodiment 10 may also
enable billers 12 and/or 14 to identify conventional mailing
addresses for consumers 22 so that consumers 22 may enable standard
paper billing. System embodiment 10 may also provide notification
to billers 12 and/or 14 when bills are rejected, bills are overdue,
or payments are received.
[0055] FIGS. 5-18 show web pages of a preferred embodiment of a
consumer portal interface on a web portal 20 controlled by system
embodiment 10. As mentioned above, the interface 15 can appear on
any device in any location in actual, electronic or virtual space,
using any network or communications system; use of the web and
browser paradigm for the following description is merely one
example and should not be interpreted to limit the invention or its
scope in any way. That said, FIGS. 5 and 6 show web pages for the
initial welcome screens for a web portal 20 of system embodiment
10. As any other web site or web portal 20 on the Internet, the
welcome screen and all linked web pages on web portal 20 are freely
accessible to billers 12 and/or 14 and consumers 22 using any
standard web browsing software and computer. Consumers 22 may also
access the web pages by using any device of whatever stripe, such
as a personal digital assistant, a cellular phone, or pager, which
supports Internet access via wireless technology, standard
telephone dial-up or network connections, or any communications
system.
[0056] The welcome screen permits new billers 12 and/or 14 and
consumers 22 to create a new account. When setting up a new
account, billers 12 and/or 14 and consumers 22 are required to
input personal information that can be used to identify and
authenticate the user for subsequent sessions. After the user
inputs the personal information, the system can contact a credit
verifier company, such as Equifax.RTM. or TRW.RTM., and uses a
credit report supplied by the company to automatically determine
whether the user meets certain predetermined requirements, in which
case a new account may be created.
[0057] After creating an account, the welcome screen permits new
consumers 22 to create a new personalized bill portfolio or
additional bill portfolios. Some sophisticated consumers 22 may
desire to have separate bill portfolios within the same account for
multiple homes, separate individuals within a home, or for a
separate business. After a biller account is established, new
billers 12 and/or 14 may access the biller functionality, which is
discussed below.
[0058] The welcome screen also permits billers 12 and/or 14 and
consumers 22 that have already registered to access system
embodiment 10 by inputting a user identification number, a
personalized password, and an encryption key. These user specific
identifiers ensure that only registered users that have been
authenticated are granted access to personal information stored on
system embodiment 10.
[0059] FIGS. 7-18 show a series of web pages for a personalized
bill portfolio management system that registered consumers 22 use
to access and interact with a bill portfolio via portal interface
15. FIG. 7 shows an incoming bill web page that enables consumers
22 to interact with all incoming electronic bills including
electronic bills that have been received but remain unpaid and
paper bills that have been received and scheduled for electronic
presentment. For each bill, the web page displays the biller's
name, the amount due, the date payment is due, and the status of
the bill. Consumers 22 may also select and view each electronic
bill. FIG. 8 shows a web page displaying a sample bill summary and
payment information. The incoming bill web page also permits
consumers 22 to select and electronically pay particular bills.
[0060] System embodiment 10 enables consumers 22 to notify paper
billers that they desire to have bills presented electronically.
System embodiment 10 can contact the paper-based biller and notify
the biller that their electronic bills may be presented to
consumers via system embodiment 10. If the biller declines, system
embodiment 10 can arrange to have the paper bill scanned into
system embodiment 10 where it can be viewed and paid by consumers
22 using system embodiment 10. Paper bills that have been received
and are being processed for scanning and electronic presentment are
displayed on the incoming bill web page as "scheduled". System
embodiment 10 may also enable billers 12 and/or 14 to identify
conventional mailing addresses for consumers 22 so that consumers
22 may enable standard paper billing.
[0061] FIG. 9 shows a biller list web page that enables consumers
22 to list the companies whose bills they desire to pay
electronically. For each biller 12 and/or 14, the web page displays
the company name, a corresponding identification number, and
whether or not the company has been scheduled for electronic bill
presentment and payment. Consumers 22 may also use the web page to
modify the configuration for a biller 12 and/or 14 or to delete a
biller 12 and/or 14 from the list altogether. FIG. 10 shows a web
page that enables consumers 22 to add additional billers 12 and/or
14 for electronic bill presentment and payment. The web page has a
series of pull down menus enabling a consumer 22 to define a biller
configuration. One menu allows the consumer 22 to define a
particular category for the biller 12 and/or 14. For example,
consumers 22 may categorize billers 12 and/or 14 as a utility
biller, telecommunications service biller, credit card biller,
professional services biller, or any other category of relevance to
the consumer. Another menu allows the consumer 22 to select a bill
delivery method such as CheckFree.RTM. or any other third party
electronic payment facilitator 18. Other menus permit the consumer
22 to input the account number for the biller 12 and/or 14, as well
as an expiration date. Consumers 22 may also elect to enable
functionality permitting a recurring payment schedule.
[0062] FIG. 11 shows an outgoing bill web page that enables
consumers 22 to interact with electronic bills that have already
been paid. Similar to the incoming bill web page, the outgoing bill
web page displays the biller's name, the amount due, the date
payment is due, and whether or not the bill has been paid.
Consumers 22 may also select and view a bill summary and payment
information screen for a particular bill. Finally, consumers 22 may
select and delete bills that have already been paid.
[0063] FIG. 12 shows a payment accounts web page that enables a
consumer 22 to view, add, modify, and delete credit card or debit
card accounts that the consumer 22 desires to use for electronic
payment of bills. For each payment account the consumer 22 is
required to input an account type, an account number, an account
name, expiration date, and the name appearing on the card.
[0064] FIG. 13 shows a consumer preferences web page that enables
the consumer 22 to personalize a bill portfolio. FIGS. 14 and 15
show web pages that enable consumers 22 to view and modify personal
information associated with a bill portfolio and a personalized
password for accessing a bill portfolio. The web page also enables
consumers 22 to initialize email notification of when bills are
presented to a bill portfolio for payment. Consumers 22 may also
create generic reminders or bill payment reminders, which may be
sent directly to an email address.
[0065] FIGS. 16 and 17 show web pages for creating and scheduling
generic reminders and payment reminders. The web pages enable
consumers 22 to specify when the reminder will begin to be sent,
how often the reminder will be sent, at what time the reminder will
be sent, and when to stop sending the reminder. For generic
reminders, the consumer 22 can be required to specify recipients of
the reminder and the content of the message.
[0066] At any time while logged into system embodiment 10 and
accessing a bill portfolio, consumers 22 may contact consumer
service by using a consumer service web page as shown in FIG. 18.
The consumer service web page also lists a variety of contact
information, as well as links to answers to frequently asked
questions.
[0067] The pages described above and shown in FIGS. 5-18 are merely
exemplary. In a first sense, each or any of them may contain
additional fields, or may contain fewer fields, to solicit or
require information of any type or sort, or to allow consumers 22
to interact with system embodiment 10 in any way for the purpose or
result of bill payment or reconciliation. In a second sense, other
pages may be employed for such results or purposes, or any of the
above-mentioned pages may be omitted. Again, these pages are merely
one example of an embodiment of a portal interface that can support
system embodiment 10 on any platform or device anywhere in actual,
electronic or virtual space.
[0068] FIGS. 19-33 show a series of web pages that billers 12
and/or 14 may use to self-enable EBPP. (As mentioned above, the
interface 15 can appear on any device in any location in actual,
electronic or virtual space, using any network or communications
system; use of the web and browser paradigm for the following
description is merely one example and should not be interpreted to
limit the invention or its scope in any way.) Any type of biller 12
and/or 14 may use system embodiment 10 to self-enable EBPP, but it
is particularly advantageous to billers 14 with a relatively small
number of consumers, as well as billers 14 with non-recurring
consumers. FIG. 19 shows a registration web page for signing up to
use system embodiment 10 for EBPP. Billers 12 and/or 14 can enter a
series of information text boxes on the web page, which include a
merchant identification number. System embodiment 10 can then
contact a credit verifier and access a credit report supplied by
the credit verifier to automatically determine whether the biller
12 and/or 14 is authenticated. If the biller 12 and/or 14 is
authenticated, system embodiment 10 automatically notifies the
biller 12 and/or 14 and access to system embodiment 10 is
granted.
[0069] As described above, once registered and authenticated
billers 12 and/or 14 may access system embodiment 10 by inputting a
user identification number, a personalized password, and an
encryption key. FIGS. 20-22 show web pages that enable billers 12
and/or 14 to define the layout of an electronic bill. FIG. 20 shows
a web page for choosing a predefined template provided by system
embodiment 10. FIG. 21 shows a web page that enables billers 12
and/or 14 to interactively design their own bill template. Once the
layout of the bill is defined, billers 12 and/or 14 can specify
what type of software program they will use to provide consumer
billing data to system embodiment 10. In the preferred embodiment
of the invention, system embodiment 10 supports billing data of any
type, such as, for example, data formatted to comply with over the
counter software accounting packages such as QuickBooks.RTM. and
Peachtree.RTM., or billing data formatted as a printer datastream
or a database export. FIG. 22 shows a web page for billers 12
and/or 14 to select the appropriate billing data format.
[0070] In situations where creating a bill template is not
manageable, as for one time transactions with a consumer 22, system
embodiment 10 can enable billers 12 and/or 14 to send a one time
only invoice. FIGS. 23-25 show web pages that enable this
functionality. Billers 12 and/or 14 can be required to include the
biller's name, the amount due, a description of the goods or
services, the recipient of the invoice, the number of the bill
portfolio where the invoice is to be sent, and the date payment is
due. After inputting the required invoice information, system
embodiment 10 preferably permits the biller 12 and/or 14 to preview
the invoice as it will appear in the consumer's bill portfolio and
send it.
[0071] System embodiment 10 can also enable billers 12 and/or 14 to
create various reports. Billers 12 and/or 14 may create reports
showing any of a number of transactional statistics, such as the
number of bills paid, the number of bills sent, the number of bills
disputed, the number of bills partially paid, the number of bills
published, the number of bills not published, and/or the number of
bills that have been reviewed for quality assurance. FIGS. 26 and
27 show web pages enabling billers 12 and/or 14 to create and
schedule reports.
[0072] System embodiment 10 can also enable billers 12 and/or 14 to
upload bills from a consumer's bill portfolio. FIG. 28 shows a web
page that enables billers 12 and/or 14 to do this. Billers 12
and/or 14 may search for a particular consumer 22 by name or may
sort for a number of consumers 22 in a predefined group. System
embodiment 10 performs the requested query and then displays each
of the bills in the consumer's bill portfolio that are associated
with the biller. Billers 12 and/or may also select and preview a
particular bill. FIG. 29 shows a web page for previewing the bill
of consumers 22. From the preview screen, billers 12 and/or 14 may
edit the bill, send the bill, or defer sending the bill until
later. FIG. 30 shows a web page that enables a biller 12 and/or 14
to edit a consumer's bill.
[0073] As shown in FIG. 31, system embodiment 10 can also enable
billers 12 and/or 14 to add, modify, or delete consumer accounts.
Billers 12 and/or 14 may add a consumer account or choose the
account organizer by selecting the appropriate link on the web
page. FIG. 32 shows the linked web page where a biller 12 and/or 14
may input a new client's name, account number, email address, and
attribute. System embodiment 10 may also enable billers 12 and/or
14 to identify conventional mailing addresses for consumers 22 so
that consumers 22 may enable standard paper billing. The attribute
field can be used in combination with the account organizer to
define groups of consumer accounts to simplify bill generation and
delivery. Billers 12 and/or 14 may use consumer groups to define
and generate bills without the need for repetition. For example,
when creating a list of consumer accounts, a biller 12 and/or 14
may assign a specific zip code attribute to a group of accounts,
which would enable the biller 12 and/or 14 to generate and deliver
all bills of the specific zip code at the same time.
[0074] As shown in FIG. 33, at any time while logged into system
embodiment 10 billers 12 and/or 14 may send emails to a consumer's
bill portfolio. Billers 12 and/or 14 can use this functionality for
payment reminders, marketing notices and offers, or any other
advantageous use.
[0075] The pages described above and shown in FIGS. 19-33 are
merely exemplary. In a first sense, each or any of them may contain
additional fields, or may contain fewer fields, to solicit or
require information of any type or sort, or to allow billers 12
and/or 14 to interact with system embodiment 10 in any way for the
purpose or result of bill presentment or to effectuate payment or
reconciliation. In a second sense, other pages may be employed for
such results or purposes, or any of the above-mentioned pages may
be omitted. Again, these pages are merely one example of an
embodiment of a portal interface that can support system embodiment
10 on any platform or device anywhere in actual, electronic or
virtual space.
[0076] The foregoing is provided for purposes of disclosure of a
preferred embodiment of the present invention. Additions to,
deletions or omissions from, or changes to interfaces, systems, or
embodiments disclosed above may be accomplished; so long as they
help carry out the results or purposes of providing systems that
support interfaces to effectuate EBPP, they remain within the scope
or spirit of the invention.
* * * * *