CZ20031053A3 - System and method for purchasing goods and services through financial data network access points - Google Patents

Abstract

A system and method for purchasing pre-paid vouchers and recharching pre-pay accounts (183) for goods and services. The system includes a data source containing data descriptive of a voucher (120) or account. The data source is accessible by a transaction system (100) for responding to user service transactions and may be accessible by a fulfillment service provider for providing the goods or services based upon the voucher or account data. The system may be accessed through a variety of service end points, including conventional automatic teller machines (ATMs)(110), point of sale (POS) systems, and personal communication devices.

Description

Technical field

The invention relates to the field of purchasing goods and services using publicly accessible access points associated with financial data networks.

BACKGROUND OF THE INVENTION

Communication services, including mobile telephone service, public telephone service, resident telephone service, internet service and other services, are presented through a large number of public communication systems. Many of these systems require a subscription in order to take advantage of the system's services. For example, public phones may request currency, a phone card number, or a prepaid phone card access code. Similarly, many mobile phone customers have to subscribe to their phone time. This is particularly prevalent in Europe. Access to public e-mail, video telephones and Internet terminals may also require a subscription. For many of these systems, it may be difficult or disadvantageous to incorporate hardware or transaction protocols to receive electronic payments. For example, magnetic card readers and security connections to the electronic cash transmission network or other financial data networks may impose undesirable technical requirements on some public and mobile communication systems.

In the presence of many users of such public and mobile communication systems, they purchase cards in different monetary values (eg $ 30 for long distance calls) or length of connection time (eg 30 min of mobile connection). These cards provide an access number, which is presented to the communication “9 9 9” 9 9 9 9 9 9 9 * · ··

16011 ~ 2 ~ system (eg by dialing a destination phone number) to access a subscription to a number of communications services. The access number is connected by a communication system to an accounting database that monitors the amount of time or money remaining in the prepaid account. In the present, such prepaid calling cards are mainly sold through occasional retail outlets such as newsagents, gas stations, convenience stores, and in some locations vending machines. This method of distribution requires surcharges for card production, distribution and retail overheads. Furthermore, only fixed card values 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 disadvantages of the prior art systems are overcome by various embodiments of the invention.

SUMMARY OF THE INVENTION

Therefore, it is an object of the invention to overcome the above-mentioned drawbacks of the prior art systems.

Another object of the invention is to provide a system and method for purchasing goods and services via secure financial data networks using available public access points and / or personal communication means.

Other objects and advantages of the invention will be explained in part in the following description and in part will be apparent from the description, or may be learned from the practice of the invention.

In particular, these and other objects of the preferred embodiments are achieved by a system and method for providing a voucher comprising an access code to a user by means of a voucher.

16011 -3terminal means 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 the account from which to deduct the money for the subscription for the voucher, and makes the purchase transactions for the voucher. The ATM verifies the payment and issues the voucher access code from the voucher database accessible to 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 number of communication services.

In particular, these and other objectives can be achieved by an alternative embodiment in which the user has an account with the service provider and the ATM can be used to execute the transaction to add the subscription service directly to the user's account without using a voucher or access code.

The accompanying drawings, which are incorporated in and constitute a part of this description, illustrate embodiments of the invention and together with the description serve to explain the principles of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

Giant. 1 is a schematic representation of a system for purchasing goods and services through an ATM according to an embodiment of the invention; FIG. 2a shows a diagram of a system for purchasing goods and services through a financial data network using one or more of a variety of terminal means according to an embodiment of the invention; a diagram of a modular login system for use in one embodiment of the invention, such as the system of Fig. 2a,

9 · 9 9

16011 -4obr. 3 is a diagram of a transaction system for purchasing goods and services through a financial data network using one or more of a variety of service endpoints according to an embodiment of the invention; FIG. 4 is a flow chart illustrating the steps of using a transaction system for voucher based purchasing goods and services through Fig. 5 is a flow chart illustrating the steps of a method of providing redeemable vouchers for goods and services through a transaction system connected to a financial data network according to an embodiment of the invention; Fig. 6 is a flow chart illustrating the steps of a method of redeeming vouchers for goods and services through a transaction system connected to a financial data network according to an embodiment of the invention, Fig. 7 is a flow chart illustrating Referring to the method of using a transaction system for an account based purchase of goods and services through a financial data network according to one embodiment of the invention, FIG. 8 is a flow chart illustrating the steps of a method of replenishing an account value redeemable for goods and services through a transaction system connected to Fig. 9 is a flow chart illustrating the steps of a method of providing goods and services through an account replenished through a transaction system connected to a financial data network according to an embodiment of the invention.

• * • *

EXAMPLES OF THE INVENTION

A preferred embodiment of the invention will now be discussed in detail, an example of which is illustrated in the accompanying drawings, in which like reference numerals refer to corresponding elements.

Referring to the figures in general and in particular to Figure 1, there is illustrated a system 100 for purchasing goods and services through an ATM 110 according to one embodiment of the invention. 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 as a prepaid communication service. Payment for a product or service is treated as a balance transfer or account withdrawal through a financial data network 150 to which an ATM is connected. ATM 110 locates or creates the appropriate voucher 120 for the product or service, including the access code 121 to verify the voucher with the service provider providing the product or service. ATM 110 prints or shows a voucher 120 for the user. In one embodiment, the user enters the access code 121 into the communication means 130 to access the communication services through the communication system 140. The communication system 140 verifies the access code 120 and can set the remaining value of the voucher 120 in response to the supplied communication services.

ATM 110 provides a publicly accessible terminal means for accessing one or more functions that are at least partially provided through the financial data network 150. ATM 110 may be one of a variety of terminal means for providing customers with products and services provided through the financial data network 150. In one embodiment, the ATM IIP comprises input means 111, output means 112, and a communication module 113. Input means

16011

For example, the input means 111 may include a magnetic card reader, a dial pad, a biometric sensor (e.g., a fingerprint or retina scanner) or other input means such as a keyboard, digital camera, and the like. means 112 provides a way for the user to receive information from ATM 110. For example, output means 112 may include a screen, one or more speakers, a printer, cash dispenser, or other output means. The communication module 113 provides the ATM 110 with a way to communicate with the financial data network 150 and any other external transaction systems, networks, servers, data sources, and other systems enabling ATM 110 functions. The ATM 110 may include one or more resident data processors, storage systems, and / or logic systems (eg software) to enable local storage and processing of information for some functions. In one embodiment, ATM 110 includes limited user software, such as a dedicated network browser, and utilizes data processing, memory, and software applications of one or more remote servers for its functions. The ATM 110 can include most of the data processing, memory, and functional logic to perform its data functions to communicate with external systems only for limited data exchange with external data sources and transaction systems. Using an ATM as an access point and terminal means for purchasing goods and services allows the service provider to leverage the existing network of input and output terminals located at convenient locations and to provide access to many customers 24 hours a day, 7 days a week. In addition, the added data processing and storage capabilities due to advances in computer technology and the productivity offered by the ubiquitous, wider bandwidth communications networks offer banks and other supporters of existing ATM networks the ability to

16011

9

