U.S. patent application number 12/109309 was filed with the patent office on 2008-11-20 for centralized payment method and system for online and offline transactions.
This patent application is currently assigned to CashEdge, Inc.. Invention is credited to Sanjeev Dheer, Behram Panthaki, Demetris Papademetriou, Neil Platt, Aaron Rudenstine, Jeremy Sokolic, Amir Sunderji.
Application Number | 20080288400 12/109309 |
Document ID | / |
Family ID | 39926094 |
Filed Date | 2008-11-20 |
United States Patent
Application |
20080288400 |
Kind Code |
A1 |
Panthaki; Behram ; et
al. |
November 20, 2008 |
Centralized Payment Method and System for Online and Offline
Transactions
Abstract
Embodiments described herein include an electronic transaction
service network (also referred to herein as a centralized
electronic transaction (CET) service)=According to an embodiment, a
financial management system hosts multiple CET web sites on behalf
of multiple merchants. All transactions through any CET web site
are executed and managed by the financial management system.
Merchants may customize their web sites to include a branded look
and feel. The merchant web sites are part of a CET service for
which customer can register. Registered customers can then view and
pay invoices from any merchants having CET web sites, whether
purchases were made online or offline. Customers specify
preferences for the CET service including choosing existing
customer accounts from which the financial management system is to
pay invoices on behalf of the customer. This eliminates the need
for the customer to open and fund a separate payment account as in
traditional methods.
Inventors: |
Panthaki; Behram; (Jersey
City, NJ) ; Rudenstine; Aaron; (New York, NY)
; Sokolic; Jeremy; (New York, NY) ; Sunderji;
Amir; (San Jose, CA) ; Dheer; Sanjeev;
(Scarsdale, NY) ; Platt; Neil; (New York, NY)
; Papademetriou; Demetris; (New York, NY) |
Correspondence
Address: |
COURTNEY STANIFORD & GREGORY LLP
P.O. BOX 9686
SAN JOSE
CA
95157
US
|
Assignee: |
CashEdge, Inc.
New York
NY
|
Family ID: |
39926094 |
Appl. No.: |
12/109309 |
Filed: |
April 24, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60926619 |
Apr 27, 2007 |
|
|
|
60957634 |
Aug 23, 2007 |
|
|
|
Current U.S.
Class: |
705/40 |
Current CPC
Class: |
G06Q 40/02 20130101;
G06Q 20/1085 20130101; G06Q 40/12 20131203; G06Q 20/102 20130101;
G06Q 20/10 20130101 |
Class at
Publication: |
705/40 |
International
Class: |
G06Q 20/00 20060101
G06Q020/00; G06Q 40/00 20060101 G06Q040/00 |
Claims
1. A central electronic transaction method, comprising: a financial
management system hosting a web site on behalf of a payee, wherein
the web site displays information to customers of the payee, the
information comprising invoices and payment options; the financial
management system receiving input from a customer of the payee, the
input comprising: customer information comprising an identification
of at least one payment account, wherein the at least one payment
account comprises an existing customer bank account; a request to
view customer invoices on the web site; and and a request to pay a
customer invoice; and the financial management system executing a
transaction in response to the received input, comprising
transferring funds from the at least one payment account to a
predetermined payee account.
2. The method of claim 1, wherein the financial management system
hosts multiple web sites on behalf of multiple payees.
3. The method of claim 1, further comprising: the payee customizing
the web site, including placing branding indicia on the web site;
and the payee designating one or more accounts to receive funds
transferred by the financial management system on behalf of
customers.
4. The method of claim 1, wherein the customer information
comprises verification information for the at least one payment
account, including personal customer identification information and
password information.
5. The method of claim 1, further comprising the customer accessing
the web site via a link in an email from the payee.
6. The method of claim 1, further comprising the customer accessing
the web site via a link on a web site of the financial management
system.
7. The method of claim 1, further comprising receiving a customer
registration in a central electronic transaction (CET) service that
enables the customer to pay multiple payees via the CET service,
wherein paying multiple payees comprises viewing payee invoices on
specific payee web cites and viewing multiple invoices from
different payees on a CET web site.
8. The method of claim 1, wherein executing the transaction
comprises the financial management system: executing a first debit
transaction to withdraw funds from the at least one payment account
at a first financial institution; executing a first credit
transaction to deposit the funds in an intermediate account at a
second financial institution; executing a second debit transaction
to withdraw funds from the intermediate account; and executing a
second credit transaction to deposit the funds in the predetermined
payee account at a third financial institution.
9. The method of claim 8, wherein the first debit transaction and
the first credit transaction are executed using a first
network.
10. The method of claim 8, wherein the second debit transaction and
the second credit transaction are executed using a second
network.
11. The method of claim 9, wherein the first network is chosen from
a group comprising: an automatic clearing house (ACH) network; a
debit network; and an automated teller machine (ATM) network.
12. The method of claim 10, wherein the second network is chosen
from a group comprising: an automatic clearing house (ACH) network;
a debit network; and an automated teller machine (ATM) network.
13. A financial management system comprising: a plurality of
servers configurable to communicate with a plurality of financial
institutions via at least one network; and a plurality of storage
devices, comprising, databases that store customer information,
merchant information, and financial institution information; and
memory devices that store instructions that when executed, cause a
central electronic transaction method to be executed, the method
comprising, a financial management system hosting a web site on
behalf of a merchant, wherein the web site displays information to
customers of the merchant, the information comprising invoices and
payment options; the financial management system receiving input
from a customer of the merchant, the input comprising, customer
information comprising an identification of at least one payment
account, wherein the at least one payment account comprises an
existing customer bank account; a request to view customer invoices
on the web site; and and a request to pay a customer invoice; and
the financial management system executing a transaction in response
to the received input, comprising transferring funds from the at
least one payment account to a predetermined merchant account.
14. The financial management system of claim 13, wherein the
financial management system hosts multiple web sites on behalf of
multiple merchants.
15. The financial management system of claim 13, wherein the
central electronic transaction method further comprises: the
merchant customizing the web site, including placing branding
indicia on the web site; and the merchant designating one or more
accounts to receive funds transferred by the financial management
system on behalf of customers.
16. The financial management system of claim 13, wherein the
customer information comprises verification information for the at
least one payment account, including personal customer
identification information and password information.
17. The financial management system of claim 13, wherein the
central electronic transaction method further comprises the
customer accesses the web site via a link in an email from the
merchant.
18. The financial management system of claim 13, wherein the
central electronic transaction method further comprises the
customer accesses the web site via a link on a web site of the
financial management system.
19. The financial management system of claim 13, wherein the
central electronic transaction method further comprises receiving a
customer registration in a central electronic transaction (CET)
service that enables the customer to pay multiple merchants via the
CET service, wherein paying multiple merchants comprises viewing
merchant invoices on specific merchant web cites and viewing
multiple invoices from different merchants on a CET web site.
20. The financial management system of claim 13, wherein executing
the transaction comprises the financial management system:
executing a first debit transaction to withdraw funds from the at
least one payment account at a first financial institution;
executing a first credit transaction to deposit the funds in an
intermediate account at a second financial institution; executing a
second debit transaction to withdraw funds from the intermediate
account; and executing a second credit transaction to deposit the
funds in the predetermined merchant account at a third financial
institution.
21. The financial management system of claim 20, wherein the first
debit transaction and the first credit transaction are executed
using a first network.
22. The financial management system of claim 21 wherein the second
debit transaction and the second credit transaction are executed
using a second network.
23. The financial management system of claim 21, wherein the first
network is chosen from a group comprising: an automatic clearing
house (ACH) network; a debit network; and an automated teller
machine (ATM) network.
24. The financial management system of claim 22, wherein the second
network is chosen from a group comprising: an automatic clearing
house (ACH) network; a debit network; and an automated teller
machine (ATM) network.
25. A method for central electronic transaction management, the
method comprising: creating and hosting a merchant web site for
each of multiple merchants; receiving merchant customization
information for a merchant web site comprising a look and feel for
the merchant web site; receiving merchant preferences comprising at
least one designated merchant account in which funds are to be
deposited by the financial management system on behalf of customers
of the merchant in payment of merchant invoices; receiving
registration input from a customer comprising customer personal
information and customer payment account information; receiving
input from the customer comprising, a request from the customer to
view merchant information comprising merchant invoices, wherein the
request is entered by the customer from at least one of the
merchant web site and a central financial management system web
site; and a request to pay a merchant invoice; and executing a
transaction in response to the request to pay comprising
transferring funds from the customer payment account to one of the
at least one designated merchant accounts.
Description
RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Patent Application Ser. No. 60/926,619, filed Apr. 27, 2007. This
application also claims the benefit of U.S. Provisional Patent
Application Ser. No. 60/957,634, filed Aug. 23, 2007.
TECHNICAL FIELD
[0002] The invention is in the field of electronic payment methods
and systems, including electronic financial networks.
BACKGROUND
[0003] Currently there are systems and methods for facilitating
online transactions. FIGS. 1 and 2 illustrate one current system
100 used to facilitate making payments for online purchases. There
are two categories of payment services available in such
traditional systems. One category includes person-to-person and
person-to-merchant payment services. The other category includes
direct-to-merchant payment services. In such traditional methods, a
user must open an account 104 with the service, referred to in
FIGS. 1 and 2 as "X" service, and the user must fund the account.
The account 104 must be funded using an external financial source
102, such as a checking account, a credit card, etc. In addition,
funds must be kept on deposit in the account 104 for transfer or
disbursement. The funds are transferred to the account 104 by the
user with no sharing of information, such as information regarding
other user accounts, or user creditors, etc. Money in the account
104 can be used for any of account service 112 offered by "X"
service. Funds from the account 104 are distributed to payees 106
when the user performs a transaction that allows use of the "X"
service, including payments to individuals 106A and to online
stores 106B. Payment services 108 for person-to-person payments,
and payment services 110 for direct-to-merchant payments are shown.
Examples of such traditional services include the PayPal.TM.
service.
[0004] However, current systems and methods for facilitating online
transactions have significant limitations. FIG. 2 illustrates
various limitations of the "X" service. For example, settlement
time 113 for payment from the external financial source 102 to the
user account 104 can be 3 to 4 days using a DDA account. When funds
are transferred from the account 104 to multiple destination
accounts 105, an additional 3 to 4 days settlement time is incurred
in transferring the funds from the destination accounts 105 to a
main bank account 117. This creates a worst-case settlement time of
up to 8 days, not including any delays caused by verification
processes at any transfer point.
[0005] Another disadvantage of such current systems is that the
user must fund and manage the account 104 with "X" service as a
separate account and relationship distinct from any other payor or
payee relationships.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] FIGS. 1 and 2 illustrate a prior art system used to
facilitate making payments for online purchases.
[0007] FIG. 3 is a block diagram illustrating an embodiment of a
centralized electronic transaction (CET) service, which provides
improved settlement time over existing payment methods, according
to an embodiment.
[0008] FIG. 4 is a block diagram further illustrating
direct-to-merchant payment CET services and person-to-person
payment CET services, according to an embodiment.
[0009] FIG. 5 is a block diagram illustrating biller-direct
invoicing for offline merchants, according to an embodiment.
[0010] FIG. 6 is a block diagram illustrating an embodiment in
which the CET service and network is used by the "unbanked" to
conduct transactions, according to an embodiment.
[0011] FIG. 7 is a block diagram of a system including a financial
management system providing a CET system, according to an
embodiment.
[0012] FIG. 8 is a block diagram illustration the operation of a
funds transfer module, according to an embodiment.
[0013] FIG. 9 is a flow chart illustrating a CET service process,
according to an embodiment.
[0014] FIG. 10 is a flow chart illustrating a CET service process
of registering a user, according to an embodiment.
DETAILED DESCRIPTION
[0015] Embodiments described herein include an electronic
transaction service network (also referred to herein as a
centralized electronic transaction (CET) service). According to an
embodiment, a financial management system hosts multiple CET web
sites on behalf of multiple merchants. All transactions through any
CET web site are executed and managed by the financial management
system. Merchants may customize their web sites to include a
branded look and feel. The merchant web sites are part of a CET
service for which customer can register. Registered customers can
then view and pay invoices from any merchants having CET web sites,
whether purchases were made online or offline. Customers specify
preferences for the CET service including choosing existing
customer accounts from which the financial management system is to
pay invoices on behalf of the customer. This eliminates the need
for the customer to open and fund a separate payment account as in
traditional methods.
[0016] The financial management system handles all transactions and
data storage on behalf of merchants. Embodiments leverage existing
financial institution (FI) payor and merchant networks. This allows
merchants who are not large enough to provide online payment
through conventional systems to have convenient online invoicing
and payment services to offer their customers. This also allows
customers of the financial management system to easily pay many
different merchants online using a customer's existing account
(such as a checking account, savings account, or credit card).
Embodiments do not require a user to create, fund and maintain a
separate account for the purpose of payment services. In an
embodiment, a user or customer registers with the transaction CET
service. The user is not required to create, fund and maintain a
separate account in order to user the CET service. The term "user"
and "customer" will be used interchangeably herein.
[0017] According to various embodiments, individuals who are
"unbanked" (e.g., individuals who have no access to checking
accounts, credit cards or other convenient non-cash payment
mechanisms) may register with the CET service, and transact with
online and offline merchants and make online payments.
[0018] One possible implementation of the CET service is by a small
business that is part of the CET service. The business can create
an invoice and send the invoice out to the customer, by mail or
electronically. The customer, who is registered with the CET
service, can access the invoice electronically, and automatically
pay that invoice, for example through the customer's bank
account.
[0019] Accounts payable can also be managed using the CET service.
For example, consider a business that maintains a running account
with a particular vendor. The business does not receive an invoice
from the vendor, but can login to the CET service, view the account
balance, and electronically pay the balance from another financial
account of the business. The financial information does not need to
be shared between the two entities.
[0020] Another functionality according to an embodiment is payroll
management. For example, the business can login to the CET service
and view payroll information. For employees who are also registered
with the CET service, the business can pay the employee
electronically from the business's financial account at a financial
institution to the employee's chosen account at a (probably, but
not necessarily, different) financial institution.
[0021] One embodiment of the CET service includes a branded
biller-direct site. In contrast to previous methods, in which a
customer or user logs into an "X" service web site, a biller-direct
web site exists for the merchant or business. The business has the
ability to customize the look and feel of this web site, which may
be branded by the merchant or co-branded with the CET service. In
an embodiment, there is a direct link to the (branded or
co-branded) CET service web site from the business web site. An
invoice, an email or some other communication is sent from the
business to the customer with an indication that the required
payment can be made directly on the business's CET service web site
(the link to the web site is provided). The link takes the customer
to the branded web site. In an embodiment, the web site includes
the icon of the business and a CET service icon.
[0022] Co-branding embodiments include cross-sell opportunities.
For example the consumer logging on to view a merchant invoice can
be provided with information regarding promotions and discounts of
the merchant. In addition, a business logging on to view its
account information can be provided with information regarding
network services.
[0023] In various embodiments, the CET service can be accessed in a
variety of ways. For example, the user can login to the CET service
web site and view the account information available for the user.
The account information available for the user includes information
related to all of the businesses with which the user has accounts
that are also registered with the CET service. When the user clicks
on an invoice of a particular business, a detail window with the
invoice information also displays the branding of the invoicing
business, as well as any cross-sell messaging provided by the
invoicing business. Alternatively, the user can login to a business
web site and view the user's account information for that
particular business (e.g., via a link as previously described).
[0024] Businesses participating in the CET service may access
various information when logged into the CET service web site. For
example, all accounts receivable information for those customers
participating in the CET service is visible. In addition, accounts
payable information is also visible for those vendors participating
in the CET service. Thus, a consolidated view of accounts, both
receivable and payable, is available to the business participant.
In addition, businesses can also leverage the service to make point
of sales payments associated with an online shopping cart.
[0025] Non-business users can perform various functions when logged
into the CET service. For example, the user can view the invoices
placed there by a business, the user can pay invoices directly
using the CET service, and the user can view a consolidated
statement that includes payment history. Users can also leverage
the service to make point of sale payments associated with a
merchant shopping cart.
[0026] According to an embodiment, even if invoices are received
offline, a user may still use the CET service web site to pay
directly because the merchant or business knows the user and is
aware of the relationship and account status. The web site can be
used to remit the payment directly to the merchant account.
[0027] An existing user bank account is used to fund transactions
according to the CET service. This is in contrast to having to
create, fund and maintain a separate "X" service account as in
existing payment methods and systems.
[0028] According to embodiments, the CET service offers rewards and
other loyalty programsto users for participation in the CET service
(e.g., for registering and completing transactions using the CET
service). The rewards can be redeemed for goods, services,
discounts, etc. This is in contrast to existing payment methods and
systems, which do not make rewards available.
[0029] FIG. 3 is a block diagram illustrating an embodiment of a
CET service 300, including improved settlement time over existing
payment methods, according to an embodiment. There is a single
relationship model with the CET service; a user does not have to
maintain a relationship and financial account with a separate
payment service entity. Instead, the user selects among multiple
funding options 302 including existing user bank accounts and
credit cards. This provides several advantages. Because the primary
account 302 designated by the user acts as the transactional
account for the ET service, expanded capabilities of the primary
account 302 are seamlessly available. For example, multiple
transaction types are executed dependent only on the various
channels used by the bank account/financial institution. This
includes multiple payment paradigms, such as 3-day settlement,
next-day settlement, and instant settlement. The CET service
executes transaction using the primary account 302 (financial
instruments, including DDAs and credit cards (CCs)) as shown at
304, but the user financial information is never shared with
anyone, including the merchant or person being paid. The ET service
enables the primary account 302 to be used for person-to-person
payments, direct-to-merchant payments (as shown at 306), and any
other type of transaction the user has available through the
primary account 302. The funds from the primary account 302 are
deposited directly in the bank account 308 of the person or
merchant being paid.
[0030] Aspects of the CET service 300 and advantages thereof as
described herein are particularly useful for a large financial
institution desiring to incorporate the CET service in it
offerings. However embodiments are not so limited. Embodiments of
the CET service may be tailored as a stand-alone application or as
an application tailored to be presented as a service of a
particular large or small entity.
[0031] Table 1 below lists some of the market opportunities in the
area of both online payments and other areas, such as serving the
unbanked.
TABLE-US-00001 TABLE 1 OPPORTUNITY FEATURES ONLINE Serving Online
Businesses Transact using primary PAYMENTS Provide easy-to-use and
DDA/Card holistic electronic payment Online Direct-to-Merchant and
merchant acquiring payments services to retail consumers Online
Person-to-Person and hobbyists with a special payments focus on
online merchants Online invoicing and collection (ACH/Card)
Consolidated Reporting Serving Offline Businesses Online invoicing
and Leveraging a large base of collection (ACH/Card) customers
built in an adjacent Biller Direct for small business (Retail,
Card, merchants Merchant Services, etc.) to Consolidated Reporting
build a network of currently Remote Deposit Capture underserved
offline merchants Call Center Payments and non profit organizations
OTHER Add on Capability-Serving the Direct-to-Merchant and Unbanked
Person-to-Person payments Leveraging an emerging brand via
ATM/Banking Center and ATM/Branch Networks to target the
Unbanked
[0032] Table 2 below describes lists some of the services offered
to consumers (also referred to as users or customers herein) and to
merchants according to various embodiments.
TABLE-US-00002 TABLE 2 CONSUMERS MERCHANTS Transact using primary
DDA/CARD Receive payments from Card and Online Direct-to-Merchant
payments DDA without merchant acquiring Online Person-to-Person
payment relationship Consolidated Reporting across Online invoicing
and collection multiple financial relationships (ACH/Card)
(payments and requests for payment) For offline merchants,
establish Privacy and security-Banking biller direct website
information is not shared with Manage accounts payable merchants
Consolidated Reporting across multiple financial relationships
(payables and receivables) Other banking service-Remote Deposit
Capture sweeps, etc.
[0033] FIG. 4 is a block diagram further illustrating
direct-to-merchant payment CET services and person-to-person
payment CET services, according to an embodiment. In a
direct-to-merchant scenario, a consumer (also referred to as a
customer or user) 402 accesses a merchant web site 404. As further
described below, the merchant web site 404 is hosted by a financial
management system that provides the CET service to many users and
merchants, thus making it possible for small merchants or
individual payees or billers to offer online payment. The CET
service 300 actually receives user input from the web site 404 and
executes transaction accordingly. For example, the CET service 300
performs online payment 406 as specified by the user 402 including
DDA account payments at any financial institution, credit card
payments, and short term loans.
[0034] In a person-to-person scenario, a user (also referred to as
a customer or user) 408 accesses a DDA, for example through the web
site of the financial institution 409 at which the DDA resides. The
CET service 300 actually receives user input from the financial
institution 409 and executes transactions accordingly. For example,
the CET service 300 performs online payment as specified by the
user 408 to one or more DDAs at another (payee) financial
institution 410.
[0035] FIG. 5 is a block diagram illustrating biller-direct
invoicing for offline merchants, according to an embodiment. A
small business 502 communicates via a network (such as the
Internet, a wide area network (WAN), etc.) with the CET service
300. The CET service 300 generates invoices or statements according
to previously specified preferences of the small business 502. A
customer 508 receives the invoice via mail, in this case (the
invoice could also be sent via email or another method). The
customer 508 logs into either a central CET service web site
presented by the financial management system that hosts the CET
service, or a branded biller-direct web site. On either web site
the customer 508 can set up payments, view paid and unpaid
invoices, view payment history, and view outstanding balances. The
customer 508 can schedule electronic payment of any invoices. The
CET service executes transactions necessary to pay the invoice
including depositing funds from an existing customer account
directly into an account designated by the small business 502.
[0036] The online capability to pay invoices received offline
provides convenience to the customer, reduces payables processing
cost for the customer, and makes payment time shorter. For small
businesses, this capability reduces the time-to-pay and days
outstanding. The capability also allows small businesses to
automatically reconcile receivables, and reduce receivables
processing costs. For financial institutions, this capability can
be offered as a value-added service to small businesses. Financial
institutions can realize subscription and transaction fee revenue
for providing the service.
[0037] FIG. 6 is a block diagram illustrating an embodiment in
which the CET service and network is used by the "unbanked" to
conduct transactions, according to an embodiment. The unbanked
include individuals that have no way of making electronic payments.
The unbanked must currently go to the U.S Post Office or Western
Union and obtain a money order or moneygram in order to make
payments. This is an opportunity for financial institutions to use
their ATM/branch networks to allow these unbanked consumers to
transact offline for goods and services provided online. In an
example, a consumer 602 shops online at a merchant 604 and chooses
to pay using a payment kiosk 606 which is via the CET service 300
or the bank itself (such as bank 608). The consumer 602 receives a
unique confirmation number and instructions to pay. The merchant
604 receives the order and has the unique confirmation number. The
consumer 602 goes to a payment kiosk at a banking center. The
consumer 602 uses the confirmation number. Once the confirmation
number is received it links the payment to the order. The consumer
602 can then select to deposit the funds directly. Some ATMs have
the capability to scan cash in. The consumer 602 can also choose to
walk up to a teller at the bank 608 and make the payment. The bank
608 receives the payment on behalf of the merchant 604. This
service enables the unbanked population to make quicker payments.
This also facilitates much faster delivery of the product to the
consumer 602. There can be a transaction fee associated with the
service.
[0038] The CET service 300 can thus be very valuable to the
unbanked consumer who is enabled to make online purchases using
cash or prepaid cards. Merchants also benefit because they can
receive electronic payments from either banked or unbanked
customers, expanding the customer base of the merchant. Financial
institutions benefit by collecting transaction fee revenue. In
addition, financial institutions have the ability to cross-sell
other products or services to unbanked customers.
[0039] FIG. 7 is a block diagram of a system 700 including a
financial management system 702, according to an embodiment. The
system 700 includes various entities in communication with each
other via a network 710, which is typically the Internet, but
embodiments are not so limited. The financial management system 702
includes databases 706 that store financial institution
information, user information, merchant information (including
merchant preferences for individual biller-direct web sites,
invoice information for merchants, etc.). The CET service 300 is
included in the financial management system 702 and interoperates
with a funds transfer module 704. The funds transfer module 704
communicates with multiple financial institutions to transfer funds
as further described below. Servers 708 host multiple web sites and
applications as described herein, including biller-direct web
sites, at least one central CET service web site, invoicing
applications, email applications, and setup applications, to name a
few.
[0040] Merchants 712 communicate with the financial management
system 702 as further described below for providing the CET service
300 to their customers, either through biller-direct web sites or
through a central CET services web site. CET customer personal
computers (PCs) 716 are an example of an interface between
customers and the CET service 300. Customers may interface with the
CET service 300 using other means, such as handheld devices,
kiosks, etc. Funds sources 714 include financial institutions of
all types that can transfer funds via the network 710 using
established financial networks such as ATM, ACH, and debit
networks.
[0041] FIG. 8 is a block diagram illustrating the operation of the
funds transfer module 704, according to an embodiment. Financial
institution #2 is for the benefit of the funds transfer module 704,
and in an embodiment is managed by a third party processor. In this
instance "third party" infers that financial institution #2 is
separate and independent from financial institution #1 and
financial institution #3. In order to transfer funds from a source
account 802 (for example a customer account) to a destination
account 806 (such as a merchant account), the funds transfer module
704 first executes a debit transaction with the source account 802.
Then the funds from the first debit transaction are deposited in
the central (or intermediate) account 804 in a first credit
transaction.
[0042] The funds are then withdrawn from the central account 804 in
a second debit transaction, and deposited in destination account
806 in a second credit transaction. Financial institutions #1 and
#2 have no knowledge of central account 804. This is in contrast to
conventional electronic funds transfers in which the financial
institution providing the funds and the financial institution
receiving the funds must deal directly with each other and have
particular information or data about each other in order to
complete the transaction. As shown, the debit and credit
transactions can be accomplished using any one of various existing
networks, including but not limited to an ACH network, a debit
network, and an ATM network.
[0043] FIG. 9 is a flow chart illustrating a CET service process
900, according to an embodiment. The financial management system
(FMS) creates a hosted merchant biller-direct (MBD) web site at
902. At 904, the merchant customizes the MBD web site, including
look and feel with branding indicia, specifying preferences such as
merchant account(s), etc. A registered CET customer receives a
merchant invoice with MBD web site information (usually a link to
the MBD web site) as shown at 906. The registered CET customer goes
to the MBD web site to view the merchant invoice at 908. At 910,
the customer pays directly on MBD web site from a customer account
(chosen previously per customer preferences). Payment is
transferred directly from the customer account to the merchant
account at 912.
[0044] FIG. 10 is a flow chart illustrating a CET service process
1000 of registering a user, according to an embodiment. A customer
logs into the CET service at 1002. The customer designates one or
more existing accounts from which to fund transactions at 1004. At
1006, the customer states various verification information, such as
user names, passwords, personal identification information, etc.
The customer states preferences at 1008, such as how the customer
would like to receive invoices. All of the customer input is stored
on the financial management system and not shared with other
entities, including financial institutions, as shown at 1010. The
registered customer can then access and use the CET service by
clicking on a CET icon to pay any merchant that also uses the CET
service at 1014. In addition, or alternatively, the registered user
can then click on a branded or co-branded icon from a merchant site
to pay the specific merchant at 1012.
[0045] Aspects of the systems and methods described herein may be
implemented as functionality programmed into any of a variety of
circuitry, including programmable logic devices (PLDs), such as
field programmable gate arrays (FPGAs), programmable array logic
(PAL) devices, electrically programmable logic and memory devices
and standard cell-based devices, as well as application specific
integrated circuits (ASICs). Some other possibilities for
implementing aspects of the system include: microcontrollers with
memory (such as electronically erasable programmable read only
memory (EEPROM)), embedded microprocessors, firmware, software,
etc. Furthermore, aspects of the system may be embodied in
microprocessors having software-based circuit emulation, discrete
logic (sequential and combinatorial), custom devices, fuzzy
(neural) logic, quantum devices, and hybrids of any of the above
device types. Of course the underlying device technologies may be
provided in a variety of component types, e.g., metal-oxide
semiconductor field-effect transistor (MOSFET) technologies like
complementary metal-oxide semiconductor (CMOS), bipolar
technologies like emitter-coupled logic (ECL), polymer technologies
(e.g., silicon-conjugated polymer and metal-conjugated
polymer-metal structures), mixed analog and digital, etc.
[0046] It should be noted that the various functions or processes
disclosed herein may be described as data and/or instructions
embodied in various computer-readable media, in terms of their
behavioral, register transfer, logic component, transistor, layout
geometries, and/or other characteristics. Computer-readable media
in which such formatted data and/or instructions may be embodied
include, but are not limited to, non-volatile storage media in
various forms (e.g., optical, magnetic or semiconductor storage
media) and carrier waves that may be used to transfer such
formatted data and/or instructions through wireless, optical, or
wired signaling media or any combination thereof. Examples of
transfers of such formatted data and/or instructions by carrier
waves include, but are not limited to, transfers (uploads,
downloads, e-mail, etc.) over the Internet and/or other computer
networks via one or more data transfer protocols (e.g., HTTP, FTP,
SMTP, etc.). When received within a computer system via one or more
computer-readable media, such data and/or instruction-based
expressions of components and/or processes under the system
described may be processed by a processing entity (e.g., one or
more processors) within the computer system in conjunction with
execution of one or more other computer programs.
[0047] Unless the context clearly requires otherwise, throughout
the description and the claims, the words "comprise," "comprising,"
and the like are to be construed in an inclusive sense as opposed
to an exclusive or exhaustive sense; that is to say, in a sense of
"including, but not limited to." Words using the singular or plural
number also include the plural or singular number respectively.
Additionally, the words "herein," "hereunder," "above," "below,"
and words of similar import refer to this application as a whole
and not to any particular portions of this application. When the
word "or" is used in reference to a list of two or more items, that
word covers all of the following interpretations of the word: any
of the items in the list, all of the items in the list and any
combination of the items in the list.
[0048] The above description of illustrated embodiments of the
systems and methods is not intended to be exhaustive or to limit
the systems and methods to the precise forms disclosed. While
specific embodiments of, and examples for, the systems components
and methods are described herein for illustrative purposes, various
equivalent modifications are possible within the scope of the
systems, components and methods, as those skilled in the relevant
art will recognize. The teachings of the systems and methods
provided herein can be applied to other processing systems and
methods, not only for the systems and methods described above.
[0049] The elements and acts of the various embodiments described
above can be combined to provide further embodiments. These and
other changes can be made to the systems and methods in light of
the above detailed description.
[0050] In general, in the following claims, the terms used should
not be construed to limit the systems and methods to the specific
embodiments disclosed in the specification and the claims, but
should be construed to include all processing systems that operate
under the claims. Accordingly, the systems and methods are not
limited by the disclosure, but instead the scope of the systems and
methods is to be determined entirely by the claims.
[0051] While certain aspects of the systems and methods are
presented below in certain claim forms, the inventors contemplate
the various aspects of the systems and methods in any number of
claim forms. For example, while only one aspect of the systems and
methods may be recited as embodied in machine-readable medium,
other aspects may likewise be embodied in machine-readable medium.
Accordingly, the inventors reserve the right to add additional
claims after filing the application to pursue such additional claim
forms for other aspects of the systems and methods.
* * * * *