Note: Descriptions are shown in the official language in which they were submitted.
CA 02530250 2005-12-14
ELECTRONIC FUNDS TRANSFER
BACKGROUND
[0001] This invention relates to electronic funds transfers.
[0002] Merchandise is commonly offered for sale over the Internet and credit
cards are frequently used as a method of payment. When making an on-line
purchase with a credit card, the consumer provides a merchant with a credit
card
number, and the amount of the purchase is charged to the associated credit
card
account. However, credit cards are susceptible to fraud, especially when used
over
the Internet, because often no verification is performed to check that the
credit card
owner has in fact authorized the purchase. Further, many consumers are
reluctant
to use a credit card over the Internet.
[0003] Non-credit card methods of payment for on-line purchases are also
known. Non-credit card methods of payment may employ an intermediate account
such that a consumer can transfer funds from his personal financial
institution
account into the intermediate account and then use the funds in the
intermediate
account in making an on-line purchase. Funds may be transferred into the
intermediate account by, for example, using an electronic cheque. When paying
for
an on-line purchase from an intermediate account the consumer provides the
merchant with information identifying his intermediate account such as an
UserlD
and a password.
[0004] By using an intermediate account, the consumer ensures that a merchant
does not have access to his personal financial institution account, credit
card
number or other personal financial information. Further, the consumer may
choose
to keep only a small balance in his intermediate account to minimize loss in
the
event of theft or fraud. A merchant is motivated to accept payment through an
intermediate account because the merchant may gain access to customers who do
not have credit cards. Also, an intermediate account provider may guarantee
the
payment and thereby assume the risk of fraud.
-1-
CA 02530250 2005-12-14
[0005] It may take two to five business days before a consumer who has
transferred funds into his intermediate account may access those funds. This
is a
function of the banking system. More specifically, the intermediate account
provider
will place a hold on deposited funds while the funds are cleared through to
the
intermediate account. A consumer who does not have enough funds in his
intermediate account to pay for his on-line purchase will therefore have to
wait for
the funds to clear before he can complete his purchase.
[0006] There is, therefore, a need for an improved approach to electronic
funds
transfer.
SUMMARY OF THE INVENTION
[0007] A consumer may make an electronic bill payment from his financial
institution account to an intermediary for a certain amount. Data related to
the bill
payment transaction may be sent to a facilitation server associated with the
intermediary. This data may be filtered to determine whether or not the data
represents a valid bill payment transaction. If it does, an intermediate
account
provided by the intermediary, or an account of a third party (such as an on-
line
merchant) may be immediately credited with the amount of the bill payment so
that
the consumer can immediately use those funds in an on-line purchase.
[0008] In accordance with this invention, there is provided a method, at a
client
computer, of facilitating an electronic funds transfer comprising the
following. A bill
payment transaction is requested, over a public Internet, through a web page
interfacing with a financial institution server associated with a first
monetary
account, to transfer funds from the first monetary account to a second
monetary
account. Information relating to the bill payment transaction is received from
the
financial institution server, over the public Internet. Information relating
to the bill
payment transaction is sent to a facilitation server associated with the
second
account, over the public Internet.
-2-
CA 02530250 2005-12-14
[0009] There is also provided a method, at a client computer, of facilitating
an
electronic funds transfer, comprising: establishing an user interface;
receiving an
indication of an on-line banking site of a financial institution from a
facilitation
server; based on the indication, pointing a web browser for a window on a
display
to the on-line banking site; on receiving a prompt from the user interface,
capturing
data displayed in the window and transmitting the data to the facilitation
server.
[0010] In another aspect of the invention, there is provided a method, at a
server, of facilitating an electronic funds transfer, comprising the
following. On
request from a client computer, an indication of an on-line banking site of a
financial
institution is sent to the client. Data is received from the client and
filtered. Based
on the filtering, an account is selectively credited with a deposit amount or
confirmation of an amount and a payee is sent to a pre-selected destination.
[0011] In a further aspect of the invention, there is provided a method, at a
server, of facilitating an electronic funds transfer, comprising: receiving
confirmation
data originating from a financial institution relating to a bill payment made
from a
monetary account at said financial institution, said confirmation data
identifying a
payer, a payee and an amount; filtering said data against filter criteria; and
based
on said filtering, selectively crediting an account with said amount or
sending
confirmation of said amount and said payer to a pre-selected destination.
[0012] Other aspects of the invention will be apparent from the following
description in conjunction with the drawings.
DESCRIPTION OF THE DRAWINGS
[0013] In the figures which illustrate an example embodiment of the invention,
[0014] FIG. I is a schematic view of a system made in accordance with this
invention,
[0015] FIG. 2 is a schematic detail view of the facilitation server of FIG. 1,
-3-
CA 02530250 2005-12-14
[0016] FIG. 3 is a schematic detail view of the client computer of FIG. 1,
[0017] FIG. 4 is a flow diagram illustrating operation of the client computer
of
FIG. 1,
[0018] FIG. 5 is a flow diagram illustrating operation of the facilitation
server of
FIG. 1,
[0019] FIGS. 6a and 6b are diagrams illustrating an user interface of the
client
computer of FIG. 1,
[0020] FIG. 7 illustrates pseudocode for a screen scraping function at the
client
computer,
[0021] FIGS. 8a and b illustrate pseudocode for a parsing function of the
parsing and filtering module of FIG. 2,
[0022] FIG. 9 illustrates pseudocode for a filtering function of the parsing
and
filtering module of FIG. 2.
DETAILED DESCRIPTION
[0023] Turning to FIG. 1, a communications system 20 may comprise a client
computer 30 associated with a consumer 31, a financial institution server 38
associated with a financial institution 39, a facilitation server 36
associated with an
intermediary 34, and a vendor server 32 associated with a vendor 33, connected
through the public Internet 22. Vendor 33 may be registered with intermediary
34
so that the vendor server 32 may accept payment through an intermediate
account
that may be supported by facilitation server 36. For a consumer 31 to use an
intermediate account, consumer 31 may first register with his financial
institution 39
for on-line banking, and add intermediary 34 holding his intermediate account
as
bill payee.
-4-
CA 02530250 2005-12-14
[0024] In overview, a consumer wishing to use a non-credit card method of
payment for an on-line purchase, such as a purchase from vendor 33, may
register
for an account with intermediary 34 by connecting over the public Internet 22,
to
facilitation server 36, using his ciient computer 30. After registration,
intermediary
34 may assign the consumer 31 a unique set of identifying information, such as
an
UserlD and a password. Thereafter, the consumer may deposit money into his
intermediate account, as follows. The consumer may log into facilitation
server 36
over the public Internet 22 using his identifying information and request a
deposit.
The consumer may then be presented with a number of deposit options, including
an instant bill payment deposit.
[0025] If the consumer 31 selects the instant bill payment deposit option, he
may
be presented with a list of financial institutions from which he may select
the name
of his financial institution. This causes facilitation server 36 to serve up a
container
web page comprising an user interface button which, when selected, sends data
back to facilitation server 36, and an embedded secondary window. If this is
the first
time that the consumer 31 is visiting the container web page, the consumer 31
is
asked to download an application from facilitation server 36 over the public
Internet
22 onto his client computer 30. Once the application is installed on client
computer
30, it creates an embedded web browser in the secondary window in the
container
web page. The facilitation server 36 sends an indication (e.g. a universal
resource
locator (URL)) of the selected financial institution to the client computer 30
so that
the embedded web browser is directed to the on-line banking site of the
selected
financial institution.
[0026] Next, the consumer 31 may log into financial institution server 38
through
the embedded web page served up by financial institution server 38 using the
unique identifying information that his financial institution has assigned him
and
request a bill payment transaction in a conventional fashion to the
intermediary for
the amount that he wishes to deposit. When financial institution server 38
accepts a
bill payment, as is typical, a confirmation page is received by the client
computer 30
for display. Once the confirmation page is displayed, the consumer 31 may
select
-5-
CA 02530250 2005-12-14
the aforenoted UI button on the container web page. This causes the downloaded
application to "scrape" data from the embedded web page and send the data to
facilitation server 36 over the public Internet 22. The scraped data may then
be
parsed by facilitation server 36 and filtered to decide whether or not to
credit the
consumer's 31 intermediate account with the bill payment amount.
[0027] If the consumer's 31 intermediate account is credited with the amount
of
the bill payment, the consumer 31 may immediately use these funds in an on-
line
purchase, for example, from vendor 33 through vendor server 32. Further, these
funds may be guaranteed to vendor 33, by the intermediary, to be present. If
the bill
payment transaction is considered invalid, the consumer 31 may be directed
either
to try again, or to wait for the payment to be credited to his intermediate
account
within the regular banking holding period.
[0028] In deciding to honour the consumer's 31 deposit transaction
immediately,
facilitation server 36 may rely upon data captured directly from the financial
institution's bill payment confirmation web page. This provides little chance
of fraud
on the intermediary by a consumer, and hence, little chance of fraud on a
vendor
accepting funds from the intermediary. Furthermore, the consumer may
immediately complete his on-line purchase without having to wait for the funds
to
clear from his personal financial institution account through to his
intermediate
account.
[0029] Turning to FIG. 2, facilitation server 36 has a port 15 for connection
to
the public Internet 22, and a memory 52 which stores a downloadable
application
54 and a parsing and filtering module 56. As shown in FIG. 3, client computer
30
has a port 16 for connection to the public Internet 22, and a memory 58, which
stores a web browser 60. Web browser 60 may be any conventional web browser,
such as Microsoft Internet ExplorerTM. Further, memory 58 may store
downloadable
application 54, downloaded from facilitation server 36.
[0030] The operation of communications system 20 is described in detail in
conjunction with FIGS. 4 to 9.
-6-
CA 02530250 2005-12-14
[0031] Client computer 30 may connect to facilitation server 36 associated
with
an intermediate account over the public Internet 22 in a conventional fashion.
The
consumer 31 may then select an instant bill payment deposit option from, for
example, a drop-down menu on a web page associated with his intermediate
account. The consumer 31 may also select a financial institution from, for
example,
another drop-down menu on the same web page. Facilitation server 36 keeps a
record of the selected financial institution.
[0032] Consumer 31 may then be presented with a web page 80 (FIG. 4, S400;
Fig. 6a). Web page 80 may be written in an Internet markup language, or an
Internet markup scripting language, or both, and may be downloaded from
facilitation server 36 and displayed by web browser 60 (Fig. 6a). If this is
the first
time that client computer 30 is displaying web page 80, the consumer may be
asked to download downloadable application 54 onto client computer 30 from
faciiitation server 36, through the public Internet 22 (FIG. 4, S402; FIG. 5,
S500).
Downloadable application 54 may include an ActiveX control object, written in
Visual Basic. Downloadable application 54 creates an embedded web browser 61
within web browser 60 (Fig. 6a). As may be appreciated by those skilled in the
art,
an ActiveX control is a simple OLE (Object Linking and Embedding) object. OLE
is
a compound document standard developed by Microsoft Corporation which
enables software developers to create objects in one application and embed
them
in another application. (See, for example,
http=//msdn.microsoft.com/library/default.asp?url=/workshop/components/activex/
ac
tivex node entry.asp, the contents of which are incorporated herein by
reference).
[0033] Once downloadable application 54 is installed and executing on client
computer 30, client computer 30 creates an embedded web browser 61 within web
page 80. Client computer 30 may then receive an indication of an on-line
banking
URL of the selected financial institution from facilitation server 36 (FIG. 4,
S404;
FIG. 5, S502). Embedded web browser 61 is directed to this on-line banking URL
of
the selected financial institution, presenting the consumer 31 with a web page
84
associated with the selected financial institution (FIG. 4, S406; Fig. 6a).
-7-
CA 02530250 2005-12-14
[0034] Next, the consumer 31 may log into financial institution server 38 and
request a bill payment, to be paid on the current day, through embedded web
browser 61 in a conventional fashion. When a bill payment transaction is
successfully completed, as is typical, financial institution server 38 may
return a
confirmation web page 84a (Fig. 6b). Confirmation web page 84a typically
contains
the following fields: the name of the bill payee 86a, an account number of an
account from which the amount of the bill payment is deducted 86b, the amount
of
the bill payment 86c, the date of the bill payment 86d, and a confirmation or
reference number 86e (Fig. 6b).
[0035] The consumer may be directed, by directions provided on web page 80,
to select UI button 62 once confirmation web page 84a is served up by
financial
institution server 38, in embedded browser 61. When UI button 62 is selected,
downloadable application 54 may scrape data captured from confirmation web
page 84a and send the captured data to facilitation server 36 (FIG. 4, S408;
FIG. 5,
S504). Captured data may comprise: the name of the bill payee 86a, the account
number 86b, the amount 86c, the date 86d, and the confirmation number 86e
(Fig.
6b). In particular, downloadable application 54 may scrape and collect data
from
confirmation web page 84a by traversing each frame in web page 84a and
concatenating the html text into a string-type variable (FIG. 7,1. 4-6) named,
for
example, htmlData (FIG. 7,11. 2). A check is then performed to ensure that the
name
of the intermediate account, as bill payee 86a, in this example, "NAVAHO", is
contained in the htmiData string (FIG. 7,11. 12-16). If the name of the
intermediate
account is not present, an error message may be generated indicating that the
confirmation page is invalid (FIG. 7,1. 13). Otherwise, the htmlData string is
sent to
facilitation server 36 over the public Internet 22 using a standard protocol,
such as
HTTP/SSL (FIG. 7,1. 15).
[0036] Upon receiving the captured data, encapsulated in the htmlData string
(FIG. 7), from client computer 30, facilitation server 36 may parse and filter
the data
(FIG. 5, S506) using parsing and filtering module 56 located in memory 52
(FIG. 2).
Parsing and filtering module 56 may be a program, written in a programming
-8-
CA 02530250 2005-12-14
language such as JAVA, which includes two functions: a ParseScreenData()
function and a FilterBillPayment() function (FIGS. 8a and b; FIG. 9).
[0037] The ParseScreenData() function may take two input parameters: 1) a
string containing the captured data from confirmation web page 84a, named, for
example, htmlData, and 2) an integer indicating the name of the selected
financial
institution, named, for example, bankName (FIG. 8a, I. 11). The
ParseScreenData()
function may then parse the htmiData string, into the account number 86b, the
amount of the bill payment 86c, the date of the bill payment 86d, and the
confirmation number 86e (Fig. 6b). Specifically, variables may be declared to
hold
the values of the four fields that will be extracted from the htmlData string
(FIG. 8a,
1. 15-18). Variables containing the starting and ending index of each field
within the
htmlData string may also be declared (FIG. 8a, I. 20-29). Then, based on the
integer indicating the name of the selected financial institution, the
starting and
ending indices of each of fields 86b to e, within the htmlData string, are
determined
from a pre-stored record, for example, a data file on facilitation server 36
(FIG. 8a
and b, I. 33-59). If the bank name is not recognized, an error message may be
generated indicating an invalid bank name (FIG. 8b, I. 55-58). Next, the
values of
fields 86b to e are extracted from the htmlData string (FIG. 8b, I. 61-64).
Finally, a
BiIlPaymentEntity object, which represents a bill payment transaction, is
instantiated with the extracted values of fields 86b to e (FIG. 8b, I. 68).
ParseScreenData() then returns this BiliPaymentEntity object to the calling
function
(FIG. 8b, I. 69).
[0038] The FilterBillPayment() function may take two input parameters: 1) a
BiIlPaymentEntity object, for example, one retumed by a call to the
ParseScreenData() function (FIG. 9,1. 8), and 2) the integer indicating the
name of
the selected financial institution. A check is then performed to determine
whether
the values of the fields 86b to e of the BillPaymentEntity object represents a
valid
bill payment. If the value(s) are valid, FilterBillPayment() returns true,
else, it returns
false (FIG. 9, I. 10-15). In this example, if one of the following conditions
fails, the
bill payment is deemed to be invalid: 1) the account number is invalid; 2) the
amount of the bill payment exceeds some pre-defined maximum amount; 3) the
-9-
CA 02530250 2005-12-14
date of the bill payment is sometime in the future, and not the current day;
or 4) the
confirmation number is invalid (FIG. 9, I. 10-11). Validity of an account
number and
a confirmation number may be determined, for example, by comparing the
extracted account number 86b and confirmation number 86e to known formats
used by the selected financial institution to generate an account number and a
confirmation number.
[0039] If the bill payment transaction is found to be valid, facilitation
server 36
may immediately credit the consumer's intermediate account with the amount of
the
bill payment (FIG. 5, S508).
[0040] Having deposited sufficient funds into his intermediate account, a
consumer 31 who wishes to make an on-line purchase from vendor 33 through
vendor server 32 may do so in a conventional fashion. And when prompted for a
method of payment, the consumer may then transfer funds from his intermediate
account to the vendor 33 in a conventional fashion.
[0041] In an alternate embodiment of the invention, the fields that are
extracted
from the data string captured from the confirmation page may include the name
of
the financial institution, and may also include the name of the bill payee. In
this
instance, the name of the bill payee may be verified at the facilitation
server 36
rather than by downloadable application 54 at the client computer. Further,
the
captured identity of the financial institution may be compared with the
selected
financial institution at the facilitation server 36 to act as a further
verification.
Without this further verification, the identity of the financial institution
is implicitly
verified by checking the format of the account number and confirmation number
with the expected format from the selected financial institution.
[0042] In another embodiment of the invention, the account from which a
consumer 31 makes a bill payment may itself be an intermediate account, if
this
account supports a bill payment transaction, and further, also provides a
confirmation page which contains data from which the validity of the bill
payment
transaction may be determined.
-10-
CA 02530250 2005-12-14
[0043] In yet another embodiment of the invention, the user interfaces that a
consumer 31 interacts with in order to deposit money into his intermediate
account
need not be web pages accessed through the public Internet 22. Instead, the
consumer 31 could log into facilitation server 36 over a private network using
a
standalone application. This standalone application may allow the consumer 31
to
access to, and interact with, financial institution server 38. The screen-
scraping and
parsing and filtering functions may employ types of textual data other than
html.
[0044] In yet another embodiment of the invention, the location of the fields
that
are extracted by the ParseScreenData() function within the captured data
string
may be indicated by means other than the starting and ending indices of the
field in
the data string. For example, for each financial institution, information may
be kept
by facilitation server 36 about the name of each examined field and the length
of
the field. Then, when looking for the value of a particular field in the data
string,
ParseScreenData() may look for the occurrence of the field name within the
data
string and extract the next x characters in the data string, where x is the
known
length of the field. These x characters would be the value of the field.
Similarly,
other types of conditions may be checked by the FilterBillPayment() method to
determine whether the bill payment transaction should be honoured or not.
[0045] In a second embodiment, the operation is identical to that described in
conjunction with FIGS. 1 to 9 except that, with reference to FIG. 5, step S508
changes. Specifically, if the data relating to a bi!l payment transaction
passes the
tests imposed by the filtering of the data (at S506), the facilitation server
36 does
not credit an intermediate account, but instead identifies to an account
provider,
such as an on-line merchant, a payee and a payment amount. In this embodiment,
a consumer, on registration with the intermediary 34, may establish the
recipient
account provider or, alternatively, whenever the consumer visits the web site
of the
intermediary, the consumer may identify a recipient for the ensuing bill
payment
transaction. In this regard, the consumer may be restricted to a list of
possible
recipients, representing ones which have agreed with the intermediary to
accept
confirmed payments from the facilitation server.
-11-
CA 02530250 2005-12-14
[0046] In another embodiment, the financial institution server may be arranged
so that when a consumer completes a bill payment transaction in favour of the
intermediary, the financial institution server 38 sends confirmation
information
directly to the facilitation server 36 of the intermediary 34. The
facilitation server
parses (where necessary) and filters this confirmation information in order to
decide
whether to credit the consumer's intermediate account.
[0047] This embodiment avoids the need for the client computer to communicate
with the intermediary before and after a bill payment transaction. Thus, the
downloadable application 54 is not needed (as there is no need for an embedded
web page at the client computer and no need to screen scrape confirmation
information from the client computer 30).
[0048] The set up for operation of this embodiment is as follows. Firstly, the
consumer registers for on-line banking with his financial institution and
establishes
the intermediary as a possible payee in a bill payment on-line banking
transaction.
Assuming the intermediary and the financial institution have previously
established
a relationship, in establishing the intermediary as a possible payee, the
financial
institution server may be configured to provide the consumer with the option
of
having confirmation of bill payments sent directly to the intermediary, as
well as to
the consumer. The consumer also needs to register for an intermediate account
with the intermediary.
[0049] In operation of this embodiment, the consumer may direct the browser of
his client computer 30 to the on-line banking site of his financial
institution hosted
by financial institution server 38. The consumer may select the intermediary
as the
payee in a bill payment transaction. On completion of the transaction, the
financial
institution may send a confirmation page to the client computer's web browser
and,
additionally, may send confirmation information directly to the facilitation
server 36
of the intermediary. The facilitation server parses (where necessary) and
filters this
information and then selectively credits the consumer's intermediate account
with
the amount of the bill payment.
-12-
CA 02530250 2005-12-14
[0050] Other modifications will be apparent to those skilled in the art and,
therefore, the invention is defined in the claims.
-13-