9 «add more different features to their ATMs. These features and functions can be added without reducing the functionality of ATMs for financial transactions for which they have been designed and located. ATM 110 may be just one of a variety of access points capable of accessing transaction systems of the financial data network 150, as described below.

In one embodiment, customer access points may include point of sale terminals, integrated voice response systems, mobile phones or other handheld wireless means or the Internet. Each of these access points comprises an input means by which the user may enter information, an output means or a channel through which the user may receive transaction-related information and a communication module allowing communication with the financial data network 150.

In one embodiment, the access point is accessed by the merchant or access point is accessed through an access point available at the merchant's device (eg, a POS terminal). In this embodiment, the merchant may receive a cash payment from the user and provide payment verification to the financial data network. The merchant may use one of the above-described customer access means to enter transaction-related information and confirm the purchase. For example, the mobile phone supplier may use the system to offer the customer immediate transactions to purchase prepaid time in the mobile phone network through its sales terminal system. The transaction is paid in cash between the merchant and the seller of the product or service. The merchant may use the system to replenish an existing service account or provide the user with a voucher as described below.

Voucher 120 is a credit with one or more service providers that represents a payment received for a product or φ ΦΦΦ · · · ·

16011 -8Service still to be performed in whole or in part. The voucher 120 need not be tangible, it can only be expressed in the electronic information credited to the user. For example, the voucher 120 may be information displayed on the screen or it may be a voice message transmitted through the loudspeaker. However, in some embodiments, the voucher 120 may be embodied in physical form as a printed ATM receipt. In one embodiment, the voucher 120 may correspond to accessing the service provider database information to route such credits. The voucher 120 may include an access code, such as an access code 121. The access code 121 may be any unique identifier that can be used to verify the voucher 120 for redemption purposes by the service provider. The access code 121 may be a number such as a conventional PIN or account number, any alphanumeric code, password, or, in some embodiments, a machine readable code (eg, a bar code) or an audible code (eg, a tone code). In one embodiment, where the access code is intended to be accessed by a conventional means of communication, such as a telephone or a mobile phone, the access code may be limited to a relatively short alphanumeric code within a range of parameters for inputting telephone keypad data. In some embodiments, the access code 121 may be only part of a number string or other service redemption protocol. For example, ATM 110 may provide both a telephone number to be dialed and an access number 121 that may be required to access purchased communication services.

The communication means 130 allows the user to redeem the voucher 120 for communication services or other products or services handled by the ATM 110. The communication means 130 is connected to the communication system 140 to provide communication services to the user of the communication means 130. The communication means 130 may include any type of communication means such as mobile • • · · · · · · · • • • mobilní mobilní mobilní mobilní

16011 -9 telephone, public telephone, two-way radio, videophone, e-mail terminal or other means of communication.

In one embodiment, the communication means 130 comprises an input means, such as a dialer, for entering an access code 121.

In one embodiment, the communication means 130 and / or the communication system 140 may include voice recognition or other processing of an audible signal (e.g., tone processing) to receive the access code 121.

The communication system 140 may be any public or proprietary communication system and may or may not be connected to a worldwide communication network. The communication system 140 receives the access code and / or the redemption request for the voucher 120 via the communication means 130 and provides the user with the desired communication services. For example, communication system 140 may allow a user to place a long distance phone call, send a message by e-mail, send a direct message to a particular terminal means, send a query to the data system, or the like. The voucher 120 may provide access to a predetermined number of communication services, such as a set time, a set number of messages, a time of unrestricted use, one or more rates to account, or any other number of usage rights, including combinations listed herein. To provide access to *

communication services in accordance with voucher 120 and to keep track of usage of voucher 120 where usage is limited, communication system 140 verifies access code 121 and uses access code 120 to access voucher description 120 as voucher data 181. In one embodiment, access code 121 provides access to the user account data 183 via the billing system 182. The voucher data 181, the billing system 182, and the billing data 183 may be maintained as part of a communication system 140 or a financial data network 150.

• · • • Φ Φ «Φ • · ♦ ·· · • · • Φ • • ΦΦ Φ · · Φ · ΦΦ ·· ΦΦ * · · ΦΦ ·· 16011 -10- Voucher data 181, billing system 182 and / or accounts data 183 can be provided third aside or as

an independent system associated with the communication system 140 and the financial data network 150.

The financial data network 150 may include various interconnected systems for providing financial services to customers, service providers and financial institutions. In one embodiment, the financial data network comprises a transaction system 160 comprising a routing system 161 and a processing system 162. The financial data network 150 may include one or more payment systems, such as a payment system 170. The payment system 170 may include a financial transaction clearing center, such as electronic account access or credit card company. The financial data network 150 may include one or more data processing servers, such as a processing server 180 for providing financial and service data, and data processing in response to queries and service requests. The processing servers may communicate with one or more data warehouses or data processing systems, such as voucher data 181, billing system 182, and billing data 183. The financial data network 150 may comprise an isolated data network such as an intranet, commercial network or other proprietary network, or Use security and access restrictive protocols in a wide

a general-purpose network such as the Internet. Transaction system 160 can contain one or more routing systems give between in the net connected resources included in the financial data network 150 or associated with it and

it may also include functional logic to provide additional processing. The transaction system 160 may also include or be connected to a data source, such as transaction data 163, to write and track transaction details for transactions passing through the transaction system 160. Routing system 161

