Note: Descriptions are shown in the official language in which they were submitted.
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 1 -
SYSTEM AND METHOD FOR PURCHASING GOODS AND SERVICES
THROUGH FINANCIAL DATA NETWORK ACCESS POINTS
Field of the Invention
This invention relates to the field of purchasing goods and services using
publicly available access points connected to financial data networks.
Background of the Invention
Communication services, including mobile phone service, public phone
service, residential phone service, Internet service, and other services, are
delivered
through a large number of public communication systems. Many of these systems
require pre-payment in order to utilize the system's services. For example,
public
phones may require currency, a phone card number, or the access code from a
pre-paid
phone card. Similarly, many mobile phone customers must prepay for their phone
time. This is particularly prevalent in Europe. Access to public electronic
mail, video
phones, and Internet terminals may also require prepayment. For many of these
systems it may be difficult or inconvenient to build in the hardware and
transaction
protocols for accepting electronic payment. For example, magnetic card readers
and
secure connections to an electronic funds transfer network, or other financial
data
network, may impose undesirable technical requirements for some public and
mobile
communication systems.
Presently, many users of such public and mobile communication systems
purchase cards in varying currency denominations (e.g., $30 of long distance)
or
quantities of communication time (e.g., 30 minutes of mobile air time). These
cards
provide an access number which is presented to the communications system
(e.g., by
dialing the access number prior to dialing the destination telephone number)
to access
the prepaid quantity of communication services. The access number is linked
through
the communication system to an account database which tracks the amount of
time or
money remaining in the prepaid account. Presently, such prepaid phone cards
are sold
primarily through retail convenience locations, such as drug stores, gas
stations, and
grocery stores, and, in some locations, vending machines. This method of
distribution
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 2 -
entails extra costs for the production, distribution, and retail mark up of
the cards.
Further, only set denominations of cards are available; not all retailers are
available 24
hours a day, seven days a week; and, few vending machines accept credit or
debit card
payments.
These and other drawbacks of prior art systems are overcome by the various
embodiments of the invention.
Summary of the Invention
It is therefore an object of the invention to overcome the above-mentioned
drawbacks of prior systems.
It is an additional object of the invention to provide a system and method for
purchasing goods and services through secure financial data networks using
available
public access points and/or personal communication devices.
Additional objects and advantages of the invention will be set forth in part
in
the description which follows and in part will be obvious from the
description, or may
be learned by practice of the invention.
These and other objects of the preferred embodiments are particularly achieved
by a system and method for providing a voucher including an access code to a
user
through a terminal device, such as an Automated Teller Machine (ATM),
connected to
a financial data network. The user accesses the ATM using a credit or debit
card,
selects an account from which to deduct money to prepay for the voucher, and
executes a purchase transaction for the voucher. The ATM verifies payment and
returns a voucher access code from a voucher database accessible by the
service
provider accepting the voucher. The access code from the voucher may then be
redeemed for a product or service, such as access to a predetermined quantity
of
communication services.
These and other objectives may also be particularly achieved by an alternate
embodiment in which the user has an account with a service provider and the
ATM
may be used to execute a transaction to add prepaid services directly to the
user's
account, without using a voucher or access code.
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 3 -
The accompanying drawings, which are incorporated in and constitute a part of
this specification, illustrate an embodiment of the invention and, together
with the
description, serve to explain the principles of the invention.
Brief Description of the Drawings
Figure 1 is a schematic view of a system for purchasing goods and services
through an ATM according to one embodiment of the invention.
Figure 2a is a schematic view of a system for purchasing goods and services
through a financial data network using one or more of a variety of terminal
devices
according to an embodiment of the invention.
Figure 2b is a schematic view of a modular application system for use in an
embodiment of the invention, such as the system of Figure 2a.
Figure 3 is a schematic view of a transaction system for purchasing goods and
services through a financial data network using one or more of a variety of
service end
points according to an embodiment of the invention.
Figure 4 is a flow chart illustrating steps in a method of using a transaction
system for voucher based purchase of goods and services through a financial
data
network according to an embodiment of the invention.
Figure 5 is a flow chart illustrating steps in a method of providing vouchers
redeemable for goods and services through a transaction system connected to a
financial data network according to an embodiment of the invention.
Figure 6 is a flow chart illustrating steps in a method of redeeming vouchers
for goods and services issued through a transaction system connected to a
fmancial
data network according to an embodiment of the invention.
Figure 7 is a flow chart illustrating steps in a method of using a transaction
system for account based purchase of goods and services through a financial
data
network according to an embodiment of the invention.
Figure 8 is a flow chart illustrating steps in a method of recharging an
account
value redeemable for goods and services through a transaction system connected
to a
financial data network according to an embodiment of the invention.
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 4 -
Figure 9 is a flow chart illustrating steps in a method of providing goods and
services through an account recharged through a transaction system connected
to a
financial data network according to an embodiment of the invention.
Detailed Description of the Preferred Embodiments
Reference will now be made in detail to the present preferred embodiment of
the invention, an example of which is illustrated in the accompanying drawings
in
which like reference characters refer to corresponding elements.
With reference to the drawing figures generally, and particularly to Figure 1,
a
system 100 for purchasing goods and services through an ATM 110 according to
one
embodiment of the invention is shown. System 100 allows a user to access ATM
110,
for example, using a credit card, bank card, or ATM card, and to select a
product or
service for purchase, such as prepaid communication services. Payment for the
product or service is handled like a balance transfer or account withdrawal
through a
financial data network 150 to which ATM 110 is connected. ATM 110 retrieves or
generates an appropriate Voucher 120 for the product or service, including an
access
code 121 for validating the voucher with the service provider providing the
product or
service. ATM 110 prints or displays Voucher 120 for the user. In one
embodiment,
the user enters the access code 121 into a communication device 130 to access
communication services through Communication System 140. Communication
System 140 validates access code 121 and may adjust the remaining value of
Voucher
120 in response to the communication services delivered.
ATM 110 provides a publicly accessible terminal device for accessing one or
more functions that are at least in part provided through financial data
network 150.
ATM 110 may be one of a variety of terminal devices for providing consumer
access
to products and services provided through financial data network 150. In one
embodiment, ATM 110 includes an Input Device 111, an Output Device 112, and a
Communication Module 113. Input Device 111 provides the user with a way to
enter
information into ATM 110. For example, Input Device 111 may include a magnetic
card reader, a number pad, a biometric sensor (e.g., thumbprint or retinal
scanner), or
other input devices, such as a keyboard, a digital camera, etc. Output Device
112
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 5 -
provides the user with a way of receiving information from ATM 110. For
example,
Output Device 112 may include a display screen, one or more speakers, a
printer, a
cash dispenser, or other output devices. Communication Module 113 provides a
way
for ATM 110 to communicate with financial data network 150 and any other
external
transaction systems, networks, servers, data sources, or other systems
enabling ATM
110's functions. ATM 110 may include one or more resident data processors,
memory systems, and/or logic systems (e.g. software) for enabling local
storage and
processing of information for some functions. In one embodiment, ATM 110
includes
thin client software, such as a specialized web browser, and utilizes the data
processing, memory, and software applications of one or more remote servers
for its
functions. In an alternate embodiment, ATM 110 may include the majority of the
data
processing, storage, and functional logic for performing its functions and
communicate with external systems only for limited data exchanges with
external data
sources and transaction systems. The use of an ATM as an access point and
terminal
device for purchasing goods and services allows a service provider to utilize
an
existing network of input/output terminals stationed in convenient locations
and
providing 24 hour, 7 day a week access for many consumers. Additionally, the
added
data processing and storage capabilities by advances in computer technology
and the
efficiencies offered by ubiquitous and higher bandwidth communication networks
offered banks and other supporters of the existing ATM networks with the
ability to
add more diverse functions to their ATMs. These features and functions may be
added without decreasing the ATM's functionality for the financial
transactions for
which they were designed and put in place. ATM 110 may be just one of a
variety of
access points capable of accessing the transactional systems of financial data
network
150, as described below.
In one embodiment, customer access points may include point of sale
terminals, integrated voice response systems, mobile telephones or other
handheld
wireless devices, or the Internet. Each of these access points includes an
input device,
by which the user may enter information, an output device or channel, by which
the
user may receive information concerning the transaction and a communication
module
permitting communication with fmancial data network 150.
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 6 -
In one embodiment, the access point is accessed by a merchant or through an
access point available at a merchant site (e.g., a POS system). In this
embodiment, the
merchant may receive a cash payment from the user and provides payment
verification
to the financial data network. The merchant may use one of the customer access
devices described above to input information concerning the transaction and
confirm
the purchase. For example, a mobile phone vendor may use the system to offer
customers instant transactions for the purchase of prepaid time on a mobile
phone
network, through the vendor's PUS system. The transaction is settled by a cash
payment between the merchant and the seller of the product or service. The
merchant
may use the system to provide recharge of an existing service account or may
provide
a voucher to the user, as described below.
Voucher 120 is a credit with one or more service providers which represents
payment received for a product or service yet to be rendered, in whole or in
part.
Voucher 120 need not be tangible, it may be embodied solely in electronic
information conveyed to the user. For example, Voucher 120 may be information
displayed upon a display screen or may be an audible message conveyed through
a
speaker. In some embodiments, however, Voucher 120 may be embodied in a
physical form, such as printed on an ATM receipt. In one embodiment, Voucher
120
may correspond to an entry in a database of service provider information for
tracking
such credits. Voucher 120 may include an access code, such as access code 121.
Access code 121 may be any unique identifier that can be used to validate
Voucher
120 for the purpose of being redeemed by a service provider. Access code 121
may
be a number, such as a conventional PIN or account number, an arbitrary
alphanumeric code, a password, or, in some embodiments, a machine-readable
code
(e.g., a bar code) or an auditory code (e.g., a tonal code). In one
embodiment, where
the access code is intended to be entered through a conventional communication
device, such as a telephone or mobile phone, the access code may be limited to
a
relatively short alphanumeric code within the data entry parameters of a
telephone
number pad. In some embodiments, the access code 121 may be only a portion of
a
string of numbers or other protocol for redeeming the services. For example,
ATM
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
-7-
110 may provide both a telephone number to be dialed and an access number 121,
both of which may be required to access the purchased communication services.
Communication device 130 allows a user to redeem Voucher 120 for the
communication services, or other products or services, transacted for through
ATM
110. Communication device 130 is connected to Communication System 140 for
providing communication services to the user of communication device 130.
Communication device 130 may include any type of communication device, such as
a
mobile phone, public telephone, two-way radio, video phone, electronic mail
terminal,
or other communication device. In one embodiment, communication device 130
includes an input device, such as a number pad, for entering access code 121.
In one
embodiment, communication device 130 and/or Communication System 140 may
include voice recognition or other audible signal processing (e.g., tone
processing) for
receiving access code 121.
Communication System 140 may be any public or proprietary communication
system and may or may not be interconnected to the worldwide communication
network. Communication System 140 receives access code 121 and/or a request
for
redemption of Voucher 120 through communication device 130 and provides the
requested communication services to the user. For example, Communication
System
140 may allow a user to place a long distance phone call, send an electronic
mail
message, send an instant message to a particular terminal device, send a query
to a
data system, or similar functions. Voucher 120 may provide access to a
predetermined quantity of the communication services, such as a set period of
time, a
set number of messages, a period of unlimited use, one or more rates debited
against
an account value, or any other quantity of usage rights, including
combinations of
those listed here. In order to provide access to communication services in
accordance
with Voucher 120 and to keep track of use of Voucher 120, where usage is
limited,
Communication System 140 validates access code 121 and uses access code 121 to
access a description of Voucher 120, such as Voucher Data 181. In one
embodiment,
access code 121 provides access to a user Account Data 183 through a Billing
System
182. Voucher Data 181, Billing System 182, and Account Data 183 may be
maintained as part of Communication System 140 or financial data network 150.
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 8 -
Voucher Data 181, Billing System 182, and/or Account Data 183 may be provided
by
a third party or as an independent system connected to Communication System
140
and financial data network 150.
Financial data network 150 may include a variety of interconnected systems
for providing financial services to consumers, service providers, and
financial
institutions. In one embodiment, Financial data network 150 includes a
Transaction
System 160 including a Routing System 161 and a Processing System 162.
Financial
data network 150 may include one or more payment systems, such as Payment
System
170. Payment System 170 may include a clearinghouse for financial
transactions,
such as a bank providing electronic account access or a credit card company.
Financial data network 150 may include one or more data processing servers,
such as
Processing Server 180, for providing financial and service data and data
processing in
response to queries and service requests. Processing servers may communicate
with
one or more data repositories or data processing systems, such as Voucher Data
181,
Billing System 182, and Account Data 183. Financial data network 150 may
include
an isolated data network, such as an intranet, business-to-business network,
or other
proprietary network, or may use security and access limiting protocols within
a
general use wide area network, such as the Internet.
Transaction System 160 may include one or more systems for directing data
between networked resources included within or connected to financial data
network
150 and may also include functional logic for providing additional processing.
Transaction System 160 may also include or be connected to a data source, such
as
Transaction Data 163, for recording and tracking transaction details for
transactions
nassing through Transaction System 160_ Routing System 161 may include
switchina
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 9 -
may receive communication data and distribute it according to addressing
and/or
communication protocols contained in the data (e.g., the information on the
location
of the user's bank account contained in the magnetically encoded information
read by
ATM 110). Routing system 161 may receive requests for a communication channel
and provide protocols for securing and timing communications through the
communication channel. In one embodiment, Routing System 161 may communicate
with one or more worldwide communication networks. Routing System 161 may rout
data using to International Electronic Funds Transfer security and
communication
protocols. Routing System 161 may rout data using Internet protocols.
Processing
System 162 may provide the logic for providing consumer services through
Transaction System 160. Processing System 162 may include a system for
evaluating
service requests and directing service requests to an appropriate service
provider. In
one embodiment, Processing System 162 may evaluate a service request and
provide
at least a portion of the data processing required for fulfilling the request.
For
example, Processing System 162 may receive a request for a voucher from a
particular
communication service provider of a particular dollar value with payment to be
withdrawn from the user's debit account with a particular bank. Processing
System
162 may evaluate the request and determine the various functional components
to be
executed, package the necessary data for each communication with another
system,
and coordinate the returned data to verify that the entire transaction is
successfully
completed. For example, Processing System 162 may send an inquiry to a
processing
server for voucher information for the particular communication service
provider and
value, may initiate a payment transaction between payment system 170 (e.g.,
the
user's bank) and the communication service provider, may record the
transaction in
Transaction Data 163, and may await successful completion of each external
transaction before reporting back to the requesting system (e.g., ATM 110)
that the
transaction is complete. One embodiment of Transaction System 160 is further
described below with reference to Figure 3.
Processing Server 180 may include a database server for= providing voucher
data in response to requests from Transaction System 160. Processing Server
180
may include or be connected to one or more data sources, such as Voucher Data
181
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 10 -
and Account Data 183. In one embodiment, Processing Server 180 may access data
included in Account Data 183 through Billing System 182. Voucher Data 181 may
include one or more database entries for one or more vouchers. Each voucher
database entry may include an access code, a voucher value, and a flag to
determine
whether the voucher has been sold or not. Account Data 183 may include one or
more
database entries for one or more user accounts. Each user account may include
user
information, such as name, billing address, type of service, and other
information, or
may correspond only to a reusable account number or similar identifier not
tied to the
identity of the account user. Each account may include a value to determine
the
communication services available to the user through the account. This value
may be
adjusted by transactions initiated through Transaction System 160 in response
to pre-
payment of additional services. This value may be adjusted by Communication
System 140 in response to communication services used through Billing System
182.
Figure 2a shows a system for purchasing goods and services through a
financial data network using one or more of a variety of terminal devices
according to
an embodiment of the invention. The system 200 includes a Routing System 210
and
an Application Server 220 which act as intermediaries between one or more
service
provider systems, issuer systems, and terminal devices, such as ATMs and POS
systems. Routing System 210 directs data transfer among financial data
networks
(e.g., EFT connection to an Issuer 260), service provider systems, the
Application
Server 220, and some terminal devices (e.g., ATM 241 and POS system 243).
Application Server 220 provides at least some logic, communication protocols,
data
storage, and/or transaction management for enabling various financial and
banking
related services utilizing fmancial data and other information directed
through
Routing System 210. In addition to one or more applications for purchasing
products
or services, Application Server 220 may include a variety of modular
applications for
providing a plurality of banking services, such as provision of a savings
account,
checking account, credit card, brokerage account access and management,
automatic
transaction management, event messaging, and other similar services. The
system 200
may include a plurality of interface servers 230, such as ATM Server 231, POS
Server
232, SMS Server 233, and Web Server 234, for enabling access to the functions
of
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 11 -
Application Server 220 through a plurality of terminal devices, including
ATMs.
Each type of interface server 230 allows users to access the Application
Server 220's
services through a variety of end points, such as personal digital assistants
(PDAs),
cellular phones, personal computers, portable computers, telephones, facsimile
machines, POS systems and other devices, as well as ATMs. Each of the example
servers 230 shown supports a different communications protocol and interface
standard for enabling one or more types of end points or terminal devices to
communicate with the plurality of financial institutions. In one embodiment,
the
system 200 may include a Cryptography System 221 to enable access to financial
data
networks requiring DES encrypted PIN blocks from terminal devices not equipped
with DES encryption. In one embodiment, the system 200 may include a Card
Registry data source 222 to enable access to financial data networks requiring
magnetic card information from terminal devices not equipped with magnetic
card
readers. Service provider systems 250 may be connected to Application Server
220
through Routing System 210. Service provider systems 250 may provide
fulfillment
and voucher and account maintenance for products or services purchased through
system 200. Service provider systems 250 may include one or more service
providers,
such as Service Providers 251 and 252, one or more processing servers, such as
Processing Server 253, and one or more data repositories, such as Voucher Data
source 254 and Account Data source 255'. Issuer 260 (i.e., financial
institutions
issuing ATM, debit, and credit cards) may provide electronic payment for
products or
services purchased through system 200.
In order to route communications, as referenced above, Routing System 210
includes switching and monitoring hardware and software for directing
communications containing electronic financial data traffic to a predetermined
destination (financial institution) according to the communications protocols
appropriate to that financial institution. Routing System 210 further includes
a hub
for directing traffic in electronic financial data among a variety of
otherwise =
incompatible communications networks and financial data systems. Routing
System
210 may also include a number of communication channels and network
connections
for communicating the electronic financial data using EFT standards, Internet-
based
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 12 -
standards, proprietary standards, and other standards for secure data
transfer. The
communication channels of Routing System 210 may also serve to interconnect a
variety of specialized and/or standalone financial end points, such as ATM 241
and
POS system 243.
In order to perform the above-described functions, Routing System 210
preferably includes an AS/400 platform using an OS/400 operating system and
ITM
2.2 software for account access and associated settlement. Alternate platforms
may
include Windows NT, Linux, Unix, and similar platforms.
Application Server 220 includes one or more servers for hosting a plurality of
financial and banking service applications, as well as service and product
purchasing
services. Such financial and banking service applications may include any
service
relating to personalized banking, finance, money management, payment
transactions
or investments. Application Server 220 further includes a platform for running
the
plurality of financing and banking applications. Application Server 220
utilizes a
modular application design supporting standard interface objects to provide a
flexible,
readily expandable, and largely hardware-independent system for providing
financial
service applications. For example, Application Server 220 may be an enterprise
application server running a plurality of applications composed of a plurality
of
interchangeable application modules (e.g., Enterprise JavaBeans). One such
interchangeable application module may be used to enable Application Server
220 to
offer financial and banking services through and respond to service inquiries
from
interface server 230. Another may enable Application Server 220 to initiate
transactions (e.g., transfers and queries) with external financial network
systems or
service provider systems.
Application Server 220 may be connected to, and communicate with,
Cryptography System 221 in order to enable the encryption of data in DES-
encrypted
PIN blocks compatible with ATM network data encryption standards. For example,
the Cryptography System 221 may be comprised of hardware for accepting a PIN
from the Application Server 220, encrypting it using DES-encryption, and
returning
the DES-encrypted PIN block to the Application Server 220. The cryptography
system may include a tamper proof casing which disables the cryptography
system if it
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 13 -
is breached. Hardware encryption conversion prevents the decrypted PIN from
ever
being available in an electronic or visible form in which it could be
misappropriated.
The provision of DES encryption may allow a user to access ATM-like functions,
such as the purchase system and method described herein, utilizing an ATM
fmancial
data network from a device not equipped with DES encryption.
Application Server 220 may be connected to, and communicate with, the Card
Registry data source 222 in order to provide magnetic card based access to
financial
services, without a magnetic card reader. In one embodiment, Card Registry
data
source 222 includes a repository of magnetic card data, such as Track II data,
for one
or more users. The data may be accessed using an account number, PIN,
password, or
other method of identifying the user. The card data may then be submitted,
along with
a transaction request, to an issuer requiring magnetic card data to enable
card based
transactions. The Card Registry data source 222 allows a user to access ATM-
like
functions, such as the purchase system and method described herein, utilizing
an
ATM financial data network from a device not equipped with a magnetic card
reader.
In one embodiment, a user's card data may be associated with the user's
identification
in such a way as to provide automated transactions utilizing the card data.
For
example, a user's account data for his/her credit card may be associated with
a user's
mobile telephone (e.g., by telephone number, subscriber number, or telephone
identifier). An application may be defined that accepts a signal from the
mobile
telephone indicating the desire for a purchase transaction. The Application
Server 220
may then execute a transaction for the purchase by identifying the mobile
telephone,
accessing the card data contained in the Card Registry data source 222, and
routing
appropriate transactions to the service provider providing the purchased goods
or
services and the issuer of the credit card. In one embodiment, such a
transaction may
be initiated through a single entry from the mobile telephone, such as a one
touch
dialing function, a dedicated hardware button, a menu option, or another
method. In
one embodiment, Card Registry data source 222 may include a variety of other
information specific to a user, such that it functions as a personal wallet
for the user.
This additional user information may include other bank account information,
utility
account information, preferred merchant account information, telephone numbers
and
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 14 -
other contact information, and other personal information (e.g., health care
provider
and account number, auto club provider and account number, frequent flyer
program
providers and account numbers, etc.)
Interface Server 230, connected to the Application Server 220, provides a
plurality of user interfaces for accessing one or more financial and banking
service
applications hosted on the Application Server 220. The Interface Server 230
may
include a plurality of servers hosting a plurality of interfaces for one or
more
communication protocols and intended end points. For example, Interface Server
230
may include a short messaging service (SMS) server, a wireless application
protocol
(WAP) server, a Web server, an ATM server, a POS system server, an automated
telephone server, etc. The SMS server provides one or more short text messages
for
interactively exchanging information with the user and may be accessed by the
user
using any SMS-enabled device, such as a cellular phone, an alphanumeric pager,
or
another wireless device with limited display capabilities. The WAP server may
provide one or more interface pages, such as pages written in Wireless Markup
Language (WML, an extensible markup language (XML) application), for
interactively exchanging information with the user and is accessible to the
user using
any device supporting WAP, such as a mobile phone, a pager, a two-way radio, a
smart phone, a communicator, and another handheld wireless device. At least a
portion of the content available through the Interface Server 230 may be
provided by
one or more applications from the Application Server 220. Security protocols
used
through Interface Server 230 and associated access points may include SSL,
WSL,
SET, PKI, or any other encryption, digital signature, or security scheme.
Service provider systems 250 may include one or more computer systems
maintained by or for one or more service providers, such as Service Providers
251 and
252. Service Providers 251 and 252 may include any business, financial
institution, or
other entity which maintains a system for dispensing products or services,
such as a
telecommunication company maintaining a communication network for vending
communication services. Data repositories 254 and 255 may include any number
of
data repositories containing voucher data, account data, or information
related to
tracking voucher and account use. Data repositories 254 and 255 may be a
localized
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 15 -
data resource, such as a database or group of databases, or they may be a
distributed
resource, such as a batch of locatable files distributed across a network.
Voucher Data
repository 254 may include voucher information, including access codes, usage
rights,
usage tracking information, and other information for validating and
monitoring
voucher use. Account Data repository 255 may include account information
including
access codes, usage rights, usage tracking information, account or user
identification
(e.g., account number), and other information for validating and monitoring
account
use. Processing Server 253 provides an interface for communications,
transactions,
and data requests routed through Routing System 210 to data repositories 254
and
255. Processing Server 253 may include security verification, query protocols,
and
transaction maintenance for voucher and/or account data. Service Providers 251
and
252 may include similar protocols for interacting with the data stored in data
repositories 254 and 255 in response to user redemption of products or
services or
other administrative functions. Alternatively, service provider communications
may
also be routed through Processing Server 253 or Routing System 210 (alternate
configurations not shown). In another embodiment (also not shown), Voucher
Data
repository 254 and/or Account Data repository 255 may be maintained directly
by the
Application Server 220 and service providers may direct communications,
transactions, and queries through Routing System 210 to access the data. In
still
another embodiment (also not shown), a Voucher Data repository 254 may be
maintained within the Application Server 220 containing the voucher numbers
and
values for issuing vouchers to customers. The Service Provider 251 maintains a
separate Voucher Data repository 254 containing voucher validation and use
data.
The Service Provider 251 provides batches of active vouchers to Application
Server
220 by download or other data transfer, but requires no further access to the
delivered
voucher data. Application Server 220 maintains and sells the voucher batch
without
further need for communication with the Service Provider 251. However, this
method
of maintaining a batch of active vouchers presents increased security risks
and may
require prepayment for the vouchers by the maintainer of the Application
Server 220
or some other settlement process.
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 16 -
System 200 may include end points or terminal devices, such as ATMs 241
and 242 and POS systems 243 and 244. ATM 241 may be a standalone ATM which
includes its own application and interface software and which is capable of
exchanging data with one or more financial data networks through Routing
System
210. ATM 242 may be a thin-client ATM which utilizes, at least in part, the
application software of Application Server 220 and the interface software of
ATM
Server 231. POS system 243 may be a POS system integrated with a retail
business,
including its own application and interface software and capable of exchanging
data
with one or more financial networks through Routing System 210. POS System 244
may be a thin-client POS system which utilizes, at least in part, the
application
software of Application Server 220 and the interface software of POS Server
232.
Other specialized thin-client terminal devices, such as a Web and wireless Web
devices, are also possible in conjunction with a compatible interface server.
In Figure 2b, a modular system 260 for processing user service requests
according to an embodiment of the invention shown. Modular system 260 may be
used by an application server, such as the Application Server 220 in Figure
2a, to
process user service requests, such as requests for the purchase of goods and
services.
Modular system 260 includes a number of application objects 270, such as
Application Objects 270a and 270b. Application Objects 270a and 270b are used
as
standard entry paths for user service requests, such as from Users 201 and
202.
Application Objects 270a and 270b create a transaction 271, such as
Transactions
271a and 271b, that describes the actions to be performed. Router 272
evaluates
Transactions 271a and 271b and directs them to an appropriate provider 273,
such as
Providers 273a, 273b, and 273c. Providers 273a, 273b, and 273c include the
operations for completing Transactions 271a and 27 lb. In some cases, a
provider,
such as Provider 273c, may issue a Service Request 274 to access an external
resource, such as financial data maintained by a financial service provider.
Providers
273a, 273b, and 273c may either direct the transaction to a further provider
or may
return a response 275, such as Responses 275a and 275b, to Application Objects
270a
and 270b.
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 17 -
Application Objects 270 provide standard entry paths for user Service
Requests 261 and 262 and initiate transactions 271 within modular system 260.
Application Objects 270 represent individual actions that modular system 260
may be
called on to perform. Some example Application Objects 270 might include a
logon
object, an account balance inquiry object, a voucher purchase object, a
voucher
balance inquiry, an account recharge object, an account balance inquiry, and
other
objects for providing a variety of financial, administrative, bill paying, and
other
services. In one embodiment, each application object 270 is a stateless
Enterprise
JavaBean (EJB) and is accessible to a user via a Java Naming and Directory
Interface
(JNDI) (not shown). Each Application Object 270 creates a transaction 220 that
describes the action to be performed and contains the user information
necessary to
initiate the action. For example, a logon object would be used to create a
logon
transaction containing basic information such as a user identifier (e.g., a
user name,
credit card number, ATM card number, etc.) and a PIN. A voucher request
inquiry
transaction could be used to create a voucher transaction including the value
of the
voucher to be purchased and the method of payment for the purchase (possibly
including an payment account number and PIN for security purposes). Each
application object 270 may also call Router 272 in order to determine a
destination
provider 273 to process transaction 271. In one embodiment, Application Object
270
passes transaction 271 to Router 272 where Router 272 evaluates transaction
271 and
passes it to a selected provider 273. Alternatively, Router 272 may evaluate
transaction 271 but Application Object 270 actually passes transaction 271 to
the
selected provider 273 identified by Router 272. Each Application Object 270
may
also receive a response 275 from providers 273 and pass the response back to
the user.
Each Application Object 270 may also be able to call a provider 273 to undo,
retry, or
alter a transaction 271 in response to response 275, new input from the user,
or other
system conditions.
Transactions 271, such as Transactions 271a and 271b, may include the data
required by providers 273 to fulfill the function of Application Object 270.
Transactions 271 may include basic transaction information, such as a unique
identifier, a time stamp, a status marker, and originator, and a destination
(or list of
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 18 -
providers 273 for completing the transaction). Any amount of additional
transaction-
specific information may be added to a transaction as a data item. In one
embodiment, the data item includes one or more key/value pairs providing a
description of the data, such as account number or PIN, and the data itself,
such as
Account # 012345, PIN 9876. The data may include a wide variety of data and
file
types and formats, such as numbers, flags, strings, data files, etc., and may
be any size.
Some example data objects might include a graphic file of a canceled check, a
sound
file of a voice recognition sample, or a spreadsheet of recent transactions in
an
account. The data may further include a token including data returned in a
response
from a previous transaction. In one embodiment, each transaction 271 is stored
as an
XML document for access, evaluation, and modification by Router 272 and
providers
273. In another embodiment, each transaction 271 contains a complete record of
the
history of the transaction. Each transaction 271 may be automatically stored
in a
database and may be archived for later retrieval.
Router 272 determines a provider 273 to handle transaction 271. Router 272
uses a combination of transaction details and/or system information to
determine the
optimal destination provider 273. For example, Router 272 mar route the
transaction
data according to account number, transaction amount, or user name. Multiple
routers
may be employed by modular system 260 to perform such routing. A single
transaction may be routed several times over the course of its processing and
Router
272 may be used by Providers 273 as well as Application Objects 270. Router
272
includes a routing table in the format of an extensible markup language (XML)
document that lists the conditions and/or rules under which transactions 271
should be
routed to a particular provider, such as Provider 273a, 273b or 273c.
Providers 273a, 273b and 273c utilize modules that include the logic for
completing at least a portion of the functions performed by one or more
Application
Objects 270. Such Providers 273 use the data stored within transactions 271 to
perform such function. Providers 273 may return a response to the Application
Object
270 which created the transaction 271 or may pass the transaction 271 to
another
Provider 273, with or without consulting Router 272. Providers 273 perform
their
function(s) locally using transaction data and local resources and system
information
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 19 -
and return a response 260 to the Application Object 270. Some providers 273,
such as
Provider 273b, may also perform their function(s) locally using the
transaction data
and local resources and system information, however, their function(s) may be
only a
portion of the total function(s) required by the Application Object 270. The
transaction 271 may be modified to include data generated by Provider 273b and
may
then be routed to another provider 273, such as Provider 273c. Some Providers
273,
such as Provider 273c, may route all or a portion of the data contained in the
transaction 271 to a Service 274 and may then receive responsive data from the
Service 274 to formulate a Response 275 to return to the Application Object
270. In
one embodiment, a number of such Providers 273 may simultaneously work on the
same transaction 271. In another embodiment, the Providers 273 may pursue the
same goal through different channels. For example, multiple Providers 273 may
perform multiple services to get the most rapid response where response times
vary
(e.g., one external service provider may be faster than another external
service
provider for any given request depending on server availability and other
factors).
A Service 274, such. as a data courier service or a communication protocol
service, may be used to exchange data with an external resource, such as a
financial
data network, bank, cryptography system, or data repository. Each Service 274
may
be customized for the communications protocols and data requirements of a
specific
external resource. Service 274 may both send and receive data. The received
data
may be delivered to the Provider 273 which initiated the Service 274, added to
the
transaction and/or returned to the application object in a response.
Responses 275a and 275b may each contain an answer or resolution to the
transaction 271 created by the Application Object 270. Responses 275a and 275b
may
each include information requested by Application Object 270 or may include an
explanation of why the request could not be fulfilled. In one embodiment,
responses
275a and 275b may each include a value to indicate whether or not the
transaction was
successful; a message that explains why the transaction was not successful; if
necessary, a token, such as a reference to the present transaction, that can
be used as
part of a subsequent transaction; and a plurality of additional data items (as
described
above with respect to Transactions 271). The information returned in responses
275a
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 20 -
and 275b may be returned in whole or in part to the user who initiated use of
Application Objects 270 and/or may be the basis of further transactions
initiated
through the same or another application object.
Figure 3 illustrates a Transaction System 300 for providing a plurality of
fmancial consumer and information services through a variety of end points 310
using
fmancial data, content, and transactional functions furnished by a variety of
remote
service providers, such as Fulfillment Service Provider 320 and Financial
Service
Provider 330. These services may be provided to a variety of service end
points 310
from a number of interfaces supporting one or more interface standards and
communication protocols. Some example service end points 310 may include PDA
311, cellular phone 312, PC 313, portable computer 314, telephone 315,
facsimile
machine 316, ATM 317, or POS system 318. Integrated transaction management
system 300 communicates with service end points 310 using any communication
network such as the Internet, telephone networks, wireless networks, radio
networks,
and other communication networks and SMS, WAP, TCP/IP, and its corresponding
data transfer protocols. The services performed by the Transaction System 300
may
use information gathered from and/or exchanged with any one or more remote
service
providers. Transaction System 300 can communicate with the remote service
providers by using any secure communication or financial data network.
Transaction System 300 may further include a variety of functional modules
for providing financial and other information services according to an
embodiment of
the invention. The functional modules may each contain a combination of
software
and/or hardware for performing a task or set of tasks. For example, a data
processor,
memory, and an instruction set (i.e., computer code) may be all that are
needed for
such a functional module to carry out the tasks necessary for a given
embodiment of
each functional module. More commonly, however, multiple input and output
devices, short term and long term memory systems, layers of computer code
(i.e.,
operating system, application software, etc.), communication devices, and
multiple
processors may be used for such a functional module. Additionally, multiple
ones of
such functional modules may share the same hardware and portions of a software
library. In some cases, a functional module may contain one or more other such
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
-21 -
functional modules. As will be understood by those of ordinary skill in the
art, the
functional modules described herein may be embodied in a large number of
equivalent
combinations of code objects and hardware. The combinations represented by the
functional modules described herein are conceptual and should not be construed
as a
limiting structure for the multiple hardware and software combinations capable
of
executing the functional modules' tasks.
As shown in Figure 3, Transaction System 300 includes an Interface System
340, an Application System 350, a Gateway System 360, and a Cryptography
System
370. Interface, System 340 includes one or more functional modules each of
which
provides, one or more user interfaces accessible through a variety of service
end points
310. Application System 350 includes one or more functional modules, each of
which
provides functional processing capabilities for one or more consumer
applications,
including formulating data queries and transaction requests for Fulfillment
Service
Provider 320 and Financial Service Provider 330. Gateway System 360 includes
one
or more functional modules for routing communications between a variety of
disparate networks or communication systems using different communications,
data
transfer, and encryption protocols. Cryptography System 370 includes one or
more
functional modules for encrypting and decrypting data according to one or more
secure encryption standards.
Interface System 340 includes one or more functional modules for presenting
and exchanging information through thin-client end points or terminal devices.
Interface System 340 may access one or more of the functional modules
providing
consumer applications within Application System 350, and may provide an
interface
between such Application System 350 and a consumer as is appropriate to the
varying
bandwidths, memory capacities, processing abilities, input and navigation
methods,
and common uses and environments of the plurality of service endpoints 310
which
may be utilized by the consumer. For example, an interface compatible with an
SMS
device may be limited to 160 text characters for sending and receiving
information. A
WAP device provides greater versatility and, therefore, an interface used in
connection with such WAP device may include graphics and other data, but may
need
to be designed for the limited bandwidth and memory of most WAP devices. Web-
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 22 -
based devices may have any range of capabilities, depending largely on the
type of
terminal device and the bandwidth, memory, and input capabilities of the
intended
terminal device. Even within a particular communications protocol, it may be
preferable to offer multiple interface options depending on the attributes of
a range of
possible terminal devices and users. Interface System 340 may allow
Transaction
System 300 to support traditional ATM-like functions through a variety of
service end
points 310 and enable the purchase of goods and services through voucher and
account applications at those same service end points. As shown in Figure 3,
Interface
System 330 includes a Web Interface module 331, an SMS Interface module 332, a
WAP Interface module 333, an ATM Interface module 334, and a POS Interface
module 335. Other interfaces may also be supported by alternate embodiments,
such
as interfaces supporting other wireless protocols and communications networks,
voice
interfaces for telephone access, proprietary and LAN interfaces for secure
limited
access special services (e.g., for service provider and system administrator
side
transactions and services), and additional interfaces to support the new and
specialized
capabilities of future networkable communication devices.
For example, in one embodiment, an SMS or WAP enabled phone, or another
portable personal communication device, may be used to recharge a user's
prepaid
account for that phone or device. In one embodiment, the SMS or WAP enabled
telephone may be able to access a telephone number or URL (corresponding to an
appropriate interface server) for recharging services even though the user's
prepaid
account has been depleted and the telephone may no longer be used for other
communications. In one embodiment, the user may take the SMS or WAP enabled
telephone to a merchant or service provider and the merchant or service
provider may
accept payment for the services and instantly provide a message or code,
including the
recharge amount and payment verification, to be entered through the user's
phone or
device.
Application System 350 includes one or more modules for providing the
functional processing for one or more consumer applications, including
formulating
data queries and transaction requests to facilitate the purchase of pre-paid
goods and
services. Application System 350 provides a variety of consumer applications
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
-23 -
according to a modular architecture that promotes interchangability,
upgradability, and
universality for access by a variety of interface modules serving a variety of
service
endpoints 310. Application System 350 utilizes data provided by a variety of
external
service providers, as well as internal system and data resources. A single
application
transaction may simultaneously or sequentially access data from, or initiate a
data
exchange with more than one service provider system. Application System 350
may
formulate queries and issue data exchange requests based upon a variety of
protocols
dependent on the destination system and the information sought. Application
System
350 may use a combination of Standard Query Language (SQL) and alternate data
exchange and transaction protocols, depending on the compatibility of the
service
provider systems. In order to facilitate the purchase of pre-paid goods and
services,
one embodiment of the invention includes a Voucher Module 351, an Account
Module 352, a Reporting Module 353, and a Payment Module 354. Each application
module may include a variety of transaction modules for performing the variety
of
functions which may be included within the application module. The
possibilities for
additional application modules and alternative arrangements of application
modules
and component transaction modules are infinite.
Voucher Module 351 provides maintenance and retrieval of voucher numbers
stored in one or more voucher data sources. The voucher data sources may be a
localized resource or may be located remotely. Voucher Module 351 provides
transactions for retrieving available voucher numbers from the voucher
database or
creating new voucher numbers to be added to the voucher database. Voucher
Module
351 may also be able to return or delete an unused voucher number in the event
that
the purchase transaction is not completed. Voucher Module may include a Get
Voucher module 351a and a Return Voucher module 35 lb. In one embodiment, Get
Voucher module 351a is a provider object called by a purchase voucher
application
object in response to a user request to purchase a voucher. Get Voucher module
351a
utilizes a query service to query the voucher data source for a voucher number
corresponding to a particular voucher value. The service response includes a
flag
designating the success or failure of the retrieval and data corresponding to
the
retrieved voucher number. In, one embodiment, Return Voucher module 351b is a
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
-24 -
provider object called by a purchase voucher application object in response to
an
interruption in the transactions session, a rejected payment attempt, or other
basis for
aborting the purchase transaction. Return Voucher module 351b utilizes a query
service to notify the voucher data source to return the included voucher
number to an
available status. The service response includes a flag designating the success
or
failure of the return attempt.
Account Module 352 provides connectivity with existing user accounts stored
in one or more account data sources. The account data sources may be stored
locally
or may be maintained remotely by a fulfillment service provider. Account
Module
352 may provide verification of the existence of a particular pre-paid
account, verify
that a pre-paid account is available for recharging, retrieve the present
value of a
prepaid account, recharge the pre-paid account, and provide other account
maintenance functions. In one embodiment, Account Module,352 may also allow a
user to establish a new pre-paid account through Transaction System 300.
Account
Module 352 may include a Verify Account module 352a and a Recharge Account
module 352b. In one embodiment, Verify Account module 352a is a provider
object
called by a recharge account application object in response to a user request
to
recharge a pre-paid account. Verify Account module 352a may use a query
service to
verify that an account number submitted by the user corresponds to an active
account
in the account data source. The service response may include a code indicating
the
success or failure of the verification, which may indicate an explanation of a
failed
verification attempt. In one embodiment, Recharge Account module 352b is a
provide object called by a recharge account application in response to a
successful
payment transaction based on the user's submitted payment method (e.g., the
clearance of an EFT transaction or credit card charge). Recharge Account
module
352b utilizes a query service to notify the account data source to increase
the value in
the specified pre-paid account be a certain value. The service response
includes a flag
designating the success or failure of the recharge attempt.
Reporting Module 353 includes transaction monitoring and recording for
administrative and billing purposes. Reporting Module 353 may include a
reporting
data source in which a record of each transaction, such as a voucher purchase
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
-25 -
transaction or account recharge transaction, is recorded. The transaction
record may
include transaction details, such as the time of the transaction, transaction
value,
transaction session time, service end from which the transaction was
initiated, etc.
The reporting data source may be used to provide transaction summaries to
service
providers for transaction verification and general account administration. The
reporting data source may also be used to track the transactions for a
particular service
provider in order to assess payment for Transaction System 300's services on a
usage
basis. Reporting module 353 may be used for other data mining activities, such
as
marketing analysis, and may be linked to user infoimation to provide targeted
marketing data.
Payment Module 354 provides for electronic payment of the value of the
product or service to be purchased. Payment Module 354 may allow the user to
pay
for products and services using debit cards, credit cards, electronic
currency, and any
other electronic payment method as is known in the art. In a preferred
embodiment,
payment is handled through ATM protocols for credit card and debit card
transactions
utilizing a magnetic card containing account infolination and a user supplied
PIN. In
an alternate embodiment, payment is provided through a service end device not
equipped with a magnetic card reader and utilizing a registry of Track II data
pre-
registered by the user. POS protocols, Internet payment protocols, proprietary
payment protocols and other protocols may also be used. In one embodiment, a
chip
or smart card may be used to provide payment information, including user
authentication. In one embodiment, electronic currency such as value stored in
a
centrally managed database (e.g., "e-purse") or stored in a chip card may be
used.
Routing System 360 may include one or more modules for directing
communications between two or more of a variety of disparate networks or
communication systems by using different communication, data transfer, and
encryption protocols. For example, Routing System 360 may include an EFT
protocol
module, an Internet protocol module, a proprietary connection protocol module,
or a
variety of other communication protocols. In operation, Routing System 360 may
receive transactions in from an ATM, a financial institution, another EFT
gateway, a
POS terminal, or Application System 350 (e.g, a purchase transaction through
an
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 26 -
alternate service endpoint). Upon receipt of the transaction, Routing System
360
determines the issuer using a Bank Identification Number (BIN) included in the
data
received, such as Track II data from a user's debit card. If the BIN belongs
to a local
bank, the transaction will be routed to the local bank for authorization. If
the BIN
does not belong to a local bank, then a routing decision will be made
depending on the
BIN number of the card. This routing decision will be determined by comparing
the
BIN to routing tables maintained within Routing System 360. When the BIN or
some
appropriate digits of the bin are found the transaction is routed to the
appropriate other
gateway or financial institution for authorization. If the BIN is not found in
the
routing tables then a default gateway will be used to authorize the
transactions. In
one embodiment, a message from the application server may be received in a
proprietary format and converted to a format appropriate for the issuing
endpoint after
the routing decision is made. An authorization will be received from the
authorizing
issuer and the transaction will be approved or declined based on the issuer's
response.
The Routing System 360 may also perform balancing and settlement with the
authorizing issuer, as well as with the acquiring service provider.
As further illustrated in Figure 3, Cryptography System 370 may include one
or more modules for encrypting and decrypting data according to one or more
secure
encryption standards. Cryptography System 370 further includes cryptography
hardware and software substantially as described above for Cryptography System
221
in Figure 2a. In one embodiment, Cryptography System 370 may include protocols
for handling one or more encryption, certificate, digital signature, or other
security
schemes, alone or in combination. These protocols may include compliance with
protocols, such as the DES encryption protocols of the EFT network, the SET
protocols for credit card transactions, chip or smart card authentication
protocols, or
other industry or proprietary schemes. Cryptography System 370 may be adapted
to
additional security schemes as they are developed and adopted for various
financial
data networks.
Fulfillment Service Provider module 320 may be any system for providing
goods or services and accepting payment from user's of those goods or services
through Transaction System 300. Fulfillment service providers may include
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 27 -
communication service providers, intemet service providers, retail goods and
service
providers, vending machine operators, or other providers of goods and
services. Each
Fulfillment Service Provider module 320 may include a system for product
distribution, billing, and administration. In one embodiment, each fulfillment
service
provider maintains one or more computer systems for overseeing product
distribution,
billing, and administration and Transaction System 300 communicates with at
least a
portion of the computer system. Fulfillment Service Provider module 320 may
provide voucher and/or account data for use by the transaction system in
retrieving
vouchers and recharging accounts. Fulfillment Service Provider module 320 may
also
include a system for receiving payments for goods or services from Transaction
System 300, a financial institution (e.g., though Financial Service Provider
module
330), or other sources. Fulfillment Service Provider module 320 may include a
Processing Application module 321, a Billing System 322, a Service System 323,
an
Account Data source 324, and a Voucher Data source 325.
Processing Application module 321 may provide an interface between
Account Data source 324 and/or Voucher Data source 325 and various systems
which
utilize that data, such as Transaction System 300, Billing System 322, Service
System
323, and other systems (e.g., service provider administration, customer
service,
marketing, etc.). In one embodiment, Processing Application module 321 may
include protocols for integrating existing fulfillment service provider
systems (e.g.,
existing account data, data management systems, billing systems, etc.) with
Transaction System 300. Processing Application module 321 may include an
Account
Query module 321a, a Voucher Query module 321b, an Account Maintenance module
321c, and a Voucher Maintenance module 321d. Account Query module 321a may
allow Processing Application module 321 to receive and execute an account data
query (e.g., an account verification query, recharge account query, etc.) from
Transaction System 300. Voucher Query module 321b may allow Processing
Application module 321 to receive and execute a voucher data query (e.g., a
get
voucher query, a return voucher query, etc.) from Transaction System 300.
Account
Maintenance module 321c and Voucher Maintenance module 321d may allow
Processing Application module 321 to receive and execute one or more
maintenance
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 28 -
actions for account and Voucher transactions. Maintenance actions may include
additional queries, data mining, data manipulation, and other actions to
oversee
Voucher Data source 325 or Account Data source 324. Maintenance actions may
also include remotely accessing data or transactional capabilities in other
fulfillment
service provider systems (e.g., Billing System 322).
Billing System 322 may include the fulfillment service provider's systems for
monitoring payments received and services due for pre-paid accounts and/or
vouchers.
Billing System 322 may also include the fulfillment service provider's systems
for
monitoring, presenting, and reconciling payments due for non-pre-paid accounts
and/or vouchers or for pre-paid accounts and/or vouchers initially paid for
using credit
or electronic currency and requiring actual payment from a third party (e.g.,
a credit
card company, bank, or other financial service provider). Billing System 322
may
include a pre-existing billing system established to handle consumer
transactions other
than sale of goods and services through Transaction System 300.
Service System 323 may include the fulfillment service provider's system for
providing goods and services purchased using pre-paid vouchers or accounts.
Service
System 323 may include authorization for distribution or access to goods and
services,
usage tracking for goods and services provided, and service or access
termination
based upon the fulfillment of pre-paid voucher or account value. Service
System 323
may include a communication system for providing communication services to the
user. In one embodiment, Service System 323 is a mobile telephone network and
mobile communication services are provided to the user in accordance with the
value
and conditions upon which the pre-paid voucher or account were purchased. In
one
embodiment, Service System 323 evaluates voucher data or account' data in
Account
Data source 324 or Voucher Data source 325 corresponding to user supplied
account
or voucher identification prior to providing goods or services. In one
embodiment,
Service System 323 may monitor usage of account and/or voucher data in order
to
identify when the value remaining in a pre-paid account is running low.
Service
System 323 may provide a notification to the user through one or more service
end
points. For example, Service System 323 may initiate an automated messaging
service (e.g., telephone message, SMS message, voice mail message, electronic
mail
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 29 -
message, etc.) which warns the user that the account or voucher is running
low. In
one embodiment, a service end device may include a hardware (e.g., LED) or
software
indicator (e.g., display icon) to warn the user when the account or voucher is
low. In
one embodiment, recharge warning messages and indicators may be provided
through
Application System 350.
Account Data source 324 and Voucher Data source 325 include one or more
databases of account or voucher data providing account or voucher
identifications and
corresponding values of pre-paid services or goods. Account Data source 324
may be
substantially as described above for Account Data 183 in Figure 1 and Account
Data
255 in Figure 2a. Voucher Data source 325 may be substantially as described
above
for Voucher Data 181 in Figure 1 and Voucher Data 254 in Figure 2a.
Figure 4 shows a method of using a service end device, such as an ATM, to
access a transaction system and a financial data network for the voucher-based
purchase of goods and services. In step 410, a user accesses a service
endpoint, such
as an ATM, POS system, personal computer, mobile telephone, etc. For example,
the
user could approach an ATM or POS system and swipe a magnetic card, such as a
debit or credit card, to access the service functions of the system. Accessing
a service
end point may include providing user identification (step 411). For example,
swiping
a magnetic card may provide some user identification, such as an account
number and
financial service provider identification. The system may require additional
identification for security purposes, such as a PIN, password, retinal scan,
or other
method to verify that the holder of the card is the authorized user. In step
420, the
user may select a product, such as goods or services, for purchase. Selection
may
include multiple interactive steps. The user may first select a purchase
option from a
menu of system services (e.g., balance inquiry, withdrawal, balance transfer,
purchase
goods or services, etc.). The user may then select from a variety of products
for
purchase available through the system (e.g., mobile communication service,
internet
service, beverage, etc.). In one embodiment, a customized menu of purchase
options
may be offered based upon the identity of the user, location of the service
end point,
time of day, or other factors. Once a product for purchase is selected, a
value for a
product available in a variety of values (e.g., a number of mobile telephone
minutes, a
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 30 -
dollar amount of long distance service, etc.) may be selected (step 421).
Selection of
the value may be chosen from a menu of options or may allow custom entry of
the
value. A service provider from a list of available service providers may also
be
chosen (step 422). In step 430, the user provides payment information.
Providing
payment information may include providing account identification (Step 431).
For
example, the user may be provided with a list of accounts associated with the
card
used to access the system (e.g., checking, savings, credit, etc.). In one
embodiment,
payment information is automatically provided by accessing the system with a
card
associated with a specific account. In step 440, the user received a voucher.
The
voucher may be received as a printout through a service end point receipt
printer or
another dispenser for a physical voucher. The voucher may also be dispensed
solely
as an access code displayed on the service end device display. In step 450,
the user
redeems the voucher through a service provider, such as a communications
company
or vendor. In one embodiment, the user uses a communication device, such as a
cellular telephone, to access a communication network and enters the voucher
code to
access the pre-paid services corresponding to the voucher. In an alternate
embodiment, the user presents the voucher or enters the voucher number into an
automated system at a location that dispenses the goods purchased.
Figure 5 shows a method of providing vouchers redeemable for goods and
services through a transaction system connected to a financial data network.
In step
510, a transaction system receives a transaction request to purchase goods or
services.
For example, the transaction system may receive a transaction message
containing
payment account data, a PIN, a good/service description, a good/service
provider
designation, a good/service value, and a designation for the originating
address (e.g.,
the ATM where the transaction was initiated). In step 520, the transaction
system
retrieves an appropriate voucher for the good or service, provider, and value.
The
transaction system may access an appropriate database of vouchers and search
for a
voucher designated as available (step 521). Alternatively, a new voucher may
be
created and added to the database. The selected voucher may be marked as sold
so
that the same voucher is not sold to more than one user (step 522). In step
530, the
transaction system verifies the payment information (account and PIN) based
upon the
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 31 -
value of the transaction with a financial service provider, such as through an
electronic funds transfer network. The transaction system may initially place
a query
to the appropriate financial service provider for the account be directing the
query
through a routing system. If the query returns data signifying an authorized
account
with sufficient available funds or credit, the transaction system may send a
second
transaction in order to execute an appropriate debit or credit transaction
with the
financial institution. Upon successful completion of the payment transaction,
the
transaction system returns the voucher information to the service end device
originating the transaction (step 540).
Figure 6 shows a method of redeeming vouchers for goods and services issued
through a transaction system connected to a financial data network. In step
610, a
fulfillment service provider, such as a communication service provider or
vendor,
receive a request for a product, such as goods or services. The protocol for
receiving
the product request may be defined by individual service providers and may be
provided to the user by instructions provided at the time a voucher is
purchased or at
the site or device through which the product request is made. For example, a
telephone service provider may provide a toll free number that the user calls
to initiate
a service request, a cellular telephone service provider may pre-program the
protocol
into the user's cellular telephone, or a vendor may provide redemption systems
(such
as vending machines) pre-programmed with the protocol. In step 620, the
fulfillment
service provider receives voucher data, such as a voucher access code. In step
630,
the fulfillment service provider validates the voucher access number against
the
contents of a voucher data source. For example, record for the voucher is
located
using the voucher access number and the record is checked for compatibility
with
requested services and remaining unused value. In step 640, the fulfillment
service
provider provides the product requested according to the compatibility and
value of
the validated voucher. Products may be provided in such a way as to prevent
exceeding any remaining value in the voucher, such as by returning an
available
product amount to the product dispensing system. In step 650, the voucher use
is
recorded in the voucher record for the voucher used. A voucher may be
exhausted or
may have remaining value.
CA 02424037 2003-03-27
WO 02/27629
PCT/US01/40024
- 32 -
Figure 7 illustrates steps in a method of using a transaction system for
account
based purchase of goods or services through a financial data network. In step
710, a
user accesses a service end device, such as by providing an access card (e.g.,
debit
card, credit card, etc.) and a PIN. In one embodiment, the service end device
may be a
personal communication device and the transaction system may include a virtual
card
registry and/or cryptography system for enabling transactions without the use
of an
access card. In step 720, the user selects a pre-existing account on which to
recharge
the value. In one embodiment, the user is offered a menu of the user's pre-pay
accounts enabled for recharging through the transaction system. In step 730,
the user
selects an amount to recharge. In step 740, the user provides payment
information. In
one embodiment, a standard or user-defined automated transaction encompassing
steps 710, 720, and/or 730 may available based upon a single selection through
the
service end device. For example, an ATM or personal communication device may
offer a quick recharge feature which accesses a pre-defined account choice,
payment
method, and recharge value. In step 750, the user receives confirmation of
successful
recharging of the account and provision of payment from the transaction
system. In
step 760, the user accesses the goods or services available through the pre-
paid
account, for example, by providing a user account number to a vendor or
utilizing a
communication device associated with a particular account number.
Figure 8 illustrates steps in a method of recharging an account with value
redeemable for goods and services through a transaction system connected to a
financial data network. In step 810, a transaction system receives a recharge
transaction request. In step 820, the transaction system verifies the
existence,
authorization, and availability of the account for recharging through the
transaction
system by querying an account data source. In step 830, the transaction system
verifies user payment information through a financial data network from a
financial
service provider. In an alternate embodiment, the transaction system verifies
that user
payment has been received at a remote locations (such as a retail outlet). For
example, the user may appear at a retail outlet, tender payment in cash (or
some other
payment method accepted by the outlet), and the retail outlet may submit a
user
transaction request with an appropriate vendor code indicating that payment
has been
CA 02424037 2012-05-10
WO 02/27629
PCT/US01/40024
- 33 -
received. In step 840, the transaction system updates the user account
according to the
value purchased. In step 850, the transaction system returns confirmation to
the user
of the successful recharge transaction.
In Figure 9, a method of providing goods and services based upon the value in
an account recharged through a transaction system connected to a financial
data
network is shown. In step 910, a fulfillment service provider received a
product
request for goods or services according to a pre-defined product request
protocol. In
step 920, the fulfillment service provider receives an account identification
corresponding to the user's recharged pre-pay account. In step 930, the
fulfillment
service provider validates the existence, authorization, and available value
in the
account by accessing an account data source. In step 940, goods or services
are
provided in accordance with the available value in the account. In step 950,
the
account record is updated to reflect the use of the account and any associated
reduction in remaining value.