16011 can receive and split communication data according to addressing and / or communication protocols contained in the data (eg location information of the user's bank account contained in magnetically encoded information read by an ATM) 110). Routing system 161 can 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 communications networks. Routing system 161 can route data using Internet protocols. Processing system 162 may provide logic for providing customer services through transaction system 160. Processing system 162 may include a system for evaluating service requests and routing service requests to a suitable service provider. In one embodiment, the processing system 162 may evaluate the service request and provide at least a portion of the data processing required to meet the request. For example, the processing system 162 may receive a voucher request from a particular dollar service provider with a payment to be withdrawn from a user's debit account at a particular bank. The processing system 162 may evaluate the request and determine the various functional components to be executed, collect the necessary data for each communication with another system, and arrange the delivered data to verify that the entire transaction is successfully completed. For example, the processing system 162 may send to the processing server a request for voucher information for a particular communication service provider and value, may trigger a payment transaction between the payment system 170 (e.g., a user bank) and the communication service provider, write the transaction to the transaction data 130 and successfully concluding each external transaction before reporting to the requesting system (eg ATM 110) that:

- - »V» »» »444 · 444 4 4 • 44 4 · 44 * 4

444 44 44 44 · ·

16011 -12transaction is fulfilled. One embodiment of the transaction system 160 is further described below with reference to FIG. 3.

The processing server 180 may include a database server for providing voucher data in response to requests from the transaction system 160. The processing server may include or be associated with one or more data sources, such as voucher data 181 and billing data 183. In one embodiment, the processing server 180 may access the data contained in the account data 183 via the billing system 182. The 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. The account data 183 may include one or more database entries for one or more user accounts. Each user account may contain user information such as name, billing address, type of service, and other information, or may only correspond to a reusable account number or similar identifier unrelated to the account user identity. Each account may contain a value to determine the communication services available to users through the account. This value may be set by transactions triggered by the transaction system 160 in response to a subscription to other services. This value can be set by the communication system 140 in response to the communication services used through the billing system 182.

Giant. 2a illustrates a system for purchasing goods and services over a financial data network using one or more of a variety of terminal means according to an embodiment of the invention. System 200 includes a routing system 210 and an application server 220 that acts as an intermediary between one or more service provider systems, voucher issuing systems, and terminal means such as ATMs;

4,444 · · 4 4 4 4

4 * 4 4

44 44 44

16011 -13 sales terminal systems. Routing system 210 routes data transmission between financial data networks (e.g., electronic transfer of funds to emitter 260), service provider systems, application server 220, and some terminal means (e.g., ATM 241 and POS terminal 243). Application Server 220 provides at least some logic, communication protocols, data storage, and / or transaction management to enable various finance and banking related services using financial data and other information routed by routing system 210. In addition to one or more applications for purchasing products or services For example, the application server 220 may include various modular applications for providing a variety of banking services, such as savings account, current account, credit card, broker account access and management, automatic transaction management, event reporting, or other similar services. The system 200 may include a plurality of interface servers 23Q, such as an ATM server 231, a POS system 232, an SMS server 233, and a web server 234 after allowing access to the features of the application server 220 through a variety of terminal means, including ATMs. Each type of interface server 230 allows the user to access application server 220 services through a variety of endpoints such as personal digital assistants (PDAs), mobile phones, personal computers, laptops, telephones, facsimile machines, vendor terminal systems and other devices as well as ATMs. . Each of the exemplary servers 230 supports a different communication protocol and interface standard to allow one or more types of endpoints or terminal means to communicate with a plurality of financial institutions. In one embodiment, the system 200 may include a cryptographic system 221 to allow access to financial services.

16011-14 data networks requiring DES encrypted PIN blocks from terminal means not equipped with DES data encryption. In one embodiment, system 200 may include card register data sources 222 to allow access to financial data networks requiring magnetic card information from terminal means not equipped with magnetic card readers. Service provider systems 250 may be coupled 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 warehouses, such as voucher data source 254 and account data source 255. Emitter 260 (i.e., ATM, debit and credit card issuers) may provide electronic payment for products or services purchased through System 200.

For routing communications, as described above, routing system 210 includes switching and monitoring hardware and software for routing communications comprising transporting electronic financial data to a predetermined destination (financial institution) according to communication protocols corresponding to the financial institution. Routing system 210 further comprises a central computer for routing electronic financial data movement between various otherwise incompatible communication networks and financial data systems. Routing system 210 may also include a plurality of communication channels and network connections for communicating electronic financial data using EFT standards, Internet based standards, proprietary standards, and other standards for

16011

-15-- · · · 4 4 4 4 4 »· 4 4 44 44 4 4 44 44 44

444 ·· · 4 «4 44 4 4 secure data transmission. Routing system communication channels 210 may also serve to interconnect various specialized and / or separate financial endpoints, such as ATMs 241 and point of sale terminal systems 243.

To perform the functions described above, routing system 210 preferably comprises an AS / 400 platform using OS / 400 and ITM 2.2 software to access accounts and associated arrangements. Alternative platforms may include Windows NT, Linux, Unix, and similar platforms.

Application Server 220 includes one or more servers to host a variety of financial and banking services applications, as well as services for purchasing services and products. Such financial and banking services applications may include any services relating to personalized banking, finance, money management, payment transactions or investments. The application server 220 further includes a platform for running a variety of financial and banking applications. Application Server 220 utilizes a modular application design supporting standard interconnect objects to provide a flexible, easily extensible, and largely hardware-independent system for providing financial services applications. For example, the application server 220 may be an enterprise application server running a plurality of applications comprised of a plurality of removable application modules (eg, Entrprise JavaBeans). One such removable application module may be used to allow application server 220 to offer financial and banking services to respond to service requests from interface server 230. Another may allow application server 220 to initiate transactions (e.g., transmissions and queries) with external financial network systems or systems. service providers.

16011

-16 W V V h • 9 «9 999 * 9 9 ······« # · ·

9 ·· * 9 9 9 9999

9 * 9 9 * 9 · 9 99 99

The application server 220 may be connected and communicate with the cryptographic system 221 to enable data encryption to DES-compatible PIN blocks compatible with ATM network data encryption standards. For example, the cryptographic system 221 may include hardware for receiving a PIN from the application server 220, encrypting it using DES encryption, and returning the encrypted PIN block to the application server 220. The cryptographic system may include a security closure that destroys the cryptographic system if broken. Hardware encryption conversion prevents a decrypted PIN from ever being available in electronic or visible form in which it could be misappropriated. Providing DES encryption may allow a user to access functions such as a shopping system and here an ATM data network similar to ATM functions, described in a manner using a device not equipped with DES encryption

The application server 220 may be connected and communicate with a card register data source 222 to provide access to magnetic card based financial services without a magnetic card reader. In one embodiment, the card registry data source 222 includes a magnetic card data store, such as Track II data, for one or more users. Data may be accessed using an account number, PIN, password, or other means of user identification. The card data may then be presented, together with the transaction request, to the emitter requesting the magnetic card data to enable the card-based transactions. The card register data source 222 allows the user access to ATM functions such as a shopping system and method described herein using a financial data network from a device not equipped with a magnetic card reader. In one embodiment, the user card data may be associated with the user identification in such a way as to provide automatic transactions using the card data. For example, data

16011

-17 * · · * ··· · I t II * I «9 · 9 · 9 · 99 * 99 •« 9 * · ♦ 9 «· '» user's account for his / her its credit card may be associated with the user's mobile phone (e.g., telephone number, subscriber number, or telephone identifier). An application can be defined that receives a signal from a mobile phone indicating a purchase transaction request. The application server 220 may then execute the purchase transaction by identifying the mobile phone, accessing the card data contained in the card registry data source 222, and routing the corresponding transactions to the service provider providing the purchased goods or services and the credit card issuer. In one embodiment, such a transaction can be triggered by a simple input from a mobile phone, such as a one-touch dial function, a dedicated hardware button, a menu selection, or other method. In one embodiment, the card registry data source 222 may include various other information unique to the user such that it acts as a personal purse of the user. This additional user information may include other bank account information, public account information, merchant account preference information, telephone numbers and other contact information and other personal information (e.g., health care provider and account number, car club and account number, program providers by airline tickets and account numbers, etc.

The interface server 230 associated with the application server 220 provides multiple user interfaces to access one or more financial and banking services applications hosted on the application server 220. The interface server 230 may include a plurality of servers with a plurality of interfaces for one or more communication protocols and intended endpoints. For example, interface server 230 may include a Short Message Service (SMS) server, a Wireless Application Protocol (WAP) server, a Web server, an ATM server, a POS system server, an automatic telephone server, and the like. SMS

16011

-18 * ·

The 444 server provides one or more short text messages for interactive exchange of information with a user and is available to a user using any SMS-enabled means such as a mobile phone, alphanumeric pager or other wireless device with limited display capabilities. The WAP server may provide one or more connection pages, such as WML, XML pages, for interactive information exchange with a user and is accessible to a user using any WAP-enabled means such as a mobile phone, pager, bidirectional radio, smart phone, communicator and 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. The security protocols used through the interface server 230 and the attached access points may include SSL, WSL, SET, PKI or any other encryption, digital signature or other security system.

Service provider systems 250 may include one or more computer systems supported by 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 that maintains a system for distributing products or services, such as a telecommunications company maintaining a communications network for selling communications services. Data warehouses 254 and 255 may include any number of data warehouses containing voucher data, billing data or information related to voucher tracking and account use. The data stores 254 and 255 may be localized data sources, such as a database or group of databases, or may be a distributed resource, such as a batch of localizable files distributed over a network. The voucher data store 254 may include voucher information, including access codes, user rights, information about * * • 444

16011 -19 tracking usage and other information to verify and monitor voucher usage. The account data store 155 may include account information including access codes, user rights, usage tracking information, account or user identification (e.g., account number), and other information for verifying and monitoring account usage. The processing server 253 provides an interface for communications, transactions, and data requests routed through the routing system 210 to the data warehouses 254 and 255. The processing server 253 may include security authentication, query logs, and transaction maintenance of the voucher and / or account data. Service providers 251 and 252 may include similar protocols for interacting with data stored in data warehouses 254 and 255 in response to user amortization of products or services or other administrative functions. Alternatively, the service provider's communications may also be routed through a processing server 253 or a routing system 210 (alternative configurations not shown). In another embodiment (also not shown), voucher data storages 254 and / or billing data storages 255 can be maintained directly by the application server 220, and service providers can route communications, transactions, and queries through the data access routing system 210. In yet another embodiment (also not shown), the voucher data store 254 may be maintained in the application server 220 including voucher numbers and values for issuing vouchers to customers. The service provider 251 maintains a separate voucher data warehouse 254 including voucher verification and data usage. The service provider 251 provides batches of active vouchers to application server 220 by loading or otherwise transmitting data, but requires no further access to the voucher data delivered. Application Server 220 maintains and sells voucher batches without the need for further communication with the provider

16011

• 4 • 4 4 4 4 • 4 4 44 4 4 · 44 4 4  4

251 services. This method of maintaining a batch of active bills presents increased security risks and may require subscription of the bills by the application server maintainer 220 or some other billing process.

System 200 may include endpoints or terminal means, such as ATMs 241 242 and POS terminals 243 and 244. ATM 241 may be a stand-alone ATM that includes its own application and interface software and is capable of exchanging data with one or more financials. ATM 242 may be a small client ATM that uses at least partially the application server application software 220 and the ATM server interface software 231. The terminal sales system 243 may be a retail terminal integrated with its own application and interface software and capable of exchanging data with one or more financial data networks via routing system 210. The terminal sales system 244 may be a small client terminal sales system that utilizes at least partially the application software of the application server 220 and the interface software of the sales terminal server 232. Other small client terminal resources such as web and wireless web resources are also possible in conjunction with a compatible interface server.

FIG. 2b illustrates a modular system 260 for processing user service requests according to an embodiment of the invention. The modular system 260 may be used by an application server, such as the application server 220 in Figure 2a, to process user service requests for the purchase of goods and services. The modular system 260 includes application objects 270, such as application objects 270a and 270b. Application objects 270a and 270b are used as standard input

16011

-21-- - w w «4 4 • * 4 4 444 4 4 4 • 444 * 4,444 4 4

4 · 4 4 4 4444

444 44 44 4 «44 44 service request paths, such as from users 201 and 202. Application objects 270a and 270b create a transaction 171, such as transactions 271a and 271b, which describe the actions to be performed. Router 272 evaluates transactions 271a and 271b and routes them to the respective provider 272, such as providers 273a, 273b and 273c. Providers 273a, 273b and 273c include operations to perform transactions 271a and 271b. In some cases, the provider, such as provider 273c, may issue a service request 274 to access an external resource, such as financial data maintained by the financial service provider. Providers 273a, 273b and 273c can either * route the transaction to another provider or can return response 275, such as responses 275a and 275b to application objects 270a and 270b.

Application objects 270 provide standard entry paths for user service requests 261 and 262 and trigger transactions 271 in the modular system 260. Application objects 270 represent individual actions to which the modular system 260 may be prompted. Some examples of application objects 270 may include a login object, an account balance object, a voucher purchase object, a voucher account balance object, an account replenishment object, and other objects for providing various financial administration, paying invoices, and other services. In one embodiment, each application object 270 is a non-state enterprise JavaBean (EJB) and is accessible to a user through a JNDI interface (not shown). Each application object 270 creates a transaction 220 that describes the action to be performed and contains the user information necessary to trigger the action. For example, a login object would be used to create a login transaction containing basic information, such as a user identifier (e.g., user name, credit card number, ATM card number, etc.) and PIN. She could • · ··

16011 -22The voucher survey transaction is used to create a voucher transaction containing the value of the voucher to be purchased and the payment method for the purchase (possibly including payment account numbers and PIN for security purposes). Each application object 270 may also call a router 272 to determine the destination provider 273 for the processing transaction 271. In one embodiment, the application object 270 forwards the transaction 271 to the router 272, where the router 272 evaluates the transaction 271 and forwards it to the selected provider 273. transaction 271, but actually passes the transaction 271 to the selected provider 273 identified by the router 272 to the application object 270. Each application object 270 may also receive a response 275 from the providers 273 and pass it back to the user. Each application object 270 may also be able to call provider 273 to cancel, resume, or modify transaction 271 in response to response 275, new user input, or other system conditions. Transactions 271, such as transactions 271a and 271b, may include the data required by providers 273 to perform the function of application object 270. Transactions 271 may include basic transaction information such as unique identifier, timestamp, status tag and originator and target (or list of providers 273 to execute the transaction ). Any amount of other transaction-specific information, such as a data item, can be added to the transaction. In one embodiment, the data item includes one or more key-value pairs providing a description of the data, such as an account number or PIN, and the data itself such as Account # 012345, PIN 9876. The data may contain a wide variety of data and file types and formats flags, strings, data files, etc. and can be of any size. Some exemplary data objects may include a canceled check graphic file, a voice recognition sample audio file, or a new transaction table in an account. The data can also be • 9 · 9 · 9 · 9 · 9 · 9 · 9 · 9 · 9 containing the data returned in 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 provider 273. In another embodiment, each transaction 271 includes a complete transaction history record. Each transaction 271 can be automatically stored in a database and can be archived for later retrieval.

Router 272 designates provider 273 to handle transaction 271. Router 272 uses a combination of transaction details and / or system information to determine the optimal target provider 273. For example, router 272 may route transaction data by account number, transaction amount, or user name. Multiple routers can be used by the modular system 260 to perform such routing. A single transaction may be routed multiple times during processing, and router 272 may be used by provider 273 as well as application objects 270. Router 272 includes a routing table in an extensible markup language (XML) document format that contains a list of conditions and / or rules according to which transactions 271 may be routed to a particular provider, such as provider 273a, 273b or 273c.

Providers 273a, 273b and 273c utilize modules that include logic to perform at least a portion of the functions performed by one or more application objects 27Q. Such providers 273 use data stored during transactions 271 to perform such functions. Providers 273 can relay the application object 270 that created the transaction 271, or they can relay the transaction to another provider 273 with or without consulting router 272. Providers 273 perform their functions locally using transaction data and local sources and system information, and relay the response 260 ·

Some providers 273, such as provider 273, may also perform their functions locally using transaction data and local resources and system information, but their functions may only be part of the total functionality required by application object 270. 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 part of the data contained in transaction 271 to service 274 and may then receive response data from service 274 to formulate a response 275 for handover to application object 270. In one embodiment, multiple such providers 273. In another embodiment, providers 273 may pursue the same target through different channels. For example, multiple providers 273 may perform multiple services to obtain the fastest 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 or communication protocol service, may be used to exchange data with an external source such as a financial data network, a bank, a cryptographic system, or a data warehouse. Each service can be customized to the communication protocols and data requirements of specific external sources. Service 274 can both send and receive data. The received data may be delivered to the provider 273 who initiated the service 274 added to the transaction and / or returned to the application object in response.

The responses 275a and 275b may include a response or decision to the transaction 271 generated by the application object 270.

• ♦ »

The responses 275a and 275b may each contain the information required by the application object 270, or may explain why the request cannot be met. In one embodiment, responses 275a and 275b may each include a value to indicate whether or not the transaction was successful; if necessary, a mark, as a reference to the present transaction, and a plurality of additional data items (as described above with respect to transaction 271) may be used as part of the subsequent transaction. The information returned in responses 275a and 275b may be returned in whole or in part to the user who caused the use of application objects 270 and / or may be the basis for further transactions invoked through the same or another application object.

Giant. 3 illustrates a transaction system 300 for taking care of a plurality of financial customers and information services through a variety of endpoints 310 using financial data, content, and transaction functions provided by remote service providers such as a provisioning service provider 320 and a financial service provider 330. The service may be provided to various service endpoints 310 from a plurality of interfaces supporting one or more interconnection standards and communication protocols. Some exemplary service endpoints 310 may include a personal digital assistant 311, mobile phone 312, personal computer 313, laptop computer 314, telephone 315, fax machine 316, ATM 317, or terminal sales system 318. The integrated transaction management system 300 communicates with the service endpoints. 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 their corresponding data transmission protocols. Services performed by transaction system 300 may use information collected from any one or more remote service providers.

16011 -26or exchanged with these providers. The transaction system 300 may communicate with remote service providers using any secure communication or financial data network.

The transaction system 300 may further comprise various functional modules for providing financial and other information services according to an embodiment of the invention. Each function module may comprise a combination of software and / or hardware for performing tasks or a set of tasks. For example, the data processor, memory, and instruction file (i.e., computer code) may represent everything that is needed for such a function module to perform the tasks necessary for a given embodiment of each function module. More generally, however, multiple input and output means, short and long term storage systems, computer code layers (ie, operating system, application software, etc.), communication means, and multiple processors may be used for such a functional module. In addition, multiple function modules can share the same hardware and parts of the software library with each other. In some cases, the functional module may include one or more other such functional models. As will be appreciated by those skilled in the art, the functional modules described herein can be made in a large number of equivalent combinations of code objects and hardware. The combinations represented by the functional modules described herein are conceptual combinations and should not be construed as limiting constructions for multiple combinations of hardware and software capable of performing the functions of the functional modules.

As shown in Fig. 3, the transaction system 300 includes an interface system 340, an application system 350, an inter-network system 360, and a cryptographic system 370. The interface system 340 includes one or more functional modules, each providing one or more user interfaces accessible through a variety of service terminal • ···

Application system 350 includes one or more functional modules, each providing functional processing capability for one or more customer applications, including formulating data queries and transaction requests to the provisioning service provider 320 and the financial service provider 330. Inter-network system 360 includes one or more functional modules for routing connections between multiple heterogeneous networks or communication systems using different communications, data transmission, and encryption protocols. Cryptographic system 370 includes one or more functional modules for encrypting and decrypting data according to one or more security encryption standards.

Interconnection system 340 includes one or more functional modules for submitting and exchanging information via retail client endpoints or terminal means. Interconnection system 340 may access one or more functional modules providing customer applications in application system 350 and may provide an interface between such application system 350 and the customer, as appropriate for variable bandwidths, memory capacities, processing capabilities, input and navigation methods, common use and an environment of a plurality of service end points 310 that can be utilized by the customer. For example, an SMS-compatible interface may be limited to 160 text characters for sending and receiving information. The WAP resource provides greater versatility, and therefore the interfaces used in conjunction with such a WAP resource may include graphics and other data, but may require it to be designed for the limited bandwidth and memory of most WAP resources. The network-based means may have any range of capacities greatly dependent on the type of end device and the bandwidth, memory and input capacities of the intended end device. Even within the scope of a particular protocol, multiple 999 options may be preferentially offered

16011

-289 9 99 99 99 99 9 «options depending on the properties of the palette of possible end devices and users. Interconnection system 340 may allow the transaction system 300 to support traditional ATM functions through a variety of service endpoints 310 and allow the purchase of goods and services through voucher and billing applications at the same service endpoints. As shown in FIG. 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 interface module 335 of a sales terminal system. Other interfaces may also be supported by alternative embodiments such as interfaces supporting other wireless protocols and communications networks, voice interfaces for telephone access, proprietary and LAN (local area network) interfaces for securely restricted access to special services (eg for service providers and transactions and services). system administrators) and additional interfaces to support new and specialized capacities of future network communication resources.

For example, in one embodiment, a telephone or other portable communication means enabling SMS and WAP services may be used to supplement its user prepaid account. In one embodiment, the SMS and WAP enabled phone may be able to access the phone number or URL (corresponding to the respective switching server) for the make-up services even if the user's prepaid account has been exhausted and the phone can no longer be used for other communications. In one embodiment, the user may take the SMS and WAP enabled telephone to the merchant or service provider, and the merchant or service provider may receive payment for the service and immediately provide a message or code containing an additional amount and payment verification for input by the user's telephone or means.

16011

-29 <* »» »» »» »» <<<<<<<<<<<<<<<<<<<<

Application system 350 includes one or more modules to provide functional processing to one or more customers, including formulating data queries and transaction requests to facilitate the purchase of prepaid goods and services. Application System 350 provides a variety of customer services according to a modular architecture that supports and versatility for accessing modules serving multiple service end points 310. Application System 350 utilizes data provided by multiple external service providers as well as an internal system and internal data sources. An individual application transaction may simultaneously or sequentially access or exchange data from more than one service provider system. The application system 350 can formulate queries and issue data exchange requests based on multiple protocols depending on the target system and the information sought. The application system 350 may use a combination of a standard query language (SQL) and an alternative data exchange of transaction logs, depending on the compatibility of the service provider system. To facilitate the purchase of prepaid goods and services, one embodiment of the invention includes a voucher module 351, a billing module 352 and a message module 353 and a payment module 354. Each application module may include a variety of transaction modules for performing a variety of functions that may be included in the application module. The possibilities of add-on application modules and the alternative arrangement of application modules and individual transaction modules are endless.

The voucher module 351 provides maintenance and access to voucher numbers stored in one or more voucher data sources. The voucher data sources may be localized sources or may be located remote. Voucher Module 351 provides transactions for access • 4 · 4 4 444 • 444444444 4 • 4 * 4444 4444

4444 · 44 · 4 44

16011 -30 Available voucher numbers from voucher database or creating new voucher numbers to be added to voucher database. The voucher module 351 may also be capable of returning or deleting an unused voucher number if the purchase transaction has not been completed. The voucher module may comprise a voucher module 351a and a return voucher module 351b. In one embodiment, the voucher module 351a is a provider object called a voucher application object in response to a user's request to purchase a voucher. The voucher module 351a uses query services to query the voucher data source for a voucher number corresponding to a particular voucher value. The service response contains a flag indicating the success or failure of the search and the data corresponding to the searched voucher number. In one embodiment, the return voucher module 351b is a provider object called a voucher application object in response to a transaction session interruption, a declined payment attempt, or other basis for canceling a purchase transaction. The return voucher module 351b uses the interrogation service to communicate to the voucher data source to return the enclosed voucher number to the ready state. The service response includes a flag indicating the success or failure of the return attempt.

The account module 352 provides the ability to link to existing user accounts stored in one or more account data sources. The accounting data sources may be stored locally or may be remotely maintained by the provisioning service provider. The account module 352 may provide verification of the existence of a particular subscription account, verification that the subscription account is eligible to replenish, locate the present value of the subscription account, replenish the subscription account, and provide other account maintenance functions. In one embodiment, the accounting module 352 may also allow for the provision of an accounting module (*) (* ··················)

16011 -31 to the user to open a new subscription account through the transaction system 300. The account module 352 may include an authentication account module 352a and a recharge account module 352b. In one embodiment, the authentication account module 352a is the provider object called by the account replenishment application object in response to the user request to replenish the subscription account. The authentication account module 352a may use the polling service to verify that the account number submitted by the user corresponds to the active account in the account data source. The service response may include a code indicating the success or failure of the authentication, which may indicate an explanation of the failed authentication attempt. In one embodiment, the refill account module 352b is a provider object called by the refill application in response to a successful payment transaction based on the user's offered payment method (e.g., clearing an electronic funds transfer or credit card account). The refill account module 352b uses the polling service to notify the account data source to increase the value in the specified subscription account to a certain value. The service information includes a flag indicating the success or failure of the make-up attempt.

Message module 353 includes monitoring and writing transactions for administrative and billing purposes. Message module 353 may include message data sources in which a record of each transaction, such as a voucher sales transaction or an account replenishment transaction, is recorded. The transaction record may contain transaction details such as transaction time, transaction value, transaction session time, business end from which the transaction was invoked, and so on.

The message data source may be used to provide transaction summaries to service providers for transaction validation and overall account management. The message data source may be φ · · · «· · · · · · · · · ·

16011 -32 also used to track transactions for a particular service provider to determine payments for the use of transaction system 300 services. Message module 353 may be used for other data mining activities such as marketing analysis and may be linked to user information to provide targeted marketing data.

Payment module 354 provides electronic payment of the value of the purchased product or service. Payment module 354 may allow the user to pay for products and services using debit cards, credit cards, electronic money and any other electronic payment method as known in the art. In a preferred embodiment, the payment is made through ATM protocols for credit card and debit card transactions using a magnetic card containing account information and a user-supplied PIN. In an alternative embodiment, the payment is provided by a service end device not equipped with a magnetic card reader using a track II data register pre-registered by the user. Sales terminal systems protocols, Internet payment protocols, proprietary payment protocols, and other protocols can be used.

In one embodiment, smart or "smart cards" may be used to provide payment information, including user authentication,

In one embodiment, electrical money may be used, such as a value stored in a centrally managed database (eg, an "electronic wallet") or stored in a smart card.

Routing system 360 may include one or more modules for routing communications between two or more of a variety of disparate networks or communication systems using different communication, data transmission, and encryption protocols. For example, routing system 360 may include an EFT protocol module, an Internet protocol module, · 4

16011

-33 • 444 • 4 4 4 4

49 proprietary switching protocol module or other various communication protocols. In its operation, routing system 360 can receive transactions from an ATM, a financial institution, another EFT gateway, a terminal sales terminal system, or an application system

350 (eg, purchase transactions through an alternative service endpoint). After receiving the transaction, the routing system

The 360 urei issuer contained using a bank identification number (BIN) in the received data such as Track II data from the user's debit card. If the BIN belongs to the local bank, the transaction will be routed to the local bank for authorization. If the BIN does not belong to the local bank, a routing decision will be issued depending on the BIN card number. This routing decision will be made by comparing the BIN with the routing tables maintained in the routing system 360. When the BIN or some corresponding BIN digits are found, the transaction is routed to the corresponding other gateway or financial institution for authorization. If the BIN is not found in the routing tables then the default gateway will be used to authorize the transaction. In one embodiment, a message may be received from the application server in the proprietary format and converted to a format corresponding to the issuing endpoint after the routing decision is made. Authorization will be received from the authorizing issuer and the transaction will be confirmed or denied based on the issuer's response. Routing system 360 may also perform balancing and settlement with the authorizing issuer as well as the acquiring service provider.

As further illustrated in FIG. 3, cryptographic system 370 may include one or more data encryption and decryption modules according to one or more encryption standards. Cryptographic system 370 further includes cryptographic hardware and software substantially as described above for cryptographic system 221 in Figure 2a. In one embodiment, it may be cryptographic

16011

-34 • 9 · 4 t • 9 9 9 9 • 99999 999 9 9

999 9999 9 9 9 9 • 9 «99 99 99 99 99 System 370 may include protocols for handling one or more encryption, certificate, digital description, and other security systems, individually or in combination. These protocols may include compliance with protocols such as EFT DES encryption protocols, credit card SET protocols, or smart or smart card authentication protocols or other industrial or proprietary systems. The cryptographic system 370 may be adapted to additional security systems such as developed and adapted for various financial data networks.

The ISP module 320 may be any system for providing goods or services and receiving payments from the user of those goods and services through a transaction system 300. ISPs may include communications service providers, Internet service providers, retail goods and service providers, vending machine operators , or other providers of goods and services. Each execution service provider module 320 may include a system for product distribution, billing and management. In one embodiment, each execution service provider maintains one or more computer systems for product distribution, billing and management supervision, and the transaction system 300 communicates with at least a portion of the computer system. The execution service provider module 320 may provide voucher and / or billing data for use by the transaction system in voucher retrieval and account replenishment. The implementation service provider module 320 may also include a system for receiving payments for goods or services from a transaction system 300, a financial institution (e.g., through a financial service provider module 330), or other resources. The execution service provider module 320 may include a processing application module 321, a charging system

16011

-35 · * 35 35 35 35 35 35 35 35 35 35 35 35 35 35 35 35 35 35 35

322, service system 323, account data source 324, and voucher data source 325.

The processing application module 321 may provide an interface between the account data source 325 and various systems that use the data, such as a transaction system 300, a billing system, 322, a service system 323, and other systems (e.g., service provider management, customer service, marketing etc.). .). In one embodiment, the processing application module 321 may include protocols for integrating existing execution service provider systems (e.g., existing accounting data, data management systems, billing systems, etc.) with a transaction system 300. The processing application module 321 may include an accounting interrogator module 321a, a voucher module. a query module 321b, an account maintenance module 321c, and a voucher maintenance module 321d. The account interrogator module 321a may allow processing application module 321 to receive and execute account data queries (e.g., account validation queries, account replenishment requests, etc.) and transaction system 300. Voucher module 321b may allow processing application module 321 to receive and execute voucher data queries (e.g., voucher issue queries, returned voucher queries, etc.) from the transaction system 300. The account maintenance module 321c and the voucher maintenance module 321d may allow the processing application module 321 to receive and perform one or more maintenance actions for the account and voucher transactions. Maintenance actions may include additional queries, data mining, data manipulation, and other actions to supervise voucher data source 325 and account data source 324. Maintenance actions may also include access to remote data or transaction capacities in other service provider systems (eg, a billing system). 322).

16011

-36 ϊ ** ** ** ** ** ** ** ** 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36

The billing system 322 may include execution service provider systems for monitoring payments received and appropriate services for prepaid accounts and / or vouchers. The charging system 322 may also include implementing service provider systems for monitoring, submitting and settling appropriate payments for unpaid accounts and / or vouchers or for prepaid accounts and / or vouchers originally paid using credit or electronic money and requiring simultaneous payment from a third party (e.g. credit card company, bank, or other financial services provider). The billing system 322 may include a pre-billing system designed to control customer transactions other than the sale of goods and services through the transaction system 300.

The service system 323 may include an implementation service provider system for providing goods and services purchased using prepaid vouchers or accounts. Service system 323 may include authorization to distribute or access goods and services, track usage of the goods and services provided, or terminate access based on the use of the prepaid value of the voucher or account. The service system 323 may include a communication system for providing communication services to the user. In one embodiment, the serving system 323 is a mobile telephone network, and the mobile communication services are provided to the user in accordance with the value and conditions under which the prepaid voucher or bill was purchased.

In one embodiment, the service system 323 evaluates the voucher data or accounting data in the account data source 324 or voucher data source 325 corresponding to the user-supplied account or voucher identification prior to providing the goods or services. In one embodiment, the service system 323 may monitor the use of the account and / or the voucher to identify when the value remaining on the prepaid account is low. Servicing

16011

-37 system 323 can system 323 can provide the user with reports via one or more service points. For example, the operator system

323 may trigger an automatic messaging service (eg, telephone, SMS, voicemail, e-mail, etc.) to alert the user that the account or voucher is near exhaustion. In one embodiment, the service terminal means may include a hardware (eg, LED) or software indicator (eg, a display icon) to alert the user when the account or voucher status is low. In one embodiment, alert messages and replenishment indicators may be provided through the application system 35Q.

The account data source 324 and the voucher data source 325 comprise one or more account or voucher databases providing account or voucher identification and corresponding subscription or service value goods. Account data source

324 may be substantially as described above for the account data 183 in FIG. 1 and the account data 255 in FIG. 2a. The voucher data source 325 may be substantially as described above for voucher data 181 in Fig. 1 and voucher data 254 in Fig. 2a.

Giant. 4 illustrates a method of using a service end device such as an ATM to access a transaction system and a financial data network for a voucher based purchase of goods and services. In step 410, the user accesses a service endpoint such as an ATM, a POS terminal, a personal computer, a mobile phone, and the like. For example, the user can access an ATM or POS terminal and pass a magnetic card such as a debit or credit card to access the system's service functions. . Access to the service endpoint may include providing user identification (step 411). For example, stretching an iGoii -38 magnetic card may provide some user identification such as an account number and a financial service provider identification. For security reasons, the system may require additional identification such as a PIN, password, retinal image capture, or other means to verify that the cardholder is an authorized user. In step 420, the user may select a product, such as goods or services for purchase. A selection can contain multiple interactive steps. The user can first select from the menu of services (eg balance inquiry, pickup, balance transfer, purchase of goods or services, etc.). The user can then select from a collection of products available for purchase via the system (eg, mobile communications services, Internet services, beverages, etc.). In one embodiment, a customized customer menu of shopping offers may be offered based on the customer identity, the location of the service endpoint, the time of day, or other factors. Once a product is selected for purchase, a value can be selected for the product available in the value collection (e.g., mobile minutes, dollar amount for long distance service, etc.) (step

421). The value selection can be selected from the menu menus or can allow the value to be entered. The service provider from the list of usable service providers can also be selected (step

422). In step 430, the user provides payment information. Providing payment information may include providing an account identification (step 431). For example, a user may be provided with a list of accounts associated with the card used to access the system (e.g., checks, savings, credit, etc.). In one embodiment, the payment information is automatically provided by accessing the system with a card associated with a particular account. In step 440, the user received the voucher. The voucher may be received as a printout through a service endpoint printer or other physical voucher delivery means. The voucher can also be issued only as an access ticket.

16011 -39Code displayed on the service terminal display. In step 450, the user redeems the voucher through a service provider such as a communications company or supplier. In one embodiment, the user uses a communication means, such as a mobile phone, to access the communication network and enters a voucher code to access the subscription services corresponding to the voucher. In an alternative embodiment, the user presents the voucher or enters the voucher number into the automated system at the location that issues the purchased goods.

Giant. 5 illustrates a method of providing vouchers redeemable for goods and services through a transaction system associated with a financial data network. In step 510, the transaction system receives a transaction request to purchase goods or services. For example, a transaction system may receive a transaction message containing payment account data, a PIN, the identification of the provider of the goods or services, the value of the goods or services, and the origin address (e.g., the ATM where the transaction was initiated). In step 520, the transaction system locates the appropriate voucher for the goods or service, provider and value. The transaction system may access the appropriate voucher database to locate the voucher marked valid (step 521). Alternatively, a new voucher can 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 on the transaction value at the financial service provider, such as through an electronic money transfer network. The transaction system may first ask the appropriate financial service provider on the account through the routing system. If the query returns data indicating an authorized account with sufficient available margin or credit, the transaction system may • • «··

16011 -40Send a second transaction to execute the appropriate debit or credit transaction for the financial institution. Upon successful completion of the payment transaction, the transaction system returns the voucher information to the service end device that initiated the transaction (step 540).

Giant. 6 illustrates a method of redeeming vouchers for goods and services provided through a transaction system associated with a financial data network. At step 610, the execution service provider, such as the communications service provider or the vendor, receives a product request, such as a good or service. The protocol for receiving a product request may be defined by each service provider and may be provided to the user with instructions provided at the time the voucher is purchased or at the location or means through which the product request was made. For example, a telephone service provider may provide a duty-free number that a user calls to retrieve a service request, a mobile phone service provider may preprogram a protocol to a user's mobile phone, or a vendor may provide payroll systems (such as vending machines) with a preprogrammed protocol. In step 620, the execution service provider receives the voucher data as a voucher access code. In step 630, the provisioning service provider verifies the voucher access number against the contents of the voucher data source. For example, the voucher entry is located using the voucher access number and the entry is checked for compatibility between the requested services and the remaining unused value. In step 640, the execution service provider provides the desired product according to the compatibility and value of the verified voucher. The products may be provided in such a way as to prevent any remaining value on the voucher from being exceeded, such as by returning a usable quantity of the product to the product dispensing system.

φ · · · · · ·

16011 -41 In step 650, the use of the voucher is recorded in the voucher record for the voucher used. The voucher may be exhausted or may have a residual value.

Giant. 7 shows the steps of a method of using a transaction system for an account based purchase of goods or services through a financial data network. In step 710, the user accesses the service end device, for example, by means of an access card (e.g., a debit card, credit card or the like) and a PIN. In one embodiment, the serving end means may be a personal communication means, and the transaction system may comprise a virtual card register and / or a cryptographic system for enabling a transaction without using an access card.

In step 720, the user selects a pre-existing account on which to add a value. In one embodiment, a user is offered a menu of user subscription accounts made available for replenishment through the transaction system. In step 730, the user selects the amount to replenish.

In step 740, the user provides payment information. In one embodiment, a standard or user-defined automated transaction may be available comprising steps 710, 720 and / or 730 based on a simple selection by the serving end device. For example, an ATM or personal means of communication may offer a quick charge capability that utilizes a predetermined account choice, payment method, and adds value. In step 750, the user receives confirmation of successful account replenishment and payment assurance from the transaction system. In step 760, the user gains access to goods or services that are available through a prepaid account, for example, by providing the user's account number to a seller or by using a communication means associated with a particular account number.

• · «*

16011 -42Fig. 8 shows the steps of a method of replenishing an account with a value redeemable for goods and services through a transaction system associated with a financial data network. In step 810, the transaction system receives a transaction recharge request.

In step 820, the transaction system verifies the existence, authorization, and availability of the replenishment account through the transaction system by querying the source of the account data. In step 830, the transaction system verifies the user's payment information via the financial data network at the financial service provider. In an alternative embodiment, the transaction system verifies that the user's payment has been received at remote locations (such as retail output). For example, a user may appear at the retail outlet, offer a cash payment (or other payment method accepted by the outlet), and the retail outlet may offer the user a transaction request with the appropriate vendor code indicating that the payment has been received. In step 840, the transaction system updates the user's account in accordance with the sold value. In step 850, the transaction system forwards the user a confirmation of a successful replenishment transaction.

Fig. 9 illustrates a method of providing value-based goods and services in an account replenished through a transaction system connected to a financial data network.

In step 910, the execution service provider received a product request for goods for services according to a predetermined product request protocol. In step 920, the provisioning service provider receives an account identification corresponding to the user's replenished subscription account. In step 930, the execution service provider confirms the existence, authorization, and available value in the account by accessing the account data source. In step 940, the goods or services are provided in accordance with the available value in the account. In step 950, the account entry is updated

16011 -43 to reflect the use of the account and any associated impairment.

The present invention has been described in connection with preferred embodiments. These embodiments are intended for illustration only. Those skilled in the art will readily appreciate that these preferred embodiments can be modified without departing from the scope of the invention as defined herein.

Claims (27)

PATENT CLAIMS A system for purchasing prepaid communication services using a financial data network, comprising an account data source comprising account data for a user's prepaid account; a transaction system in conjunction with an account data source for modifying an account data source in response to a user's transaction request by a service end device; a communication system in connection with the account data source for modifying the account data source in response to the use of communication services associated with the user's prepaid account, and a payment system associated with the transaction system for performing a payment clearing transaction based on filling the user's transaction request. System according to claim 1, characterized in that the service terminal means is an ATM or a point of sale system. The system of claim 1, further comprising a routing system for the financial data network, and wherein the user service request is routed to the routing system by the serving end device. The system of claim 1, further comprising an application server and the user request for service being routed to the application server by the serving end means. The system of claim 1, further comprising a card register data source and a transaction system 16011 -45 Performs automated transactions using card data obtained from the card registry data source. The system of claim 5, wherein the service end means comprises a selector for executing automated transactions using card data obtained from a card register data source. The system of claim 6, wherein the selector is a hardware selector. The system of claim 1, further comprising a cryptographic system, and wherein at least a portion of the user's service request is routed by the cryptographic system and encrypted to meet the encryption standards of the financial data network. The system of claim 1, wherein the service end means is a portable communication means. The system of claim 1, wherein the service end means comprises an indicator to show when the user's prepaid account has fallen below a predetermined balance. 11. A method of replenishing a prepaid account for goods or services via a financial data network, comprising the steps of: (a) receiving the user's transaction request to replenish the user's account through the service end device; (b) verifying the existence of the user's account by communicating with the account data source accessible to the provider of the goods or services; (C) verifying a payment method associated with a user request for a transaction through the financial data network; (d) updating the account data source to reflect the user's transaction request; and (e) returning a confirmation of completing the user's transaction request to the user. The method of claim 11, wherein the service end device is an ATM or point of sale system. The method of claim 11, wherein the service end means is a personal communication means. 14. The method of claim 11, further comprising the step of accessing the card register data source to provide payment method data to the financial data network. The method of claim 11, comprising the step of accessing a cryptographic system for encrypting payment method data provided to a financial data network. 16. The method of claim 11, wherein the step of verifying the payment method comprises verifying a payment received at a remote user location. 17. The method of claim 11, further comprising the step of informing the user that the current account balance has fallen below a predetermined value. 18. The method of claim 11, wherein the user &apos; s transaction request comprises a single message containing all of the user &apos; s input for completion. replenishment transactions. 19. A system for the purchase of goods or services using prepaid vouchers, comprising: a voucher asset containing a plurality of unique identifier of prepaid vouchers; a transaction system in conjunction with a voucher data source for locating a voucher identifier in response to a user's transaction request and a service end-user for receiving the user's service request and delivering the voucher identifier to the user. The system of claim 19, wherein the service end device is an ATM or point of sale system. 21. The system of claim 19, wherein the service end means is a personal communication means. 22. The system of claim 19, further comprising a financial data network in conjunction with a transaction system for providing payment billing. 23. A method of purchasing goods or services using prepaid vouchers comprising the steps of: (a) accessing the service terminal; (b) selecting the goods or services to be purchased through the service end device; (c) providing payment information via the serving end device to the financial data network; »99 i» 9 9 * ·· • 9 9 9 9 9 ··· · * · 99 * 9 9 * 16011 -48 (d) obtaining the voucher identification by means of a service end device from the voucher data source; and (e) redeeming the voucher by presenting the voucher identification to the provider of the selected goods or service. 24. The method of claim 23, wherein the service end device is an ATM or point of sale system. 25. The method of claim 23, wherein the service end means is a personal communication means. The method of claim 23, wherein step (c) comprises providing a user identification for use in accessing payment method data stored in the card register data source. 27. The method of claim 23, wherein the step of providing payment information comprises a bid payment to a third party that provides a payment verification code for input through the service end device.